Jetpack Compose中两ViewModel订阅同一StateFlow仅一个接收更新

问题场景 #

我正在开发一个基于Jetpack Compose和Dagger-Hilt做依赖注入的应用。目前有两个ViewModel（MainViewModel和FormViewModel）订阅单例AppRepository中的StateFlow，两者初始化都正常，但只有MainViewModel能接收到仓库的更新，FormViewModel完全收不到，且两个ViewModel是在同一个Composable中同时创建的。

补充说明：这是我用Jetpack Compose+MVVM开发的规模最大的应用，最初只有一个MainViewModel，现在已经到了约800行代码还在扩展，其中一半是表单处理逻辑。我打算把表单相关代码拆成独立的FormViewModel，但不确定这种做法是否符合MVVM和Dagger-Hilt的最佳实践——到底是维护单个大ViewModel更好，还是拆分成多个ViewModel提升模块化和可维护性？

相关代码 #

AppRepository（摘要） #

@Singleton
class AppRepository @Inject constructor(...) {
    private val _services = MutableStateFlow<List<LocalService>>(listOf())
    val services: StateFlow<List<LocalService>> = _services
    // ...其他代码
}

MainViewModel #

@HiltViewModel
class MainViewModel @Inject constructor(
    private val appRepository: AppRepository,
    private val application: Application
) : ViewModel() {
    val services: StateFlow<List<LocalService>> = appRepository.services

    init {
        viewModelScope.launch {
            services.collect { 
                // 打印services.size的日志
                Log.d("MainViewModel", "MainViewModel services has changed: ${it.size}")
            }
        }
    }
}

FormViewModel #

@HiltViewModel
class FormViewModel @Inject constructor(private val appRepository: AppRepository) : ViewModel() {
    val services: StateFlow<List<LocalService>> = appRepository.services

    init {
        viewModelScope.launch {
            services.collect { 
                // 打印services.size的日志
                Log.d("FormViewModel", "FormViewModel services has changed: ${it.size}")
            }
        }
    }
}

Dagger-Hilt Module #

@Module
@InstallIn(SingletonComponent::class)
object Module {
    // ...其他提供方法
    @Provides
    fun provideMainRepository(
        // ...依赖参数
    ): AppRepository {
        return AppRepository(
          // ...传入参数
        )
    }
}

日志输出 #

2023-11-14 11:31:16.170 15406-15406 FormViewModel           com.conecta                  D  MainViewModel init
2023-11-14 11:31:16.172 15406-15406 FormViewModel           com.conecta                  D  MainViewModel formQuestionCrossRef has changed: 0
2023-11-14 11:31:16.173 15406-15406 FormViewModel           com.conecta                  D  MainViewModel serviceFormCrossRef has changed: 0
2023-11-14 11:31:16.174 15406-15406 FormViewModel           com.conecta                  D  MainViewModel services has changed: 0
2023-11-14 11:31:16.757 15406-15406 FormViewModel           com.conecta                  D  FormViewModel init
2023-11-14 11:31:16.758 15406-15406 FormViewModel           com.conecta                  D  FormViewModel formQuestionCrossRef has changed: 0
2023-11-14 11:31:16.759 15406-15406 FormViewModel           com.conecta                  D  FormViewModel serviceFormCrossRef has changed: 0
2023-11-14 11:31:16.760 15406-15406 FormViewModel           com.conecta                  D  FormViewModel services has changed: 0
2023-11-14 11:31:20.028 15406-15406 FormViewModel           com.conecta                  D  MainViewModel services has changed: 30
2023-11-14 11:31:20.270 15406-15406 FormViewModel           com.conecta                  D  MainViewModel formQuestionCrossRef has changed: 1260
2023-11-14 11:31:20.274 15406-15406 FormViewModel           com.conecta                  D  MainViewModel serviceFormCrossRef has changed: 90

问题解答 #

一、StateFlow订阅异常排查 #

从日志和代码来看，FormViewModel初始化时能收到初始值，但后续仓库更新无响应，可从以下方向排查：

1. ViewModel创建方式验证
   确认Composable中是否用Hilt指定的方式创建FormViewModel：

   val formViewModel: FormViewModel = hiltViewModel()
   

   若误用viewModel()而非hiltViewModel()，可能导致ViewModel未通过Hilt注入，拿到的AppRepository不是预期的单例实例。

2. StateFlow实例一致性检查
   检查AppRepository中是否存在重新赋值_services的代码（比如再次执行_services = MutableStateFlow(...)）。如果_services被替换，FormViewModel订阅的是旧的StateFlow实例，自然收不到后续更新。

3. 日志标签修正
   注意到所有日志的标签都是FormViewModel，包括MainViewModel的输出，这可能是日志标签写错导致的误判。确认两个ViewModel的日志标签是否正确：

   • MainViewModel用Log.d("MainViewModel", ...)
   • FormViewModel用Log.d("FormViewModel", ...)

4. ViewModelScope状态检查
   若FormViewModel的viewModelScope被意外取消，collect协程会停止。可在collect块中添加协程状态日志，或排查是否有其他操作触发了viewModelScope的取消。

二、ViewModel拆分的最佳实践 #

强烈建议拆分成多个ViewModel，理由如下：

1. 符合单一职责原则
   MVVM核心要求每个组件职责单一，MainViewModel专注主页面逻辑，FormViewModel聚焦表单处理，代码边界清晰，更易维护和测试。

2. 提升模块化与复用性
   独立的FormViewModel可在其他需要表单功能的页面直接复用，避免重复编写相同逻辑。

3. 避免ViewModel膨胀
   800行的ViewModel已属于大型组件，后续扩展会大幅增加维护成本。拆分后每个ViewModel代码量控制在300-500行的合理范围，降低认知负担。

4. 适配Dagger-Hilt特性
   Hilt对多ViewModel的支持非常友好，只要依赖（如AppRepository）是单例配置，就能保证多ViewModel共享同一数据源，完全匹配你的场景需求。

拆分注意事项：

• 确保AppRepository的单例配置正确（当前代码已满足），保证两个ViewModel共享同一数据源。
• 表单相关的状态和逻辑完全迁移到FormViewModel，避免ViewModel间直接通信，所有状态通过AppRepository的StateFlow传递，保持单向数据流。

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