前言
在上一期 《Activity 生命周期的 3 个辟谣》 中，我们通过介绍网文普遍忽略的 “进程模式”，来帮助大家深入理解 Activity 生命周期 的设计依据、存在意义 及 注意事项。
并且，文末我还针对网文的 3 个讹传，来给大家辟了谣。
相信经过这样一次介绍，你对生命周期拥有了更加深刻的认识。
那么这一期，我们来结合现实的案例，来讲解一下 Activity 的重建机制。
文章目录一览
- 前言
- 因为心里没底，而不敢用的状态恢复
- 什么是重建？引发重建的场景有哪些？
- 为何要设计出重建的机制？有何好处？
- 状态保存和恢复的具体过程？（99% 的网文遗漏的关键细节）
- 状态保存和恢复的的注意事项？
- 如何避免 “配置发生变化” 导致的重建？
- 综上
因为心里没底，而不敢用的状态恢复
某天同事 A 向客户推送了 App 新版本，原以为万事大吉，毕竟经过了一周的打磨，各项功能都已趋于流畅稳定，没想到，在客户近乎变态的数据操作下，有客户反映 “页面切换巨卡”、“速度巨慢”。
为何会产生这种情况呢？我找到编写该页面的同事询问了缘由。
同事说，问题在于每次 onPause 时，为了避免App 切到后台被系统回收导致数据丢失，而做了大量的数据持久化操作。
那为什么不直接通过 Activity 的状态管理机制 来管理临时数据呢？
同事说，那东西“不靠谱”，用着感觉心里没底。
…… 是网上介绍 Activity 重建流程和状态管理的文章不够多吗？不是的，网文都有提到：当发生重建时，就会走 onSaveInstanceState 和 onRestoreInstanceState，
然而却没有一篇深入地探究过：当走 onSaveInstanceState 和 onRestoreInstanceState 时，过程中究竟经历了哪些细节、背后 决定状态被成功保存和恢复的关键条件 到底是怎样的。
这使得读者在使用这个机制时忐忑不安，无法 100% 确定不会出事。👀
于是在经过源码分析和再三的实测检验后，我将 “重建机制” 及 “状态管理机制” 的内容整理成这篇文章。
如果阅读完本文后，你对二者的缘起、规律有了明确的认识，从而 100% 放心地在日后工作中使用，那我的这番功夫就没白费 ~
什么是重建？引发重建的场景有哪些？
正常的生命周期流程，是页面从正常创建到销毁全流程。
而重建流程，则是在特定条件下，引发页面被销毁，并再次被创建的流程。
通常是 “系统资源的回收” 或 “配置发生变化” 导致的重建。
划重点 👆 👆 👆
系统资源回收是指：
当 App 处于背景模式时，可能因系统内存不足而被回收。
例如按下 Home 键切回桌面，或是接电话跳转到电话程序，都有可能使此前的这个 App 处于背景模式。
配置发生变化是指：
当系统配置发生变化时，比如屏幕方向、语言的改变。
为何要设计出重建的机制？有何好处？
一来： 对于资源回收的情况，保存状态并等到使用时再恢复，要比后台存留进程 所占的资源要小得多。
二来： 对于配置变化的情况，比如当屏幕方向发生变化时，唯有重建，才有机会加载不同的视图，如果横竖屏的布局不同的话。
状态保存和恢复的具体过程？
首先，“状态” 是指支撑 UI 界面内容展示的临时数据。
比如 EditText 中的文本、CheckBox 的勾选与否。
有且只有引发重建时，Activity 会走 onSaveInstanceState 和 onRestoreInstanceState，来保存和恢复状态。
onSaveInstanceState 执行在 onStop 之前，onRestoreInstanceState 执行在 onStart 之后。
其次，Activity 有两个数据结构用于保存状态：
一个是 View States，专门用于存储 View 的状态；
再一个是 Instance States，用于存储 View States 以及 开发者在 onSaveInstanceState 中手动保存的 Activity 成员变量。
在引发重建时，Activity 会自动为我们保存和恢复 View 的状态。具体表现为：
Activity 在 onSaveInstanceState 时，会 自动收集 View Hierachy 中每一个 “实现了状态保存和恢复方法” 的 View 的状态，这些状态数据会在 onRestoreInstanceState 时回传给每一个 View。并且回传时是依据 View 的 id 来逐一匹配的。
划重点 👆 👆 👆
其中，View 的状态数据会被收集到 View States 中，View States 也会随着 Activity 中其他被指定收集的成员变量，一同被收集到 Instance States 中，等待恢复时逐个恢复。
状态保存和恢复的的注意事项？
简言之：
1.为了成功保存状态，要求在 View 内部实现状态保存和恢复方法。
原生的 View 都有做到；如果是自定义 View，务必记住这一点；如果第三方 View 没做到，可以通过继承其来实现保存和恢复方法。
2.为了成功恢复状态，要求在布局中给 View 赋予相应的 id。
划重点 👆 👆 👆
3.如果是 Activity 的成员变量，需要额外在 Activity（子类）中重写 onSaveInstanceState 和 onRestoreInstanceState 方法。
注意：
Activity 中重写仅仅是为了额外地保存成员变量。重写方法时，记得要保留基类（super）的实现，Activity 正是在基类中完成 View 状态的保存和恢复。
划重点 👆 👆 👆
如何避免 “配置发生变化” 导致的重建？
在清单文件中为该 Activity 配置 android:configChanges 属性。
比如属性值 orientation|screenSize 对应着旋转屏幕，locale 对应着语言变化。
如此，在配置发生变化时，不会导致重建，而是走 onConfigurationChanged 回调。
综上
只要遵循 《状态保存和恢复的的注意事项》一节所提到的关键细节，就能稳妥地保存和恢复状态。
你再也不用为了临时数据而在 onPause 或 onStop 中执行重量级的持久化存储操作啦！
版权声明
本文以 CC 署名-非商业性使用-禁止演绎 4.0 国际协议 发行。
Copyright © 2019-present KunMinX
本文引言、思路及结论属于作者 KunMinX 原创，当您借鉴或引用本文的引言、思路、结论进行二次创作，或全文转载时，须注明链接出处，否则我们保留追责的权利。
