requestLayout in layout问题

最新推荐文章于 2025-11-11 21:11:51 发布

原创最新推荐文章于 2025-11-11 21:11:51 发布 · 4k 阅读

4 ·

CC 4.0 BY-SA版权

文章标签：

#onLayout #reuqestLay

android_framework源码解析专栏收录该内容

7 篇文章

订阅专栏

本文分析了在自定义View的onLayout方法中调用requestLayout导致的bug，特别是在Android 4.1.2和4.2版本上的严重问题。通过深入ViewRootImpl的源码解析，介绍了该问题的根本原因及不同版本间的处理差异。

requestLayout in layout问题

最近遇到个requestLayout in layout，触发了严重的bug，通过对bug的分析，让我对ViewRootImpl的layout过程有了更深入的了解，在此记录一下。

bug介绍

我在写一个自定义控件(ThreePieceScrollView)的时候，写了如下代码,没想到触发了严重的bug。

   @Override
    protected void onLayout(boolean changed, int l, int t, int r, int b) {
        super.onLayout(changed, l, t, r, b);
        int residue = getHeight() - neck.getHeight() - extraSpace;
        ViewGroup.LayoutParams parms = body.getLayoutParams();
        if (parms.height != residue) {
            LogUtil.fish("修改布局");
            parms.height = residue;
            body.setLayoutParams(parms);
        }
    }

现在仔细分析这个问题,将上述代码稍微调整一下，如下所示，这个问题的关键就是在onLayout里面调用了body.setLayoutParams，导致子view的requestLayout，这会导致什么后果呢？

在高版本手机上没什么问题，但是在4.1.2，4.2上出现了严重bug。
不触发vsync，然后recyclerview的notifyDataSetChanged无效。

基础知识

分析这个bug之前先学点基础知识，预先了解requestLayout的知识，以及PFLAG_FORCE_LAYOUT是如何变化的

requestLayout

先回顾下requestLayout的代码，看L19可知，要想调parent的requestLayout，必须满足mParent.isLayoutRequested()为false,即PFLAG_FORCE_LAYOUT这个flag为false，如果parent的PFLAG_FORCE_LAYOUT为1，那么requestLayout无法上传给parent的。requestLayout是否能触发父view的requestLayout主要看父view的PFLAG_FORCE_LAYOUT是不是0，如果是0就可以触发

    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_FORCE_LAYOUT是如何变化的，forceLayout和requestLayout会导致PFLAG_FORCE_LAYOUT变为1，而layout的末端会将PFLAG_FORCE_LAYOUT置0。

    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;
    }

问题精简

将原问题精简，得到view关系图

子view->A0->A1->A2->A3->A4->父view

我们来看一个例子A3就是在onLayout内写了requestLayout的自定义view
A3代码如下，可以看到在onlayout之后，调用了A1的requestLayout

//A3
   @Override
    protected void onLayout(boolean changed, int l, int t, int r, int b) {
        super.onLayout(changed, l, t, r, b);
        if (...) {
                A1.requestLayout();
        }
    }

根据2条前文的理论来分析整个过程

requestLayout是否能触发父view的requestLayout主要看父view的PFLAG_FORCE_LAYOUT是不是0，如果是0就可以触发
requestLayout会导致PFLAG_FORCE_LAYOUT变为1，而layout的末端会将PFLAG_FORCE_LAYOUT置0。

我们来分析下，

