1.1 Activity的生命周期

第一章 Activity的生命周期和启动模式

本章的侧重点是Activity在使用过程中的一些不容易搞清楚的概念,主要包括生命周期和启动模式以及IntentFilter的匹配规则分析。

1.1 Activity的生命周期全面分析

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

`Configuration`:专门用来描述手机设备上的配置信息。
1.1.1 典型情况下的生命周期分析

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

  • (1) onCreate(): 表示Activity正在被创建,这是生命周期的第一个方法。在这个方法中,我们可以做一些初始化的工作,比如调用setContentView()去加载界面布局资源,初始化Activity所需数据等。
  • (2)onRestart(): 表示Activity正在重新启动,一般情况下,当当前Activity从不可见重新变为可见状态时,onRestart就会被调用。
  • (3) onStart(): 表示Activity正在被启动,即将开始,这时Activity已经可见了,但是还没有出现在前台,还无法和用户交互。这个时候其实可以理解为Activity已经显示出来了,但是我们还看不到。
  • (4)onResume(): 表示Activity已经可见了,并且出现在前台并开始活动。要注意这个和onStart的对比,onStartonResume都表示Activity已经可见,但是onStart的时候Activity还在后台,onResume的时候Activity才显示到前台。
  • (5) onPause(): 表示Activity正在停止,正常情况下,紧接着onStop就会被调用。此时可以做一些存储数据,停止动画等工作,但是注意不能太耗时,因为这会影响到新Activity的显示,onPause必须先执行完,新ActivityonResume才会执行。
  • (6) onStop(): 表示Activity即将停止,可以做一些稍微重量级的回收工作,同样不能太耗时。
  • (7)onDestroy(): 表示Activity即将被销毁,这是Activity生命周期中的最后一个回调,在这里,我们可以做一些回收工作和最终的资源释放。
1.1 Activity的生命周期_第1张图片
Activity生命周期的切换过程

一个ActivityA跳转到另一个ActivityB,然后在finish。生命周期如下:

1. onCreateA
2. onStart()A
3. onResume()A
跳转
4. onPause()A
5. onCreateB
6. onStart()B
7. onResume()B
8. onStop()A
finish掉
9. onPause()B
10. onRestart()A
11. onStart()A
12. onResume()A
13. onStop()B
14. onDestroy()B
  • (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) 从整个生命周期来说,onCreateonDestroy是配对的,分别标识着Activity的创建和销毁,并且只可能有一次调用。从Activity的是否可见来说,onStartonStop是配对的,随着用户的操作或者设备屏幕的点亮和熄灭,这两个方法可能会被调用多次;从Activity是否在前台来说,onResumeonPause是配对的,随着用户操作或者设备屏幕的点亮和熄灭,这两个方法可能会被调用多次。

这里提出两个问题

    1. onStartonResumeonPauseonStop从描述上来看差不多,对我们来说有什么实质性的不同呢?

这两个配对的回调分别表示不同的意义,onStartonStop是从Activity是否可见这个角度来回调的,而onResumeonPause是从Activity是否位于前台这个角度来回调的,除了这种区别,在实际使用中没有其他明显区别。

    1. 假设当前ActivityA,如果这时用户打开一个新ActivityB,那么BonResumeAonPause哪个先执行呢?
1.1 Activity的生命周期_第2张图片
image

当新启动一个Activity的时候,旧ActivityonPause会先执行,然后才会启动新的ActivityAndroid官方文档对onPause的解释有这么一句: 不能在onPause中做重量级的操作,因为必须onPause执行完成以后新Activity才能Resume,从这一点也能间接证明我们的结论。通过分析这个问题,我们知道onPauseonStop都不能执行耗时的操作,尤其是onPause,这也意味着,我们应当尽量在onStop中做操作,从而使得新Activity尽快显示出来并切换到前台。

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

我们知道,Activity除了受用户操作所导致的正常的生命周期方法调度,还有一些异常情况,比如当资源相关的系统配置发生改变以及系统内存不足时,Activity就可能被杀死。

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

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

1.1 Activity的生命周期_第3张图片
image

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

同时,我们要知道,在onSaveInstanceStateonRestoreInstanceState方法中,系统自动为我们做了一定的恢复工作。当Activity在异常情况下需要重新创建时,系统会默认为我们保存当前Activity的视图结构,并且在Activity重启后为我们恢复这些数据,比如文本框中用户输入的数据、ListView滚动的位置等,这些View相关的状态系统都能够默认为我们恢复。具体针对某一个特定的View系统能为我们恢复哪些数据,我们可以查看View的源码。和Activity一样,每个View都有onSaveInstanceStateonRestoreInstanceState这两个方法,看一下它们的具体实现,就能知道系统能够自动为每个VIew恢复哪些数据。

关于保存和恢复View的层次结构,系统的工作流程是这样的:首先Activity被意外终止时,Activity会调用onSaveInstanceState去保存数据,然后Activity会委托Window去保存数据,接着Window再委托它上面的顶级容器去保存数据。顶级容器是一个ViewGroup,一般来说它很可能是DecorView。最后顶层容器再去一一通知它的子元素来保存数据,这样整个数据保存过程就完成了

TextView来说,我们分析一下它到底保存了哪些数据?

@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();
            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();
                }
            }

            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;
    }

TextView保存了自己的文本选中状态和文本内容,并且通过查看其onRestoreInstanceState方法的源码,可以发现它的确恢复了这些数据。

