在第13周之前，我一直认为“旋转屏幕丢数据”只是个小事——Demo里丢了就重新输入即可。其实，

但当使用者在填写一个长表单到第八个字段时手机突然翻转。或者在搜索页输入关键词滑到第三屏后切出微信，等到回来的时候App进程被程序回收，页面会被重建。其实，此时使用者之前填好的内容是否还在？如果不在他们不会说这是Android机制问题，而是觉得这个App很难用。

一、先搞清楚：状态到底什么时候会丢

状态丢失不是一种情况，而是三种完全不同的场景，对应的方法也不一样：

再看关键细节，当使用者主动退出时程序不会帮你保存任何状态（). 官方文档明确写到这点。我们只需关注前两种“非使用者本意”的重建。

二、View 自动保存：程序的免费能力

很多人没意识到一个事实：你什么都不写，EditText里的文字旋转后也不会丢。

程序默认把布局里每个 View 的状态存进 instance state Bundle——EditText 的文本、CheckBox 的勾选、SeekBar 的进度、ScrollView 的滚动位置，都在其中。

官方文档写得很明确：

Demos中的区域①验证了这一点：

No Kotlin code needed – 输入文字或勾选后旋转，两样都还在。

大厂实践映射

• 方向这方面，内容社区、电商App发布页和搜索页。
• 处理问题的观点是，发布页常有标题/正文/标签等多个输入字段；利用程序自动保存可以覆盖大部分纯UI状态，只需手写业务变量。

相关技术清单

• ID & saveEnabled & generateViewId & onSaveInstanceState.
• Systerm机制：按ID为key存入instance state Bundle。
• Pitfalls：动态创建View忘setId导致静默丢失；密码框忘关saveEnabled导致明文泄漏。

三、onSaveInstanceState：成员变量的救生艇

对比普通成员变量和onSaveInstanceState写入Bundle：

// 普通成员变量
private var notSavedCounter = // 未保存
// 会被写进 Bundle 的变量
private var savedCounter =
override fun onSaveInstanceState {
super.onSaveInstanceState
outState.putInt
}

"notSavedCounter" 在全新实例中归零；"savedCounter" 从Bundle里读回来保持数值。界面上红绿两行数字直观对比。

1. #super.onSaveInstanceState: 必须调用，否则自动保存失效。

• #取舍判断: • 序列化成本高于复杂对象；若数据模型较大请考虑 ViewModel + SavedStateHandle.

大厂实践映射

• 说到参考方向。表单填写页、下单确认页、滤镜/编辑参数页
• 处理问题这方面，多步表单中间态必须扛住配置变化；编辑类页面参数丢失等于白操作
• 至于取舍判断，onSaveInstanceState 写入读取都要序列化且发生主线程，仅适合 Int/String/小对象。不适合整个页面的数据模型 — 后者是第六节反面教材

相关技术清单

• API / 类 ： onSaveInstanceStat、 onRestoreInsta…Bundle.putInt/getInt isFinishing 
• 程序机制 ： instance state Bundle 程序进程侧持有。Activity 重建时交还 
• 常见坑 ：忘记调 super，在 on…做 IO，指望 finish 后还能恢复 

四、ViewModel：配置变化场景的最优解

<="">

kotlin class Week13StateViewModel( private val state : SavedSta…) : ViewModel{ /** 内存状态 */ var memoryCount…= ，}

Activity 用 by viewModels 获取

kotlin private val viewModel : Week13St…by viewModels binding.tvVmInst….text= “VM 实例:${System.iden…}”

by viewModels 是 activity‑ktx 提供委托；背后向当前 Activity 的 ViewModelStore 请求实例。老实说，配置变化时 Activity 重建，但 ViewModelStore 被保留。通过 NonConfigurationInstances 把同一实例传递给新 Activity —— hashCode 不变。

缺少 ViewModel 时要么塞进 Bundle，要么用静态变量。ViewModel 是官方正解。说起来，

但边界必须说清楚：《ViewModel 活但是进程死亡》——Demo 中开启“不保留活动”后按 Home 再回来hashCode 改变计数归零。

正确定位 - 配置变化场景下把“重建成本高但可重新加载”的数据放到 ViewModel。- 别把它当万能方案，

• 至于参考方向。信息流列表页、搜索结果页
• 处理问题这方面，“列表旋转后是否重新请求网络？”答案是—不应该——数据放 ViewM…老实说，，零网络开销零等待体验差距显著。
• 取舍判断 ：ViewM…省掉序列化，但代表着它不参与程序保存流程。进程死亡后数据模型丢失设计使然可通过 SavedStat… 存“线索”，重建后按线索重新加载。

五、SavedStatHandle：进程死亡也能恢复的组合拳

SavedStatHandle 是补这个口子的工具。它是 ViewModel 构造参数里的一个 Map 类结构，写入的数据会被程序以序列化副本保存在程序进程侧，即使进程死亡重建也可取。

kotlin class Week13StatV…: Vi，

companion object{ const val KEYSEARCHQUERY ="week13searchquery" }

val savedQuery : MutableLiveData=state.getLiveData fun updateQuery{ state = q }

构造函数只声明 SavedStatHandle 一个参数。ComponentActivity 默认 SavedStatVe...Factory 会自动注入，无需手写 Factory — 新手最易卡住点。

Activity 示例

kotlin viewM….savedQuery.observe{ query -> binding.tvSavedQue..text= “SavedStatHandle 中的搜索词:$query” } binding.btnSav..setOnClickListener{ viewM.updateQue.orEmpty) }

测试方式这方面，1️⃣ 输入搜索词并写入；2️⃣ 开发者选项打开“不保留活动”；3️⃣ 按 Home 回到最近任务。不过，此时看到的观点是，- ViewM hashCode变了但搜索词仍在 —— SavedStatHandle 生效。

