官方描述:
根据系统窗体里的元素比如状态栏来调整View的布局。如果被设为true,控件的padding将会被调整为顶部留出一个statusBar的空间。类似于伪代码paddingTop="statusBarHeight"。
重点说明:
当布局内容可以延伸到状态栏,被状态栏覆盖时(比如设置了View.SYSTEM_UI_FLAG_LAYOUT_FULLSCREEN,默认不会有这个flag,布局不会延伸到状态栏下),该属性才会起作用
静态布局中多个View的fitSystemWindows都为true,只对最外层(如同层,则为第一个)的View起作用
动态添加子View过程中,只会对第一次添加的子View起作用
上述2、3点和官方描述的行为都是默认行为,而这个行为可以通过自定义View来进行个性化,比如CoordinateLayout就重载了这种行为(可以参考下方链接文章)
多Fragment时fitSystemWindows无效的坑
最近一个项目中,有几个界面是一个Activity装载多个Fragment的形式,为了实现沉浸式布局,将Activity的decorView加上View.SYSTEM_UI_FLAG_LAYOUT_FULLSCREEN(使布局延伸到状态栏),所有Fragment的布局中,则将在最顶部的View(比如Toolbar)的fitSystemWindows设为true。 却惊讶地发现,只有第一个被加入到Activity的Fragment显示正常,随后被添加的Fragment都适配错误,如下图:
原因
添加Fragment的过程可看作往容器布局添加子View的过程。当第一个Fragment被添加到容器布局时,容器布局找出fitSystemWindows为true的子View,并为其paddingTop一个状态栏的高度,当其他Fragment随后被添加时,上述的paddingTop适配已经被消费过一次,并不会再为其后添加的View进行适配(默认行为),因此我们要自定义容器布局View,使其每个子View都消费一次ViewGroup分发的WindowsInsets,相当于每个子Fragment都能适配状态栏
注意
此方法实现的布局容器会对其每个子View都适配一次
实现代码
我一般用FrameLayout作为容器布局,因此继承了FrameLayout,每次addView都requestApplyInsets请求分发WindowInsets,并且保存当前添加的子View,在重载方法onApplyWindowInsets中调用子View的dispatchApplyWindowInsets,使每个子View都有机会消费一次insets
class WindowInsetsFrameLayout: FrameLayout {
private var requestView: View? = null
constructor(context: Context): this(context, null)
constructor(context: Context, attrs: AttributeSet?): this(context, attrs, 0)
constructor(context: Context, attrs: AttributeSet?, defStyleAttr: Int): super(context, attrs, defStyleAttr) {
setOnHierarchyChangeListener(object : OnHierarchyChangeListener {
override fun onChildViewAdded(parent: View?, child: View?) {
requestView = child
requestApplyInsets() //子View添加时申请解析inset
}
override fun onChildViewRemoved(parent: View?, child: View?) {}
})
}
override fun onApplyWindowInsets(insets: WindowInsets?): WindowInsets? {
val t = requestView
return if (t == null) {
super.onApplyWindowInsets(insets)
} else {
val res = t.dispatchApplyWindowInsets(insets) //子View解析
requestView = null
res
}
}
}
复制代码
参考链接