概要
requestLayout
在进行完layout之后，requestLayout()所引发的过程就此终止了，它不会调用draw，不会重新绘制任何视图包括该调用者本身。
invalidate
最终又会走到前面说的performTraversals()方法，请求重绘View树，即draw()过程，假如视图发生大小没有变化就不会调用layout()过程，并且只绘制那些需要重绘的视图。
invalidate，请求重新draw，只会绘制调用者本身。
setSelection，同上。
setVisibility：当View从INVISIBLE变为VISIBILE，会间接调用invalidate方法，继而绘制该View，而从INVISIBLE/VISIBLE变为GONE之后，由于View树的大小发生了变化，会进行measure/layout/draw，同样，他只会绘制需要重绘的视图。
setEnable：请求重新draw，只会绘制调用者本身。
requestFocus：请求重新draw，只会绘制需要重绘的视图。
一、requestLayout
requestLayout是在View中定义的，并且在ViewGroup中没有重写该方法，它的注释是这样解释的：在需要刷新View的布局时调用这个函数，它会安排一个布局的传递。我们不应该在布局的过程中（isInLayout()）调用这个函数，如果当前正在布局，那么这一请求有可能在以下时刻被执行：当前布局结束、当前帧被绘制完或者下次布局发生时。
@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;
}
}
设置了两个标志位：PFLAG_FORCE_LAYOUT/PFLAG_INVALIDATED，除此之外最关键的一句话是：
protected ViewParent mParent;
//....
mParent.requestLayout();
这个mParent存储的时候该View所对应的父节点，而当调用父节点的requestLayout()时，它又会调用它的父节点的requestLayout，就这样，以调用requestLayout的View为起始节点，一步步沿着View树传递上去，那么这个过程什么时候会终止呢？我们知道整个View树的根节点是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()中会执行一个mTraversalRunnable，该Runnable中最终会调用doTraversal，而doTraversal中执行的就是我们前面一直在谈到的performTraversals。
那么，前面我们分析过，performTraversals的measure方法会从根节点调用子节点的测量操作，并依次传递下去，那么是否所有的子View都有必要重新测量呢，这就需要我们在调用View的requestLayout是设置的标志位PFLAG_FORCE_LAYOUT来判断，在measure当中，调用onMeasure之前，会有这么一个判断条件：
if ((mPrivateFlags & PFLAG_FORCE_LAYOUT) == PFLAG_FORCE_LAYOUT ||
widthMeasureSpec != mOldWidthMeasureSpec ||
heightMeasureSpec != mOldHeightMeasureSpec) {
onMeasure(widthMeasureSpec, heightMeasureSpec);
}
这个标志位会在layout完成之后被恢复：
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()所引发的过程就此终止了，它不会调用draw，不会重新绘制任何视图包括该调用者本身。
二、invalidate
invalidate最终会调用到下面这个方法：
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();
}
}
}
其中，关键的一句是：
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会根据传入的区域来决定自己的绘制区域，和requestLayout类似，最终会调用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;
}
这其中又会调用invalidate：
void invalidate() {
mDirty.set(0, 0, mWidth, mHeight);
if (!mWillDrawSoon) {
scheduleTraversals();
}
}
这里，最终又会走到前面说的performTraversals()方法，请求重绘View树，即draw()过程，假如视图发生大小没有变化就不会调用layout()过程，并且只绘制那些需要重绘的视图。
三、其他
invalidate，请求重新draw，只会绘制调用者本身。
setSelection，同上。
setVisibility：当View从INVISIBLE变为VISIBILE，会间接调用invalidate方法，继而绘制该View，而从INVISIBLE/VISIBLE变为GONE之后，由于View树的大小发生了变化，会进行measure/layout/draw，同样，他只会绘制需要重绘的视图。
setEnable：请求重新draw，只会绘制调用者本身。
requestFocus：请求重新draw，只会绘制需要重绘的视图。
View 绘制体系知识梳理(6) 绘制过程之 requestLayout 和 invalidate 详解
