对Android App 中卡顿的处理和分析

用户对卡顿的感知, 主要来源于界面的刷新. 而界面的性能主要是依赖于设备的UI渲染性能. 如果我们的UI设计过于复杂, 或是实现不够友好，计算绘制算法不够优化, 设备又不给力, 界面就会像卡住了一样, 给用户卡顿的感觉.，让用户体验感到很不爽，所以抽空总结一下    希望对大家能有所帮助

1.16ms原则   

Android 在不同的版本都会优化“UI的流畅性”问题，但是直到在android 4.1版本中做了有效的优化，这就是Project Butter。 
Project Butter 加入了三个核心元素: VSYNC、Triple Buffer 和 Choreographer。其中，VSYNC 是理解Project Buffer的核心。

VSYNC：产生一个中断信号 
Triple Buffer：当双 Buffer 不够使用时，该系统可分配第三块 Buffer 
Choreographer：这个用来接受一个 VSYNC 信号来统一协调UI更新

对于16ms原则想深入的了解的可以去研究研究 ，下面主要说说产生卡顿的原因和场景

1.1    过于复杂的布局

界面性能取决于 UI 渲染性能. 我们可以理解为 UI 渲染的整个过程是由 CPU 和 GPU 两个部分协同完成的。

其中, CPU 负责UI布局元素的 Measure, Layout, Draw 等相关运算执行. GPU 负责栅格化(rasterization), 将UI元素绘制到屏幕上。

如果我们的 UI 布局层次太深, 或是自定义控件的 onDraw 中有复杂运算, CPU 的相关运算就可能大于16ms, 导致卡顿。

解决方案： 
我们需要借助 Hierarchy Viewer 这个工具来帮我们分析布局了. Hierarchy Viewer 不仅可以以图形化树状结构的形式展示出UI层级, 还对每个节点给出了三个小圆点, 以指示该元素 Measure, Layout, Draw 的耗时及性能。
 

1.2    过度的绘制

Overdraw: 用来描述一个像素在屏幕上多少次被重绘在一帧上.

通俗的说: 理想情况下, 每屏每帧上, 每个像素点应该只被绘制一次, 如果有多次绘制, 就是 Overdraw, 过度绘制了。 常见的就是:绘制了多重背景或者绘制了不可见的UI元素.

解决方案： 
Android系统提供了可视化的方案来让我们很方便的查看overdraw的现象: 
在”系统设置”–>”开发者选项”–>”调试GPU过度绘制”中开启调试: 
此时界面可能会有五种颜色标识:

overdraw indicator

原色: 没有overdraw
蓝色: 1次overdraw
绿色: 2次overdraw
粉色: 3次overdraw
红色: 4次及4次以上的overdraw

1.3   UI线程的复杂运算

UI线程的复杂运算会造成UI无响应, 当然更多的是造成UI响应停滞, 卡顿。产生ANR已经是卡顿的极致了。

解决方案： 
关于运算阻塞导致的卡顿的分析, 可以使用 Traceview 这个工具

1.4   频繁的使用GC

为什么说频繁的 GC 会导致卡顿呢? 
简而言之, 就是执行 GC 操作的时候，任何线程的任何操作都会需要暂停，等待 GC 操作完成之后，其他操作才能够继续运行, 故而如果程序频繁 GC, 自然会导致界面卡顿。

导致频繁GC有两个原因:

内存抖动(Memory Churn), 即大量的对象被创建又在短时间内马上被释放。
瞬间产生大量的对象会严重占用 Young Generation 的内存区域, 当达到阀值, 剩余空间不够的时候, 也会触发 GC。即使每次分配的对象需要占用很少的内存，但是他们叠加在一起会增加 Heap 的压力, 从而触发更多的 GC。
解决方案： 
一般来说瞬间大量产生对象一般是因为我们在代码的循环中 new 对象, 或是在 onDraw 中创建对象等。 
还是是尽量不要在循环中大量的使用局部变量。所以说这些地方是我们尤其需要注意的。

 

以上就是总结的卡顿现象的可能及解决办法   后期会持续更新