⚠️ 写入 SavedStatHandle 的数据，只在宿主 Activity 进入 stopped 状态 时才真正交给程序保存。若 Activity 一直停在 Resumed 状态接下来突然被杀，其最近写入可能没落进去。但正常使用场景都会经过 onStop，所以无需恐慌。

底层机制是 SavedStatiRegistry: ComponentActivity 实现了 SavesRegOwner,各组件向其注册 SavesProvider;程序在保存状态时统一回调 saveSta... 收集成 Bundle。SavedStatHandle 本质上就是这套机制给 ViewM…开的官方通道，

实践案例

处理问题 ： 搜索词/筛选条件/当前 Tab 是“重建页面最小线索”。即使进程死亡，只要有这些线索，就能重新请求数据把页面恢复到离开前样子；无线索只能回初始态，

取舍判断 ： SavedStatHan... 与 onSavaInstan... 同受 Bundle 限制——只放基本类型和小对象，一样需要主线程序列化。其价值不是“存更多”，而是让 ViewM…架构下有官方通道避免为保存状态而倒腾业务层代码。

六、轻量化保存：存 ID，不存数据

前几节反复出现约束：Bundle 系列方案仅适合小数据。至于本节量化解释，

为什么必须小？不过，1️⃣ 序列化在主线程执行 — 配置变化本身就要重建整个页面再多干一次序列化直接表现为卡顿。2️⃣ 占用程序进程内存 — Bundle 序列化副本放在程序侧，你越多越占空间。3️⃣ Binder 限制 — 跨进程传输走 Binder，每个事务缓冲区约1MB共享。当Bundle太大直接抛 TransactionTooLargeException 并崩溃。

Demo 区域⑤ 用 Parcel 实测两种写法体积差：

kotlin private fun measureBunlSize: Int { val parcel=Parc... return try{ parcel.writeBundl;parcel.dataSize }finally{parcel.recycl} } // 写法一：只存ID和滚动位置 val small=Bundl.apply{ putInt;putInt } // 写法二：存条模拟商品文本 val big=Bundl.apply{ putStringArrayList } // 条长文本

Parcel 就是跨进程前实际序列化格式，所以 parcel.dataSize 测量的是真实成本。

结果显示短文本已 +KB；真实列表带图片URL、多字段对象几百条破1MB 非难事。正确姿势是只存最小线索：

vbscript // 死亡后按 ID 恢复，而不是整张列表 outSt.putInt outSt.putInt

重建后用 ID 从缓存或网络拿回来。这正是官方文档反复强调原则：“saved state里只放‘重建所需最少信息’。”

大厂实践映射

• 方向 ： 电商商品详情页／外卖点单页／内容详情页          | ｜ | ｜ | ｜ | ｜ |

处理问题 ： 商品详情需要保留 “当前SKU id + 规格面板展开 + 滚动位置”，整个商品模型必须留在缓存层；把模型塞进去 App 在低配机旋转会出现明显卡顿甚至 TransactionTooLargeException 崩溃。老实说，

取舍判断 ： “仅存 ID 重构”的代价可能出现一次加载等待。所以需配合缓存策略： 若 ViewM…存活则直接用 否则查内存/磁盘缓存，再走网络。这既不是二选一，而是 状态 保存 与 缓存 策略协同。|

技术清单

• API / 类 : Parcel.obtain,parcel.writeBundl,parcel.dataSize。TransactionTooLargeException .                                                                                                                                                                                     

常见坑: 把 Bitmap / 整个 JSON 列表塞 Bundl;老实说，误以为1MB 单次独占而非共享缓冲区;|

│ │ │ │ │ │ │ │ ││ |

|

.

七、方案选型：一张表收口

...

方案​↕︎​✅✔✔✓✔✔✓✔✓✓✔✔✅✅✅✅✅✅✅✔✔✔✓✓✓✓✓✓✓✿✿✿✿✿✿✿✿✿✿✿✿✿✿བབབབབབིིིིྍྍྍྍྍ༐༐༐༐༐༝༝༝༝͹͹͹͹͹ͩͩͩϵϵϵϵϵϴϴϴϴϴ\ud83e\udca9\u001d\u001d\u001d\u001d\u001d\u001d\u001d\u001d\u001d\ud83e\udd27 \ud83e\udd27 \ud83e\udd27 \ud83e\udd27 \ud83e\udd27 \ud83e\udd27                           */

理由​↕︎​⏱⏱⌛⌛⌛⌛⌛⌛⌛⌛⌋⌋⌋⏱⏱➡➡➗➗➗➗➗➗➗ ➕

备注​↕︎​ⓦⓧⓦⓧⓥⓥⓦⓦⓧⓧⓤ⒄⒄⒄⒄❁❁❂❂❃❃⭕⭕⭕⭕♥♥♥♥♥♥❤️❤️❤️❤️❤️❤❤❤❤❤❤❤ ❤❤❤ ❤❤ ❤❤ ❤ ❤ ❤ ❤️ ❤️ ❤️ ❤️ ♥ ♥ ♥ ♥ ♥ ❤️ ❤️ ❤️❤️❤️☺☺☺☺☺☺☺☺☺☎☎☎☎☎☎☎☎☎☎☎☎☎☎ */

TOTAL COST REASONING OF STATE SE MECHANISMS

八、一周学习

主要

1. 「视图自动保存」必备唯一;动态 addView 忘 setId 将导致静默丢失—没有崩溃。没有日志，却只有使用者投诉！怎么说呢，长表单快速填完却因翻屏遗失所有输入！搜索结果翻至第三屏因切出微信返回却看不到之前关键词！，