你需要了解下Android View的更新requestLayout与重绘invalidate

你需要了解下Android View的更新requestLayout与重绘invalidate从View的绘制机制可知,View从测量、布局、绘制的步骤中会对应执行该View#onMeasure()、View#onLayout()、View#onDraw()。那么我们今天讨论的View#invalidate()和View#requestLayout()呢?我们打印一下数…

在大家都了解过Android View的测量布局绘制机制后,我们来细化地分析一下关于View的重绘invalidate与更新requestLayout

现象

public class CustomEmptyView extends View {
    public CustomEmptyView(Context context) {
        super(context);
    }

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

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

    @Override
    protected void onMeasure(int widthMeasureSpec, int heightMeasureSpec) {
        super.onMeasure(widthMeasureSpec, heightMeasureSpec);
        Log.i("CustomEmptyView", "onMeasure");
    }

    @Override
    protected void onLayout(boolean changed, int left, int top, int right, int bottom) {
        super.onLayout(changed, left, top, right, bottom);
        Log.i("CustomEmptyView", "onLayout");
    }

    @Override
    protected void onDraw(Canvas canvas) {
        super.onDraw(canvas);
        Log.i("CustomEmptyView", "onDraw");
    }
}

从View的绘制机制可知,View从测量、布局、绘制的步骤中会对应执行该View#onMeasure()、View#onLayout()、View#onDraw()。那么我们今天讨论的View#invalidate()和View#requestLayout()呢?我们打印一下数据。

View#invalidate()的执行步骤是:

2019-03-26 17:32:34.739 8075-8075/com.example.myapplication I/CustomEmptyView: onDraw

View#requestLayout()的执行步骤是:

2019-03-26 17:33:13.497 8075-8075/com.example.myapplication I/CustomEmptyView: onMeasure
2019-03-26 17:33:13.501 8075-8075/com.example.myapplication I/CustomEmptyView: onLayout
2019-03-26 17:33:13.503 8075-8075/com.example.myapplication I/CustomEmptyView: onDraw

从打印数据来推测就是View#invalidate()只会执行View#onDraw();而View#requestLayout()则会重新走View的绘制流程。接下来我们从源码的角度来分析一下。 下面的源码分析基于android-28

View#requestLayout()

我们分析一下View#requestLayout()。我们定位到对应的源码

    /** * Call this when something has changed which has invalidated the * layout of this view. This will schedule a layout pass of the view * tree. This should not be called while the view hierarchy is currently in a layout * pass ({@link #isInLayout()}. If layout is happening, the request may be honored at the * end of the current layout pass (and then layout will run again) or after the current * frame is drawn and the next layout occurs. * * 当某内容发生更改,导致该视图的布局重绘时调用此函数。这将安排视图树的布局传递。 * 当视图层次结构当前处于布局Layout事件时,不会执行该函数. * 如果正在进行布局,可以在当前布局传递结束时(然后布局将再次运行)或在绘制当前帧并执行下一个布局之后执行请求。 * <p>Subclasses which override this method should call the superclass method to * handle possible request-during-layout errors correctly.</p> */
    @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;
        }
        // PFLAG_FORCE_LAYOUT会在执行View的measure()和layout()方法时判断,这个是以前的文章看到的。
        // 但是在当前源码的View.class和ViewRootImpl.class,全局搜索PFLAG_FORCE_LAYOUT,并没有直接的判断,导致View#requestLayout()不执行测量和布局方法
        mPrivateFlags |= PFLAG_FORCE_LAYOUT;
        mPrivateFlags |= PFLAG_INVALIDATED;
        // isLayoutRequested()对应是mLayoutRequested字段,该字段在默认为false
        if (mParent != null && !mParent.isLayoutRequested()) {
            // 执行父容器的requestLayout()方法
            mParent.requestLayout();
        }
        if (mAttachInfo != null && mAttachInfo.mViewRequestingLayout == this) {
            mAttachInfo.mViewRequestingLayout = null;
        }
    }

