引言
应用程序组件有一个生命周期——一开始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中添加：
<receiverandroid:name=".mEvtReceiver">
<intent-filter>
<actionandroid:name="android.intent.action.BOOT_COMPLETED"/>
</intent-filter>
</receiver>
上面两个android:name分别是广播名和广播的动作（这里的动作是表示系统启动完成），如果要自己发送一个广播，在代码中为：
Intenti=newIntent("android.intent.action.BOOT_COMPLETED");
sendBroadcast(i);
这样，广播就发出去了，然后是接收。
接收可以新建一个类，继承至BroadcastReceiver，也可以建一个BroadcastReceiver的实例，然后得写onReceive方法，实现如下：
protectedBroadcastReceivermEvtReceiver=newBroadcastReceiver(){
@Override
publicvoidonReceive(Contextcontext,Intentintent){
Stringaction=intent.getAction();
if(action.equals("android.intent.action.BOOT_COMPLETED")){
//Dosomething
}
}
};第二种方式，直接在代码中实现，但需要手动注册注销，实现如下：
IntentFilterfilter=newIntentFilter();
filter.addAction("android.intent.action.BOOT_COMPLETED");
registerReceiver(mEvtReceiver,filter);//这时注册了一个recevier,名为mEvtReceiver，然后同样用上面的方法以重写onReceiver，
最后在程序的onDestroy中要注销广播，实现如下：
@Override
publicvoidonDestroy(){
super.onDestroy();
unregisterReceiver(mPlayerEvtReceiver);
}Android开发之旅：组件生命周期（三）
Android系统试图尽可能长地保持一个应用程序进程，但是当内存低时它最终还是需要移除旧的进程。为了决定保持哪个进程及杀死哪个进程，Android将每个进程放入一个基于运行于其中的组件的重要性等级和这些组件的状态。重要性最低的进程首先被杀死，然后是次低，以此类推。总共有5个层次等级。下列清单按重要性顺序列出：
- 前台进程，用户当前工作所需要的。一个进程如果满足下列任何条件被认为是前台进程：
- 它正运行着一个正在与用户交互的活动（Activity对象的onResume()方法已经被调用）。
- 它寄宿了一个服务，该服务与一个与用户交互的活动绑定。
- 它有一个Service对象执行它的生命周期回调（onCreate()、onStart()、onDestroy()）。
- 它有一个BroadcastReceiver对象执行他的onReceive()方法。
在给定时间内仅有少数的前台进程存在。仅作为最后采取的措施他们才会被杀掉——如果内存太低以至于他们不能继续运行。一般来说，就在那时，设备达到一个内存？？？状态，因此杀掉某些前台进程以保持用户界面响应。
- 可视进程，他没有任何前台组件，但是仍然能影响用户在屏幕上看到东西。一个进程满足下面任何一个条件都被认为是可视的:
- 它寄宿着一个不是前台的活动，但是它对用户仍可见（它的onPause()方法已经被调用）。举例来说，这可能发送在，如果一个前台活动是一个对话框且运行之前的活动在其后面仍可视。
- 它寄宿着一个服务，该服务绑定到一个可视的活动。一个可视进程被认为是及其重要的且不会被杀死，除非为了保持前台进程运行。
- 服务进程，是一个运行着一个用startService()方法启动的服务，并且该服务并没有落入上面2种分类。虽然服务进程没有直接关系到任何用户可见的，它们通常做用户关心的事（诸如在后台播放mp3或者从网络上下载数据），因此系统保持它们运行，除非没有足够内存随着所有的前台进程和可视进程保持它们。
- 后台进程，是一个保持着一个当前对用户不可视的活动（已经调用Activity对象的onStop()方法）。这些进程没有直接影响用户体验，并且可以在任何时候被杀以收回内存用于一个前台、可视、服务进程。一般地有很多后台进程运行着，因此它们保持在一个LRU（least recently used，即最近最少使用，如果您学过操作系统的话会觉得它很熟悉，跟内存的页面置换算法LRU一样。）列表以确保最近使用最多的活动的进程最后被杀。如果一个活动执行正确地执行它的生命周期方法，且捕获它当前的状态，杀掉它对用户的体验没有有害的影响。
- 空进程，是一个没有保持活跃的应用程序组件的进程。保持这个进程可用的唯一原因是作为一个cache以提高下次启动组件的速度。系统进程杀死这些进程，以在进程cache和潜在的内核cache之间平衡整个系统资源。
Android把进程标记为它可以的最高级，即进程中活跃的组件中重要性最高的那个（选取重要性最高的那个作为进程的重要性级别）。例如，有一个进程寄宿着一个服务和一个可视活动，进程的级别被设置为可视进程级别，而不是服务进程级别（因为可视进程级别比服务进程级别高）。
此外，一个进程的排名因为其他进程依赖它而上升。一个进程服务其它进程，它的排名从不会比它服务的进程低。例如，进程A中的一个内容提供者服务进程B中的一个客户，或者进程A中的一个服务绑定到进程B中的一个组件，进程A总是被认为比进程B重要。
因为一个运行一个服务进程排名比一个运行后台活动的进程排名高，一个活动启动一个服务来初始化一个长时间运行操作，而不是简单地衍生一个线程——特别是如果操作很可能会拖垮活动。这方面的例子是在后台播放音乐和上传相机拍摄的图片到一个网站。使用服务保证操作至少有“服务进程”的优先级，无论活动发生什么情况。