Compose Destinations 项目中处理 Android 15 状态栏/导航栏适配方案

背景介绍

随着 Android 15 的发布，应用默认会绘制在状态栏和导航栏下方，这要求开发者必须正确处理窗口插入（insets）。在 Compose Destinations 这样的导航库中，如何优雅地处理这些插入值成为了一个重要课题。

问题分析

在典型的 Jetpack Compose 应用中，我们通常会使用 Scaffold 布局，其中可能包含一个底部导航栏（BottomBar）。当这个底部导航栏在某些目标页面显示，在其他页面隐藏时，会导致内容的内边距（contentPadding）发生变化。

开发者最初尝试的方案是通过将 contentPadding 作为依赖项传递给子目标页面：

@Composable
@Destination<PhotosNavGraph>(navArgs = PhotoGalleryNavArgs::class, start = true)
fun PhotoGalleryScreen(
    navigator: DestinationsNavigator,
    getContainerPadding: () -> PaddingValues,
    modifier: Modifier = Modifier,
) {
    // 使用 getContainerPadding() 获取内边距
}

然而，这种方法存在一个关键问题：contentPadding 的更新发生在导航完成之后，导致目标页面在底部导航栏隐藏之前就已经渲染，造成布局问题。

解决方案

经过探索，发现更有效的解决方案是在子目标页面的 Scaffold 中使用 contentWindowInsets：

Scaffold(
    contentWindowInsets = WindowInsets.systemBars
) { innerPadding ->
    // 页面内容
}

这种方案之所以有效，可能有以下几个原因：

1. 多阶段重组：Scaffold 会经历多次重组，在此期间父级布局已经调整好了插入值
2. 系统级协调：WindowInsets.systemBars 会自动与系统保持同步
3. 响应式设计：Compose 的响应式特性确保了插入值的正确传播

实现建议

对于使用 Compose Destinations 的开发者，建议采用以下最佳实践：

1. 统一使用 WindowInsets：在所有需要处理插入的页面中，优先考虑使用 WindowInsets API
2. 避免直接传递 PaddingValues：由于导航时序问题，直接传递内边距值可能不可靠
3. 考虑嵌套 Scaffold 的使用：在子页面中也使用 Scaffold 可以更好地管理插入值

技术细节

理解 WindowInsets 的工作原理对于解决这类问题很有帮助：

1. 系统栏插入：包括状态栏、导航栏和手势栏
2. 内容插入：确保内容不会被系统UI覆盖
3. 手势插入：处理全面屏设备的手势区域

在 Android 15 及更高版本中，系统默认启用了边缘到边缘（edge-to-edge）显示，这使得正确处理插入变得更加重要。

结论

在 Compose Destinations 项目中处理 Android 15 的插入问题时，直接使用 WindowInsets API 比传递 PaddingValues 更可靠。这种方法不仅解决了导航时序问题，还能更好地适应不同设备和系统版本的变化。开发者应当熟悉 WindowInsets 的各种用法，以确保应用在各种环境下都能正确显示。

对于更复杂的场景，还可以考虑使用 accompanist 库中的 insets 相关组件，它们提供了更多便捷的功能来处理各种插入情况。