本篇文章主要介绍以下几个知识点：
- Activity 的生命周期全面分析；
- Activity 的启动模式。
1.1 Activity 的生命周期全面分析
典型情况下的生命周期，指在有用户参与的情况下，Activity 所经过的生命周期的改变。
异常情况下的生命周期，指 Activity 被系统回收或由于设备的 Configuration 改变导致 Activity 被销毁重建。
1.1.1 典型情况下的生命周期分析
（1）针对一个特定的 Activity，首次启动，回调如下：onCreate ->onStart -> onResume。
（2）当用户打开新的 Activity 或切换到桌面时，回调如下：onPause -> onStop。（注：若新 Activity 采用了透明主题，则当前 Activity 不会回调 onStop）
（3）当用户再次回到原 Activity 时，回调如下：onRestart -> onStart -> onResume。
（4）当用户按 back 键回退时，回调如下：onPause -> onStop -> onDestroy。
（5）当 Activity 被系统回收后再次打开，生命周期方法回调过程和（1）一样。（注：只是生命周期方法一样，不代表所有过程都一样）
（6）整个生命周期：onCreate 和 onDestroy 是配对的（标识着 Activity 的创建和销毁，只调用一次）。
Activity 是否可见：onStart 和 onStop 是配对的（可能被调用多次）；
Activity 是否在前台：onResume 和 onPause 是配对的（可能被调用多次）。
问题 1：onStart 和 onResume、onPause 和 onStop 从描述上看差不多，对我们来说有什么实质的不同呢？
答：这两配对的回调具有不同的意义，onStart 和 onStop 是根据 Activity 是否可见来回调的，而 onResume 和 onPause 是根据 Activity 是否位于前台来回调的，除此之外，在实际使用中无其他明显区别。
问题2：假设当前Activity为A，若这时用户打开一个新Activity B，那么B的 onResume 和 A 的 onPause 哪个先执行呢？
答：当新启动一个 Activity 时，旧 Activity 的 onPause 会先执行，然后才会启动新的 Activity。（注：onPause 和 onStop 都不能执行耗时的操作，尤其是 onPause）
问题 3：onRestart 会在哪些场景调用？
答：当 Activity 从后台（非栈顶状态）重新回到前台时，系统会调用 onRestart()。例如，用户通过任务管理器恢复 Activity、按 Home 键返回后再次进入 Activity，或屏幕方向改变后重新显示时。
1.1.2 异常情况下的生命周期分析
- 情况 1：资源相关的系统配置发生改变导致 Activity 被杀死并重新创建
在默认情况下，若 Activity 不做特殊处理，当系统配置发生改变后，Activity 就会被销毁并重新创建，其生命周期如图：
当系统配置发生改变后，Activity 会被销毁，其 onPause、onStop、onDestroy 均会被调用，同时由于 Activity 是在异常情况下终止的，系统会调用 onSaveInstanceState 来保存当前Activity 的状态。
方法 onSaveInstanceState 的调用时机是在 onStop 之前（和 onPause 无既定的时序关系），并且只会在 Activity 被异常终止的情况下回调。
当 Activity 被重新创建后，系统会调用 onRestoreInstanceState，并把 Activity 销毁时 onSaveInstanceState 方法保存的 Bundle 对象作为参数同时传递给 onRestoreInstanceState 和 onCreate 方法。
因此，可以通过 onRestoreInstanceState 和 onCreate 方法来判断 Activity 是否被重建了，若被重建了，可取出之前保存的数据并恢复。（onRestoreInstanceState 在 onStart 之后调用）
关于保存和恢复 View 层次结构，其工作流程为：首先 Activity 被意外终止时，Activity 会调用 onSaveInstanceState 去保存数据，然后 Activity 会委托 Window 去保存数据，接着 Window 再委托它上面的顶级容器去保存数据。
- 情况 2：资源内存不足导致低优先级的 Activity 被杀死
Activity 按照优先级从高到低，可以分为如下三种：
（1）前台 Activity——正在和用户交互的 Activity，优先级最高。
（2）可见但非前台 Activity —— 如 Activity 中弹出一个对话框，导致 Activity 可见但位于后台无法和用户直接交互。
（3）后台 Activity——已经被暂停的 Activity，如执行了 onStop，优先级最低。
当系统内存不足时，系统会按上述优先级杀死目标 Activity 所在的进程，并在后续通过 onSaveInstanceState 和 onRestoreInstanceState 来存储和恢复数数据。
系统配置中有很多内容，当某项内容改变后，若不想系统重新创建 Activity，可以给 Activity 指定 configChanges 属性。
如给 configChanges 属性添加 android:configChanges="orientation" 可避免 Activity 在屏幕旋转时重新创建。
若想指定多个值，可用“|”连接起来，如 android:configChanges="orientation|keyboardHidden"。
系统配置中所含的项目很多，如下：
上表中项目很多，但常用的只有 locale、orientation 和 keyboardHidden 这三个。
值得注意的是 ，screenSize 和 smallestScreenSize 比较特殊，它们的行为和编译选项有关，和运行环境无关。
问题：
onSaveInstanceState是如何保存bundle对象的，保存在哪？
- 如何保存Bundle对象
- 保存方式：
在onSaveInstanceState(Bundle outState)方法中，开发者通过Bundle对象的putXXX()方法（如putString、putSerializable等）将数据存入Bundle。例如，可以保存字符串、自定义对象（需序列化）等。
示例代码中展示了将对象序列化为字节数组并存入Bundle的过程。- 保存时机：
当Activity因配置变化（如屏幕旋转）或内存不足时，系统会调用onSaveInstanceState()，此时保存的数据会被保存到Bundle中。
- 保存位置
Bundle对象保存在Android系统内部的内存中，具体由ActivityManager服务管理。具体而言，ActivityRecord（Activity的内部表示）的icicle字段（即Bundle）存储在ActivityManager服务的内存中。
- 系统层面：Bundle保存在SystemServer进程的ActivityRecord中，属于系统内存中的临时数据。
- 生命周期：数据仅在Activity的生命周期内有效，系统重启或进程被回收时数据会丢失。
- 恢复机制
当Activity重新创建时，系统会将保存的Bundle通过onCreate(Bundle savedInstanceState)或onRestoreInstanceState(Bundle savedInstanceState)方法传递回Activity，开发者可从中恢复数据。
- 总结
保存方式：通过putXXX()方法将数据存入Bundle。
保存位置：保存在Android系统内存中的ActivityManager服务管理的ActivityRecord中。
适用场景：用于保存临时状态（如UI状态、临时数据），不适用于持久化存储。
1.2 Activity 的启动模式
1.2.1 Activity 的 LaunchMode
（1）standard：标准模式。
系统的默认模式，每次启动一个 Activity 都会重新创建一个新的实例，不管这个实例是否已存在。
值得注意的是，用 ApplicationContext 去启动 standard 模式的 Activity 时会报错，如以下代码：
tv_text.setOnClickListener {
// 点击跳转到 KotlinActivity
val intent = Intent()
intent.setClass(applicationContext, KotlinActivity::class.java)
applicationContext.startActivity(intent)
}
运行会报如下错误：
这是因为 standard 模式的 Activity 默认会进入启动它的 Activity 所属的任务栈中，但由于非 Activity 类型的 Context（如 ApplicationContext）并无所谓的任务栈，从而报错。
解决上面问题的方法是为待启动 Activity 指定 FLAG_ACTIVITY_NEW_TASK 标记位，这样启动时就会为它创建一个新的任务栈（此时待启动 Activity 是以 singleTask 模式启动的）。
（2）singleTop：栈顶复用模式。
此模式下，若新 Activity 已经位于任务栈的栈顶，则此 Activity 不会被重新创建，同时它的 onNewIntent 方法会被回调，通过此方法的参数可以取出当前请求的信息。
值得注意的是，这个 Activity 的 onCreate、onStart 不会被系统调用，因为它并没有发生改变。
（3）singleTask：栈内复用模式。
一种单实例模式，此模式下，只要 Activity 在一个栈中存在，那么多次启动此 Activity 都不会重新创建实例，和 singleTop 一样，系统也会回调其 onNewIntent。
（4）singleInstance：单实例模式。
一种加强的 singleTask 模式，具有 singleTask 模式的所有特性，并且具有此种模式的 Activity 只能单独地位于一个任务栈中。
给 Activity 指定启动模式有两种方法：
1. 通过 AndroidMenifest 为 Activity 指定启动模式
2. 通过在 Intent 中设置标志位为 Activity 指定启动模式。
二者区别在于：
（1） 优先级上，方式2的优先级高于方式1，当两种同时存在时，以方式2为准；
（2） 限定范围不同，比如，方式1无法直接为 Activity 设定 FLAG_ACTIVITY_CLEAR_TOP 标识，而方式2无法为 Activity 指定 singleInstance 模式。
1.2.2 Activity 的 Flags
Activity 的 Flags 有很多，有的标记位可以设定 Activity 的启动模式，有的会影响 Activity 的运行状态等。常用的如下：
- FLAG_ACTIVITY_NEW_TASK
其作用是为 Activity 指定 singleTask 启动模式，效果和在 XML 中指定该模式相同。
- FLAG_ACTIVITY_SINGLE_TOP
其作用是为 Activity 指定 singleTop 启动模式，效果和在 XML 中指定该模式相同。
- FLAG_ACTIVITY_CLEAR_TOP
具有此标记位的 Activity 启动时，在同一个任务栈中所有位于它上面的 Activity 都要出栈。
此模式一般需要和 FLAG_ACTIVITY_NEW_TASK 配合使用，若被启动Activity 的实例已存在，则系统会调用它的 onNewIntent。
- FLAG_ACTIVITY_EXCLUDE_FROM_RECENTS
具有此标记的 Activity 不会出现在历史 Activity 的列表中（用于某些情况不希望用户通过历史列表回到 Activity 时）。它等同于在 XML 中指定 Activity 的属性 android:excludeFromRecents="true"。
本篇文章就介绍到这。