当我们点击ViewGroup#requestLayout(),发现它是一个空实现,我们可知ViewParent是interface类,我们通过之前的View的分析,可以去ViewRootImpl类看看ViewGroup#requestLayout()的实现方法。

    @Override
    public void requestLayout() {
        // mHandlingLayoutInLayoutRequest这个参数,通过全局变量定位,在performLayout()开始时为true,结束时为false,与之前说的,不在布局期间执行相对应
        if (!mHandlingLayoutInLayoutRequest) {
            // 检查是否UI线程
            checkThread();
            // 这里将mLayoutRequested设为true
            mLayoutRequested = true;
            scheduleTraversals();
        }
    }
    
    void scheduleTraversals() {
        if (!mTraversalScheduled) {
            mTraversalScheduled = true;
            mTraversalBarrier = mHandler.getLooper().getQueue().postSyncBarrier();
            mChoreographer.postCallback(
                    Choreographer.CALLBACK_TRAVERSAL, mTraversalRunnable, null);
            if (!mUnbufferedInputDispatch) {
                scheduleConsumeBatchedInput();
            }
            notifyRendererOfFramePending();
            pokeDrawLockIfNeeded();
        }
    }    

看到scheduleTraversals(),我相信大家都觉得快触摸到真相,但是发现点击该方法里的实现,并不能找到我们想要的,此时我们想一下之前的打印数据,View#requestLayout()会重新执行View的绘制步骤,View的绘制步骤最核心是ViewRootImpl#performTraverals,按照这个思路我们继续寻找。

从上面的源码中,我们看到mChoreographer这个对象,我们曾经在分析滑动流程度的时候,提及过Choreographer编舞者这个对象,我们最后从mChoreographer这个对象中的mTraversalRunnable参数找到线索。

    final class TraversalRunnable implements Runnable {
        @Override
        public void run() {
            doTraversal();
        }
    }
    
    final TraversalRunnable mTraversalRunnable = new TraversalRunnable();
    
    void doTraversal() {
        if (mTraversalScheduled) {
            mTraversalScheduled = false;
            mHandler.getLooper().getQueue().removeSyncBarrier(mTraversalBarrier);

            if (mProfile) {
                Debug.startMethodTracing("ViewAncestor");
            }

            performTraversals();

            if (mProfile) {
                Debug.stopMethodTracing();
                mProfile = false;
            }
        }
    }    

最终我们发现mTraversalRunnable这个是一个Runnable对象,在scheduleTraversals()中传入mTraversalRunnable,就会执行doTraversal(),在doTraversal()中我们也如愿地找到我们想要的核心方法ViewRootImpl#performTraverals().当调用ViewRootImpl#performTraverals就重新开始该控件的测量、布局、绘制步骤。符合了我们一开始的打印数据。

View#invalidate()

