传递带Room的ViewModel给Composable引发多次重组问题

现象回顾 #

在导航图中创建包含Room实体Collection的AddCollectionHiltViewModel，并将其作为参数传递给AddCollectionScreen时，该Composable会触发多次重组（日志显示达5次）；但将ViewModel创建逻辑移至AddCollectionScreen内部，或移除ViewModel中的Room实体后，重组次数恢复为1次；移除navigation-compose依赖可减少2次重组，需保留ViewModel传参方式以统一管理工具栏与底部栏。

核心原因拆解 #

1. Room实体的稳定性缺失导致Compose误判参数变化 #

Room生成的实体类默认是data class，其equals/hashCode基于所有字段实现，但Compose的稳定性推断无法自动识别Room实体的稳定性——因为Room实体可能包含生成的代理逻辑（比如延迟初始化的字段），或者Compose无法确认实体属性是否会被外部修改。

当ViewModel作为参数传递给Composable时，Compose会判断整个ViewModel的稳定性：由于内部持有未标记稳定的Room实体，Compose会将ViewModel视为不稳定类型。此时，每次父Composable（导航图中的composable lambda）重组时，Compose无法确定ViewModel是否发生变化，就会触发子ComposableAddCollectionScreen的重组。

而将ViewModel创建移至子Composable内部时，hiltViewModel()会被Compose自动关联到Lifecycle，Compose默认将ViewModel视为稳定引用，即使内部有Room实体，也只会在Composable内部使用实体属性时才触发重组，而非因为ViewModel本身的传递引发重组。

2. Navigation-Compose的内部状态更新触发额外重组 #

Navigation-Compose的NavHost和composable函数本身会因导航状态变化触发多次重组：比如页面切换时的过渡动画、导航参数解析完成后的状态同步、导航栈的内部状态更新等。这些内部更新会导致composable lambda多次执行。

当ViewModel作为不稳定参数传递时，每次composable重组都会引发子Composable的重组；移除navigation-compose依赖后，少了导航相关的两次重组，正好对应导航内部状态更新带来的额外触发。

3. Compose稳定性推断机制的影响 #

Compose的重组触发依赖于参数的稳定性判断：

• 稳定类型（如基本类型、标记@Stable/@Immutable的类）的参数，只有当值真正变化时才会触发重组；
• 不稳定类型的参数，父Composable每次重组都会导致子Composable跟着重组，因为Compose无法确认参数是否变化。

ViewModel本身是稳定的，但内部未标记稳定的Room实体破坏了整体稳定性，导致Compose将整个ViewModel判定为不稳定，最终引发多次不必要的重组。

保留ViewModel传参的优化方案 #

方案1：给Room实体添加@Stable注解 #

手动给Room实体添加@Stable注解，明确告知Compose该实体的属性不会随意修改，从而让Compose将ViewModel判定为稳定类型：

@Entity
@Stable
data class Collection(val name: String) {
    @PrimaryKey(autoGenerate = true) val id: Long = 0
}

方案2：用remember缓存ViewModel实例 #

在导航图的composable lambda中，用remember包裹ViewModel实例，确保即使父Composable重组，传递给子Composable的ViewModel引用始终被视为稳定的同一实例：

composable(HomeTab.AddCollection.route) {
    Log.d("TAG322", "Recomposition. AddCollection composable")
    val vm: AddCollectionHiltViewModel = remember { hiltViewModel() }
    AddCollectionScreen(vm)
}

方案3：封装ViewModel的暴露状态 #

如果不需要在子Composable中直接持有ViewModel引用，可以将需要的状态封装为StateFlow或MutableState传递，既满足统一管理需求，又避免传递不稳定的ViewModel实例：

// ViewModel中暴露状态
val collectionState = mutableStateOf(Collection(""))

// 导航图中传递状态
composable(HomeTab.AddCollection.route) {
    val vm: AddCollectionHiltViewModel = hiltViewModel()
    AddCollectionScreen(collectionState = vm.collectionState)
}

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