Jetpack Compose两种状态订阅写法的重绘逻辑疑问

Case A #

@Composable
fun Parent(viewModel: VM = hiltViewModel()) {
    val stateA by remember { viewModel.stateA }
    val stateB by remember { viewModel.stateB }

    Column {
        ChildA(stateA = stateA)
        ChildB(stateB = stateB)
    }
}

@Composable
fun ChildA(
    stateA: StateA
) {
    ...
}

@Composable
fun ChildB(
    stateB: StateB
) {
    ...
}

Case B #

@Composable
fun Parent(viewModel: VM = hiltViewModel()) {
    Column {
        ChildA(viewModel = viewModel)
        ChildB(viewModel = viewModel)
    }
}

@Composable
fun ChildA(
    viewModel: VM
) {
    val stateA by remember { viewModel.stateA }
    ...
}

@Composable
fun ChildB(
    viewModel: VM
) {
    val stateB by remember { viewModel.stateB }
    ...
}

我注意到大多数Jetpack Compose示例都用Case A的写法，但有个疑问：如果Compose没有特殊优化，Case A里stateA或stateB变化时，Parent、ChildA和ChildB都会重绘；而Case B只会在stateA变化时重绘ChildA，stateB变化时重绘ChildB。那为什么大家普遍用Case A？

核心原理：Compose的智能重组机制 #

你的误解在于对Compose重组逻辑的判断——Case A并不会导致无关组件的冗余重组。Compose的重组是基于参数相等性的智能重组：当某个Composable的输入参数发生变化时，它才会触发重组；如果参数没有变化，Compose会直接跳过该Composable的重组，复用之前的渲染结果。

具体到Case A：

• 当stateA变化时，Parent会触发重组，但重组过程中，ChildB的输入参数stateB未发生变化，所以Compose会跳过ChildB的重组；只有ChildA因参数stateA变化会执行重组。
• 同理，stateB变化时，仅ChildB会重组，ChildA和Parent的非关联逻辑不会冗余执行。
• 另外，Parent本身的重组开销极低，因为它仅负责读取状态并传递参数，无复杂UI计算逻辑。

Case A的优势（为什么被普遍采用） #

1. 解耦与单一职责：子组件仅依赖自身需要的具体状态，而非整个ViewModel，组件职责更清晰，复用性更强——比如ChildA可以在任何需要StateA的场景中复用，无需绑定特定ViewModel。
2. 可测试性提升：测试子组件时，直接传入模拟的StateA即可，无需依赖ViewModel初始化、Hilt注入等复杂环境，测试逻辑更简洁。
3. 符合状态管理最佳实践：官方推荐“将状态提升到需要它的最低共同父组件”，通过参数向下传递状态的模式，能让状态流向更透明，避免组件间的隐式依赖。
4. 避免潜在维护风险：Case B中子组件依赖整个ViewModel，即使组件不需要的状态发生变化，也可能因依赖关系不透明引发意外问题，增加后续维护成本。

官方文档相关要点 #

Jetpack Compose官方文档明确提及：

• 稳定类型：若一个类型的实例在属性值不变时，equals()始终返回true，则被视为稳定类型。State、数据类等都属于稳定类型，Compose会利用这一特性判断是否需要触发重组。
• 重组优化：传递最小必要状态而非整个ViewModel，能让Compose更精准地控制重组范围，同时提升组件的可复用性与可测试性。
• 状态提升：将状态提升至父组件再通过参数传递，是Compose状态管理的核心模式，可确保状态的单一数据源，避免状态不一致问题。

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