接下来,我们通过旋转屏幕来异常终止Activity的例子来看一下:

@Override
protected void onCreate(Bundle savedInstanceState) {
    super.onCreate(savedInstanceState);
    setContentView(R.layout.activity_main);

    if (savedInstanceState != null) {
        String test = savedInstanceState.getString("extra_test");
        Log.d(TAG,"[onCreate]restore extra_test: " + test);
    }
}

@Override
protected void onSaveInstanceState(Bundle outState) {
    super.onSaveInstanceState(outState);
    Log.d(TAG,"onSaveInstanceState");
    outState.putString("extra_test","test");
}

@Override
protected void onRestoreInstanceState(Bundle savedInstanceState) {
    super.onRestoreInstanceState(savedInstanceState);
    String test = savedInstanceState.getString("extra_test");
    Log.d(TAG,"[onRestoreInstanceState]restore extra_test:" + test);
}

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

04-27 05:48:19.361 19892-19892/com.example.wumeng.chapter1 D/MainActivity: onPause
04-27 05:48:19.363 19892-19892/com.example.wumeng.chapter1 D/MainActivity: onSaveInstanceState
04-27 05:48:19.369 19892-19892/com.example.wumeng.chapter1 D/MainActivity: onStop
04-27 05:48:19.371 19892-19892/com.example.wumeng.chapter1 D/MainActivity: onDestroy
04-27 05:48:19.522 19892-19892/com.example.wumeng.chapter1 D/MainActivity: onStart
04-27 05:48:19.526 19892-19892/com.example.wumeng.chapter1 D/MainActivity: [onRestoreInstanceState]restore extra_test:test
04-27 05:48:19.529 19892-19892/com.example.wumeng.chapter1 D/MainActivity: onResume

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

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

Activity按照优先级从高到低,可以分为以下三种:

  • (1) 前台Activity------正在和用户交互的Activity,优先级最高。
  • (2) 可见但非前台Activity------比如Activity中弹出了一个对话框,导致Activity可见但是位于后台无法和用户直接交互。
  • 后台Activity------已经被暂停的Activity,比如执行了onStop,优先级最低。

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

我们知道,当系统配置发生改变后,Activity会被重新创建。那么有没有办法不重新创建呢?系统配置中有很多内容,如果当某项内容发生改变后,我们不想系统重新创建Activity,可以给Activity指定configChanges属性。比如不想让Activity在屏幕旋转的时候重新创建,就可以给configChanges属性添加orientation这个值。

android:configChanges="orientation"

如果我们想要指定多个值,可以用|连接起来,比如android:configChanges="orientation|keyboardHidden"系统配置中所含的项目是非常多的。

-mcc:The IMSI mobile country code (MCC) has changed — a SIM has been detected and updated the MCC.
IMSI(国际移动用户识别码)发生改变,检测到SIM卡,或者更新MCC。

-mnc:The IMSI mobile network code (MNC) has changed — a SIM has been detected and updated the MNC.
IMSI网络发生改变,检测到SIM卡,或者更新MCC其中mcc和mnc理论上不可能发生变化

  • locale:The locale has changed — the user has selected a new language that text should be displayed in.
    语言发生改变,用户选择了一个新的语言,文字应该重新显示
  • touchscreen:The touchscreen has changed. (This should never normally happen.)
    触摸屏发生改变,这通常是不应该发生的
  • keyboard:The keyboard type has changed — for example, the user has plugged in an external keyboard.
    键盘类型发生改变,例如,用户使用了外部键盘
  • keyboardHidden:The keyboard accessibility has changed — for example, the user has revealed the hardware keyboard.
    键盘的可访问性发生了改变,比如用户调出了键盘
  • navigation:The navigation type (trackball/dpad) has changed. (This should never normally happen.)
    导航发生改变,(这通常不应该发生) 举例:连接蓝牙键盘,连接后确实导致了navigation的类型发生变化。因为连接蓝牙键盘后,我可以使用方向键来navigate了
  • screenLayout:The screen layout has changed — this might be caused by a different display being activated.
    屏幕的布局发生改变,这可能导致激活不同的显示
  • ontScale:The font scaling factor has changed — the user has selected a new global font size.
    全局字体大小缩放发生改变
  • orientation:The screen orientation has changed — that is, the user has rotated the device.设备旋转,横向显示和竖向显示模式切换。
  • screenSize: 屏幕大小改变了
  • smallestScreenSize: 屏幕的物理大小改变了,如:连接到一个外部的屏幕上
  • 4.2增加了一个layoutDirection属性,当改变语言设置后,该属性也会成newConfig中的一个mask位。所以ActivityManagerService(实际在ActivityStack)在决定是否重启Activity的时候总是判断为重启。

需要在android:configChanges中同时添加localelayoutDirection
在不退出应用的情况下切换到Settings里切换语言,发现该Activity还是重启了。

上面表格中的项目很多,但是我们常用的只有localeorientationkeyboardHidden这三个选项,其他很少使用。需要注意的是screenSizesmallestScreenSize,它们两个比较特殊,它们的行为和编译选项有关,但和运行环境无关。

当修改后,Activity的确没有重新创建,并且也没有调用onSaveInstanceStateonRestoreInstanceState来存储和恢复数据,,取而代之的是系统调用了ActivityonConfigurationChanged方法,这个时候我们就可以做一些自己的特殊处理了。

你可能感兴趣的:(1.1 Activity的生命周期)