2024年Android最全揭秘：Android屏幕中你不知道的刷新机制(1)，面试经历分享网站

最后

以前一直是自己在网上东平西凑的找，找到的东西也是零零散散，很多时候都是看着看着就没了，时间浪费了，问题却还没得到解决，很让人抓狂。

后面我就自己整理了一套资料，还别说，真香！

资料有条理，有系统，还很全面，我不方便直接放出来，大家可以先看看有没有用得到的地方吧。

网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。

需要这份系统化学习资料的朋友，可以戳这里获取

一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！

void scheduleTraversals() {
if (!mTraversalScheduled) {
mTraversalScheduled = true;
mTraversalBarrier = mHandler.getLooper().getQueue().postSyncBarrier();
mChoreographer.postCallback(
Choreographer.CALLBACK_TRAVERSAL, mTraversalRunnable, null);
if (!mUnbufferedInputDispatch) {
scheduleConsumeBatchedInput();
}
notifyRendererOfFramePending();
pokeDrawLockIfNeeded();
}
}
复制代码方法不长，首先如果mTraversalScheduled为false，进入判断，同时将此标志位置位true，第二句暂时不管，后续会讲到，主要看postCallback方法，传递进去了一个mTraversalRunnable对象，可以看到这里是一个请求绘制的Runnable对象
final class TraversalRunnable implements Runnable {
@Override
public void run() {
doTraversal();
}
}
void doTraversal() {
if (mTraversalScheduled) {
mTraversalScheduled = false;
mHandler.getLooper().getQueue().removeSyncBarrier(mTraversalBarrier);
if (mProfile) {
Debug.startMethodTracing(“ViewAncestor”);
}
performTraversals();
if (mProfile) {
Debug.stopMethodTracing();
mProfile = false;
}
}
}

doTraversal方法里面，又将mTraversalScheduled置位了false，对应上面的scheduleTraversals方法，可以看到一个是postSyncBarrier()，而在这里又是removeSyncBarrier()，这里其实涉及到一个很有意思的东西，叫同步屏障，等会会拉出来单独讲解，然后调用了performTraversals()，这个方法应该都知道了，View 的测量、布局、绘制都是在这个方法里面发起的，代码逻辑太多了，就不贴出来了，暂时只需要知道这个方法是发起测量的开始。

这里我们暂时总结一下，当子View调用invalidate的时候，最终是调用到ViewRootImpl的performTraversals()方法的，performTraversals()方法又是在doTraversal里面调用的，doTraversal又是封装在mTraversalRunnable之中的，那么这个Runnable的执行时机又在哪呢

###Choreographer##postCallback
回到上面的scheduleTraversals方法中，mTraversalRunnable是传递进了Choreographer的postCallback方法之中

private void postCallbackDelayedInternal(int callbackType,
Object action, Object token, long delayMillis) {
if (DEBUG_FRAMES) {
synchronized (mLock) {
final long now = SystemClock.uptimeMillis();
final long dueTime = now + delayMillis;
mCallbackQueues[callbackType].addCallbackLocked(dueTime, action, token);

if (dueTime <= now) {
scheduleFrameLocked(now);
} else {
Message msg = mHandler.obtainMessage(MSG_DO_SCHEDULE_CALLBACK, action);
msg.arg1 = callbackType;
msg.setAsynchronous(true);
mHandler.sendMessageAtTime(msg, dueTime);
}
}
}

可以看到内部好像有一个类似MessageQueue的东西，将Runnable通过delay时间给存储起来的，因为我们这里传递进来的delay是0，所以执行scheduleFrameLocked(now)方法

private void scheduleFrameLocked(long now) {
if (!mFrameScheduled) {
mFrameScheduled = true;
if (isRunningOnLooperThreadLocked()) {
scheduleVsyncLocked();
} else {
Message msg = mHandler.obtainMessage(MSG_DO_SCHEDULE_VSYNC);
msg.setAsynchronous(true);
mHandler.sendMessageAtFrontOfQueue(msg);
}
}
}
private boolean isRunningOnLooperThreadLocked() {
return Looper.myLooper() == mLooper;
}

这里有一个判断isRunningOnLooperThreadLocked，看着像是判断当前线程是否是主线程，如果是的话，调用scheduleVsyncLocked()方法，不是的话会发送一个MSG_DO_SCHEDULE_VSYNC消息，但是最终都会调用这个方法

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 {
  nativeScheduleVsync(mReceiverPtr);
  }
  }

如果mReceiverPtr不等于0的话，会去调用nativeScheduleVsync(mReceiverPtr)，这是个native方法，暂不跟踪到C++里面去了，看着英文方法像是一个安排信号的意思
之前是把CallBack存储在一个Queue之中了，那么必然有执行的方法

