performance optimization for animation
TRANSCRIPT
朱才
画卡 的 化动 顿 调试优
目录
1. 动画简介
2. 发现掉帧
3. 找出问题
4. 解决问题
动画简介
1. 动画简介
动画简介
好的动画：连贯。
动画简介
影响连贯的因素：
1. 动画因子不连贯
2. 帧率低或不稳定：掉帧
动画简介
最常见的问题：掉帧。
发现掉帧
2. 发现掉帧
发现掉帧
肉眼观察
GPU呈现模式
Systrace
发现掉帧
GPU呈现模式
蓝色（ getDisplayList） CPU： getDisplayList的过程， java层 View的 draw方法。
红色（ drawDisplayList） CPU&GPU：执行 draw DisplayList的过程。
黄色（ dequeueBuffer&eglSwapBuffers）：将绘制好的 Buffer交给 SurfaceFlinger。
发现掉帧
GPU呈现模式
缺点：
它是用来反映 draw方法中三个过程的时间，不能完全真实的反映卡顿情况。长一定会有掉帧，但不长不表示就没有掉帧。
发现掉帧
Systrace
最佳利器。可以精确判断是否掉帧，哪里掉帧。
发现掉帧
Systrace 怎么看掉帧
发现掉帧
Systrace 怎么看掉帧
发现掉帧
Buffer Queue
3缓冲：对于每个Window， Buffer Queue中有 3个 Buffer。1个 Buffer的状态变化： Released -> Dequeued -> Queued -> Acquired -> ... 可在 Systrace上查看 Buffer的流转情况
发现掉帧
Buffer QueueSurfaceFlinger并不总是马上使用最近的 Buffer。当 Queued Buffer有 2个时，则先使用之前那个。
找出问题
3. 找出问题
找出问题
Systrace
Method Trace (仅辅助作用 )
OpenGL Trace
找出问题
Systrace抓取 systrace的时候除了选择 Graphics, Input, ViewSystem, 还建议选上 Resource Loading, Dalvik VM。
找出问题
通过 Systrace找出这一帧中哪段时间比较长：
找出问题
通过 Systrace找出这一帧中哪段时间比较长：
1. getDisplayList
2. drawDisplayList
3. dequeueBuffer & eglSwapBuffers
4. 有 GC
6. 上面的都不是，在 performTraversals之外比较长
7. 其他
找出问题
getDisplayList 时间长：
因为是 java 层的调用，可以先用 Method Trace 简单看一看。
在比较怀疑的地方用 Trace.beginSection/endSection 为 Systrace 添加自定义Trace 。
在 View.java 的 getDisplayList/draw 等方法里为 Systrace 添加自定义 Trace 。
用这些方式找出耗费时间长的地方。
找出问题
getDisplayList 时间长：
找出问题
drawDisplayList 时间长： Systrace
可以先打开“开发者选项”里的“启动 OpenGL 跟踪” -> “Systrace （图形）”。
这样抓出来的 systrace 文件的 getDisplayList 这项下面会有更详细的信息。
找出问题
drawDisplayList 时间长： Systrace
找出问题
drawDisplayList 时间长： OpenGL Trace
OpenGL Trace 可以更清楚的看到整个调用过程。
可以发现哪个过程最耗时；可以发现不该有的调用。
找出问题
drawDisplayList 时间长： OpenGL Trace
找出问题
drawDisplayList 时间长： OpenGL Trace
OpenGL Trace 显示出了最终 OpenGL 的调用过程。需要一些 OpenGL 知识来看明白这个 Trace 。
找出问题
drawDisplayList 时间长：
通过发现的 OpenGL 的耗时调用，找出对应的 View/draw 的问题原因：
Overdraw 太多；View 太多， draw 次数太多；不可见的 View/ 内容 也有 draw 的过程；硬件层更新；触发了某个耗时命令：如 glCopyTexSubImage2D ；Bitmap 被修改，再次绘制的时候需要重新加载纹理；等等。
找出问题
dequeueBuffer & eglSwapBuffers 时间长：
这个一般都是 SurfaceFlinger 端的阻塞导致的。 app 端没有办法。一般不会遇到。
找出问题
出现 GC ：
抓取 systrace 的时候选上“ dalvik VM” 则会清楚的看到 GC 的发生时间。
找出问题
出现 GC ：
用 DDMS 的 Allocation Tracker 来跟踪动画过程中创建了哪些对象。
找出问题
performanTraversals 之外的时间长：
说明不是绘制的过程导致的。现在 measure/layout/obtainView 等方法都已经有在 Trace 中，所以如果是这些耗时也可以轻松看出来。如果仍然不是，则需要自己找到怀疑的地方打 Trace 。
找出问题
其他：
还有一些情况，不是 app 自己的问题，而是环境导致的。
如：某个 app 抢占 CPU 太厉害（可通过 Systrace 或 adb shell top 来看）；如 CPU&GPU 频率不够（可通过 Systrace 抓取对应信息）；等等。
解决问题
4. 解决问题
解决问题
解决问题：
一般来讲，就是想办法避免耗时方法。需要具体情况具体对待。
解决问题
一些常见的情况 / 建议：
overdraw 太多，去掉看不到的那些，看得到的也尽量优化；复杂的且不太变化的 View 可设为 HardwareLayer ；会变化的 View 不应该在 HardwareLayer 里；尽量避开 glCopyTexSubImage2D(Canvas.saveLayer 要传 CLIP_TO_LAYER_SAVE_FLAG) ；对 View 设置 alpha 或 alpha 动画时考虑 override 其 hasOverlappingRendering 返回false ；尽量避免每帧都触发 measure ；尽量避免动画过程中创建对象，用静态变量或对象池复用对象。
链接
Android Performance Case Study: http://www.curious-creature.com/docs/android-performance-case-study-1.html上文的译文： http://www.importnew.com/3784.html
Hardware Acceleration: http://developer.android.com/guide/topics/graphics/hardware-accel.html
Graphics: https://source.android.com/devices/graphics/index.html
Architecture:http://source.android.com/devices/graphics/architecture.html
Systrace:http://developer.android.com/tools/help/systrace.htmlhttp://developer.android.com/tools/debugging/systrace.html
Tracer for OpenGL ES (OpenGL Trace):http://developer.android.com/tools/help/gltracer.html
