Activity详解（二）——异常情况下的生命周期分析

Posted 2023-04-18

参考技术A 最近 无意当中看到一道面试题是关于Activity异常情况下的生命周期分析，感觉自己还有所欠缺，随即在书中寻找完整答案，特记录如下。

常见的异常情况有两种，资源相关的系统配置发生改变以及系统内存不足时，Activity就会被杀死

在默认情况下，如果我们的Activity不做特殊处理，那么当系统配置发生改变后，Activity就会被销毁并重新创建，其生命周期如下图：

当系统配置发生改变后，Activity会被销毁，其onPause，onStop，onDestroy均会被调用，由于Activity是在异常情况下终止的，系统会调用onSaveInstanceState来保存当前Activity的状态。

如图：当竖屏切换到横屏时，测试log如下：

当由横屏切换到竖屏的时候，测试log如下：

由此我们可以看出，当系统配置发生改变后，Activity会被销毁，其中onPause，onStop，onDestory均会被调用，同时由于Activity是在异常情况下终止的，系统会调用onSaveInstanceState来保存当前Activity的状态。由上图我们可以看出，onSaveInstanceState调用时机是在onStop之前，需要说明的是这个方法只会出现在Activity被异常终止的情况下，正常情况下系统不会回调这个方法。当系统重建的时候会调用onRestoreInstanceState这个方法，并且把Activity销毁时onSaveInstanceState方法所保存的Bundle对象作为参数同时传递给onRestoreInstanceState和onCreate方法，因为我们可以通过onCreate和onRestoreInstanceState方法来判断Activity是否被重建了，如果被重建了，那么我们就可以取出之前保存的数据并恢复，从上图我们可以看出，onRestoreInstanceState的调用时机是在onStart之后。

同时，我们知道onSaveInstanceState和onRestoreInstanceState方法当中，系统为我们做了一定得恢复工作。当Activity在异常情况下需要重新创建时，系统会默认为我们保存当前的Activity的视图结构，并且在Activity重启后为我们恢复这些数据。比如文本框中用户输入的数据，ListVIew滚动的位置等。这些View相关的状态系统都能够默认为我们恢复。

关于保存和恢复View层次结构，系统的工作流程是这样的：首先Activity被意外终止时，Activity会调用onSaveInstanceState去保存数据，然后Activity会委托Window去保存数据，接着Window再委托它上面的顶级容器去保存数据。顶层容器是一个ViewGroup，一般来说它可能是DecorView。最后顶层容器再去意义通知它的子元素来保存数据，这样整个数据保存过程就完成了。可以发现，这就是一种典型的委托思想，上层委托下次，父容器委托子元素去处理一件事情。

针对onSaveInstanceState方法还需要有一点说明，那就是系统只会在Activity即将被销毁并且有机会重新显示的情况下才会调用它。当Activity正常销毁的时候，系统不会调用onSaveInstanceState，因为被销毁的Activity不可能再次被显示。比如我们上文提到的旋转屏幕所造成的Activity异常销毁，这个过程和正常停止Activity是不一样的，因为旋转屏幕后，Activity被销毁的同时会立刻创建Activity实例，这个时候Activity有机会再次立刻展示，所以系统要进行数据存储。这里可以简单地这么理解，系统只在Activity异常终止的时候才会调用onSaveInstanceState和onRestoreInstanceState来存储和恢复数据，其他情况不会触发这个过程。

这种情况，不是很好模拟，但是其数据存储和恢复过程和情况1完全一致，这里我们描述一下Activity的优先级情况，Activity按照优先级从高到低，可以分为如下三种：

1）前台Activity——正在和用户交互的Activity，优先级最高

2）可见但是非前台Activity——比如Activity中弹出了一个对话框，导致Activity可见但是位于后台无法和用户直接交互

3）后台Activity——已经被暂停的Activity，比如执行了onStop，优先级最低

当系统内存不足时，系统就会按照上述优先级去杀死目标Activity所在的进程，并且后续通过onSaveInstanceState和onRestoreInstanceState来存储和恢复数据，如果一个进程中没有四大组件在执行，那么这个进程将很快被系统杀死，比较好的方法是将后台工作放入Service中从而保证进程有一定的优先级，这样就不会轻易地被系统杀死。

####欢迎关注公共号


Android 的生命周期

参考技术A Android的生命周期分为两个部分内容：（异常情况下的生命周期的关注点和典型情况下略有不同）

一、典型情况下的生命周期，是指在有用户参与的情况下，Activity所经历的生命周期的改变。在正常情况下，Activity会经历如下生命周期：

1）onCreate():我们可以做一些初始化的工作，比如调用setContentView去加载界面布局资源、初始化Activity所需数据等。

2）onRestart:表示Activity正在重新启动。一般情况下，当当前Activity从不可见重新变为可见状态时，onRestart就会被调用。这种情形一般是用户行为所导致的，比如用户按Home按键切换到桌面或者用户打开了一个新的Activity，这时当前的Activity就会暂停，也就是onPause和onStop被执行了，接着用户又回到了这个Activity,就会出现这种情况。

3）onStart:表示Activity正在被启动，即将开始，这时Activity已经可见了，但是还没有出现在前台，还无法和用户交互。

4）onResume:表示Activity已经可见了，并且出现在前台并开始活动。 onStart和onResume都表示Activity已经可见，但是onStart的时候Activity还在后台，onResume的时候Activity才显示到前台。

