從UI控件內(nèi)容更改到被重新繪制到屏幕上拍顷，這中間到底經(jīng)歷了什么谍失？另外结澄，連續(xù)兩次setTextView到底會觸發(fā)幾次UI重繪呢朴沿？為什么Android APP的幀率最高是60FPS呢，這就是本文要討論的內(nèi)容授艰。
以電影為例辨嗽，動畫至少要達到24FPS，才能保證畫面的流暢性淮腾，低于這個值糟需，肉眼會感覺到卡頓。在手機上谷朝，這個值被調(diào)整到60FPS洲押，增加絲滑度，這也是為什么有個（1000/60）16ms的指標圆凰，一般而言目前的Android系統(tǒng)最高FPS也就是60杈帐，它是通過了一個VSYNC來保證每16ms最多繪制一幀。簡而言之：UI必須至少等待16ms的間隔才會繪制下一幀专钉，所以連續(xù)兩次setTextView只會觸發(fā)一次重繪挑童。下面來具體看一下UI的重繪流程。
UI刷新流程示意
以Textview為例 跃须，當(dāng)我們通過setText改變TextView內(nèi)容后站叼，UI界面不會立刻改變，APP端會先向VSYNC服務(wù)請求菇民，等到下一次VSYNC信號觸發(fā)后尽楔，APP端的UI才真的開始刷新，基本流程如下
從我們的代碼端來看如下：setText最終調(diào)用invalidate申請重繪玉雾，最后會通過ViewParent遞歸到ViewRootImpl的invalidate翔试，請求VSYNC，在請求VSYNC的時候复旬，會添加一個同步柵欄垦缅，防止UI線程中同步消息執(zhí)行，這樣做為了加快VSYNC的響應(yīng)速度驹碍，如果不設(shè)置壁涎，VSYNC到來的時候凡恍，正在執(zhí)行一個同步消息，那么UI更新的Task就會被延遲執(zhí)行怔球，這是Android的Looper跟MessageQueue決定的嚼酝。
APP端觸發(fā)重繪，申請VSYNC流程示意
等到VSYNC到來后竟坛，會移除同步柵欄闽巩，并率先開始執(zhí)行當(dāng)前幀的處理，調(diào)用邏輯如下
VSYNC回來流程示意
doFrame執(zhí)行UI繪制的示意圖
UI刷新源碼跟蹤
同TextView類似担汤，View內(nèi)容改變一般都會調(diào)用invalidate觸發(fā)視圖重繪涎跨，這中間經(jīng)歷了什么呢？View會遞歸的調(diào)用父容器的invalidateChild崭歧，逐級回溯隅很，最終走到ViewRootImpl的invalidate，如下：
View.java
void invalidateInternal(int l, int t, int r, int b, boolean invalidateCache,
boolean fullInvalidate) {
// Propagate the damage rectangle to the parent view.
final AttachInfo ai = mAttachInfo;
final ViewParent p = mParent;
if (p != null && ai != null && l < r && t < b) {
final Rect damage = ai.mTmpInvalRect;
damage.set(l, t, r, b);
p.invalidateChild(this, damage);
}
ViewRootImpl.java
void invalidate() {
mDirty.set(0, 0, mWidth, mHeight);
if (!mWillDrawSoon) {
scheduleTraversals();
}
}
ViewRootImpl會調(diào)用scheduleTraversals準備重繪率碾，但是叔营，重繪一般不會立即執(zhí)行，而是往Choreographer的Choreographer.CALLBACK_TRAVERSAL隊列中添加了一個mTraversalRunnable所宰，同時申請VSYNC绒尊，這個mTraversalRunnable要一直等到申請的VSYNC到來后才會被執(zhí)行，如下：
ViewRootImpl.java
// 將UI繪制的mTraversalRunnable加入到下次垂直同步信號到來的等待callback中去
// mTraversalScheduled用來保證本次Traversals未執(zhí)行前歧匈，不會要求遍歷兩邊垒酬，浪費16ms內(nèi)砰嘁，不需要繪制兩次
void scheduleTraversals() {
if (!mTraversalScheduled) {
mTraversalScheduled = true;
// 防止同步柵欄件炉，同步柵欄的意思就是攔截同步消息
mTraversalBarrier = mHandler.getLooper().getQueue().postSyncBarrier();
// postCallback的時候，順便請求vnsc垂直同步信號scheduleVsyncLocked
mChoreographer.postCallback(
Choreographer.CALLBACK_TRAVERSAL, mTraversalRunnable, null);
<!--添加一個處理觸摸事件的回調(diào)矮湘，防止中間有Touch事件過來-->
if (!mUnbufferedInputDispatch) {
scheduleConsumeBatchedInput();
}
notifyRendererOfFramePending();
pokeDrawLockIfNeeded();
}
}
Choreographer.java
private void postCallbackDelayedInternal(int callbackType,
Object action, Object token, long delayMillis) {
synchronized (mLock) {
final long now = SystemClock.uptimeMillis();
final long dueTime = now + delayMillis;
mCallbackQueues[callbackType].addCallbackLocked(dueTime, action, token);
if (dueTime <= now) {
<!--申請VSYNC同步信號-->
scheduleFrameLocked(now);
}
}
}
scheduleTraversals利用mTraversalScheduled保證斟冕，在當(dāng)前的mTraversalRunnable未被執(zhí)行前，scheduleTraversals不會再被有效調(diào)用缅阳，也就是Choreographer.CALLBACK_TRAVERSAL理論上應(yīng)該只有一個mTraversalRunnable的Task磕蛇。mChoreographer.postCallback將mTraversalRunnable插入到CallBack之后，會接著調(diào)用scheduleFrameLocked請求Vsync同步信號
// mFrameScheduled保證16ms內(nèi)十办，只會申請一次垂直同步信號
// scheduleFrameLocked可以被調(diào)用多次秀撇，但是mFrameScheduled保證下一個vsync到來之前，不會有新的請求發(fā)出
// 多余的scheduleFrameLocked調(diào)用被無效化
private void scheduleFrameLocked(long now) {
if (!mFrameScheduled) {
mFrameScheduled = true;
if (USE_VSYNC) {
if (isRunningOnLooperThreadLocked()) {
scheduleVsyncLocked();
} else {
// 因為invalid已經(jīng)有了同步柵欄向族，所以必須mFrameScheduled呵燕，消息才能被UI線程執(zhí)行
Message msg = mHandler.obtainMessage(MSG_DO_SCHEDULE_VSYNC);
msg.setAsynchronous(true);
mHandler.sendMessageAtFrontOfQueue(msg);
}
}
}
}
scheduleFrameLocked跟上一個scheduleTraversals類似，也采用了利用mFrameScheduled來保證：在當(dāng)前申請的VSYNC到來之前件相，不會再去請求新的VSYNC再扭，因為16ms內(nèi)申請兩個VSYNC沒意義氧苍。再VSYNC到來之后，Choreographer利用Handler將FrameDisplayEventReceiver封裝成一個異步Message泛范，發(fā)送到UI線程的MessageQueue让虐，
private final class FrameDisplayEventReceiver extends DisplayEventReceiver
implements Runnable {
private boolean mHavePendingVsync;
private long mTimestampNanos;
private int mFrame;
public FrameDisplayEventReceiver(Looper looper) {
super(looper);
}
@Override
public void onVsync(long timestampNanos, int builtInDisplayId, int frame) {
long now = System.nanoTime();
if (timestampNanos > now) {
<!--正常情況，timestampNanos不應(yīng)該大于now罢荡，一般是上傳vsync的機制出了問題-->
timestampNanos = now;
}
<!--如果上一個vsync同步信號沒執(zhí)行赡突，那就不應(yīng)該相應(yīng)下一個（可能是其他線程通過某種方式請求的）-->
if (mHavePendingVsync) {
Log.w(TAG, "Already have a pending vsync event. There should only be "
+ "one at a time.");
} else {
mHavePendingVsync = true;
}
<!--timestampNanos其實是本次vsync產(chǎn)生的時間，從服務(wù)端發(fā)過來-->
mTimestampNanos = timestampNanos;
mFrame = frame;
Message msg = Message.obtain(mHandler, this);
<!--由于已經(jīng)存在同步柵欄区赵，所以VSYNC到來的Message需要作為異步消息發(fā)送過去-->
msg.setAsynchronous(true);
mHandler.sendMessageAtTime(msg, timestampNanos / TimeUtils.NANOS_PER_MS);
}
@Override
public void run() {
mHavePendingVsync = false;
<!--這里的mTimestampNanos其實就是本次Vynsc同步信號到來的時候麸俘，但是執(zhí)行這個消息的時候，可能延遲了-->
doFrame(mTimestampNanos, mFrame);
}
}
之所以封裝成異步Message惧笛，是因為前面添加了一個同步柵欄从媚，同步消息不會被執(zhí)行。UI線程被喚起患整，取出該消息拜效，最終調(diào)用doFrame進行UI刷新重繪
void doFrame(long frameTimeNanos, int frame) {
final long startNanos;
synchronized (mLock) {
<!--做了很多東西，都是為了保證一次16ms有一次垂直同步信號各谚，有一次input 紧憾、刷新、重繪-->
if (!mFrameScheduled) {
return; // no work to do
}
long intendedFrameTimeNanos = frameTimeNanos;
startNanos = System.nanoTime();
final long jitterNanos = startNanos - frameTimeNanos;
<!--檢查是否因為延遲執(zhí)行掉幀昌渤，每大于16ms赴穗，就多掉一幀-->
if (jitterNanos >= mFrameIntervalNanos) {
final long skippedFrames = jitterNanos / mFrameIntervalNanos;
<!--跳幀，其實就是上一次請求刷新被延遲的時間膀息，但是這里skippedFrames為0不代表沒有掉幀-->
if (skippedFrames >= SKIPPED_FRAME_WARNING_LIMIT) {
<!--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的機制出現(xiàn)了問題潜支，那就再申請一次-->
scheduleVsyncLocked();
return;
}
<!--intendedFrameTimeNanos是本來要繪制的時間戳甸赃，frameTimeNanos是真正的，可以在渲染工具中標識延遲VSYNC多少-->
mFrameInfo.setVsync(intendedFrameTimeNanos, frameTimeNanos);
<!--移除mFrameScheduled判斷冗酿，說明處理開始了埠对，-->
mFrameScheduled = false;
<!--更新mLastFrameTimeNanos-->
mLastFrameTimeNanos = frameTimeNanos;
}
try {
<!--真正開始處理業(yè)務(wù)-->
Trace.traceBegin(Trace.TRACE_TAG_VIEW, "Choreographer#doFrame");
<!--處理打包的move事件-->
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 {
Trace.traceEnd(Trace.TRACE_TAG_VIEW);
}
}
doFrame也采用了一個boolean遍歷mFrameScheduled保證每次VSYNC中，只執(zhí)行一次裁替，可以看到项玛，為了保證16ms只執(zhí)行一次重繪，加了好多次層保障弱判。doFrame里除了UI重繪襟沮，其實還處理了很多其他的事，比如檢測VSYNC被延遲多久執(zhí)行，掉了多少幀臣嚣，處理Touch事件（一般是MOVE）净刮，處理動畫，以及UI硅则，當(dāng)doFrame在處理Choreographer.CALLBACK_TRAVERSAL的回調(diào)時（mTraversalRunnable）淹父，才是真正的開始處理View重繪：
final class TraversalRunnable implements Runnable {
@Override
public void run() {
doTraversal();
}
}
回到ViewRootImpl調(diào)用doTraversal進行View樹遍歷，
// 這里是真正執(zhí)行了怎虫，
void doTraversal() {
if (mTraversalScheduled) {
mTraversalScheduled = false;
<!--移除同步柵欄暑认，只有重繪才設(shè)置了柵欄，說明重繪的優(yōu)先級還是挺高的大审，所有的同步消息必須讓步-->
mHandler.getLooper().getQueue().removeSyncBarrier(mTraversalBarrier);
performTraversals();
}
}
doTraversal會先將柵欄移除蘸际，然后處理performTraversals，進行測量徒扶、布局粮彤、繪制，提交當(dāng)前幀給SurfaceFlinger進行圖層合成顯示姜骡。以上多個boolean變量保證了每16ms最多執(zhí)行一次UI重繪导坟，這也是目前Android存在60FPS上限的原因。
注： VSYNC同步信號需要用戶主動去請求才會收到圈澈，并且是單次有效惫周。
UI局部重繪
某一個View重繪刷新，并不會導(dǎo)致所有View都進行一次measure康栈、layout递递、draw，只是這個待刷新View鏈路需要調(diào)整啥么，剩余的View可能不需要浪費精力再來一遍登舞，反應(yīng)再APP側(cè)就是：不需要再次調(diào)用所有ViewupdateDisplayListIfDirty構(gòu)建RenderNode渲染Op樹，如下
View.java
public RenderNode updateDisplayListIfDirty() {
final RenderNode renderNode = mRenderNode;
...
if ((mPrivateFlags & PFLAG_DRAWING_CACHE_VALID) == 0
|| !renderNode.isValid()
|| (mRecreateDisplayList)) {
<!--失效了饥臂，需要重繪-->
} else {
<!--依舊有效逊躁，無需重繪-->
mPrivateFlags |= PFLAG_DRAWN | PFLAG_DRAWING_CACHE_VALID;
mPrivateFlags &= ~PFLAG_DIRTY_MASK;
}
return renderNode;
}
總結(jié)
- android最高60FPS，是VSYNC及決定的隅熙，每16ms最多一幀
- VSYNC要客戶端主動申請，才會有
- 有VSYNC到來才會刷新
- UI沒更改核芽，不會請求VSYNC也就不會刷新
- UI局部重繪其實只是省去了再次構(gòu)建硬件加速用的DrawOp樹（復(fù)用上衣幀的）
作者：看書的小蝸牛
Android VSYNC （Choreographer）與UI刷新原理分析.md
僅供參考囚戚，歡迎指正
