一文搞定Android VSync机制来龙去脉

1. VSync的起源

显示屏上一帧画面的显示过程，是像素自上而下逐行扫描的过程，如果在上一帧的扫描还没有结束的情况下，屏幕又开始扫描下一帧的像素，那么就会出现如下图中撕裂（tearing）的情况。

这个问题最初是在PC上被重视和解决的，GPU厂商开发出了一种防止屏幕被撕裂的技术方案，全称Vertical Synchronization（中文名垂直同步，简称VSync）。基本思路就是在屏幕刷新之前向外提供一个信号，主机端根据此信号选择合适的策略完成画面的刷新，避免数据刷新和屏幕扫描不匹配（撕裂）的情况发生。所以VSync信号也叫做TE信号或VBlank信号。

下图展示了开启与关闭Vsync的状态下，屏幕画面的不同显示情况。这里需要先说明一下传统的显示架构，主要有三部分组成，第一部分负责渲染，包含CPU，GPU及一些系统模块；第二部分叫做帧缓冲，实质上是一块内存块，渲染完的数据会被保存在这块内存中；第三部分是屏幕，用来绘制帧缓冲上的数据。一般来说帧缓冲会有两块，一块叫做backbuffer，用来写入渲染数据，一块叫做frontbuffer，用来把渲染数据送给屏幕。这两块buffer的状态是不断变化的，也就是说当backbuffer被写入完数据等待显示时，它就变成了frontbuffer，而当frontbuffer的数据被显示完毕之后，它就变成了backbuffer。

VSync off：

VSync on：

具体来说，硬件视角中的VSync其实就是一个电平信号，Panel上有一个单独的引脚，主机端需要有一个单独的GPIO与之相连，获取其信号变化；软件视角中的VSync其实就是一个GPIO的中断，一般是上升沿的中断，软件根据此中断完成相应的显示逻辑。

2. Andriod中的Vsync

2.1 背景

Android的显示系统一直使用双缓冲和VSync来防止屏幕画面发生撕裂现象，这也是其他系统的常规操作。Android的不同之处是将VSync运用到绘制系统中，作为黄油计划（Project Butter）的一部分，用以提升系统的流畅度。

黄油计划从android4.1引入，主要有三部分：VSync、Choreographer和Triple Buffer

VSync:

Android中VSync的作用是统一系统绘制与显示节奏（Apps和SurfaceFlinger），大家各司其职，确保在VSync来的时候干活，这样系统理论上就丝滑了。

如下图，在没有VSync的情况下，系统渲染的节奏与屏幕刷新的节奏不一致，如果某一帧系统渲染的比较晚，那么就会出现屏幕两次刷新都显示同一份内容的情况，也就是Jank（掉帧）。

有了VSync的话，系统会在VSync到来时进行绘制，与屏幕的刷新节奏保持一致，这样就大大降低了jank的概率。

那么问题来了，怎么让Apps根据VSync的节奏来进行绘制呢？App依赖系统的绘制系统，所以必须让绘制系统听命令才行，这就是Choreographer出现的原因。

Choreographer：

Choreographer（编舞者）的作用在源码的注释中已经写得很明白，是用来接收定时脉冲信号来控制绘制的模块。也就是说，有了Choreographer，apps就能够根据Vsync信号来进行周期性的绘制工作。

以上两者配合就基本上完成了Android中VSync的改造，但是还有一个造成Jank的原因也是不容忽视的，这就是双buffer机制带来的jank风险。

Triple Buffer：

如下图，理想情况下的双buffer是没有问题的，这个理想状态是指绘制工作（可以粗略地理解为一帧CPU和GPU执行的总耗时）在一个VSync周期内完成，这样的情况下，不会发生jank。

遗憾的是，事情的发展不会总是按我们的预期来进行的，如果绘制时长超过了一个VSync周期，那么就必然会发生jank。如下图所示，有