5) onPause:表示Activity正在停止，正常情况下，紧接着onStop就会被调用。在特殊情况下，如果这个时候快速的再回到当前Activity，那么onResume就会被调用。此时可以做一些存储数据、停止动画等工作， 但是注意不能太耗时，因为这会影响到新的Activity的显示，onPause执行完，新的Activity的onResume才会执行。（在新的Activity需要先onPause后，新的Activity才能启动，所以是旧的Activity先onPause，然后新的Activity再启动）

6）onStop:表示Activity即将停止，可以做些稍微重量级的回收工作，同样不能太耗时。

7）onDestroy：表示Activity即将被销毁，这是Activity生命周期中的最后一个回调，可以做些回收工作和最终的资源释放。

针对上图，这里在附加一下具体的说明，分如下几种情况：

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是配对的，随着用户操作或者设备屏幕的点亮和熄灭这两个方法可能被多次调用。

附：当新启动一个Activity的时候，旧Activity的onPause会先执行，然后才启动新的Activity。验证

        结论：不能在onPause中做重量级的操作，因为必须onPause执行完成后以后新的Activity才能Resume。onPause和onStop都不能执行耗时操作，尤其是onPause，这也意味着，我们应当尽量在onStop中操作，从而使得新的Activity尽快显示出来并切换到前台。

二、异常情况的生命周期，是指Activity被系统的回收或者由于当前设备的Configuration发生改变从而导致Activity被销毁重建。

1.情况1：资源相关的系统配置发生改变时，导致Activity被杀死并重新创建。

       拿最简单的图片来说，当我们把一张图片放在mipmap目录后，就可以通过Resource去获取这张图片，同时为了兼容不同的设备，我们可能还需要在其他的一些目录放置不同的图片，比如mipmap-mdpi、mipmap-hdpi等，这样当程序启动时，系统就会根据当前设备的情况去加载合适的Resource资源，比如说横屏手机和竖屏手机会拿到两张不同的图片(设定了landscape或者portrait状态下的图片）。比如说当前的Activity处于竖屏状态，如果突然旋转屏幕，由于系统配置发生了改变，默认情况下、Activity就会被销毁并且重新创建，当然我们可以阻止系统重新创建我们的Activity。

       系统会调用onSaveInstanceState来保存当前Activity的状态，这个方法的调用时机在onStop之前，它和onPause没有既定的时序关系，既可能在onPause之前调用，也可能在onPause之后调用。 正常情况系统不会回调这个方法！ 当Activity被重新创建后，系统就会调用onRestoreInstanceState,并且把Activity销毁时onSaveInstanceState方法所保存的Bundle对象作为参数同时传递给onRestoreInstanceState和onCreate方法，从时序上来看，onRestoreInstanceState的调用时机在onStart之后。

       在onSaveInstance和onRestoreInstanceState方法中，系统自动为我们做了一定的恢复工作。当Activity在异常情况下需要重新创建时，系统会默认为我们保存当前Activity的视图结构，并且在Activity重启后为我们恢复这些数据，比如文本框中用户输入的数据、ListView滚动的位置等， 这些View相关的状态，系统都能够默认为我们恢复 。系统能够自动地做一些View层次结构方面的数据存储和恢复。比如TextView可以保存文本选中的状态和文本内容。

eg:

       首先我们在onSaveInstance中存储一个字符串，然后当Activity被销毁并重新创建后，我们再去获取之前存储的的字符串。接手的位置可以是onRestoreInstanceState或者onCreate。二者的区别是：onRestoreInstanceState一旦被调用，其参数Bundle savedInstanceState一定是有值的，我们不用额外地判断是否为空；但是onCreate不行，onCreate如果是正常启动的话，其参数Bundle savedInstanceState为null，所以必须要额外的判断。官方文档建议采用onRestoreInstanceState去恢复数据。

       注意：系统只在Activity异常终止的时候才会调用onSaveInstanceState和onRestoreInstanceState来存储和恢复数据，其他情况不会触发这个过程。

2.情况2：资源内存不足导致低优先级的Activity被杀死（数据存储和恢复过程和情况一完全一致）

Activity按优先级从高到低，可以分为如下三种情况：

1）前台Activity：正在和用户交互的Activity，优先级最高。

2）可见但非前台Activity-比如Activity中弹出了一个对话框，导致Activity可见但是位于后台无法和用户直接交互。

3）后台Activity-已经被暂停的Activity，比如执行了onStop。优先级最低。

问题：当系统配置发生改变，如何阻止系统重新创建Activity？指定ConfigChanges属性

由于编译时指定的minSDKVersion和targetSDKVersion有一个大于13，所以为了防止旋转屏幕时Activity重启，除了orientation，我们还要加上screenSize。

结论：Activity的确没有重新创建，并且也没有调用onSaveInstanceState和onRestoreInstanceState来存储和恢复数据，取而代之是系统调用了onConfigurationChanged方法，这个时候我们可以做一些自己的处理了。

附：

configChanges的三个常用项目和含义：

1）local 设备的本地位置发生了改变，一般指切换了系统语言。

2）keyboardHidden 键盘的可访问性发生了改变，比如用户调出了键盘。

3）orientation 屏幕方向发生了改变，比如旋转了手机屏幕。