前言
上一篇我们讲了 Choreographer 决定了“什么时候画”。今天我们聊聊“画在哪”以及“画完怎么传”。
当 Compose 的绘图指令执行完毕，像素已经生成。但这些数据在应用进程里，显示器在物理硬件里，中间隔着操作系统的千山万水。这场像素的跨进程接力，由 BufferQueue 和 SurfaceFlinger 完成。
一、 接力棒：GraphicBuffer (图形缓冲区)
想象你有一张白纸。在 Android 中，这张纸叫 GraphicBuffer。
- 双缓冲机制：App 手里拿一张（Back Buffer），屏幕正在显示一张（Front Buffer）。这样可以保证 App 涂抹的时候，用户看不到中间过程。
二、 核心队列：BufferQueue
这是生产者（App）与消费者（SurfaceFlinger）之间的传送带。
- Dequeue (出队)：App 向
BufferQueue要一张空白的 GraphicBuffer。 - Draw (绘制)：Compose 通过 Skia 在这张 Buffer 上“挥毫泼墨”。
- Queue (入队)：画好了，App 把 Buffer 塞回队列，并通知系统。
- Acquire (获取)：系统的渲染进程 SurfaceFlinger 拿到这张画好的图。
三、 总指挥：SurfaceFlinger
SurfaceFlinger 是 Android 系统的首席化妆师。
在一个屏幕上，可能同时有：
- 状态栏（SystemUI）
- 导航栏
- 你的 App 窗口
SurfaceFlinger 负责把这些来自不同进程的 Buffer 合成（Composition） 在一起。
- 它利用 HWC (Hardware Composer) 硬件，直接在显卡层面完成叠加，从而释放 CPU。
四、 跨全栈的深度思考
当你开发 KMP 项目时，理解这一层有何意义？
- 渲染延迟（Latency）：如果 BufferQueue 积压了，用户就会感觉到明显的“不跟手”。
- 显存压力：每一张 GraphicBuffer 都是真金白银的显存（通常是几 MB）。如果你的 App 开启了过多的浮窗或复杂的 Surface 叠加，会导致显存波动。
- Vulkan/Metal 差异：在 KMP 跨端渲染中，不同的图形后端对 Buffer 的申请和交换策略（Swap Chain）是不同的。这也是为什么同样的逻辑在不同端可能有微小的渲染时差。
五、 源码探秘路径
android.gui.BufferQueue：查看 Buffer 的流转状态机（FREE -> DEQUEUED -> QUEUED -> ACQUIRED）。/system/core/include/ui/GraphicBuffer.h：了解内存布局。
结语
像素不是瞬间变出来的，它是在一个个缓冲区中不断流转、合成的产物。理解了 BufferQueue，你就掌握了 Android 渲染的物理底座。
下一篇，我们将直面图形学的终极挑战 —— 硬件加速与 HWC：谁在决定屏幕上的最终成象？
