渲染性能优化

2017-04-15 本文已影响726人 i冰点

多数情況下，卡顿发生的根本原因，是渲染问题，即系统无法及时的完成复杂界面的渲染操作。系统会尝试每个16ms对UI进行渲染，如果每次都渲染成功，这样画面就是流畅的(达到了60fps)；否则，就会发生丢帧现象，丢帧越多，用户感受到的卡顿情况就越严重。
为了获得更平滑的动画，就必须保证帧率不低于60fps——意味着每帧只能花费16毫秒的时间。

1、一些概念

1、刷新率vs帧率

刷新率：每秒屏幕刷新次数，手机屏幕的刷新率是60HZ
帧率：GPU在一秒内绘制的帧数

2、撕裂vs掉帧

撕裂
因为屏幕的刷新过程是自上而下、自左向右的，如果帧率>刷新率，当屏幕还没有刷新n-1帧的数据时，就开始生成第n帧的数据了，从上到下，覆盖第n-1帧。如果此时刷新屏幕，就会出现图像的上半部分是第n帧的，下半部分是第n帧的现象。CPU/GPU一直都在渲染

撕裂

丢帧
Android系统每隔16ms发出VSYNC信号，触发GPU对UI进行渲染，如果你的某个操作花费时间是24ms，系统在得到VSYNC信号的时候由于还没有准备好，就无法进行更新任何内容，那么用户在32ms内看到的会是同一帧画面（卡顿现象），即丢帧现象。

丢帧

3、单缓存 vs VSYNC vs 双缓存 vs 三缓存

单缓存（没有引入VSync ）
GPU向缓存中写入数据，屏幕从缓存中读取数据，刷新后显示。由于刷新率和帧率并不总是一致的，很可能导致撕裂的现象。为了解决单缓存的画面撕裂问题，出现了双缓存和 VSync 。
单缓存

VSYNC 和双缓存
双缓存使用了两个缓存区： Back Buffer 、 Frame Buffer。当写入下一帧时，GPU会先填充 Back Buffer 中，当刷新屏幕时，屏幕从 Frame Buffer 中读数据。VSYNC 主要是完成帧的复制，开始下一帧的渲染。

双缓存

当帧率大于刷新频率时，通过使帧率被迫跟刷新频率保持同步，从而避免画面撕裂的现象（只有当 VSync 信号产生时， CPU/GPU 才会开始绘制）。当VSync 信号产生时，先完成Back Buffer 到 Frame Buffer的复制操作（通过交换内存地址），然后通知 CPU/GPU 绘制下一帧图像。也只有VSync 信号发生时，才绘制下一帧。

VSYNC 和双缓存

当刷新频率>帧率时，此时刷新屏幕，发出VSYNC 信号，由于CPU/GPU的渲染操作还没有完成，就不把Back Buffer的数据复制到 Frame Buffer，此时就从Frame Buffer去取旧数据，这样在两个刷新周期里，显示的是同一帧数据，掉帧

三重缓存

三缓存

双重缓存的缺陷在于：当 CPU/GPU 绘制一帧的时间超过 16 ms 时，会产生 Jank。更要命的是，产生 Jank 的那一帧的显示期间，GPU/CPU 都是在闲置的。
如下图，A、B 和 C 都是 Buffer。

双重缓存

如果有第三个 Buffer 能让 CPU/GPU 在这个时候继续工作，那就完全可以避免第二个 Jank 的发生了！

三重缓存

2、渲染是怎么实现的

如何把布局渲染成用户可以识别的图片？它的核心是通过栅格化操作，将一些按钮、文字等布局对象拆分到像素点进行显示。由于栅格化是非常费时的，因此引入了GPU加快栅格化过程。

整个处理过程是：CUP负把把UI对象转变GPU可以识别的成图元（多边形、纹理），然后上传到GPU进行栅格化过程。

渲染的过程

1、在GPU中保存图元

但是由于这个转换、上传都是耗时的，所以为了减少时间，需要减少它们的数量，庆幸的是Open GL API，允许你将这些图元保存到GPU，当下次需要一个按钮的时候，只要参考GPU中已经存在的图元，告诉GPU如何去绘制它。优化渲染性能就意味着尽可能多且快的将更多的数据上传到GPU，然后留在GPU，尽可能长时间的不去修改它。

