Activity的生命周期和启动模式--Activity的生命周期的全面分析

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

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

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

  • onCreate:表示Activity正在被创建,这是生命周期的第一个方法。在这个方法中,我们可以做一些初始化工作,比如调用setContentView去加载界面布局资源、初始化Activity所需数据等。
  • onRestart:表示Activity正在重新启动。一般情况下,当当前Activity从不可见重新变为可见状态时,onRestart就会被调用。这种情形一般时用户行为所导致的,比如用户按Home键切换到桌面或者用户打开了一个新的Activity,这时当前的Activity就会暂停,也就是onPause和onStop被执行了,接着用户又回到了这个Activity,就会出现这种情况。

  • onStart:表示Activity正在被启动,即将开始,这时Activity已经可见了,但是还是没有出现在前台,还无法和用户交互。这个时候其实可以理解为Activity已经显示出来了,但是我们还看不到。
  • onResume:表示Activity已经可见了,并且出现在前台并开始活动。要注意这个和onStart的对比,onStart和onResume都表示Activity已经可见,但是onStart的时候Activity还在后台,onResume的时候Activity才显示到前台。

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

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

正常情况下,Activity的常用生命周期就只有上面7个,下图更加详细地描述了Activity各种生命周期的切换过程。
Activity的生命周期和启动模式--Activity的生命周期的全面分析_第1张图片

针对上图,这里再附加一下说明,分如下几种情况。
  • 针对一个特定的Activity,第一次启动,回调如下:onCreate-->onStart-->onResume.

  • 当用户打开新的Activity或者切换到桌面的时候,回调如下:onPause-->onStop。这里又一种特殊情况,如果新Activity采用了透明主题,那么当前Activity不会回调onStop.
  • 当用户再次回到原Activity时,回调如下:onRestart-->onStart-->onResume。

  • 当用户按back键回退时,回调如下:onPause-->onStop-->onDestory。
  • 当Activity被系统回收后再次打开,生命周期方法回调过程和(1)一样,注意只是生命周期方法一样,不代表所有过程都一样,这个问题在下一节会详细说明。

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

有两个问题,不知道大家是否清楚。

问题1:onStart和onResume、onPause和onStop从描述上来看差不多,对我们来说有什么实质的不同呢?

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

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

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

        // We need to start pausing the current activity so the top one
        // can be resumed...
        boolean pausing = mStackSupervisor.pauseBackStacks(userLeaving);
        if (mResumedActivity != null) {
            pausing = true;
            startPausingLocked(userLeaving, false);
            if (DEBUG_STATES) Slog.d(TAG, "resumeTopActivityLocked: Pausing " + mResumedActivity);
        }
从上述代码可以看出,在新Activity启动之前,栈顶的Activity需要先onPause后,新Activity才能启动。最终,在ActivityStackSupervisor中的realStartActivityLocked方法会调用如下代码。

app.thread.scheduleLaunchActivity(new Intent(r.intent), r.appToken,
                    System.identityHashCode(r), r.info,
                    new Configuration(mService.mConfiguration), r.compat,
                    app.repProcState, r.icicle, results, newIntents, !andResume,
                    mService.isNextTransitionForward(), profileFile, profileFd,
                    profileAutoStop);

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

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

        if (r.profileFd != null) {
            mProfiler.setProfiler(r.profileFile, r.profileFd);
            mProfiler.startProfiling();
            mProfiler.autoStopProfiler = r.autoStopProfiler;
        }

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

        if (localLOGV) Slog.v(
            TAG, "Handling launch of " + r);
            
        //这里新Activity被创建出来,其onCreate和onStart会被调用
        Activity a = performLaunchActivity(r, customIntent);

        if (a != null) {
            r.createdConfig = new Configuration(mConfiguration);
            Bundle oldState = r.state;
            //这里新Activity的onResume会被调用
            handleResumeActivity(r.token, false, r.isForward,
                    !r.activity.mFinished && !r.startsNotResumed);

        //省略...
    }
从上面的分析可以看出,当新启动一个Activity的时候,旧Activity的onPause会先执行,然后才会启动新的Activity。到底是不是这样呢?我们写一个例子验证下,如下是2个Activity的代码,在MainActivity中点击按钮旧可以跳转到SecondActivity,同时为了分析我们的问题,在生命周期方法中打印出了日志,通过日志我们就能看出他们的调用顺序。
public class MainActivity extends AppCompatActivity {
    private static final String TAG = "MainActivity";

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

