invalidate和requestLayout經(jīng)常被用來(lái)刷新界面，有的時(shí)候2個(gè)一起用，TextView的源碼里也經(jīng)常看到2者一起用的情況达吞。什么時(shí)候該用哪個(gè)呢？為什么有的時(shí)候2個(gè)要一起用呢危纫？
本文所從源碼是6.0.1來(lái)研究下2者的原理和區(qū)別以及如何使用宗挥。測(cè)試工程InvalidateDemo
Invalidate
PFLAG_DRAWING_CACHE_VALID、PFLAG_INVALIDATED
這里我們要注意view的2個(gè)flag种蝶，一個(gè)是PFLAG_INVALIDATED契耿，一個(gè)是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;
看起來(lái)好像螃征，子view invalidate就會(huì)導(dǎo)致父view PFLAG_INVALIDATED搪桂，但是我實(shí)際試了下，子view invalidate只會(huì)導(dǎo)致子view PFLAG_INVALIDATED盯滚，父view的PFLAG_INVALIDATED不會(huì)被設(shè)置踢械。
而PFLAG_DRAWING_CACHE_VALID代表drawing_cache有效了，這個(gè)才是其中某個(gè)子view invalidate了魄藕，一個(gè)子view invalidate會(huì)導(dǎo)致父view的PFLAG_DRAWING_CACHE_VALID被置0内列，父view的父view也會(huì)PFLAG_DRAWING_CACHE_VALID被置為0，后文會(huì)分析背率。
Invalidate具體分析
先來(lái)看看invalidate方法话瞧，這是view的一個(gè)方法嫩与，一般我們想更新某個(gè)view會(huì)調(diào)用此方法.我們都知道view的invalidate會(huì)導(dǎo)致這個(gè)view被重新繪制，這個(gè)是怎么實(shí)現(xiàn)的呢交排？
我們知道invalidate會(huì)導(dǎo)致ViewRootImpl的peformDraw被調(diào)用划滋，那怎么保證不繪制所有的view，而只繪制某個(gè)view呢埃篓？大概流程圖如下所示
step1.invalidateInternal
大概流程如上面的圖所展示的处坪，View的invalidate會(huì)調(diào)到invalidateInternal，里面會(huì)在L7設(shè)置2個(gè)標(biāo)志位PFLAG_INVALIDATED和PFLAG_DRAWING_CACHE_VALID架专，PFLAG_INVALIDATED置為1同窘，PFLAG_DRAWING_CACHE_VALID置為0. 并且調(diào)用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內(nèi)部有個(gè)dowhile循環(huán)服傍，不停調(diào)用父view的invalidateChildInParent钱雷，一直到調(diào)用ViewRootImpl的invalidateChildInParent。我們看invalidateChild的L21吹零，把PFLAG_DRAWING_CACHE_VALID置為0罩抗，在dowhile循環(huán)后，當(dāng)前view的所有父view灿椅，父view的父view套蒂。。茫蛹。都會(huì)被PFLAG_DRAWING_CACHE_VALID置為0.調(diào)用invalidateChildInParent會(huì)傳進(jìn)去一個(gè)Rect叫dirty操刀，代表子窗口需要刷新的rect，父窗口會(huì)根據(jù)這個(gè)rect和父窗口本身做union婴洼，從而得到父窗口需要刷新的rect區(qū)域骨坑，然后再傳給父窗口的父窗口，一直遞歸直到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內(nèi)部調(diào)用而invalidateRectOnScreen進(jìn)而調(diào)用scheduleTraversals柬采。
step3. scheduleTraversals
scheduleTraversals一般都會(huì)調(diào)用performDraw進(jìn)而調(diào)draw欢唾，在draw內(nèi)，如果發(fā)現(xiàn)mDirty非空就會(huì)調(diào)mAttachInfo.mHardwareRenderer.draw(mView, mAttachInfo, this);
這是ThreadedRenderer內(nèi)的方法了粉捻，里面會(huì)調(diào)updateRootDisplayList進(jìn)而調(diào)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;
}
此時(shí)view是DecorView，DecorView會(huì)往下分發(fā)找到需要重繪的view肩刃，然后調(diào)用此view的draw方法祟霍。假設(shè)調(diào)用invalidate的view為a杏头，a的parent為ap。我們知道此時(shí)a的PFLAG_DRAWING_CACHE_VALID 為0浅碾，PFLAG_INVALIDATED為1.而a的父族view大州，ap,app,appp等的PFLAG_DRAWING_CACHE_VALID為0，PFLAG_INVALIDATED為0.
所以上邊會(huì)把mRecreateDisplayList設(shè)置為false垂谢，后面會(huì)知道m(xù)RecreateDisplayList代表了哪個(gè)view要被重繪厦画，只有a的mRecreateDisplayList為true，其他都是false滥朱。
來(lái)看DecorView如何分發(fā)的根暑。DecorView的updateViewTreeDisplayList會(huì)調(diào)updateDisplayListIfDirty，如下徙邻，因?yàn)镈ecorView是a的父族view排嫌，所以會(huì)進(jìn)L10的if，然后mRecreateDisplayList為false缰犁，所以會(huì)進(jìn)L16.在L19調(diào)用dispatchGetDisplayList淳地，哦喲，看到分發(fā)的影子了帅容。
/**
* 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的代碼很簡(jiǎn)單,主要就是L4的for循環(huán)遣钳，內(nèi)調(diào)用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蕴茴，內(nèi)部給mRecreateDisplayList賦值，然后調(diào)用updateDisplayListIfDirty（咦回去了姐直，只是此時(shí)對(duì)象變成了DecorView的child）倦淀，好了，分發(fā)在這里完全成型了声畏。
private void recreateChildDisplayList(View child) {
child.mRecreateDisplayList = (child.mPrivateFlags & PFLAG_INVALIDATED) != 0;
child.mPrivateFlags &= ~PFLAG_INVALIDATED;
child.updateDisplayListIfDirty();
child.mRecreateDisplayList = false;
}
總結(jié)
parent:updateDisplayListIfDirty-》dispatchGetDisplayList-》for（） recreateChildDisplayList
child:recreateChildDisplayList-》updateDisplayListIfDirty
我們?cè)诰唧w分析下各個(gè)view會(huì)如何表現(xiàn)晃听，核心代碼是updateDisplayListIfDirty，
父族view的執(zhí)行流程是
parent:updateDisplayListIfDirty-》dispatchGetDisplayList-》for（） recreateChildDisplayList
child:recreateChildDisplayList-》updateDisplayListIfDirty
如果是a本身砰识，那么L10進(jìn)去能扒，但是由于a的mRecreateDisplayList為true，所以會(huì)到L43進(jìn)行重繪辫狼，這就是invalidate導(dǎo)致的分發(fā)過(guò)程
如果不是父族view也不是a本身初斑，那么PFLAG_DRAWING_CACHE_VALID為1，會(huì)走L10的else設(shè)置標(biāo)志位膨处，然后結(jié)束见秤，不會(huì)分發(fā)到子view砂竖。
所以整個(gè)過(guò)程中只有a調(diào)用了draw方法進(jìn)行重繪，這是PFLAG_INVALIDATED標(biāo)志位起的作用鹃答。
/**
* 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;
}
問(wèn)題onMeasure置济、onLayout
還有個(gè)問(wèn)題，invalidate會(huì)不會(huì)導(dǎo)致onMeasure和onLayout被調(diào)用呢??
在performTraversals方法中锋八，mLayoutRequested為false浙于，所有onMeasure和onLayout都不會(huì)被調(diào)用。
ViewGroup的invalidate
我們?cè)賮?lái)看看ViewGroup的invalidate挟纱，剛才說(shuō)了invalidate如果是個(gè)view羞酗，那就只有自己本身會(huì)draw，如果是ViewGroup呢?
因?yàn)橐话愕腣iewGroup都是SKIP_DRAW的紊服，所以會(huì)走到L38 dispatchDraw, dispatchDraw的實(shí)現(xiàn)一般在ViewGroup里檀轨，就是調(diào)用子view的draw（注意是調(diào)用的3參的draw方法，而不是單參的方法）
所以一般來(lái)說(shuō)ViewGroup的invalidate就是對(duì)子view進(jìn)行重繪（android.view.View#draw(android.graphics.Canvas, android.view.ViewGroup, long)）
總結(jié)
1欺嗤、view的invalidate并不會(huì)調(diào)用ViewRootImpl的invalidate裤园。
2、performDraw的過(guò)程中剂府，大部分view的 updateDisplayListIfDirty都會(huì)被調(diào)用，但是只有設(shè)了標(biāo)志位的view會(huì)調(diào)用draw方法進(jìn)而調(diào)用onDraw
requestLayout
主體過(guò)程
讀完了invalidate再看requestLayout就很簡(jiǎn)單了剃盾，
1.view的requestLayout會(huì)調(diào)用parent的requestLayout腺占，直到ViewRootImpl的requestLayout。ViewRootImpl的requestLayout代碼如下
public void requestLayout() {
if (!mHandlingLayoutInLayoutRequest) {
checkThread();
mLayoutRequested = true;
scheduleTraversals();
}
}
可以看到mLayoutRequested變true了痒谴，然后觸發(fā)了scheduleTraversals
2.我們可以簡(jiǎn)單的認(rèn)為mLayoutRequested為true會(huì)觸發(fā)perfomMeasure(內(nèi)部會(huì)調(diào)用onMeasure)和performLayout(內(nèi)部會(huì)調(diào)用onLayout)衰伯。然后在performDraw內(nèi)部draw的過(guò)程中發(fā)現(xiàn)mDirty為空，所以onDraw不會(huì)被調(diào)用积蔚，不重繪意鲸。
這么看來(lái)requestLayout不會(huì)導(dǎo)致onDraw調(diào)用了？
也不見(jiàn)得尽爆，我們知道requestLayout會(huì)導(dǎo)致perfomMeasure和performLayout怎顾，如果在layout過(guò)程中發(fā)現(xiàn)l,t,r,b和以前不一樣，那就會(huì)觸發(fā)一次invalidate漱贱。代碼在View的setFrame中槐雾，這個(gè)會(huì)在layout時(shí)被調(diào)用。
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有可能會(huì)導(dǎo)致onDraw被調(diào)用，也可能不導(dǎo)致onDraw被調(diào)用擎值，取決于view的l,t,r,b是否改變
part or full
requestLayout會(huì)導(dǎo)致整個(gè)view tree的measure/layout嗎慌烧？
我們?cè)谡f(shuō)invalidate的時(shí)候，invalidate會(huì)對(duì)調(diào)用的view進(jìn)行標(biāo)記鸠儿，到時(shí)候只要重繪標(biāo)記了PFLAG_INVALIDATED的view就可以了屹蚊。但是requestLayout的過(guò)程中，我們沒(méi)有看到對(duì)requestLayout的標(biāo)記（本以為是mViewRequestingLayout捆交，結(jié)果沒(méi)卵用）淑翼。那么一個(gè)a調(diào)用requestLayout和ap調(diào)用requestLayout效果一樣嗎？
答案是不一樣品追，但是有時(shí)候效果也一樣玄括。
看看下邊requestLayout的代碼，其實(shí)主要就是L16,L17設(shè)置了PFLAG_FORCE_LAYOUT和PFLAG_INVALIDATED 2個(gè)標(biāo)志位肉瓦，特別是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;
}
}
一個(gè)view調(diào)用了requestLayout，那么他自己與他的父族view都會(huì)被設(shè)置為PFLAG_FORCE_LAYOUT泞莉，我們?cè)诳纯磎easure過(guò)程哪雕，要進(jìn)入L18，measure的核心代碼處必須滿足3個(gè)條件之一鲫趁，而他自己與他的父族view都會(huì)被設(shè)置為PFLAG_FORCE_LAYOUT斯嚎，所以他們都必然會(huì)被重新measure，但是其他的view就不一定了挨厚，就看這3個(gè)條件是否會(huì)滿足堡僻。
結(jié)論是requestLayout會(huì)導(dǎo)致部分view重新measure和layout。a的requestLayout必然會(huì)導(dǎo)致a,ap...的重新measure疫剃，ap的requestLayout必定會(huì)導(dǎo)致ap的measure钉疫，但不一定會(huì)導(dǎo)致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的關(guān)系
一般來(lái)說(shuō)我們認(rèn)為調(diào)用了onMeasure就會(huì)調(diào)用onLayout，onMeasure和onLayout是強(qiáng)相關(guān)的巢价，為什么這么認(rèn)為呢牲阁？看下邊代碼
measure的代碼簡(jiǎn)化后，如下所示壤躲，在滿足3條件時(shí)城菊，進(jìn)入主measure流程，調(diào)用onMeasure碉克，然后設(shè)置PFLAG_LAYOUT_REQUIRED役电，看標(biāo)志就明白了，打上了這個(gè)標(biāo)志棉胀，就表示此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內(nèi)怎么用上此標(biāo)志位的,如果changed或者PFLAG_LAYOUT_REQUIRED冀膝，那就調(diào)用onLayout，這個(gè)flag就是剛才我們onMeasure完畢后設(shè)置上的霎挟，所以可以認(rèn)為調(diào)用了onMeasure就會(huì)調(diào)用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;
}
總結(jié)
1.view不停找parent可以一直找到DecorView赐纱，按理說(shuō)DecorView是頂點(diǎn)了，但是DecorView還有個(gè)虛擬父view熬北，ViewRootImpl疙描。 ViewRootImpl不是一個(gè)View或者ViewGroup,他有個(gè)成員mView是DecorView，所有的操作從ViewRootImpl開(kāi)始自上而下分發(fā)
2.view的invalidate不會(huì)導(dǎo)致ViewRootImpl的invalidate被調(diào)用讶隐，而是遞歸調(diào)用父view的invalidateChildInParent起胰，直到ViewRootImpl的invalidateChildInParent，然后觸發(fā)peformTraversals巫延，會(huì)導(dǎo)致當(dāng)前view被重繪,由于mLayoutRequested為false效五，不會(huì)導(dǎo)致onMeasure和onLayout被調(diào)用，而OnDraw會(huì)被調(diào)用
3.一個(gè)view的invalidate會(huì)導(dǎo)致本身PFLAG_INVALIDATED置1炉峰，導(dǎo)致本身以及父族viewgroup的PFLAG_DRAWING_CACHE_VALID置0
4.requestLayout會(huì)直接遞歸調(diào)用父窗口的requestLayout畏妖，直到ViewRootImpl,然后觸發(fā)peformTraversals，由于mLayoutRequested為true疼阔，會(huì)導(dǎo)致onMeasure和onLayout被調(diào)用戒劫。不一定會(huì)觸發(fā)OnDraw
5.requestLayout觸發(fā)onDraw可能是因?yàn)樵谠趌ayout過(guò)程中發(fā)現(xiàn)l,t,r,b和以前不一樣，那就會(huì)觸發(fā)一次invalidate婆廊，所以觸發(fā)了onDraw迅细，也可能是因?yàn)閯e的原因?qū)е耺Dirty非空（比如在跑動(dòng)畫(huà)）
- requestLayout會(huì)導(dǎo)致自己以及父族view的PFLAG_FORCE_LAYOUT和PFLAG_INVALIDATED標(biāo)志被設(shè)置。
7.一般來(lái)說(shuō)否彩，只要刷新的時(shí)候就調(diào)用invalidate，需要重新measure就調(diào)用requestLayout嗦随，后面再跟個(gè)invalidate（為了保證重繪）列荔，這是我個(gè)人的理解。
參考文獻(xiàn)
aosp6.0.1
