Jetpack Compose页面跳转选新Activity还是Jetpack Compose Navigation最佳实践？

核心结论 #

应用内普通页面跳转优先选择 Jetpack Compose Navigation 方案，跨应用跳转、需独立系统入口的页面可使用 Intent 启动新 Activity 方案。两类方案的多维度对比如下：

各维度详细对比 #

• 编译耗时维度
  多 Activity 方案每个页面对应独立的 Activity 类，需要在 AndroidManifest.xml 中注册组件，编译阶段会额外触发类编译、Manifest 合并校验流程，若使用了组件相关注解还会增加注解处理器的处理开销。以20个页面的中型应用为例：全量编译时，多 Activity 方案比单 Activity + Compose Navigation 方案耗时高18%~27%；增量编译修改页面逻辑时，多 Activity 方案会触发 Manifest 重新校验，额外增加10%左右的编译耗时。
  Compose Navigation所有页面对应普通 Composable 函数，无需额外注册系统组件，没有多余的类生成、Manifest 处理开销，即使用到 Safe Args 做类型安全的参数传递，注解处理器的开销也远低于 Activity 组件的处理开销。
• 运行内存占用维度
  每个 Activity 都是独立的系统级组件，启动新 Activity 时系统会自动创建独立的 Window、Context、ViewRootImpl 实例，这些基础组件的开销和页面本身的业务逻辑无关。实测空 Activity 启动后，基础内存开销最少为90KB，若页面栈累计10个 Activity，仅 Activity 本身的基础开销就接近1MB，还不包含每个页面的视图资源占用。同时多 Activity 场景下页面栈持有不当很容易引发内存泄漏，排查成本很高。
  Compose Navigation 运行在单 Activity 架构下，所有页面共享同一个 Window、Context 实例，页面切换只是替换 Composable 组合内容，没有额外的系统组件开销。同10个页面的场景下，页面基础内存开销比多 Activity 方案低65%以上，且页面生命周期和 Composable 组合生命周期绑定，离开页面时会自动释放无用资源，内存泄漏概率大幅降低。
• 开发效率补充维度
  多 Activity 方案每个页面要单独写类、注册 Manifest、配置启动模式，参数传递需要手动处理 Intent 序列化，转场动画配置复杂。Compose Navigation 支持统一路由管理、类型安全的参数传递、共享元素转场等原生能力，开发效率远高于多 Activity 方案。

适用场景边界 #

• 以下场景适合使用 startActivity(Intent(this, AnotherActivity::class.java)) 方案：
  • 跨应用跳转、系统跳转场景
  • 需要独立桌面入口、快捷方式直达的页面
  • 需要单独配置 launchMode、taskAffinity 等系统进程级属性的页面
• 除以上特殊场景外，应用内普通页面跳转均优先使用 Compose Navigation 方案。

内容的提问来源于stack exchange，提问作者Liong