Android性能优化相关

1. UI卡顿的原因，如何优化？

View的绘制帧数保持60fps最佳，这要求没帧绘制时间不超过16ms，如果不能在16ms内完成界面的渲染，那么就会出现卡顿的现象。

卡顿原因分析：

• UI线程中做了耗时操作，导致UI线程卡顿
• 布局层次嵌套过多，过于复杂，无法在16ms内完成渲染
• 同一时间动画执行的次数过多，导致CPU和GPU负载过重
• overDraw，导致像素在同一帧的时间内被绘制多次
• view频繁的触发measure、layout，导致measure、layout类似耗时过多和整个view频繁重新渲染
• 频繁触发GC，使得16ms无法完成绘制
• ANR

优化：

• 布局优化
  • 删除无用的布局和层级，选择性使用性能较低的ViewGroup，如RelativeLayout（会对子View做两次Measure，因为有依赖关系，所以横向竖向分别要进行一次排序测量）。
  • 使用include，merge标签和Viewstub。include、merge标签可以降低布局的层级；Viewstub提供了按需加载，需要时才将布局加载到内存中，提高了程序初始化的效率。
• 绘制优化
  • onDraw中不要创建新的局部对象（因为onDraw方法可能会被频繁调用，瞬间产生大量对象，占用过多内存以及导致系统更加频繁GC，降低效率）
  • onDraw不要做耗时的任务，不要做过多的循环操作。

2. 内存泄漏，内存泄漏有哪些影响？常见的内存泄漏有哪些？怎么检测内存泄漏的？

内存泄漏：指程序分配出去的内存不再使用，无法进行回收。

延伸：非静态内部类天然持有外部类的引用；静态内部类不持有外部类的引用。

影响：

• 应用可用内存减少，增加堆内存压力
• 频繁触发GC，会降低应用的性能
• 到一定程度会导致内存溢出的错误

常见的内存泄漏：（括号里面为解决办法）

• 静态变量持有Activity的上下文 （减少使用static）
• 单例造成的内存泄漏（使用Application的Context）
• 匿名内部类与非静态内部类持有外部类的引用造成的（非静态内部类转换为静态内部类+弱引用）
• 各种注册的监听器，没有解注册（在onDestroy里面取消注册）
• Handler造成的（Handler持有的引用最好使用弱引用，在Activity被释放的时候要记得清空Message，取消Handler对象的）
• 资源对象未关闭，例如IO，数据库，Bitmap（及时关闭资源）
• 属性动画中无限循环的未取消（及时取消动画）

如何检测内存泄漏：AS monitor、MAT、LeakCanary

数据结构相关

1.数组与链表的区别

各种细节问题收集及解答

1. 扩大view的点击区域怎么做？

   • 将点击事件写在父View上
   • 增加padding，适合图片等dp或px为单位的view，不适合textview，button等包含sp计算单位的view
   • 通过TouchDelegate来扩大view的点击区域

2. requestLayout和invalide的区别

   requestLayout会从View树重新进行一次测量、布局、绘制；invalidate只会开始View树的绘制（只绘制需要重绘的视图），在UI线程中调用；postInvalidate是在非UI线程中调用。

3. LRUCache（最近最少使用算法）的原理

   LRU是近期最少使用的算法，它的核心思想是当缓存满时，会优先淘汰那些近期最少使用的缓存对象。

   缓存策略分为添加、获取和删除，为什么需要删除缓存呢？因为每个设备都会有一定的容量限制，当容量满了的话就需要删除。

   LRUCache是个泛型类，主要算法原理是把最近使用的对象用强引用存储在LinkedHashMap中。当缓存满时，把最近最少使用的对象从内存中移除，并提供了get和put方法来完成缓存的存取和添加操作。

一些性能优化建议

• 避免创建过多的对象
• 不要过多使用枚举，枚举占用的内存空间要比整型大
• 常量请使用static final来修饰
• 使用一些Android特有的数据结构，比如SparseArray和Pair等，它们都具有更好的性能
• 适当使用软引用和弱引用
• 采用内存缓存和磁盘缓存
• 尽量采用静态内部类，这样可以避免潜在的由于内部类而导致的内存泄漏