Systrace/Perfetto trace 关键事件解读：Choreographer、Vsync、BufferQueue、SurfaceFlinger、GPU 工作阶段
在定位帧率回归时，抓取到 trace 只是第一步。真正决定排查效率的，是能否在 trace 中快速识别关键事件，并将它们串联成完整的“一帧生命周期”。本章将拆解从应用发起绘制到屏幕亮起的五大核心阶段，同时给出每个阶段的异常判定规则和排查表。
🔍 排查提醒： 版本更新后最常见的帧率回归 trace 信号是
SF 进程中的 onHandleMessage 耗时突增，或应用主线程 Choreographer#doFrame 出现连续红色（延迟）段。优先在这两个位置打标记，再向上下游扩散。
4.1 现象识别：帧率回归在 Trace 中的三大典型信号
在开始逐阶段解读前，先建立全局现象判断基准。出现以下任一信号即代表存在帧率回归风险：
| 现象 | Trace 内表现 | 严重等级 |
|---|---|---|
| 信号 1：连续的 Janky Frames | Choreographer#doFrame 出现连续多个红色高亮片段；SurfaceFlinger 进程的 onMessageInvalidate 流程间出现 > 16ms 的空闲等待。 |
高 |
| 信号 2：合成超时 | SurfaceFlinger 中 onFrameAvailable 到 onMessageRefresh 间隔 > 32ms；对应 GPU 完成 fence 信号晚于 Vsync。 |
高 |
| 信号 3：Buffer 堆积 | BufferQueue 的 dequeueBuffer 阻塞耗时 > 50ms；队列深度持续为 2 或 3。 |
中 |
4.2 数据采集：抓取含关键阶段的有效 Trace
为了让 trace 包含完整的工作阶段信息，采集命令必须启用对应 category。推荐使用 Android 10+ 的 Perfetto 模式抓取 8~10 秒的交互过程：
# 使用 Perfetto 抓取含 GPU 和 SurfaceFlinger 的能力
adb shell perfetto -c - -o /data/misc/perfetto-traces/frame_regression.pb \
--txt -e 10s
&
sleep 2 && adb shell input swipe 300 1000 300 400 500
# 注意：需在 perfetto 配置中启用 gpu、surfaceflinger、hal 等数据源若使用旧的 Systrace：
# 确保包含 -a 指定目标包名，并开启 -l 所有图层跟踪
python systrace.py -o trace.html sched freq idle am wm gfx view webview \
-a com.example.demapp -t 8
💡 最佳实践： 抓取时保持屏幕亮度固定、关闭后台省电模式、使用同一充电状态对比。版本更新前后的 trace 应用相同的 swipe/scroll 手势路径。
4.3 原因定位：逐阶段故障树排查与关键事件解读
下面通过故障树和事件解读表，串联起 Choreographer → Vsync → BufferQueue → SurfaceFlinger → GPU 的完整排查链路。每个阶段都附带判断规则。
4.3.1 帧率回归故障树
以下 SVFG 展示了回归根因的排查分支。从 Janky Frames 出发，依次判断是应用主线程堵塞、SF 合成排队还是 GPU 渲染超限。
4.3.2 关键事件解读与判断规则表
以下表格详细列出每个阶段在 systrace/perfetto 中的事件名、位置所在进程、正常耗时阈值以及异常判定规则。
| 阶段 | Trace 事件/切面 | 正常耗时 | 异常判断规则 |
|---|---|---|---|
| Choreographer | Choreographer#doFrame（应用主线程） |
< 12ms | > 14ms 连续 3 帧；或 doFrame 回调中出现 Binder 调用超过 5ms |
| Vsync 分发 | VsyncThread（SF 进程）DispSync (HW vsync) |
< 1ms 偏移 | Vsync 周期波动 > 0.5ms；或 SF 的 onVsync 回调被调度延迟 |
| BufferQueue | dequeueBuffer / queueBuffer（应用进程）BufferQueueProducer |
< 2ms | 单次 dequeue > 10ms，或 queueBuffer 后等待 acquire fence 超过 8ms |
| SurfaceFlinger | onMessageInvalidateonMessageRefresh |
< 12ms 完成一次合成 | onMessageRefresh 总耗时 > 16ms；或 doComposition 阶段出现多次 unlock 重试 |
| GPU | renderframe / queueBuffer (egl fence)Perfetto 中 gpu_render_stage |
< 8ms | GPU 完整执行阶段（submit → end）超 16ms；或 fence 信号晚于下一帧 Vsync 到达 |
4.4 修复动作
依据上级故障树排查结果，采取对应的修复策略：
- Choreographer 延迟（主线程阻塞） → 检查版本更新后是否新增了
Handler.post长任务或相对耗时的 ContentProvider/Service 启动；将非 UI 强相关操作迁移至子线程或 IdleHandler。 - BufferQueue 阻塞 → 回退
BufferQueue的maxDequeuedBufferCount配置（AOSP 更新常增加此值）；确认是否开启了SurfaceControl.Transaction的批量提交以避免频繁 dequeue。 - SurfaceFlinger 合成超时 → 对比新旧版本
surfaceflinger.rc的 cgroup 权重；将 SF 进程移入top-app并确认 GPU comp 方式为device（通过dumpsys SurfaceFlinger检查）。 - GPU fence 超时 → 检视驱动更新引入的 shader 回退路径（如从 HWC2 回退到 GLES comp）；通过
adb shell dumpsys gfxinfo对比 renderstage 耗时。
4.5 复测
修复后使用完全相同的手势脚本抓取 trace，重点验证以下指标是否回退到正常区间：
# 快速验证命令集
1. adb shell dumpsys gfxinfo com.example.demapp | grep "Flags\|Janky frames"
2. 检查 perftrace 中 Choreographer doFrame 连续三帧是否均小于 12ms
3. 查看 SurfaceFlinger onMessageRefresh 耗时是否降到 12ms 以下
4. 确认 GPU render stage 最大时长 < 12ms若修复后持续观察 120 帧，Janky 帧比例低于 1% 视为通过。
4.6 预防
为了确保版本更新后不再产生类似的帧率回归，需将以下 check 加入持续集成：
- Perfetto 性能门禁：在 CI 中配置固定时长的 Frame Benchmark，如果
maxFrameMissedCount > 5则阻断合入。 - SurfaceFlinger cgroup 审查：每次 AOSP 同步后检查
surfaceflinger.rc中的cpuset/cpuctl配置是否改变。 - GPU Renderstage 快照：记录每个 release 版本中 app 侧的 renderstage 平均耗时，出现 > 2ms 的涨幅立即告警。
- BufferQueue 压力测试：在预提交时运行
dEQP-EGL.functional.buffer_age*测试，确保 dequeue 延迟不翻倍。
📘 本章排查口诀： 应用看
doFrame，SF 看 Refresh；队列看 dequeue，GPU 看 fence。始终以 Choreographer → SF → GPU 的顺序扫描 trace，避免在下游阶段浪费排查时间。