面试：Android的16ms、垂直同步、三重缓存

“终于懂了” 系列：Android屏幕刷新机制—VSync、Choreographer 全面理解！ – 掘金

Android的16ms和垂直同步以及三重缓存 – 掘金

一、显示系统基础知识

在一个典型的显示系统中，一般包括CPU、GPU、Display三个部分， CPU负责计算帧数据，把计算好的数据交给GPU，GPU会对图形数据进行渲染，渲染好后放到buffer(图像缓冲区)里存起来，然后Display（屏幕或显示器）负责把buffer里的数据呈现到屏幕上。

数据处理顺序是：CPU–> GPU –> 屏幕Display

1.1 基础概念

• 屏幕刷新频率 一秒内屏幕刷新的次数（一秒内显示了多少帧的图像），单位 Hz（赫兹），如常见的 60 Hz。刷新频率取决于硬件的固定参数（不会变的）。

• 逐行扫描 显示器并不是一次性将画面显示到屏幕上，而是从左到右边，从上到下逐行扫描，顺序显示整屏的一个个像素点，不过这一过程快到人眼无法察觉到变化。以 60 Hz 刷新率的屏幕为例，这一过程即 1000 / 60 ≈ 16ms。

• 帧率 （Frame Rate） 表示 GPU 在一秒内绘制操作的帧数，单位 fps。例如在电影界采用 24 帧的速度足够使画面运行的非常流畅。而 Android 系统则采用更加流程的 60 fps，即每秒钟GPU最多绘制 60 帧画面。帧率是动态变化的，例如当画面静止时，GPU 是没有绘制操作的，屏幕刷新的还是buffer中的数据，即GPU最后操作的帧数据。

• 画面撕裂（tearing） 一个屏幕内的数据来自2个不同的帧，画面会出现撕裂感

1.2 双缓存

1.2.1 画面撕裂 原因

屏幕刷新频是固定的，比如每16.6ms从buffer取数据显示完一帧，理想情况下帧率和刷新频率保持一致，即每绘制完成一帧，显示器显示一帧。但是CPU/GPU写数据是不可控的，所以会出现buffer里有些数据根本没显示出来就被重写了，即buffer里的数据可能是来自不同的帧的， 当屏幕刷新时，此时它并不知道buffer的状态，因此从buffer抓取的帧并不是完整的一帧画面，即出现画面撕裂。

简单说就是Display在显示的过程中，buffer内数据被CPU/GPU修改，导致画面撕裂。

1.2.2 双缓存

那咋解决画面撕裂呢？ 答案是使用 双缓存。

由于图像绘制和屏幕读取 使用的是同个buffer，所以屏幕刷新时可能读取到的是不完整的一帧画面。

双缓存，让绘制和显示器拥有各自的buffer：GPU 始终将完成的一帧图像数据写入到 Back Buffer，而显示器使用 Frame Buffer，当屏幕刷新时，Frame Buffer 并不会发生变化，当Back buffer准备就绪后，它们才进行交换。如下图：

1.2.3 VSync

问题又来了：什么时候进行两个buffer的交换呢？

假如是 Back buffer准备完成一帧数据以后就进行，那么如果此时屏幕还没有完整显示上一帧内容的话，肯定是会出问题的。看来只能是等到屏幕处理完一帧数据后，才可以执行这一操作了。

当扫描完一个屏幕后，设备需要重新回到第一行以进入下一次的循环，此时有一段时间空隙，称为VerticalBlanking Interval(VBI)。那，这个时间点就是我们进行缓冲区交换的最佳时间。因为此时屏幕没有在刷新，也就避免了交换过程中出现 screen tearing的状况。

VSync(垂直同步)是VerticalSynchronization的简写，它利用VBI时期出现的vertical sync pulse（垂直同步脉冲）来保证双缓冲在最佳时间点才进行交换。另外，交换是指各自的内存地址，可以认为该操作是瞬间完成。

所以说V-sync这个概念并不是Google首创的，它在早年的PC机领域就已经出现了。

二、 屏幕绘制

作为严重影响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.时间从0开始，进入第一个16ms：Display显示第0帧，CPU处理完第一帧后，GPU紧接其后处理继续第一帧。三者互不干扰，一切正常。 2.时间进入第二个16ms：因为早在上一个16ms时间内，第1帧已经由CPU，GPU处理完毕。故Display可以直接显示第1帧。显示没有问题。但在本16ms期间，CPU和GPU 却并未及时去绘制第2帧数据（注意前面的空白区），而是在本周期快结束时，CPU/GPU才去处理第2帧数据。 3.时间进入第3个16ms，此时Display应该显示第2帧数据，但由于CPU和GPU还没有处理完第2帧数据，故Display只能继续显示第一帧的数据，结果使得第1 帧多画了一次（对应时间段上标注了一个Jank）。 4.通过上述分析可知，此处发生Jank的关键问题在于，为何第1个16ms段内，CPU/GPU没有及时处理第2帧数据？原因很简单，CPU可能是在忙别的事情（比如某个应用通过sleep 固定时间来实现动画的逐帧显示），不知道该到处理UI绘制的时间了。可CPU一旦想起来要去处理第2帧数据，时间又错过了！

VSYNC的出现

为解决这个问题，Project Buffer引入了VSYNC，这类似于时钟中断。结果如图所示：

由图可知，每收到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，会是什么情况呢？请看下图：

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

三级缓存

为什么CPU不能在第二个16ms处开始绘制工作呢？原因就是只有两个Buffer。如果有第三个Buffer的存在，CPU就能直接使用它， 而不至于空闲。出于这一思路就引出了Triple Buffer。结果如图所示：

由图可知： 第二个16ms时间段，CPU使用C Buffer绘图。虽然还是会多显示A帧一次，但后续显示就比较顺畅了。 是不是Buffer越多越好呢？回答是否定的。由图4可知，在第二个时间段内，CPU绘制的第C帧数据要到第四个16ms才能显示， 这比双Buffer情况多了16ms延迟。所以，Buffer最好还是两个，三个足矣。

以上对VSYNC进行了理论分析，其实也引出了Project Buffer的三个关键点： 核心关键：需要VSYNC定时中断。 Triple Buffer：当双Buffer不够使用时，该系统可分配第三块Buffer。 另外，还有一个非常隐秘的关键点：即将绘制工作都统一到VSYNC时间点上。这就是Choreographer的作用。在它的统一指挥下，应用的绘制工作都将变得井井有条。

今天的文章面试：Android的16ms、垂直同步、三重缓存分享到此就结束了，感谢您的阅读。