接着我们看一下View#invalidate的源码。

    /** * Invalidate the whole view. If the view is visible, * 重绘整个View,如果View是可视的。 * {@link #onDraw(android.graphics.Canvas)} will be called at some point in * the future. * <p> * This must be called from a UI thread. To call from a non-UI thread, call * {@link #postInvalidate()}. * 这个方法必须被使用在UI线程,用在非UI线程的方法为postInvalidate() */
    public void invalidate() {
        invalidate(true);
    }

    /** * This is where the invalidate() work actually happens. A full invalidate() * causes the drawing cache to be invalidated, but this function can be * called with invalidateCache set to false to skip that invalidation step * for cases that do not need it (for example, a component that remains at * the same dimensions with the same content). * 这就是invalidate()方法工作发生的地方,一个完整的invalidate()方法会引起绘制 * 缓存失效,但是这个函数能设置参数invalidateCache为false来跳过重绘步骤,由于 * 该方法不被需要,例如一个组件保持相同的尺寸和相同的内容 * * @param invalidateCache Whether the drawing cache for this view should be * invalidated as well. This is usually true for a full * invalidate, but may be set to false if the View's contents or * dimensions have not changed. * 这绘制缓存是否应被重绘.一个完整的重绘通常为true,但是可能设置为false,如果View的内容和尺寸没有被改变。 * * @hide */
    public void invalidate(boolean invalidateCache) {
        invalidateInternal(0, 0, mRight - mLeft, mBottom - mTop, invalidateCache, true);
    }

    void invalidateInternal(int l, int t, int r, int b, boolean invalidateCache, boolean fullInvalidate) {
        // 暂不见赋值,从下面的方法中,得出他是一个被舍弃的方法,可以跳过
        if (mGhostView != null) {
            mGhostView.invalidate(true);
            return;
        }
        // 跳过重绘。从方法描述可知,该方法判断该View不被重绘,当它处于不可见和没有处于动画中
        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;
            // 如果需要全部重绘,invalidate()未传参调用时默认为true
            if (invalidateCache) {
                // 记住这个PFLAG_INVALIDATED标志位
                mPrivateFlags |= PFLAG_INVALIDATED;
                mPrivateFlags &= ~PFLAG_DRAWING_CACHE_VALID;
            }

            // Propagate the damage rectangle to the parent view.
            // 从下面参数mParent可知,应该是将需要重绘这个事件通知给父容器
            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);
                // 这个就是重点,我们去看一下父容器的invalidateChild()方法
                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();
                }
            }
        }
    }

从上面的分析可知,经过invalidate()的重载方法,最终会调用invalidateInternal(),在这个方法里头,要判断是否需要重绘,如果需要重绘,就对该View进行标识,然后将该View的Rect信息传递给父容器的invalidateChild().

与之前的View#requestLayout()相似,最终同样是执行ViewRootImpl#invalidateChild(),然后我继续分析ViewRootImpl#invalidateChild()的实现。

    @Override
    public void invalidateChild(View child, Rect dirty) {
        invalidateChildInParent(null, dirty);
    }

    // 由于没有注释,我们从方法名去分析源码,重载至这个最终的方法,意思为在父容器中重绘子控件
    @Override
    public ViewParent invalidateChildInParent(int[] location, Rect dirty) {
        // 检查线程,里面判断为,该方法需要执行在UI线程,验证了之前View#invalidate()的描述
        checkThread();
        if (DEBUG_DRAW) Log.v(mTag, "Invalidate child: " + dirty);
        // 从上一步可知,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;
    }
    
    private void invalidateRectOnScreen(Rect dirty) {
        final Rect localDirty = mDirty;
        if (!localDirty.isEmpty() && !localDirty.contains(dirty)) {
            mAttachInfo.mSetIgnoreDirtyState = true;
            mAttachInfo.mIgnoreDirtyState = true;
        }

        // Add the new dirty rect to the current one
        localDirty.union(dirty.left, dirty.top, dirty.right, dirty.bottom);
        // Intersect with the bounds of the window to skip
        // updates that lie outside of the visible region
        final float appScale = mAttachInfo.mApplicationScale;
        final boolean intersected = localDirty.intersect(0, 0,
                (int) (mWidth * appScale + 0.5f), (int) (mHeight * appScale + 0.5f));
        if (!intersected) {
            localDirty.setEmpty();
        }
        if (!mWillDrawSoon && (intersected || mIsAnimating)) {
            // 上面的设置和调整,最终调用scheduleTraversals()
            scheduleTraversals();
        }
    }    

    void scheduleTraversals() {
        if (!mTraversalScheduled) {
            mTraversalScheduled = true;
            mTraversalBarrier = mHandler.getLooper().getQueue().postSyncBarrier();
            mChoreographer.postCallback(
                    Choreographer.CALLBACK_TRAVERSAL, mTraversalRunnable, null);
            if (!mUnbufferedInputDispatch) {
                scheduleConsumeBatchedInput();
            }
            notifyRendererOfFramePending();
            pokeDrawLockIfNeeded();
        }
    }    

