4、Choreographer机制：帧调度逻辑、Callback队列管理、掉帧检测原理与FrameCallback使用
聊到Android的UI渲染，绕不开一个核心角色——Choreographer。中文翻译过来叫“编舞者”，这个名字挺形象的。它就像个舞台导演，指挥着每一帧的绘制、输入处理、动画更新，让它们按节奏有序进行。
我记得刚接触Android性能优化那会儿，遇到界面卡顿，第一反应就是去查布局是不是太深、有没有过度绘制。后来才发现，很多时候问题出在帧调度层面。你布局再简单，如果Choreographer的节奏被打乱，该来的Vsync信号没被正确处理，画面照样掉帧。所以，理解Choreographer，是UI优化的基本功。
4.1 帧调度逻辑：Vsync信号与流水线
Choreographer的核心工作，就是响应Vsync（垂直同步）信号。硬件每16.6ms（60Hz刷新率下）发出一次Vsync，告诉系统：“该准备下一帧了！”
Choreographer收到信号后，会依次执行三个阶段的回调：
- INPUT：处理输入事件（触摸、按键等）
- ANIMATION：执行动画回调
- TRAVERSAL：执行测量、布局、绘制
这三个阶段是串行的，而且必须在一次Vsync周期内完成。如果任何一个阶段超时，就会导致掉帧。
关键点：Choreographer并不直接绘制，它只是“调度者”。真正的绘制工作由RenderThread和GPU完成。但调度一旦延迟，后续所有环节都会受影响。
我习惯把Choreographer的调度想象成一条流水线。Vsync信号就是流水线的节拍器。每个节拍到来，工人（回调）开始干活。如果某个工人动作慢了，下一个节拍来了他还没干完，那这一帧就错过了。说白了，掉帧就是流水线“堵车”了。
4.2 Callback队列管理：三种队列与优先级
Choreographer内部维护了三个Callback队列，分别对应上面提到的三个阶段。每个队列都是一个CallbackRecord链表，按添加顺序执行。
| 队列类型 | 常量值 | 执行时机 | 典型用途 |
|---|---|---|---|
| INPUT | 0 | Vsync后最先执行 | 触摸事件分发 |
| ANIMATION | 1 | 输入处理完成后 | 属性动画、ValueAnimator |
| TRAVERSAL | 2 | 动画更新完成后 | ViewRootImpl的performTraversals |
这里有个细节值得注意：同一队列内的回调是按FIFO顺序执行的。但不同队列之间有严格的优先级。INPUT必须最先处理，因为用户交互的响应延迟最敏感。ANIMATION次之，TRAVERSAL最后。
我曾经在项目中遇到过一个问题：某个自定义View在onDraw里做了大量计算，导致TRAVERSAL阶段耗时过长。结果就是触摸响应正常，动画也流畅，但画面就是卡顿。原因就是TRAVERSAL队列堵住了，绘制提交晚了。嗯，这就是典型的“调度延迟”问题。
4.3 掉帧检测原理：从源码层面看掉帧
掉帧检测，说白了就是看两帧之间的时间间隔是否超过了16.6ms。Choreographer内部通过FrameCallback或FrameMetrics来监控。
核心原理是这样的：
- Choreographer在每次Vsync到来时，记录当前时间
mLastFrameTimeNanos - 下一次Vsync到来时，计算时间差
- 如果时间差 > 16.6ms + 阈值（通常2ms），就判定为掉帧
源码里有个关键方法doFrame()，它长这样（简化版）：
void doFrame(long frameTimeNanos, int frame) {
final long startNanos = System.nanoTime();
// 计算与上次帧的时间差
long jitterNanos = startNanos - mLastFrameTimeNanos;
if (jitterNanos >= SKIPPED_FRAME_WARNING_LIMIT) {
// 掉帧了！记录日志或回调
Log.i(TAG, "Skipped " + (jitterNanos / REFRESH_PERIOD) + " frames!");
}
// 执行三个队列的回调
doCallbacks(Choreographer.CALLBACK_INPUT, frameTimeNanos);
doCallbacks(Choreographer.CALLBACK_ANIMATION, frameTimeNanos);
doCallbacks(Choreographer.CALLBACK_TRAVERSAL, frameTimeNanos);
mLastFrameTimeNanos = startNanos;
}注意看那个SKIPPED_FRAME_WARNING_LIMIT，默认是30ms。也就是说，如果两帧间隔超过30ms，就会打印“Skipped X frames!”的日志。这就是我们平时在Logcat里看到的掉帧警告的来源。
注意：掉帧检测的阈值不是固定的16.6ms。因为Vsync信号本身就有抖动，加上系统调度开销，所以源码里留了余量。但如果你看到“Skipped 2 frames”以上的日志，那基本可以确定有性能问题了。
4.4 FrameCallback使用：自定义掉帧监控
Choreographer提供了一个FrameCallback接口，允许我们注册一个回调，在每一帧被绘制时得到通知。它的用法很简单：
Choreographer.getInstance().postFrameCallback(new Choreographer.FrameCallback() {
@Override
public void doFrame(long frameTimeNanos) {
// 当前帧开始的时间（纳秒）
// 在这里可以计算帧间隔
if (mLastFrameTimeNanos != 0) {
long interval = frameTimeNanos - mLastFrameTimeNanos;
long fps = 1_000_000_000L / interval;
Log.d("FPS", "当前帧率: " + fps);
}
mLastFrameTimeNanos = frameTimeNanos;
// 注册下一帧回调，形成循环
Choreographer.getInstance().postFrameCallback(this);
}
});这个回调会在每一帧的TRAVERSAL阶段之后被调用。注意，它是在UI线程执行的，所以回调里不要做耗时操作，否则会影响下一帧。
我个人习惯用这个接口来做线上掉帧监控。比如在doFrame里统计帧间隔，如果连续3帧都超过16.6ms，就上报一个自定义事件。这样能精准定位到哪些页面、哪些操作容易掉帧。
小技巧：frameTimeNanos是Vsync信号的时间戳，不是当前实际时间。用它计算帧间隔更准确，因为它排除了回调执行本身的耗时。你想想看，如果用System.nanoTime()，那回调里的计算时间也会被算进去，就不准了。
4.5 知识体系总览
下面这张图总结了Choreographer的核心机制，我把它画成了流程图，方便你理解整体脉络：
从这张图可以看得很清楚：Vsync信号触发doFrame()，先做掉帧检测，然后依次执行三个队列。任何一个环节卡住，都会导致这一帧无法按时提交。说白了，掉帧就是流水线上某个工位“堵车”了。
嗯，关于Choreographer的核心机制，今天就聊到这儿。理解了这个调度模型，你再去分析卡顿问题，思路会清晰很多。下一节我们聊聊更具体的——如何用FrameMetrics做精细化掉帧统计。