一刽脖、概述
經(jīng)過前面三篇文章的分析：
對于繪制的整個分發(fā)過程已經(jīng)有了一個大致的了解畔塔，我們可以發(fā)現(xiàn)一個規(guī)律恼琼，無論是測量掩浙、布局還是繪制，對于任何一個View/Group來說萄喳，它都是一個至上而下的遞歸事件調(diào)用芬骄，直到到達整個View樹的葉節(jié)點為止猾愿。
下面，我們來分析幾個平時常用的方法：
requestLayoutinvalidatepostInvalidate
二德玫、requestLayout
requestLayout是在View中定義的匪蟀，并且在ViewGroup中沒有重寫該方法，它的注釋是這樣解釋的：在需要刷新View的布局時調(diào)用這個函數(shù)宰僧，它會安排一個布局的傳遞材彪。我們不應(yīng)該在布局的過程中（isInLayout()）調(diào)用這個函數(shù)观挎，如果當前正在布局，那么這一請求有可能在以下時刻被執(zhí)行：當前布局結(jié)束段化、當前幀被繪制完或者下次布局發(fā)生時嘁捷。
/**
* Call this when something has changed which has invalidated the
* layout of this view. This will schedule a layout pass of the view
* tree. This should not be called while the view hierarchy is currently in a layout
* pass ({@link #isInLayout()}. If layout is happening, the request may be honored at the
* end of the current layout pass (and then layout will run again) or after the current
* frame is drawn and the next layout occurs.
*
* <p>Subclasses which override this method should call the superclass method to
* handle possible request-during-layout errors correctly.</p>
*/
@CallSuper
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;
}
}
在上面的代碼當中，設(shè)置了兩個標志位：PFLAG_FORCE_LAYOUT/PFLAG_INVALIDATED显熏，除此之外最關(guān)鍵的一句話是：
protected ViewParent mParent;
//....
mParent.requestLayout();
這個mParent存儲的時候該View所對應(yīng)的父節(jié)點雄嚣，而當調(diào)用父節(jié)點的requestLayout()時，它又會調(diào)用它的父節(jié)點的requestLayout喘蟆，就這樣缓升，以調(diào)用requestLayout的View為起始節(jié)點，一步步沿著View樹傳遞上去蕴轨，那么這個過程什么時候會終止呢港谊？
根據(jù)前面的分析，我們知道整個View樹的根節(jié)點是DecorView橙弱，那么我們需要看一下DecorView的mParent變量是什么歧寺，回到ViewRootImpl的setView方法當中，有這么一句：
view.assignParent(this);
因此棘脐，DecorView中的mParent就是ViewRootImpl斜筐，而ViewRootImpl中的mView就是DecorView，所以蛀缝，這一傳遞過程的終點就是ViewRootImpl的requestLayout方法：
//ViewRootImpl中的requestLayout方法.
@Override
public void requestLayout() {
if (!mHandlingLayoutInLayoutRequest) {
checkThread();
mLayoutRequested = true;
scheduleTraversals();
}
}
void scheduleTraversals() {
if (!mTraversalScheduled) {
mTraversalScheduled = true;
mTraversalBarrier = mHandler.getLooper().getQueue().postSyncBarrier();
//該Runnable進行操作doTraversal.
mChoreographer.postCallback(Choreographer.CALLBACK_TRAVERSAL, mTraversalRunnable, null);
if (!mUnbufferedInputDispatch) {
scheduleConsumeBatchedInput();
}
notifyRendererOfFramePending();
pokeDrawLockIfNeeded();
}
}
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;
}
}
}
其中scheduleTraversals()中會執(zhí)行一個mTraversalRunnable顷链，該Runnable中最終會調(diào)用doTraversal，而doTraversal中執(zhí)行的就是我們前面一直在談到的performTraversals屈梁。
那么蕴潦，前面我們分析過，performTraversals的measure方法會從根節(jié)點調(diào)用子節(jié)點的測量操作俘闯，并依次傳遞下去，那么是否所有的子View都有必要重新測量呢忽冻，這就需要我們在調(diào)用View的requestLayout是設(shè)置的標志位PFLAG_FORCE_LAYOUT來判斷真朗，在measure當中，調(diào)用onMeasure之前僧诚，會有這么一個判斷條件：
if ((mPrivateFlags & PFLAG_FORCE_LAYOUT) == PFLAG_FORCE_LAYOUT ||
widthMeasureSpec != mOldWidthMeasureSpec ||
heightMeasureSpec != mOldHeightMeasureSpec) {
onMeasure(widthMeasureSpec, heightMeasureSpec);
}
這個標志位會在layout完成之后被恢復(fù)：
public void layout(int l, int t, int r, int b) {
if (changed || (mPrivateFlags & PFLAG_LAYOUT_REQUIRED) == PFLAG_LAYOUT_REQUIRED) {
onLayout(changed, l, t, r, b);
}
mPrivateFlags &= ~PFLAG_FORCE_LAYOUT;
mPrivateFlags3 |= PFLAG3_IS_LAID_OUT;
}
在進行完layout之后遮婶，requestLayout()所引發(fā)的過程就此終止了，它不會調(diào)用draw湖笨，不會重新繪制任何視圖包括該調(diào)用者本身旗扑。
三、invalidate
invalidate最終會調(diào)用到下面這個方法：
void invalidateInternal(int l, int t, int r, int b, boolean invalidateCache,
boolean fullInvalidate) {
if (mGhostView != null) {
mGhostView.invalidate(true);
return;
}
if (skipInvalidate()) {
return;
}
if ((mPrivateFlags & (PFLAG_DRAWN | PFLAG_HAS_BOUNDS)) == (PFLAG_DRAWN | PFLAG_HAS_BOUNDS)
|| (invalidateCache && (mPrivateFlags & PFLAG_DRAWING_CACHE_VALID) == PFLAG_DRAWING_CACHE_VALID)
|| (mPrivateFlags & PFLAG_INVALIDATED) != PFLAG_INVALIDATED
|| (fullInvalidate && isOpaque() != mLastIsOpaque)) {
if (fullInvalidate) {
mLastIsOpaque = isOpaque();
mPrivateFlags &= ~PFLAG_DRAWN;
}
mPrivateFlags |= PFLAG_DIRTY;
if (invalidateCache) {
mPrivateFlags |= PFLAG_INVALIDATED;
mPrivateFlags &= ~PFLAG_DRAWING_CACHE_VALID;
}
// 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);
}
// Damage the entire projection receiver, if necessary.
if (mBackground != null && mBackground.isProjected()) {
final View receiver = getProjectionReceiver();
if (receiver != null) {
receiver.damageInParent();
}
}
// Damage the entire IsolatedZVolume receiving this view's shadow.
if (isHardwareAccelerated() && getZ() != 0) {
damageShadowReceiver();
}
}
}
其中慈省，關(guān)鍵的一句是：
p.invalidateChild(this, damage);
在這里臀防，p一定不為空并且它一定是一個ViewGroup，那么我們來看一下ViewGroup的這個方法：
public final void invalidateChild(View child, final Rect dirty) {
do {
parent = parent.invalidateChildInParent(location, dirty);
} while (parent != null);
}
而ViewGroup當中的invalidateChildInParent會根據(jù)傳入的區(qū)域來決定自己的繪制區(qū)域，和requestLayout類似袱衷，最終會調(diào)用ViewRootImpl的該方法：
@Override
public ViewParent invalidateChildInParent(int[] location, Rect dirty) {
checkThread();
if (DEBUG_DRAW) Log.v(TAG, "Invalidate child: " + dirty);
if (dirty == null) {
invalidate();
return null;
} else if (dirty.isEmpty() && !mIsAnimating) {
return null;
}
if (mCurScrollY != 0 || mTranslator != null) {
mTempRect.set(dirty);
dirty = mTempRect;
if (mCurScrollY != 0) {
dirty.offset(0, -mCurScrollY);
}
if (mTranslator != null) {
mTranslator.translateRectInAppWindowToScreen(dirty);
}
if (mAttachInfo.mScalingRequired) {
dirty.inset(-1, -1);
}
}
invalidateRectOnScreen(dirty);
return null;
}
這其中又會調(diào)用invalidate：
void invalidate() {
mDirty.set(0, 0, mWidth, mHeight);
if (!mWillDrawSoon) {
scheduleTraversals();
}
}
這里捎废，最終又會走到前面說的performTraversals()方法，請求重繪View樹致燥，即draw()過程登疗，假如視圖發(fā)生大小沒有變化就不會調(diào)用layout()過程，并且只繪制那些需要重繪的視圖嫌蚤。
三辐益、其它知識點
-
invalidate，請求重新draw脱吱，只會繪制調(diào)用者本身智政。 -
setSelection，同上急凰。 -
setVisibility：當View從INVISIBLE變?yōu)?code>VISIBILE女仰，會間接調(diào)用invalidate方法，繼而繪制該View抡锈，而從INVISIBLE/VISIBLE變?yōu)?code>GONE之后疾忍，由于View樹的大小發(fā)生了變化，會進行measure/layout/draw床三，同樣一罩，他只會繪制需要重繪的視圖。 -
setEnable：請求重新draw撇簿，只會繪制調(diào)用者本身聂渊。 -
requestFocus：請求重新draw，只會繪制需要重繪的視圖四瘫。
四汉嗽、參考文獻
1.http://blog.csdn.net/yanbober/article/details/46128379/
2.http://blog.csdn.net/a553181867/article/details/51583060
