Android中View的更新方法:invalidate()和requestLayout()

Android中View的更新方法:invalidate()和requestLayout()_第1张图片

前言
我们在自定义View时可能需要更新View的显示,比如为View添加动画等等,有两个方法是我们经常会用到的:invalidate()requestLayout(),本文就来具体分析一下这两个方法的区别和使用场景。

在进入正文之前还是要强调一下,本文的分析基于Android 9.0(API Level 28)的源码,不同版本的源码可能会有不同,但是基本思路不会变化太多,可以进行参考。

invalidate()

我们直接来看View的invalidate()方法:

public void invalidate() {
    invalidate(true);
}

public void invalidate(boolean invalidateCache) {
    invalidateInternal(0, 0, mRight - mLeft, mBottom - mTop, invalidateCache, true);
}

可以看出View的invalidate()方法最终会调用invalidateInternal()方法:

void invalidateInternal(int l, int t, int r, int b, boolean invalidateCache,
                        boolean fullInvalidate) {
    // ...
    // 判断是否跳过重绘
    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) {
            // 设置PFLAG_INVALIDATED标志位
            mPrivateFlags |= PFLAG_INVALIDATED;
            // 移除PFLAG_DRAWING_CACHE_VALID标志位
            mPrivateFlags &= ~PFLAG_DRAWING_CACHE_VALID;
        }

        final AttachInfo ai = mAttachInfo;
        final ViewParent p = mParent;
        if (p != null && ai != null && l < r && t < b) {
            // damage表示要重绘的区域
            final Rect damage = ai.mTmpInvalRect;
            damage.set(l, t, r, b);
            // 将要重绘的区域传给父View
            p.invalidateChild(this, damage);
        }
        // ...
    }
}

invalidateInternal()方法中首先会根据skipInvalidate()方法判断是否跳过绘制,如果同时满足以下三个条件就直接return,跳过重绘。

  • View是不可见的
  • 当前没有设置动画
  • 父View的类型不是ViewGroup或者父ViewGoup不处于过渡态

接下来根据一系列条件判断是否需要重绘,如果满足以下任意一条就进行重绘。

  • View已经被绘制完成并且具有边界
  • invalidateCache为true并且设置了PFLAG_DRAWING_CACHE_VALID标志位,即绘制缓存可用
  • 没有设置PFLAG_INVALIDATED标志位,即没有被重绘过
  • fullInvalidate为true并且透明度发生了变化

接下来判断如果invalidateCache为true,就给View设置PFLAG_INVALIDATED标志位,这一步很重要,后面还会提到,通过上面的调用也能看出这里的invalidateCache传入的值为true,因此会设置这个标志位。方法的最后会调用mParent即父View的invalidateChild()方法,将要重绘的区域damage传递给父View。下面我们来看ViewGroup的invalidateChild()方法:

@Override
public final void invalidateChild(View child, final Rect dirty) {
    final AttachInfo attachInfo = mAttachInfo;
    if (attachInfo != null && attachInfo.mHardwareAccelerated) {
        // 开启了硬件加速
        onDescendantInvalidated(child, child);
        return;
    }

    ViewParent parent = this;
    if (attachInfo != null) {
        // ...
        do {
            View view = null;
            if (parent instanceof View) {
                view = (View) parent;
            }
            // ...
            parent = parent.invalidateChildInParent(location, dirty);
            // ...
        } while (parent != null);
    }
}

方法内部首先会判断是否开启了硬件加速,接下来我们分别看一下关闭和开启硬件加速情况下的重绘流程。

  • 关闭硬件加速

关闭硬件加速的情况下会循环调用invalidateChildInParent()方法,将返回值赋给parent,当parent为null时退出循环,我们来看ViewGroup的invalidateChildInParent()方法。

