State Hoisting：状态提升与 Compose 中的单向数据流

什么是 Jetpack Compose 中的 State Hoisting

State Hoisting（状态提升）— 是一种模式，其中 Composable 函数不拥有状态，而是从外部接收。函数内部不使用 var，而是使用两个参数：用于显示的值和用于处理变更的 lambda 回调。从技术上讲，这意味着子组件变为 stateless（没有自己的状态），而父组件变为 stateful（拥有状态）。

示例：来自 Material3 的 TextField 组件不在其内部存储输入的文本。它接受 value: String 和 onValueChange: (String) -> Unit。调用 TextField 的父组件声明 var value by remember { mutableStateOf("") } 并传递 value 和 onValueChange。这是经典的 State Hoisting：TextField — 简单组件（只显示并报告输入），父组件 — 智能（拥有状态）。

Stateless 与 Stateful 对比：Stateless 组件更容易测试 — 它不依赖于内部状态，其行为完全由输入参数决定。Stateful 组件适合快速原型开发，但更难以重用 — 它与单一数据源紧密绑定。State Hoisting 提供选择：通过将状态向上移动，任何组件都可以变为 stateless。

单向数据流（UDF）和 State Hoisting

UDF（Unidirectional Data Flow）— 是一种架构原则，其中数据沿着一个方向运动：从真理源（ViewModel 或父级 Composable）到 UI，事件则沿着相反的方向运动。State Hoisting 是 UDF 在单个组件级别的实现。不是每个组件自己决定何时以及如何改变其状态，而是它向父组件报告事件，由父组件决定如何改变状态。

UDF 的优点：可预测性 — 状态只在一个地方变更，消除了竞争条件；可追踪性 — 通过调用栈可以重建变更链；测试 — stateful 逻辑可以提取到单独的类中，无需 UI 进行测试。在大型项目中，UDF 与 State Hoisting 的组合是事实上的标准。

单一真理源（Single Source of Truth）— 陪伴 UDF 的另一个原则。每个状态片段都有且仅有一个源。如果两个组件使用相同的状态，源必须是共享的（在 ViewModel 或共同父组件级别）。State Hoisting 保证源在层级结构中更高，并且不会发生状态复制。

State Hoisting 规则：何时以及如何提升状态

主要规则：状态应提升到对所有需要它的组件而言达到最低可能级别的地方。如果状态只在一个组件内部使用 — 保持本地。如果两个邻近组件需要相同的状态 — 提升到共同的父组件。如果状态在整个屏幕上都需要 — 提升到 ViewModel。

最小提升规则 避免不必要的复杂性。如果文本框的状态只在一个屏幕内使用且不会在 Activity 重新创建时保存，那么将其提升到 ViewModel 没有意义。对于必须存活屏幕旋转但不需要业务逻辑的 UI 状态，请在屏幕父级级别使用 rememberSaveable，而非 ViewModel。

何时提升到 ViewModel：如果状态必须在 Activity 重新创建时保持，如果多个屏幕需要它，如果状态变更触发业务逻辑（网络请求、数据库）。ViewModel 级别的 State Hoisting 是 MVVM 架构中的典型模式，其中 UI 层是 stateless，ViewModel 是 stateful。

    // ❌ 不好：组件拥有自己的状态
@Composable
fun BadTextField(label: String) {
    var text by remember { mutableStateOf("") }
    TextField(value = text, onValueChange = { text = it }, label = { Text(label) })
}

    // ✅ 好：State Hoisting — 状态在父组件中
@Composable
fun GoodTextField(value: String, onValueChange: (String) -> Unit, label: String) {
    TextField(value = value, onValueChange = onValueChange, label = { Text(label) })
}

    // 用法：父组件拥有状态
@Composable
fun Form() {
    var name by rememberSaveable { mutableStateOf("") }
    GoodTextField(value = name, onValueChange = { name = it }, label = "Name")
}

State Hoisting 在实际组件中的示例

考虑一个带有两个字段（电子邮件、密码）和一个按钮的 登录 界面。所有三个组件都通过 State Hoisting 接收状态：电子邮件和密码由父组件管理，按钮作为值接收 enabled 状态。

    // 屏幕级别的 State Hoisting
@Composable
fun LoginScreen(viewModel: LoginViewModel) {
    val uiState by viewModel.uiState.collectAsState()

    Column(modifier = Modifier.padding(16.dp)) {
        // 电子邮件字段 — 通过 lambda 的 State Hoisting
        EmailField(
            email = uiState.email,
            onEmailChange = { viewModel.onEmailChanged(it) }
        )

        // 密码字段 — 类似
        PasswordField(
            password = uiState.password,
            onPasswordChange = { viewModel.onPasswordChanged(it) }
        )

        // 按钮 — 仅接收 enabled（只读）
        LoginButton(enabled = uiState.isFormValid, onClick = viewModel::login)
    }
}

// Stateless 组件：接收电子邮件 + 回调
@Composable
fun EmailField(email: String, onEmailChange: (String) -> Unit) {
    OutlinedTextField(
        value = email,
        onValueChange = onEmailChange,
        label = { Text("电子邮件") },
        singleLine = true
    )
}

// Stateless 按钮组件
@Composable
fun LoginButton(enabled: Boolean, onClick: () -> Unit) {
    Button(onClick = onClick, enabled = enabled) {
        Text("登录")
    }
}

EmailField 和 PasswordField — 完全 stateless。它们可以在任何屏幕上重用，连接到任何数据源。LoginButton 作为只读接收 enabled — 这是 State Hoisting 的另一种形式，状态不被提升（按钮无法自己启用），而是以已完成的形式传递。这种方法以最小的组件耦合提供了最大的灵活性。

State Hoisting 与本地状态：选择标准

并非所有状态都需要提升。本地状态（Composable 内部的 State）在以下情况下是合理的：数据只在一个组件内部需要，不影响邻近元素，不必存活特定区段的重组。例如，动画状态、输入字段聚焦、当前滚动位置 — 适合保持本地。

何时需要 State Hoisting：状态被多个子组件使用；一个子组件中的变化必须在另一个中反映；需要单独测试状态变更逻辑而不依赖于 UI；状态必须在 Activity 重新创建时保持。在这些情况下，本地状态会导致数据复制和不一致。

混合方法：将最小状态保持本地，提升剩余状态。Compose 规则：“将状态提升到必要的高度，同时尽可能低”。在实践中，这意味着从本地 remember 开始，只有当需要从另一个组件访问时 — 再提升级别。不要预防性地使用 State Hoisting — 这会无缘无故地复杂化代码。