從源碼看invalidate和requestLayout的區別
invalidate和requestLayout經常被用來刷新界面，有的時候2個一起用，TextView的源碼裏也經常看到2者一起用的情況。什麼時候該用哪個呢？爲什麼有的時候2個要一起用呢？
本文所從源碼是6.0.1來研究下2者的原理和區別以及如何使用。測試工程InvalidateDemo
Invalidate
PFLAG_DRAWING_CACHE_VALID、PFLAG_INVALIDATED
這裏我們要注意view的2個flag，一個是PFLAG_INVALIDATED，一個是PFLAG_DRAWING_CACHE_VALID。
/**
* Indicates that this view was specifically invalidated, not just dirtied because some
* child view was invalidated. The flag is used to determine when we need to recreate
* a view's display list (as opposed to just returning a reference to its existing
* display list).
*
* @hide
*/
static final int PFLAG_INVALIDATED = 0x80000000;看起來好像，子view invalidate就會導致父view PFLAG_INVALIDATED，但是我實際試了下，子view invalidate只會導致子view PFLAG_INVALIDATED，父view的PFLAG_INVALIDATED不會被設置。
而PFLAG_DRAWING_CACHE_VALID代表drawing_cache有效了，這個纔是其中某個子view invalidate了，一個子view invalidate會導致父view的PFLAG_DRAWING_CACHE_VALID被置0，父view的父view也會PFLAG_DRAWING_CACHE_VALID被置爲0，後文會分析。
Invalidate具體分析
先來看看invalidate方法，這是view的一個方法，一般我們想更新某個view會調用此方法.我們都知道view的invalidate會導致這個view被重新繪製，這個是怎麼實現的呢？
我們知道invalidate會導致ViewRootImpl的peformDraw被調用，那怎麼保證不繪製所有的view，而只繪製某個view呢？大概流程圖如下所示
step1.invalidateInternal
大概流程如上面的圖所展示的，View的invalidate會調到invalidateInternal，裏面會在L7設置2個標誌位PFLAG_INVALIDATED和PFLAG_DRAWING_CACHE_VALID，PFLAG_INVALIDATED置爲1，PFLAG_DRAWING_CACHE_VALID置爲0. 並且調用invalidateChild（L17）。代碼如下。
void invalidateInternal(int l, int t, int r, int b, boolean invalidateCache,
boolean fullInvalidate) {
。。。。
mPrivateFlags |= PFLAG_DIRTY;
//invalidateCache一般爲true
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();
}
}
}step2.invalidateChildInParent
invalidateChild內部有個dowhile循環，不停調用父view的invalidateChildInParent，一直到調用ViewRootImpl的invalidateChildInParent。我們看invalidateChild的L21，把PFLAG_DRAWING_CACHE_VALID置爲0，在dowhile循環後，當前view的所有父view，父view的父view。。。都會被PFLAG_DRAWING_CACHE_VALID置爲0.調用invalidateChildInParent會傳進去一個Rect叫dirty，代表子窗口需要刷新的rect，父窗口會根據這個rect和父窗口本身做union，從而得到父窗口需要刷新的rect區域，然後再傳給父窗口的父窗口，一直遞歸直到ViewRootImpl
public ViewParent invalidateChildInParent(final int[] location, final Rect dirty) {
if ((mPrivateFlags & PFLAG_DRAWN) == PFLAG_DRAWN ||
(mPrivateFlags & PFLAG_DRAWING_CACHE_VALID) == PFLAG_DRAWING_CACHE_VALID) {
if ((mGroupFlags & (FLAG_OPTIMIZE_INVALIDATE | FLAG_ANIMATION_DONE)) !=
FLAG_OPTIMIZE_INVALIDATE) {
dirty.offset(location[CHILD_LEFT_INDEX] - mScrollX,
location[CHILD_TOP_INDEX] - mScrollY);
if ((mGroupFlags & FLAG_CLIP_CHILDREN) == 0) {
dirty.union(0, 0, mRight - mLeft, mBottom - mTop);
}
final int left = mLeft;
final int top = mTop;
if ((mGroupFlags & FLAG_CLIP_CHILDREN) == FLAG_CLIP_CHILDREN) {
if (!dirty.intersect(0, 0, mRight - left, mBottom - top)) {
dirty.setEmpty();
}
}
//此處抹掉PFLAG_DRAWING_CACHE_VALID
mPrivateFlags &= ~PFLAG_DRAWING_CACHE_VALID;
location[CHILD_LEFT_INDEX] = left;
location[CHILD_TOP_INDEX] = top;
if (mLayerType != LAYER_TYPE_NONE) {
mPrivateFlags |= PFLAG_INVALIDATED;
}
return mParent;
} else {
...
}
}
return null;
}而ViewRootImpl的invalidateChildInParent內部調用而invalidateRectOnScreen進而調用scheduleTraversals。
step3. scheduleTraversals
scheduleTraversals一般都會調用performDraw進而調draw，在draw內，如果發現mDirty非空就會調mAttachInfo.mHardwareRenderer.draw(mView, mAttachInfo, this);
這是ThreadedRenderer內的方法了，裏面會調updateRootDisplayList進而調updateViewTreeDisplayList。
private void updateViewTreeDisplayList(View view) {
view.mPrivateFlags |= View.PFLAG_DRAWN;
view.mRecreateDisplayList = (view.mPrivateFlags & View.PFLAG_INVALIDATED)
== View.PFLAG_INVALIDATED;
view.mPrivateFlags &= ~View.PFLAG_INVALIDATED;
view.updateDisplayListIfDirty();
view.mRecreateDisplayList = false;
}此時view是DecorView，DecorView會往下分發找到需要重繪的view，然後調用此view的draw方法。假設調用invalidate的view爲a，a的parent爲ap。我們知道此時a的PFLAG_DRAWING_CACHE_VALID 爲0，PFLAG_INVALIDATED爲1.而a的父族view，ap,app,appp等的PFLAG_DRAWING_CACHE_VALID爲0，PFLAG_INVALIDATED爲0.
所以上邊會把mRecreateDisplayList設置爲false，後面會知道mRecreateDisplayList代表了哪個view要被重繪，只有a的mRecreateDisplayList爲true，其他都是false。
來看DecorView如何分發的。DecorView的updateViewTreeDisplayList會調updateDisplayListIfDirty，如下，因爲DecorView是a的父族view，所以會進L10的if，然後mRecreateDisplayList爲false，所以會進L16.在L19調用dispatchGetDisplayList，哦喲，看到分發的影子了。
/**
* Gets the RenderNode for the view, and updates its DisplayList (if needed and supported)
* @hide
*/
@NonNull
public RenderNode updateDisplayListIfDirty() {
final RenderNode renderNode = mRenderNode;
。。。
if ((mPrivateFlags & PFLAG_DRAWING_CACHE_VALID) == 0
|| !renderNode.isValid()
|| (mRecreateDisplayList)) {
// Don't need to recreate the display list, just need to tell our
// children to restore/recreate theirs
if (renderNode.isValid()
&& !mRecreateDisplayList) {
mPrivateFlags |= PFLAG_DRAWN | PFLAG_DRAWING_CACHE_VALID;
mPrivateFlags &= ~PFLAG_DIRTY_MASK;
dispatchGetDisplayList();
return renderNode; // no work needed
}
// If we got here, we're recreating it. Mark it as such to ensure that
// we copy in child display lists into ours in drawChild()
mRecreateDisplayList = true;
int width = mRight - mLeft;
int height = mBottom - mTop;
int layerType = getLayerType();
final DisplayListCanvas canvas = renderNode.start(width, height);
canvas.setHighContrastText(mAttachInfo.mHighContrastText);
try {
// Fast path for layouts with no backgrounds
if ((mPrivateFlags & PFLAG_SKIP_DRAW) == PFLAG_SKIP_DRAW) {
dispatchDraw(canvas);
if (mOverlay != null && !mOverlay.isEmpty()) {
mOverlay.getOverlayView().draw(canvas);
}
} else {
draw(canvas);
}
}
} finally {
renderNode.end(canvas);
setDisplayListProperties(renderNode);
}
} else {
mPrivateFlags |= PFLAG_DRAWN | PFLAG_DRAWING_CACHE_VALID;
mPrivateFlags &= ~PFLAG_DIRTY_MASK;
}
return renderNode;
}dispatchGetDisplayList的代碼很簡單,主要就是L4的for循環，內調用recreateChildDisplayList，讓子view recreate display。
protected void dispatchGetDisplayList() {
final int count = mChildrenCount;
final View[] children = mChildren;
for (int i = 0; i < count; i++) {
final View child = children[i];
if (((child.mViewFlags & VISIBILITY_MASK) == VISIBLE || child.getAnimation() != null)) {
recreateChildDisplayList(child);
}
}
if (mOverlay != null) {
View overlayView = mOverlay.getOverlayView();
recreateChildDisplayList(overlayView);
}
if (mDisappearingChildren != null) {
final ArrayList<View> disappearingChildren = mDisappearingChildren;
final int disappearingCount = disappearingChildren.size();
for (int i = 0; i < disappearingCount; ++i) {
final View child = disappearingChildren.get(i);
recreateChildDisplayList(child);
}
}
}再看recreateChildDisplayList，內部給mRecreateDisplayList賦值，然後調用updateDisplayListIfDirty（咦回去了，只是此時對象變成了DecorView的child），好了，分發在這裏完全成型了。
private void recreateChildDisplayList(View child) {
child.mRecreateDisplayList = (child.mPrivateFlags & PFLAG_INVALIDATED) != 0;
child.mPrivateFlags &= ~PFLAG_INVALIDATED;
child.updateDisplayListIfDirty();
child.mRecreateDisplayList = false;
}總結
parent:updateDisplayListIfDirty-》dispatchGetDisplayList-》for（） recreateChildDisplayList
child:recreateChildDisplayList-》updateDisplayListIfDirty
我們在具體分析下各個view會如何表現，核心代碼是updateDisplayListIfDirty，
父族view的執行流程是
parent:updateDisplayListIfDirty-》dispatchGetDisplayList-》for（） recreateChildDisplayList
child:recreateChildDisplayList-》updateDisplayListIfDirty
如果是a本身，那麼L10進去，但是由於a的mRecreateDisplayList爲true，所以會到L43進行重繪，這就是invalidate導致的分發過程
如果不是父族view也不是a本身，那麼PFLAG_DRAWING_CACHE_VALID爲1，會走L10的else設置標誌位，然後結束，不會分發到子view。
所以整個過程中只有a調用了draw方法進行重繪，這是PFLAG_INVALIDATED標誌位起的作用。
/**
* Gets the RenderNode for the view, and updates its DisplayList (if needed and supported)
* @hide
*/
@NonNull
public RenderNode updateDisplayListIfDirty() {
final RenderNode renderNode = mRenderNode;
。。。
if ((mPrivateFlags & PFLAG_DRAWING_CACHE_VALID) == 0
|| !renderNode.isValid()
|| (mRecreateDisplayList)) {
// Don't need to recreate the display list, just need to tell our
// children to restore/recreate theirs
if (renderNode.isValid()
&& !mRecreateDisplayList) {
mPrivateFlags |= PFLAG_DRAWN | PFLAG_DRAWING_CACHE_VALID;
mPrivateFlags &= ~PFLAG_DIRTY_MASK;
dispatchGetDisplayList();
return renderNode; // no work needed
}
// If we got here, we're recreating it. Mark it as such to ensure that
// we copy in child display lists into ours in drawChild()
mRecreateDisplayList = true;
int width = mRight - mLeft;
int height = mBottom - mTop;
int layerType = getLayerType();
final DisplayListCanvas canvas = renderNode.start(width, height);
canvas.setHighContrastText(mAttachInfo.mHighContrastText);
try {
// Fast path for layouts with no backgrounds
if ((mPrivateFlags & PFLAG_SKIP_DRAW) == PFLAG_SKIP_DRAW) {
dispatchDraw(canvas);
if (mOverlay != null && !mOverlay.isEmpty()) {
mOverlay.getOverlayView().draw(canvas);
}
} else {
draw(canvas);
}
}
} finally {
renderNode.end(canvas);
setDisplayListProperties(renderNode);
}
} else {
mPrivateFlags |= PFLAG_DRAWN | PFLAG_DRAWING_CACHE_VALID;
mPrivateFlags &= ~PFLAG_DIRTY_MASK;
}
return renderNode;
}問題onMeasure、onLayout
還有個問題，invalidate會不會導致onMeasure和onLayout被調用呢??
在performTraversals方法中，mLayoutRequested爲false，所有onMeasure和onLayout都不會被調用。
ViewGroup的invalidate
我們再來看看ViewGroup的invalidate，剛纔說了invalidate如果是個view，那就只有自己本身會draw，如果是ViewGroup呢?
因爲一般的ViewGroup都是SKIP_DRAW的，所以會走到L38 dispatchDraw, dispatchDraw的實現一般在ViewGroup裏，就是調用子view的draw（注意是調用的3參的draw方法，而不是單參的方法）
所以一般來說ViewGroup的invalidate就是對子view進行重繪（android.view.View#draw(android.graphics.Canvas, android.view.ViewGroup, long)）
總結
1、view的invalidate並不會調用ViewRootImpl的invalidate。
2、performDraw的過程中，大部分view的 updateDisplayListIfDirty都會被調用，但是隻有設了標誌位的view會調用draw方法進而調用onDraw
requestLayout
主體過程
讀完了invalidate再看requestLayout就很簡單了，
1.view的requestLayout會調用parent的requestLayout，直到ViewRootImpl的requestLayout。ViewRootImpl的requestLayout代碼如下
public void requestLayout() {
if (!mHandlingLayoutInLayoutRequest) {
checkThread();
mLayoutRequested = true;
scheduleTraversals();
}
}可以看到mLayoutRequested變true了，然後觸發了scheduleTraversals
2.我們可以簡單的認爲mLayoutRequested爲true會觸發perfomMeasure(內部會調用onMeasure)和performLayout(內部會調用onLayout)。然後在performDraw內部draw的過程中發現mDirty爲空，所以onDraw不會被調用，不重繪。
這麼看來requestLayout不會導致onDraw調用了？
也不見得，我們知道requestLayout會導致perfomMeasure和performLayout，如果在layout過程中發現l,t,r,b和以前不一樣，那就會觸發一次invalidate。代碼在View的setFrame中，這個會在layout時被調用。
protected boolean setFrame(int left, int top, int right, int bottom) {
boolean changed = false;
if (DBG) {
Log.d("View", this + " View.setFrame(" + left + "," + top + ","
+ right + "," + bottom + ")");
}
if (mLeft != left || mRight != right || mTop != top || mBottom != bottom) {
changed = true;
// Remember our drawn bit
int drawn = mPrivateFlags & PFLAG_DRAWN;
int oldWidth = mRight - mLeft;
int oldHeight = mBottom - mTop;
int newWidth = right - left;
int newHeight = bottom - top;
boolean sizeChanged = (newWidth != oldWidth) || (newHeight != oldHeight);
// Invalidate our old position
invalidate(sizeChanged);
mLeft = left;
mTop = top;
mRight = right;
mBottom = bottom;
mRenderNode.setLeftTopRightBottom(mLeft, mTop, mRight, mBottom);
。。。
} 所以requestLayout有可能會導致onDraw被調用，也可能不導致onDraw被調用，取決於view的l,t,r,b是否改變
part or full
requestLayout會導致整個view tree的measure/layout嗎？
我們在說invalidate的時候，invalidate會對調用的view進行標記，到時候只要重繪標記了PFLAG_INVALIDATED的view就可以了。但是requestLayout的過程中，我們沒有看到對requestLayout的標記（本以爲是mViewRequestingLayout，結果沒卵用）。那麼一個a調用requestLayout和ap調用requestLayout效果一樣嗎？
答案是不一樣，但是有時候效果也一樣。
看看下邊requestLayout的代碼，其實主要就是L16,L17設置了PFLAG_FORCE_LAYOUT和PFLAG_INVALIDATED 2個標誌位，特別是PFLAG_FORCE_LAYOUT。
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;
}
}一個view調用了requestLayout，那麼他自己與他的父族view都會被設置爲PFLAG_FORCE_LAYOUT，我們在看看measure過程，要進入L18，measure的核心代碼處必須滿足3個條件之一，而他自己與他的父族view都會被設置爲PFLAG_FORCE_LAYOUT，所以他們都必然會被重新measure，但是其他的view就不一定了，就看這3個條件是否會滿足。
結論是requestLayout會導致部分view重新measure和layout。a的requestLayout必然會導致a,ap…的重新measure，ap的requestLayout必定會導致ap的measure，但不一定會導致a的measure
public final void measure(int widthMeasureSpec, int heightMeasureSpec) {
boolean optical = isLayoutModeOptical(this);
if (optical != isLayoutModeOptical(mParent)) {
Insets insets = getOpticalInsets();
int oWidth = insets.left + insets.right;
int oHeight = insets.top + insets.bottom;
widthMeasureSpec = MeasureSpec.adjust(widthMeasureSpec, optical ? -oWidth : oWidth);
heightMeasureSpec = MeasureSpec.adjust(heightMeasureSpec, optical ? -oHeight : oHeight);
}
// Suppress sign extension for the low bytes
long key = (long) widthMeasureSpec << 32 | (long) heightMeasureSpec & 0xffffffffL;
if (mMeasureCache == null) mMeasureCache = new LongSparseLongArray(2);
if ((mPrivateFlags & PFLAG_FORCE_LAYOUT) == PFLAG_FORCE_LAYOUT ||
widthMeasureSpec != mOldWidthMeasureSpec ||
heightMeasureSpec != mOldHeightMeasureSpec) {
//....measure核心代碼
}
mPrivateFlags |= PFLAG_LAYOUT_REQUIRED;
}
mOldWidthMeasureSpec = widthMeasureSpec;
mOldHeightMeasureSpec = heightMeasureSpec;
mMeasureCache.put(key, ((long) mMeasuredWidth) << 32 |
(long) mMeasuredHeight & 0xffffffffL); // suppress sign extension
}onMeasure和onLayout的關係
一般來說我們認爲調用了onMeasure就會調用onLayout，onMeasure和onLayout是強相關的，爲什麼這麼認爲呢？看下邊代碼
measure的代碼簡化後，如下所示，在滿足3條件時，進入主measure流程，調用onMeasure，然後設置PFLAG_LAYOUT_REQUIRED，看標誌就明白了，打上了這個標誌，就表示此view需要layout。
public final void measure(int widthMeasureSpec, int heightMeasureSpec) {
if ((mPrivateFlags & PFLAG_FORCE_LAYOUT) == PFLAG_FORCE_LAYOUT ||
widthMeasureSpec != mOldWidthMeasureSpec ||
heightMeasureSpec != mOldHeightMeasureSpec) {
...
onMeasure(widthMeasureSpec, heightMeasureSpec);
mPrivateFlags |= PFLAG_LAYOUT_REQUIRED;
}
}再看layout內怎麼用上此標誌位的,如果changed或者PFLAG_LAYOUT_REQUIRED，那就調用onLayout，這個flag就是剛纔我們onMeasure完畢後設置上的，所以可以認爲調用了onMeasure就會調用onLayout
public void layout(int l, int t, int r, int b) {
boolean changed = isLayoutModeOptical(mParent) ?
setOpticalFrame(l, t, r, b) : setFrame(l, t, r, b);
if (changed || (mPrivateFlags & PFLAG_LAYOUT_REQUIRED) == PFLAG_LAYOUT_REQUIRED) {
onLayout(changed, l, t, r, b);
mPrivateFlags &= ~PFLAG_LAYOUT_REQUIRED;
。。。
}
mPrivateFlags &= ~PFLAG_FORCE_LAYOUT;
mPrivateFlags3 |= PFLAG3_IS_LAID_OUT;
}總結
1.view不停找parent可以一直找到DecorView，按理說DecorView是頂點了，但是DecorView還有個虛擬父view，ViewRootImpl。 ViewRootImpl不是一個View或者ViewGroup,他有個成員mView是DecorView，所有的操作從ViewRootImpl開始自上而下分發
2.view的invalidate不會導致ViewRootImpl的invalidate被調用，而是遞歸調用父view的invalidateChildInParent，直到ViewRootImpl的invalidateChildInParent，然後觸發peformTraversals，會導致當前view被重繪,由於mLayoutRequested爲false，不會導致onMeasure和onLayout被調用，而OnDraw會被調用
3.一個view的invalidate會導致本身PFLAG_INVALIDATED置1，導致本身以及父族viewgroup的PFLAG_DRAWING_CACHE_VALID置0
4.requestLayout會直接遞歸調用父窗口的requestLayout，直到ViewRootImpl,然後觸發peformTraversals，由於mLayoutRequested爲true，會導致onMeasure和onLayout被調用。不一定會觸發OnDraw
5.requestLayout觸發onDraw可能是因爲在在layout過程中發現l,t,r,b和以前不一樣，那就會觸發一次invalidate，所以觸發了onDraw，也可能是因爲別的原因導致mDirty非空（比如在跑動畫）
6. requestLayout會導致自己以及父族view的PFLAG_FORCE_LAYOUT和PFLAG_INVALIDATED標誌被設置。
7.一般來說，只要刷新的時候就調用invalidate，需要重新measure就調用requestLayout，後面再跟個invalidate（爲了保證重繪），這是我個人的理解。
參考文獻
aosp6.0.1