@Override
public ViewParent invalidateChildInParent(final int[] location, final Rect dirty) {
    if ((mPrivateFlags & (PFLAG_DRAWN | PFLAG_DRAWING_CACHE_VALID)) != 0) {
        // ...
        // 移除PFLAG_DRAWING_CACHE_VALID标志位
        mPrivateFlags &= ~PFLAG_DRAWING_CACHE_VALID;
        // ...
        return mParent;
    }
    return null;
}

这里省略了大量代码,主要是对子View传递过来的重绘区域进行运算处理,方法最后会返回mParent。因此在invalidateChild()方法中会通过循环逐层调用父View的invalidateChildInParent()方法,那么当调用到最顶层ViewGroup——DecorView的invalidateChild()方法时,它的mParent是谁呢?我们可以回顾一下ViewRootImpl的setView()方法:

public void setView(View view, WindowManager.LayoutParams attrs, View panelParentView) {
    synchronized (this) {
        if (mView == null) {
            mView = view;
            // ...
            requestLayout();
            // ...
            view.assignParent(this);
            // ...
        }
    }
}

可以发现方法执行了view.assignParent(this),这里的view其实就是DecorView(ActivityThread的handleResumeActivity()方法中调用wm.addView()传过来的),我们来看一下assignParent()方法,它定义在View中:

void assignParent(ViewParent parent) {
    if (mParent == null) {
        mParent = parent;
    } else if (parent == null) {
        mParent = null;
    } else {
        throw new RuntimeException("view " + this + " being added, but"
                + " it already has a parent");
    }
}

很明显assignParent()方法完成了View的成员变量mParent的赋值,因此DecorView的mParent就是上面传入的this,也就是ViewRootImpl。既然清楚了DecorView的mParent,接下来我们就来看一下ViewRootImpl的invalidateChildInParent()方法:

@Override
public ViewParent invalidateChildInParent(int[] location, Rect dirty) {
    checkThread();
    // ...
    invalidateRectOnScreen(dirty);
    return null;
}

方法内部首先会调用checkThread()方法:

void checkThread() {
    if (mThread != Thread.currentThread()) {
        throw new CalledFromWrongThreadException(
                "Only the original thread that created a view hierarchy can touch its views.");
    }
}

checkThread()方法会判断当前线程是否为主线程,如果不是主线程就直接抛出异常,因此我们需要特别注意,invalidate()方法必须在主线程中调用。回到ViewRootImpl的invalidateChildInParent()方法,最后调用了invalidateRectOnScreen()方法,同时由于返回值为null,因此执行完invalidateChildInParent()方法后parent被赋值为null,退出do-while循环。接下来我们就来看一下invalidateRectOnScreen()方法:

private void invalidateRectOnScreen(Rect dirty) {
    // ...
    if (!mWillDrawSoon && (intersected || mIsAnimating)) {
        scheduleTraversals();
    }
}

invalidateRectOnScreen()方法内部会调用scheduleTraversals()方法,这个方法我们很熟悉了,接下来会调用performTraversals()方法,开始View的三大流程,这里再来回顾一下:

private void performTraversals() {
    // ...
    boolean layoutRequested = mLayoutRequested && (!mStopped || mReportNextDraw);
    if (layoutRequested) {
        // ...
        // 调用performMeasure()方法开始measure流程
        measureHierarchy(host, lp, res,
                desiredWindowWidth, desiredWindowHeight);
    }
    // ...
    final boolean didLayout = layoutRequested && (!mStopped || mReportNextDraw);
    if (didLayout) {
        // ...
        // 开始layout流程
        performLayout(lp, mWidth, mHeight);
    }
    // ...
    // 开始draw流程
    performDraw();
    // ...
}

由于此时没有给mLayoutRequested赋值,它的默认值为false,因此不会调用measureHierarchy()performLayout()方法,只调用performDraw()方法,换句话说就是不会执行measure和layout流程,只执行draw流程,接下来就是调用DecorView的draw()方法,遍历DecorView的子View,逐层完成子View的绘制。

  • 开启硬件加速

开启硬件加速时在ViewGroup的invalidateChild()方法中会调用onDescendantInvalidated()方法并直接返回,不会执行后面的invalidateChildInParent()方法,我们来看一下onDescendantInvalidated()方法:

