u011726984

Android学习之管理Activity的生命周期

Activity生命周期

activity第一次启动的时候，它来到系统的前台，开始与用户交互。在此期间，Android系统调用了Activity生命周期中一系列的方法。如果用户执行启动了另一个activity或者切换到另一个app(此时虽然当前activity不可见，但其实例与数据仍然存在)的操作, 系统又会调用生命周期中一系列的方法。

在Activity生命周期的回调方法中，可以声明当用户离开或者重新进入这个Activity所需要执行的操作。

启动Activity

当创建了一个新的activity实例时，系统会像金字塔模型一样去调用一系列的生命周期回调函数，每一个回调函数会向上一阶移动activity状态。处在金字塔顶端意味着当前activity处在前台并处于用户可与其进行交互的状态。

当用户退出这个activity时，为了回收该activity，系统会调用其它方法来向下一阶移动activity状态。在某些情况下，activity会隐藏在金字塔下等待(例如当用户切换到其他app),此时activity可以重新回到顶端(如果用户回到这个activity)并恢复用户离开时的状态。如下图所示：

上图所示的几个生命状态其中只有三个状态是静态的，在这三个状态下activity可以存在一段比较长的时间。(其它几个状态会很快就切换掉，停留的时间比较短暂)

Resumed：该状态下，activity处在前台，用户可以与它进行交互。(通常也被理解为”running” 状态)
Paused：该状态下，activity的部分被另外一个activity所遮盖：另外的activity来到前台，但是半透明的，不会覆盖整个屏幕。被暂停的activity不再接受用户的输入且不再执行任何代码。
Stopped：该状态下, activity完全被隐藏，对用户不可见。可以认为是在后台。当stopped, activity实例与它的所有状态信息（如成员变量等）都会被保留，但activity不能执行任何代码。

其它状态 (Created与Started)都是短暂的，系统快速的执行那些回调函数并通过执行下一阶段的回调函数移动到下一个状态。也就是说，在系统调用onCreate(), 之后会迅速调用onStart(), 之后再迅速执行onResume()。

activity在onStart()被调用后开始被用户可见，但是 onResume()会迅速被执行使得activity停留在Resumed状态，直到一些因素发生变化才会改变这个状态。例如接收到一个来电，用户切换到另外一个activity，或者是设备屏幕关闭。

销毁Activity

activity的第一个生命周期回调函数是 onCreate(),它最后一个回调是onDestroy().当收到需要将该activity彻底移除的信号时，系统会调用这个方法。

当系统Destory我们的activity，它会为activity调用onDestroy()方法。

因为我们会在onStop方法里面做释放资源的操作，那么onDestory方法则是我们最后去清除那些可能导致内存泄漏的地方。
因此需要确保那些线程都被destroyed并且所有的操作都被停止。

Note: 除非程序在onCreate()方法里面就调用了finish()方法，否则系统通常是在执行了onPause()与onStop() 之后再调用onDestroy() 。

暂停与恢复Activity

暂停Activity

在正常使用app时，前端的activity有时会被其他可见的组件阻塞(obstructed)，从而导致当前的activity进入Pause状态。

例如，当打开一个半透明的activity时(例如以对话框的形式)，之前的activity会被暂停。

只要之前的activity仍然被部分可见，这个activity就会一直处于Paused状态。

当一个半透明的activity阻塞当前activity时，系统会调用onPause()方法并且当前这个activity会停留在Paused 状态. 如果用户还在这个activity是Paused 状态时回到这个activity，系统则会调用当前Activity的onResume() 方法。

一旦之前的activity被完全阻塞并不可见时，则其会进入Stop状态。

意味着activity仍然处于部分可见的状态。但更多时候意味着用户正在离开这个activity，并马上会进入Stopped 状态. 通常应该在onPause()回调方法里面做以下事情:

停止动画或者是其他正在运行的操作，这些都会导致CPU的浪费.
提交在用户离开时待保存的内容(例如邮件草稿).
释放系统资源，例如（广播接收器）broadcast receivers, 传感器（sensors） (比如GPS), 或者是其他任何会影响到电量的资源。

例如, 如果程序使用Camera,onPause()会是一个比较好的地方去做那些释放资源的操作。

@Override
public void onPause() {
    super.onPause();  // 总是先调用超类方法

    // 释放Camera资源因为当Activity为paused状态时，不
    // 需要它
    // 并且其它activities可能需要使用它
    if (mCamera != null) {
        mCamera.release()
        mCamera = null;
    }
}

我们应该避免在onPause()方法里执行CPU-intensive 的工作，例如写数据到DB，因为它会导致切换到下一个activity变得缓慢(应该把那些高负荷的工作放到onStop()去做)。

