1.1 Avtivity的生命周期全面分析

本文将Activity的生命周期分为两部分内容，一部分是典型情况下的生命周期，另一部分是异常情况下的生命周期。所谓典型情况下的生命周期，是指在有用户参与的情况下，Activity所经过的生命周期的改变；而异常情况下的生命周期是指在Activity被系统回收或者由于当前设备的Configuration发生改变从而导致Activity被销毁重建，异常情况下的生命周期的关注点和典型情况下略有不同。

1.1.1 典型情况下的生命周期分析

在正常情况下，Activity会经历如下生命周期。

(1)onCreate:表示Activity正在被创建，这是生命周期的第一个方法，在这里可以做一些初始化操作，比如调用setContentView去加载界面布局资源、初始化Activity所需数据等。

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

(3)onStart:表示Activity正在被启动，即将开始，这时的Activity已经可见了，但是还没有出现在前台，还无法和用户交互。这个时候其实可以理解为Activity已经显示出来了，但是我们还看不到。

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

(5)onPause:表示Activity正在停止，正常情况下，紧接着onStop就会被调用。在特殊情况下，如果这个时候迅速地再回到当前Activity，那么onResume就会被调用。笔者的理解是，这种情况属于极端情况，用户操作很难重现这一场景。此时可以做一些存储数据、停止动画等工作，但是注意不能太耗时，因为这会影响新Activity的显示，onPause必须先执行完，新Activity的onResume才会执行。

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

(7)onDestory:表示Activity即将被销毁，这是Activity生命周期中的最后一个回调，在这里，我们可以做一些回收工作和资源释放。

正常情况下，Activity的常用生命周期只有上面7个，图1-1更详细直观地描述了Activity各种生命周期的切换过程。

图1-1 Activity生命周期切换过程
针对图1-1，这里再附加一下具体说明，分如下几种情况：

1. 针对一个特定的Activity,第一次启动，回调如下：onCreate ->onStart ->onResume。

2. 当用户再打开新的Activity或者切换到桌面的时候，回调如下：onPause -> onStop。这里有一种特殊情况，如果新Activity采用了透明主题，那么当前Activity不会回调onStop。

3. 当用户再次回到原Activity时，回调如下：onRestart -> onStart ->onResume。

4. 当用户按back键回退时，回调如下：onPause ->onStop ->onDestory。

5. 当Activity被系统回收后再次打开，生命周期方法回调过程和 (1) 一样，注意只是生命周期方法一样，不代表所有过程一样，这个问题在下一节会详细说明。

6. 从整个生命周期来说，onCreate和onDestroy是配对的，分别标识着Activity的创建和销毁，并且只可能有一次调用。从Activity是否可见来说，onStart和onStop是配对的，随着用户的操作或者设备屏幕的点亮和熄灭，这两个方法可能被调用多次；从Activity是否在前台来说，onResume和onPause是配对的，随着用户的操作或者设备屏幕的点亮和熄灭，这两个方法可能被调用多次。

这里提2个问题：

问题1：onStart和onReaume、onPause和onStop从描述上来看差不多，对我们来说有什么实质的不同呢？

问题2：假设当前的Activity为A,如果这时用户打开一个新Activity
B，那么B的onResume和A的onPause哪个先执行呢？

先说第一个问题，从实际使用过程来说，onStart和onReaume、onPause和onStop看起来的确差不多，甚至我们可以只保留其中一对。既然如此，那为什么Android系统还要提供看起来重复的接口呢？根据上面的分析，我们知道，这两个配对的回调分别表示不同的意义，onStart和onStop是从Activity是否可见这个角度来回调的，而onResume和onPause是从Activity是否位于前台这个角度来回调的，除了这种区别，在实际使用中没有其他明显区别。

第二个问题可以从Android源码里得到解释。关于Activity的工作原理在本文后续章节
会进行介绍，这里大致了解即可。从Activity的启动过程来看，我们来看一下系统源码。Activity的启动过程的源码相当复杂，涉及Instrumentation、ActivityThread和ActivityManageService(下面简称AMS)。这里不详细分析这一过程，简单理解，启动Activity的请求会由Instrumentation来处理，然后它通过Binder向AMS发请求，AMS内部维护着一个ActivityStack并负责栈内的Activity的状态同步，AMS通过ActivityThread去同步Activity的状态从而完成生命周期方法的调用。在ActivityStack中的resumeTopActivityInnerLocked方法中，有这么一段代码：

final boolean resumeTopActivityInnerLocked(ActivityRecord prev, Bundle options) {
        ...

        // We need to start pausing the current activity so the top one
        // can be resumed...
        boolean dontWaitForPause = (next.info.flags&ActivityInfo.FLAG_RESUME_WHILE_PAUSING) != 0;
        boolean pausing = mStackSupervisor.pauseBackStacks(userLeaving, true, dontWaitForPause);
        if (mResumedActivity != null) {
            if (DEBUG_STATES) Slog.d(TAG, "resumeTopActivityLocked: Pausing " + mResumedActivity);
            //调用start[
            pausing |= startPausingLocked(userLeaving, false, true, dontWaitForPause);
        }

        ...
        return true;
    }

从上述代码可以看出，在新Activity启动之前，栈顶的Activity需要先onPause后，新Activity才能启动，最终，在ActivityStackSupervisor中的realStartActivityLocked方法会调用如下代码：

app.thread.scheduleLaunchActivity(new Intent(r.intent), r.appToken,
                    System.identityHashCode(r), r.info, new Configuration(mService.mConfiguration),
                    new Configuration(stack.mOverrideConfig), r.compat, r.launchedFromPackage,
                    task.voiceInteractor, app.repProcState, r.icicle, r.persistentState, results,
                    newIntents, !andResume, mService.isNextTransitionForward(), profilerInfo);