void doCallbacks(int callbackType, long frameTimeNanos) {
CallbackRecord callbacks;
synchronized (mLock) {
try {
Trace.traceBegin(Trace.TRACE_TAG_VIEW, CALLBACK_TRACE_TITLES[callbackType]);
for (CallbackRecord c = callbacks; c != null; c = c.next) {
if (DEBUG_FRAMES) {
Log.d(TAG, “RunCallback: type=” + callbackType

• “, action=” + c.action + “, token=” + c.token
• “, latencyMillis=” + (SystemClock.uptimeMillis() - c.dueTime));
  }
  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);
  }
  }

看一下这个方法在哪里调用的，走到了doFrame方法里面

void doFrame(long frameTimeNanos, int frame) {
final long startNanos;
synchronized (mLock) {
try {
…
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();
Trace.traceEnd(Trace.TRACE_TAG_VIEW);
}
…
}

那么这样一来，就找到关键的方法了：doFrame()，这个方法里会根据一个时间戳去队列里取任务出来执行，而这个任务就是 ViewRootImpl 封装起来的 doTraversal() 操作，而 doTraversal() 会去调用 performTraversals() 开始根据需要测量、布局、绘制整颗 View 树。所以剩下的问题就是 doFrame() 这个方法在哪里被调用了。

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) {
scheduleVsync();
return;
}
mTimestampNanos = timestampNanos;
mFrame = frame;
Message msg = Message.obtain(mHandler, this);
msg.setAsynchronous(true);
mHandler.sendMessageAtTime(msg, timestampNanos / TimeUtils.NANOS_PER_MS);
}
@Override
public void run() {
mHavePendingVsync = false;
doFrame(mTimestampNanos, mFrame);
}
}

可以看到，是在onVsync回调中，Message msg = Message.obtain(mHandler, this)，传入了this，然后会执行到run方法里面，自然也就执行了doFrame方法，所以最终问题也就来了，这个onVsync()这个是什么时候回调来的，这里查询了网上的一些资料，是这么解释的

FrameDisplayEventReceiver继承自DisplayEventReceiver接收底层的VSync信号开始处理UI过程。VSync信号由SurfaceFlinger实现并定时发送。FrameDisplayEventReceiver收到信号后，调用onVsync方法组织消息发送到主线程处理。这个消息主要内容就是run方法里面的doFrame了，这里mTimestampNanos是信号到来的时间参数。

那也就是说，onVsync是底层回调回来的，那也就是每16.6ms，底层会发出一个屏幕刷新的信号，然后会回调到onVsync方法之中，但是有一点很奇怪，底层怎么知道上层是哪个app需要这个信号来刷新呢，结合日常开发，要实现这种一般使用观察者模式，将app本身注册下去，但是好像也没有看到哪里有往底层注册的方法，对了，再次回到上面的那个native方法，nativeScheduleVsync(mReceiverPtr)，那么这个方法大体的作用也就是注册监听了，
###同步屏障
总结下上面的知识，我们调用了 invalidate()，requestLayout()，等之类刷新界面的操作时，并不是马上就会执行这些刷新的操作，而是通过 ViewRootImpl 的 scheduleTraversals() 先向底层注册监听下一个屏幕刷新信号事件，然后等下一个屏幕刷新信号来的时候，才会去通过 performTraversals() 遍历绘制 View 树来执行这些刷新操作。

那么这样是不是产生一个问题，因为我们知道，平常Handler发送的消息都是同步消息的，也就是Looper会从MessageQueue中不断去取Message对象，一个Message处理完了之后，再去取下一个Message，那么绘制的这个Message如何尽量保证能够在16.6ms之内执行到呢，

这里就使用到了一个同步屏障的东西，再次回到scheduleTraversals代码

void scheduleTraversals() {
if (!mTraversalScheduled) {
mTraversalScheduled = true;
mTraversalBarrier = mHandler.getLooper().getQueue().postSyncBarrier();
mChoreographer.postCallback(
Choreographer.CALLBACK_TRAVERSAL, mTraversalRunnable, null);
if (!mUnbufferedInputDispatch) {
scheduleConsumeBatchedInput();
}
notifyRendererOfFramePending();
pokeDrawLockIfNeeded();
}
}

mHandler.getLooper().getQueue().postSyncBarrier()，这一句上面没有分析，进入到方法里

private int postSyncBarrier(long when) {
synchronized (this) {
final int token = mNextBarrierToken++;
final Message msg = Message.obtain();
msg.markInUse();
msg.when = when;
msg.arg1 = token;
Message prev = null;
Message p = mMessages;
if (when != 0) {
while (p != null && p.when <= when) {
prev = p;
p = p.next;
}
}
if (prev != null) { // invariant: p == prev.next
msg.next = p;
prev.next = msg;
} else {
msg.next = p;
mMessages = msg;
}
return token;

更多Android高级工程师进阶学习资料

进阶学习视频

附上：我们之前因为秋招收集的二十套一二线互联网公司Android面试真题（含BAT、小米、华为、美团、滴滴）和我自己整理Android复习笔记（包含Android基础知识点、Android扩展知识点、Android源码解析、设计模式汇总、Gradle知识点、常见算法题汇总。）

里面包含不同方向的自学编程路线、面试题集合/面经、及系列技术文章等，资源持续更新中…

网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。

需要这份系统化学习资料的朋友，可以戳这里获取

一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！

程路线、面试题集合/面经、及系列技术文章等，资源持续更新中…**

网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。

需要这份系统化学习资料的朋友，可以戳这里获取

一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！