如何合理架构Jetpack Compose安卓项目的多页面代码？

首先明确：直接把所有页面代码都堆在MainActivity中是非常不推荐的做法，长期迭代下会导致代码耦合严重、难以维护。Compose 不绑定传统的Activity/Fragment页面载体，你可以用更灵活的方式组织页面代码，以下是经过社区验证的最优架构方式和最佳实践：

核心页面架构逻辑 #

• 单Activity作为唯一入口：整个应用只保留一个MainActivity作为Compose的承载容器，不需要为不同页面创建单独的Activity或Fragment，减少系统组件的生命周期管理开销。
• 页面按业务拆分独立Compose函数：每个独立页面都定义为顶层Screen级Compose函数，单独存放在对应业务模块的目录下，比如/feature/home/HomeScreen.kt、/feature/settings/SettingsScreen.kt。页面函数只接收必要的入参和事件回调，不依赖特定的上下文或路由组件，保证可单独测试。
• 统一路由层管理页面跳转：使用Navigation Compose组件统一管理所有页面的路由注册、跳转逻辑，路由配置可以单独抽成一个Navigation.kt文件，不要散落在各个页面中。参考示例代码：

  // 导航层统一注册路由
  NavHost(navController = navController, startDestination = Route.HOME) {
      composable(Route.HOME) {
          HomeScreen(onJumpToDetail = { id ->
              navController.navigate("${Route.DETAIL}/$id")
          })
      }
      composable("${Route.DETAIL}/{id}") { backStack ->
          val detailId = backStack.arguments?.getString("id").orEmpty()
          DetailScreen(detailId = detailId, onBack = { navController.popBackStack() })
      }
  }
  

• 页面内部按粒度拆分组件：单个页面代码超过200行时，把可复用的UI块、通用交互组件抽成独立的子Compose函数，放到对应模块的components子目录下，避免单个Screen函数过于臃肿。

通用最佳实践 #

• 遵循单向数据流原则：页面状态优先存放在对应业务的ViewModel中持有，Screen函数只负责UI渲染和用户事件转发，不要在Compose函数中处理复杂业务逻辑，保证UI层是无副作用的纯函数。
• 页面间只传递基础类型参数：页面跳转时不要传递复杂的序列化对象，只传id、标识类的基础类型参数，目标页面用入参自行拉取对应业务数据，降低页面间的耦合度。
• 按业务模块而非代码类型分包：不要把所有页面放同一个包、所有ViewModel放另一个包，而是按业务域划分目录，同一个业务的页面、ViewModel、数据层代码都放在同一个目录下，便于后续功能迭代和模块拆分。
• 可组合函数保持单一职责：每个Compose函数只负责一个功能，通用组件支持Slot API做插槽扩展，提升复用性，避免出现动辄上百行的大段Compose代码。

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