第1章 状态提升的本质与动机

状态提升（State Hoisting）是 Jetpack Compose 中最重要的架构模式之一，其本质是将状态的管理职责从子组件转移到更高层级的父组件，从而在组件树中建立清晰的模块边界与数据契约。本章从模块边界视角出发，剖析状态提升的三大核心动机，并给出可落地的架构决策框架。

1.1 状态提升的架构本质

在 Compose 组件树中，每一个 @Composable 函数都可以拥有自己的状态。当多个子组件需要共享同一份状态、或父组件需要控制子组件的行为时，状态必须提升到它们共同的最低公共祖先中管理。这一过程重新划定了组件的职责边界：

1.2 三大动机的架构意义

状态提升的三大动机——消除状态冗余、单一数据源、单向数据流——本质上是模块边界治理的三个核心原则。下面从架构收益角度对比：

1.3 从模块边界视角理解状态提升

在模块化架构中，模块边界定义了组件之间的依赖契约。状态提升实际上是在组件树中建立了两类边界：

• 数据边界：父组件通过 val state: T 向下传递数据，子组件不能直接修改该数据。
• 控制边界：子组件通过 onEvent: (T) -> Unit 回调向上发送事件，父组件决定如何响应。

下面这张图展示了状态提升后的标准架构模式，包含三个清晰的层级和双向通信契约：

1.4 组件职责的重新分配

状态提升迫使开发者明确每个组件的职责边界。提升后，组件被分为两类：

• 有状态组件（Stateful）：持有状态，负责状态的定义、更新和分发。通常位于组件树的较高层级。
• 无状态组件（Stateless）：通过参数获取数据，通过回调上报事件，不持有可变状态。通常位于组件树的较低层级。

在 Compose 中，无状态组件的典型签名模式如下：

@Composable
fun EditableTextField(
    text: String,               // 数据：由父组件传入
    onTextChange: (String) -> Unit, // 事件：通过回调通知父组件
    modifier: Modifier = Modifier
) {
    TextField(
        value = text,
        onValueChange = onTextChange,
        modifier = modifier
    )
}

父组件通过 remember 持有状态，并将状态和回调传递给子组件：

@Composable
fun ParentScreen() {
    var name by remember { mutableStateOf("") }
    EditableTextField(
        text = name,
        onTextChange = { name = it }
    )
}

1.5 方案权衡：提升与封装的平衡

状态提升并非“越高越好”。过度提升会导致中间组件传递无关状态（Prop Drilling），增加模块间的耦合。下面是提升程度的决策指南：

1.6 落地步骤：在模块边界中实施状态提升

在真实项目中实施状态提升，建议按以下五个步骤操作：

1. 识别共享状态：在组件树中找出被两个或以上子组件使用的数据。
2. 确定最低公共祖先：找到包含所有使用该状态的组件的最低公共父组件。
3. 提取状态到祖先：用 remember + mutableStateOf 在该祖先中定义状态。
4. 通过参数传递状态和回调：将状态值作为 val 参数向下传递，将更新逻辑包装为回调函数向下传递。
5. 移除子组件中的本地状态：删除子组件中冗余的 remember 声明，确保状态只在一处定义。

1.7 验收标准：如何判断状态提升是否成功

每个架构决策都需要可衡量的验收标准。状态提升实施完成后，应满足以下条件：

• 无状态冗余：同一份业务数据在组件树中只出现一次 remember 定义。
• 单一数据源可追溯：任意时刻都能明确回答“这个数据从哪里来”。
• 数据流单向闭环：数据向下传递的路径与事件向上传递的路径不交叉、不循环。
• 子组件可独立测试：子组件仅依赖参数输入和回调输出，不依赖外部可变状态。
• 模块边界可识别：每个组件的 @Composable 签名清晰反映了其数据依赖和事件能力。