安卓T及U版本BBQ动态分析：DRAW_PENDING与同步机制

"draw-pending" 在Android系统中，"draw-pending"状态通常涉及到UI渲染过程中的一个阶段，尤其是在SurfaceFlinger服务的角色下。SurfaceFlinger是Android系统中负责合成窗口和图形元素，并将它们显示到屏幕上的关键组件。本文将深入探讨Android T、S和U版本中与"draw-pending"状态相关的改变，以及这些改变如何影响UI线程和RenderThread之间的交互。 1. Android T的改动 在Android T版本中，UI线程与RenderThread的交互方式发生了变化。传统的FrameCompleteCallback和TransactionComplete机制被弃用，取而代之的是通过syncNextTransaction()方法，该方法现在接收一个callback参数。这个调整的触发时机是在onFrameAvailable()回调中，意味着当一个新的帧准备好时，会立即进行同步操作。这种改变减少了不必要的等待时间，提高了UI更新的效率。 2. BBQ（BufferQueue）同步处理 在Android S版本中，BBQ（BufferQueue）的交互模式涉及到一个名为DRAW_PENDING的问题。DRAW_PENDING状态表示一个帧正在被绘制但还未完成。在这个版本中，BBQ的同步机制进行了优化，使得ViewRootImpl不再需要阻塞等待，从而降低了应用的响应延迟。 3. Android U的BBQ变化 在Android U版本中，BLASTBufferQueue.cpp引入了mSyncedFrameNumbers，用于标记同步的帧。这个改动可能旨在进一步优化帧同步的过程，确保在适当的时间点进行帧的交换和显示，以减少画面撕裂或延迟现象。 4. BBQ的Queue队列位置讨论 有观点提出是否可以将BBQ的队列移出App进程，仍在原来的SurfaceFlinger中维护。然而，由于交互时间点的不同，这种做法不可行。在旧机制下，交互发生在queueBuffer()成功时；而在新机制下，交互发生在acquireBuffer()成功时。这两者对同步的要求和时机不同，因此保持BBQ队列在SurfaceFlinger中是必要的。 5. FrameCompleteCallback的变更及其影响 在Android的某个版本中，FrameCompleteCallback不再报告"actually drawn."的情况，这意味着如果一个帧没有实际被绘制，将不会触发TransactionComplete回调。这可能导致VRI（Virtual Reality Interface）无法执行clearBlastSync()，进而影响到帧的正确显示。然而，据实测，这个问题已经被修复。现在，VRI在FrameComplete时会检查BBQ的frameNr和AttemptedDrawFrameNum，如果不一致则调用clearBlastSync()。 6. 分屏场景与UseBlastSync 在分屏模式下，UseBlastSync机制会被启用，确保多窗口环境下每个窗口的正确同步。而对于首次启动的应用，如果没有调用reportDrawFinished()，其layer可能不会处于show()状态，导致显示问题。 总结： "draw-pending"状态是Android系统UI渲染流程中的一个关键环节，随着系统版本的迭代，其处理方式不断优化以提高性能和用户体验。从Android T到Android U，我们可以看到在BBQ同步、回调机制以及分屏场景下的处理都有所改进，这些改动旨在减少延迟，提升系统响应速度，并确保图形渲染的准确性和一致性。