Note:当activity处于暂停状态时，Activity实例是驻留在内存中的，并且在activity恢复的时候重新调用。我们不需要在恢复到Resumed状态的一系列回调方法中重新初始化组件。

恢复Activity

当用户从Paused状态恢复activity时，系统会调用onResume()方法。

Note:系统每次调用这个方法时，activity都处于前台，包括第一次创建的时候。所以，应该实现onResume()来初始化那些在onPause方法里面释放掉的组件，并执行那些activity每次进入Resumed state都需要的初始化动作 (例如开始动画与初始化那些只有在获取用户焦点时才需要的组件)

下面的onResume()的例子是与上面的onPause()例子相对应的。

@Override
public void onResume() {
    super.onResume();  

    if (mCamera == null) {
        // 本地方法处理相机初始化操作
        initializeCamera(); 
    }
}

停止与重启Activity

下面一些关键的场景中会涉及到停止与重启：

用户打开最近使用app的菜单并从我们的app切换到另外一个app，这个时候我们的app是被停止的。如果用户通过手机主界面的启动程序图标或者最近使用程序的窗口回到我们的app，那么我们的activity会重启。
用户在我们的app里面执行启动一个新activity的操作，当前activity会在第二个activity被创建后stop。如果用户点击back按钮，上级activtiy会被重启。
用户在使用我们的app时接收到一个来电通话.

不同于暂停状态的部分阻塞UI，停止状态是UI不再可见并且用户的焦点转移到另一个activity中.

Note: 系统在activity停止时会在内存中保存Activity的实例.
无论什么原因导致activity停止，系统总是会在onStop()之前调用onPause()方法。

停止activity

要点：
当activity调用onStop()方法, activity不再可见，并且应该释放那些不再需要的所有资源。一旦activity停止了，系统会在需要内存空间时摧毁它的实例(和栈结构有关，通常back操作会导致前一个activity被销毁)。极端情况下，系统会直接杀死我们的app进程，并不执行activity的onDestroy()回调方法, 因此我们需要使用onStop()来释放资源，从而避免内存泄漏。

Note: 即使系统会在activity 停止时停止这个activity，它仍然会保存View对象的状态(比如EditText中的文字) 到一个Bundle中，并且在用户返回到这个activity时恢复它们。

启动与重启activity

当activity从Stopped状态回到前台时，它会调用onRestart().系统再调用onStart()方法，onStart()方法在每次activity可见时都会被调用。

onRestart()方法则是只在activity从stopped状态恢复时才会被调用，因此我们可以使用它来执行一些特殊的恢复工作，请注意之前是被stopped而不是destrory。

应该使用onStart()作为onStop()所对应方法。因为系统会在创建activity与从停止状态重启activity时都会调用onStart()。也就是说，我们在onStop里面做了哪些清除的操作，就该在onStart里面重新把那些清除掉的资源重新创建出来。

重新创建Activity

要点：

当Activity是因为用户点击Back按钮或者是activity通过调用finish()结束自己时，系统就丢失了对Activity实例的引用，因为这一行为意味着不再需要这个activity了。

然而，如果因为系统资源紧张而导致Activity的Destory，系统会在用户回到这个Activity时，检测这个Activity保存的记录，系统会使用那些保存的记录数据（描述了当Activity被销毁Destory时的状态）来重新创建一个新的Activity实例。那些被系统用来恢复之前状态而保存的数据被叫做 “instance state” ，它是一些存放在Bundle对象中的key-value对。

小心：你的Activity会在每次旋转屏幕时被销毁与重建。当屏幕改变方向时，系统会销毁与重建前台的activity，因为屏幕配置被改变，你的Activity可能需要加载另一些替代的资源(例如layout).

默认情况下, 系统使用 Bundle 实例来保存每一个View(视图)对象中的信息(例如输入EditText 中的文本内容)。因此，如果Activity被销毁与重建, 则layout的状态信息会自动恢复到之前的状态。然而，activity也许存在更多你想要恢复的状态信息，例如记录用户Progress的成员变量(member variables)。

为了可以保存额外更多的数据到saved instance state，必须重写onSaveInstanceState() 。

当用户离开Activity时，系统会调用它。当系统调用这个函数时，系统会在Activity被异常销毁时传递 Bundle 对象，这样我们就可以增加额外的信息到Bundle中并保存到系统中。

若系统在Activity被销毁之后想重新创建这个Activity实例，之前的Bundle对象会被系统传递到你我们的activity的onRestoreInstanceState()方法与 onCreate() 方法中。

图片说明：

