读书笔记-艺术探索-Activity的生命周期

1. Activity 的生命周期

1.0 前言

本文总结自任玉刚老师的《Android开发艺术探索》，文章中的【示例】在这里

1.1 Activity的总体介绍

  在Android开发中，正常情况下，除了Window , Dialog , Toast ，我们能见到的界面只有Activity。所以毋庸置疑Activity是很重要的。
  平时开发中对于Activity的生命周期，Flags，IntentFilter的匹配规则，Intent的匹配过程这类的实际应用可能比较少，所以对此还是比较陌生的，但是Activity对要深入了解一个应用程序，优化一个应用程序等等来说是还是非常重要的，现在就来回顾一下：

1.2 Activity的生命周期

1.2.1 典型情况下的生命周期

  典型情况就是正常的情况...不正常的下一小节再说，先上一张所有Android学习者都看过的图：

[图片上传失败...(image-5c19fc-1525574855834)]

• (1) onCreate : 表示Activity正在被创建，这个方法中通常做一些初始化工作，比如调用setContentView加载布局资源，初始化Activity所需数据等    [示例：针对一个特定的Activity，第一次启动回调如下：onCreate -> onStart -> onResume]

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

• (3) onResume : 表示Activity已经可见了，并且出现在前台并开始活动，接下来Activity已经完全运行了。

• (4) onPause : 表示Activity正在停止，正常情况下，紧接着onStop就会被调用，特殊情况下，如果这个时候快速地回到当前Activity，那么onResume会被调用（极端情况，用户很难复现该情况）。此时可以做一些储存数量、停止动画等工作，但是不能太耗时，因为这会影响新Activity的显示，onPause必须先执行完，新Activity的onResume才会执行。

• (5) onStop : 表示Activity即将停止，可以做一些稍微重量级的回收工作，同样不能太耗时。  [示例：用户打开新的Activity/切换到桌面/关闭屏幕时：onPause -> onStop (特殊情况：如果新Activity采用了透明主题或是一个dialog，那么当前Activity不会回调onStop)，再次回到原Activity时，onRestart -> onStart -> onResume]

• (6) onRestart : 表示Activity正在重新启动，一般情况下，当当前Activity从不可见重新变为可见状态时，onRestart就会被调用。

• (7) onDestory : 表示Activity即将被销毁，这是Activity生命周期最后一个回调，在这里可以做一些回收工作和最终的资源释放。[示例：用户按back键回退时，回调onPause -> onStop -> onDestory]

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

  Activity 的启动过程的源码相当复杂，简概来说是：启动Activity的请求会由Instrumentation来处理，然后通过Binder向ActivityManagerService(AMS)发请求，AMS内部维护着一个ActivityStack并负责栈内的Activity的状态同步，AMS通过ActivityThread去同步Activity的状态从而完成生命周期方法的调用。（看不懂）

  在ActivityStack中的resumeTopActivityInnerLocked方法中，有这么一段代码：

//ActivityStack.resumeTopActivityInnerLocked()
// If the flag RESUME_WHILE_PAUSING is set, then continue to schedule the previous activity
// to be paused, while at the same time resuming the new resume activity only if the
// previous activity can't go into Pip since we want to give Pip activities a chance to
// enter Pip before resuming the next activity.
final boolean resumeWhilePausing = (next.info.flags & FLAG_RESUME_WHILE_PAUSING) != 0
        && !lastResumedCanPip;

boolean pausing = mStackSupervisor.pauseBackStacks(userLeaving, next, false);
if (mResumedActivity != null) {
    if (DEBUG_STATES) Slog.d(TAG_STATES,
            "resumeTopActivityLocked: Pausing " + mResumedActivity);
    pausing |= startPausingLocked(userLeaving, false, next, false);
}

  上面代码的意思就是在新Activity启动之前，栈顶的Activity需要先onPause后，新Activity才能启动。最终在ActivityStackSupervisor中的realStartActivityLocked方法中调用如下代码：

//ActivityStackSupervisor.realStartActivityLocked()
app.thread.scheduleLaunchActivity(new Intent(r.intent), r.appToken,
    System.identityHashCode(r), r.info,
    // TODO: Have this take the merged configuration instead of separate global and
    // override configs.
    mergedConfiguration.getGlobalConfiguration(),
    mergedConfiguration.getOverrideConfiguration(), r.compat,
    r.launchedFromPackage, task.voiceInteractor, app.repProcState, r.icicle,
    r.persistentState, results, newIntents, !andResume,
    mService.isNextTransitionForward(), profilerInfo);

  这个app.thread的类型是IApplicationThread，而IApplicationThread的具体实现是ActivityThread中的ApplicationThread。所以这段代码实际调到了ActivityThread中，即ApplicationThread的scheduleLaunchActivity方法，而scheduleLaunchActivity方法最终会完成新Activity的onCreate、onStart、onResume的调用过程。因此可以得出结论：是旧Activiy先onPause，然后新Activity再启动(onCreate, onStart, onResume),旧activity再调用onStop。

  ActivityStackSupervisor.scheduleLaunchActivity最终会调用如下代码,从而完成onCreate、onStart、onResume的调用过程：