TIME0:初始布局时，在上边L6执行前，发生了什么，此时A3的onLayout即将结束，A2,A1,A0的layout已经结束，所以A2,A1,A0的PFLAG_FORCE_LAYOUT为0，而A3,A4的PFLAG_FORCE_LAYOUT为1.
TIME1:然后调用了A1.requestLayout()，A1想要调用A2的requestLayout，此时A2的PFLAG_FORCE_LAYOUT为0，所以成功调到A2的requestLayout。然后A2想要调用A3的requestLayout，但是此时A3的PFLAG_FORCE_LAYOUT为1，所以A3的requestLayout无法调起，requestLayout递归流程结束。在这个递归流程中，A1,A2调用了requestLayout，A1,A2的PFLAG_FORCE_LAYOUT被置为1。
TIME2：所有layout过程结束，A3 layout结束的时候会把PFLAG_FORCE_LAYOUT给置为0，A4也是，所以此时只有A1,A2的PFLAG_FORCE_LAYOUT还是1。这个时候其实已经有隐患了，layout过程已经结束了，但是A1,A2的PFLAG_FORCE_LAYOUT还是1。
TIME3：A0调用requestLayout试图重新布局，一个view调用requestLayout一般都可以重新布局的，但是这里就不一定了。A0的requestLayout尝试调用A1的requestLayout，但是A1的PFLAG_FORCE_LAYOUT还是1，所以无法触发A1的requestLayout，这样A0的requestLayout就无效了，出现bug。在我实际工程内的表现就是recyclerview的notiftItemChanged和notifyDatasetChanged都无效，这就是大问题了。

STEP	A1	A2	A3	A4
TIME0	0	0	1	1
TIME1	1	1	1	1
TIME2	1	1	0	0

版本变化

按理说，此时这个bug就解决了，我们只要改变布局策略，不要在onLayout内调用requestLayout就好了。但是为什么这个问题在4.1，4.2上必现，但是在5.0，6.0上都不存在呢？
再明确下bug的原因是A1,A2的PFLAG_FORCE_LAYOUT为1，导致TIME3里A0的requestLayout无法上传上去
这我们得看一看ViewRootImpl的代码，先看6.0.1的，去理解为什么6.0.1不会出现此bug

ViewRootImpl.performLayout6.0

其实android考虑到了有人会在onLayout内调用requestLayout，对此他们也有了处理策略，那就是在平常的layout完毕之后来处理这些额外的requestLayout(比如上文的A1的requestLayout)。如下所示，

step1 普通layout.

实际上L10就完成了普通的layout，后边的所有代码都是为了处理这种额外的requestLayout.