当系统开始停止Activity时，只有在Activity实例会需要重新创建的情况下才会调用到onSaveInstanceState() (1) ，在这个方法里面可以指定额外的状态数据到Bunde中。

如果这个Activity被destroyed然后这个实例又需要被重新创建时，系统会传递在 (1) 中的状态数据到 onCreate() (2) 与 onRestoreInstanceState()(3).

通常来说，跳转到其他的activity或者是点击Home都会导致当前的activity执行onSaveInstanceState，因为这种情况下的activity都是有可能会被destory并且是需要保存状态以便后续恢复使用的，而从跳转的activity点击back回到前一个activity，那么跳转前的activity是执行退栈的操作，所以这种情况下是不会执行onSaveInstanceState的，因为这个activity不可能存在需要重建的操作

保存Activity状态

当我们的activity开始Stop，系统会调用 onSaveInstanceState() ，Activity可以用键值对的集合来保存状态信息。这个方法会默认保存Activity视图的状态信息，如在 EditText 组件中的文本或 ListView 的滑动位置。

为了给Activity保存额外的状态信息，你必须实现onSaveInstanceState() 并增加key-value pairs到 Bundle 对象中，例如：

static final String STATE_SCORE = "playerScore";
static final String STATE_LEVEL = "playerLevel";
...

@Override
public void onSaveInstanceState(Bundle savedInstanceState) {
    // Save the user's current game state
    savedInstanceState.putInt(STATE_SCORE, mCurrentScore);
    savedInstanceState.putInt(STATE_LEVEL, mCurrentLevel);

    // 必须要调用 onSaveInstanceState() 方法的父类实
    //现，这样默认的父类实现才能保存视图状态的信息。
    super.onSaveInstanceState(savedInstanceState);
}

恢复Activity状态

当Activity从Destory中重建，我们可以从系统传递的Activity的Bundle中恢复保存的状态。 onCreate() 与 onRestoreInstanceState() 回调方法都接收到了同样的Bundle，里面包含了同样的实例状态信息。

下面是一个示例：演示在onCreate方法里面恢复一些数据：

@Override
protected void onCreate(Bundle savedInstanceState) {
    super.onCreate(savedInstanceState); // Always call the superclass first

    // 检测是否重建一个上次被销毁的实例
    if (savedInstanceState != null) {
        // Restore value of members from saved state
        mCurrentScore = savedInstanceState.getInt(STATE_SCORE);
        mCurrentLevel = savedInstanceState.getInt(STATE_LEVEL);
    } else {
        // Probably initialize members with default values for a new instance
    }
    ...
}

我们也可以选择实现 onRestoreInstanceState() ，而不是在onCreate方法里面恢复数据。

onRestoreInstanceState()方法会在 onStart() 方法之后执行. 系统仅仅会在存在需要恢复的状态信息时才会调用 onRestoreInstanceState() ，因此不需要检查 Bundle 是否为null。

public void onRestoreInstanceState(Bundle savedInstanceState) {
    // Always call the superclass so it can restore the view hierarchy
    super.onRestoreInstanceState(savedInstanceState);

    // Restore state members from saved instance
    mCurrentScore = savedInstanceState.getInt(STATE_SCORE);
    mCurrentLevel = savedInstanceState.getInt(STATE_LEVEL);
}

注意: 与上面保存一样，总是需要调用onRestoreInstanceState()方法的父类实现，这样默认的父类实现才能保存视图状态的信息。

以上就是基本的activity生命周期。

实践

启动应用Activity LifeCycle

Demo下载：http://download.csdn.net/detail/u011726984/9206627

注：以下测试过程保持连续，未中断。并且Activity A的运行模式为singleTask

可以看到应用Activitya依次调用了onCreate(),onStart(),最终停在Resumed状态。

此时，点击 START B按钮启动另一activityb，如下图：

可以看到activitya处于暂停状态（部分可见）随后即变为停止状态（不可见），activityb处在Resumed状态（可见）。

此时，按返回键，如下图：

可以看到activitya停止后调用onRestart方法最终处在Resumed状态，此时activityb由暂停状态依次转变为停止、销毁状态。

此时，点击 DIALOG 按钮，如下图：

可以看到activitya处于暂停状态（部分可见）。此时，按返回键或Close按钮返回activitya，会调用Resume方法回到Resumed状态。

在此，中断。

依次连续启动activitya、b、c ，如下图：

首先activitya处在Resumed状态，启动b后，a被暂停，当b处于Resumed状态时，a被停止，处于Stopped状态。之后启动c，b被暂停,当c处于Resumed状态时，b被停止，最后a、b处于Stopped状态，而c处于Resumed状态。