android Activity,service,broadcastReceiver生命周期

Android生命周期
      在 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开发之旅：组件生命周期（一）

引言

应用程序组件有一个生命周期——一开始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()。

 

Android开发之旅：组件生命周期（二）

引言

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

上篇Android开发之旅：组件生命周期（一）讲解了论活动的生命周期及他们可能的状态、通知状态改变的方法。本篇将介绍服务和广播接收者的生命周期：

• 服务生命周期
• 广播接收者生命周期

1、服务生命周期

一个服务可以用在两个方面：

1 通过startService
    Service会经历 onCreate --> onStart
    stopService的时候直接onDestroy 
    如果是 调用者 直接退出而没有调用stopService的话，Service会一直在后台运行。 下次调用者再起来仍然可以  stopService。如果打算采用Context.startService()方法启动服务，在服务未被创建时，  系统会先调用服务的onCreate()方法，
  接着调用onStart()方法。如果调用startService()方法前服务已经被创建，多次调用startService()方法并不会导致多 次创建服务，但会导致多次调用onStart()方法。采用startService()方法启动的服务，只能调用Context.stopService()方法结束服务，服务结束时会调用onDestroy()方法。


2 通过bindService   
    Service只会运行onCreate， 这个时候 调用者和Service绑定在一起

   调用者退出了，Srevice就会调用onUnbind-->onDestroyed
   所谓绑定在一起就共存亡了。
如果打算采用Context.bindService()方法启动服务，在服务未被创建时，系统会先调用服务的onCreate()方法，
接着调用onBind()方法。这个时候调用者和服务绑定在一起，调用者退出了，系统就会先调用服务的onUnbind()方法，
接着调用onDestroy()方法。如果调用bindService()方法前服务已经被绑定，
多次调用bindService()方法并不会导致多次创建服务及绑定(也就是说onCreate()和onBind()方法并不会被多次调用)。
如果调用者希望与正在绑定的服务解除绑定，可以调用unbindService()方法，调用该方法也会导致系统调用服务的onUnbind()-->onDestroy()方法.

• 它可以启动且允许一直运行直到有人停止它，或者它自己停止。在这种模式，通过调用Context.startService()启动服务及通过调用Context.stopService()停止服务。服务也可以通过调用Service.stopSelf()或Service.stopSelfResult()停止自己。仅需要调用一次stopService()停止服务，而不管调用startService()了多少次，
• 通过使用相关接口可以编程地操作服务。客户端建立与Service对象的一个连接及使用该连接调入服务。连接通过调用Context.bindService()建立，通过调用Context.unbindService()关闭。多个客户端可以绑定到同一个服务。如果服务尚未启动，bindService()可以选择启动它。

这两种模式并不是完全分离的。你可以绑定到一个用startService()启动的服务。例如，一个后台音乐服务可以通过使用定义了音乐播放的Intent对象调用startService()启动。直到后来，用户可能想对播放器做一些控制或者获取当前歌曲的一些信息，一个活动将调用bindService()与服务建立连接。在这种情况下，实际上直到最后一个绑定关闭stopService()并不会停止。

像活动一样，一个服务也有生命周期方法，你可以执行监视它的状态改变。但是比活动的生命周期方法更少，只有三个且它们是公有的（public）而不是受保护的（protected）（说明：活动的生命周期方法是protected的）：

• void onCreate()
• void onStart(Intent intent)
• void onDestory()

通过这三个方法，你可以监视服务生命周期的两个嵌套循环：

• 服务的整个生命时间（entire lifetime），从调用onCreate()到相应地调用onDestory()。像一个活动一样，服务在onCreate()中做一些初始设置，且在中释放所有的资源。例如，一个音乐播放服务可以在onCreate()中创建线程，然后在onDestory()中停止线程。
• 服务的活跃生命时间（active lifetime），从调用onStart()开始。这个方法传递参数是传送给startService()的Intent对象。音乐服务将打开Intent，了解播放哪个音乐并且开始播放。
  没有相应的回调方法，因为服务停止没有onStop()方法。