@Override
public void onDescendantInvalidated(@NonNull View child, @NonNull View target) {
    // ...
    if (mParent != null) {
        mParent.onDescendantInvalidated(this, target);
    }
}

方法内部会调用mParent的onDescendantInvalidated()方法,和invalidateChildInParent()类似,接下来会逐级调用父View的onDescendantInvalidated()方法,最后来到ViewRootImpl的onDescendantInvalidated()方法。

@Override
public void onDescendantInvalidated(@NonNull View child, @NonNull View descendant) {
    if ((descendant.mPrivateFlags & PFLAG_DRAW_ANIMATION) != 0) {
        mIsAnimating = true;
    }
    invalidate();
}

接下来会调用ViewRootImpl的invalidate方法:

void invalidate() {
    mDirty.set(0, 0, mWidth, mHeight);
    if (!mWillDrawSoon) {
        scheduleTraversals();
    }
}

可以看到这里同样调用了scheduleTraversals()方法,之后的流程和关闭硬件加速的情况类似,同样是调用performDraw()方法,不同的是开启硬件加速的情况下会执行mAttachInfo.mThreadedRenderer.draw(mView, mAttachInfo, this, callback),上一篇文章Android自定义View的基石——View工作原理总结中分析View的draw流程时也介绍过了,这里就不再分析了,之后会依次调用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的invalidate()方法后,会给当前View设置PFLAG_INVALIDATED标志位,因此它的mRecreateDisplayList变量值为true,而其他的父级View由于没有设置PFLAG_INVALIDATED标志位,mRecreateDisplayList值为false。接下来会调用view的updateDisplayListIfDirty()方法,这里的view是DecorView。

public RenderNode updateDisplayListIfDirty() {
    final RenderNode renderNode = mRenderNode;
    // ...
    if ((mPrivateFlags & PFLAG_DRAWING_CACHE_VALID) == 0
            || !renderNode.isValid()
            || (mRecreateDisplayList)) {
        if (renderNode.isValid()
                && !mRecreateDisplayList) {
            // 不需要重新进行绘制
            mPrivateFlags |= PFLAG_DRAWN | PFLAG_DRAWING_CACHE_VALID;
            mPrivateFlags &= ~PFLAG_DIRTY_MASK;
            dispatchGetDisplayList();

            return renderNode;
        }

        // 需要重新进行绘制
        mRecreateDisplayList = true;

        try {
            // ...
            if ((mPrivateFlags & PFLAG_SKIP_DRAW) == PFLAG_SKIP_DRAW) {
                // 如果设置了PFLAG_SKIP_DRAW标志位,执行dispatchDraw()方法
                dispatchDraw(canvas);
                drawAutofilledHighlight(canvas);
                if (mOverlay != null && !mOverlay.isEmpty()) {
                    mOverlay.getOverlayView().draw(canvas);
                }
                if (debugDraw()) {
                    debugDrawFocus(canvas);
                }
            } else {
                // 没有设置PFLAG_SKIP_DRAW标志位,执行draw()方法
                draw(canvas);
            }
            // ...
        } finally {
            renderNode.end(canvas);
            setDisplayListProperties(renderNode);
        }
    } else {
        mPrivateFlags |= PFLAG_DRAWN | PFLAG_DRAWING_CACHE_VALID;
        mPrivateFlags &= ~PFLAG_DIRTY_MASK;
    }
    return renderNode;
}

由于页面首次绘制完成后执行了renderNode.end(canvas),因此这里renderNode.isValid()返回值为true,而DecorView的mRecreateDisplayList值为false,因不会执行后面的重新绘制逻辑,取而代之的是调用dispatchGetDisplayList()方法,我们来看一下这个方法:

@Override
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);
        }
    }
    // ...
}

