Jetpack Compose+MVVM安卓应用：导航、架构及生命周期疑问

1. Jetpack Compose的UI导航方案选择 #

优先采用**单主Activity搭配全局导航器（NavHost）**的方案，这是Jetpack Compose官方推荐的架构模式，原因如下：

• 契合Compose声明式UI的设计逻辑，导航状态可统一管理，页面跳转更流畅，避免多Activity间的跳转开销与生命周期同步问题。
• 每个模块的页面（比如Profile的登录页、Items的详情页）可作为独立导航目的地，各自对应专属ViewModel，通过viewModel()函数在Composable中获取，ViewModel的生命周期会与导航目的地的栈生命周期绑定，资源管理更合理。
• 多Activity方案会增加页面间状态传递的复杂度，且每个Activity的ViewModel受限于自身生命周期，容易出现不必要的资源持有，不利于模块化维护。

2. 独立Repository与ViewModel的整合方式 #

绝对不建议将4个独立Repository整合到一个大型ViewModel，这违反了单一职责原则，会带来以下问题：

• ViewModel职责过重，代码量庞大，后续维护、调试难度陡增，比如修改收藏模块逻辑时，可能误触商品模块的代码。
• 造成不必要的资源占用：比如用户停留在Profile模块时，Items、Categories的Repository仍被ViewModel持有，可能触发无用的网络请求或占用数据库连接。
• 正确做法：每个模块对应专属ViewModel（如ProfileViewModel、CategoriesViewModel），每个ViewModel仅依赖自身模块所需的Repository，比如ProfileViewModel只关联ProfileRepository，FavoritesViewModel只关联FavoritesRepository。

3. ViewModel的生命周期管理 #

ViewModel不应该置于Activity内部，ViewModel的生命周期由ViewModelStoreOwner决定，正确管理方式分场景：

• 全局共享状态（比如用户登录状态）：可使用Application级的ViewModelStoreOwner，让ViewModel生命周期跟随整个应用，避免屏幕旋转等配置变化导致状态丢失。
• 模块内页面级ViewModel：应将导航目的地（NavBackStackEntry）作为ViewModelStoreOwner，在Compose中通过viewModel()或navGraphViewModels()获取，ViewModel的生命周期会与页面在导航栈中的周期绑定——页面出栈时，ViewModel会被自动清理，避免内存泄漏。
• 若将ViewModel绑定到Activity，其生命周期会跟随Activity的整个生命周期（直到Activity被销毁），如果页面已退出但Activity仍存活，ViewModel会持续持有资源，造成不必要的内存占用。

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