android 生命周期研究资料

引言

应用程序组件有一个生命周期——一开始Android实例化他们响应意图，直到结束实例被销毁。在这期间，他们有时候处于激活状态，有时候处于非激活状态；对于活动，对用户有时候可见，有时候不可见。组件生命周期将讨论活动、服务、广播接收者的生命周期——包括在生命周期中他们可能的状态、通知状态改变的方法、及这些状态的组件寄宿的进程被终结和实例被销毁的可能性。

本文主要讨论活动的生命周期及他们可能的状态、通知状态改变的方法。分为以下三部分：

• 1、活动生命周期
• 2、保存活动状态
• 3、协调活动

1、活动生命周期

一个活动有三个基本状态：

• 激活状态或运行状态，这时它运行在屏幕的前台（处于当前任务活动栈的最上面）。这个活动有用户的操作的焦点。
• 暂停状态，这时活动失去焦点但是它对用户仍可见。也就是说，另一个活动在它的上面且那个活动是透明的或者没有覆盖整个屏幕，因此通过它可以看见暂停状态的活动。一个暂停的活动完全是活着的（它维护着所有的状态和成员信息，且仍然依附在窗口管理器），但是当内存极小时可以被系统杀掉。
• 停止状态，这时活动完全被其他活动掩盖。它仍然保留所有状态和成员信息，但是对用户它不可见，因此它的窗口时隐藏的且当其他地方需要内存时它往往被系统杀掉。

如果一个活动被暂停或停止，系统可以将它从内存移除，通过要求它结束（通过调用它的finish()方法），或简单地杀掉它的进程。当它再次显示给用户时，必须要完全重新启动和恢复到之前的状态。随着活动从一个状态转为另一个状态，通过调用下面的受保护的方法通知该改变：

• void onCreate(Bundle saveInstanceState)
• void onStart()
• void onRestart()
• void onResume()
• void onPause()
• void onStop()
• void onDestroy()

所有这些方法都是钩子，你可以重写当状态改变时做适当的工作。所有的活动必须要实现onCreate()去做一些初始化的设置，当对象第一次实例化的时候。很多活动也会实现onPause()去提交数据修改或准备停止与用户交互。

将他们合并在一起，这七个方法定义了活动的整个生命周期。有三个嵌套的循环，你可以通过这七个方法监视：

• 活动的整个生命时间，从第一次调用onCreate()开始直到调用onDestroy()结束。一个活动在onCreate()中做所有的“全局”状态的初始设置，在onDestroy()中释放所有保留的资源。举例来说，有一个线程运行在后台从网络上下载数据，它可能会在onCreate()中创建线程，在onDestroy()中结束线程。
• 活动的可视生命时间，从调用onStart()到相应的调用onStop() 。在这期间，用户可以在屏幕上看见活动，虽然它可能不是运行在前台且与用户交互。在这两个方法之间，你可以保持显示活动所需要的资源。举例来说，你可以在onStart()中注册一个广播接收者监视影响你的UI的改变，在onStop() 中注销。因为活动在可视和隐藏之间来回切换，onStart()和onStop()  可以调用多次。
• 活动的前台生命时间，从调用onResume()到相应的调用onPause()。在这期间，频繁地在重用和暂停状态转换——例如，当设备进入睡眠状态或一个新的活动启动时调用onPause()，当一个活动返回或一个新的意图被传输时调用onResume()。因此，这两个方法的代码应当是相当轻量级的。

下面这个图解释了这三个循环和状态之间状态的可能路径。着色的椭圆表示活动的主要状态，矩形表示当活动在状态之间转换时你可以执行的回调方法。

 

 

 

 

 

 

 

 

图1、活动生命周期（来源：Android SDK）

下面的表格对每个方法更详细的描述和在活动的整个生命周期中的定位。

注意上面表格的Killable列，它表示当方法返回时没有执行活动的其它代码，系统是否能杀死活动寄宿的进程。三个方法（onPause()、onStop()、onDestroy()）标记为Yes。因为onPause()是唯一一个保证在进程被杀之前会调用的，因此你应该使用onPause()来写任何持久化存储数据。

被标记为No的方法保护活动寄宿的进程在他们调用的时候不会被杀掉。因此活动是可杀掉状态，例如onPause()返回到onResume()调用期间。直到onPause()再次返回，活动是不可杀掉的。其实，没有标记为Killable的活动也是可以系统被杀掉的，不过这仅仅发生在极端困难的情况下，没有有任何其他资源可用。

