Jetpack Compose底部导航两种方案优劣及生产可行性分析

Jetpack Compose官方推荐的底部导航实现方式是在Scaffold内部嵌套NavHost，但该方案会导致底部导航栏在所有关联页面中显示，无法满足“仅在底部导航对应主页面显示导航栏”的需求。另一种方案是通过状态索引直接切换Scaffold主体中的Composable，以下是两种方案的优缺点对比，以及第二种方案的生产环境可行性分析：

一、官方方案（Scaffold内嵌NavHost） #

优点 #

• 完全遵循官方导航架构规范，可直接复用Navigation组件的全部原生特性：包括页面状态自动保存、深度导航管理、转场动画、Back栈维护等
• 代码结构标准化，后续新增底部导航项、扩展导航逻辑时，维护成本低
• 自动处理底部导航与Back栈的联动，比如从子页面返回时，会自动恢复对应底部导航项的选中状态

缺点 #

• 默认情况下底部导航栏会在所有导航关联页面显示，要实现“子页面隐藏导航栏”的需求，需要额外添加导航目的地的判断逻辑，实现相对繁琐

二、索引切换Composable方案 #

该方案通过维护一个选中索引状态，在Scaffold主体中根据索引切换显示不同的主页面Composable，代码示例如下：

var selectedBottomBarIndex by remember {
    mutableStateOf(0)
}

Scaffold(
    bottomBar = {
            MyBottomBar(currentIndex = selectedBottomBarIndex, onChanged = {
                    selectedBottomBarIndex = it
                }
            )
    } {
    when (selectedBottomBarIndex) {        
        0 -> HomeScreen(navController)
        1 -> AssignmentHomeScreen(navController)
        2 -> CategoryScreen(navController)
        else -> ProfileHomeScreen(navController)
    }
}

优点 #

• 实现逻辑简单直观，无需复杂的导航配置，快速上手
• 可以轻松实现“仅主页面显示底部导航栏”的需求：进入子页面时，只需修改索引状态或直接隐藏Scaffold的bottomBar参数即可
• 主页面切换时无额外导航Back栈开销，状态管理轻量化

缺点 #

• 完全放弃了Navigation组件的Back栈管理能力，子页面的导航逻辑需要手动实现，容易出现Back栈混乱、返回逻辑错误等问题
• 无法复用Navigation组件的深层链接、转场动画、状态自动保存等高级特性，需要自行开发，代码冗余度高
• 当底部导航项增多或主页面逻辑复杂时，when分支会变得臃肿，不利于代码维护
• 主页面切换时，若未额外处理状态保存（如使用rememberSaveable、ViewModel），页面状态会丢失

三、第二种方案是否可安全用于生产环境？ #

如果你的应用符合以下场景，该方案可以安全用于生产环境：

• 底部导航对应的主页面没有复杂的子页面导航，或子页面数量极少
• 不需要使用Navigation组件的深层链接、转场动画等高级功能
• 能够手动做好页面状态的保存与恢复（比如借助rememberSaveable、ViewModel管理页面状态）

但如果应用存在复杂导航需求（如多级页面跳转、深层链接、精细的Back栈控制），不推荐使用该方案，否则后续会产生大量自定义维护成本，且容易引发导航逻辑bug。

内容的提问来源于stack exchange，提问作者simarjot singh kalsi