深入理解Activity生命周期（二）

        上一篇博客深入理解Activity（一）中讲述了正常情况下Activity的生命周期，然而，在实际用户操作中Activity有可能因为一些异常情况比如当资源相关的系统配置发生改变以及系统内存不足而被杀死，这种情况Activity的生命周期又会怎样呢？接下来我们分析下Activity异常情况下的生命周期。

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

系统配置发生改变时，在默认情况下，Activity就会被销毁并且重新创建。举个例子，当应用程序启动时，系统就会根据当前的设备的情况去加载合适的Resources资源（drawable-mdpi、drawable-hdpi...），比如说横屏手机和竖屏手机会拿到两张不同的图片，如果突然旋转屏幕，由于系统配置发生了改变，Activity就会被销毁并重新创建。

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

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

        当Activity在异常情况下需要重新创建时，系统会默认为我们保存当前Activity的视图结构，并且在Activity重启后为我们恢复这些数据，比如文本框中用户输入的数据、ListView滚动的位置等。关于保存和恢复View层次结构，系统的工作流程是这样的：首先Activity被意外终止时，Activity会调用onSaveInstanceState去保存数据，然后Activity会委托Window去保存数据，接着Window再委托它上面的顶级容器去保存数据。顶层容器是一个ViewGroup，一般来说它很可能是DecorView。最后顶层容器再去一一通知它的子元素来保存数据，这样整个数据保存过程就完成了。

        恢复数据接收的位置可以选择onRestoreInstanceState或onCreate，二者的区别是onRestoreInstanceState一旦被调用，其参数Bundle savedInstanceState一定是有值的，我们不用额外地判断是否为空；但是onCreate不行，onCreate如果是正常启动的话，其参数Bundle savedInstanceState为null，所以必须要额外判断。这两个方法我们选择任意一个都可以进行数据恢复，但是官方文档的建议是采用onRestoreInstanceState去恢复数据。

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

情况2：资源内存不足导致低优先级的Activity被杀死

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

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

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

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

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