看到这里,我们马上联想起之前分析的View#requestLayout(),同样是scheduleTraversals(),但是从打印数据可知,View#invalidate()是不会执行测量与布局的,但是目前来看它们最终调用的方法可是一致的。

我们可以留意一下之前的ViewRootImpl#requestLayout()方法中,主动将一个全局变量mLayoutRequested设置为true;那么大胆猜测这个对象肯定会影响到performMeasure()与performLayout(),我们翻一下ViewRootImpl#performTraversals()

    private void performTraversals() {
    
    ···
        boolean layoutRequested = mLayoutRequested && (!mStopped || mReportNextDraw); 
    ···
        boolean windowShouldResize = layoutRequested && windowSizeMayChange
            && ((mWidth != host.getMeasuredWidth() || mHeight != host.getMeasuredHeight())
                || (lp.width == ViewGroup.LayoutParams.WRAP_CONTENT &&
                        frame.width() < desiredWindowWidth && frame.width() != mWidth)
                || (lp.height == ViewGroup.LayoutParams.WRAP_CONTENT &&
                        frame.height() < desiredWindowHeight && frame.height() != mHeight));
    ···
        if (mFirst || windowShouldResize || insetsChanged || viewVisibilityChanged || params != null || mForceNextWindowRelayout) {
                ···
                performMeasure(childWidthMeasureSpec, childHeightMeasureSpec);
                ···
            }
        ···
        final boolean didLayout = layoutRequested && (!mStopped || mReportNextDraw);
        boolean triggerGlobalLayoutListener = didLayout
                || mAttachInfo.mRecomputeGlobalAttributes;
        if (didLayout) {
            performLayout(lp, mWidth, mHeight);
        }
        ···
    }

对于复杂的ViewRootImpl#performTraversals(),我们抽取一些关键的代码,的确可以验证mLayoutRequested对象是会影响测量和布局对应的方法的,因此可以验证我们一开始的打印数据,View#invalidate()是不会执行测量和布局的。

View#postInvalidate()

从View#invalidate()的注释描述可知,View#invalidate()需要执行在UI线程中,如果在非UI线程需要使用View#postInvalidate(),我们简单地分析一下源码。

    public void postInvalidate() {
        postInvalidateDelayed(0);
    }
    
    public void postInvalidate(int left, int top, int right, int bottom) {
        postInvalidateDelayed(0, left, top, right, bottom);
    }
    
    public void postInvalidateDelayed(long delayMilliseconds, int left, int top, int right, int bottom) {

        // We try only with the AttachInfo because there's no point in invalidating
        // if we are not attached to our window
        final AttachInfo attachInfo = mAttachInfo;
        if (attachInfo != null) {
            final AttachInfo.InvalidateInfo info = AttachInfo.InvalidateInfo.obtain();
            info.target = this;
            info.left = left;
            info.top = top;
            info.right = right;
            info.bottom = bottom;

            attachInfo.mViewRootImpl.dispatchInvalidateRectDelayed(info, delayMilliseconds);
        }
    }    

ViewRootImpl#dispatchInvalidateRectDelayed()

    public void dispatchInvalidateRectDelayed(AttachInfo.InvalidateInfo info, long delayMilliseconds) {
        final Message msg = mHandler.obtainMessage(MSG_INVALIDATE_RECT, info);
        mHandler.sendMessageDelayed(msg, delayMilliseconds);
    }
    
    @Override
    public void handleMessage(Message msg) {
        switch (msg.what) {
            case MSG_INVALIDATE_RECT:
                final View.AttachInfo.InvalidateInfo info = (View.AttachInfo.InvalidateInfo) msg.obj;
                info.target.invalidate(info.left, info.top, info.right, info.bottom);
                info.recycle();
                break;
                ···
        }  
    }    

从源码可知,View#postInvalidate()会发送一个MSG_INVALIDATE_RECT的Handler消息,在接收消息后,同样是执行View#invalidate()方法。

