BroadcastReceiver详解_移动开发_编程开发_程序员俱乐部

   BroadcastReceiver是接收从sendBroadcast()发出的intent的基类。在Android中，Broadcast是一种广泛运用的在应用程序之间传输信息的机制。而BroadcastReceiver是对发送出来的 Broadcast进行过滤接受并响应的一类组件。

　首先在需要发送信息的地方，把要发送的信息和用于过滤的信息(如Action、Category)装入一个Intent对象，然后通过调用 sendBroadcast()或sendOrderBroadcast()或sendStickyBroadcast()方法，把 Intent对象以广播方式发送出去。

　当Intent发送以后，所有已经注册的BroadcastReceiver会检查注册时的IntentFilter是否与发送的Intent 相匹配，若匹配则就会调用BroadcastReceiver的onReceive()方法。所以当我们定义一个BroadcastReceiver的时候，都需要实现onReceive()方法。

注册BroadcastReceiver有两种方式:

静态注册：在 AndroidManifest.xml 中注册

< receiver android:name = ".MyBroadcastReceiver" >

           < intent-filter android:priority = "1000" >

< action android:name = " android.provider.Telephony.SMS_RECEIVED" />

           </ intent-filter >

       </ receiver > 

    当然了需要权限 ：

< uses-permission android:name = "android.permission.RECEIVE_SMS" />

< uses-permission android:name = "android.permission.SEND_SMS" />

动态注册：在代码中注册

IntentFilter intentFilter = new IntentFilter( "android.provider.Telephony.SMS_RECEIVED " );

registerReceiver( mBatteryInfoReceiver , intentFilter);

注意：如果你在Activity.onResume()方法中注册的一个receiver，那么你必须在Activity.onPause()方法中进行注销。(当一个activity处于暂停状态是不会接收intents的，并且这样做也可以减小系统不必要的开销)。不要在 Activity.onSaveInstanceState()方法中注销receiver，因为activity从栈中恢复的时候并不会调用这个方法了。

可以接收的Broadcast主要分为两种类型：

     普通的broadcasts：(通过Context.sendBroadcast发送)是完全异步的。这个broadcast的receiver以无序的状态运行，经常是在同一时刻运行。这种做法是十分高效的，但是也意味着receiver不能够利用相互处理的结果或者是调用退出的API来退出(因为不知道哪个receiver先接收到intent)。
     有序的broadcasts：(通过Context.sendOrderedBroadcast发送)一次只发送给一个receiver。每一个 receiver是有序的处理这个intent的，前面的receiver可以传递结果给下一个receiver，或者任意一个receiver都可以完全的退出，这样intent就不会传递给其他的receivers.receiver的执行顺序可以通过匹配的intent-filter中的 android:priority属性来控制；如果有多个receivers处于同一个优先级，那么这几个receivers将会以任意的顺序来执行。

注意：尽管Intent类是用来发送和接受这些broadcasts，这里的Intent broadcast机制和那些通过Context.startActivity()方法来启动activity的intent是完全独立的。一个 BroadcastReceiver是没办法观察和捕获一个用于启动activity的intent的；同样的，当你通过intent来发出 broadcast时，你也不可能(通过这个intent)找到或者启动一个activity的。这两种操作是完全不同的：通过一个intent来启动一个activity是一个前台操作，会改变用户当前交互的对象；而通过intent来发出broadcast是一个后台操作，用户经常是察觉不到的。

Receiver的生命周期

一个BroadcastReceiver的对象仅仅在调用onReceiver(Context, Intent)的时间中有效。一旦你的代码从这个函数中返回，那么系统就认为这个对象应该结束了，不能再被激活。
     你在onReceive(Context, Intent)中的实现有着非常重要的影响：任何对于异步操作的请求都是不允许的，因为你可能需要从这个函数中返回去处理异步的操作，但是在那种情况下，BroadcastReceiver将不会再被激活，因此系统就会再异步操作之前杀死这个进程。
     特别是，你不应该再一个BroadcastReceiver中显示一个对话框或者绑定一个服务。对于前者(显示一个对话框),你应该用 NotificationManager API来替代，对于后者(绑定一个服务),你可以使用Context.startService()发送一个命令给那个服务来实现绑定效果。

进程的生命周期

       一个正在执行BroadcastReceiver(也就是，正在执行onReceive(Context, Intent)方法)的进程被认为是一个前台的进程，将会一直运行，除非系统处于内存极度低的情况下。
      一旦从OnReceive()方法中返回，这个BroadcastReceiver将不会再被激活，此时它的主进程就和任何其他运行于此应用程序中的组件拥有相同的优先级。这一点非常重要，如果进程仅仅只是拥有BroadReceiver(一个普遍的情况是用户从不或者是最近没有和它进行交互)，因此一旦它从onReceive()方法中返回时，系统就会认为进程是空的并且主动的杀死它，以便这些资源可以被其他重要的进程利用。
      这意味着对于耗时的操作，可以采用将Service和BroadcastReceiver结合使用以确保执行这个操作的进程在整个执行过程中都保持激活状态。