一、Android渲染机制

Android的渲染机制，我们要知道Android系统每隔16ms就重新绘制一次Activity，也就是说，我们的应用必须在16ms内完成屏幕刷新的全部逻辑操作，即每一帧只能停留16ms

• 16秒原理简述
  16ms意味着1000/60hz，相当于60fps。这是因为人眼与大脑之间的协作无法感知超过60fps的画面更新。12fps大概类似手动快速翻动书籍的帧率， 这明显是可以感知到不够顺滑的。24fps使得人眼感知的是连续线性的运动，这其实是归功于运动模糊的效果。 24fps是电影胶圈通常使用的帧率，因为这个帧率已经足够支撑大部分电影画面需要表达的内容，同时能够最大的减少费用支出。 但是低于30fps是 无法顺畅表现绚丽的画面内容的，此时就需要用到60fps来达到想要的效果，超过60fps就没有必要了。如果我们的应用没有在16ms内完成屏幕刷新的全部逻辑操作，就会发生卡顿。

• 为啥超过16S会发生卡顿
  Android系统每隔16ms发出VSYNC信号，触发对UI进行渲染，VSync是Vertical Synchronization(垂直同步)的缩写，是一种在PC上很早就广泛使用的技术，可以简单的把它认为是一种定时中断。而在Android 4.1(JB)中已经开始引入VSync机制。

image.png

由图可知，每收到VSYNC中断，CPU就开始处理各帧数据。整个过程非常完美。 不过，仔细琢磨图2却会发现一个新问题：图2中，CPU和GPU处理数据的速度似乎都能在16ms内完成，而且还有时间空余，也就是说，CPU/GPU的FPS（帧率，Frames Per Second）要高于Display的FPS。确实如此。由于CPU/GPU只在收到VSYNC时才开始数据处理，故它们的FPS被拉低到与Display的FPS相同。但这种处理并没有什么问题，因为Android设备的Display FPS一般是60，其对应的显示效果非常平滑。 如果CPU/GPU的FPS小于Display的FPS，会是什么情况呢？请看下图：

image

由图可知： 1.在第二个16ms时间段，Display本应显示B帧，但却因为GPU还在处理B帧，导致A帧被重复显示。 2.同理，在第二个16ms时间段内，CPU无所事事，因为A Buffer被Display在使用。B Buffer被GPU在使用。注意，一旦过了VSYNC时间点， CPU就不能被触发以处理绘制工作了。

二、原理简述

上面说了CPU和GPU的处理时间因为各种原因都大于一个VSync的间隔（16.6ms），导致了卡顿。渲染操作通常依赖于两个核心组件：CPU与GPU。CPU负责包括Measure，Layout，Record，Execute的计算操作，GPU 负责Rasterization(栅格化)操作。何为栅格化，看下图。

image.png

所谓的栅格化就是绘制那些Button，Shape，Path，String，Bitmap等组件最基础的操作。它把那些组件拆分到不同的像素上进行显示，说的俗气一点，就是解决那些复杂的XML布局文件和标记语言，使之转化成用户能看懂的图像，但是这不是直接转换的，XML布局文件需要在CPU中首先转换为多边形或者纹理，然后再传递给GPU进行格栅化，对于栅格化，跟OpenGL有关，格栅化是一个特别费时的操作。

image.png

分析到这里，16毫秒的时间主要被两件事情所占用，第一件：将UI对象转换为一系列多边形和纹理；第二件：CPU传递处理数据到GPU。所以很明显，我们要缩短这两部分的时间，也就是说需要尽量减少对象转换的次数，以及上传数据的次数。

我们再看一图，这图简单说明CPU和GPU的职责工作，以及可能发生的问题和解决方案。

image.png

在CPU方面，最常见的性能问题是不必要的布局和失效，这些内容必须在视图层次结构中进行测量、清除并重新创建，引发这种问题通常有两个原因：一是重建显示列表的次数太多，二是花费太多时间作废视图层次并进行不必要的重绘，这两个原因在更新显示列表或者其他缓存GPU资源时导致CPU工作过度。在GPU方面，最常见的问题是我们所说的过度绘制（overdraw），通常是在像素着色过程中，通过其他工具进行后期着色时浪费了GPU处理时间。下面我们对GPU和CPU产生的两大问题进行优化。

• CPU产生的问题：不必要的布局
• GPU产生的问题：过度绘制（overdraw）