介绍完 Choreographer 是如何初始化的，再回到 Choreographer 发送任务那块。

mChoreographer.postCallback(                Choreographer.CALLBACK_TRAVERSAL, mTraversalRunnable, null);

我们看看 mTraversalRunnable 是什么东西。

> ViewRootImpl.javafinal TraversalRunnable mTraversalRunnable = new TraversalRunnable();    final class TraversalRunnable implements Runnable {    @Override    public void run() {        doTraversal();    }}

没什么特别的，它就是一个 Runnable 对象，run() 方法中会执行 doTraversal() 方法。

> ViewRootImpl.javavoid doTraversal() {    if (mTraversalScheduled) {        // 1. mTraversalScheduled 置为 false        mTraversalScheduled = false; // 2. 移除同步屏障        mHandler.getLooper().getQueue().removeSyncBarrier(mTraversalBarrier); // 3. 开始布局，测量，绘制流程        performTraversals();        ......    }

再对比一下最开始发起绘制的 scheduleTraversals() 方法：

> ViewRootImpl.javavoid scheduleTraversals() {    // 1. mTraversalScheduled 置为 true，防止重复调用    if (!mTraversalScheduled) {        mTraversalScheduled = true; // 2. 发送同步屏障，保证优先处理异步消息        mTraversalBarrier = mHandler.getLooper().getQueue().postSyncBarrier(); // 3. 最终会执行 mTraversalRunnable 这个任务        mChoreographer.postCallback(                Choreographer.CALLBACK_TRAVERSAL, mTraversalRunnable, null);        ......    }}

仔细分别看一下上面两个方法的注释 1、2、 3，还是很清晰的。mTraversalRunnable被执行后最终会调用 performTraversals() 方法，来完成整个 View 的测量，布局和绘制流程。

分析到这里，就差最后一步了，mTraversalRunnable 是如何被调度执行的？ 我们再回到 Choreographer.postCallback() 方法。

> Choreographer.javapublic void postCallback(int callbackType, Runnable action, Object token) {    postCallbackDelayed(callbackType, action, token, 0);}public void postCallbackDelayed(int callbackType,        Runnable action, Object token, long delayMillis) {    ......    postCallbackDelayedInternal(callbackType, action, token, delayMillis);}// 传入的参数依次是 Choreographer.CALLBACK_TRAVERSAL, mTraversalRunnable, null，0private void postCallbackDelayedInternal(int callbackType,        Object action, Object token, long delayMillis) {    ......    synchronized (mLock) {        final long now = SystemClock.uptimeMillis();        final long dueTime = now + delayMillis;        // 1. 将 mTraversalRunnable 塞入队列        mCallbackQueues.addCallbackLocked(dueTime, action, token);        if (dueTime <= now) { // 立即执行            // 2. 由于 delayMillis 是 0，所以会执行到这里            scheduleFrameLocked(now);        } else { // 延迟执行            Message msg = mHandler.obtainMessage(MSG_DO_SCHEDULE_CALLBACK, action);            msg.arg1 = callbackType;            msg.setAsynchronous(true);            mHandler.sendMessageAtTime(msg, dueTime);        }    }}

首先根据 callbackType(这里是 CALLBACK_TRAVERSAL) 将稍后要执行的 mTraversalRunnable 放入相应队列中，其中的具体逻辑就不看了。

然后由于 delayMillis 是 0，所以 dueTime 和 now 是相等的，所以直接执行 scheduleFrameLocked(now) 方法。如果 delayMillis 不为 0 的话，会通过 FrameHandler 发送一个延时消息，最后执行的仍然是 scheduleFrameLocked(now) 方法。

> Choreographer.javaprivate void scheduleFrameLocked(long now) {    if (!mFrameScheduled) {        mFrameScheduled = true;        if (USE_VSYNC) { // Android 4.1 之后 USE_VSYNCUSE_VSYNC 默认为 true                           // 如果是当前线程，直接申请 vsync，否则通过 handler 通信            if (isRunningOnLooperThreadLocked()) {                scheduleVsyncLocked();            } else {                // 发送异步消息                Message msg = mHandler.obtainMessage(MSG_DO_SCHEDULE_VSYNC);                msg.setAsynchronous(true);                mHandler.sendMessageAtFrontOfQueue(msg);            }        } else { // 未开启 vsync，4.1 之后默认开启            final long nextFrameTime = Math.max(                    mLastFrameTimeNanos / TimeUtils.NANOS_PER_MS + sFrameDelay, now);            Message msg = mHandler.obtainMessage(MSG_DO_FRAME);            msg.setAsynchronous(true);            mHandler.sendMessageAtTime(msg, nextFrameTime);        }    }}

开头到现在，已经好几次提到了 VSYNC，官方也有一个视频介绍 Android Performance Patterns: Understanding VSYNC<14> ，大家可以看一看。简而言之，VSYNC 是为了解决屏幕刷新率和 GPU 帧率不一致导致的 “屏幕撕裂” 问题。VSYNC 在 PC 端是很久以来就存在的技术，但在 4.1 之后，Google 才将其引入到 Android 显示系统中，以解决饱受诟病的 UI 显示不流畅问题。

再说的简单点，可以把 VSYNC 看成一个由硬件发出的定时信号，通过 Choreographer 监听这个信号。每当信号来临时，统一开始绘制工作。这就是 scheduleVsyncLocked() 方法的工作内容。

> Choreographer.javaprivate void scheduleVsyncLocked() {    mDisplayEventReceiver.scheduleVsync();}

mDisplayEventReceiver 是 FrameDisplayEventReceiver 对象，但它并没有 scheduleVsync() 方法，而是直接调用的父类方法。FrameDisplayEventReceiver 的父类是 DisplayEventReceiver 。

> DisplayEventReceiver.javapublic abstract class DisplayEventReceiver {    public void scheduleVsync() {        if (mReceiverPtr == 0) {            Log.w(TAG, "Attempted to schedule a vertical sync pulse but the display event "                    + "receiver has already been disposed.");        } else {         // 注册监听 vsync 信号，会回调 dispatchVsync() 方法            nativeScheduleVsync(mReceiverPtr);        }    }    // 有 vsync 信号时，由 native 调用此方法    private void dispatchVsync(long timestampNanos, int builtInDisplayId, int frame) {        // timestampNanos 是 vsync 回调的时间        onVsync(timestampNanos, builtInDisplayId, frame);    }    public void onVsync(long timestampNanos, int builtInDisplayId, int frame) {    }}

在 scheduleVsync() 方法中会通过 nativeScheduleVsync() 方法注册下一次 vsync 信号的监听，从方法名也能看出来，下面会进入 native 调用，水平有限，就不追进去了。

注册监听之后，当下次 vsync 信号来临时，会通过 jni 回调 java 层的dispatchVsync() 方法，其中又调用了 onVsync() 方法。父类 DisplayEventReceiver的 onVsync() 方法是个空实现，我们再回到子类 FrameDisplayEventReceiver ，它是 Choreographer 的内部类。

> Choreographer.javaprivate final class FrameDisplayEventReceiver extends DisplayEventReceiver        implements Runnable {    private long mTimestampNanos;    private int mFrame;    // vsync 信号监听回调    @Override    public void onVsync(long timestampNanos, int builtInDisplayId, int frame) {        ......        long now = System.nanoTime();        // // timestampNanos 是 vsync 回调的时间，不能比 now 大        if (timestampNanos > now) {            Log.w(TAG, "Frame time is " + ((timestampNanos - now) * 0.000001f)                    + " ms in the future!  Check that graphics HAL is generating vsync "                    + "timestamps using the correct timebase.");            timestampNanos = now;        }        ......        mTimestampNanos = timestampNanos;        mFrame = frame;        // 这里传入的是 this，会回调本身的 run() 方法        Message msg = Message.obtain(mHandler, this);        // 这是一个异步消息，保证优先执行        msg.setAsynchronous(true);        mHandler.sendMessageAtTime(msg, timestampNanos / TimeUtils.NANOS_PER_MS);    }    @Override    public void run() {        doFrame(mTimestampNanos, mFrame);    }}

在 onVsync() 回调中，向主线程发送了一个异步消息，注意 sendMessageAtTime() 方法参数中的时间是 timestampNanos / TimeUtils。timestampNanos 是 vsync 信号的时间戳，单位是纳秒，所以这里做一个除法转换为毫秒。代码执行到这里的时候 vsync 信号已经发生，所以 timestampNanos 是比当前时间小的。这样这个消息塞进 MessageQueue 的时候就可以直接塞到前面了。另外 callback 是 this，所以当消息被执行时，调用的是自己的 run() 方法，run() 方法中调用的是 doFrame() 方法。

> Choreographer.javavoid doFrame(long frameTimeNanos, int frame) {    final long startNanos;    synchronized (mLock) {        if (!mFrameScheduled) {            return; // no work to do        }        ......        long intendedFrameTimeNanos = frameTimeNanos;        startNanos = System.nanoTime();  // 计算超时时间  // frameTimeNanos 是 vsync 信号回调的时间，startNanos 是当前时间戳  // 相减得到主线程的耗时时间        final long jitterNanos = startNanos - frameTimeNanos;  // mFrameIntervalNanos 是一帧的时间  if (jitterNanos >= mFrameIntervalNanos) {            final long skippedFrames = jitterNanos / mFrameIntervalNanos;   // 掉帧超过 30 帧，打印 log            if (skippedFrames >= SKIPPED_FRAME_WARNING_LIMIT) {                Log.i(TAG, "Skipped " + skippedFrames + " frames!  "                        + "The application may be doing too much work on its main thread.");            }            final long lastFrameOffset = jitterNanos % mFrameIntervalNanos;            frameTimeNanos = startNanos - lastFrameOffset;        }        ......    }    try {        AnimationUtils.lockAnimationClock(frameTimeNanos / TimeUtils.NANOS_PER_MS);  // doCallBacks() 开始执行回调        mFrameInfo.markInputHandlingStart();        doCallbacks(Choreographer.CALLBACK_INPUT, frameTimeNanos);        mFrameInfo.markAnimationsStart();        doCallbacks(Choreographer.CALLBACK_ANIMATION, frameTimeNanos);        mFrameInfo.markPerformTraversalsStart();        doCallbacks(Choreographer.CALLBACK_TRAVERSAL, frameTimeNanos);        doCallbacks(Choreographer.CALLBACK_COMMIT, frameTimeNanos);    } finally {        AnimationUtils.unlockAnimationClock();    }    ......}

在 Choreographer.postCallback() 方法中将 mTraversalRunnable 塞进了 mCallbackQueues<> 数组中，下面的 doCallbacks() 方法就要把它取出来执行了。

> Choreographer.java    void doCallbacks(int callbackType, long frameTimeNanos) {        CallbackRecord callbacks;        synchronized (mLock) {            final long now = System.nanoTime();   // 根据 callbackType 找到对应的 CallbackRecord 对象            callbacks = mCallbackQueues.extractDueCallbacksLocked(                    now / TimeUtils.NANOS_PER_MS);            if (callbacks == null) {                return;            }            mCallbacksRunning = true;            ......        }        try {            for (CallbackRecord c = callbacks; c != null; c = c.next) {                // 执行 callBack                c.run(frameTimeNanos);            }        } finally {           ......        }    }

根据 callbackType 找到对应的 mCallbackQueues ，然后执行，具体流程就不深入分析了。callbackType 共有四个类型，分别是CALLBACK_INPUT、CALLBACK_ANIMATION、CALLBACK_TRAVERSAL、CALLBACK_COMMIT 。

> Choreographer.CallbackRecordpublic void run(long frameTimeNanos) {            if (token == FRAME_CALLBACK_TOKEN) {                ((FrameCallback)action).doFrame(frameTimeNanos);            } else {                ((Runnable)action).run();            }        }

到此为止，mTraversalRunnable 得以被执行，View.invalidate() 的整个流程就走通了。总结一下：

1. 从 View.invalidate() 开始，最后会递归调用 parent.invalidateChildInParent()方法。这里最顶层的 parent 是 ViewRootImpl 。ViewRootImpl 是 DecorView 的 parent，这个赋值调用链是这样的 ActivityThread.handleResumeActivity -> WindowManagerImpl.addView() -> WindowManagerGlobal.addView() -> ViewRootImpl.setView() -> View.assignParent() 。
2. ViewRootImpl.invalidateChildInParent() 最终调用到 scheduleTraversals() 方法，其中建立同步屏障之后，通过 Choreographer.postCallback() 方法提交了任务mTraversalRunnable，这个任务就是负责 View 的测量，布局，绘制。
3. Choreographer.postCallback() 方法通过 DisplayEventReceiver.nativeScheduleVsync() 方法向系统底层注册了下一次 vsync 信号的监听。当下一次 vsync 来临时，系统会回调其 dispatchVsync() 方法，最终回调FrameDisplayEventReceiver.onVsync() 方法。
4. FrameDisplayEventReceiver.onVsync() 方法中取出之前提交的 mTraversalRunnable并执行。这样就完成了整个绘制流程。

如何监测应用的 FPS？

监测当前应用的 FPS 很简单。每次 vsync 信号回调中，都会执行四种类型的 mCallbackQueues 队列中的回调任务。而 Choreographer 又对外提供了提交回调任务的方法，这个方法就是 Choreographer.getInstance().postFrameCallback() 。简单跟进去看一下。

> Choreographer.javapublic void postFrameCallback(FrameCallback callback) {    postFrameCallbackDelayed(callback, 0);}public void postFrameCallbackDelayed(FrameCallback callback, long delayMillis) {    ......    // 这里的类型是 CALLBACK_ANIMATION    postCallbackDelayedInternal(CALLBACK_ANIMATION,            callback, FRAME_CALLBACK_TOKEN, delayMillis);}

和 View.invalite() 流程中调用的 Choreographer.postCallback() 基本一致，仅仅只是 callback 类型不一致，这里是 CALLBACK_ANIMATION 。

我直接给出实现代码 ：FpsMonitor.kt<15>

object FpsMonitor {    private const val FPS_INTERVAL_TIME = 1000L    private var count = 0    private var isFpsOpen = false    private val fpsRunnable by lazy { FpsRunnable() }    private val mainHandler by lazy { Handler(Looper.getMainLooper()) }    private val listeners = arrayListOf<(Int) -> Unit>()    fun startMonitor(listener: (Int) -> Unit) {        // 防止重复开启        if (!isFpsOpen) {            isFpsOpen = true            listeners.add(listener)            mainHandler.postDelayed(fpsRunnable, FPS_INTERVAL_TIME)            Choreographer.getInstance().postFrameCallback(fpsRunnable)        }    }    fun stopMonitor() {        count = 0        mainHandler.removeCallbacks(fpsRunnable)        Choreographer.getInstance().removeFrameCallback(fpsRunnable)        isFpsOpen = false    }    class FpsRunnable : Choreographer.FrameCallback, Runnable {        override fun doFrame(frameTimeNanos: Long) {            count++            Choreographer.getInstance().postFrameCallback(this)        }        override fun run() {            listeners.forEach { it.invoke(count) }            count = 0            mainHandler.postDelayed(this, FPS_INTERVAL_TIME)        }    }}

大致逻辑是这样的 ：

• 声明变量 count 用于统计回调次数
• 通过 Choreographer.getInstance().postFrameCallback(fpsRunnable) 注册监听下一次 vsync信号，提交任务，任务回调只做两件事，一是 count++，二是继续注册监听下一次 vsync 信号 。
• 通过 Handler 做个定时任务，每隔一秒统计 count 值并清空。

来张 GIF 感受一下，源码已经上传到我的开源项目 Mamba<16> 。

最后

目前也有很多开源项目实现了 FPS 监测或者流畅度检测的功能。

滴滴开源的 DoraemonKit<17> 的做法和上面介绍的是一致的（没错，我就是仿照它写的，/goutou），可以看一下 PerformanceDataManager.startMonitorFrameInfo() 方法的实现。

腾讯开源的 Matrix<18> 虽然也是在 Choreographer 上动手脚，但做的更加彻底，它可以监听到CALLBACK_INPUT、CALLBACK_ANIMATION、CALLBACK_TRAVERSAL 三种事件各自精确的耗时，重点关注 LooperMonitor 和 UIThreadMonitor 这两个类。具体原理这里就不再分析了，可以给大家推荐一篇文章， Matrix-TraceCanary的设计和原理分析手册<19> 。

这一期的文章到这就结束了。以 如何监测应用的 FPS 为引子，重点讲述了屏幕刷新机制和 Choreographer 的工作流程，中间也掺杂了一些其他内容。后续的文章也将延续此风格，尽量涵括更多的知识点，敬请期待。

最后留下一个简单的问题，为什么会发生掉帧？ 欢迎在评论区进行交流。