cover
在 Android Translucent Status Bar 系列中，我基于“给哪个View设置fitsSystemWindows属性”的角度分析了Android对fitsSystemWindows的处理；这篇文章，我们把这个属性的处理过程详细分析一下，同时解决这个属性在另一个场景中的问题——ViewPager。
如果你不知道这个属性或者不知道WindowInsets是什么，推荐看一下Why would I want to fitsSystemWindows?
处理流程
我们知道View树的根节点是DecorView，而DecorView又是由ViewRootImpl管理的。ViewRootImpl负责View树和Window之间的消息发送和事件传递，ViewRootImpl通过Stub接收Window的消息。
WindowInsets是Window在大小发生变化的时候，回调传递给ViewRootImpl的。ViewRootImpl会保存WindowInsets的值，在performTraversal方法中，如果mApplyInsetsRequested标记为true，则执行WindowInsets的分发，具体为调用dispatchApplyInsets方法。
Android Translucent Status Bar 系列对WindowInsets分发的总结：
深度遍历，从上至下依次消费Insets，直到WindowInsets的isConsumed方法返回true
这个遍历就是dispatchApplyInsets方法触发的（API v25）：
void dispatchApplyInsets(View host) {
host.dispatchApplyWindowInsets(getWindowInsets(true /* forceConstruct */));
}
也就是说DecorView的dispatchApplyWindowInsets就是整个遍历分发的入口，而DecorView的实现也是继承自ViewGroup的实现。
Android的UI框架中，对WindowInsets的处理基本都使用View和ViewGroup的默认实现：
View.dispatchApplyWindowInsets(WindowInsets)
public WindowInsets dispatchApplyWindowInsets(WindowInsets insets) {
try {
mPrivateFlags3 |= PFLAG3_APPLYING_INSETS;
// 尝试自己处理
if (mListenerInfo != null && mListenerInfo.mOnApplyWindowInsetsListener != null) {
return mListenerInfo.mOnApplyWindowInsetsListener.onApplyWindowInsets(this, insets);
} else {
return onApplyWindowInsets(insets);
}
} finally {
mPrivateFlags3 &= ~PFLAG3_APPLYING_INSETS;
}
}
View的dispatchApplyWindowInsets方法会直接尝试自己处理，先判断是否有OnApplyWindowInsetsListener，有的话调用OnApplyWindowInsetsListener的处理方法，否则调用onApplyWindowInsets方法。
<span id="PFLAG3_APPLYING_INSETS">PFLAG3_APPLYING_INSETS</span>表示正在分发Windowinsets处理，防止循环调用。
View.onApplyWindowInsets(WindowInsets)
public WindowInsets onApplyWindowInsets(WindowInsets insets) {
if ((mPrivateFlags3 & PFLAG3_FITTING_SYSTEM_WINDOWS) == 0) {
// We weren't called from within a direct call to fitSystemWindows,
// call into it as a fallback in case we're in a class that overrides it
// and has logic to perform.
if (fitSystemWindows(insets.getSystemWindowInsets())) {
return insets.consumeSystemWindowInsets();
}
} else {
// We were called from within a direct call to fitSystemWindows.
if (fitSystemWindowsInt(insets.getSystemWindowInsets())) {
return insets.consumeSystemWindowInsets();
}
}
return insets;
}
PFLAG3_FITTING_SYSTEM_WINDOWS标记表示正在处理SystemWindowInsets。如果当前没有在处理SystemWindowInsets，调用fitSystemWindows方法处理；否则调用fitSystemWindowsInt方法直接设置padding；如果这两个方法返回true，消费SystemWindowInsets。
SystemWindowInsets是WindowInsets的最常见一种，另外还有StableInsets(API v21)和WindowDecorInsets。
StableInsets和SystemWindowInsets类似，表示被StatusBar等遮盖的区域，不同的是StableInsets不会随着StatusBar的隐藏和显示变化。沉浸式全屏下，StatusBar可以通过手势呼出，StableInsets不会发生变化。
WindowDecorInsets为预留属性，忽略。
消费SystemWindowInsets是将SystemWindowInsets属性置为空，并将已消费的标记为置为true。
View.fitSystemWindow(Rect)
protected boolean fitSystemWindows(Rect insets) {
if ((mPrivateFlags3 & PFLAG3_APPLYING_INSETS) == 0) {
if (insets == null) {
// Null insets by definition have already been consumed.
// This call cannot apply insets since there are none to apply,
// so return false.
return false;
}
// If we're not in the process of dispatching the newer apply insets call,
// that means we're not in the compatibility path. Dispatch into the newer
// apply insets path and take things from there.
try {
mPrivateFlags3 |= PFLAG3_FITTING_SYSTEM_WINDOWS;
return dispatchApplyWindowInsets(new WindowInsets(insets)).isConsumed();
} finally {
mPrivateFlags3 &= ~PFLAG3_FITTING_SYSTEM_WINDOWS;
}
} else {
// We're being called from the newer apply insets path.
// Perform the standard fallback behavior.
return fitSystemWindowsInt(insets);
}
}
这个方法是API v20开始已经标记过时的方法，调用这个方法是为了保证基于之前版本开发的逻辑能够正常运行。
首先判断是否有PFLAG3_APPLYING_INSETS标记，前文提到该标记位表示正在分发WindowInsets处理，如果正在分发，那么就直接调用fitSystemWindowsInt方法；否则针对SystemWindowInsets进行分发，并设置PFLAG3_FITTING_SYSTEM_WINDOWS标记。View.onApplyWindowInsets(WindowInsets)方法判断如果存在该标记，就直接调用fitSystemWindowsInt方法。
View.fitSystemWindowsInt(Rect)
private boolean fitSystemWindowsInt(Rect insets) {
if ((mViewFlags & FITS_SYSTEM_WINDOWS) == FITS_SYSTEM_WINDOWS) {
mUserPaddingStart = UNDEFINED_PADDING;
mUserPaddingEnd = UNDEFINED_PADDING;
Rect localInsets = sThreadLocal.get();
if (localInsets == null) {
localInsets = new Rect();
sThreadLocal.set(localInsets);
}
boolean res = computeFitSystemWindows(insets, localInsets);
mUserPaddingLeftInitial = localInsets.left;
mUserPaddingRightInitial = localInsets.right;
internalSetPadding(localInsets.left, localInsets.top,
localInsets.right, localInsets.bottom);
return res;
}
return false;
}
这个方法就是真正消费SystemWindowInsets的地方。首先判断是否设置了fitsSystemWindows属性，最终使用internalSetPadding方法设置padding，注意这里会直接覆盖已经设置好的padding。当然这样也可能导致一些问题，后面我们会说到。
ViewGroup.dispatchApplyWindowInsets(WindowInsets)
@Override
public WindowInsets dispatchApplyWindowInsets(WindowInsets insets) {
insets = super.dispatchApplyWindowInsets(insets);
if (!insets.isConsumed()) {
final int count = getChildCount();
for (int i = 0; i < count; i++) {
insets = getChildAt(i).dispatchApplyWindowInsets(insets);
if (insets.isConsumed()) {
break;
}
}
}
return insets;
}
上面的一系列方法都是保证View能处理WindowInsets，最后看下ViewGroup是如何将WindowInsets分发给子View的。在遍历子View分发之前，首先调用了super.dispatchApplyWindowInsets方法，这实际上就是调用了View.dispatchApplyWindowInsets方法，通过前文的分析，View的实现就是自己处理，最终调用fitSystemWindowsInt，而View是否处理的唯一条件，就是是否设置了fitsSystemWindows属性。
这里可以得出一个结论：如果ViewGroup设置了fitsSystemWindows属性，那么将自己消费WindowInsets，而不会向下分发。
流程图
下面是整个分发过程的流程图。通常起始点在ViewRootImpl的dispatchApplyInsets方法，View的onApplyWindowInsets方法依然调用了废弃的fitSystemWindow方法是为了兼容有些覆写该方法的自定义View（兼容真是很麻烦），而API v21以后的fitSystemWindow方法再次调用了dispatchApplyWindowInsets方法，这样保证无论从dispatchApplyWindowInsets方法还是fitSystemWindow方法进入的处理流程，都可以完整调用onApplyWindowInsets方法和fitSystemWindow方法。
另外，onApplyWindowInsets方法也是public的，所以可以跳过dispatchApplyWindowInsets直接调用onApplyWindowInsets，为了保证分发过程的完整性，直接调用onApplyWindowInsets，也会在当前View中执行一次完整的dispatch -> apply流程。
overall
自定义View、ViewGroup
通过上面的分析，我们可以得到一些有用的信息：
- 并不是每次布局都会分发WindowInsets，只有当WindowInsets发生变化时，ViewRootImpl才会主动分发。如果子View需要更新WindowInsets，调用
ViewCompaxt.requestApplyInsets()方法。 -
dispatchApplyWindowInsets方法用于分发。 - 消费WindowInsets的方法有两个：
OnApplyWindowInsetsListener或者覆写onApplyWindowInsets方法，因为后者是API v20才添加的，所以通常使用前者。 - 如果不希望执行默认的消费方式（padding），覆写前文的两个方法自行处理。
- 对于ViewGroup，如果设置了fitsSystemWindows属性，就一定会消费WindowInsets（不考虑overscan逻辑）。
- ViewGroup会优先尝试自己消费WindowInsets，然后才进行分发。
下面讨论几个自定义View的例子，看下Android官方的实现中是怎么处理WindowInsets的。当我们需要自定义实现WindowInsets的处理时，也可以参考。
CoordinatorLayout
CoordinatorLayout覆写了默认实现，最终通过dispatchApplyWindowInsetsToBehaviors方法将WindowInsets分发给Behavior的onApplyWindowInsets方法。
在onAttachToWindow方法中，CoordinatorLayout包含如下逻辑：
if (mLastInsets == null && ViewCompat.getFitsSystemWindows(this)) {
// We're set to fitSystemWindows but we haven't had any insets yet...
// We should request a new dispatch of window insets
ViewCompat.requestApplyInsets(this);
}
CoordinatorLayout会缓存WindowInsets，当Attach到window上时，如果没有缓存，就请求刷新WindowInsets，如果CoordinatorLayout并不是在页面初次加载就被添加到View上，比如在ViewPager中，这个方法就能保证及时更新WindowInsets。
通过上面我们分析的结论，CoordinatorLayout只有当被设置fitsSystemWindows属性时才会执行自己的分发逻辑。所以对于需要消费WindowInsets的直接子View，有两种处理WindowInsets的方式：
- 给CoordinatorLayout设置fitsSystemWindows，子View不设置fitsSystemWindows属性，然后自定义Behavior实现
onApplyWindowInsets方法处理。 - CoordinatorLayout不设置fitsSystemWindows属性，子View通过上面第3点结论处理。
CollapsingToolbarLayout
CollapsingToolbarLayout同样使用OnApplyWindowInsetsListener处理WindowInsets，在回调中CollapsingToolbarLayout缓存WindowInsets，在onLayout、OffsetUpdateListener、绘制scrim中计算偏移量。具体可在源码中搜索mLastInsets。
有一个额外逻辑是：
@Override
protected void onAttachedToWindow() {
super.onAttachedToWindow();
// Add an OnOffsetChangedListener if possible
final ViewParent parent = getParent();
if (parent instanceof AppBarLayout) {
// Copy over from the ABL whether we should fit system windows
ViewCompat.setFitsSystemWindows(this, ViewCompat.getFitsSystemWindows((View) parent));
// ...
}
}
如果父View是AppBarLayout，CollapsingToolbarLayout跟随父View的fitsSystemWindows属性。你可能会问如果父View设置了fitsSystemWindows属性，那CollapsingToolbarLayout即便也设置了这个属性，不也拿不到消费的机会了吗？
答案是不会。AppBarLayout、CollapsingToolbarLayout是关联使用的，所以耦合性很高。AppBarLayout中对WindowInsets的处理仅仅是记录和使用，并没有消费，真正消费是在CollapsingToolbarLayout中。感兴趣可以查看AppBarLayout的代码。
[Digging] Android Translucent StatusBar 3这篇文章中提到了CollapsingToolbarLayout处理WindowInsets引入的一个问题，虽然在onLayout中正确处理了偏移，但是onMeasure中没有根据WindowInsets扩大View尺寸，导致本来够大的View尺寸在设置Padding后放不下子View了。这在自定义ViewGroup处理WindowInsets的时候要特别注意。
ViewPager
如果一个ViewGroup有多个子View需要处理WindowInsets，应该怎么处理？这就是ViewPager面临的问题。我们知道如果要给子View分发WindowInsets，只需要调用子View的dispatchApplyWindowInsets方法即可。如果多个子View需要处理，那么相同一份WindowInsets，分发多次即可，当然要分发副本，否则就被子View消费了。
下面是ViewPager的实现：
ViewCompat.setOnApplyWindowInsetsListener(this,
new android.support.v4.view.OnApplyWindowInsetsListener() {
private final Rect mTempRect = new Rect();
@Override
public WindowInsetsCompat onApplyWindowInsets(final View v,
final WindowInsetsCompat originalInsets) {
// First let the ViewPager itself try and consume them...
final WindowInsetsCompat applied =
ViewCompat.onApplyWindowInsets(v, originalInsets);
if (applied.isConsumed()) {
// If the ViewPager consumed all insets, return now
return applied;
}
// Now we'll manually dispatch the insets to our children. Since ViewPager
// children are always full-height, we do not want to use the standard
// ViewGroup dispatchApplyWindowInsets since if child 0 consumes them,
// the rest of the children will not receive any insets. To workaround this
// we manually dispatch the applied insets, not allowing children to
// consume them from each other. We do however keep track of any insets
// which are consumed, returning the union of our children's consumption
final Rect res = mTempRect;
res.left = applied.getSystemWindowInsetLeft();
res.top = applied.getSystemWindowInsetTop();
res.right = applied.getSystemWindowInsetRight();
res.bottom = applied.getSystemWindowInsetBottom();
for (int i = 0, count = getChildCount(); i < count; i++) {
final WindowInsetsCompat childInsets = ViewCompat
.dispatchApplyWindowInsets(getChildAt(i), applied);
// Now keep track of any consumed by tracking each dimension's min
// value
res.left = Math.min(childInsets.getSystemWindowInsetLeft(), res.left);
res.top = Math.min(childInsets.getSystemWindowInsetTop(), res.top);
res.right = Math.min(childInsets.getSystemWindowInsetRight(), res.right);
res.bottom = Math.min(childInsets.getSystemWindowInsetBottom(), res.bottom);
}
// Now return a new WindowInsets, using the consumed window insets
return applied.replaceSystemWindowInsets(
res.left, res.top, res.right, res.bottom);
}
});
源码的注释也说明了这个问题，为了让每个子View都收到WindowInsets事件，需要逐个分发。
问题
但是这个实现有个小问题，你发现了吗？
最后的return语句，返回了一个未被消费的，但是值为0的insets。ViewPager也是ViewGroup的子类，在dispatchApplyWindowInsets(WindowInsets)方法中，super.dispatchApplyWindowInsets(insets)方法的调用会触发上文的OnApplyWindowInsetsListener.onApplyWindowInsets(View, WindowInsetsCompat)，但是之后的逻辑：
if (!insets.isConsumed()) {
// 分发给子View
}
会使得判断条件为真（没有被消费），进而继续分发，这样第一个子View（getChildAt(0)，而不一定是Adapter中的index）就会再收到一次WindowInsets，而这个WindowInsets不再是副本，子View消费掉之后，会直接跳出循环并返回。（完整代码见上文）
if (insets.isConsumed()) {
break;
}
导致的结果，就是第一个子View的WindowInsets被重置为0。
源码注释还说了是 "the consumed window insets"……
解决
解决方法，就是重新实现这个listener，在最后返回一个被消费的insets：
// ...
return applied.replaceSystemWindowInsets(
res.left, res.top, res.right, res.bottom).consumeSystemWindowInsets();
是的，多一个方法调用即可。
网友评论