官方描述：
根据系统窗体里的元素比如状态栏来调整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
}
}
}
参考链接