    @Override
    protected void onPause() {
        super.onPause();
        Log.e(TAG, "onPause");
    }

    @Override
    protected void onStop() {
        super.onStop();
        Log.e(TAG, "onStop");
    }

    public void btnStartSecondActivity(View view) {
        Intent intent = new Intent(this, SecondActivity.class);
        startActivity(intent);
    }
}
public class SecondActivity extends AppCompatActivity {

    private static final String TAG = "SecondActivity";
    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_second);
        Log.e(TAG, "onCreate");
    }

    @Override
    protected void onStart() {
        super.onStart();
        Log.e(TAG, "onStart");
    }

    @Override
    protected void onResume() {
        super.onResume();
        Log.e(TAG, "onResume");
    }
}

我们来看一下log,是不是和我们上面的分析一样,如下所示。
Activity的生命周期和启动模式--Activity的生命周期的全面分析_第2张图片

通过Log可以发现,旧Activity的onPause先调用,然后新Activity才启动 ,这也证实了我们上面的分析过程。也许有人会问,你只是分析了Android5.0的源码,你怎么知道所有版本的源码都是相同的逻辑呢?关于这个问题,我们的确不大可能把所有版本的源码都分析一边,但是作为Android运行过程中的基本机制,随着版本的更新并不会有大的跳转,因为Android系统也需要兼容性,不能说在不同的版本上同一个运行机制有着截然不同的表现。关于这一点我们需要把握一个度,就是对于Android运行的基本机制在不同Android版本上具有延续性。从另一个角度来说,Android官方文档对onPause的解释有这么一句:不能在onPause中做重量级的操作,因为必须onPause完成后,新的Activity才能Resume,从这一点也能间接的证明我们的结论。通过分析这个问题,我们知道onPause和onStop都不能执行耗时的操作,尤其是onPause,这也意味着,我们应当尽量在onStop中操作,从而使得新Activity尽快显示出来,并切换到前台。

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

上一节我们分析了典型情况下Activity的生命周期,本节我们接着分析Activity在异常情况下的生命周期。我们知道,Activity除了受用户操作所导致的正常的生命周期方法调度,还有一些异常情况,比如当系统资源相关的系统配置发生改变以及系统内存不足时,Activity就可能被杀死。下面我们具体分析这两种情况。

1.情况1:资源相关的系统配置发生改变导致Activity被杀死并重新创建
理解这个问题,我们首先要对系统的资源加载机制有一定了解,这里不详细分析系统的资源加载机制,只是简单说明一下。拿最简单的图片来说,当我们把一张图片放在drawable目录后,就可以通过Resources去获取这张图片。同时为了兼容不同的设备,我们可能还需要在其他一些目录放置不同的图片,比如drawable-mdpi、drawable-hdpi、drawable-land灯。这样,当应用程序启动时,系统就会根据当前设备的情况去加载合适的Resources资源,比如横屏手机和竖屏手机会拿到不同的图片(设定了landspace或者portait状态下的图片)。比如说当前Activity处于竖屏状态,如果屏幕突然旋转,由于系统配置发生了改变,在默认情况下,Activity就会被销毁并且重新创建,当然我们也可以组织系统重新创建我们的Activity。
在默认情况下,如果我们的Activity不做特殊处理,那么当系统配置发生改变后,Activity就会被销毁并重新创建,其生命周期如图所示。

Activity的生命周期和启动模式--Activity的生命周期的全面分析_第3张图片
当系统配置发生改变后,Activity会被销毁,其onPause、onStop、onDestory均会被调用,同时由于Activity是在异常情况下终止的,系统会调用onSaveInstanceState来保存当前Activity的状态,这个方法的调用时机是在onStop之前,他和onPause没有既定的时序关系,它极可能在onPause之前被调用,也可能在onPause之后调用。需要强调的一点是,这个方法只会出现在Activity被异常种植的情况下,正常情况下系统不会回调这个方法。当Activity被重新创建后,系统会调用onRestoreInstanceState,并且把Activity销毁时onSaveInstanceState方法所保存的Bundle对象作为参数同时传递给onRestoreInstanceState和onCreate方法。因此,我们可以通过onRestoreInstanceState和onCreate方法来判断Activity是否被重建了,如果被重建了,那么我们就可以取出之前保存的数据并恢复,从时许上来说onRestoreInstanceState的调用时机在onStart之后。

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

