从源码解析WindowInsets：为什么你的fitsSystemWindows总不生效？

从源码解析WindowInsets：为什么你的fitsSystemWindows总不生效？

如果你在Android开发中尝试过沉浸式状态栏、全屏适配或者处理软键盘遮挡，那么android:fitsSystemWindows这个属性大概率让你头疼过。明明在布局文件里设置了true，状态栏却依然和内容重叠；或者在某些自定义ViewGroup里，这个属性仿佛完全失效。网上的解决方案五花八门，有的让你在主题里设置windowTranslucentStatus，有的让你重写onApplyWindowInsets，但很少有人能说清楚，这一切背后的机制到底是什么。

今天，我们不谈那些零散的“魔法代码”，而是直接深入到Android框架的源码层面，把WindowInsets的分发链路、fitsSystemWindows的触发条件，以及它们与View的测量、布局、绘制流程如何交织，彻底理清楚。你会发现，很多“玄学”问题，其实在源码里都有明确的答案。这篇文章面向的是已经有一定Android开发经验，但在处理系统UI适配时仍感到困惑的开发者。我们将从ViewRootImpl开始，一路追踪到你的自定义View，看看WindowInsets这个“包裹”是如何被传递、谁有权签收、以及为什么有时会“丢件”。

1. WindowInsets的本质：不仅仅是“边距”

在开始追踪分发流程之前，我们必须先建立一个正确的认知：WindowInsets到底是什么？很多开发者把它简单理解为系统UI（状态栏、导航栏）占据的“高度”或“边距”，这个理解是片面的，也是导致后续处理出错的根源。

WindowInsets的核心是描述“窗口内容”与“系统装饰区域”之间的关系。它不是一个简单的Rect或尺寸值，而是一个包含了多种类型“插图”信息的集合。在Android R (API 30) 之后，这套API被彻底重构，变得更加清晰和类型安全。

1.1 WindowInsets的现代构成

我们可以通过一个简单的代码片段，在DecorView上设置监听器，来直观感受一下WindowInsets包含的内容：