private void recreateChildDisplayList(View child) {
    child.mRecreateDisplayList = (child.mPrivateFlags & PFLAG_INVALIDATED) != 0;
    child.mPrivateFlags &= ~PFLAG_INVALIDATED;
    child.updateDisplayListIfDirty();
    child.mRecreateDisplayList = false;
}

dispatchGetDisplayList()方法内部会遍历子View,依次调用recreateChildDisplayList()方法,不难看出recreateChildDisplayList()方法和updateViewTreeDisplayList()方法很像,接下来同样会调用updateDisplayListIfDirty()方法,对于没有设置PFLAG_INVALIDATED标志位的View,它的mRecreateDisplayList值为false,会重复上面的过程,即调用dispatchGetDisplayList()方法;而对于调用了invalidate()方法的View,由于设置了PFLAG_INVALIDATED标志位,它的mRecreateDisplayList值为true,会执行updateDisplayListIfDirty()方法最后的重绘逻辑,即调用dispatchDraw()方法或者draw()方法完成自身及子View的绘制。
最后总结一下invalidate()方法,调用View的invalidate()方法后会逐级调用父View的方法,最终导致ViewRootImpl的scheduleTraversals()方法被调用,进而调用performTraversals()方法。由于mLayoutRequested的值为false,因此不会执行measure和layout流程,只执行draw流程。draw流程的执行过程和是否开启硬件加速有关:

  • 如果关闭了硬件加速,从DecorView开始的所有View都会重新完成绘制
  • 如果开启了硬件加速,只有调用invalidate()方法的View(包括它的子View)会完成重新绘制

由此也可以看出,开启硬件加速确实可以提高重绘的效率。
此外,由于invalidate()方法必须在主线程中调用,那么如果我们想要在子线程中刷新视图要怎么做呢?不用担心,官方还为我们提供了一个postInvalidate()方法,其实从名称上我们也能猜到它的作用了,就是用于在子线程中刷新视图,简单看一下它的定义:

public void postInvalidate() {
    postInvalidateDelayed(0);
}

public void postInvalidateDelayed(long delayMilliseconds) {
    final AttachInfo attachInfo = mAttachInfo;
    if (attachInfo != null) {
        attachInfo.mViewRootImpl.dispatchInvalidateDelayed(this, delayMilliseconds);
    }
}

public void dispatchInvalidateDelayed(View view, long delayMilliseconds) {
    Message msg = mHandler.obtainMessage(MSG_INVALIDATE, view);
    mHandler.sendMessageDelayed(msg, delayMilliseconds);
}

哈哈,果然还是用到了Handler,mHandler是ViewRootImpl中的一个成员变量,类型为ViewRootHandler,我们来看一下ViewRootHandler对MSG_INVALIDATE消息的处理:

final class ViewRootHandler extends Handler {
    // ...
    @Override
    public void handleMessage(Message msg) {
        switch (msg.what) {
            case MSG_INVALIDATE:
                ((View) msg.obj).invalidate();
                break;
            // ...
        }
    }
}

可以看出最后还是调用了invalidate()方法,因此postInvalidate()方法其实就是通过Handler完成了线程的切换,使得invalidate()方法在主线程中被调用。

requestLayout()

我们来看View的requestLayout()方法:

public void requestLayout() {
    // ...
    // 给View添加两个标志位
    mPrivateFlags |= PFLAG_FORCE_LAYOUT;
    mPrivateFlags |= PFLAG_INVALIDATED;

    if (mParent != null && !mParent.isLayoutRequested()) {
        // 调用父类的requestLayout()方法
        mParent.requestLayout();
    }
    // ...
}

requestLayout()方法内部会调用mParent即父View的requestLayout()方法,最终会来到ViewRootImpl的requestLayout()方法:

@Override
public void requestLayout() {
    if (!mHandlingLayoutInLayoutRequest) {
        checkThread();
        mLayoutRequested = true;
        scheduleTraversals();
    }
}

