Jetpack Compose：封装ViewModel多状态变量的惯用方案

我有一个名为HelloCompose的根Composable代码十分冗长，它由包含大量变量的HelloComposeViewModel提供支持。我希望优化该代码以提升可读性，想了解封装大量状态变量的惯用方式。

当前代码 #

@Composable
fun HelloCompose() {
 val viewModelHelloCompose: HelloComposeViewModel = viewModel { HelloComposeViewModel() }
 val foo: String by viewModel.foo.collectAsState()
 val bar: Int by viewModel.bar.collectAsState()
 val baz: String by viewModel.baz.collectAsState()
 Foobar(foo = foo, bar = bar, baz = baz)
}

我的重构代码 #

data class FoobarParams(
 val foo: String,
 val bar: Int,
 val baz: String
)

@Composable
fun getFoobarParams(viewModel: HelloComposeViewModel): FoobarParams {
 val foo: String by viewModel.foo.collectAsState()
 val bar: Int by viewModel.bar.collectAsState()
 val baz: String by viewModel.baz.collectAsState()
 val result = FoobarParams(foo = foo, bar = bar, baz = baz)
 return result
}

@Composable
fun HelloCompose() {
 val viewModelHelloCompose: HelloComposeViewModel = viewModel { HelloComposeViewModel() }
 val foobarParams = getFoobarParams(viewModelHelloCompose)
 Foobar(foo = foobarParams.foo, bar = foobarParams.bar, baz = foobarParams.baz)
}

请问是否有更优的重构方式？当ViewModel持有10个需传入Composable的变量时，是否应采用如下方式封装：

private val _uiState = MutableStateFlow(HelloComposeUiState())
val uiState: StateFlow<HelloComposeUiState> = _uiState.asStateFlow()

优化方案推荐 #

你的重构思路已经在一定程度上简化了Composable的代码，但更惯用且适合大量状态变量的方式是使用单一的UiState对象配合StateFlow封装，也就是你提到的第二种方式，这种方案在变量数量越多时优势越明显，具体原因和实现如下：

1. 为什么选择UiState封装？ #

• 减少重复的collectAsState()调用：无需为每个单独的StateFlow写一次收集逻辑，只需收集整个uiState一次
• 更清晰的状态边界：ViewModel明确提供当前UI所需的完整状态集合，符合MVVM中ViewModel负责管理UI状态的职责
• 更易维护：新增或修改状态只需调整UiState数据类和ViewModel内的更新逻辑，不用在Composable层修改多个变量的收集代码

2. 具体实现示例 #

第一步：定义UiState数据类

// 包含所有UI所需的状态变量
data class HelloComposeUiState(
    val foo: String = "",
    val bar: Int = 0,
    val baz: String = "",
    // 新增的状态变量直接在这里添加
    val qux: Boolean = false
)

第二步：在ViewModel中封装状态流

class HelloComposeViewModel : ViewModel() {
    // 私有可变状态流，仅在ViewModel内部修改
    private val _uiState = MutableStateFlow(HelloComposeUiState())
    // 对外暴露不可变的状态流
    val uiState: StateFlow<HelloComposeUiState> = _uiState.asStateFlow()

    // 示例：更新状态的方法，通过copy修改不可变数据类
    fun updateFoo(newFoo: String) {
        _uiState.value = _uiState.value.copy(foo = newFoo)
    }

    fun incrementBar() {
        _uiState.value = _uiState.value.copy(bar = _uiState.value.bar + 1)
    }
}

第三步：在Composable中使用

@Composable
fun HelloCompose() {
    val viewModel: HelloComposeViewModel = viewModel { HelloComposeViewModel() }
    // 只需收集一次整个UI状态
    val uiState by viewModel.uiState.collectAsState()
    
    // 直接解构或使用uiState的属性传递给子Composable
    Foobar(
        foo = uiState.foo,
        bar = uiState.bar,
        baz = uiState.baz
    )
    
    // 如果子Composable需要的参数正好是UiState的子集，也可以直接传递整个对象（如果合理的话）
    // Foobar(params = uiState)
}

// 子Composable示例
@Composable
fun Foobar(foo: String, bar: Int, baz: String) {
    // ... 组件实现
}

3. 和你的重构方案对比 #

你的FoobarParams方案是在Composable层收集多个状态后封装，而UiState方案是在ViewModel层就完成状态的整合，后者更符合架构职责分离的原则——ViewModel负责准备好UI需要的所有状态，Composable只负责渲染。当状态变量增加到10个时，UiState方案的代码复杂度几乎不会上升，而你的方案需要在getFoobarParams中不断新增collectAsState()调用，维护成本会显著提高。

内容的提问来源于stack exchange，提问作者J. Cool