从 Android 4.1 开始，谷歌在黄油计划中，引入了了三个核心元素，即 VSYNC、Triple Buffer 和 Choreographer。
在一个典型的显示系统中，一般包括CPU、GPU、Display三个部分， CPU负责计算帧数据，把计算好的数据交给GPU，GPU会对图形数据进行渲染，渲染好后放到buffer(图像缓冲区)里存起来，然后Display（屏幕或显示器）负责把buffer里的数据呈现到屏幕上。
-
屏幕刷新频率
一秒内屏幕刷新的次数，如常见的 60 Hz。刷新频率取决于硬件的固定参数（不会变的）。 -
逐行扫描
显示器并不是一次性将画面显示到屏幕上，而是从左到右边，从上到下逐行扫描，顺序显示整屏的一个个像素点，不过这一过程快到人眼无法察觉到变化。以 60 Hz 刷新率的屏幕为例，这一过程即 1000 / 60 ≈ 16ms。 -
帧率
表示 GPU 在一秒内绘制操作的帧数，单位 fps。例如在电影界采用 24 帧的速度足够使画面运行的非常流畅。而 Android 系统则采用更加流程的 60 fps，即每秒钟GPU最多绘制 60 帧画面。帧率是动态变化的，例如当画面静止时，GPU 是没有绘制操作的，屏幕刷新的还是buffer中的数据，即GPU最后操作的帧数据。 -
画面撕裂（tearing）
一个屏幕内的数据来自2个不同的帧，画面会出现撕裂感，
理想情况下帧率和刷新频率保持一致，即每绘制完成一帧，显示器显示一帧。但是CPU/GPU写数据是不可控的，所以会出现buffer里有些数据根本没显示出来就被重写了，即buffer里的数据可能是来自不同的帧的， 当屏幕刷新时，此时它并不知道buffer的状态，因此从buffer抓取的帧并不是完整的一帧画面，即出现画面撕裂。
那咋解决画面撕裂呢？
双缓存+VSYNC
由于图像绘制和屏幕读取 使用的是同个buffer，所以屏幕刷新时可能读取到的是不完整的一帧画面。双缓存，让绘制和显示器拥有各自的buffer：GPU 始终将完成的一帧图像数据写入到 Back Buffer，而显示器使用 Frame Buffer，当屏幕刷新时，Frame Buffer 并不会发生变化，当Back buffer准备就绪后，它们才进行交换。
什么时候进行两个buffer的交换呢？
当扫描完一帧画面后，设备需要重新回到第一行以进入下一次的循环，此时有一段时间空隙，称为VerticalBlanking Interval(VBI)。那，这个时间点就是我们进行缓冲区交换的最佳时间。因为此时屏幕没有在刷新，也就避免了交换过程中出现 screen tearing的状况。
VSYNC 信号是由屏幕（显示设备）产生的，利用VBI时期出现的vertical sync pulse（垂直同步脉冲）来保证双缓冲在最佳时间点才进行交换。并且以 60fps 的固定频率发送给 Android 系统，Android 系统中的 SurfaceFlinger 接收发送的 VSYNC 信号。VSYNC 信号表明可对屏幕进行刷新而不会产生撕裂。另外，交换是指各自的内存地址，可以认为该操作是瞬间完成。
CPU/GPU根据VSYNC信号同步处理数据，可以让CPU/GPU有完整的16ms时间来处理数据，减少了jank（丢帧）。
一句话总结，VSync同步使得CPU/GPU充分利用了16.6ms时间，减少jank。
现在有的手机已经开始使用更高频率了，需要硬件设备性能一起提上来才能有更好的体验
如果界面比较复杂，CPU/GPU的处理时间较长 超过了16.6ms呢？如下图：
- 在第二个时间段内，但却因 GPU 还在处理 B 帧，缓存没能交换，导致 A 帧被重复显示。
- 而B完成后，又因为缺乏VSync pulse信号，它只能等待下一个signal的来临。于是在这一过程中，有一大段时间是被浪费的。
- 当下一个VSync出现时，CPU/GPU马上执行操作（A帧），且缓存交换，相应的显示屏对应的就是B。这时看起来就是正常的。只不过由于执行时间仍然超过16ms，导致下一次应该执行的缓冲区交换又被推迟了——如此循环反复，便出现了越来越多的“Jank”。
为什么 CPU 不能在第二个 16ms 处理绘制工作呢？
原因是只有两个 buffer，Back buffer正在被GPU用来处理B帧的数据， Frame buffer的内容用于Display的显示，这样两个buffer都被占用，CPU 则无法准备下一帧的数据。 那么，如果再提供一个buffer，CPU、GPU 和显示设备都能使用各自的buffer工作，互不影响。
三缓存
三缓存就是在双缓冲机制基础上增加了一个 Graphic Buffer 缓冲区，这样可以最大限度的利用CPU空闲时间，带来的坏处是多使用的一个 Graphic Buffer 所占用的内存。
- 第一个Jank，是不可避免的。但是在第二个 16ms 时间段，CPU/GPU 使用 第三个 Buffer 完成C帧的计算，虽然还是会多显示一次 A 帧，但后续显示就比较顺畅了，有效避免 Jank 的进一步加剧。
- 注意在第3段中，A帧的计算已完成，但是在第4个vsync来的时候才显示，如果是双缓冲，那在第三个vynsc就可以显示了。
三缓冲有效利用了等待vysnc的时间，减少了jank，但是带来了延迟。 所以，是不是 Buffer 越多越好呢？这个是否定的，Buffer 正常还是两个，当出现 Jank 后三个足以。
那Choreographer用来干什么的？
Choreographer：一般通过Choreographer来监控应用的帧率。
- Choreographer 负责请求(FrameDisplayEventReceiver.scheduleVsync) 和接收 Vsync 信号( FrameDisplayEventReceiver.onVsync )。
- 当 Vsync 到来的时候负责接收和处理 App 的各种更新消息和回调。比如集中处理 Input(主要是 Input 事件的处理) 、Animation(动画相关)、Traversal(包括 measure、layout、draw 等操作) ，判断卡顿掉帧情况，记录 CallBack 耗时等。
- 同时通过对系统的时间脉冲（垂直同步信号Vsync）周期的调整，来控制每一帧绘制操作的时机，使得App 的渲染更为稳定。
- 通常 应用层不会直接使用Choreographer，而是使用更高级的API，例如动画和View绘制相关的ValueAnimator.start()、View.invalidate()等。
Choreographer源码分析
使用：
看看 Choreographer 是如何协调任务的执行。
mChoreographer = Choreographer.getInstance();
mFrameCallback = new Choreographer.FrameCallback() {
@Override
public void doFrame(long frameTimeNanos) {
//do something
}
};
mChoreographer.postFrameCallback(mFrameCallback);构建实例
Choreographer在View绘制相关类中的应用先实例化Choreographer 的构造方法被设计成私有，并且是线程单例的。只能通过其内部的 getInstance 方法获取当前线程的 Choreographer 实例：
public static Choreographer getInstance() {
// Choreographer线程单例的实现方式
return sThreadInstance.get();
}通过 ThreadLocal 实现 Choreographer 的线程单例。
private static final ThreadLocal<Choreographer> sThreadInstance =
new ThreadLocal<Choreographer>() {
@Override
protected Choreographer initialValue() {
// 获取当前线程的Looper对象
Looper looper = Looper.myLooper();
if (looper == null) {
// 如果当前线程未创建Looper对象则抛出异常
// 主线程（UI线程）的Looper默认在ActivityThread的main方法被创建
throw new IllegalStateException("The current thread must have a looper!");
}
// 为当前线程创建一个Choreographer对象 后面进入构造方法看下
Choreographer choreographer = new Choreographer(looper, VSYNC_SOURCE_APP);
if (looper == Looper.getMainLooper()) {
// 如果是UI线程赋值给成员mMainInstance
mMainInstance = choreographer;
}
return choreographer;
}
};看下 Choreographer 的构造方法
private Choreographer(Looper looper, int vsyncSource) {
// 当前线程的Looper
mLooper = looper;
// 使用该Looper创建FrameHandler
mHandler = new FrameHandler(looper);
//USE_VSYNC = SystemProperties.getBoolean("debug.choreographer.vsync", true);
// 4.1后默认开启VSYNC，开启VSYNC后将通过FrameDisplayEventReceiver接收VSYNC脉冲信号
mDisplayEventReceiver = USE_VSYNC
? new FrameDisplayEventReceiver(looper, vsyncSource)
: null;
mLastFrameTimeNanos = Long.MIN_VALUE;
// 计算一帧的时间
// Android手机屏幕采用60Hz的刷新频率
// 这里是纳秒 ≈16000000ns 还是16ms
mFrameIntervalNanos = (long)(1000000000 / getRefreshRate());
// 创建一个CallbackQueu的数组，默认为4
// CallbackQueue中存放要执行的输入、动画、遍历绘制、提交任务
// 也就是 CALLBACK_INPUT、CALLBACK_ANIMATION、CALLBACK_TRAVERSAL、CALLBACK_COMMIT
mCallbackQueues = new CallbackQueue[CALLBACK_LAST + 1];
for (int i = 0; i <= CALLBACK_LAST; i++) {
mCallbackQueues[i] = new CallbackQueue();
}
// b/68769804: For low FPS experiments.
setFPSDivisor(SystemProperties.getInt(ThreadedRenderer.DEBUG_FPS_DIVISOR, 1));
}创建frameHandler处理VSYNC信号任务
Choreographer 的构造必须传递一个 Looper 对象，其内部会根据该 Looper 创建一个 FrameHandler。Choreographer 的所有任务最终都会发送到该 Looper 所在的线程。
private final class FrameHandler extends Handler {
public FrameHandler(Looper looper) {
super(looper);
}
@Override
public void handleMessage(Message msg) {
switch (msg.what) {
case MSG_DO_FRAME:
// 执行doFrame
// 如果启用VSYNC机制，当VSYNC信号到来时触发
doFrame(System.nanoTime(), 0);
break;
case MSG_DO_SCHEDULE_VSYNC:
// 申请VSYNC信号，例如当前需要绘制任务时
doScheduleVsync();
break;
case MSG_DO_SCHEDULE_CALLBACK:
// 需要延迟的任务，最终还是执行doScheduleVsync
doScheduleCallback(msg.arg1);
break;
}
}
}创建FrameDisplayEventReceiver接收VSYN信号
FrameDisplayEventReceiver 是 DisplayEventReceiver 的子类，DisplayEventReceiver 是一个 抽象类。DisplayEventReceiver 的构造方法中会通过 JNI 创建一个 IDisplayEventConnection 的 VSYNC 的监听者。
public DisplayEventReceiver(Looper looper, int vsyncSource) {
if (looper == null) {
throw new IllegalArgumentException("looper must not be null");
}
mMessageQueue = looper.getQueue();
// 注册VSYNC信号监听者
mReceiverPtr = nativeInit(new WeakReference<DisplayEventReceiver>(this), mMessageQueue, vsyncSource);
mCloseGuard.open("dispose");
}
另外 DisplayEventReceiver 内还有用于申请 VSYNC 信号的 scheduledVsync 方法和用于接收 VSYNC 信号的 onVsync 方法。这样，当应用需要绘制时，通过 scheduledVsync 方法申请 VSYNC 中断，来自 EventThread 的 VSYNC 信号就可以传递到 Choreographer：
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中断信号
// 会回调onVsync方法
nativeScheduleVsync(mReceiverPtr);
}
}
public void onVsync(long timestampNanos, int builtInDisplayId, int frame) {
// 该方法在其子类FrameDisplayEventReceiver中被重写
// 目的是通知Choreographer
}
CallbackQueue，用于保存通过 postCallback 添加的任务。目前一共定义了四种任务类型，它们分别是：
- CALLBACK_INPUT：优先级最高，和输入事件处理有关。
- CALLBACK_ANIMATION：优先级其次，和 Animation 的处理有关
- CALLBACK_TRAVERSAL：优先级最低，和 UI 绘制任务有关
- CALLBACK_COMMIT：最后执行，和提交任务有关（在 API Level 23 添加）
优先级的高低和处理顺序有关。CallbackQueue 是一个容量为 4 的数组，分别对应不同的任务类型。通过 Choreographer 添加的任务最后都被封装成 CallbackRecord，同种任务之间按照时间顺序以链表的形式保存在 CallbackQueue 内。
private static final class CallbackRecord {
// 链表，指向下一个
public CallbackRecord next;
// 到期时间
public long dueTime;
// Runnable or FrameCallback
public Object action;
public Object token;
public void run(long frameTimeNanos) {
if (token == FRAME_CALLBACK_TOKEN) {
// 通过postFrameCallback 或 postFrameCallbackDelayed
// 会执行这里
((FrameCallback)action).doFrame(frameTimeNanos);
} else {
((Runnable)action).run();
}
}
}View 的绘制流程
下面，以 View 的绘制流程为例。View会递归的调用父容器的invalidateChild，逐级回溯，最终走到ViewRootImpl的invalidate。
ViewRootImpl.java
void invalidate() {
mDirty.set(0, 0, mWidth, mHeight);
if (!mWillDrawSoon) {
scheduleTraversals();
}
} 里面调用scheduleTraversals准备重绘
ViewRootImpl.java
// 将UI绘制的mTraversalRunnable加入到下次垂直同步信号到来的等待callback中去
// mTraversalScheduled用来保证本次Traversals未执行前，不会绘制两次
void scheduleTraversals() {
if (!mTraversalScheduled) {
mTraversalScheduled = true;
// 同步栅栏，意思就是阻塞所有的同步消息 ，保证VSync到来立即执行绘制
mTraversalBarrier = mHandler.getLooper().getQueue().postSyncBarrier();
// postCallback的时候，顺便请求vnsc垂直同步信号scheduleVsyncLocked
mChoreographer.postCallback(
Choreographer.CALLBACK_TRAVERSAL, mTraversalRunnable, null);
<!--添加一个处理触摸事件的回调，防止中间有Touch事件过来-->
if (!mUnbufferedInputDispatch) {
scheduleConsumeBatchedInput();
}
notifyRendererOfFramePending();
pokeDrawLockIfNeeded();
}
} Choreographer 提供了两种添加任务的方式，postCallback() 和 postFrameCallback()，当然还有对应的 delay 方法。
- postCallback 对应调用 postCallbackDelayed
public void postCallbackDelayed(int callbackType,
Runnable action, Object token, long delayMillis) {
if (action == null) {
throw new IllegalArgumentException("action must not be null");
}
if (callbackType < 0 || callbackType > CALLBACK_LAST) {
throw new IllegalArgumentException("callbackType is invalid");
}
// 最终都会调用到postCallbackDelayedInternal
postCallbackDelayedInternal(callbackType, action, token, delayMillis);
}
- postFrameCallback 对应调用 postFrameCallbackDelayed
public void postFrameCallbackDelayed(FrameCallback callback, long delayMillis) {
if (callback == null) {
throw new IllegalArgumentException("callback must not be null");
}
//最终调用postCallbackDelayedInternal
postCallbackDelayedInternal(CALLBACK_ANIMATION,
callback, FRAME_CALLBACK_TOKEN, delayMillis);
}
postCallback 相比 postFrameCallback 更加灵活一些。
它们最终都会调用到 postCallbackDelayedInternal 方法：
private void postCallbackDelayedInternal(int callbackType,
Object action, Object token, long delayMillis) {
synchronized (mLock) {
// 当前时间
final long now = SystemClock.uptimeMillis();
// 加上延迟时间
final long dueTime = now + delayMillis;
// 根据任务类型添加到mCallbackQueues中
// VSYNC信号处理任务具有优先级
mCallbackQueues[callbackType].addCallbackLocked(dueTime, action, token);
if (dueTime <= now) {
//表示立即执行，立即申请VSYNC信号
scheduleFrameLocked(now);
} else {
// 在指定时间运行，最终仍然会调用scheduleFrameLocked
Message msg = mHandler.obtainMessage(MSG_DO_SCHEDULE_CALLBACK, action);
// 到时根据callbackType在mCallbackQueues中查找执行
msg.arg1 = callbackType;
// 消息设置为异步
msg.setAsynchronous(true);
mHandler.sendMessageAtTime(msg, dueTime);
}
}
}根据任务类型 callbackType 添加到对应的 CallbackQueue 内，然后判断任务是否有延迟，无延迟则立即执行 scheduleFrameLocked 方法，否则发送定时消息到 FrameHandler，handler里面针对消息类型MSG_DO_SCHEDULE_VSYNC会调用doScheduleCallback，最终还是调用 scheduleFrameLocked 方法：
private void scheduleFrameLocked(long now) {
// mFrameScheduled保证16ms内，只会申请一次垂直同步信号
// scheduleFrameLocked可以被调用多次，但是下一个vsync到来之前，不会有新的请求发出
// 多余的scheduleFrameLocked调用被无效化
if (!mFrameScheduled) {
mFrameScheduled = true;
// 判断是否开启VSYNC
if (USE_VSYNC) {
// 判断是否在原线程
if (isRunningOnLooperThreadLocked()) {
//默认会走这里
scheduleVsyncLocked();
} else {
// 如果不在原线程，则发送消息到原线程
//调用doScheduleCallback， 最后调用scheduleVsyncLocked方法
Message msg = mHandler.obtainMessage(MSG_DO_SCHEDULE_VSYNC);
msg.setAsynchronous(true);
mHandler.sendMessageAtFrontOfQueue(msg);
}
} else {
// 如果未开启VSYNC则直接doFrame方法
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到来之前，不会再去请求新的VSYNC，因为16ms内申请两个VSYNC没意义;
VSYNC到来之后，Choreographer利用Handler将FrameDisplayEventReceiver封装成一个异步Message，发送到UI线程的MessageQueue;
注意 USE_VSYNC，Android 4.1 之后系统默认开启 VSYNC。
如果系统未开启 VSYNC 机制，此时直接发送 MSG_DO_FRAME 消息到 FrameHandler。针对该消息类型，handler中会直接执行 doFrame 方法。（这个涉及丢帧处理，后面进行讲解）
isRunningOnLooperThreadLocked 方法，其内部根据 Looper 判断是否在原线程，否则发送消息到 FrameHandler。最终还是会调用 scheduleVsyncLocked 方法申请 VSYNC 信号。
下面进入scheduleVsyncLocked：
private void scheduleVsyncLocked() {
// 调用 FrameDisplayEventReceiver 的scheduleVsync
// 实际调用到其父类DisplayEventReceiver
mDisplayEventReceiver.scheduleVsync();
}
scheduleVsyncLocked方法其实就是通过 FrameDisplayEventReceiver 申请 VSYNC 信号，实际是在其父类 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信号 native方法
nativeScheduleVsync(mReceiverPtr);
}
}
真正的请求是在DisplayEventReceiver类中的scheduleVsync()，里面调用的是一个native方法来进行请求Vsync信号。DisplayEventReceiver 初始化完成后，Choreographer 与 SurfaceFlinger 的 Vsync 信号传递通道就建立好了，后续有 Vsync 信号到来时，就可以沿着这条通道，一路回调到 Java 层的 Choreographer.FrameDisplayEventReceiver.onVsync 方法。
接着看下 VSYNC 信号的接收方法 onVsync，该方法在其子类 FrameDisplayEventReceiver 中重写：
private final class FrameDisplayEventReceiver extends DisplayEventReceiver
implements Runnable {
private boolean mHavePendingVsync;
private long mTimestampNanos;
private int mFrame;
public FrameDisplayEventReceiver(Looper looper, int vsyncSource) {
super(looper, vsyncSource, CONFIG_CHANGED_EVENT_SUPPRESS);
}
// TODO(b/116025192): physicalDisplayId is ignored because SF only emits VSYNC events for
// the internal display and DisplayEventReceiver#scheduleVsync only allows requesting VSYNC
// for the internal display implicitly.
@Override
public void onVsync(long timestampNanos, long physicalDisplayId, int frame) {
// Post the vsync event to the Handler.
// The idea is to prevent incoming vsync events from completely starving
// the message queue. If there are no messages in the queue with timestamps
// earlier than the frame time, then the vsync event will be processed immediately.
// Otherwise, messages that predate the vsync event will be handled first.
long now = System.nanoTime();
if (timestampNanos > now) {
//正常情况，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;
}
if (mHavePendingVsync) {
Log.w(TAG, "Already have a pending vsync event. There should only be "
+ "one at a time.");
} else {
mHavePendingVsync = true;
}
//timestampNanos其实是本次vsync产生的时间，从服务端发过来
mTimestampNanos = timestampNanos;
mFrame = frame;
// this表示当前Runnable
//VSYNC到来之后，Choreographer利用Handler将FrameDisplayEventReceiver封装成一个 //异步Message，发送到UI线程的MessageQueue;
//后面会进入run()
Message msg = Message.obtain(mHandler, this);
//由于已经存在同步栅栏，所以VSYNC到来的Message需要作为异步消息发送过去
msg.setAsynchronous(true);
mHandler.sendMessageAtTime(msg, timestampNanos / TimeUtils.NANOS_PER_MS);
}
@Override
public void run() {
mHavePendingVsync = false;
// 回调这里，执行doFrame方法
doFrame(mTimestampNanos, mFrame);
}
}
之所以要封装成异步Message，是因为前面添加了一个同步栅栏，同步消息不会被执行；
FrameDisplayEventReceiver 实现了 Runnable，将其（上面的this）作为 callback 发送到 FrameHandler，此时 run 方法便得到执行，然后执行 doFrame 方法
void doFrame(long frameTimeNanos, int frame) {
final long startNanos;
synchronized (mLock) {
if (!mFrameScheduled) {
// 没有执行的Frame任务直接return
//也为了保证一次16ms只有一次垂直同步信号
return;
}
...
// 预期执行时间
long intendedFrameTimeNanos = frameTimeNanos;
// 当前时间
startNanos = System.nanoTime();
//执行时间差
final long jitterNanos = startNanos - frameTimeNanos;
// 时间差是否超过一帧的时间
if (jitterNanos >= mFrameIntervalNanos) {
// 计算掉帧数（取整）每大于16ms，就多掉一帧
final long skippedFrames = jitterNanos / mFrameIntervalNanos;
// 掉帧超过30帧打印log提示
if (skippedFrames >= SKIPPED_FRAME_WARNING_LIMIT) {
//掉帧log skippedFrames很大一定掉帧，但是为0不代表没掉帧，因为上边是取整的
Log.i(TAG, "Skipped " + skippedFrames + " frames! "
+ "The application may be doing too much work on its main thread.");
}
//帧偏移（时间差与帧间隔取余，用于修正预期执行时间）
final long lastFrameOffset = jitterNanos % mFrameIntervalNanos;
//修正后的预计执行时间。也就是开始doFrame的真正有效时间戳
frameTimeNanos = startNanos - lastFrameOffset;
}
if (frameTimeNanos < mLastFrameTimeNanos) {
// 某种异常，导致小于上一个信号最后一帧的时间
// 一般是生成vsync的机制出现了问题，所以重新申请VSYNC信号
scheduleVsyncLocked();
return;
}
...
mFrameInfo.setVsync(intendedFrameTimeNanos, frameTimeNanos);
// 标志位恢复
mFrameScheduled = false;
// 记录最后一帧时间的时间
mLastFrameTimeNanos = frameTimeNanos;
}
try {
//按类型顺序 执行任务
Trace.traceBegin(Trace.TRACE_TAG_VIEW, "Choreographer#doFrame");
AnimationUtils.lockAnimationClock(frameTimeNanos / TimeUtils.NANOS_PER_MS);
mFrameInfo.markInputHandlingStart();
// 先执行CALLBACK_INPUT任务
doCallbacks(Choreographer.CALLBACK_INPUT, frameTimeNanos);
mFrameInfo.markAnimationsStart();
// 再执行CALLBACK_ANIMATION
doCallbacks(Choreographer.CALLBACK_ANIMATION, frameTimeNanos);
mFrameInfo.markPerformTraversalsStart();
// 其次执行CALLBACK_TRAVERSAL
doCallbacks(Choreographer.CALLBACK_TRAVERSAL, frameTimeNanos);
// API Level 23 之后加入，
doCallbacks(Choreographer.CALLBACK_COMMIT, frameTimeNanos);
} finally {
AnimationUtils.unlockAnimationClock();
Trace.traceEnd(Trace.TRACE_TAG_VIEW);
}
}
上面都有注释了很好理解，接着看任务的具体执行doCallbacks 方法，将根据不同的任务类型依次执行其 run 方法：
void doCallbacks(int callbackType, long frameTimeNanos) {
CallbackRecord callbacks;
synchronized (mLock) {
final long now = System.nanoTime();
// 根据指定的类型CallbackkQueue中查找到达执行时间的CallbackRecord
callbacks = mCallbackQueues[callbackType].extractDueCallbacksLocked(
now / TimeUtils.NANOS_PER_MS);
if (callbacks == null) {
return;
}
mCallbacksRunning = true;
if (callbackType == Choreographer.CALLBACK_COMMIT) {
final long jitterNanos = now - frameTimeNanos;
Trace.traceCounter(Trace.TRACE_TAG_VIEW, "jitterNanos", (int) jitterNanos);
if (jitterNanos >= 2 * mFrameIntervalNanos) {
final long lastFrameOffset = jitterNanos % mFrameIntervalNanos
+ mFrameIntervalNanos;
if (DEBUG_JANK) {
Log.d(TAG, "Commit callback delayed by " + (jitterNanos * 0.000001f)
+ " ms which is more than twice the frame interval of "
+ (mFrameIntervalNanos * 0.000001f) + " ms! "
+ "Setting frame time to " + (lastFrameOffset * 0.000001f)
+ " ms in the past.");
mDebugPrintNextFrameTimeDelta = true;
}
frameTimeNanos = now - lastFrameOffset;
mLastFrameTimeNanos = frameTimeNanos;
}
}
}
try {
Trace.traceBegin(Trace.TRACE_TAG_VIEW, CALLBACK_TRACE_TITLES[callbackType]);
// 迭代执行所有任务
for (CallbackRecord c = callbacks; c != null; c = c.next) {
// 回调CallbackRecord的run
// 其内部回调Callback的run
c.run(frameTimeNanos);
}
} finally {
synchronized (mLock) {
mCallbacksRunning = false;
do {
final CallbackRecord next = callbacks.next;
//回收CallbackRecord
recycleCallbackLocked(callbacks);
callbacks = next;
} while (callbacks != null);
}
Trace.traceEnd(Trace.TRACE_TAG_VIEW);
}
}
注意遍历 CallbackRecord 链表调用其 run 方法：
public void run(long frameTimeNanos) {
if (token == FRAME_CALLBACK_TOKEN) {
// 通过postFrameCallback 或 postFrameCallbackDelayed
// 会执行这里
((FrameCallback)action).doFrame(frameTimeNanos);
} else {
((Runnable)action).run();
}
}
token == FRAME_CALLBACK_TOKEN 表示通过 postFrameCallback 添加的任务。这里就是按照 Callback 类型回调其 run 方法。
mChoreographer.postCallback传的token是null，所以取出action，就是Runnable，执行run()，这里的action就是 ViewRootImpl 发起的绘制任务mTraversalRunnable了，那么这样整个逻辑就闭环了。
回到 ViewRootImpl 发起的绘制任务，在回调方法中执行doTraversal，此时 View 的绘制流程便开始了。
final class TraversalRunnable implements Runnable{
@Override
public void run(){
// View 的绘制任务开始
doTraversal();
}
}
总结
Choreographer构造函数
- 创建了FrameHandler来处理请求VSync和当VSync到来时的任务；
- 创建FrameDisplayEventReceiver提供请求和接收VSYNC脉冲信号方法
- 创建一个CallbackQueu的数组，默认为4。CallbackQueue中存放要执行的输入、动画、遍历绘制、提交任务
View的绘制过程，即使用Choreographer的postCallback()、postFrameCallback() 的过程理解（View会递归的调用父容器的invalidateChild，逐级回溯，最终走到ViewRootImpl的invalidate-》scheduleTraversals-》mChoreographer.postCallback/postFrameCallback等）
- 将任务（postCallback中的参数） 存队列CallbackQueue中；
- 请求并监听VSync信号
- 当VSync到来时（回调FrameDisplayEventReceiver的onVsync方法），使用mHandler发送异步message，这个message的Runnable就是队列中的所有任务。
- 在handler中回调doFrame对Vsync信号进行帧处理（做丢帧、纠正预计执行时间的偏移等操作，主要是为了保证帧率和刷新频率同频）
- 处理完后针对不同的任务类型对任务进行处理（会进入相应的回调，如View的绘制任务进入TraversalRunnable 的doTraversal方法开始绘制）。
流程图：
问题
- 丢帧(掉帧) ，是说 这一帧延迟显示 还是丢弃不再显示 ？
答：延迟显示，因为缓存交换的时机只能等下一个VSync了。 - 布局层级较多/主线程耗时 是如何造成 丢帧的呢？
答：布局层级较多/主线程耗时 会影响CPU/GPU的执行时间，大于16.6ms时只能等下一个VSync了。 - 16.6ms刷新一次 是啥意思？是每16.6ms都走一次 measure/layout/draw ？
答：屏幕的固定刷新频率是60Hz，即16.6ms。不是每16.6ms都走一次 measure/layout/draw，而是有绘制任务才会走，并且绘制时间间隔是取决于布局复杂度及主线程耗时。 - measure/layout/draw 走完，界面就立刻刷新了吗?
答：不是。measure/layout/draw 走完后 会在VSync到来时进行缓存交换和刷新。 - 如果界面没动静止了，还会刷新吗？
答：屏幕会固定每16.6ms刷新，但CPU/GPU没有绘制任务时就不走绘制流程。 - VSYNC具体指啥？在屏幕刷新中如何工作的？
答：当扫描完一个屏幕后，设备需要重新回到第一行以进入下一次的循环，此时会发出一个vertical sync pulse（垂直同步脉冲）来保证双缓冲在最佳时间点才进行交换。并且Android4.1后 CPU/GPU的绘制是在VSYNC到来时开始。 - 屏幕刷新使用 双缓存、三缓存，这又是啥意思呢？
答：双缓存是Back buffer、Frame buffer，用于解决画面撕裂。三缓存增加一个Back buffer，用于减少Jank。
2095
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