首先还是会进行线程的检查,因此requestLayout()方法同样只能在主线程中调用。接着会把mLayoutRequested赋值为true并调用scheduleTraversals()方法。后面的流程相信也不用我多说了,调用performTraversals()方法,由于将mLayoutRequested赋值为true,因此会依次执行measureHierarchy()performLayout()performDraw()方法,开始View的三大流程。
到这里还没完,我们需要探究一下View调用requrestLayout()是否会导致View树中的所有View都进行重新测量、布局和绘制。我们注意到调用requestLayout()方法后,会为当前View及所有父级View添加PFLAG_FORCE_LAYOUTPFLAG_INVALIDATED标志位。首先来回顾一下View的measure()方法:

public final void measure(int widthMeasureSpec, int heightMeasureSpec) {
    // ...
    final boolean forceLayout = (mPrivateFlags & PFLAG_FORCE_LAYOUT) == PFLAG_FORCE_LAYOUT;

    final boolean specChanged = widthMeasureSpec != mOldWidthMeasureSpec
            || heightMeasureSpec != mOldHeightMeasureSpec;
    final boolean isSpecExactly = MeasureSpec.getMode(widthMeasureSpec) == MeasureSpec.EXACTLY
            && MeasureSpec.getMode(heightMeasureSpec) == MeasureSpec.EXACTLY;
    final boolean matchesSpecSize = getMeasuredWidth() == MeasureSpec.getSize(widthMeasureSpec)
            && getMeasuredHeight() == MeasureSpec.getSize(heightMeasureSpec);
    final boolean needsLayout = specChanged
            && (sAlwaysRemeasureExactly || !isSpecExactly || !matchesSpecSize);

    if (forceLayout || needsLayout) {
        // ...
        onMeasure(widthMeasureSpec, heightMeasureSpec);
        // ...
        // 设置PFLAG_LAYOUT_REQUIRED标志位
        mPrivateFlags |= PFLAG_LAYOUT_REQUIRED;
    }

    mOldWidthMeasureSpec = widthMeasureSpec;
    mOldHeightMeasureSpec = heightMeasureSpec;
    // ...
}

可以看出,当View设置了PFLAG_FORCE_LAYOUT标志位后,forceLayout的值为true,因此会执行onMeasure() 方法,而对于没有设置PFLAG_FORCE_LAYOUT标志位的View,需要判断测量尺寸是否发生了改变,如果改变了才会调用onMeasure()方法。在调用onMeasure()方法后会给View设置PFLAG_LAYOUT_REQUIRED标志位,我们再来看View的layout()方法:

public void layout(int l, int t, int r, int b) {
    // ...
    int oldL = mLeft;
    int oldT = mTop;
    int oldB = mBottom;
    int oldR = mRight;

    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);
        // ...
    }
    // ...
}

对于设置了PFLAG_LAYOUT_REQUIRED标志位的View,onLayout()方法肯定会执行,另一种情况就是View的四个顶点坐标发生改变,也会执行onLayout()方法。
结合上面的分析可以得出结论,当View调用了requestLayout()方法后,自身及父级View的onMeasure()onLayout()方法会被调用,对于它的子View,onMeasure()onLayout()方法不一定被调用。
对于draw流程,performDraw()方法会调用ViewRootImpl中的draw()方法:

private boolean draw(boolean fullRedrawNeeded) {
    // ...
    final Rect dirty = mDirty;
    // ...
    if (!dirty.isEmpty() || mIsAnimating || accessibilityFocusDirty) {
        if (mAttachInfo.mThreadedRenderer != null && mAttachInfo.mThreadedRenderer.isEnabled()) {
            // ...
            // 开启了硬件加速
            mAttachInfo.mThreadedRenderer.draw(mView, mAttachInfo, this, callback);
        } else {
            // ...
            // 关闭了硬件加速
            if (!drawSoftware(surface, mAttachInfo, xOffset, yOffset,
                    scalingRequired, dirty, surfaceInsets)) {
                return false;
            }
        }
    }
    // ...
    return useAsyncReport;
}

