Jetpack Compose重组阶段执行细节及性能影响技术咨询

我正在研究Jetpack Compose 阶段（Phases），尝试梳理其在重组（recomposition）中的应用方式。

假设的ViewModel实现 #

data class MyDataClass(
    val contentA: String? = null,
    val contentB: String? = null,
    val contentC: String? = null,
    val contentD: String? = null,
    val editTextContent: String? = null // EDIT-1

)
class MyViewModel: ViewModel() {
    private val _uiState = MutableStateFlow(MyDataClass())
    val uiState = _uiState.asStateFlow

    fun updateContentA(newContent: String) {
        _uiState.update { it.copy(contentA = newContent) }
    }

    // EDIT-1
    fun updateEditText(newContent: String) {
        _uiState.update { it.copy(editTextContent = newContent) }
    }
}

Compose UI布局实现 #

fun MyMainScreen(viewModel = MyViewModel()) {

    // P1: 由于在此收集最新状态，每次uiState更新时，此Compose函数（MyMainScreen）的`recomposed`计数会在布局检查器中增加
    val uiState by viewModel.uiState.collectAsStateWithLifecycle().value

    
    // P2: 尽管只有一个文本发生变化，所有这些方法的重组计数都会增加，但叶子节点会跳过重组
    MyMiniUiElement(uiState.contentA)
    MyMidUiElement(uiState.contentB)
    MyLargeUiElement(uiState.contentC)
    MyHugeUiElement(uiState.contentD)
    MyEditTextField(uiState.editTextContent)  // EDIT-1
}


fun MyMiniUiElement(val text: String) {
    Text()
}

fun MyMidUiElement(val text: String) {
    Text()
}

fun MyLargeUiElement(val text: String) {
    Text()
}

fun MyHugeUiElement(val text: String) {
    Text()
}

//EDIT-1
fun MyEditTextField(val text: String, onValueChange: (String) -> Unit) {
    var textFieldValue by rememberSaveable(stateSaver = TextFieldValue.Saver) {
        mutableStateOf(TextFieldValue(text = text))
    }
    BasicTextField(
        value = text,
        onValueChange = {
            textFieldValue = TextFieldValue(it, TextRange(Int.MAX_VALUE))
            onValueChange(it)
         }
    )
    
}

疑问点 #

结合上述两点（P1和P2），想咨询：当MyMainScreen和My{x}UiElement发生重组时，会执行哪些Jetpack Compose阶段？有何影响？是否会增加CPU负载、进行布局测量或重绘像素？

注： 我知晓最佳实践是避免将ViewModel向下传递给其他组件，但如果传递ViewModel，理论上可避免MyMainScreen和My{x}UiElement发生重组。

解答 #

1. 重组触发的Compose阶段 #

当MyMainScreen和My{x}UiElement触发重组时，会按顺序涉及以下阶段，但Compose会通过智能对比跳过不必要的步骤：

• 组合（Composition）阶段：重新执行MyMainScreen函数体，生成新的UI节点引用；对于My{x}UiElement，Compose会对比传入的新参数与旧参数：如果参数未变化（比如contentB在contentA更新时无变动），会直接复用之前生成的UI节点，跳过该函数内部的组合逻辑。
• 布局（Layout）阶段：仅当组合阶段产出的UI节点存在尺寸、位置变更时才会触发。比如MyMiniUiElement的Text内容更新后宽度变化，才会对该节点执行测量与布局计算，其他未变化的节点不会进入此阶段。
• 绘制（Drawing）阶段：只有UI节点的视觉属性（如文本内容、颜色、形状）发生变化时，才会执行像素绘制操作。未改变的节点会直接跳过此步骤。

2. 性能影响分析 #

• CPU负载：重组本身会带来少量CPU开销，但Compose的跳过机制将其控制在极低水平。MyMainScreen的重组仅涉及状态读取和参数传递，未变化的My{x}UiElement内部逻辑不会执行，除非你在这些函数中加入了大量计算逻辑，否则不会造成明显CPU负担。
• 布局测量：仅受影响的节点会触发布局计算。比如只有contentA更新时，只有MyMiniUiElement可能触发布局（如果文本长度改变），其他节点的布局流程会被跳过。
• 像素重绘：仅视觉属性变化的节点会被重绘。比如contentA更新后，只有MyMiniUiElement中的Text会执行重绘，其余Text控件不会有像素绘制操作。

3. 传递ViewModel的优化逻辑 #

若直接将ViewModel传递给子组件，子组件可在内部单独收集自身依赖的状态（如在MyMiniUiElement中直接读取viewModel.uiState.contentA），这样MyMainScreen不会因单个状态更新触发重组，子组件也仅在自身依赖的状态变化时才重组。这种方式能减少MyMainScreen的重组次数，但需注意避免过度传递ViewModel导致组件耦合度升高，遵循组件单一职责原则。

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