[Digging]android:fitsSystemWindows

cover

Android Translucent Status Bar 系列中,我基于“给哪个View设置fitsSystemWindows属性”的角度分析了Android对fitsSystemWindows的处理;这篇文章,我们把这个属性的处理过程详细分析一下,同时解决这个属性在另一个场景中的问题——ViewPager。

如果你不知道这个属性或者不知道WindowInsets是什么,推荐看一下Why would I want to fitsSystemWindows?

处理流程(API20)

我们知道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):

1
2
3
void dispatchApplyInsets(View host) {
host.dispatchApplyWindowInsets(getWindowInsets(true /* forceConstruct */));
}

也就是说DecorView的dispatchApplyWindowInsets就是整个遍历分发的入口,而DecorView的实现也是继承自ViewGroup的实现。

Android的UI框架中,对WindowInsets的处理基本都使用View和ViewGroup的默认实现:

View.dispatchApplyWindowInsets(WindowInsets)

1
2
3
4
5
6
7
8
9
10
11
12
13
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方法。

PFLAG3_APPLYING_INSETS表示正在分发Windowinsets处理,防止循环调用。

View.onApplyWindowInsets(WindowInsets)

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
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)

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
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)

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
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)

1
2
3
4
5
6
7
8
9
10
11
12
13
14
@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

通过上面的分析,我们可以得到一些有用的信息:

  1. 并不是每次布局都会分发WindowInsets,只有当WindowInsets发生变化时,ViewRootImpl才会主动分发。如果子View需要更新WindowInsets,调用ViewCompaxt.requestApplyInsets()方法。
  2. dispatchApplyWindowInsets方法用于分发。
  3. 消费WindowInsets的方法有两个:OnApplyWindowInsetsListener或者覆写onApplyWindowInsets方法,因为后者是API v20才添加的,所以通常使用前者。
  4. 如果不希望执行默认的消费方式(padding),覆写前文的两个方法自行处理。
  5. 对于ViewGroup,如果设置了fitsSystemWindows属性,就一定会消费WindowInsets(不考虑overscan逻辑)。
  6. ViewGroup会优先尝试自己消费WindowInsets,然后才进行分发。

下面讨论几个自定义View的例子,看下Android官方的实现中是怎么处理WindowInsets的。当我们需要自定义实现WindowInsets的处理时,也可以参考。

CoordinatorLayout

CoordinatorLayout覆写了默认实现,最终通过dispatchApplyWindowInsetsToBehaviors方法将WindowInsets分发给Behavior的onApplyWindowInsets方法。

在onAttachToWindow方法中,CoordinatorLayout包含如下逻辑:

1
2
3
4
5
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的方式:

  1. 给CoordinatorLayout设置fitsSystemWindows,子View不设置fitsSystemWindows属性,然后自定义Behavior实现onApplyWindowInsets方法处理。
  2. CoordinatorLayout不设置fitsSystemWindows属性,子View通过上面第3点结论处理。

CollapsingToolbarLayout

CollapsingToolbarLayout同样使用OnApplyWindowInsetsListener处理WindowInsets,在回调中CollapsingToolbarLayout缓存WindowInsets,在onLayout、OffsetUpdateListener、绘制scrim中计算偏移量。具体可在源码中搜索mLastInsets

有一个额外逻辑是:

1
2
3
4
5
6
7
8
9
10
11
12
13
@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的实现:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
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),但是之后的逻辑:

1
2
3
if (!insets.isConsumed()) {
// 分发给子View
}

会使得判断条件为真(没有被消费),进而继续分发,这样第一个子View(getChildAt(0),而不一定是Adapter中的index)就会再收到一次WindowInsets,而这个WindowInsets不再是副本,子View消费掉之后,会直接跳出循环并返回。(完整代码见上文))

1
2
3
if (insets.isConsumed()) {
break;
}

导致的结果,就是第一个子View的WindowInsets被重置为0。

源码注释还说了是 “the consumed window insets”……

解决

解决方法,就是重新实现这个listener,在最后返回一个被消费的insets:

1
2
3
// ...
return applied.replaceSystemWindowInsets(
res.left, res.top, res.right, res.bottom).consumeSystemWindowInsets();

是的,多一个方法调用即可。

API 19

update 2017-11-15

ViewCompat并不能解决所有版本的兼容性问题,在API 19上,ViewCompat.setOnApplyWindowInsetsListener方法并不会产生任何效果,所以类似上面ViewPager的实现方式,在API 19上就不会有预期的适配效果。那怎么处理API 19上的兼容问题呢?

如果没有特别有力的理由(很可能没有),在API 19上就不要设置透明导航栏了:P。

万一老板非要有,有没有办法?有。

在没有dispatch/apply逻辑之前,也就是API 19上,View通过fitSystemWindows(Rect)方法由上至下应用WindowInsets。那么我们也就通过这个方法来处理类似ViewPager这种需要分发给多个子View的情况。

这个解决方法并不只针对ViewPager,只要是需要干预WindowInsets的分发流程,在某一级将同一WindowInsets同时分发给多个View处理,都可以使用本文提到的方法。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
@Override
protected boolean fitSystemWindows(Rect insets) {
if (Build.VERSION.SDK_INT == Build.VERSION_CODES.KITKAT) {
// fitSystemWindows 的声明:Method fitSystemWindows;
// 这里是为了不需要每次都重新反射获取一遍方法。
if (fitSystemWindows == null) {
try {
fitSystemWindows = View.class.getDeclaredMethod("fitSystemWindows", Rect.class);
fitSystemWindows.setAccessible(true);
} catch (NoSuchMethodException e) {
e.printStackTrace();
}
}
if (fitSystemWindows == null) {
return super.fitSystemWindows(insets);
}
final int count = getChildCount();
for (int i = 0; i < count; i++) {
// 防止每次都创建一个新的Rect
if (mTempRect == null) {
mTempRect = new Rect();
}
mTempRect.set(insets);
try {
// 这里fitSystemWindows方法的参数Rect,不能直接使用insets,
// 因为View在消费insets的时候,会修改insets为剩余值;
// 因为我们要分发给多个子View,所以这里需要每次都传入初始值。
fitSystemWindows.invoke(getChildAt(i), mTempRect);
} catch (IllegalAccessException e) {
e.printStackTrace();
} catch (InvocationTargetException e) {
e.printStackTrace();
}
}
return true;
}
return super.fitSystemWindows(insets);
}

因为API 19上View只通过这个方法分发Insets,我们也就只能通过这个方法来干预分发的过程,遗憾的是因为fitSystemWindowsprotected方法,所以只能通过反射来调用。

还有一点要注意,API 20开始我们可以通过Listener来控制是否分发,但是API 19上,必须显示声明fitSystemWindow属性,所以还要加这一行代码:

1
setFitsSystemWindows(Build.VERSION.SDK_INT == Build.VERSION_CODES.KITKAT);