Jetpack Compose中通过导航传递对象的最佳实践咨询

Hey 👋，针对你这个Jetpack Compose导航传对象的问题，我来给你捋几个靠谱的实践思路，你可以结合自己的场景来选~

首先得说，你当前用共享ViewModel+ViewModel工厂传参的思路完全是可行的，但确实有更贴合不同场景的优化方向，下面给你拆解：

1. 优先考虑让Drink实现Parcelable，通过导航参数直接传递 #

这是导航组件推荐的轻量对象传递方式，步骤也很简单：

• 给你的Drink类加上@Parcelize注解（记得在build.gradle里开启kotlin-parcelize插件），实现Parcelable接口：

  @Parcelize
  data class Drink(val name: String, val ingredients: List<String>) : Parcelable
  

• 导航的时候直接把Drink作为参数传入，搭配Compose Navigation的参数配置：

  composable(
      route = "edit_drink",
      arguments = listOf(navArgument("drink") { type = ParcelableType(Drink::class.java) })
  ) { backStackEntry ->
      val drink = backStackEntry.arguments?.getParcelable<Drink>("drink")
      drink?.let {
          EditDrinkScreen(viewModel = hiltViewModel<EditDrinkViewModel>().apply { initDrink(it) })
      }
  }
  

• 然后你的EditDrinkViewModel只需要提供一个初始化方法（比如initDrink）来接收对象，或者通过ViewModel工厂把导航参数里的Drink注入进去，这样每个ViewModel的职责更单一，也不需要依赖共享ViewModel，解耦性更好。

这个方案的优点是完全遵循导航组件的设计理念，页面之间的依赖关系清晰，不会因为共享ViewModel导致不必要的生命周期耦合。唯一需要注意的是，如果Drink类非常复杂（比如包含大量嵌套对象），实现Parcelable会有点繁琐，但Kotlin的@Parcelize已经帮我们省了大部分工作量，一般场景下都够用。

2. 优化你当前的共享ViewModel方案 #

如果你还是倾向于用共享ViewModel的方式，那可以做几个优化让它更规范：

• 确保共享ViewModel的作用域是Activity级别（或者和你的导航Graph绑定的级别），这样在导航到Edit页面时，ViewModel不会被销毁。比如用viewModel(storeOwner = LocalContext.current as Activity)来获取Activity级别的ViewModel。
• EditDrinkViewModel通过工厂接收Drink时，只接收需要的数据，而不是让EditViewModel依赖整个共享ViewModel。比如共享ViewModel只暴露selectedDrink的getter，然后工厂从共享ViewModel拿到这个对象，再传给EditViewModel：

  class EditDrinkViewModelFactory(
      private val selectedDrink: Drink
  ) : ViewModelProvider.Factory {
      @Suppress("UNCHECKED_CAST")
      override fun <T : ViewModel> create(modelClass: Class<T>): T {
          if (modelClass.isAssignableFrom(EditDrinkViewModel::class.java)) {
              return EditDrinkViewModel(selectedDrink) as T
          }
          throw IllegalArgumentException("Unknown ViewModel class")
      }
  }
  

  这样EditDrinkViewModel完全不需要知道共享ViewModel的存在，只专注于编辑逻辑，解耦性会好很多。

3. 未来扩展：如果后续要持久化Drink #

如果你的App之后打算把Drink保存到数据库（比如Room），那最佳实践就变成只传递Drink的ID，然后EditDrinkViewModel自己从数据库加载对应的Drink数据。这样即使导航过程中App被后台杀死，重新打开时也能通过ID重新加载数据，稳定性更高，也符合单一职责原则——列表页面负责展示，编辑页面负责从数据源加载和修改数据。

总结一下 #

• 如果你现在的Drink类不复杂，优先选Parcelable+导航参数的方案，解耦性最好，也符合导航组件的设计思路；
• 如果Drink特别复杂，或者你已经有Activity级别的共享ViewModel在处理其他全局状态，那优化后的共享ViewModel+工厂传参方案也完全ok；
• 后续如果有持久化需求，记得切换成传ID的方式。

你的初始思路其实已经踩在正确的方向上了，只是可以根据场景再做些优化，不用怀疑自己~ 😊

备注：内容来源于stack exchange，提问作者Tyler Allen