Android UI 分析工具篇

Android UI 探析

---

介绍

一般不管是游戏还是App都会要求FPS（每秒帧率）不能低于30，如果低于30就会产生不顺畅的感觉。

App的性能目标为60FPS。也就是一帧在16ms = 1000ms/60的时间内处理完。如果处理不完则就会出来drop frames的情况，可在logcat里面查看

---

表现

1. UI执行动画
2. 滑动ListView
3. Activity或者fragment切换时的卡顿

---

原因

1. layout太过复杂
2. UI上有层叠太多的绘制单元
3. 动画执行的次数过多
4. 被忽视的一点：GC操作
   
   1. Dalvik ART
   2. 新生代，老年代，永久代
   3. 每一个级别的内存区域都有固定的大小，执行GC操作的时候，任何线程的任何操作都会需要暂停
   4. 内存抖动

---

检查

1. 开发者选项->调试GPU过度绘制
2. 开发者选项->GPU呈现模式分析->条形图
   
   1. 绿色的横线——16ms
   2. 蓝色代表测量绘制Display List的时间
   3. 红色代表OpenGL渲染Display List所需要的时间
   4. 黄色代表CPU等待GPU处理的时间
3. 开发者选项->GPU呈现模式分析->在…中
   adb shell dumpsys gfxinfo
4. Systrace
   重点推荐
5. Hierarchy View
   
   1. 绿灯——高于50%的速度
   2. 黄灯——低于50%的速度
   3. 红灯——需要改进的极慢速度

---

待优化点

1. 
   
   1. 修改三红灯View
2. 注意List滑动帧率，提前加载多个？
3. Static holder

《Effective java》——如果声明成员类不要求访问外围实例，就要始终把static修饰符放在它的声明中，是它成为静态成员类，而不是非静态成员类

---

重点和总结

1. 对于多层嵌套的UI建议使用自定义View
2. 修改View的大小会触发整个HierarcyView的重新计算大小的操作。
   
   1. 如果是修改View的位置则会触发HierarchView重新计算其他View的位置。
   2. 如果布局很复杂，这就会很容易导致严重的性能问题。比如频繁GC，清空DisplayList重新测量。
3. 重写了onDraw方法的view，可以使用canvas.clipRect()
4. Inflate而不是setVisiblity