startService()和onDestory()被所有服务调用，不管是通过Context.startService()启动还是通过Context.bindService()启动的。然而，onStart()仅被通过startService()启动的服务调用。

如果一个服务允许别的绑定到它，有一些额外的回调方法来实现它：

• IBinder onBind(Intent intent)
• boolean onUnbind(Intent intent)
• void onRebind(Intent intent)

onBind()回调传递的参数是传给bindService()的Intent对象，onUnbind()回调传递的参数是传给unbindService()的Intent对象。如果服务允许绑定，onBind()返回客户端与服务交互的通信通道。onUnbind()方法可以要求调用onRebind()，如果一个新的客户端连接到服务。

下图解释了服务的回调方法。虽然，它分离了由startService()启动的服务和由bindService()启动的服务，记住任何服务，无论它怎么启动的，都可能允许客户端绑定到它，因此任何服务可能接收onBind()和onUnbind()调用。

2、广播接收者生命周期

一个广播接收者有一个回调方法：void onReceive(Context curContext, Intent broadcastMsg)。当一个广播消息到达接收者是，Android调用它的onReceive()方法并传递给它包含消息的Intent对象。广播接收者被认为仅当它执行这个方法时是活跃的。当onReceive()返回后，它是不活跃的。

有一个活跃的广播接收者的进程是受保护的，不会被杀死。但是系统可以在任何时候杀死仅有不活跃组件的进程，当占用的内存别的进程需要时。

这带来一个问题，当一个广播消息的响应时费时的，因此应该在独立的线程中做这些事，远离用户界面其它组件运行的主线程。如果onReceive()衍生线程然后返回，整个进程，包括新的线程，被判定为不活跃的（除非进程中的其它应用程序组件是活跃的），将使它处于被杀的危机。解决这个问题的方法是onReceive()启动一个服务，及时服务做这个工作，因此系统知道进程中有活跃的工作在做。

推荐android 开发：广播（broadcast）的应用
    android中，不同进程之间传递信息要用到广播，可以有两种方式来实现。
    第一种方式：在Manifest.xml中注册广播，是一种比较推荐的方法，因为它不需要手动注销广播（如果广播未注销，程序退出时可能会出错）。
具体实现在Manifest的application中添加：
<receiver android:name=".mEvtReceiver">
    <intent-filter>
    <action android:name="android.intent.action.BOOT_COMPLETED" />
    </intent-filter>
</receiver>
上面两个android:name分别是广播名和广播的动作（这里的动作是表示系统启动完成），如果要自己发送一个广播，在代码中为：
Intent i = new Intent("android.intent.action.BOOT_COMPLETED");
sendBroadcast(i);
这样，广播就发出去了，然后是接收。
接收可以新建一个类，继承至BroadcastReceiver，也可以建一个BroadcastReceiver的实例，然后得写onReceive方法，实现如下：
protected BroadcastReceiver mEvtReceiver = new BroadcastReceiver() {
@Override
public void onReceive(Context context, Intent intent) {
String action = intent.getAction();
if (action.equals("android.intent.action.BOOT_COMPLETED")) {
    //Do something
}
}       
};

第二种方式，直接在代码中实现，但需要手动注册注销，实现如下：
IntentFilter filter = new IntentFilter();
filter.addAction("android.intent.action.BOOT_COMPLETED");
registerReceiver(mEvtReceiver, filter); //这时注册了一个recevier ,名为mEvtReceiver，然后同样用上面的方法以重写onReceiver，
最后在程序的onDestroy中要注销广播，实现如下：
@Override
public void onDestroy() {
super.onDestroy();
unregisterReceiver(mPlayerEvtReceiver);
}

Android开发之旅：组件生命周期（三）