2、保存活动状态

当系统而不是用户关闭一个活动来节省内存时，用户可能希望返回到活动且是它之前的状态。为了获得活动被杀之前的状态，你可以执行活动的onSaveInstanceState()方法。Android在活动容易被销毁前调用这个方法，也就是调用onPause()之前。该方法的参数是一个Bundle对象，在这个对象你可以以名值对记录活动的动态状态。当活动再次启动时，Bundle同时被传递到onCreate()和调用onCreate()之后的方法，onRestoreInstanceState()，因此使用一个或两个可以重新创建捕获的状态。

因为onSaveInstanceState()方法不总是被调用，你应该仅使用onSaveInstanceState()它来记录活动的临时状态，而不是持久的数据。应该使用onPause()来存储持久数据。

3、协调活动

当一个活动启动另一个活动，他们都经历生命周期转换。一个暂停或许是停止，然而另一个启动。有时，你可能需要协调这些活动。生命周期的回调顺序是明确界定的，特别是当这两个活动在同一个进程中：

1. 当前活动的onPause()方法被调用。
2. 接下来，启动活动的onCreate()、onStart()、onResume()方法按序被调用。
3. 然后，如果获得不再在屏幕上可见，它的onStop()方法被调用。

修正：第一节——活动生命周期中的表格第一、二行中的第二列（description）中的onRestart()应该为onStart()。
1000多的点击，居然没有人发现这个错误，看了大家根本就没认真看或者说根本没有静心看园子里的任何博文，心痛！还是水帖比较受欢迎。

 

 

 

作者：吴秦
出处：http://www.cnblogs.com/skynet/

 

 

=========================================================================

 

对手机有所研究的朋友们，应该对于Android这一手机操作系统并不陌生。它是一款基于Linux平台的开源手机操作系统。我们在这里会通过对Android Activity生命周期的介绍来充分的了解一下这一系统的基本原理。

注意到在Activity的API中有大量的onXXXX形式的函数定义，除了我们前面用到的onCreate以外，还有onStart，onStop以及onPause等等。从字面上看，它们是一些事件回调，那么次序又是如何的呢？其实这种事情，自己做个实验最明白不过了。在做这个实验之前，我们先得找到在Android中的Log是如何输出的。

显然，我们要用的是android.util.log类，这个类相当的简单易用，因为它提供的全是一些静态方法：

 Log.v(String tag, String msg); //VERBOSE
 Log.d(String tag, String msg); //DEBUG
 Log.i(String tag, String msg); //INFO
 Log.w(String tag, String msg); //WARN
 Log.e(String tag, String msg); //ERROR

前面的tag是由我们定义的一个标识，一般可以用“类名_方法名“来定义。

输出的LOG信息，如果用Eclipse+ADT开发，在LogCat中就可以看到，否则用adb logcat也行，不过我是从来都依赖于IDE环境的。

好了，现在我们修改前面的HelloThree代码：

 public void onStart()
 ...{
 super.onStart();
 Log.v(TAG,"onStart");
 }
 public void onStop()
 ...{
 super.onStop();
 Log.v(TAG,"onStop");
 }
 public void onResume()
 ...{
 super.onResume();
 Log.v(TAG,"onResume");
 }
 public void onRestart()
 ...{
 super.onRestart();
 Log.v(TAG,"onReStart");
 }
 public void onPause()
 ...{
 super.onPause();
 Log.v(TAG,"onPause");
 }
 public void onDestroy()
 ...{
 super.onDestroy();
 Log.v(TAG,"onDestroy");
 }
 public void onFreeze(Bundle outState)
 ...{
 super.onFreeze(outState);
 Log.v(TAG,"onFreeze");
 }

在HelloThreeB中也同样增加这样的代码，编译，运行一下，从logcat中分析输出的日志。

在启动第一个界面Activity One时，它的次序是：

onCreate (ONE) - onStart (ONE) - onResume(ONE)

虽然是第一次启动，也要走一遍这个resume事件。然后，我们点goto跳到第二个Activity Two中（前一个没有关闭），这时走的次序是：

onFreeze(ONE) - onPause(ONE) - onCreate(TWO) -  onStart(TWO) - onResume(TWO) - onStop(ONE)

