一 渲染的原理
具体到Android中，在Android4.1之前，屏幕刷新也遵循 上面介绍的 双缓存+VSync 机制。如下图：
以时间的顺序来看下将会发生的过程：
- Display显示第0帧数据，此时CPU和GPU渲染第1帧画面，且在Display显示下一帧前完成
- 因为渲染及时，Display在第0帧显示完成后，也就是第1个VSync后，缓存进行交换，然后正常显示第1帧
- 接着第2帧开始处理，是直到第2个VSync快来前才开始处理的。
- 第2个VSync来时，由于第2帧数据还没有准备就绪，缓存没有交换，显示的还是第1帧。这种情况被Android开发组命名为“Jank”，即发生了丢帧。
- 当第2帧数据准备完成后，它并不会马上被显示，而是要等待下一个VSync 进行缓存交换再显示。
所以总的来说，就是屏幕平白无故地多显示了一次第1帧。
原因是 第2帧的CPU/GPU计算 没能在VSync信号到来前完成 。
我们知道，双缓存的交换 是在Vsyn到来时进行，交换后屏幕会取Frame buffer内的新数据，而实际 此时的Back buffer 就可以供GPU准备下一帧数据了。 如果 Vsyn到来时 CPU/GPU就开始操作的话，是有完整的16.6ms的，这样应该会基本避免jank的出现了（除非CPU/GPU计算超过了16.6ms）
为了优化显示性能，Google在Android 4.1系统中对Android Display系统进行了重构，实现了Project Butter（黄油工程）：系统在收到VSync pulse后，将马上开始下一帧的渲染。即一旦收到VSync通知（16ms触发一次），CPU和GPU 才立刻开始计算然后把数据写入buffer。
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 缓冲区，这样可以最大限度的利用空闲时间，带来的坏处是多使用的一个 Graphic Buffer 所占用的内存。
-
第一个Jank，是不可避免的。但是在第二个 16ms 时间段，CPU/GPU 使用 第三个 Buffer 完成C帧的计算，虽然还是会多显示一次 A 帧，但后续显示就比较顺畅了，有效避免 Jank 的进一步加剧。
-
注意在第3段中，A帧的计算已完成，但是在第4个vsync来的时候才显示，如果是双缓冲，那在第三个vynsc就可以显示了。
三缓冲有效利用了等待vysnc的时间，减少了jank，但是带来了延迟。 所以，是不是 Buffer 越多越好呢？这个是否定的，Buffer 正常还是两个，当出现 Jank 后三个足以。
以上就是Android屏幕刷新的原理了。
上面讲到，Google在Android 4.1系统中对Android Display系统进行了优化：在收到VSync pulse后，将马上开始下一帧的渲染。即一旦收到VSync通知，CPU和GPU就立刻开始计算然后把数据写入buffer。本节就来讲 "drawing with VSync" 的实现——Choreographer。
- Choreographer，意为 舞蹈编导、编舞者。在这里就是指 对CPU/GPU绘制的指导—— 收到VSync信号 才开始绘制，保证绘制拥有完整的16.6ms，避免绘制的随机性。
- Choreographer，是一个Java类，包路径android.view.Choreographer。类注释是“协调动画、输入和绘图的计时”。
- 通常 应用层不会直接使用Choreographer，而是使用更高级的API，例如动画和View绘制相关的ValueAnimator.start()、View.invalidate()等。
- 业界一般通过Choreographer来监控应用的帧率。
二 源码分析
使用 ValueAnimator.start()、View.invalidate()时，最后也是走到ViewRootImpl的scheduleTraversals()方法。（View.invalidate()内部会循环获取ViewParent直到ViewRootImpl的invalidateChildInParent()方法，然后走到scheduleTraversals()，可自行查看源码 ）
即 所有UI的变化都是走到ViewRootImpl的scheduleTraversals()方法。
//ViewRootImpl.java
void scheduleTraversals() {
if (!mTraversalScheduled) {
mTraversalScheduled = true;
//添加同步屏障，屏蔽同步消息，保证VSync到来立即执行绘制
mTraversalBarrier = mHandler.getLooper().getQueue().postSyncBarrier();
//mTraversalRunnable是TraversalRunnable实例，最终走到run()，也即doTraversal();
mChoreographer.postCallback(
Choreographer.CALLBACK_TRAVERSAL, mTraversalRunnable, null);
if (!mUnbufferedInputDispatch) {
scheduleConsumeBatchedInput();
}
notifyRendererOfFramePending();
pokeDrawLockIfNeeded();
}
}
final class TraversalRunnable implements Runnable {
@Override
public void run() {
doTraversal();
}
}
final TraversalRunnable mTraversalRunnable = new TraversalRunnable();
void doTraversal() {
if (mTraversalScheduled) {
mTraversalScheduled = false;
//移除同步屏障
mHandler.getLooper().getQueue().removeSyncBarrier(mTraversalBarrier);
...
//开始三大绘制流程
performTraversals();
...
}
}主要有以下逻辑：
- 首先使用mTraversalScheduled字段保证同时间多次更改只会刷新一次，例如TextView连续两次setText()，也只会走一次绘制流程。
- 然后把当前线程的消息队列Queue添加了同步屏障，这样就屏蔽了正常的同步消息，保证VSync到来后立即执行绘制，而不是要等前面的同步消息。后面会具体分析同步屏障和异步消息的代码逻辑。
- 调用了mChoreographer.postCallback()方法，发送一个会在下一帧执行的回调，即在下一个VSync到来时会执行TraversalRunnable-->doTraversal()--->performTraversals()-->绘制流程。
接下来，就是分析的重点——Choreographer。我们先看它的实例mChoreographer，是在ViewRootImpl的构造方法内使用Choreographer.getInstance()创建：
Choreographer mChoreographer;
//ViewRootImpl实例是在添加window时创建
public ViewRootImpl(Context context, Display display) {
...
mChoreographer = Choreographer.getInstance();
...
}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和Looper一样 是线程单例的。且当前线程要有looper，Choreographer实例需要传入。接着看看Choreographer构造方法：
private Choreographer(Looper looper, int vsyncSource) {
mLooper = looper;
//使用当前线程looper创建 mHandler
mHandler = new FrameHandler(looper);
//USE_VSYNC 4.1以上默认是true，表示 具备接受VSync的能力，这个接受能力就是FrameDisplayEventReceiver
mDisplayEventReceiver = USE_VSYNC
? new FrameDisplayEventReceiver(looper, vsyncSource)
: null;
mLastFrameTimeNanos = Long.MIN_VALUE;
// 计算一帧的时间，Android手机屏幕是60Hz的刷新频率，就是16ms
mFrameIntervalNanos = (long)(1000000000 / getRefreshRate());
// 创建一个链表类型CallbackQueue的数组，大小为5，
//也就是数组中有五个链表，每个链表存相同类型的任务：输入、动画、遍历绘制等任务（CALLBACK_INPUT、CALLBACK_ANIMATION、CALLBACK_TRAVERSAL）
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));
}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:
// 需要延迟的任务，最终还是执行上述两个事件
doScheduleCallback(msg.arg1);
break;
}
}
}- 注意 USE_VSYNC，用于判断当前是否启用 VSYNC 机制，Android 在 4.1 之后默认开启该机制。
使用doScheduleCallback方法，看看
void doScheduleCallback(int callbackType) {
synchronized (mLock) {
if (!mFrameScheduled) {
final long now = SystemClock.uptimeMillis();
if (mCallbackQueues[callbackType].hasDueCallbacksLocked(now)) {
scheduleFrameLocked(now);
}
}
}
}发现也是走到这里，即延迟运行最终也会走到scheduleFrameLocked()
private void scheduleFrameLocked(long now) {
if (!mFrameScheduled) {
mFrameScheduled = true;
//开启了VSYNC
if (USE_VSYNC) {
if (DEBUG_FRAMES) {
Log.d(TAG, "Scheduling next frame on vsync.");
}
//当前执行的线程，是否是mLooper所在线程
if (isRunningOnLooperThreadLocked()) {
//申请 VSYNC 信号
scheduleVsyncLocked();
} else {
// 若不在，就用mHandler发送消息到原线程，最后还是调用scheduleVsyncLocked方法
Message msg = mHandler.obtainMessage(MSG_DO_SCHEDULE_VSYNC);
msg.setAsynchronous(true);//异步
mHandler.sendMessageAtFrontOfQueue(msg);
}
} else {
// 如果未开启VSYNC则直接doFrame方法（4.1后默认开启）
final long nextFrameTime = Math.max(
mLastFrameTimeNanos / TimeUtils.NANOS_PER_MS + sFrameDelay, now);
if (DEBUG_FRAMES) {
Log.d(TAG, "Scheduling next frame in " + (nextFrameTime - now) + " ms.");
}
Message msg = mHandler.obtainMessage(MSG_DO_FRAME);
msg.setAsynchronous(true);//异步
mHandler.sendMessageAtTime(msg, nextFrameTime);
}
}
}private static final boolean USE_VSYNC = SystemProperties.getBoolean(
"debug.choreographer.vsync", true);FrameDisplayEventReceiver 是 DisplayEventReceiver 的子类，DisplayEventReceiver 是一个 abstract class。在 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 方法，
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);
}
}和用于接收 VSYNC 信号的 onVsync 方法。这样，当应用需要绘制时，通过 scheduledVsync 方法申请 VSYNC 中断，来自 EventThread 的 VSYNC 信号就可以传递到 Choreographer：
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 添加）
优先级的高低和处理顺序有关，每当收到 VSYNC 信号时，Choreographer 将首先处理 INPUT 类型的任务，然后是 ANIMATION 类型，最后才是 TRAVERSAL 类型。
通过 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();
}
}
}接下来分析内部通过 Choreographer 的 postCallback 将绘制任务添加到 Chorographer流程
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，不过其最终还是调用到 scheduleFrameLocked 方法：
private void scheduleFrameLocked(long now) {
//mFrameScheduled默认为false
if (!mFrameScheduled) {
mFrameScheduled = true;
// 判断是否开启VSYNC
if (USE_VSYNC) {
// 判断是否在原线程
if (isRunningOnLooperThreadLocked()) {
//默认会走这里
scheduleVsyncLocked();
} else {
// 否则不在原线程，发送消息到原线程
// 最后还是调用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);
}
}
}注意 USE_VSYNC，如果系统未开启 VSYNC 机制，此时直接发送 MSG_DO_FRAME 消息到 FrameHandler。注意查看上面贴出的 FrameHandler 代码，此时直接执行 doFrame 方法。
不过 Android 4.1 之后系统默认开启 VSYNC，还记得在 Choreographer 的构造方法会创建一个 FrameDisplayEventReceiver，scheduleVsyncLocked 方法将会通过它申请 VSYNC 信号。
FrameDisplayEventReceiver 申请 VSYNC 信号的过程如下：
private void scheduleVsyncLocked() {
// 调用 FrameDisplayEventReceiver 的scheduleVsync
// 实际调用到其父类DisplayEventReceiver
mDisplayEventReceiver.scheduleVsync();
}前面我们也有说过，申请 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信号
nativeScheduleVsync(mReceiverPtr);
}
}接着看下 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);
}
@Override
public void onVsync(long timestampNanos, int builtInDisplayId, int frame) {
if (builtInDisplayId != SurfaceControl.BUILT_IN_DISPLAY_ID_MAIN) {
// 忽略来自非主屏的VSYNC信号
scheduleVsync();
return;
}
// ... 省略
if (mHavePendingVsync) {
Log.w(TAG, "Already have a pending vsync event. There should only be "
+ "one at a time.");
} else {
mHavePendingVsync = true;
}
mTimestampNanos = timestampNanos;
mFrame = frame;
// 发送消息执行doFrame
// 注意this，表示当前Runnable
Message msg = Message.obtain(mHandler, this);
msg.setAsynchronous(true);
mHandler.sendMessageAtTime(msg, timestampNanos / TimeUtils.NANOS_PER_MS);
}
@Override
public void run() {
mHavePendingVsync = false;
// 回调这里，执行doFrame方法
doFrame(mTimestampNanos, mFrame);
}
}FrameDisplayEventReceiver 实现了 Runnable，将其作为 callback 发送到 FrameHandler，此时 run 方法便得到执行并且执行 doFrame 方法：
void doFrame(long frameTimeNanos, int frame) {
final long startNanos;
synchronized (mLock) {
1
if (!mFrameScheduled) {
// 不是在执行Frame任务直接return
return;
}
// ... 省略
// 预期执行时间
long intendedFrameTimeNanos = frameTimeNanos;
// 当前时间
startNanos = System.nanoTime();
final long jitterNanos = startNanos - frameTimeNanos;
// 超时时间是否超过一帧的时间
if (jitterNanos >= mFrameIntervalNanos) {
// 计算掉帧数
final long skippedFrames = jitterNanos / mFrameIntervalNanos;
// 掉帧超过30帧打印Log提示
if (skippedFrames >= SKIPPED_FRAME_WARNING_LIMIT) {
// 著名的掉帧Log
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;
}
if (frameTimeNanos < mLastFrameTimeNanos) {
// 未知原因，居然小于最后一帧的时间
// 重新申请VSYNC信号
scheduleVsyncLocked();
return;
}
if (mFPSDivisor > 1) {
long timeSinceVsync = frameTimeNanos - mLastFrameTimeNanos;
if (timeSinceVsync < (mFrameIntervalNanos * mFPSDivisor) && timeSinceVsync > 0) {
scheduleVsyncLocked();
return;
}
}
mFrameInfo.setVsync(intendedFrameTimeNanos, frameTimeNanos);
// Frame标志位恢复
mFrameScheduled = false;
// 记录最后一帧时间
mLastFrameTimeNanos = frameTimeNanos;
}
try {
Trace.traceBegin(Trace.TRACE_TAG_VIEW, "Choreographer#doFrame");
AnimationUtils.lockAnimationClock(frameTimeNanos / TimeUtils.NANOS_PER_MS);
2
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);
}
}注释1处
第一个 if 语句，不知道大家是否在自己项目的 Logcat 台遇到过这样一条日
Skipped （该值>=30） frames! The application may be doing too much work on its main thread注释2处
注意看方法的最后，按照类型顺序触发 doCallbacks 回调相关任务。
doCallbacks(Choreographer.CALLBACK_INPUT, frameTimeNanos);
doCallbacks(Choreographer.CALLBACK_ANIMATION, frameTimeNanos);
doCallbacks(Choreographer.CALLBACK_TRAVERSAL, frameTimeNanos);
doCallbacks(Choreographer.CALLBACK_COMMIT, frameTimeNanos);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;
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 方法。
回到 ViewRootImpl 发起的绘制任务，此时 View 的绘制流程便开始了
final class TraversalRunnable implements Runnable{
@Override
public void run(){
// View 的绘制任务开始
doTraversal();
}
}至此 Choreographer 的工作流程就已经分析清楚了，Choreographer 支持四种类型任务：输入、动画、绘制和提交，并配合系统的 VSYNC 进行刷新、绘制等流程。确实做到了统一协调管理。
大致流程总结如下：
常见的问题
1.丢帧一般是什么原因引起的？
答:主线程有耗时操作，耽误了view的绘制
2.Android刷新频率60帧/秒，每隔16ms调onDraw绘制一次？
答: 60帧/秒也是vsync信号的频率，但不一定每次vsync信号都会去绘制，先要应用端主动发起重绘，才会向SurfaceFlinger请求接收vsync信号，这样当vsync信号来的时候，才会真正去绘制。
3.onDraw执行完之后屏幕会马上刷新么？
答: 不会马上刷新，会等到下一次vsync信号时才会刷新。
4.如果界面没有重绘，还会每隔16ms刷新屏幕么？
答：界面没有重绘，应用就不会收的vsync信号，屏幕还是会刷新，画面数据用的是旧的，看起来没什么变化而已
5.如果屏幕快要刷新的时候才去onDraw绘制会丢帧么？
答: 重绘不会立即执行，而是等到下一次vsync信号来时才开始， 所以什么时候发起重绘影响不大
634
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
