为了理解App是如何进行渲染的，我们必须了解手机硬件是如何工作，那么就必须理解什么是VSYNC。
在讲解VSYNC之前，我们需要了解两个相关的概念：
Refresh Rate：代表了屏幕在一秒内刷新屏幕的次数，这取决于硬件的固定参数，例如60Hz。
Frame Rate：代表了GPU在一秒内绘制操作的帧数，例如30fps，60fps。
GPU会获取图形数据进行渲染，然后硬件负责把渲染后的内容呈现到屏幕上，他们两者不停的进行协作。
不幸的是，刷新频率和帧率并不是总能够保持相同的节奏。如果发生帧率与刷新频率不一致的情况，就会容易出现Tearing的现象(画面上下两部分显示内容发生断裂，来自不同的两帧数据发生重叠)。
理解图像渲染里面的双重与三重缓存机制，这个概念比较复杂，请移步查看这里：http://source.android.com/devices/graphics/index.html，还有这里http://article.yeeyan.org/view/37503/304664。
通常来说，帧率超过刷新频率只是一种理想的状况，在超过60fps的情况下，GPU所产生的帧数据会因为等待VSYNC的刷新信息而被Hold住，这样能够保持每次刷新都有实际的新的数据可以显示。但是我们遇到更多的情况是帧率小于刷新频率。
在这种情况下，某些帧显示的画面内容就会与上一帧的画面相同。糟糕的事情是，帧率从超过60fps突然掉到60fps以下，这样就会发生LAG，JANK，HITCHING等卡顿掉帧的不顺滑的情况。这也是用户感受不好的原因所在。
Project Buffer背景介绍
随着时间的推移，AndroidOS系统一直在不断进化、壮大，日趋完善。但直到Android 4.0问世，有关UI显示不流畅的问题也一直未得到根本解决。在整个进化过程中，Android在Display（显示）系统这块也下了不少功夫，例如，使用硬件加速等技术，但本质原因似乎和硬件关系并不大，因为iPhone的硬件配置并不比那些价格相近的Android机器的硬件配置强，而iPhone UI的流畅性强却是有目共睹的。
从Android 4.1（版本代号为Jelly Bean）开始，Android OS开发团队便力图在每个版本中解决一个重要问题（这是不是也意味着Android OS在经过几轮大规模改善后，开始进入手术刀式的精加工阶段呢？）。作为严重影响Android口碑问题之一的UI流畅性差的问题，首先在Android 4.1版本中得到了有效处理。其解决方法就是本文要介绍的Project Butter。
Project Butter对Android Display系统进行了重构，引入了三个核心元素，即VSYNC、Triple Buffer和Choreographer。其中，VSYNC是理解Project Buffer的核心。VSYNC是Vertical Synchronization（垂直同步）的缩写，是一种在PC上已经很早就广泛使用的技术。读者可简单的把它认为是一种定时中断。
接下来，本文将围绕VSYNC来介绍Android Display系统的工作方式[①]。请注意，后续讨论将以Display为基准，将其划分成16ms长度的时间段，在每一时间段中，Display显示一帧数据（相当于每秒60帧）。时间段从1开始编号。
首先是没有VSYNC的情况，如图1所示：
由图1可知：
时间从0开始，进入第一个16ms：Display显示第0帧，CPU处理完第一帧后，GPU紧接其后处理继续第一帧。三者互不干扰，一切正常。
时间进入第二个16ms：因为早在上一个16ms时间内，第1帧已经由CPU，GPU处理完毕。故Display可以直接显示第1帧。显示没有问题。但在本16ms期间，CPU和GPU却并未及时去绘制第2帧数据（注意前面的空白区），而是在本周期快结束时，CPU/GPU才去处理第2帧数据。
时间进入第3个16ms，此时Display应该显示第2帧数据，但由于CPU和GPU还没有处理完第2帧数据，故Display只能继续显示第一帧的数据，结果使得第1帧多画了一次（对应时间段上标注了一个Jank）。
通过上述分析可知，此处发生Jank的关键问题在于，为何第1个16ms段内，CPU/GPU没有及时处理第2帧数据？原因很简单，CPU可能是在忙别的事情（比如某个应用通过sleep固定时间来实现动画的逐帧显示），不知道该到处理UI绘制的时间了。可CPU一旦想起来要去处理第2帧数据，时间又错过了！
为解决这个问题，Project Buffer引入了VSYNC，这类似于时钟中断。结果如图2所示：
由图2可知，每收到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，会是什么情况呢？请看图3：
由图3可知：
在第二个16ms时间段，Display本应显示B帧，但却因为GPU还在处理B帧，导致A帧被重复显示。
同理，在第二个16ms时间段内，CPU无所事事，因为A Buffer被Display在使用。B Buffer被GPU在使用。注意，一旦过了VSYNC时间点，CPU就不能被触发以处理绘制工作了。
为什么CPU不能在第二个16ms处开始绘制工作呢？原因就是只有两个Buffer。如果有第三个Buffer的存在，CPU就能直接使用它，而不至于空闲。出于这一思路就引出了Triple Buffer。结果如图4所示：
图4 Triple Buffer的情况
由图4可知：
第二个16ms时间段，CPU使用C Buffer绘图。虽然还是会多显示A帧一次，但后续显示就比较顺畅了。
是不是Buffer越多越好呢？回答是否定的。由图4可知，在第二个时间段内，CPU绘制的第C帧数据要到第四个16ms才能显示，这比双Buffer情况多了16ms延迟。所以，Buffer最好还是两个，三个足矣。
介绍了上述背景知识后，下文将分析Android Project Buffer的一些细节。
Project Buffer分析
上一节对VSYNC进行了理论分析，其实也引出了Project Buffer的三个关键点：
核心关键：需要VSYNC定时中断。
Triple Buffer：当双Buffer不够使用时，该系统可分配第三块Buffer。
另外，还有一个非常隐秘的关键点：即将绘制工作都统一到VSYNC时间点上。这就是Choreographer的作用。Choreographer是一个极富诗意的词，意为舞蹈编导。在它的统一指挥下，应用的绘制工作都将变得井井有条。
下面来看Project Buffer实现的细节。
首先被动刀的是SurfaceFlinger家族成员。目标是提供VSYNC中断。相关类图如图5所示：
由图5可知：
HardwareComposer封装了相关的HAL层，如果硬件厂商提供的HAL层实现能定时产生VSYNC中断，则直接使用硬件的VSYNC中断，否则HardwareComposer内部会通过VSyncThread来模拟产生VSYNC中断（其实现很简单，就是sleep固定时间，然后唤醒）。
当VSYNC中断产生时（不管是硬件产生还是VSyncThread模拟的），VSyncHandler的onVSyncReceived函数将被调用。所以，对VSYNC中断来说，VSyncHandler的onVSyncReceived，就是其中断处理函数。
在SurfaceFlinger家族中，VSyncHandler的实例是EventThread。下边是EventThread类的声明：
class EventThread : public Thread, public DisplayHardware::VSyncHandler
由EventThread定义可知，它本身运行在一个单独的线程中，并继承了VSyncHandler。EventThread的核心处理在其线程函数threadLoop中完成，其处理逻辑主要是：
等待下一次VSYNC的到来，并派发该中断事件给VSYNC监听者。
通过EventThread，VSYNC中断事件可派发给多个该中断的监听者去处理。相关类如图6所示：
由图6可知：
SurfaceFlinger从Thread派生，其核心功能单独运行在一个线程中。
SurfaceFlinger包括一个EventThread和一个MessageQueue对象。
对象通过mEvents成员指向一个IDisplayEventConnection类型的对象。IDisplayEventConnection是一个纯虚类，它代表VSYNC中断的监听者。其实体类是EventThread的内部类Connection。
IDisplayEventConnection定义了一个getDataChannel函数，该函数返回一个BitTube实例。这个实例提供的read/write方法，用于传送具体的信号数据（其内部实现为socketpair，可通过Binder实现进程跨越）。
EventThread最重要的一个VSYNC监听者就是MessageQueue的mEvents对象。当然，这一切都是为最大的后台老板SurfaceFlinger服务的。来自EventThread的VSYNC中断信号，将通过MessageQueue转化为一个REFRESH消息并传递给SurfaceFlinger的onMessageReceived函数处理。
有必要指出，4.1中SurfaceFlinger onMessageReceived函数的实现仅仅是将4.0版本的SurfaceFlinger的核心函数挪过来罢了[②]，并未做什么改动。
以上是Project Buffer对SurfaceFlinger所做的一些改动。那么Triple Buffer是怎么处理的呢？幸好从Android 2.2开始，Display的Page Flip算法就不依赖Buffer的个数，Buffer个数不过是算法的一个参数罢了。所以，Triple Buffer的引入，只是把Buffer的数目改成了3，而算法本身相对于4.0来说并没有变化。图7为Triple Buffer的设置示意图：
图7 Layer.cpp中对Triple Buffer的设置
图7所示，为Layer.cpp中对Buffer个数的设置。TARGET_DISABLE_TRIPLE_BUFFERING宏可设置Buffer的个数。对某些内存/显存并不是很大的设备，也可以选择不使用Triple Buffer。
Choreographer是一个Java类。第一次看到这个词时，我很激动。一个小小的命名真的反应出了设计者除coding之外的广博的视界。试想，如果不是对舞蹈有相当了解或喜爱，一般人很难想到用这个词来描述它。
Choreographer的定义和基本结构如图8所示：
图8中：
Choreographer是线程单例的，而且必须要和一个Looper绑定，因为其内部有一个Handler需要和Looper绑定。
DisplayEventReceiver是一个abstract class，其JNI的代码部分会创建一个IDisplayEventConnection的VSYNC监听者对象。这样，来自EventThread的VSYNC中断信号就可以传递给Choreographer对象了。由图8可知，当VSYNC信号到来时，DisplayEventReceiver的onVsync函数将被调用。
另外，DisplayEventReceiver还有一个scheduleVsync函数。当应用需要绘制UI时，将首先申请一次VSYNC中断，然后再在中断处理的onVsync函数去进行绘制。
Choreographer定义了一个FrameCallback interface，每当VSYNC到来时，其doFrame函数将被调用。这个接口对Android Animation的实现起了很大的帮助作用。以前都是自己控制时间，现在终于有了固定的时间中断。
Choreographer的主要功能是，当收到VSYNC信号时，去调用使用者通过postCallback设置的回调函数。目前一共定义了三种类型的回调，它们分别是：
CALLBACK_INPUT：优先级最高，和输入事件处理有关。
CALLBACK_ANIMATION：优先级其次，和Animation的处理有关。
CALLBACK_TRAVERSAL：优先级最低，和UI等控件绘制有关。
优先级高低和处理顺序有关。当收到VSYNC中断时，Choreographer将首先处理INPUT类型的回调，然后是ANIMATION类型，最后才是TRAVERSAL类型。
此外，读者在自行阅读Choreographer相关代码时，还会发现Android对Message/Looper类[③]也进行了一番小改造，使之支持Asynchronous Message和Synchronization Barrier（参照Looper.java的postSyncBarrier函数）。其实现非常巧妙，这部分内容就留给读者自己理解并欣赏了。
相比SurfaceFlinger，Choreographer是Android 4.1中的新事物，下面将通过一个实例来简单介绍Choreographer的工作原理。
假如UI中有一个控件invalidate了，那么它将触发ViewRootImpl的invalidate函数，该函数将最终调用ViewRootImpl的scheduleTraversals。其代码如图9所示：
图9 ViewRootImpl scheduleTraversals函数的实现
由图9可知，scheduleTraversals首先禁止了后续的消息处理功能，这是由设置Looper的postSyncBarrier来完成的。一旦设置了SyncBarrier，所有非Asynchronous的消息便将停止派发。
然后，为Choreographer设置了CALLBACK类型为TRAVERSAL的处理对象，即mTraversalRunnable。
最后调用scheduleConsumeBatchedInput，这个函数将为Choreographer设置了CALLBACK类型为INPUT的处理对象。
Choreographer的postCallback函数将会申请一次VSYNC中断（通过调用DisplayEventReceiver的scheduleVsync实现）。当VSYNC信号到达时，Choreographer doFrame函数被调用，内部代码会触发回调处理。代码片段如图10所示：
图10 Choreographer doFrame函数片段
对ViewRootImpl来说，其TRAVERSAL回调对应的处理对象，就是前面介绍的mTraversalRunnable，它的代码很简单，如图11所示：
图11 mTraversalRunnable的实现
doTraversal内部实现和Android 4.0版本一致。故相比于4.0来说，4.1只是把doTraversal调用位置放到VSYNC中断处理中了。
通过上边的介绍，可知Choreographer确实做到了对绘制工作的统一安排，不愧是个长于统筹安排的“舞蹈编导”。