关于保存和恢复View层次结构,系统的工作流程时这样的:首先Activity被意外终止时,Activity会调用onSaveInstanceState去保存数据,然后Activity会委托Window去保存数据,接着Window再委托它上面的顶级容器去保存数据。顶层容器是一个ViewGroup,一般来说它很可能是DecorView。最后顶层容器再去一一通知它的子元素来保存数据,这样整个数据保存过程就完成了。可以发现,这是一种典型的委托思想,上层委托下层、父容器委托子容器去处理一件事情,这种思想再Android中又很多应用,比如View的绘制过程、时间分发等都是采用类似的思想。至于数据恢复过程也是类似,这里就不再重复介绍了。接下来举个例子,拿ProgressBar来说,我们分析一下它到底保存了哪些数据。(PS-我用的是Android-19的源码)

    @Override
    public Parcelable onSaveInstanceState() {
        // Force our ancestor class to save its state
        Parcelable superState = super.onSaveInstanceState();
        SavedState ss = new SavedState(superState);
        
        ss.progress = mProgress;
        ss.secondaryProgress = mSecondaryProgress;
        
        return ss;
    }

从上述源码可以很容易看出,ProgressBar保存了自己的progress和secondaryProgress,并且通过查看onRestoreInstanceState方法的源码,可以发现它的确恢复了这些数据,具体源码就不再贴出了,读者可以去看看源码。下面我们来看看实际的例子,对比一下Activity正常终止和异常终止的不同,同时验证系统的数据恢复能力。为了方便,我们选择旋转屏幕来异常终止Activity,如图所示。
Activity的生命周期和启动模式--Activity的生命周期的全面分析_第4张图片 Activity的生命周期和启动模式--Activity的生命周期的全面分析_第5张图片 Activity的生命周期和启动模式--Activity的生命周期的全面分析_第6张图片

通过上图,我们选择屏幕以后,Activity被销毁后重新创建,我们设置的Progress会被正确的还原,这说明系统的确能够自动地做一些View层次结构方面地数据存储和恢复。下面再用一个例子,来证明我们自己做数据存储和恢复的情况,代码如下:

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

        if (savedInstanceState != null) {
            //被异常重启Activity
            String test = savedInstanceState.getString(EXTRA_TEST);
            Log.e(TAG, "[onCreate] restore extra_test:" + test);
        }
    }
    
    @Override
    protected void onSaveInstanceState(Bundle outState) {
        super.onSaveInstanceState(outState);

        Log.e(TAG, "onSaveInstanceState");
        outState.putString(EXTRA_TEST, "test");
    }

    @Override
    protected void onRestoreInstanceState(Bundle savedInstanceState) {
        super.onRestoreInstanceState(savedInstanceState);

        String test = savedInstanceState.getString(EXTRA_TEST);
        Log.e(TAG, "[onRestoreInstanceState] restore extra_test:" + test);
    }

上面的代码很简单,首先我们再onSaveInstanceState中存储一个字符串,然后当Activity被销毁并重新创建后,我们再去获取之前存储的字符串。接受的位置可以选择onCreate或onRestoreInstanceState,二者的区别是onRestoreInstanceState一旦被调用,其参数Bundle savedInstanceState一定是有值的,我们不用额外判断是否为空;但是onCreate不行,onCreate正常启动的话,其参数Bundle savedInstanceState为null,所以必须要额外判断。这两个方法我们选择任意一个都可以进行数据恢复,但是官方文档建议采用onRestoreInstanceState去恢复数据。下面我们看一下运行的日志,如下图所示。

如图所示,Activity被销毁了以后调用了onSaveInstanceState来保存数据,重新创建以后再onCreate和onRestoreInstanceState中都能够正确地恢复我们之前存储的字符串。这个例子很好地证明了上面我们分析地结论。针对onSaveInstanceState方法还有一点需要说明,那就是系统只会再Activity即将被销毁并且有机会重新显示地情况下才会去调用它。考虑这么一种情况,当Activity正常销毁的时候,系统不会调用onSaveInstanceState,因为被销毁的Activity不可能再次被显示。这句话不好理解,但是我们可以对比一下屏幕旋转所造成的Activity被销毁的同时会立刻创建新的Activity实例,这个时候Activity有机会再次立刻展示,所以系统要进行数据存储,这里可以简单地这么理解,系统只再Activity异常终止地时候才会调用onSaveInstanceState和onRestoreInstanceState来存储和恢复数据,其他情况不会触发这个过程。

