android 设置状态栏文字颜色引起的页面无法重新layout的问题

基于api26

前言

android开发经常用到沉浸式，此时为了防止用户无法看清状态栏文字的颜色，还需要对其颜色进行主动更改。api>=23可以采用如下方式修改状态文字颜色：

        Window window = activity.getWindow();
        window.addFlags(WindowManager.LayoutParams.FLAG_DRAWS_SYSTEM_BAR_BACKGROUNDS);
        window.clearFlags(WindowManager.LayoutParams.FLAG_TRANSLUCENT_STATUS);

        View decorView = window.getDecorView();
        int visibility = decorView.getSystemUiVisibility();
        if (isDarkMode) {
            visibility |= View.SYSTEM_UI_FLAG_LIGHT_STATUS_BAR;
        } else {
            visibility &= ~View.SYSTEM_UI_FLAG_LIGHT_STATUS_BAR;
        }
        decorView.setSystemUiVisibility(visibility);

最近开发新的页面就碰到了一个修改状态栏文字颜色的坑。

问题描述

开发的页面设置了沉浸式+修改状态颜色的逻辑，根布局设置了android:fitsSystemWindows="true"，只有一个RecyclerView，RecyclerView可以中的数据可以控制正序/倒序排列。问题如下：

1、在未修改过状态栏颜色的时候，RecyclerView的正序或者倒序排列功能正常；
2、一旦修改过状态栏颜色，修改RecyclerView的顺序后，RecyclerView不会主动刷新显示，需要手动触碰，才会由触摸事件触发刷新显示的逻辑。

问题追踪

RecyclerView不刷新显示，最先想到的就是没有调用notifyXX方法，不过显然我们调用了。
再看notifyXX方法最终会调用requestLayout请求重新布局，而问题就出在了这里。首先看下源码：

    public void requestLayout() {
        ...
        mPrivateFlags |= PFLAG_FORCE_LAYOUT;
        mPrivateFlags |= PFLAG_INVALIDATED;

        if (mParent != null && !mParent.isLayoutRequested()) {
            mParent.requestLayout();
        }
        ...
    }

留意一下PFLAG_FORCE_LAYOUT标志位。
在调试时，发现从RecyclerView的parent一直到DecorView的直接子View，isLayoutRequested()方法全部返回true，导致requestLayout无法向上传递。

该方法如下：

    public boolean isLayoutRequested() {
        return (mPrivateFlags & PFLAG_FORCE_LAYOUT) == PFLAG_FORCE_LAYOUT;
    }

但奇怪的是DecorView的isLayoutRequested()返回false，并且此时并没有在进行重新布局。也就是说我们整个页面的requestLayout全都不好使了！形象的说，就是神经出了问题，局部组织和大脑的联系断了。
很奇怪，因为正常的流程是，只要isLayoutRequested()返回true，就说明布局流程还在继续，然后layout函数会将LayoutRequested复位，如下：

    public void layout(int l, int t, int r, int b) {
        ...
        mPrivateFlags &= ~PFLAG_FORCE_LAYOUT;
        ...
    }

问题原因

调试过程比较漫长，只说下结论吧。
在系统修改状态栏颜色时，会触发一次从新布局，布局流程如下：

ViewRootImpl中：

首先 measureHierarchy，触发view tree的测量工作；
然后dispatchApplyInsets，设置了fitSystemWindow=true的view最后会调用requestLayout函数
最后performLayout，触发view tree的布局工作。

问题就出在dispatchApplyInsets被夹在了中间。首先说view tree的根布局是DecorView，View的measure方法如下：

    public final void measure(int widthMeasureSpec, int heightMeasureSpec) {
        ...
        final boolean forceLayout = (mPrivateFlags & PFLAG_FORCE_LAYOUT) == PFLAG_FORCE_LAYOUT;
        ...
        if (forceLayout || needsLayout) {
            ...
            mPrivateFlags |= PFLAG_LAYOUT_REQUIRED;
        }
        ...
    }

这里留意一下PFLAG_LAYOUT_REQUIRED标志位。

然后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;
        ...
    }

正常流程是，子类requestLayout，为整个view tree设置上PFLAG_FORCE_LAYOUT标志位；然后从根布局开始，measure时，检测到PFLAG_FORCE_LAYOUT，给自身设置PFLAG_LAYOUT_REQUIRED，并且可以调用onMeasure触发子类的measure，依次递归；然后在layout时，检测到PFLAG_LAYOUT_REQUIRED，调用onLayout，触发子类的layout，依次递归。

但改变状态栏颜色时，类似（注意是类似，这里是为了方便理解）直接触发DecorView的requestLayout，子View并无感知，执行完DecorView的measure后，由于没有设置PFLAG_FORCE_LAYOUT，所以并不会调用onMeasure，触发子view的measure，也不会在后面的layout中触发onLayout，进而引发整个view tree的layout事件；而dispatchApplyInsets夹在中间，导致从设置fitSystemWindow=true的View开始一直到DecorView的直接子View，都被设置了PFLAG_FORCE_LAYOUT，但他们各自的layout又不会被触发，所以就出现了神经死掉的现象。

解决方式

毫无疑问，这是一个系统bug。一个简单的解决方式是，在设置状态栏颜色之前，调用如下代码：

                    View view1 = 设置了fitSystemWindow的View;
                    while (true) {
                        view1.forceLayout();
                        ViewParent parent = view1.getParent();
                        if (parent instanceof View) {
                            view1 = (View) parent;
                        } else {
                            break;
                        }
                    }

forceLayout会强制给View设置上PFLAG_FORCE_LAYOUT标记，这样在设置状态栏颜色触发DecorViewmeasure时，这些view都会measure，同样也会layout，不会出现中间一段死掉的情况。