Android系统试图尽可能长地保持一个应用程序进程，但是当内存低时它最终还是需要移除旧的进程。为了决定保持哪个进程及杀死哪个进程，Android将每个进程放入一个基于运行于其中的组件的重要性等级和这些组件的状态。重要性最低的进程首先被杀死，然后是次低，以此类推。总共有5个层次等级。下列清单按重要性顺序列出：

1. 前台进程，用户当前工作所需要的。一个进程如果满足下列任何条件被认为是前台进程：
   1. 它正运行着一个正在与用户交互的活动（Activity对象的onResume()方法已经被调用）。
   2. 它寄宿了一个服务，该服务与一个与用户交互的活动绑定。
   3. 它有一个Service对象执行它的生命周期回调（onCreate()、onStart()、onDestroy()）。
   4. 它有一个BroadcastReceiver对象执行他的onReceive()方法。
      
      在给定时间内仅有少数的前台进程存在。仅作为最后采取的措施他们才会被杀掉——如果内存太低以至于他们不能继续运行。一般来说，就在那时，设备达到一个内存？？？状态，因此杀掉某些前台进程以保持用户界面响应。
2. 可视进程，他没有任何前台组件，但是仍然能影响用户在屏幕上看到东西。一个进程满足下面任何一个条件都被认为是可视的:
   1. 它寄宿着一个不是前台的活动，但是它对用户仍可见（它的onPause()方法已经被调用）。举例来说，这可能发送在，如果一个前台活动是一个对话框且运行之前的活动在其后面仍可视。
   2. 它寄宿着一个服务，该服务绑定到一个可视的活动。
      
      一个可视进程被认为是及其重要的且不会被杀死，除非为了保持前台进程运行。
3. 服务进程，是一个运行着一个用startService()方法启动的服务，并且该服务并没有落入上面2种分类。虽然服务进程没有直接关系到任何用户可见的，它们通常做用户关心的事（诸如在后台播放mp3或者从网络上下载数据），因此系统保持它们运行，除非没有足够内存随着所有的前台进程和可视进程保持它们。
4. 后台进程，是一个保持着一个当前对用户不可视的活动（已经调用Activity对象的onStop()方法）。这些进程没有直接影响用户体验，并且可以在任何时候被杀以收回内存用于一个前台、可视、服务进程。一般地有很多后台进程运行着，因此它们保持在一个LRU（least recently used，即最近最少使用，如果您学过操作系统的话会觉得它很熟悉，跟内存的页面置换算法LRU一样。）列表以确保最近使用最多的活动的进程最后被杀。如果一个活动执行正确地执行它的生命周期方法，且捕获它当前的状态，杀掉它对用户的体验没有有害的影响。
5. 空进程，是一个没有保持活跃的应用程序组件的进程。保持这个进程可用的唯一原因是作为一个cache以提高下次启动组件的速度。系统进程杀死这些进程，以在进程cache和潜在的内核cache之间平衡整个系统资源。

Android把进程标记为它可以的最高级，即进程中活跃的组件中重要性最高的那个（选取重要性最高的那个作为进程的重要性级别）。例如，有一个进程寄宿着一个服务和一个可视活动，进程的级别被设置为可视进程级别，而不是服务进程级别（因为可视进程级别比服务进程级别高）。

此外，一个进程的排名因为其他进程依赖它而上升。一个进程服务其它进程，它的排名从不会比它服务的进程低。例如，进程A中的一个内容提供者服务进程B中的一个客户，或者进程A中的一个服务绑定到进程B中的一个组件，进程A总是被认为比进程B重要。

因为一个运行一个服务进程排名比一个运行后台活动的进程排名高，一个活动启动一个服务来初始化一个长时间运行操作，而不是简单地衍生一个线程——特别是如果操作很可能会拖垮活动。这方面的例子是在后台播放音乐和上传相机拍摄的图片到一个网站。使用服务保证操作至少有“服务进程”的优先级，无论活动发生什么情况。