//ViewRootImpl
    private void performLayout(WindowManager.LayoutParams lp, int desiredWindowWidth,
            int desiredWindowHeight) {
        mLayoutRequested = false;
        mScrollMayChange = true;
        mInLayout = true;

        final View host = mView;

            host.layout(0, 0, host.getMeasuredWidth(), host.getMeasuredHeight());

            mInLayout = false;
            int numViewsRequestingLayout = mLayoutRequesters.size();
            if (numViewsRequestingLayout > 0) {
                // requestLayout() was called during layout.
                // If no layout-request flags are set on the requesting views, there is no problem.
                // If some requests are still pending, then we need to clear those flags and do
                // a full request/measure/layout pass to handle this situation.
                ArrayList<View> validLayoutRequesters = getValidLayoutRequesters(mLayoutRequesters,
                        false);
                if (validLayoutRequesters != null) {
                    // Set this flag to indicate that any further requests are happening during
                    // the second pass, which may result in posting those requests to the next
                    // frame instead
                    mHandlingLayoutInLayoutRequest = true;

                    // Process fresh layout requests, then measure and layout
                    int numValidRequests = validLayoutRequesters.size();
                    for (int i = 0; i < numValidRequests; ++i) {
                        final View view = validLayoutRequesters.get(i);
                        Log.w("View", "requestLayout() improperly called by " + view +
                                " during layout: running second layout pass");
                        view.requestLayout();
                    }
                    measureHierarchy(host, lp, mView.getContext().getResources(),
                            desiredWindowWidth, desiredWindowHeight);
                    mInLayout = true;
                    host.layout(0, 0, host.getMeasuredWidth(), host.getMeasuredHeight());

                    mHandlingLayoutInLayoutRequest = false;

                    // Check the valid requests again, this time without checking/clearing the
                    // layout flags, since requests happening during the second pass get noop'd
                    validLayoutRequesters = getValidLayoutRequesters(mLayoutRequesters, true);
                    if (validLayoutRequesters != null) {
                        final ArrayList<View> finalRequesters = validLayoutRequesters;
                        // Post second-pass requests to the next frame
                        getRunQueue().post(new Runnable() {
                            @Override
                            public void run() {
                                int numValidRequests = finalRequesters.size();
                                for (int i = 0; i < numValidRequests; ++i) {
                                    final View view = finalRequesters.get(i);
                                    Log.w("View", "requestLayout() improperly called by " + view +
                                            " during second layout pass: posting in next frame");
                                    view.requestLayout();
                                }
                            }
                        });
                    }
                }

            }
        mInLayout = false;
    }

    /**

step2 getValidLayoutRequesters

先看L13，这里用到了一个数组mLayoutRequesters，这个数组里存的就是在layout过程内申请requestLayout的view。

    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;
        }
    }

再回过头看requestLayout的代码，如果在layout过程中调用requestLayout，A1的requestLayout会走到requestLayout的L9 viewRoot.requestLayoutDuringLayout(this) ，返回false，然后mAttachInfo.mViewRequestingLayout=A1

再看viewRoot.requestLayoutDuringLayout(this)这个代码很简单,判断当前view是否在mLayoutRequesters，如果不在的话就加进去，A1被加进去。

   boolean requestLayoutDuringLayout(final View view) {
        if (view.mParent == null || view.mAttachInfo == null) {
            // Would not normally trigger another layout, so just let it pass through as usual
            return true;
        }
        if (!mLayoutRequesters.contains(view)) {
            mLayoutRequesters.add(view);
        }
        if (!mHandlingLayoutInLayoutRequest) {
            // Let the request proceed normally; it will be processed in a second layout pass
            // if necessary
            return true;
        } else {
            // Don't let the request proceed during the second layout pass.
            // It will post to the next frame instead.
            return false;
        }
    }

而A2的requestLayout过程中，由于mAttachInfo.mViewRequestingLayout非空，所以A2不会进入mLayoutRequesters，所以我们的mLayoutRequesters里只有孤独的A1，实际上只有主动发起requestLayout的view才会进入mLayoutRequesters。像A2是当了A1的爹，所以被A1的requestLayout调用起来的，是被动的，不算。

再看performLayout的L19 getValidLayoutRequesters，此时第二个参数传false。
所以我们先看secondLayoutRequests为false的场景，主要2步，过滤layoutRequesters和清parent。

过滤layoutRequesters是把layoutRequesters进行过滤，只有PFLAG_FORCE_LAYOUT标志被设置的，而且非gone的view被选出来进入validLayoutRequesters。代码为L4-L32
清parent，前面选择出一批view了，这批view即将调用requestLayout，这里清parent是把view的父族的PFLAG_FORCE_LAYOUT置为0。代码为L33-L48。为甚要置为0，一开始我没看明白为什么要这么做，然后回头看到了requestLayout是否能触发父view的requestLayout主要看父view的PFLAG_FORCE_LAYOUT是不是0，如果是0就可以触发，要想requestLayout传到顶部，必须让它的父族view的PFLAG_FORCE_LAYOUT置为0，这实际上是为requestLayout扫清障碍。按我们的例子，A2的PFLAG_FORCE_LAYOUT置为0。

    private ArrayList<View> getValidLayoutRequesters(ArrayList<View> layoutRequesters,
            boolean secondLayoutRequests) {

        int numViewsRequestingLayout = layoutRequesters.size();
        ArrayList<View> validLayoutRequesters = null;
        for (int i = 0; i < numViewsRequestingLayout; ++i) {
            View view = layoutRequesters.get(i);
            if (view != null && view.mAttachInfo != null && view.mParent != null &&
                    (secondLayoutRequests || (view.mPrivateFlags & View.PFLAG_FORCE_LAYOUT) ==
                            View.PFLAG_FORCE_LAYOUT)) {
                boolean gone = false;
                View parent = view;
                // Only trigger new requests for views in a non-GONE hierarchy
                while (parent != null) {
                    if ((parent.mViewFlags & View.VISIBILITY_MASK) == View.GONE) {
                        gone = true;
                        break;
                    }
                    if (parent.mParent instanceof View) {
                        parent = (View) parent.mParent;
                    } else {
                        parent = null;
                    }
                }
                if (!gone) {
                    if (validLayoutRequesters == null) {
                        validLayoutRequesters = new ArrayList<View>();
                    }
                    validLayoutRequesters.add(view);
                }
            }
        }
        if (!secondLayoutRequests) {
            // If we're checking the layout flags, then we need to clean them up also
            for (int i = 0; i < numViewsRequestingLayout; ++i) {
                View view = layoutRequesters.get(i);
                while (view != null &&
                        (view.mPrivateFlags & View.PFLAG_FORCE_LAYOUT) != 0) {
                    view.mPrivateFlags &= ~View.PFLAG_FORCE_LAYOUT;
                    if (view.mParent instanceof View) {
                        view = (View) view.mParent;
                    } else {
                        view = null;
                    }
                }
            }
        }
        layoutRequesters.clear();
        return validLayoutRequesters;
    }

step3 HandlingLayoutInLayoutRequest

上边拿到了需要重新requestLayout的view数组，马上开始requestLayout，代码如下，这里的每一个requestLayout都能上传到ViewRootImpl，但不会触发vsync，因为写了一个bool值mHandlingLayoutInLayoutRequest（去看看ViewRootImpl的requestLayout是不是有这个mHandlingLayoutInLayoutRequest）。一堆requestLayout之后，直接调用measureHierarchy、host.layout（这也是以前没见过的，以前我认为requestLayout都是触发vsync来刷新的）。按我们的例子，数组里只有A1，A1触发requestLayout并重新布局

                    // Set this flag to indicate that any further requests are happening during
                    // the second pass, which may result in posting those requests to the next
                    // frame instead
                    mHandlingLayoutInLayoutRequest = true;

                    // Process fresh layout requests, then measure and layout
                    int numValidRequests = validLayoutRequesters.size();
                    for (int i = 0; i < numValidRequests; ++i) {
                        final View view = validLayoutRequesters.get(i);
                        Log.w("View", "requestLayout() improperly called by " + view +
                                " during layout: running second layout pass");
                        view.requestLayout();
                    }
                    measureHierarchy(host, lp, mView.getContext().getResources(),
                            desiredWindowWidth, desiredWindowHeight);
                    mInLayout = true;
                    host.layout(0, 0, host.getMeasuredWidth(), host.getMeasuredHeight());

                    mHandlingLayoutInLayoutRequest = false;

step4 check again

后边的代码其实不是很重要，因为重新layout了一次，所以可能又触发了未完结的requestLayout，这可以无限循环下去。android对第二次还在mLayoutRequesters内的view，在当前帧不再重新布局，而是把他post一下丢到下一帧处理。

简单点解释为什么6.0中，不会存在上述bug，因为在ViewRootImpl的layout之后，android做了处理，把A1的requestLayout给处理了，所以最后A1,A2的PFLAG_FORCE_LAYOUT都变为了0，那么TIME3时A0的requestLayout就可以成功传递到顶部并触发vsync。

ViewRootImpl.performLayout4.2.1

再看看4.2.1为什么有bug，可以看到performLayout除了host.layout根本没做啥，这种requestLayout in layout问题根本没去解决,那么android是在哪个版本开始处理此问题的呢？我查了下源码，是在4.3解决这个问题的。所以要支持4.3以下的，就不要在onLayout内调用requestLayout。我最后的解决方法是把布局策略移到measure里面去，重新onMeasure方法，并且没有在onMeasure里触发requestLayout。

private void performLayout() {
       mLayoutRequested = false;
       mScrollMayChange = true;

       final View host = mView;
       if (DEBUG_ORIENTATION || DEBUG_LAYOUT) {
           Log.v(TAG, "Laying out " + host + " to (" +
                   host.getMeasuredWidth() + ", " + host.getMeasuredHeight() + ")");
       }

       Trace.traceBegin(Trace.TRACE_TAG_VIEW, "layout");
       try {
           host.layout(0, 0, host.getMeasuredWidth(), host.getMeasuredHeight());
       } finally {
           Trace.traceEnd(Trace.TRACE_TAG_VIEW);
       }
   }