Choreographer工作原理：UI渲染管线、Vsync信号、FrameCallback与FrameCompleteCallback、回调队列机制
排查核心认知：Choreographer是Android UI渲染的“心脏起搏器”，它依靠Vsync信号协调每一帧的输入、动画、布局、绘制和提交。帧回调延迟的直接表现就是掉帧、卡顿或帧率抖动。本章从现象到原理，建立排查上下文。
现象识别：如何“听出”Choreographer在掉拍？
- 视觉卡顿：滑动列表时出现明显停顿、动画跳跃、帧率从60fps突然跌至30fps以下。
- 帧时间不均衡：使用
adb shell dumpsys gfxinfo看到Draw/Prepare/Process阶段某一帧超过16ms。 - Systrace信号异常：Choreographer#doFrame 段出现连续拖延或首帧滞后。
- FrameCallback回传时间戳差异大：注册FrameCallback后，回调传入的
frameTimeNanos与实际执行时间差>2ms。
排查陷阱：不要只关注主线程Looper消息执行时间，Choreographer的“帧回调队列”本身也可能因队列堆积导致延迟，即使单个回调很快，队列排队也会造成整体延迟。
数据采集：用哪些“听诊器”？
- Systrace（Perfetto）：开启
sched freq idle+gfx+view标签，重点关注Choreographer#doFrame起止点之间的系统调用。 - FrameCallback日志埋点：在
Choreographer.FrameCallback.doFrame(long frameTimeNanos)中记录System.nanoTime() - frameTimeNanos。 - FrameCompleteCallback（API 32+）：利用
Choreographer.postFrameCallback和FrameCompleteCallback观察帧完成时间。 - gfxinfo输出：
分析每帧的adb shell dumpsys gfxinfo <package> framestatsINTENDED_VSYNC到FRAME_COMPLETED的耗时。
关键指标：如果每一帧的
frameTimeNanos与实际回调时间之差大于4ms，说明回调队列已经积压或Vsync信号本身被延迟。
原因定位：故障树与排查表
Choreographer帧回调延迟的原因可以归纳为以下三个层级，使用故障树从顶层现象倒查根源：
故障树结构：
帧回调延迟 → Vsync信号下发延迟 / 主线程消息队列阻塞 / 回调队列内部排队超时
└─ Vsync信号延迟 → 后台进程抢占了drm_vblank_work / 屏幕刷新率切换抖动
└─ 主线程阻塞 → LongTask（GC、Binder、Layout）占据消息循环
└─ 回调队列堆积 → 单个FrameCallback耗时>2ms / 过多FrameCallback同时注册
帧回调延迟 → Vsync信号下发延迟 / 主线程消息队列阻塞 / 回调队列内部排队超时
└─ Vsync信号延迟 → 后台进程抢占了drm_vblank_work / 屏幕刷新率切换抖动
└─ 主线程阻塞 → LongTask（GC、Binder、Layout）占据消息循环
└─ 回调队列堆积 → 单个FrameCallback耗时>2ms / 过多FrameCallback同时注册
| 排查维度 | 指标阈值 | 判断规则 |
|---|---|---|
| Vsync信号延迟 | frameTimeNanos与实际时间差 > 2ms | 输出Systrace查看vsync_drm_work调度延迟 |
| 主线程消息队列 | doFrame之前Looper message处理时间 > 10ms | 检查doFrame前相邻消息的wall duration |
| FrameCallback排队 | 同一个doFrame周期内回拨数量 > 5个 | 统计Choreographer内部mCallbackQueues的size |
| FrameCompleteCallback超时 | 从doFrame开始到回调执行 > 2个vsync周期 | 使用FrameCompleteCallback记录时间戳差 |
修复动作：针对性打击
- Vsync信号延迟：降低屏幕刷新率至固定60Hz；关闭frame rate switching；使用
Surface.setFrameRate锁定。 - 主线程阻塞：将非UI操作移到子线程；使用
StrictMode检测磁盘IO、网络调用；减少onMeasure的递归深度。 - 回调队列堆积：合并多个FrameCallback为一个；避免在回调中注册新的回调；使用
postFrameCallback代替postFrameCallbackDelayed减少定时队列。 - FrameCompleteCallback延迟：确保UI线程空闲，不要在同一帧内执行异步提交逻辑。
快速修复示例：将自定义帧动画从独立的Choreographer回调改为使用
View.postOnAnimation()，该API内部使用统一的Choreographer并自动分离优先级。
复测：验证修复是否有效
- 使用
gfxinfo framestats采集修复后200帧，计算INTENDED_VSYNC到FRAME_COMPLETED的P95和P99。 - 运行自动化滑动测试，观察Systrace中Choreographer#doFrame段是否连续<16ms。
- 注册测试用FrameCallback，输出
System.nanoTime() - frameTimeNanos，确保方差<1ms。 - 在覆盖1%低电量、后台进程满载的极端场景下复现，确认延迟不再出现。
预防：构建健壮的渲染链路
- 注册上限：单个Activity中FrameCallback数量不超过3个，且总执行时间<1ms。
- 异步化：通过
Choreographer.postFrameCallback的frameTimeNanos做时间对齐，避免在回调中做耗时计算。 - 监控：在生产环境集成
FrameMetricsAggregator或jank_stats，当dropped frames>5%时主动上报。 - 设计原则：仅将UI动画或明确依赖下一个VSync的任务放到Choreographer回调中，其他定时任务使用Handler或AlarmManager。
排查捷径：在Systrace中同时标记Choreographer#doFrame和用户注册的FrameCallback，观察两者之间的间隔。若间隔大于1个vsync（约16.6ms@60Hz），则回调队列必存在阻塞。