ViewModel更新MutableStateFlow后init重复执行致状态重置问题

问题现象 #

更新MutableStateFlow类型的uiState时，ViewModel的init代码会重复执行，导致状态被重置。仅当更新操作依赖uiState的历史状态信息时才会触发该问题：

• 触发问题的更新代码：

  (it as CreateGameState.InputDataState).copy(selectedHeroes = it.selectedHeroes.plusElement(action.hero))
  

  此时Logcat会重复输出init阶段的日志，应用始终停留在初始状态。
• 无问题的更新代码：

  (it as CreateGameState.InputDataState).copy(selectedHeroes = listOf(Hero.SPIDERMAN))
  

  直接赋值时状态更新正常，ViewModel不会重复初始化。

核心原因 #

这种情况本质是ViewModel被意外重复实例化，而依赖历史状态的更新操作往往触发了导致ViewModel重建的连锁逻辑：

• 可能是UI层错误的订阅方式，导致状态更新后触发重复的Action发送，进而引发ViewModel重建；
• 也可能是ViewModel的实例化逻辑错误，每次状态更新都重新创建了ViewModel实例；
• 另外，状态更新的循环依赖（比如状态更新→UI触发Action→状态再更新）也会导致无限循环，最终触发ViewModel的意外重建。

解决方案 #

1. 规范ViewModel实例化方式
   确保在Activity/Fragment中使用官方推荐的方式获取ViewModel实例：

   • Compose中用viewModel()；
   • View系统中用ViewModelProvider(this)[YourViewModel::class.java]；
   • 依赖注入框架（如Hilt）用hiltViewModel()。
     避免在非初始化逻辑中重复创建ViewModel实例。

2. 修正StateFlow订阅逻辑
   在UI层订阅uiState时，使用生命周期感知的订阅方式：

   • Compose中用collectAsStateWithLifecycle()替代普通的collectAsState()，确保订阅随生命周期启停；
   • View系统中用repeatOnLifecycle包裹collect逻辑，避免后台订阅导致的不必要触发：

     lifecycleScope.launch {
         repeatOnLifecycle(Lifecycle.State.STARTED) {
             viewModel.uiState.collect { state ->
                 // 更新UI
             }
         }
     }
     

3. 排查循环触发逻辑
   在Action发送和状态更新的关键节点添加日志，确认是否存在“状态更新→UI发送Action→状态再更新”的循环。如果有，需要调整UI层的触发逻辑，避免重复发送相同Action。

4. 确保状态类的不可变性
   确认CreateGameState.InputDataState是data class，且所有属性均为不可变类型（如用List而非MutableList）。你的代码中用plusElement生成新列表的做法是正确的，保持这种不可变状态更新模式，避免引用类型修改导致的意外状态变化。

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