Android三重缓冲-预期行为？

Question

我正在研究应用程序的性能，因为我注意到它在滚动时会掉落一些帧。我运行了systrace(在运行4.3的Nexus 4上)，并在输出中注意到了interesting section。

起初一切都很好。 Zooming in on the left section，我们可以看到绘图在每个vsync上开始，以剩余的时间结束，并等到下一个vsync为止。由于它是三重缓冲的，因此应将其绘制到一个缓冲区中，然后在完成后将其发布到以下vsync上。

在放大的屏幕快照中的第4个vsync上，该应用程序执行了一些工作，并且下一个vsync的绘制操作无法及时完成。但是，我们不会丢弃任何帧，因为先前的抽奖正在前面进行。

但是，在这种情况发生之后，绘制操作不会弥补丢失的vsync。相反，每个vsync仅启动一个绘制操作，现在它们不再向前绘制一帧。

Zooming in on the right section，应用程序完成了更多工作，并且错过了另一个vsync。由于我们没有在前面画一个框架，因此实际上在这里放置了一个框架。此后，它可以回到前面绘制一帧。

这是预期的行为吗？我的理解是，如果您错过了vsync，则三重缓冲可以使您恢复，但是这种行为看起来像是您错过的每两个vsync都会丢掉一帧。

跟进问题

在this screenshot的右侧，应用程序渲染缓冲区的速度实际上比显示器消耗缓冲区的速度快。假设在PerformTraversals＃1(在屏幕快照中标记)期间，正在显示缓冲区A，并且正在渲染缓冲区B。 ＃1在vsync之前完成很长时间，并将缓冲区B放入队列中。此时，应用程序是否应该能够立即开始渲染缓冲区C？相反，performTraversals＃2直到下一个vsync才开始，这浪费了之间的宝贵时间。

同样，对于waitForever on the left side here的需求我也有些困惑。假设正在显示缓冲区A，正在队列B中，正在渲染缓冲区C。缓冲区C完成渲染后，为什么不立即将其添加到队列中？相反，它会执行waitForever直到从队列中删除缓冲区B，然后才添加缓冲区C，这就是为什么无论应用程序渲染缓冲区的速度如何，队列似乎始终保持在大小1。

Answer 1

仅当您保持缓冲区已满时，才提供缓冲的数量。这意味着渲染速度快于显示器消耗它们的速度。

标签没有出现在图像中，但是我猜测绿色vsync行上方的紫色行是BufferQueue状态。您可以看到它通常随时都有0或1个完整的缓冲区。在“左侧放大”图像的最左侧，您可以看到它有两个缓冲区，但是之后只有一个，在屏幕的3/4处，您会看到一个很短的紫色条，表示它几乎没有及时渲染帧。

有关背景，请参见this post和this post。

更新以解决所添加的问题...

the other post中的细节几乎没有爬取表面。我们必须更深入。

systrace中显示的BufferQueue计数是排队的缓冲区的数量，即其中包含内容的缓冲区的数量。当SurfaceFlinger抓取要显示的缓冲区时，它将立即释放该缓冲区，并将其状态更改为“空闲”。当缓冲区显示在叠加层上时，这特别令人兴奋，因为显示是直接从缓冲区渲染的(与合成暂存缓冲区并显示相反)。

我再说一遍:显示器正在主动从中读取数据以在屏幕上显示的缓冲区在BufferQueue中被标记为“空闲”。缓冲区具有关联的围栅，该围栅最初是“Activity 的”。处于 Activity 状态时，不允许任何人修改缓冲区内容。当显示器不再需要缓冲区时，它将向篱笆发出信号。

因此，跟踪左侧的代码位于waitForever()中的原因是因为它正在等待栅栏发出信号。当VSYNC命中时，显示切换到另一个缓冲区，向围墙发出信号，您的应用程序可以立即开始使用该缓冲区。这样可以消除因必须等待SurfaceFlinger唤醒，不再使用缓冲区，通过BufferQueue发送IPC释放缓冲区等而导致的等待时间。

请注意，仅当您不落后时(对跟踪的左侧和右侧)，才会显示对waitForever()的调用。当队列只有1个完整的缓冲区时，我不确定为什么会发生这种情况-应该使最早的缓冲区出队，该缓冲区应该已经发出信号了。

最重要的是，您将永远不会看到BufferQueue在三重缓冲之上超过两个。

并非所有设备都如上所述工作。 Nexus 7(2012)并未使用“显式同步”机制，并且ICS之前的设备完全没有BufferQueues。

回到编号的屏幕截图，是的，在“1”和“2”之间有足够的时间可以让您的应用运行performTraversals()。很难肯定地说不知道您的应用程序在做什么，但是我想您已经有了一个由Choreographer驱动的动画周期，该周期会唤醒每个VSYNC并起作用。它没有比这更频繁地运行。

如果您使用systrace Android Breakout，则可以尽可能快地进行渲染(“队列填充”)，并依靠BufferQueue背压来调节游戏速度，从而看到它的外观。

比较运行4.3的N4和运行4.4的N4尤其有趣。在4.3上，跟踪与您相似，队列在1处徘徊，规则降为0，在2处偶尔出现尖峰。在4.4上，队列几乎总是在2处，偶尔下降到1。睡在eglSwapBuffers();在4.3中，跟踪通常显示在其下方的waitForever()，而在4.4中，其显示dequeueBuffer()。 (我不知道产生这种意外原因的原因。)

更新2: 4.3和4.4之间存在差异的原因似乎是Nexus 4驱动程序的更改。 4.3驱动程序使用了旧的dequeueBuffer调用，该调用变成了dequeueBuffer_DEPRECATED()(Surface.cpp line 112)。旧的接口(interface)不会将fence作为“输出”参数，因此调用必须调用waitForever()本身。较新的接口(interface)只是将篱笆返回给GL驱动程序，GL驱动程序会在需要时进行等待(可能不会立即执行)。

更新3: here现在可以使用甚至更长的解释。