surfaceflinger-bufferqueue

1. 实验目标

用 dumpsys SurfaceFlinger 与 dumpsys gfxinfo 观察 Android 图形合成链路（对应 docs/02-memory-lifecycle/11）：

• 确认 App 的 Surface 背后是 BufferQueue（生产者-消费者模型）
• 观察 triple buffering 下缓冲区的占用状态（3 个 slot 如何轮换）
• 区分 GPU 合成（client composition） 与 Overlay（硬件合成 / HWC） ，理解掉帧发生在哪一环

本实验为「观测型」实验，依赖 adb + 真机/模拟器；暂不接入 Android Host 的 Activity 构建。

2. 工程要点

• 每个 Window/Surface 对应一个 BufferQueue：app 是生产者，SurfaceFlinger 是消费者
• 双缓冲 → 易在「生产者赶不上消费者」时丢帧；三缓冲多一个 slot 作为缓冲，降低掉帧但增加延迟
• dumpsys SurfaceFlinger --list 列出所有 layer；dumpsys SurfaceFlinger 的 BufferQueue 段显示每个 layer 的 mQueue 状态

3. 运行方式

# 列出当前所有 surface layer
adb shell dumpsys SurfaceFlinger --list

# 观察某个 App 的 BufferQueue 状态（找包名对应的 layer）
adb shell dumpsys SurfaceFlinger | grep -A 40 "BufferQueue"

# 帧耗时 / 合成类型（GPU vs HWC）
adb shell dumpsys gfxinfo <pkg> framestats

4. 预期现象

• dumpsys SurfaceFlinger 中每个 layer 出现 BufferQueue 条目，含 mSlots（通常 3 个）、queue / acquire / released 计数
• 滚动复杂页面时，若合成类型大量为 GPU 而非 HWC，更易掉帧
• 开启 Developer Options 的「显示刷新频率 / 显示 GPU 视图更新」可肉眼交叉验证

5. 常见误区

误区	实际情况
掉帧一定是 App 主线程卡	也可能在 SurfaceFlinger 合成或 BufferQueue 等待（生产者/消费者不同步）
双缓冲够用	高刷新率 / 重合成场景下三缓冲才稳，代价是输入延迟略增
dumpsys 数据能直接当 FPS	它是瞬时快照，需多次采样或配合 gfxinfo framestats 统计

6. 对应知识库文档

• 理论主文档：SurfaceFlinger、BufferQueue 与三重缓冲：帧如何合成上屏
• 相邻专题：Android View 绘制流程、Choreographer 与 VSync 帧同步

7. 关键源码

• 本实验为 adb 观测型，无需 App 源码（dumpsys SurfaceFlinger 需 shell 权限，App 内会被 SELinux 拒绝，只能在 PC 端 adb shell 执行）。
• 本目录附带一键脚本 dump_surfaceflinger.sh，封装了上面的 adb 观测命令。

接入状态

📋 文档化（adb 观测型，非 App 运行时） ：dumpsys SurfaceFlinger 需 shell 权限，App 内会被 SELinux 拒绝，只能在 PC 端 adb shell 执行。本目录附带 dump_surfaceflinger.sh 一键脚本。