//ActivityThread.handleLaunchActivity()
private void handleLaunchActivity(ActivityClientRecord r, Intent customIntent, String reason) {
        // If we are getting ready to gc after going to the background, well
        // we are back active so skip it.
        unscheduleGcIdler();
        mSomeActivitiesChanged = true;

        if (r.profilerInfo != null) {
            mProfiler.setProfiler(r.profilerInfo);
            mProfiler.startProfiling();
        }

        // Make sure we are running with the most recent config.
        handleConfigurationChanged(null, null);

        if (localLOGV) Slog.v(
            TAG, "Handling launch of " + r);

        // Initialize before creating the activity
        WindowManagerGlobal.initialize();

        Activity a = performLaunchActivity(r, customIntent);

        if (a != null) {
            r.createdConfig = new Configuration(mConfiguration);
            reportSizeConfigurations(r);
            Bundle oldState = r.state;
            handleResumeActivity(r.token, false, r.isForward,
                    !r.activity.mFinished && !r.startsNotResumed, r.lastProcessedSeq, reason);

        ......
}

   从另外一个角度上说，通过分析这个问题，我们知道onPause和onStop都不能执行耗时的操作，尤其是onPause，这也意味着，我们尽量应当在onStop中做操作，从而使得新的Activity尽快显示出来到前台。

  【示例：当启动一个新Activity的时候，是否旧Activity的onPause先执行，再启动新的Activity】。

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

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

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

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

[图片上传失败...(image-7d3374-1525574855834)]

  当系统配置发生改变后，Activity会被销毁，其onPause、onStop、onDestory均会被调用，同时由于Activity在异常情况下终止，系统会调用onSaveInstanceState来保存当前Activity的状态。这个方法的调用时机实在onStop之前，他和onPause没有既定的时序关系。需要注意的是，这个方法只会出现在Activity被异常终止的情况下，正常情况下系统不会回调这个方法。当Activity被重新创建后，系统会调用onRestoreInstanceState，并且把Activity销毁时的onSaveInstanceState方法保存的Bundle对象作为参数同时传递给onRestoreInstanceState和onCreate方法。因此，我们可以通过onRestoreInstanceState和onCreate方法来判断Activity是否被重建了，如果是，那就可以取出之前保存的数据并恢复（在Activity重建的过程中，系统自动为我们做了一定的重建工作，每个View都有onSaveInstanceState和onRestoreInstanceState方法，看一下具体实现就知道系统为每个View恢复哪些数据）。

  保存和恢复View层次结构的流程：Activity被意外终止 -> Activity调用onSaveInstanceState保存数据 -> Activity委托Window保存数据 -> Window委托它上面的顶级容器(ViewGroup,一般是DecorView)保存数据 -> 顶层容器再一一通知它的子元素来保存数据 (典型的委托思想) 。

  下面拿TextView举例分析一下它到底保存了哪些数据：

//TextView.onSaveInstanceState()
@Override
    public Parcelable onSaveInstanceState() {
        Parcelable superState = super.onSaveInstanceState();

        // Save state if we are forced to
        final boolean freezesText = getFreezesText();
        boolean hasSelection = false;
        int start = -1;
        int end = -1;

        if (mText != null) {
            start = getSelectionStart();     //保存文本选中状态(Text selected state)
            end = getSelectionEnd();
            if (start >= 0 || end >= 0) {
                // Or save state if there is a selection
                hasSelection = true;
            }
        }

        if (freezesText || hasSelection) {
            SavedState ss = new SavedState(superState);

            if (freezesText) {
                if (mText instanceof Spanned) {
                    final Spannable sp = new SpannableStringBuilder(mText);

                    if (mEditor != null) {
                        removeMisspelledSpans(sp);
                        sp.removeSpan(mEditor.mSuggestionRangeSpan);
                    }

                    ss.text = sp;
                } else {
                    ss.text = mText.toString();     //保存文本内容(Text content)
                }
            }

            if (hasSelection) {
                // XXX Should also save the current scroll position!
                ss.selStart = start;
                ss.selEnd = end;
            }

            if (isFocused() && start >= 0 && end >= 0) {
                ss.frozenWithFocus = true;
            }

            ss.error = getError();

            if (mEditor != null) {
                ss.editorState = mEditor.saveInstanceState();
            }
            return ss;
        }

        return superState;
    }

  简单理解：系统只有在Activity异常终止的时候才会调用onSaveInstanceState和onRestoreInstanceState来存储和恢复数据，其他情况不会触发这个过程。
  【示例：Activity异常情况下重新创建（屏幕旋转）时，数据的储存与恢复】

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

Activity按照优先级从高到低，分为以下3种：
 (1) 前台Activity ———— 正在与用户交互的Activity， 优先级最高。
 (2) 可见但非前台Activity ———— 比如Activity中弹出了一个对话框，导致Activity可见但是位于后台无法与用户直接交互。
 (3) 后台Activity ———— 已经被暂停的Activity， 比如执行了onStop， 优先级最低。

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

  上文说的都是当系统配置发生改变后，Activity会被重新创建，下面讲到的是不重新创建的方法：给Activity指定configChanges属性，比如不想让Activity在屏幕旋转时重新创建：

    android:configChanges = "orientation"

项目（常用的）	含义
locale	设备所在地区发生变化，一般指切换了系统语言。
orientation	设备旋转，横向显示和竖向显示模式切换。
keyboardHidden	键盘的可访问性发生了改变，比如用户调出了键盘。
screenSize	当屏幕的尺寸信息发生了改变。当旋转设备屏幕时，屏幕尺寸会发生变化。
smallestScreenSize	设备的物理屏幕尺寸发生改变，这个项目和屏幕的方向没关系。

  当指定android:configChanges = "orientation|screenSize "时屏幕旋转，Activity不会被重新创建，也没有调用onSaveInstanceState和onRestoreInstanceState来存储和恢复数据，取而代之的是系统调用了Activity的onConfigurationChanged方法， 这时候就可以做一些自己的特殊处理了。
  【示例：Activity指定configChanges属性时屏幕旋转】