dirty指向ViewRootImpl中的一个成员变量mDirty,类型为Rect,在ViewRootImpl的invalidate()方法中会调用set()方法为其设置四个边界值,由于此时没有调用invalidate()方法,因此mDirty.isEmpty()返回true,不会执行后面的绘制方法,因此整个View树不会进行重新绘制。不过也有这样一种情况,我们知道在执行VIew的layout流程时会调用setFrame()方法,在setFrame()方法中有这样的逻辑:

int oldWidth = mRight - mLeft;
int oldHeight = mBottom - mTop;
int newWidth = right - left;
int newHeight = bottom - top;
boolean sizeChanged = (newWidth != oldWidth) || (newHeight != oldHeight);

invalidate(sizeChanged);

可以看出当View的宽或高发生改变时会调用invalidate()方法,导致View的重新绘制。

总结

我们已经分析过了invalidate()requestLayout()的具体实现,现在就来总结一下invalidate()requestLayout()的异同:
相同点
1.invalidate()requestLayout()方法最终都会调用ViewRootImpl的performTraversals()方法。
不同点
1.invalidate()方法不会执行measureHierarchy()performLayout()方法,也就不会执行measure和layout流程,只执行draw流程,如果开启了硬件加速则只进行调用者View的重绘。
2.requestLayout()方法会依次measureHierarchy()performLayout()performDraw()方法,调用者View和它的父级View会重新进行measure、layout,一般情况下不会执行draw流程,子View不一定会重新measure和layout。
综上,当只需要进行重新绘制时就调用invalidate(),如果需要重新测量和布局就调用requestLayout(),但是requestLayout()不保证进行重新绘制,如果要进行重新绘制可以再手动调用invalidate()
光介绍结论可能不是很直观,下面就以一个简单的例子验证一下上面的几个结论,我定义了两个ViewGroup和一个View,代码很简单,如下所示:
MyViewGroup1.java

public class MyViewGroup1 extends ViewGroup {

    public MyViewGroup1(Context context) {
        this(context, null);
    }

    public MyViewGroup1(Context context, AttributeSet attrs) {
        this(context, attrs, 0);
    }

    public MyViewGroup1(Context context, AttributeSet attrs, int defStyleAttr) {
        super(context, attrs, defStyleAttr);
        setWillNotDraw(false);
    }

    @Override
    protected void onMeasure(int widthMeasureSpec, int heightMeasureSpec) {
        super.onMeasure(widthMeasureSpec, heightMeasureSpec);
        Log.e("TAG", "MyViewGroup1执行了onMeasure");
        measureChildren(widthMeasureSpec, heightMeasureSpec);
    }

    @Override
    protected void onLayout(boolean changed, int l, int t, int r, int b) {
        Log.e("TAG", "MyViewGroup1执行了onLayout");
        for (int i = 0; i < getChildCount(); i++) {
            View child = getChildAt(i);

            int width = child.getMeasuredWidth();
            int height = child.getMeasuredHeight();

            child.layout(l, t, l + width, t + height);
        }
    }

    @Override
    protected void onDraw(Canvas canvas) {
        super.onDraw(canvas);
        Log.e("TAG", "MyViewGroup1执行了onDraw");
        canvas.drawColor(Color.YELLOW);
    }
}

MyViewGroup2.java

public class MyViewGroup2 extends ViewGroup {

    public MyViewGroup2(Context context) {
        this(context, null);
    }

    public MyViewGroup2(Context context, AttributeSet attrs) {
        this(context, attrs, 0);
    }

    public MyViewGroup2(Context context, AttributeSet attrs, int defStyleAttr) {
        super(context, attrs, defStyleAttr);
        setWillNotDraw(false);
    }

    @Override
    protected void onMeasure(int widthMeasureSpec, int heightMeasureSpec) {
        super.onMeasure(widthMeasureSpec, heightMeasureSpec);
        Log.e("TAG", "MyViewGroup2执行了onMeasure");
        measureChildren(widthMeasureSpec, heightMeasureSpec);
    }

