从源码看invalidate和requestLayout的区别

从源码看invalidate和requestLayout的区别从源码看invalidate和requestLayout的区别invalidate和requestLayout经常被用来刷新界面,有的时候2个一起用,TextView的源码里也经常看到2者一起用的情况。什么时候该用哪个呢?为什么有的时候2个要一起用呢?本文所从源码是6.0.1来研究下2者的原理和区别以及如何使用。测试工程InvalidateDemoInvalidatePFLAG_DRAWING_CA

大家好,欢迎来到IT知识分享网。

从源码看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呢?大概流程图如下所示

从源码看invalidate和requestLayout的区别

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

http://zjmdp.github.io/2012/07/04/invalidate-in-Android/

免责声明:本站所有文章内容,图片,视频等均是来源于用户投稿和互联网及文摘转载整编而成,不代表本站观点,不承担相关法律责任。其著作权各归其原作者或其出版社所有。如发现本站有涉嫌抄袭侵权/违法违规的内容,侵犯到您的权益,请在线联系站长,一经查实,本站将立刻删除。 本文来自网络,若有侵权,请联系删除,如若转载,请注明出处:https://yundeesoft.com/23911.html

(0)

相关推荐

发表回复

您的电子邮箱地址不会被公开。 必填项已用 * 标注

关注微信