2.情况2:资源内存不足导致低优先级地Activity被杀死
这种情况我们不好模拟,但是其数据存储和恢复过程和情况1完全一致。这里我们描述一下Activity的优先级情况。Activity按照优先级从高到低,可以分为如下三种情况:

  • 前台Activity——正在和用户交互的Activity,优先级最高。
  • 可见前台但非前台Activity——比如Activity弹出了一个对话框,导致Activity可见,但是位于后台无法和用户直接交互。

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

上面分析了系统地数据存储和恢复机制,我们知道,当系统配置发生改变后,Activity会被重新创建,那么有没有办法不重新创建呢?答案时有的,接下来我们就来分析这个问题。系统配置中有很多内容,如果当某项内容发生改变后,我们不想系统重新创建Activity,可以给Activity知道configChanges属性。比如不想让Activity在屏幕旋转的时候重新创建,就可以给configChanges属性添加orientation这个值,如下所示。

android:configChanges="orientation"
如果我们想指定多个值,可以用“|”连接起来,比如android:configChanges="orientation|keyboardHidden"。系统配置中所含的项目是非常多的,下面介绍每个项目的含义。如下表所示。
congifChanges的项目和含义
项目 含义
mcc SIM卡唯一标识符IMSI(国际移动用户识别码)中的国家代码,由三位数字组成,中国为460。此项标识mcc代码发生了改变。
mnc SIM卡唯一标识符IMSI(国际移动用户识别码)中的运营商代码,由两位数字组成,中国移动TD系统为00,中国联通为01,中国电信为03,此标识mnc发生改变
locale 设备的本地位置发生了改变,一般指切换了语言系统
touchscreen 触摸屏发生了改变,这个很费解,正常情况下无法发生,可以忽略它    
keyboard 键盘类型发生了改变,比如用户使用了外插键盘
keyboardHidden 键盘的可访问性发生了改变,比如用户调出了键盘
navigation 系统导航方式发生了改变,比如采用了轨迹球导航,这个有点非接,很难发生,可以忽略它
screenLayout 屏幕布局发生了改变,很可能是用户激活了另外一个显示设备
fontScale 系统字体缩放比例发生了改变,比如用户选择了一个新字号
uiMode 用户界面模式发生了改变,比如是否开启了夜间模式(API8新添加)
orientation 屏幕方向发生了改变,这个是最常用了,比如旋转了手机屏幕
screenSize 当屏幕尺寸信息发生了改变,当旋转设备屏幕时,屏幕尺寸会发生变化,这个选项比较特殊,它和编译选项有关,当编译选项中minSdkVersion和targetSdkVersion均低于13时,此选项不会导致Activity重启,否则会导致Activity重启(API13添加)
smallestScreenSize 设备的物理屏幕尺寸发生改变,这个项目和屏幕方向没有关系,仅仅表示在实际物理屏幕的尺寸改变的时候发生,比如用户切换到了外部的显示设备,这个选项和screenSize一样,当编译选项中的minSdkVersion和targetSdkVersion均低于13时,此选项不会导致Activity重启,否则会导致Activity重启(API13添加)
layoutDirection 当布局方向发生变化,这个属性用的比较少,正常情况下无法修改布局的layoutDirection

从上边可以知道,如果我们没有在Activity的configChanges属性中指定该选项的话,当配置发生改变后就会导致Activity重新创建。表格中的项目很多,但是我们常用的只有locale、orientation和keyboardHidden这三个选项,其他很少使用。需要注意的是screenSize和smallestScreenSize,他们两个比较特殊,他们的行为和编译选项有关,但和运行环境无关。下面我们再看一个demo,看看当我们指定了configChanges属性后,Activity是否真的不会重新创建了。我们所要修改的代码很简单,只需要再AndroidMenifest.xml中加入Activity的声明即可,代码如下:



            
                

                
            
        

    @Override
    public void onConfigurationChanged(Configuration newConfig) {
        super.onConfigurationChanged(newConfig);
        Log.e(TAG, "[onConfigurationChanged] newOrientation:" + newConfig.orientation);
    }

需要说明的是,由于编译时笔者指定的minSdkVersion和targetSdkVersion有一个大于13,所以为了放置屏幕旋转时Activity重启,除了orientation,我们还加上了screenSize,原因在上面的表格已经说明了。其他的代码还是不变,运行后看看log,如下图所示。

由上面的日志可见,Activity的确没有重新创建,并且也没有调用onSaveInstanceState和onRestoreInstanceState来存储和恢复数据,取而代之的时系统调用了Activity的onConfigurationChanged方法,这个时候我们就可以做一些自己的处理了。

你可能感兴趣的:(Android开发艺术探索笔记)