window.decorView.setOnApplyWindowInsetsListener { view, insets -> if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.R) { val statusBarInsets = insets.getInsets(WindowInsets.Type.statusBars()) val navigationBarInsets = insets.getInsets(WindowInsets.Type.navigationBars()) val imeInsets = insets.getInsets(WindowInsets.Type.ime()) val systemBarsInsets = insets.getInsets(WindowInsets.Type.systemBars()) val captionBarInsets = insets.getInsets(WindowInsets.Type.captionBar()) val displayCutoutInsets = insets.getInsets(WindowInsets.Type.displayCutout()) Log.d("InsetsDebug", "状态栏插图: $statusBarInsets") Log.d("InsetsDebug", "导航栏插图: $navigationBarInsets") Log.d("InsetsDebug", "输入法插图: $imeInsets") // ... 其他类型 } insets }

运行这段代码，你可能会看到类似下面的日志输出（数值因设备而异）：

状态栏插图: Insets{left=0, top=84, right=0, bottom=0} 导航栏插图: Insets{left=0, top=0, right=0, bottom=168} 输入法插图: Insets{left=0, top=0, right=0, bottom=1155}

这里的关键是理解Insets对象。它的top: 84并不代表状态栏的底部Y坐标是84，而是表示窗口内容需要从顶部开始，让出84像素的空间给状态栏。它是一个“插入”值，而非“占据”值。这一点区别至关重要，因为它决定了后续View的padding是如何被计算的。

1.2 历史遗留：SystemWindowInsets与兼容性

在Android R之前，我们主要接触的是WindowInsets的systemWindowInsets属性。它是一个Rect对象，其top、bottom等字段的含义与新版Insets类似，但缺乏类型区分。为了向后兼容，老版本的应用在调用onApplyWindowInsets(WindowInsets)时，传入的仍然是包含systemWindowInsets的旧对象，但内部逻辑已经适配了新API。

注意：在处理历史代码或阅读旧资料时，你会频繁遇到systemWindowInsets。请记住，在Android R及以后，更推荐使用类型化的getInsets(Type)方法，因为它能更精确地处理刘海屏、摄像头挖孔等复杂情况。

为了更清晰地对比新旧API的核心差异，我整理了下面这个表格：

这种设计演进带来的最大好处是可组合性与安全性。你可以只处理输入法插图而不影响状态栏，也可以安全地传递WindowInsets对象而不担心被意外修改。

2. 分发链路的起点：ViewRootImpl与performTraversals

WindowInsets不是凭空出现的，也不是由Activity或Fragment直接分发的。整个分发过程的发动机是ViewRootImpl。ViewRootImpl是连接WindowManager和视图层View体系的桥梁，负责调度measure、layout、draw三大流程，同时也负责处理来自系统层的各种输入，包括WindowInsets。

2.1 何时触发分发？

WindowInsets的分发并非发生在每一次performTraversals()中。系统只在特定条件下才会重新计算并分发WindowInsets。核心的触发逻辑在ViewRootImpl的performTraversals()方法里，我们可以从源码中梳理出关键路径：

// ViewRootImpl.java (简化示意) private void performTraversals() { // ... 大量准备工作，计算窗口尺寸、可见性等 // 关键判断点：是否需要分发Insets? if (dispatchApplyInsets || mLastSystemUiVisibility != mAttachInfo.mSystemUiVisibility || mApplyInsetsRequested) { mLastSystemUiVisibility = mAttachInfo.mSystemUiVisibility; dispatchApplyInsets(host); // host 就是 DecorView dispatchApplyInsets = true; // 标记已分发，可能影响后续测量 } // ... 后续执行measure, layout, draw }

触发条件主要有三个：

1. dispatchApplyInsets标志为true：通常在窗口尺寸变化、系统UI可见性变化（如状态栏隐藏/显示）后设置。
2. 系统UI可见性发生变化：mLastSystemUiVisibility与当前值不同，比如通过setSystemUiVisibility()改变了状态栏模式。
3. 主动请求分发：mApplyInsetsRequested被设置为true，这可以来自应用内部的请求。

当以上任一条件满足，ViewRootImpl就会调用dispatchApplyInsets(View)方法，并将DecorView作为起点传入。从这里开始，WindowInsets这个“包裹”正式进入视图树的分发流程。

2.2 dispatchApplyInsets：构造与预处理

进入dispatchApplyInsets方法，它会做两件重要的事：

public void dispatchApplyInsets(View host) { mApplyInsetsRequested = false; // 1. 获取（或强制构造）当前的WindowInsets对象 WindowInsets insets = getWindowInsets(true /* forceConstruct */); // 2. 预处理：如果窗口布局不需要处理刘海，则消费掉DisplayCutout部分 if (!shouldDispatchCutout()) { insets = insets.consumeDisplayCutout(); } // 3. 开始向视图树分发 host.dispatchApplyWindowInsets(insets); // ... 其他逻辑 }

getWindowInsets(true)会强制根据当前的窗口状态构造一个最新的WindowInsets实例。shouldDispatchCutout()是一个有趣的判断，它决定了是否将刘海屏区域信息（DisplayCutout）传递给应用。如果窗口布局模式（如LAYOUT_IN_DISPLAY_CUTOUT_MODE_NEVER）指定不处理刘海，系统会直接调用consumeDisplayCutout()，这样下游的View就感知不到刘海区域的存在了。

提示：这个预处理机制解释了为什么有时候即使设备有刘海屏，你的应用也可能收不到相关的WindowInsets信息。你需要检查windowLayoutInDisplayCutoutMode这个窗口属性的设置。

3. 视图树中的传递：从DecorView到叶子View

WindowInsets的分发遵循一个深度优先、可中断的传递规则。它从DecorView开始，沿着视图树向下传递，每个View都有机会消费它。一旦某个View消费了WindowInsets（即返回的WindowInsets对象的isConsumed()为true），传递就会停止，其兄弟节点和子节点将不会收到该WindowInsets。

3.1 ViewGroup的分发策略

ViewGroup的dispatchApplyWindowInsets(WindowInsets)方法是传递逻辑的核心：

@Override public WindowInsets dispatchApplyWindowInsets(WindowInsets insets) { // 1. 先让ViewGroup自己尝试处理 insets = super.dispatchApplyWindowInsets(insets); // 2. 如果自己已经消费完了，直接返回，停止传递 if (insets.isConsumed()) { return insets; } // 3. 自己没消费完，则分发给子View final int count = getChildCount(); for (int i = 0; i < count; i++) { insets = getChildAt(i).dispatchApplyWindowInsets(insets); if (insets.isConsumed()) { break; // 任何一个子View消费了，就停止循环 } } return insets; }

这个逻辑非常清晰：

• 先己后人：ViewGroup会先调用父类View的dispatchApplyWindowInsets，给自己一个处理的机会。
• 短路传递：如果自己处理完后insets被标记为已消费，整个传递链路就此结束，子View不会收到任何信息。
• 顺序遍历：如果自己没消费完，则按Z序（通常是添加顺序）遍历子View进行分发。
• 子View优先：第一个消费了insets的子View会“阻断”其后续兄弟View接收insets。

这种机制导致了fitsSystemWindows行为的一个经典陷阱：如果一个父容器（如DrawerLayout、CoordinatorLayout）消费了WindowInsets，那么其子View即使设置了fitsSystemWindows="true"也无效。

3.2 View的处理入口：dispatchApplyWindowInsets

现在我们深入到单个View，看看dispatchApplyWindowInsets做了什么：

public WindowInsets dispatchApplyWindowInsets(WindowInsets insets) { try { mPrivateFlags3 |= PFLAG3_APPLYING_INSETS; // 标记正在处理中 // 优先级1：开发者设置的监听器 if (mListenerInfo != null && mListenerInfo.mOnApplyWindowInsetsListener != null) { return mListenerInfo.mOnApplyWindowInsetsListener.onApplyWindowInsets(this, insets); } else { // 优先级2：默认的onApplyWindowInsets方法 return onApplyWindowInsets(insets); } } finally { mPrivateFlags3 &= ~PFLAG3_APPLYING_INSETS; // 清除标记 } }

这里存在一个优先级关系：

1. 自定义监听器优先：如果开发者通过setOnApplyWindowInsetsListener设置了监听器，则完全由监听器处理，View自身的逻辑被绕过。这是最灵活、最高优先级的处理方式。
2. 默认处理逻辑：如果没有设置监听器，则调用View自身的onApplyWindowInsets(WindowInsets)方法。fitsSystemWindows属性正是在这个方法里起作用的。

很多支持库组件（如CoordinatorLayout、AppBarLayout）就是通过设置自己的OnApplyWindowInsetsListener来实现复杂的嵌套滚动和Insets响应行为的。如果你在自己的自定义ViewGroup中重写了这个方法并消费了insets，务必考虑清楚是否会意外阻断子View的响应。

4. fitsSystemWindows的生效机制：从属性到Padding

终于来到了问题的核心：android:fitsSystemWindows="true"这个简单的属性，是如何一步步转化为View的padding，从而为系统栏留出空间的？秘密藏在View.onApplyWindowInsets(WindowInsets)这个默认实现里。

4.1 onApplyWindowInsets的决策逻辑

我们来看View.onApplyWindowInsets的关键部分（经过简化）：

public WindowInsets onApplyWindowInsets(WindowInsets insets) { // 情况A：处理框架可选fitSystemWindows（系统View专用，如DecorView的直接子View） if ((mPrivateFlags4 & PFLAG4_FRAMEWORK_OPTIONAL_FITS_SYSTEM_WINDOWS) != 0 && (mViewFlags & FITS_SYSTEM_WINDOWS) != 0) { return onApplyFrameworkOptionalFitSystemWindows(insets); } // 情况B：常规的fitsSystemWindows处理 if ((mPrivateFlags3 & PFLAG3_FITTING_SYSTEM_WINDOWS) == 0) { // 首次进入，走fitSystemWindows兼容路径 if (fitSystemWindows(insets.getSystemWindowInsetsAsRect())) { return insets.consumeSystemWindowInsets(); } } else { // 已经在fitSystemWindows路径中，直接调用内部方法 if (fitSystemWindowsInt(insets.getSystemWindowInsetsAsRect())) { return insets.consumeSystemWindowInsets(); } } return insets; // 未消费，原样返回 }

逻辑分支有点绕，但核心判断条件可以梳理如下：

• PFLAG4_FRAMEWORK_OPTIONAL_FITS_SYSTEM_WINDOWS：这是一个框架内部使用的标记，通常由PhoneWindow通过DecorView.makeOptionalFitsSystemWindows()方法设置。它标记了那些“框架提供的、可选择是否处理系统窗口”的视图，比如DecorView的直接子布局（contentParent）。普通应用开发者创建的View不会拥有这个标记。
• FITS_SYSTEM_WINDOWS：这就是我们在XML中设置android:fitsSystemWindows="true"时，框架为View设置的标志位。它是fitsSystemWindows属性生效的必要条件。
• PFLAG3_FITTING_SYSTEM_WINDOWS：这是一个临时标记，表示当前正在执行fitSystemWindows的兼容逻辑。用于区分是来自老APIfitSystemWindows(Rect)的调用，还是来自新APIonApplyWindowInsets(WindowInsets)的调用。

对于绝大多数应用层View，我们走的是情况B。而且由于PFLAG3_FITTING_SYSTEM_WINDOWS初始为0，我们会进入第一个if块，调用那个被标记为@Deprecated的fitSystemWindows(Rect)方法。

4.2 fitSystemWindows的兼容桥接

fitSystemWindows(Rect)是一个历史方法，为了兼容旧版本应用而保留。它的作用是将新的WindowInsets分发机制桥接到旧的fitSystemWindows逻辑上。

@Deprecated protected boolean fitSystemWindows(Rect insets) { if ((mPrivateFlags3 & PFLAG3_APPLYING_INSETS) == 0) { // 不在APPLYING_INSETS过程中，说明是从新API路径进来的 // 设置FITTING标记，并重新派发到新API路径（确保监听器能捕获） try { mPrivateFlags3 |= PFLAG3_FITTING_SYSTEM_WINDOWS; return dispatchApplyWindowInsets(new WindowInsets(insets)).isConsumed(); } finally { mPrivateFlags3 &= ~PFLAG3_FITTING_SYSTEM_WINDOWS; } } else { // 已经在APPLYING_INSETS过程中，直接走内部处理 return fitSystemWindowsInt(insets); } }

这里有一个巧妙的循环：

1. 从onApplyWindowInsets进来时，PFLAG3_APPLYING_INSETS标志已被dispatchApplyWindowInsets设置。
2. 因此，fitSystemWindows(Rect)会进入else分支，直接调用fitSystemWindowsInt(Rect)。
3. fitSystemWindowsInt(Rect)才是真正执行“根据insets设置padding”逻辑的地方。

这个设计确保了无论通过新API还是旧兼容路径，最终都会汇聚到同一个核心处理函数fitSystemWindowsInt。

4.3 核心操作：fitSystemWindowsInt与padding设置

fitSystemWindowsInt(Rect)是属性生效的最后一环：

private boolean fitSystemWindowsInt(Rect insets) { // 关键判断：只有设置了FITS_SYSTEM_WINDOWS标志的View才会处理 if ((mViewFlags & FITS_SYSTEM_WINDOWS) == FITS_SYSTEM_WINDOWS) { Rect localInsets = sThreadLocal.get(); // 1. 计算是否需要消费，以及消费多少 boolean res = computeFitSystemWindows(insets, localInsets); // 2. 应用计算出的insets，实质是设置View的padding applyInsets(localInsets); return res; // 返回true表示消费了insets } return false; // 未设置标志，直接返回false，不消费 }

这个方法清晰地说明了两个问题：

1. 为什么设置了fitsSystemWindows可能无效？因为你的View可能根本没有FITS_SYSTEM_WINDOWS这个标志位。某些自定义ViewGroup（特别是重写了dispatchApplyWindowInsets或onApplyWindowInsets的）可能会在给子View分发前，就消费掉insets，或者根本不给子View调用默认处理逻辑的机会。
2. fitsSystemWindows做了什么？它最终调用了applyInsets(Rect)，而applyInsets内部就是调用了internalSetPadding，用insets的left,top,right,bottom值来设置View的对应padding。

computeFitSystemWindows方法会根据View的类型和状态，决定最终应用多少insets。例如，对于被标记为OPTIONAL_FITS_SYSTEM_WINDOWS的系统View，它可能会咨询一个OnContentApplyWindowInsetsListener来决定如何处理，这给了系统更大的灵活性。

5. 实战：诊断与解决fitsSystemWindows失效问题

理解了原理，我们就可以系统地诊断和解决fitsSystemWindows不生效的问题了。下面是一个自顶向下的排查清单。

5.1 检查窗口级别配置

首先，确保你的窗口配置允许内容延伸到系统栏之下，这是fitsSystemWindows起作用的前提。如果窗口本身就不透明，系统栏区域不透明，那么insets的尺寸可能就是0。

• 主题/样式检查：确保你的Activity主题或当前窗口设置了以下至少一个属性：

  <!-- 方式1：透明状态栏 --> <item name="android:windowTranslucentStatus">true</item> <!-- 方式2：透明导航栏 --> <item name="android:windowTranslucentNavigation">true</item> <!-- 方式3（Android 5.0+）：全屏布局，内容可延伸到系统栏下 --> <item name="android:windowDrawsSystemBarBackgrounds">false</item> <item name="android:windowLayoutInDisplayCutoutMode">shortEdges</item> <!-- 处理刘海 -->

  在代码中，可以通过Window的addFlags方法动态设置：

  if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.KITKAT) { window.addFlags(WindowManager.LayoutParams.FLAG_TRANSLUCENT_STATUS) } // 或使用更现代的API if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.R) { window.setDecorFitsSystemWindows(false) window.insetsController?.hide(WindowInsets.Type.statusBars() or WindowInsets.Type.navigationBars()) }

5.2 检查视图树中的“拦截者”

这是最常见的问题根源。使用以下方法检查WindowInsets在视图树中的传递情况：

1. 添加全局监听器进行调试：在Activity的onCreate中，为DecorView设置一个监听器，打印分发路径。

   window.decorView.setOnApplyWindowInsetsListener { v, insets -> Log.d("InsetsFlow", "DecorView received: $insets, isConsumed: ${insets.isConsumed}") insets // 返回原insets，不消费，让其继续传递 }

2. 检查关键父容器：依次在你的布局根节点、可能消费insets的ViewGroup（如DrawerLayout,CoordinatorLayout,SwipeRefreshLayout等）上设置类似的监听器。观察insets在哪个环节被消费（isConsumed()变为true）。

3. 识别“拦截”行为：一些库提供的ViewGroup有自己的OnApplyWindowInsetsListener。例如，CoordinatorLayout的默认行为是不消费WindowInsets，而是将其分发给设置了Behavior的子View。但DrawerLayout的早期版本可能会消费掉insets。你需要查阅所用库的文档或源码。

5.3 自定义ViewGroup的正确处理方式

如果你正在编写一个自定义的ViewGroup，并且希望它既能自己处理insets，又不阻断子View，可以参考以下模式：

class MyCustomLayout @JvmOverloads constructor( context: Context, attrs: AttributeSet? = null, defStyleAttr: Int = 0 ) : ViewGroup(context, attrs, defStyleAttr) { private var lastInsets: WindowInsets? = null init { // 关键：设置一个自定义的监听器，而不是依赖默认的fitsSystemWindows属性 setOnApplyWindowInsetsListener { v, insets -> lastInsets = insets // 1. 自己先应用insets（例如设置自己的padding） val consumed = applyInsetsForSelf(insets) // 2. 将处理后的insets（或新的insets）分发给子View dispatchApplyWindowInsetsToChildren(insets) // 3. 返回insets。如果自己完全消费了，就返回insets.consumed()。 // 如果希望子View也能处理，就返回传入的insets（或修改后的）。 consumed } } private fun applyInsetsForSelf(insets: WindowInsets): WindowInsets { // 例如，只消费状态栏的top insets val statusBars = insets.getInsets(WindowInsets.Type.statusBars()) setPadding(paddingLeft, statusBars.top, paddingRight, paddingBottom) // 消费掉状态栏的top部分，其他部分保留 return insets.inset(Insets.of(0, statusBars.top, 0, 0)) } private fun dispatchApplyWindowInsetsToChildren(insets: WindowInsets) { for (i in 0 until childCount) { getChildAt(i).dispatchApplyWindowInsets(insets) } } // ... 省略measure和layout代码 }

这种模式的要点是：

• 使用setOnApplyWindowInsetsListener获得完全控制权。
• 在监听器中，先处理自己需要的部分（applyInsetsForSelf）。
• 然后，手动调用每个子View的dispatchApplyWindowInsets，将处理后的（或原始的）insets传递下去。这是确保子View的fitsSystemWindows属性能够生效的关键。
• 根据你是否希望子View继续处理，返回消费后的insets或原insets。

5.4 使用现代API：WindowInsetsCompat与边衬区

对于支持库用户，WindowInsetsCompat提供了更好的向后兼容性和更清晰的API。特别是“边衬区”（Sidecar）的概念，可以帮助你更精细地控制不同系统栏的交互。

// 使用 ViewCompat 替代直接设置监听器 ViewCompat.setOnApplyWindowInsetsListener(yourView) { v, insets -> // 获取类型化的插图 val systemBars = insets.getInsets(WindowInsetsCompat.Type.systemBars()) val ime = insets.getInsets(WindowInsetsCompat.Type.ime()) // 检查特定类型是否可见 val isImeVisible = insets.isVisible(WindowInsetsCompat.Type.ime()) // 你可以选择只消费一部分，比如IME val consumedInsets = WindowInsetsCompat.Builder() .setInsets(WindowInsetsCompat.Type.ime(), Insets.NONE) .build() // 将消费后的insets返回 WindowInsetsCompat.CONSUMED }

WindowInsetsCompat还能与EdgeToEdge开发模式更好地配合，帮助你实现真正的全屏体验，同时妥善处理手势冲突。

6. 高级场景与性能考量

6.1 与软键盘（IME）的协同

软键盘的弹出也会产生WindowInsets（类型为ime()）。处理软键盘插图时，需要特别注意：

• 消费行为：如果你消费了ime插图，系统会认为你的View已经处理了键盘空间，可能不会自动调整窗口布局。
• adjustResize与adjustPan：Activity的windowSoftInputMode属性会严重影响WindowInsets的分发和窗口调整行为。通常，adjustResize模式与fitsSystemWindows或自定义插图处理配合更好。
• 动画同步：软键盘的弹出/收起是动画过程。从Android R开始，你可以通过WindowInsetsAnimationCompat来监听动画过程，实现内容与键盘的平滑同步移动，提供更佳的用户体验。

6.2 性能陷阱：requestLayout的触发

在fitSystemWindowsInt内部的applyInsets方法中，如果计算出的新padding与旧值不同，会调用requestLayout()和invalidateOutline()。这意味着，WindowInsets的每次变化（如屏幕旋转、系统栏隐藏显示）都可能导致整个视图树的重新测量和布局。

对于复杂界面，这可能成为性能瓶颈。优化策略包括：

• 减少嵌套：扁平化视图层级。
• 局部更新：如果只有局部UI需要响应insets变化，考虑使用ConstraintLayout的Guideline或Barrier，或者通过View的setPadding手动调整，而不是依赖fitsSystemWindows的全局传递。
• 防抖处理：在OnApplyWindowInsetsListener中，可以对比新旧insets，仅在确实发生变化时才更新UI。

6.3 多窗口模式与配置变更

在分屏、自由窗口等多窗口模式下，WindowInsets的值会实时反映当前可用区域。你的UI需要能够动态适应。确保相关处理逻辑放在Configuration变更或OnApplyWindowInsetsListener中，而不是仅在onCreate中执行一次。

此外，从Android R开始，引入了getInsetsIgnoringVisibility(Type)API，它可以获取某种类型系统栏的最大可能插图，即使当前该栏是隐藏的。这在做动画或预布局时非常有用。

回过头看最初的问题：“为什么我的fitsSystemWindows总不生效？”现在我们可以给出一个结构化的排查思路了。首先确认窗口透明或全屏设置已启用，这是基石。然后，像侦探一样，从DecorView开始，沿着视图树向下排查，使用监听器打印日志，找到是哪个父容器“拦截”了insets。如果是第三方库，查阅其文档；如果是自己的布局，检查是否有自定义ViewGroup错误地消费了insets。最后，在需要精细控制的场景，果断使用setOnApplyWindowInsetsListener替代简单的属性设置，掌握分发的主动权。

WindowInsets机制是Android实现沉浸式、自适应UI的基石。理解它的分发逻辑，不仅能解决fitsSystemWindows失效的诡异问题，更能让你在实现复杂UI适配时游刃有余。下次再遇到状态栏重叠、键盘遮挡内容时，不妨先想想：WindowInsets这个“包裹”，到底传到哪里去了？