哪些场景会在savedInstanceState中保存数据？系统对其还有哪些用途？如何关联Android生命周期？

嘿，我来帮你把savedInstanceState的这些疑问彻底捋明白——这玩意儿算是Android生命周期里的「隐形管家」，很多新手容易搞混它的触发场景和作用，咱们一步步拆解：

savedInstanceState的核心作用是在Activity临时销毁重建时保留状态，触发数据保存的场景主要有这几类：

• 系统配置变更：比如屏幕旋转、切换系统语言、横竖屏切换、调整字体大小，这时候Activity会被销毁后重建，系统会自动把View的状态（比如EditText的输入内容、CheckBox的勾选状态、ListView的滚动位置），以及你手动在onSaveInstanceState()里存入的自定义键值对，都打包进savedInstanceState。
• 后台Activity因内存不足被销毁：当你的App处于后台，系统内存吃紧时，会优先杀掉后台的Activity释放资源。等用户再次切回你的App时，系统会用savedInstanceState帮你恢复之前的界面状态，让用户感觉App好像没被关掉过。
• 其他临时销毁重建场景：比如切换到分屏/多窗口模式、Activity被来电界面/系统弹窗短暂覆盖后又回到前台，只要系统判定这个Activity需要恢复状态，就会触发savedInstanceState的保存逻辑。

除了帮你恢复自定义数据，它还有这些「隐藏功能」：

• 维持View层级的自动恢复：系统会自动遍历Activity的整个View树，把每个带id的View的状态（比如SeekBar的进度、Switch的开关状态）保存到savedInstanceState里，你不用手动写代码处理这些基础View的状态恢复，系统会帮你搞定。
• 辅助Fragment状态恢复：Fragment的实例和内部状态也依赖savedInstanceState。当Activity重建时，系统会用savedInstanceState来恢复Fragment的实例，以及你存在arguments之外的临时数据（比如Fragment里的表单输入内容）。
• 保证状态连续性：比如用户正在填写一份长表单，突然切到后台处理其他事，回来时能直接回到之前填写的进度，大幅提升用户体验，避免重复操作的烦躁感。

这部分是最容易搞混的，咱们把调用顺序理清楚：

1. 保存阶段：当系统要销毁Activity但还可能重建它时，会在onStop()方法之前（部分版本可能在onPause()之后）调用onSaveInstanceState(Bundle outState)。你可以在这个方法里把需要保存的自定义数据（比如用户输入的临时内容、当前选中的tab索引）放进outState这个Bundle里。

   注意：如果是用户主动关闭Activity（比如按返回键、调用finish()方法），系统不会触发onSaveInstanceState()，因为不需要恢复状态了。

2. 恢复阶段：当Activity被重建时，有两个地方可以拿到savedInstanceState：
   • onCreate(Bundle savedInstanceState)：这个方法的参数就是保存的状态Bundle，如果它不为null，说明当前是重建场景，你可以在这里恢复数据。
   • onRestoreInstanceState(Bundle savedInstanceState)：这个方法在onStart()之后调用，专门用来处理状态恢复，它的参数和onCreate里的是同一个Bundle。如果你觉得把恢复逻辑和初始化逻辑分开更清晰，就可以把恢复代码放在这里。

另外要注意：savedInstanceState只能保存可序列化的数据（比如基本类型、String、Parcelable、Serializable对象），不能存储大对象、Context或者其他无法序列化的实例，不然会抛出异常或者导致内存问题。

内容的提问来源于stack exchange，提问作者Ariel