Android 应用程序的生命周期

Android 应用程序的生命周期Android 是一构建在Linux 之上的开源移动开发平台，在Android 中，多数情况下每个程序都是在各自独立的Linux 进程中运行的。

当一个程序或其某些部分被请求时，它的进程就“出生”了；当这个程序没有必要再运行下去且系统需要回收这个进程的内存用于其他程序时，这个进程就“死亡”了。

可以看出，Android 程序的生命周期是由系统控制而非程序自身直接控制。

这和我们编写桌面应用程序时的思维有一些不同，一个桌面应用程序的进程也是在其他进程或用户请求时被创建，但是往往是在程序自身收到关闭请求后执行一个特定的动作（比如从main 函数中return）而导致进程结束的。

要想做好某种类型的程序或者某种平台下的程序的开发，最关键的就是要弄清楚这种类型的程序或整个平台下的程序的一般工作模式并熟记在心。

在Android中，程序的生命周期控制就是属于这个范畴——我的个人理解:)在Android 系统中，当某个activity（应用程序的一个“帧”）调用startActivity(myIntent) 时，系统会在所有已经安装的程序中寻找其intent filter和myIntent 最匹配的一个activity，启动这个进程，并把这个intent通知给这个activity。

这就是一个程序的“生”。

比如我们在Home application 中选择“Web browser”，系统会根据这个intent 找到并启动Web browser 程序，显示Web browser 的一个activity 供我们浏览网页（这个启动过程有点类似我们在在个人电脑上双击桌面上的一个图标启动某个应用程序）。

在Android 中，所有的应用程序“生来就是平等的”，所以不光Android 的核心程序甚至第三方程序也可以发出一个intent 来启动另外一个程序中的一个activity。

Android 的这种设计非常有利于“程序部件”的重用。

一个Android 程序的进程是何时被系统结束的呢？通俗地说，一个即将被系统关闭的程序是系统在内存不足（low memory）时，根据“重要性层次”选出来的“牺牲品”。

一个进程的重要性是根据其中运行的部件和部件的状态决定的。

各种进程按照重要性从高到低排列如下：1. 前台进程。

这样的进程拥有一个在屏幕上显示并和用户交互的activity 或者它的一个IntentReciver 正在运行。

这样的程序重要性最高，只有在系统内存非常低，万不得已时才会被结束。

2. 可见进程。

在屏幕上显示，但是不在前台的程序。

比如一个前台进程以对话框的形式显示在该进程前面。

这样的进程也很重要，它们只有在系统没有足够内存运行所有前台进程时，才会被结束。

3. 服务进程。

这样的进程在后台持续运行，比如后台音乐播放、后台数据上传下载等。

这样的进程对用户来说一般很有用，所以只有当系统没有足够内存来维持所有的前台和可见进程时，才会被结束。

4. 后台进程。

这样的程序拥有一个用户不可见的activity。

这样的程序在系统内存不足时，按照LRU 的顺序被结束。

5. 空进程。

这样的进程不包含任何活动的程序部件。

系统可能随时关闭这类进程。

从某种意义上讲，垃圾收集机制把程序员从“内存管理噩梦”中解放出来，而Android 的进程生命周期管理机制把用户从“任务管理噩梦”中解放出来。

我见过一些Nokia S60 用户和Windows Mobile 用户要么因为长期不关闭多余的应用程序而导致系统变慢，要么因为不时查看应用程序列表而影响使用体验。

Android 使用Java 作为应用程序API，并且结合其独特的生命周期管理机制同时为开发者和使用者提供最大程度的便利。

关于Android 的程序生命周期管理，这里有个非常生动形象的演示。

注意到在Activity的API中有大量的onXXXX形式的函数定义，除了我们前面用到的onCreate以外，还有onStart，onStop以及onPause等等。

从字面上看，它们是一些事件回调，那么次序又是如何的呢？其实这种事情，自己做个实验最明白不过了。

在做这个实验之前，我们先得找到在Android中的Log是如何输出的。

显然，我们要用的是android.util.log类，这个类相当的简单易用，因为它提供的全是一些静态方法：Log.v(String tag, String msg); //VERBOSELog.d(String tag, String msg); //DEBUGLog.i(String tag, String msg); //INFOLog.w(String tag, String msg); //WARNLog.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）。

下面不跑例子了，看看文档吧。

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是可以被清掉的，以及其中哪一个应该是最先被清掉。