疑问:requestLayout不执行performDraw()?

在翻阅资料的时候,很多地方都会描述到View#requestLayout不执行performDraw(),但是自己的打印结果是会显示执行performDraw()的。我们带着问题翻一下源码。直接定位到ViewRootImpl#performTraversals的performDraw()

    private void performTraversals() {
        ···
        // dispatchOnPreDraw()返回注释是:如果当前绘制应该被取消和重新调度,则为True,否则为false。
        // final boolean isViewVisible = viewVisibility == View.VISIBLE; 只要是显示的View,cancelDraw为true
        boolean cancelDraw = mAttachInfo.mTreeObserver.dispatchOnPreDraw() || !isViewVisible;

        // cancelDraw通过dispatchOnPreDraw()的注释解析和isViewVisible,得出cancelDraw应该为false
        // newSurface默认为false,在测量判断逻辑中,在判断是否新的Surface会设置为true,这里应该是false
        // 因为会执行performDraw()
        if (!cancelDraw && !newSurface) {
            if (mPendingTransitions != null && mPendingTransitions.size() > 0) {
                for (int i = 0; i < mPendingTransitions.size(); ++i) {
                    mPendingTransitions.get(i).startChangingAnimations();
                }
                mPendingTransitions.clear();
            }

            performDraw();
        }
    
    }

ViewRootImpl#performDraw()

    private void performDraw() {
        // Display.STATE_OFF表示显示状态:显示关闭。
        // mReportNextDraw对象默认false,可在ViewRootImpl#reportNextDraw()中设置为true,但是第一个判断已经为false,不影响判断
        if (mAttachInfo.mDisplayState == Display.STATE_OFF && !mReportNextDraw) {
            return;
        } else if (mView == null) {// 必然不为null
            return;
        }

        final boolean fullRedrawNeeded = mFullRedrawNeeded || mReportNextDraw;
        mFullRedrawNeeded = false;

        mIsDrawing = true;
        Trace.traceBegin(Trace.TRACE_TAG_VIEW, "draw");

        boolean usingAsyncReport = false;
        if (mReportNextDraw && mAttachInfo.mThreadedRenderer != null
                && mAttachInfo.mThreadedRenderer.isEnabled()) {
            usingAsyncReport = true;
            mAttachInfo.mThreadedRenderer.setFrameCompleteCallback((long frameNr) -> {
                // TODO: Use the frame number
                pendingDrawFinished();
            });
        }

        try {
            // 最重点是这句,draw()方法的执行,能影响这段代码的执行,只有上面的两个return逻辑。
            boolean canUseAsync = draw(fullRedrawNeeded);
            if (usingAsyncReport && !canUseAsync) {
                mAttachInfo.mThreadedRenderer.setFrameCompleteCallback(null);
                usingAsyncReport = false;
            }
        } finally {
            mIsDrawing = false;
            Trace.traceEnd(Trace.TRACE_TAG_VIEW);
        }
        ···
    }    

从上面的判断可以推断到draw()是会被执行,与网上得出结论不一致,暂时没得出什么原因,如有分析错误和不足的地方,希望指定一下。

总结

步骤图

View绘制步骤是performMeasure()、performLayout()、performDraw(),我们经过对invalidate和requestLayout的源码分析,可以得出。invalidate()方法只会执行performDraw()方法;而requestLayout()方法会执行performMeasure()、performLayout()、performDraw()。在对应的应用场景,如果只是View的显示内容发生变化且不改变View的大小和位置,则使用invalidate(),如果大小、位置、内容都发生改变则调用requestLayout()。

今天的文章你需要了解下Android View的更新requestLayout与重绘invalidate分享到此就结束了,感谢您的阅读。

版权声明:本文内容由互联网用户自发贡献,该文观点仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容, 请发送邮件至 举报,一经查实,本站将立刻删除。
如需转载请保留出处:https://bianchenghao.cn/20458.html

(0)
编程小号编程小号

相关推荐

发表回复

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