. . . }
总得来说，这七个方法定义了一个activity完整的生命周期。实现这些方法可以帮助你监察三个嵌套的生命周期循环：
? 一个activity 完整的生命周期 自第一次调用 onCreate()开始，直至调用onDestroy()为止。activity在onCreate()中设置所有“全局”状态以完成初始化，而在onDestroy()中释放所有系统资源。比如说，如果activity有一个线程在后台运行以从网络上下载数据，它会以
onCreate()创建那个线程，而以 onDestroy()销毁那个线程。
? 一个activity的 可视生命周期自 onStart() 调用开始直到相应的 onStop()调用。在此期
间，用户可以在屏幕上看到此activity，尽管它也许并不是位于前台或者正在与用户做交互。在这两个方法中，你可以管控用来向用户显示这个activity的资源。比如说，你可以在onStart() 中注册一个BroadcastReceiver 来监控会影响到你UI的改变，而在onStop() 中来取消注册，这时用户是无法看到你的程序显示的内容的。onStart() 和 onStop() 方法可以随着应用程序是否为用户可见而被多次调用。
? 一个activity的 前台生命周期 自 onResume() 调用起，至相应的 onPause()调用为止。在此期间，activity位于前台最上面并与用户进行交互。activity会经常在暂停和恢复之间进行状态转换──比如说当设备转入休眠状态或有新的activity启动时，将调用onPause() 方法。当activity获得结果或者接收到新的intent的时候会调用onResume() 方法。因此，在这两个方法中的代码应当是轻量级的。
下图展示了上述循环过程以及activity在这个过程之中历经的状态改变。着色的椭圆是activity可以经历的主要状态。矩形框代表了当activity在状态间发生改变的时候，你进行操作所要实现的回调方法。
下表详细描述了这些方法，并在activity的整个生命周期中定位了它们。
可方法 描述 杀死 被下一个 在activity第一次被创建的时候调用。这里是你做所有初始化设置的地方──创建视图、绑定数据至列表等。如果曾经有状态记录（参阅后述Saving Activity onCreate() State。），则调用此方法时会传入一个包含着此activity以前状态的包对象做为参数。 总继之以onStart()。 否 onStart() 可方法 描述 杀死 被下一个 在activity停止后，在再次启动之前被调用。 onRestart() 总继之以onStart()。 否 onStart() 当activity正要变得为用户所见时被调用。 onStart() 当activity转向前台时继以onResume()，在activity变为隐藏时继以onStop()。 否 onResume() or onStop() 在activity开始与用户进行交互之前被调用。此时onResume() activity位于堆栈顶部，并接受用户输入。 继之以onPause()。 onPause() 当系统将要启动另一个activity时调用。此方法主要用来将未保存的变化进行持久化，停止类似动画这样耗费CPU的动作等。这一切动作应该在短时间内完成，因为下一个activity必须等到此方法返回后才会继续。 当activity重新回到前台是继以onResume()。当activity变为用户不可见时继以onStop()。 当activity不再为用户可见时调用此方法。这可能发生在它被销毁或者另一个activity（可能是现存的或者是新onStop() 的）回到运行状态并覆盖了它。 如果activity再次回到前台跟用户交互则继以是 是 否 onPause() onResume() or onStop() onRestart() or onDestroy() onRestart()，如果关闭activity则继以onDestroy()。 在activity销毁前调用。这是activity接收的最后一个调用。这可能发生在activity结束（调用了它的 finish() onDestroy() 方法）或者因为系统需要空间所以临时的销毁了此acitivity的实例时。你可以用isFinishing() 方法来区分这两种情况。 是 nothing 请注意上表中可被杀死一列。它标示了在方法返回后，还没执行activity的其余代码的任意时间里，系统是否可以杀死包含此activity的进程。三个方法（onPause()、 onStop()和onDestroy()）被标记为“是”。
onPause()是三个中的第一个，它也是唯一一个在进程被杀死之前必然会调用的方法──onStop() 和 onDestroy() 有可能不被执行。因此你应该用 onPause() 来将所有持久性数据（比如用户的编辑结果）
写入存储之中。
在可被杀死一列中标记为“否”的方法在它们被调用时将保护activity所在的进程不会被杀死。所以只有在
onPause()方法返回后到onResume() 方法被调用时，一个activity才处于可被杀死的状态。在onPause()再次被调用并返回之前，它不会被系统杀死。
如后面一节进程和生命周期所述，即使是在这里技术上没有被定义为“可杀死”的activity仍然有可能被系统杀死──但这仅会发生在实在没有其它方法的极端情况之下。
保存activity状态
当系统而不是用户自己出于回收内存的考虑，关闭了一个activity之后。用户会期望当他再次回到那个activity的时候，它仍保持着上次离开时的样子。
为了获取activity被杀死前的状态，你应该为activity实现onSaveInstanceState() 方法。Android在activity有可能被销毁之前（即onPause() 调用之前）会调用此方法。它会将一个以名称-值对方式记录了activity动态状态的Bundle 对象传递给该方法。当activity再次启动时，这个Bundle会传递给
onCreate()方法和随着onStart()方法调用的onRestoreInstanceState()，所以它们两个都可以恢复捕获的状
态。
与onPause()或先前讨论的其它方法不同，onSaveInstanceState() 和 onRestoreInstanceState() 并不是生命周期方法。它们并不是总会被调用。比如说，Android会在activity易于被系统销毁之前调用
onSaveInstanceState()，但用户动作（比如按下了BACK键）造成的销毁则不调用。在这种情况下，用
户没打算再次回到这个activity，所以没有保存状态的必要。
因为onSaveInstanceState()不是总被调用，所以你应该只用它来为activity保存一些临时的状态，而不能用来保存持久性数据。而是应该用onPause()来达到这个目的。
协调activity
当一个activity启动了另外一个的时候，它们都会经历生命周期变化。一个会暂停乃至停止，而另一个则启动。这种情况下，你可能需要协调好这些activity：
生命周期回调顺序是已经定义好的，尤其是在两个activity在同一个进程内的情况下：
1. 调用当前activity的 onPause() 方法。
2. 接着，顺序调用新启动activity的onCreate()、 onStart()和onResume()方法。 3. 然后，如果启动的activity不再于屏幕上可见，则调用它的onStop()方法。
服务生命周期
服务以两种方式使用：
? 它可以启动并运行，直至有人停止了它或它自己停止。在这种方式下，它以调用Context.startService()启动，而以调用Context.stopService()结束。它可以调用Service.stopSelf() 或 Service.stopSelfResult()来自己停止。不论调用了多少次
startService()方法，你只需要调用一次stopService()来停止服务。
?
它可以通过自己定义并暴露出来的接口进行程序操作。客户端建立一个到服务对象的连接，并通过那个连接来调用服务。连接以调用Context.bindService()方法建立，以调用
Context.unbindService()关闭。多个客户端可以绑定至同一个服务。如果服务此时还没有加载，bindService()会先加载它。
这两种模式并不是完全分离的。你可以绑定至一个用 startService()启动的服务。比如说，一个后台音乐播放服务可以调用startService()并传递给它一个包含欲播放的音乐列表的Intent对象来启动。不久，当用户想要对播放器进行控制或者查看当前播放曲目的详情时，会启用一个activity，调用bindService()连接到服务来完成操作。在这种情况下，直到绑定连接关闭stopService() 才会真正停止一个服务。 与activity一样，服务也有一系列你可以实现以用于监控其状态变化的生命周期方法。但相对于activity要少一些，只有三个，而且，它们是public属性，并非protected：
void onCreate()
void onStart(Intent intent) void onDestroy()
倚仗实现这些方法，你监控服务的两个嵌套的生命周期循环：
? 服务的完整生命周期始于调用onCreate()而终于onDestroy()方法返回。如同activity一样，服务在onCreate()里面进行它自己的初始化，而在onDestroy()里面释放所有资源。比如说，一个音乐回放服务可以在onCreate()中创建播放音乐的线程， 而在onDestroy()中停止这个线程。
? 服务的活跃生命周期始于调用onStart()。这个方法用于处理传递给startService()的Intent对象。音乐服务会打开Intent来探明将要播放哪首音乐，并开始播放。 服务停止时没有相应的回调方法──不存在onStop()方法。
onCreate()和onDestroy()方法在所有服务中都会被调用，不论它们是由Context.startService()还是由
Context.bindService()所启动的。而onStart()仅会被startService()所启用的服务调用。 如果一个服务允许别的进程绑定，则它还会有以下额外的回调方法以供实现：
IBinder onBind(Intent intent) boolean onUnbind(Intent intent) void onRebind(Intent intent)
传递给bindService的Intent的对象也会传递给onBind()回调方法，而传递给unbindService()的Intent对象同样传递给onUnbind()。如果服务允许绑定，onBind()将返回一个供客户端与服务进行交互的通讯渠道。如果有新的客户端连接至服务，则onUnbind()方法可以要求调用onRebind() 。
下图描绘了服务的回调方法。尽管图中对由startService 和startService方法启动的服务做了区分，但要记住，不论一个服务是怎么启动的，它都可能允许客户端的连接，所以任何服务都可以接受onBind()和onUnbind()调用。
广播接收器生命周期
广播接收器只有一个回调方法：
void onReceive(Context curContext, Intent broadcastMsg)
当广播消息抵达接收器时，Android调用它的onReceive() 方法并将包含消息的Intent对象传递给它。广播接收器仅在它执行这个方法时处于活跃状态。当onReceive()返回后，它即为失活状态。
拥有一个活跃状态的广播接收器的进程被保护起来而不会被杀死。但仅拥有失活状态组件的进程则会在其它进程需要它所占有的内存的时候随时被杀掉。
这种方式引出了一个问题：如果响应一个广播信息需要很长的一段时间，我们一般会将其纳入一个衍生的线程中去完成，而不是在主线程内完成它，从而保证用户交互过程的流畅。如果onReceive()衍生了一个线程并且返回，则包涵新线程在内的整个进程都被会判为失活状态（除非进程内的其它应用程序组件仍处于活跃状态），于是它就有可能被杀掉。这个问题的解决方法是令onReceive()启动一个新服务，并用其完成任务，于是系统就会知道进程中仍然在处理着工作。 下一节中，我们会讨论更多进程易误杀的问题。
进程与生命周期
Android系统会尽可能长的延续一个应用程序进程，但在内存过低的时候，仍然会不可避免需要移除旧的进程。为决定保留或移除一个进程，Android将每个进程都放入一个“重要性层次”中，依据则是它其中运行着的组件及其状态。重要性最低的进程首先被消灭，然后是较低的，依此类推。重要性共分五层，依据重要性列表如下：
1. 前台进程是用户操作所必须的。当满足如下任一条件时，进程被认为是处于前台的：
o 它运行着正在与用户交互的activity（Activity对象的 onResume() 方法已被调用）。 o 一个正在与用户交互的activity使用着它提供的一个服务。
o 它包含着一个正在执行生命周期回调方法（onCreate()、onStart()或onDestroy()）
的Service对象。
o 它包含着一个正在执行 onReceive() 方法的BroadcastReceiver对象。
任一时间下，仅有少数进程会处于前台，仅当内存实在无法供给它们维持同时运行时才会被杀死。一般来说，在这种情况下，设备已然处于使用虚拟内存的状态，必须要杀死一些前台进程以用户界面保持响应。
2. 可视进程没有前台组件，但仍可被用户在屏幕上所见。当满足如下任一条件时，进程被认为是可
视的：、