JellyBean的VSync与三级buffer的入门介绍（外文翻译）

最近在研究JellyBean在Graphics上面的新改动，最吸引人的在图像的平滑上大作文章，读了一篇关于VSync和三级缓冲的外国文章，很有收获，特别翻译成中文，与大家分享。

原文地址：http://www.androidpolice.com/2012/07/12/getting-to-know-android-4-1-part-3-project-butter-how-it-works-and-what-it-added/

今天我们来探讨一些不同的，来研究一些对于所有人都很实用的一个话题：性能。大家可以看到JellyBean非常的快，在GalaxyNexus测试它可以感到它变成了一台全新的手机。滚动变得非常平滑和更快了，而且相应点击也变得高度敏感。另外，这些平滑的表现体现在了各个方面。

           我不清楚你们是否都已经看到了这些改变，不过这些都很无趣呀，真正有趣的东西是——他们怎么做到这些的？这就是我们这里要探究的。因此，抓起你的爆米花，孩子；是时候开始学习“黄油计划”（ProjectButter）了。

他们是怎么做的

那么你们是怎么让一个八个月大的GalaxyNexus跑起来像是Galaxy SIII一样？答案是，许许多多努力的结果。在GoogleI/O大会上我们已经看到了，由我最喜欢两个I/O演讲者，ChetHaase和Romain Guy。一个小时长的PPT展示对于开发者似乎长了一点，所以让我从中挑选一些有意思的事。

VSync使得帧数被放入了一个充满润滑油的机器里

PC游戏者们可能对于“VSync”这个词比较熟悉，它是一个图像选项可以防止你的屏幕发生图像不同步（imagetearing）的情况。为了了解什么事VSync，我们来补充一点背景知识：影像（比如手机显示的那样）是通过一张一张的图，叫做帧，构成的。平滑的动画通常是一秒60帧。帧是由像素构成，而且，当显示的时候，像素是一行一行的打上去的。明白了么？很好。

显示器（LED,AMOLED,或其他）从图形芯片上面获得每一帧，然后开始一行一行的绘制。理想情况下，你希望在下一帧还未出现时就已经被绘制好了，不同步或者叫图像撕裂（tearing）的情况出现在当芯片还未完全生成新的一帧，LCD已经开始显示了，这样你就会看到一半新的一半老的帧。

  VSync，同步了这样一个过程，它告诉GPU去等屏幕显示完上一帧再去加载下一帧。

Android一直都是用的VSync来防止屏幕发生不同步，但是JellyBean把这件事做的更好。现在VSync被用在了所有的进程上用来显示下一帧。

            大多数android显示是保持在每秒60帧的水平，即60Hz。为了有一个平滑的动画效果，为了能够保持这种60Hz的状态不变，这意味着你只有16ms的时间来处理每一帧。如果你超过16ms，动画会发生迟滞，那种犹如黄油般的感觉就会荡然无存。

            16毫秒的时间不算太长，所以你要充分的利用它。在IceCreamSandwich中，对下一帧的展现可以说算得上是一种“懒加载”的形式，在JellyBean里，在VSync脉冲开始时，所有的进程会尽可能快的在上一帧完成时显示下一帧。换句话说，他们是尽可能的充分利用那16ms。如下是一个例子

             这就是没有加入VSync的情况。在这张图里，数字代表的是帧，帧是由CPU和GPU处理的，当它被处理完之后会被放在下一个VSync脉冲周期里去显示。所以在这张图片里，0号帧被显示了，在16ms的显示时间内，CPU和GPU准备好了下一帧，计算如期完成，在下一个VSync脉冲周期里，1号帧很好的显示出来了，很好！

             现在我们正在显示1号帧，开始处理2号帧，有一些东西降低了系统的性能，2号帧在这个脉冲周期结束临近时还没有处理完成。这时候只有4ms来处理2号帧，所以它没有被及时处理完，没有2号帧，显示只能继续显示1号帧，并且又是一个16ms。Android团队称之为为“Jank”，他的大意是动画在这个时间点上变得不流畅，用户会有迟滞的感觉。

             这里是JellyBean如何做的，所有帧的处理都被放在了每一个VSync脉冲周期的最开始，这样一来，所有的16ms都被充分的利用了。帧的处理从最开始的“好吧，被我碰到了我就来处理”的模式到现在的刚性时间规划，高度的有组织。在这个例子里，你会获得一个黄油一般平滑的体验。

三级缓冲让Jank的几率更加低

             VSync不是唯一提高动画平滑度的事情，Android还能提供一种从性能下降之后恢复平滑的办法。

             那么到底什么又是“buffer”？简单来说，buffer就是帧在被创建和储存的一个容器。在前面，我们将帧标上了编号，但事实上，这些帧都是放置在两个buffer中的。Android是一个双缓冲的，很典型的架构，这意味着它可以显示着一个并且处理着另外一个。在图中我们可以看到buffer被标上了“A”和“B”。当显示着A的时候，B正在被处理中。当A显示完成，B也准备完成之后，他们交换角色，B被显示，A被清理然后开始处理新的一帧。

             当某一帧的处理时间超过16ms时，双buffer的问题就暴露了出来。在图里我们看到当bufferB的处理时间超过了16ms，就意味着迟滞（Jank）要发生了。迟滞是一件坏事，但是更要命的是，图中的CPU和GPU的空白部分都是浪费掉的时间片。在显示第一帧时，bufferB时间超了，因此bufferB会被占用着直到它被显示，bufferA也被占用着，因为他要继续显示直到B可以显示为止。而且要记住一点，buffer的切换只能发生在VSync脉冲周期开始的时候，CPU和GPU没有了可以使用的buffer，因此他们只能等在哪里。一次的减速会带来后续的速度降低，这就是4.0如何工作的。

              在JellyBean中，我们有了关于这种问题的解决办法，第三个buffer！一样的情况像刚才一样，bufferB使用了很长的时间，A被用作显示在这时候，与其让CPU,GPU等在哪里，系统创建了bufferC，来处理下一帧。三级缓冲停止了这种迟滞的蔓延。当跳过了一个初始的迟钝之后，用户在后面看到将是一个平滑的动画，这都是因为提供给显示一个临时的跳板，这样即使在程序下面并不是运行的那么顺利，用户所看到的依然很流畅。

              所以为什么他们不是一直使用三级缓冲的技术呢？那么，我们再从图中看一下，三级缓冲引入了一些点击、输入的延时，当bufferC开始运行到显示的这段时间，你可能会受到两种感受，一种是输入的延时，另一种是起伏的动画（这里作者用的是choppy animation，不知道该怎么理解）。

              鉴于此，JellyBean并没有任何时候都使用三级缓冲，它通常是使用双buffer，但是三级缓冲会在你需要的时候出现。这样做也是为了减少输入的延时，当有问题出现的时候，三级缓冲才会跳出来帮助你恢复画面迟滞的现象。