UI状态的保存与恢复

转一下屏幕，表单全没了

用户填到一半旋转手机——输入框被清空，体验等于白填。原因是 配置变更 会重建 Activity，除非你把状态存到系统能带过去的地方。

两种主流方案：onSaveInstanceState（轻量）和 ViewModel（业务状态）。

onSaveInstanceState

override fun onSaveInstanceState(outState: Bundle) {
    super.onSaveInstanceState(outState)
    outState.putString("user_input", editText.text.toString())
}
 
override fun onCreate(savedInstanceState: Bundle?) {
    super.onCreate(savedInstanceState)
    setContentView(R.layout.activity_main)
    savedInstanceState?.getString("user_input")?.let { editText.setText(it) }
}

Bundle 约 1MB 上限，只适合字符串、整型等可序列化小数据。

ViewModel

class FormViewModel : ViewModel() {
    val userInput = MutableLiveData("")
}
 
class FormActivity : AppCompatActivity() {
    private val viewModel: FormViewModel by viewModels()
 
    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        editText.setText(viewModel.userInput.value)
        editText.doAfterTextChanged { viewModel.userInput.value = it.toString() }
    }
}

旋转后仍是同一个 ViewModel 实例——不必手动 Bundle 也能保住数据。

小结

• 旋转：ViewModel 或 onSaveInstanceState
• 进程被杀：onSaveInstanceState / SavedStateHandle
• ViewModel 不碰 View 层引用

“UI状态的保存与恢复”不使用未获授权的纸书正文；InformIT出版信息与授权电子版完整目录只用于确认第四版32章、269个正式目录节点和时代语境，第四版官方勘误用于识别工具链变更。下列中文解释、图示、交互、代码与练习均为独立教学重写，平台行为再以Android Developers的一手文档复核。

为什么“UI状态的保存与恢复”必须回到可观察状态

“UI状态的保存与恢复”的学习结果不是记住类名，而是能预测“掌握 onSaveInstanceState 和 ViewModel——让用户在旋转屏幕或进程被杀死后回到原来的界面状态。”在一次输入、一次重建和一次失败中的不同状态，并指出哪条Android合同产生差异。

第四版机制逐项深读

4. Persisting UI State

在“UI状态的保存与恢复”中，“4. Persisting UI State”要求把临时UI状态、配置期状态与进程死亡后需恢复的最小事实分层；ViewModel跨配置但不跨进程，saved state必须小且可序列化。

Including the ViewModel Dependency

在“UI状态的保存与恢复”中，分析“Including the ViewModel Dependency”要画出事件进入、状态归约、数据源写入和UI重绘四条边，并指出配置变化时谁被重建。

Adding a ViewModel

在“UI状态的保存与恢复”中，“Adding a ViewModel”按事实、界面表示和用户事件拆责任；状态所有者不能持有已销毁View，界面也不能绕过边界直接改持久数据。

Saving Data Across Process Death

在“UI状态的保存与恢复”中，“Saving Data Across Process Death”要求把临时UI状态、配置期状态与进程死亡后需恢复的最小事实分层；ViewModel跨配置但不跨进程，saved state必须小且可序列化。

ViewModel vs Saved Instance State

在“UI状态的保存与恢复”中，验证“ViewModel vs Saved Instance State”用同一事件序列比较旋转前后状态和副作用次数；界面相同但重复写入仍是不正确。

For the More Curious: Jetpack, AndroidX, and Architecture Components

在“UI状态的保存与恢复”中，验证“For the More Curious: Jetpack, AndroidX, and Architecture Components”用同一事件序列比较旋转前后状态和副作用次数；界面相同但重复写入仍是不正确。

For the More Curious: Avoiding a Half-Baked Solution

在“UI状态的保存与恢复”中，“For the More Curious: Avoiding a Half-Baked Solution”用于推翻“掌握 onSaveInstanceState 和 ViewModel——让用户在旋转屏幕或进程被杀死后回到原来的界面状态。”的顺利路径：先写预期，再引入一个边界输入、重建或平台差异，并用状态、日志与用户结果解释首个分叉。

“UI状态的保存与恢复”验收回顾

“UI状态的保存与恢复”只有在实例ID、回调轨迹、旋转与进程恢复后的状态断言能够从相同基线再次得到相同断言时才通过；第四版机制与现代平台政策分别记录，不用新API名称掩盖旧行为。

← 上一页：activity的生命周期 · 下一页：Android应用的调试 →

章专属可重放状态实验

先预测“旋转、后台进程回收与冷启动恢复”发生后，QuizViewModel、SavedStateHandle 与持久仓库应怎样改变题号、作答记录、临时输入和可恢复事实；再操作三个实验。第四版示例与当前 Android 政策分别记录，实验不把新 API 名称倒填为原书内容。

实验一：所有者—状态—结果合同

选择任一正式目录节点和正常/边界场景，检查它是否真的进入本章状态合同。目录标题只有同时出现在解释、可视状态和交付证据中才算覆盖。

实验二：事件与生命周期轨迹

沿五次转换逐步执行“旋转、后台进程回收与冷启动恢复”。每一步只允许QuizViewModel、SavedStateHandle 与持久仓库按职责提交状态，并持续核对“每类状态只由适合其寿命的所有者恢复且不重复提交副作用”。

实验三：章专属反例与同输入恢复

注入“只用 ViewModel 保存答案并假设它可以跨进程死亡”，保存第一个偏离点；撤销后以完全相同的 SDK、设备状态和用户事件重放。只有保存键、序列化值、进程 ID、恢复轨迹和行为断言一起恢复才算修复。