Android性能优化之UI布局渲染流程

一.CPU与GPU的简单比较

Control为控制器，用于协调整个CPU的运行，包括取指令、控制其他模块的运行等；

Cache和DRAM分别为缓存和RAM，用于存储信息。

ALU是算术逻辑单元，用于进行数学、逻辑运算。

从图中可看出CPU结构较为复杂，而ALU数量较少。因此CPU擅长各种复杂的逻辑运算，但不擅长数学运算尤其是浮点运算。

二.XML布局显示到屏幕的流程

（1）CPU将UI对象转换成多维图形 

（2）通过OPENGL调用GPU

（3）GPU对图形进行珊格化

以上三个步骤是否在16ms完成？

是 --> 显示器直接显示对应的UI

否 --> 垂直同步等待下一帧完成

大多数Android显示器运行在60帧/秒左右（或在显示行业60Hz）。在与手机交互的过程，触摸和反馈低于60帧时，你会感觉到画面的卡顿现象，60帧以上人是不会察觉到变化的。

Android系统每隔16ms就会发出VSYNC信号（1000ms/60=16.6ms）,触发对UI进行渲染，如果每次渲染都成功，这样就能够达到流畅的画面所需要的60fps，为了能够实现60fps,这意味着计算渲染的大多数操作都必须在16ms内完成。

三.卡顿原理分析

当一帧画面渲染时间超过16ms的时候，VSYNC信息号的垂直同步机制会让显示器硬件等待GPU完成珊格化渲染操作，这样会让这一帧画面，多停留了16ms,甚至更多，这样就造成屏幕的卡顿现象。

四.如何解决卡顿问题

16ms主要被两件事占用： 如何减少这两部分时间：

CPU将UI对象转换成多边形和纹理 ---> CPU减少对xml转换成对象的时间

CPU传递数据到GPU，GPU进行绘制 ---> GPU减少重复绘制

过度绘制

GPU的绘制过程是根据CPU传递的指令来的，它让画什么就画什么，16ms就画一次。造成有些图像被其他图像覆盖，底下以及面上的图像都要绘制，造成没有必要的浪费

过度绘制的几种情况

1.布局层级太深，用户看不到的区域也被绘制

2.自定义控件中，onDraw方法做了过多的绘制。

过度绘制查看工具

原色 – 没有被过度绘制 – 这部分的像素点只在屏幕上绘制了一次。

蓝色 – 1次过度绘制– 这部分的像素点只在屏幕上绘制了两次。

绿色 – 2次过度绘制 – 这部分的像素点只在屏幕上绘制了三次。

粉色 – 3次过度绘制 – 这部分的像素点只在屏幕上绘制了四次。

红色 – 4次过度绘制 – 这部分的像素点只在屏幕上绘制了五次。