转换、上传耗时

将图元保存到GPU

2、display list，CPU、GPU沟通的桥梁

将图元从CPU上传到GPU，这个操作是在DisplayList的帮助下完成的。DisplayList持有GPU渲染时需要的信息，包括了一些图元和Open GL命令列表。

CPU直接与GPU通信，而是通过中间的一个图形驱动层（Graphics Driver）来连接这两部分。图形驱动维护了一个队列，CPU把display list添加到队列里，GPU从这个队列取出数据进行绘制。

Display List，在View第一次需要被渲染时被创建，当这个View要显示到屏幕上时，我们会执行GPU的绘制指令来执行这个Display List。

CUP 工作

GPU

整体流程是：CUP负把把UI对象转变GPU可以识别的成图元（多边形、纹理），并存储进display list列表；GPU执行绘图指令来执行display list，取出相应的图元信息，进行栅格化渲染

3、引起的原因和检测方法

主要有以下几点，可能引起渲染的性能问题：

布局Layout过于复杂，无法在16ms内完成渲染。
同一时间动画执行的次数过多，导致CPU或GPU负载过重。
View过度绘制，导致某些像素在同一帧时间内被绘制多次。
UI线程中做了稍微耗时的操作。

可以通过如下工具进行检测
HierarchyViewer（布局尽量扁平化）、Show GPU Overdraw、Profile GPU Rendering等等

1、Profile GPU Rendering

１、打开手机里面的开发者选项，选择Profile GPU Rendering，选中On screen as bars的选项

通过Profile GPU Rendering，可以在屏幕上实时显示渲染每一帧图像花费的时间。渲染时间用柱状图表示，每一条柱状图都由3部分组成，蓝色、红色和黄色，代表渲染的3个不同的阶段，通过分析这三个阶段的时间就可以找到渲染时的性能瓶颈。

Profile GPU Rendering

2、使用命令

adb shell dumpsys gfxinfo yourpackagename

命令

将得到的数据保存为txt，之后导出到excel（数据-导入数据），生成图表

fps图表

Draw:表示在Java中创建显示列表部分中，OnDraw()方法占用的时间。
Process：表示渲染引擎执行显示列表所花的时间，view越多，时间就越长
Execute：表示把一帧数据发送到屏幕上排版显示实际花费的时间。其实是实际显示帧数据的后台缓存区与前台缓冲区交换后并将前台缓冲区的内容显示到屏幕上的时间。所以这个时间，一般都很短。
Draw + Process + Execute = 完整显示一帧，这个时间要小于16ms才能保存每秒60帧（即1000秒/60帧）。　　
将数据复制到 excel中，然后将数据生成“柱形图”来观察结果。

参考：Android性能专项FPS测试实践

3、通过Android Studio的GPU Monitor查看

Android Studio的GPU Monitor

4、分析

随着界面的刷新，界面上会滚动显示垂直的柱状图来表示每帧画面所需要渲染的时间，柱状图越高表示花费的渲染时间越长。中间有一根绿色的横线，代表16ms，我们需要确保每一帧花费的总时间都低于这条横线，这样才能够避免出现卡顿的问题。
每一条柱状线都都包含三部分

蓝色代表测量绘制Display List的时间，是CPU将UI对象转变成图元，并缓存在display list的时间
视图（display list ）突然无效了
红色是GPU执行渲染指令，使用OpenGL执行Display List的时间
view过于复杂或绘制多次
黄色代表CPU等待GPU处理的时
GPU做了太多的工作

总之，布局层次过深，view过于复杂都会导致时间过长

Android 4.0-5.0的柱状条

Android 6.0以上的柱状条

Swap Buffers（黄色）：CPU等待GPU的时间
Command Issue（红色）：OpenGL绘制display list的时间
Sync/upload（浅蓝色）：代表上传bitmap到GPU的时间，如果值比较大，是因为花费了相当多的时间价值大量图片。
Draw（蓝色）：创建和更新display list的时间
Misc Time/Vsync Delay（深绿）：在两个连续的帧之间执行的操作，如果很大，可能因为在UI线程做了太多的工作。
Input Handling（浅绿）：处理用户的输入事件，花费的时间
Animation（浅浅绿）：在当前帧中的动画花费了的时间