一文搞定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。如下图所示，有两帧的绘制超过了一个VSync周期，那么就会发生两次Jank。

三Buffer机制实际上就是在上述backbuffer和frontbuffer的基础上，再添加一块buffer进行轮转。在这样的情况下，同样假设有两帧的绘制就是大于一个VSync周期，那么只会造成一次Jank。

相当于多了个buffer，不用非得去等待一个才有的用，增加了流转性

三buffer机制虽然能降低jank的概率，但是也会带来Touch响应慢和内存消耗高的负面影响，只不过相对于它带来的效果，这些负面影响被忽略了。

本文重点讲VSync，下面就看下安卓系统中VSync是具体怎么产生和使用的。

2.2 VSync的虚拟化

由上面的介绍可以知道，VSync其实起源于显示屏，但是想想如果每个App和SurfaceFlinger都去从硬件驱动中直接监听VSync，那未免有点太复杂了，而且耦合性太高，不行。那怎么办呢？

因此，最好是有一个模块去专门跟驱动沟通，再由它将VSync信号广播给大家，就像一个hub一样。但是VSync频率这么高，每次从kernel到userspace的消耗也不少，而且VSync是周期性的，很容易猜，所以没必要一直从kernel监听，但是系统是一直需要VSync来控制绘制合成的，所以有必要搞一个虚拟的VSync来模拟硬件VSync了。大概架构如下图：

更多可以参考：https://mp.weixin.qq.com/s/gAcBEqjYAwSVwFSg2vuN8Q