说明，第二个Activity Two在启动前，One会经历一个：冻结、暂停的过程，在启动Two后，One才会被停止？

然后，我们再点back回到第一个界面，这时走的次序是：

onPause(TWO) - onActivityResult(ONE) - onStart(ONE) -  onRestart(ONE) - onResume(ONE) - onStop(TWO) - onDestroy(TWO)

说明，返回时，Two没有经历冻结就直接暂停了，在One接收参数，重启后，Two就停止并被销毁了。最后，我们点一下Exit退出应用，它的次序是：

onPause(ONE) - onStop(ONE) - onDestroy(ONE)

说明如果我们用了finish的话，不会有freeze，但是仍会经历pause - stop才被销毁。

这里有点疑问的是：为什么回来时先是Start才是Restart？可是文档中的图上画的却是先restart再start的啊？不过，后面的表格中的描述好象是正确的，start后面总是跟着resume（如果是第一次）或者restart（如果原来被stop掉了，这种情况会在start与resume 中插一个restart）。

 

下面不跑例子了，看看Android Activity生命周期的文档吧。

1.Android用Activity Stack来管理多个Activity，所以呢，同一时刻只会有最顶上的那个Activity是处于active或者running状态。其它的Activity都被压在下面了。

2. 如果非活动的Activity仍是可见的（即如果上面压着的是一个非全屏的Activity或透明的Activity），它是处于paused状态的。在系统内存不足的情况下，paused状态的Activity是有可被系统杀掉的。只是不明白，如果它被干掉了，界面上的显示又会变成什么模样？看来下回有必要研究一下这种情况了。

3.几个事件的配对可以比较清楚地理解它们的关系。Create与Destroy配成一对，叫entrie lifetime，在创建时分配资源，则在销毁时释放资源；往上一点还有Start与Stop一对，叫visible lifetime，表达的是可见与非可见这么一个过程；最顶上的就是Resume和Pause这一对了，叫foreground lifetime，表达的了是否处于激活状态的过程。

4.因此，我们实现的Activity派生类，要重载两个重要的方法：onCreate()进行初始化操作，onPause()保存当前操作的结果。

除了Activity Lifecycle以外，Android还有一个Process Lifecycle的说明：

在内存不足的时候，Android是会主动清理门户的，那它又是如何判断哪个process是可以清掉的呢？文档中也提到了它的重要性排序：

1. 最容易被清掉的是empty process，空进程是指那些没有Activity与之绑定，也没有任何应用程序组件（如Services或者IntentReceiver）与之绑定的进程，也就是说在这个process中没有任何activity或者service之类的东西，它们仅仅是作为一个cache，在启动新的 Activity时可以提高速度。它们是会被优先清掉的。因此建议，我们的后台操作，最好是作成Service的形式，也就是说应该在Activity中启动一个Service去执行这些操作。

2.接下来就是background activity了，也就是被stop掉了那些activity所处的process，那些不可见的Activity被清掉的确是安全的，系统维持着一个 LRU列表，多个处于background的activity都在这里面，系统可以根据LRU列表判断哪些activity是可以被清掉的，以及其中哪一个应该是最先被清掉。不过，文档中提到在这个已被清掉的Activity又被重新创建的时候，它的onCreate会被调用，参数就是onFreeze时的那个Bundle。不过这里有一点不明白的是，难道这个Activity被killed时，Android会帮它保留着这个Bundle吗？

3.然后就轮到service process了，这是一个与Service绑定的进程，由startService方法启动。虽然它们不为用户所见，但一般是在处理一些长时间的操作（例如MP3的播放），系统会保护它，除非真的没有内存可用了。

4.接着又轮到那些visible activity了，或者说visible process。前面也谈到这个情况，被Paused的Activity也是有可能会被系统清掉，不过相对来说，它已经是处于一个比较安全的位置了。

5.最安全应该就是那个foreground activity了，不到迫不得已它是不会被清掉的。这种process不仅包括resume之后的activity，也包括那些onReceiveIntent之后的IntentReceiver实例。

在Android Activity生命周期的讨论中，文档也提到了一些需要注意的事项：因为Android应用程序的生存期并不是由应用本身直接控制的，而是由 Android系统平台进行管理的，所以，对于我们开发者而言，需要了解不同的组件Activity、Service和IntentReceiver的生命，切记的是：如果组件的选择不当，很有可能系统会杀掉一个正在进行重要工作的进程。