概述 在我們在進行自定義View的相關開發中,當我們更改了當前View的狀態,比如大小,位置等,我們需要重新刷新整個界面,保證顯示最新的狀態。在Android中,讓當前的視圖重繪有兩種方式,invalidate和requestLayout,今天我們看看這兩種方式的原理以及區別。 分析 invalid ...
概述
在我們在進行自定義View的相關開發中,當我們更改了當前View的狀態,比如大小,位置等,我們需要重新刷新整個界面,保證顯示最新的狀態。在Android中,讓當前的視圖重繪有兩種方式,invalidate和requestLayout,今天我們看看這兩種方式的原理以及區別。
分析
invalidate的原理
public void invalidate() { invalidate(true); }
最後會調用到invalidateInternal這個方法
1 void invalidateInternal(int l, int t, int r, int b, boolean invalidateCache, 2 boolean fullInvalidate) { 3 if (mGhostView != null) { 4 mGhostView.invalidate(true); 5 return; 6 } 7 8 if (skipInvalidate()) { 9 return; 10 } 11 12 if ((mPrivateFlags & (PFLAG_DRAWN | PFLAG_HAS_BOUNDS)) == (PFLAG_DRAWN | PFLAG_HAS_BOUNDS) 13 || (invalidateCache && (mPrivateFlags & PFLAG_DRAWING_CACHE_VALID) == PFLAG_DRAWING_CACHE_VALID) 14 || (mPrivateFlags & PFLAG_INVALIDATED) != PFLAG_INVALIDATED 15 || (fullInvalidate && isOpaque() != mLastIsOpaque)) { 16 if (fullInvalidate) { 17 mLastIsOpaque = isOpaque(); 18 mPrivateFlags &= ~PFLAG_DRAWN; 19 } 20 21 mPrivateFlags |= PFLAG_DIRTY; 22 23 if (invalidateCache) { 24 mPrivateFlags |= PFLAG_INVALIDATED; 25 mPrivateFlags &= ~PFLAG_DRAWING_CACHE_VALID; 26 } 27 28 // Propagate the damage rectangle to the parent view. 29 final AttachInfo ai = mAttachInfo; 30 final ViewParent p = mParent; 31 if (p != null && ai != null && l < r && t < b) { 32 final Rect damage = ai.mTmpInvalRect; 33 damage.set(l, t, r, b); 34 p.invalidateChild(this, damage); 35 } 36 .....
我們看到方法的最後調用了ViewParent的invalidateChild方法,因為ViewParent是個介面,invalidateChild是空實現,我們去看看它的實現類ViewRootImpl中的invalidateChild是如何做的
@Override public void invalidateChild(View child, Rect dirty) { invalidateChildInParent(null, dirty); }
1 @Override 2 public ViewParent invalidateChildInParent(int[] location, Rect dirty) { 3 checkThread(); 4 if (DEBUG_DRAW) Log.v(TAG, "Invalidate child: " + dirty); 5 6 if (dirty == null) { 7 invalidate(); 8 return null; 9 } else if (dirty.isEmpty() && !mIsAnimating) { 10 return null; 11 } 12 13 if (mCurScrollY != 0 || mTranslator != null) { 14 mTempRect.set(dirty); 15 dirty = mTempRect; 16 if (mCurScrollY != 0) { 17 dirty.offset(0, -mCurScrollY); 18 } 19 if (mTranslator != null) { 20 mTranslator.translateRectInAppWindowToScreen(dirty); 21 } 22 if (mAttachInfo.mScalingRequired) { 23 dirty.inset(-1, -1); 24 } 25 } 26 27 invalidateRectOnScreen(dirty); 28 29 return null; 30 }
又會調用ViewRootImpl中的invalidate方法
void invalidate() { mDirty.set(0, 0, mWidth, mHeight); if (!mWillDrawSoon) { scheduleTraversals(); } }
這裡調用了scheduleTraversals重新開始了View的繪製,我們知道View的繪製是從ViewRootImpl的performTraversals方法開始的。我們看看scheduleTraversals是不是觸發了performTraversals。
void scheduleTraversals() { if (!mTraversalScheduled) { mTraversalScheduled = true; mTraversalBarrier = mHandler.getLooper().getQueue().postSyncBarrier(); mChoreographer.postCallback( Choreographer.CALLBACK_TRAVERSAL, mTraversalRunnable, null); if (!mUnbufferedInputDispatch) { scheduleConsumeBatchedInput(); } notifyRendererOfFramePending(); pokeDrawLockIfNeeded(); } }
在scheduleTraversals方法中我們發現了一個mTraversalRunnable對象,這個對象就是我們要觀察的重點
final class TraversalRunnable implements Runnable { @Override public void run() { doTraversal(); } } final TraversalRunnable mTraversalRunnable = new TraversalRunnable();
我們發現這個對象就是一個Runnable對象,我們在scheduleTraversals方法中傳入mTraversalRunnable 就會執行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方法中調用了performTraversals開始了View的重新繪製,這就是invalidate的整個過程。
requestLayout的原理
public void requestLayout() { if (mMeasureCache != null) mMeasureCache.clear(); if (mAttachInfo != null && mAttachInfo.mViewRequestingLayout == null) { // Only trigger request-during-layout logic if this is the view requesting it, // not the views in its parent hierarchy ViewRootImpl viewRoot = getViewRootImpl(); if (viewRoot != null && viewRoot.isInLayout()) { if (!viewRoot.requestLayoutDuringLayout(this)) { return; } } mAttachInfo.mViewRequestingLayout = this; } mPrivateFlags |= PFLAG_FORCE_LAYOUT; mPrivateFlags |= PFLAG_INVALIDATED; if (mParent != null && !mParent.isLayoutRequested()) { mParent.requestLayout(); } if (mAttachInfo != null && mAttachInfo.mViewRequestingLayout == this) { mAttachInfo.mViewRequestingLayout = null; } }
其中會調用ViewParent的requestLayout方法,同樣,我們去看ViewRootImpl中的requestLayout方法。
Override public void requestLayout() { if (!mHandlingLayoutInLayoutRequest) { checkThread(); mLayoutRequested = true; scheduleTraversals(); } }
這裡調用了scheduleTraversals,後面的步驟就和上面invalidate時一樣了。相對來說,requestLayout的流程還是比較簡單的。
區別
既然兩種方式都可以完成View的重繪,那麼有什麼區別呢?
使用invalidate重繪當前視圖是不會再次執行measure和layout流程的。因為視圖沒有強制重新測量的標誌位,而且大小也沒有發生過變化,所以這時只有draw流程可以得到執行。
如果你希望視圖的繪製流程可以完完整整地重新走一遍,就不能使用invalidate()方法,而應該調用requestLayout()了