基于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，不会出现中间一段死掉的情况。