View的渲染机制

Android渲染机制基础认知

我们都知道，计算机是基于二进制数据流来进行工作的，而且又知道，计算机五大组成部分是各司其职的，其中屏幕就是专门来"渲染"图像的，既然要显示图像，肯定要有显示的数据，这些数据从哪来呢？答案就是cpu(「这里为了方便，把cpu、gpu、sf等统一称为cpu」)，这些数据由cpu提供，cpu经过各种运算，将数据写入一块内存中，这块内存叫做「帧缓冲」，我们可以将帧缓冲理解为一个M*N矩阵，数据从上到下一行一行保存，显示器在显示的时候，从上到下逐行扫描，依次显示在屏幕上，我们把这样的一屏数据叫做「一帧」，当一帧数据渲染完后，就开始新一轮扫描，如果CPU「正好」(不正好后面再说)也把下一帧数据写入帧缓冲，那么就会显示下一帧画面，如此循环，我们就看到了不断变化的画面，也就是图像。这个过程很简单，但是实现起来却很难，具体有两点:

• 屏幕需要在16.7毫秒内绘制完一帧，因为根据研究，16.7ms正符合人类能觉察到卡顿的分割点，如果低于16.7ms，则可能感觉卡顿，高于16.7ms则没必要。

• CPU需要在屏幕渲染完毕后，正好把下一帧数据写入帧缓冲。如果早了，那么屏幕上就会绘制一半上一帧的数据，一半下一帧的数据。比如:绘制到第一帧的a行时，cpu把下一帧数据送进来了，屏幕会接着从a+1行接着绘制，这样导致前a行是第一帧的数据，后面几行是第二帧的数据，在我们看来就是两张图片撕开各取一部分拼起来，这叫做「撕裂」。如果晚了，那么屏幕会在下一次继续绘制上一帧，导致画面没有变化，这样就会出现画面不变的情况，在我们看起来就是卡了，也叫做「卡顿」。所以，CPU和屏幕的这个交互时机很重要。

渲染流程线：UI对象—->CPU处理为多维图形,纹理 —–通过OpeGL ES接口调用GPU—-> GPU对图进行光栅化(Frame Rate ) —->硬件时钟(Refresh Rate)—-垂直同步—->投射到屏幕。

用一句话来概括一下Android应用程序显示的过程：Android应用程序调用SurfaceFlinger服务把经过测量、布局和绘制后的Surface渲染到屏幕上。

CPU: 中央处理器,它集成了运算,缓冲,控制等单元,包括绘图功能.CPU负责包括Measure，Layout，Record，Execute的计算操作，将对象处理为多维图形,纹理(Bitmaps、Drawables等都是一起打包到统一的纹理)。

GPU:一个类似于CPU的专门用来处理Graphics（图形）的处理器, 作用用来帮助加快栅格化操作,当然,也有相应的缓存数据(例如缓存已经光栅化过的bitmap等)机制。

OpenGL ES是手持嵌入式设备的3DAPI,跨平台的、功能完善的2D和3D图形应用程序接口API,有一套固定渲染管线流程。

DisplayList 在Android把XML布局文件转换成GPU能够识别并绘制的对象。这个操作是在DisplayList的帮助下完成的。DisplayList持有所有将要交给GPU绘制到屏幕上的数据信息。

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

垂直同步VSYNC:让显卡的运算和显示器刷新率一致以稳定输出的画面质量。它告知GPU在载入新帧之前，要等待屏幕绘制完成前一帧。

屏幕刷新率(Hz)：屏幕在一秒内刷新的次数，Android手机一般都是60Hz，也就是一秒刷新60次，当然也有高刷的，但是60Hz足矣。

SurfaceFlinger：Android系统服务，负责管理Android系统的帧缓冲