状态提升层级选择：组件内部状态、屏幕级状态、全局状态的选择依据

在支付输入场景中，状态究竟应该放在组件内部、屏幕级（如ViewModel）还是全局（如单例/数据仓库），直接决定了代码的可维护性、测试难度和性能。选择不当会导致状态混乱、重复请求或内存泄漏。本章从原理出发，给出清晰的选择树和实现范例。

三种状态层级的定义与生命周期

层级 生命周期 典型宿主 适用场景
组件内部状态 随 Composable 重组而销毁/重建 remember、mutableStateOf 仅影响当前UI显示（如输入框焦点、动画中间值）
屏幕级状态 与屏幕（Activity/Fragment/Composable宿主）共存亡 ViewModel（viewModel()） 跨组合的重用、屏幕内多个组件共享（如支付表单校验结果）
全局状态 应用进程存活期间始终存在 单例、SharedPreferences、DataStore 跨屏幕共享（如用户登录态、支付卡号默认填充）
关键认知： State Hoisting 的核心是向上提，但不必一步提到全局。逐级提升，每次仅提升到能满足“共享范围”的最小层级，才是最佳实践。

选择依据：三层决策树

为帮助你在实际编码时快速判断，下面给出决策流程。每个判断都基于“状态是否会被兄弟组件、子组件、或不同屏幕访问”。

选择流程：

  1. 状态是否仅属于当前组件自身？（如输入框的动画旋转值）→ 使用remember保留在组件内部。
  2. 状态是否需要在同一屏幕的多个组件间共享？（如支付金额在输入框和确认按钮之间同步）→ 提升至屏幕级（ViewModel）。
  3. 状态是否需要在不同屏幕之间保持？（如用户选择的支付方式在多个页面保持）→ 提升至全局（数据仓库/Repository）。
  4. 特殊情形：临时业务标记（如“是否已显示过新手引导”）→ 优先使用持久化全局状态而非屏幕级。
状态提升层级选择决策流程图 开始评估状态 仅当前组件使用？ 组件内部状态 remember + mutableStateOf 同屏幕多个组件共享？ 屏幕级状态 ViewModel + StateFlow 跨屏幕 / 需持久化？ 全局状态 Repository / DataStore 重新考虑 决策原则：每次仅提升到刚好能满足共享范围的最小层级 避免过早全局化导致测试困难、状态污染；但也不要在组件内部硬塞跨组件共享逻辑

实现流程：从组件内部逐步提升到屏幕级

以支付金额输入组件为例，展示逐级提升的完整步骤。

  1. 初始阶段（组件内部状态）：在输入框 Composable 中使用 remember { mutableStateOf("") } 保存金额。
  2. 发现问题：支付确认按钮也需要读取金额用于校验和提交，此时需要将状态上提到父级，成为屏幕级状态。
  3. 提升到屏幕级：在 ViewModel 中声明 MutableStateFlow<String>，在 Composable 中通过 viewModel() 获取，输入框和确认按钮都订阅该流。
  4. 进一步需求：用户退出支付页后回到首页，再进入支付页希望保留上次输入的金额。此时需要将状态进一步持久化到全局存储（如 DataStore）。

代码对比：组件内部 vs 屏幕级

组件内部版本（劣化写法，无法共享）

@Composable
fun AmountInput() {
    var amount by remember { mutableStateOf("") }
    OutlinedTextField(
        value = amount,
        onValueChange = { amount = it },
        label = { Text("金额") }
    )
    // 确认按钮无法直接访问amount
}

提升到屏幕级（推荐写法，ViewModel 共享）

// ViewModel
class PaymentViewModel : ViewModel() {
    private val _amount = MutableStateFlow("")
    val amount: StateFlow<String> = _amount.asStateFlow()

    fun onAmountChanged(value: String) {
        _amount.value = value
    }
}

// Composable
@Composable
fun PaymentScreen(viewModel: PaymentViewModel = viewModel()) {
    val amount by viewModel.amount.collectAsState()
    Column {
        AmountInput(value = amount, onValueChange = { viewModel.onAmountChanged(it) })
        ConfirmButton(amount = amount) // 现在可以正确读取
    }
}

调试与常见错误

  • 错误：在组件内部使用 remember 存储需要跨组件共享的状态。 症状：点击确认按钮时无法获取最新输入值。解决：将状态提升到共同的父级或 ViewModel。
  • 错误：滥用全局状态导致内存泄漏。 例如将大量表单字段存入单例 Map 而不清理。解决：优先使用屏幕级状态，仅在真正需要跨屏持久化时才使用全局存储。
  • 调试技巧： 在 ViewModel 的 init 块中打印状态变化，或在 Composable 中使用 LaunchedEffect(Unit) 观察 StateFlow 收集情况，确认状态是否被正确传递。

性能与稳定性优化

层级 优化建议
组件内部 避免在 remember 中存储大数据对象（如图片Bitmap），仅保留轻量UI状态。
屏幕级 使用 derivedStateOf 合并多个 Flow 减少重组次数；避免在 ViewModel 中维护不必要的 Expensive 状态。
全局状态 使用 DataStore 代替 SharedPreferences 进行异步非阻塞读写；对于高频更新的全局状态（如网络连接状态），考虑使用 StateFlow 而非冷流。
常见陷阱： 将全局状态直接注入到 Composable 中作为 remember 的默认值，但不做观察更新。这样会导致状态变更后 UI 不刷新。务必使用 collectAsState() 或 observeAsState() 订阅。
← 上一章 📖 返回目录 下一章 →