    @Override
    protected void onLayout(boolean changed, int l, int t, int r, int b) {
        Log.e("TAG", "MyViewGroup2执行了onLayout");
        for (int i = 0; i < getChildCount(); i++) {
            View child = getChildAt(i);

            int width = child.getMeasuredWidth();
            int height = child.getMeasuredHeight();

            child.layout(l, t, l + width, t + height);
        }
    }

    @Override
    protected void onDraw(Canvas canvas) {
        super.onDraw(canvas);
        Log.e("TAG", "MyViewGroup2执行了onDraw");
        canvas.drawColor(Color.GREEN);
    }
}

MyView.java

public class MyView extends View {

    public MyView(Context context) {
        super(context);
    }

    public MyView(Context context, @Nullable AttributeSet attrs) {
        super(context, attrs);
    }

    public MyView(Context context, @Nullable AttributeSet attrs, int defStyleAttr) {
        super(context, attrs, defStyleAttr);
    }

    @Override
    protected void onMeasure(int widthMeasureSpec, int heightMeasureSpec) {
        super.onMeasure(widthMeasureSpec, heightMeasureSpec);
        Log.e("TAG", "MyView执行了onMeasure");
    }

    @Override
    protected void onLayout(boolean changed, int left, int top, int right, int bottom) {
        super.onLayout(changed, left, top, right, bottom);
        Log.e("TAG", "MyView执行了onLayout");
    }

    @Override
    protected void onDraw(Canvas canvas) {
        super.onDraw(canvas);
        Log.e("TAG", "MyView执行了onDraw");
        canvas.drawColor(Color.RED);
    }
}

为了保证ViewGroup的onDraw()方法执行,我在构造方法中调用了setWillNotDraw(false)。布局文件也很简单,一个三级的嵌套:
activity_test.xml




    

        

    


运行后的效果如下:

Android中View的更新方法:invalidate()和requestLayout()_第2张图片

我给三个View添加了点击事件,点击后分别调用自身的invalidate()requestLayout()方法,下面分情况看一下。

  • 调用invalidate()方法

开启硬件加速
调用MyView的invalidate()方法:

调用MyViewGroup2的invalidate()方法:

调用MyViewGroup1的invalidate()方法:

关闭硬件加速
调用MyView的invalidate()方法:

调用MyViewGroup2的invalidate()方法:

调用MyViewGroup1的invalidate()方法:

可以看出,关闭硬件加速时,调用任何一个View的invalidate()方法都会导致整个View树的重新绘制;开启硬件加速时,调用哪一个View的invalidate()方法就会重绘哪一个View。invalidate()方法不会导致onMeasure()onLayout()被调用。

  • 调用requestLayout()方法

开启硬件加速
调用MyView的requestLayout()方法:

Android中View的更新方法:invalidate()和requestLayout()_第3张图片

调用MyViewGroup2的requestLayout()方法:

调用MyViewGroup1的requestLayout()方法:

关闭硬件加速
调用MyView的requestLayout()方法:

Android中View的更新方法:invalidate()和requestLayout()_第4张图片

调用MyViewGroup2的requestLayout()方法:

调用MyViewGroup1的requestLayout()方法:

可以看出此时是否开启硬件加速对于requestLayout()方法的调用流程没有影响,调用View的requestLayout()方法会导致自身及其父View的onMeasure()onLayout()方法被调用,并不会调用onDraw()方法进行重绘,当然前面也分析过了,onDraw()方法不是一定不会被调用,当View重新绘制时硬件加速的作用就会有所体现了。
其实这篇文章本来是作为上一篇文章Android自定义View的基石——View工作原理总结的一个章节的,由于字数限制只能单独提出来了,因此难免有地方介绍得不是很详细,可以结合上一篇文章来看。由于自身水平的原因,文章中分析得不正确的地方,欢迎大家交流指出,

参考文章

invalidate、postInvalidate与requestLayout浅析

你可能感兴趣的:(Android中View的更新方法:invalidate()和requestLayout())