应用输出与合成接缝：Surface 如何交给 SurfaceFlinger

上一章看了帧调度。这一章回答：应用帧最终怎么从 Surface 走到 SurfaceFlinger， 首帧显示与合成时序有什么关系？

Surface 是生产端，SurfaceFlinger 消费缓冲

常见误解	正确理解
Surface 是“一块画布”	Surface 是生产者侧对象，背后是 BufferQueue 缓冲流转
应用提交缓冲就上屏	缓冲要等 SurfaceFlinger 合成，按 VSync 上屏
SurfaceFlinger 只服务应用	状态栏、SystemUI、所有窗口都在合成范围

核心结论

1. 应用通过 Surface 提交帧，缓冲进入 BufferQueue。
2. SurfaceFlinger 作为消费者取缓冲并合成。
3. 首帧显示要过“缓冲提交 + 合成 + VSync 上屏”三关。
4. 生产者与消费者异步协作，缓冲队列防止互等。
5. 黑屏/首帧慢常与 Surface 创建、合成等待有关。

输出与合成主链

逐步解释：

1. 绘制完成：RenderThread 把帧写入缓冲。
2. 提交：Surface 把缓冲交给 BufferQueue。
3. 流转：队列管理缓冲生命周期（dequeue/queue/acquire）。
4. 合成：SurfaceFlinger 按窗口层级合成。
5. 上屏：按 VSync 显示。

首帧为什么可能慢

首帧要等：Surface 创建与窗口关联 → 第一帧缓冲提交 → 合成器认可 → VSync 上屏。 任一环节等待（如窗口未显示、缓冲未就绪）都会延迟首帧。这也是“白屏/黑屏”类问题的 常见排查点。

源码证据

阅读目标：确认 Surface 与 BufferQueue 的边界。

正文指针：Surface.java（生产者端）；SurfaceFlinger 的消费者逻辑； BufferQueueProducer.cpp 的队列实现。

// Surface.java（伪代码，行号以 r75 为准）
public class Surface implements Parcelable {
    // 持有 Native 生产者，提交缓冲
}

这段代码证明： Surface 是生产者入口；缓冲流转由 BufferQueue 管理，SurfaceFlinger 消费。两者通过队列解耦，不互相阻塞。

验证与排障

环境：开发设备或模拟器；以下命令不需要 root。

adb shell dumpsys SurfaceFlinger | grep -iE "Surface|Buffer"
adb shell dumpsys window | grep -iE "Surface|mSurface"
adb shell dumpsys gfxinfo <包名> | grep -iE "Janky|Total frames"

先确认窗口 Surface 是否存在（dumpsys window），再看合成器状态（SurfaceFlinger）， 最后用帧数据定位首帧/掉帧。黑屏问题先查 Surface 与合成时序，再查绘制。

常见误区

1. “Surface 是画布”：是生产者入口。
2. “提交就上屏”：还要合成与 VSync。
3. “SurfaceFlinger 只管应用”：所有窗口都过合成。
4. “缓冲越多越好”：队列策略按场景平衡。

延伸问题

1. BLASTBufferQueue 改变了什么？
2. 合成方式（GPU/客户端/硬件）如何选择？
3. 多窗口下缓冲如何共享与隔离？
4. 首帧显示与 REPORT_FIRST_FRAME 的关系是什么？

源码入口

文件	关键位置	作用
Surface.java	生产者对象	提交缓冲
BufferQueueProducer.cpp	队列	缓冲流转
SurfaceFlinger	消费者	合成
WindowManagerService.java	Surface 关联	窗口显示

公共路径：frameworks/base/core/java/android/view/、 frameworks/native/libs/gui/ 与 frameworks/native/services/surfaceflinger/。 行号以 r75 检索为准。

帧迟到时如何判断生产端或合成端，见 渲染卡顿。