【Android - 组件】之Activity生命周期的全面分析

　　Activity是Android四大组件之首，其重要性不言而喻，Activity的生命周期更是我们了解Android工作机制的重中之重。我们一般将Activty的生命周期做两种情况下的理解，即正常情况和异常情况。

　　所谓正常情况下的生命周期，指的是在有用户参与的情况下，Activity所经过的生命周期的改变；

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

　　接下来我们来依次深入了解一下这两种情况下Activity的生命周期。

正常情况下的生命周期分析

　　正常情况下Activity的生命周期如下图所示：

　　（1） onCreate() ：Activity正在被创建时调用的生命周期函数；

　　（2） onStart() ：Activity能被用户看到时候调用的生命周期函数；

　　（3） onResume() ：Activity获取用户焦点的时候调用的生命周期函数；

　　（4） onPause() ：Activity失去用户焦点的时候调用的生命周期函数；

　　（5） onStop() ：Activity不能被用户看到的时候调用的生命周期函数；

　　（6） onDestroy() ：Activity即将被销毁的时候调用的生命周期函数；

　　（7） onRestart() ：Activity不可见而没有被销毁的情况下重新可见时调用的生命周期函数。

【注意】：

　　（1）生命周期函数基本上是配对的，如 onCreate() 方法和 onDestroy() 方法、onStart() 方法和 onStop() 方法、onResume() 方法和 onPause() 方法等；

　　（2）当打开一个新的 Activity 时，旧 Activity 的 onPause() 方法会先于新 Activity 的 onResume() 方法执行；

　　（3）由于上一条，因此不能在 onPause() 方法中做太过好事的操作，较为耗时的操作应该尽量放在 onStop() 方法中执行，从而使新 Activity 尽快显示出来。

异常情况下的生命周期分析

　　开头说过，导致Activity生命周期异常的情况有两种：Activity的配置发生改变，以及Activity被系统回收。

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

　　Activity中有很多配置信息，如果这些信息发生改变，那么Activty就可能会被杀死并重建。但是，我们可以通过代码来干预这些配置，设置某些配置即使发生改变，Activity也不会被杀死。系统配置中有很多内容，如果当某项内容发生改变后，我们不想系统重新创建Activity，则可以在Manifest文件中给这个Activity指定configChanges属性，示例代码如下：

<activity
    android:name=".ui.activity.LoginActivity"
    android:configChanges="orientation|keyboardHidden|orientation|screenSize"
    android:windowSoftInputMode="adjustResize|stateVisible">
    <intent-filter>
        <action android:name="android.intent.action.MAIN" />
        <category android:name="android.intent.category.LAUNCHER" />
    </intent-filter>
</activity>

　　例如，我们可以通过设置 android:configChanges 属性来禁止设置在横竖屏切换后被杀死并重建，只需要在Manifest文件的 <activity> 标签中添加 android:configChanges="orientation|keyboardHidden|screenSize" 即可。

　　更多的配置选项请参考下表：

　　【注意】：不同的配置选项之间可以通过“ | ”符号分隔。

　　如果我们不为Activity设置configChanges属性，那么当Activity被杀死重建之后，我们还能不能获取到之前的数据了呢？答案是可以的，我们可以通过Android系统为我们提供的两个方法 onSaveInstanceState() 和 onRestoreInstanceState() 来存储和取出数据。当Activity在异常情况下需要重新创建时，系统会默认为我们保存一些数据，如当前Activity的视图结构、文本框中用户输入的数据、ListView滚动的位置等。　　

　　如果我们需要将自定义的数据保存下来，可以重写 onSaveInstanceState() 和 onRestoreInstanceState() 这两个方法，使用Bundle对象存储自定义的数据，进行数据传递。

　　【注意】：

　　（1） onSaveInstanceState() 在onStop()方法之前执行， onRestoreInstanceState() 在onStart()方法之后执行；

　　（2） onSaveInstanceState() 和 onRestoreInstanceState() 在正常情况的生命周期中不会被调用，只有当生命周期发生异常时才会被调用；

　　（3） onCreate() 方法中有一个Bundle类型的参数，这个参数也是用于接收异常情况下传递的保存数据的，但是不建议在onCreate()方法中处理保存的数据，原因有二：第一，onCreate()方法中处理的事情已经够多了，我们应该将恢复数据的操作提到其他生命周期函数中；第二，每次开启Activity都会调用onCreate()方法，如果在onCreate()方法中恢复数据，那么每次都需要判断该Activity是否被重启了，即Bundle对象是否为空，这样很繁琐；

　　（4）和Activity相同，View中也有 onSaveInstanceState() 和 onRestoreInstanceState() 两个方法。Android系统保存和回复View层次结构中的数据的方法使用了委托思想，其流程是这样的：首先Activity被异常终止时，Activity会调用 onSaveInstanceState() 方法去保存数据，然后Activity委托Window去保存数据，接着Window再委托它上面的顶层容器去保存数据，最后顶层容器再去一一通知它的子元素来保存数据。数据恢复过程也是类似的，这样就保证了View层级树中的所有View中的数据都被保存并恢复了。

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

　　这里我们需要先了解一下Andorid系统中Activity的优先级分类，从高到低可以分为以下三类：

　　（1）前台Activity——正在和用户交互的（获取用户焦点的）Activity，优先级最高；

　　（2）可见但非前台Activity——用户可见但没有获取用户焦点的Activity；

　　（3）后台Activity——用户不可见、已经被暂停了的的Activity，优先级最低。

　　当系统内存不足时，系统就会按照上述优先级去杀死目标Activity所在的进程，并在后续通过 onSaveInstanceState() 和 onRestoreInstanceState() 来存储和恢复数据。

　　【注意】：如果一个进程中没有四大组件在执行，那么这个进程将很快被系统杀死，因此，一些后台工作不适合脱离四大组件而独立的运行在后台中，这样进程将很容易被杀死。比较好的方法是将后台工作放入Service中从而保证进程有一定的优先级，这样就不会轻易地被系统杀死。