BroadcastReceiver的原理和使用

转载自www.360doc.com

1.     动态注册、静态注册的优先级

在AndroidManifest.xml中静态注册的receiver比在代码中用registerReceiver动态注册的优先级要低。发送方在sendBroadcast后，ActivityManagerService里的broadcastIntentLocked函数会处理广播的接收者。静态注册的接收者存在一张表里，动态注册的接收者存在另一张表，AMS会将两个表合并，按广播的优先级排序，如果优先级相同，动态的排在前面。这样动态注册的receiver会先收到广播。

静态注册的receiver可以用android:priority属性来设置接收广播的优先级，这是个4字节整型值，越大优先级越高。因为int型范围是2^31-1到2^31，所以要设置最大的优先级，在intent-filter标签里可写为android:priority="2147483647"。

如果都是动态注册、并且优先级也相同的两个receiver，在broadcastIntentLocked内部会并行地向两个receiver发出Intent。

2.     有序广播

有序广播是用sendOrderedBroadcast来发送。高优先级的接收者会先接收到广播，然后它可以决定是否继续转发，让低优先级的接收者接收到，或者终止广播。高优先级的接收者可以通过setResult把一些信息传给下一个接收者，下一个接收者则通过getResult获取上一个接收者传过来的信息。这个优先级也是用android:priority来设置，范围是-1000到1000。

3.sendStickyBroadcast

Sticky的意思是即使没有接收者，发送的广播Intent也会一直驻留在系统中，一旦有receiver注册，就会立即收到之前发送的广播。发送这个广播的应用需要权限<uses-permissionandroid:name="android.permission.BROADCAST_STICKY" />

如果sendStickyBroadcast发了多个广播，但暂时没有接收者，系统会保留最后一条广播。当有receiver接收到广播并处理后，系统中驻留的广播Intent仍存在，只有在接收者调用removeStickyBroadcast后系统才会移除该Intent。

本来广播就是一种松耦合的机制，而stickyBroadcast对发送方和接收方的耦合要求就更加宽松了，发送广播时接收方可以不存在，但只要接收方一出现就会保证它一定能收到之前发送的广播。比如USB或hdmi的插拔等状态信息，一开机时就已经用sticky的广播把这些信息发送出去了，而接收者所在的应用可能在以后的某个时机才会运行起来，只要一有接收者被注册，它就能立即收到广播来进行异步处理，所以对双方来说都是个完全异步的过程。

4.     生命周期

onReceive是在主线程中被调用的，在onReceive中执行超过10秒就会有ANR，所以在onReceive中只做简单的逻辑处理，稍微耗时的任务放到工作线程或交由service去处理。

无论是静态还是动态注册的receiver，只有在接收到广播后，BroadcastReceiver这个类才会被实例化。receiver在内存紧张时也是会被系统回收掉的。如果在onReceive中另外开启一个线程去长时间执行任务，那么该线程虽然不会被系统kill掉，但receiver会被回收，也就是说receiver里的成员变量都不可用了，后台线程中如果用到receiver这个类里的变量那就会出错。所以还是推荐收到广播后用service去处理重要的（必需保证执行完成）、需长时间执行的任务，虽然起一个service的代价比new Thread的花费要大得多。

二、注册和接收广播的过程

前面提到过，应用发送广播调sendBroadcast后，在AMS里都会由broadcastIntentLocked这个函数去处理，最终会找到receiver，调用接收者的onReceiver，下面简略看一下这个过程，先从动态注册的过程看起。

ContextImpl的registerReceiver函数会调用registerReceiverInternal，其中参数scheduler是一个Handler，registerReceiver调用时传入的为null，这样scheduler指向了主线程的Handler，后面在收到广播后会用这个主线程的Handler去post执行一个Runnable，在Runnalble中执行onReceive。

这里mPackageInfo是LoadedApk类型，它表示进程空间加载的apk，进程空间里有几个apk就对应有几个LoadedApk，通过它的getReceiverDispatcher方法可以获取一个IIntentReceiver类型的对象rd。这个IIntentReceiver是客户端进程用来处理广播Intent的Binder对象，它接下来会被传给AMS。

我们回头再来看LoadedApk的getReceiverDispatcher方法。它里面会先根据context从mReceivers中获取一个map，如果这个map不存在就构造一个放入mReceivers中。mReceivers是LoadedApk的一个成员，它的类型是ArrayMap，其中key是context，value是ArrayMap<BroadcastReceiver, ReceiverDispatcher>。ReceiverDispatcher和BroadcastReceiver是一一对应的，new一个ReceiverDispatcher时要传入BroadcastReceiver、context、handler、instrumentation这些对象。

ReceiverDispatcher有一个内部类InnerReceiver，它实现了IIntentReceiver.Stub，getReceiverDispatcher最后rd.getIIntentReceiver返回的就是InnerReceiver的实例。这个InnerReceiver类在sendBroadcast过程中会被用到，AMS用IIntentReceiver来跨进程调用InnerReceiver的performReceive方法，来完成客户端接收Intent的工作。

再来看AMS里，broadcastIntentLocked的部分代码。

每一个要发送的广播对应一个BroadcastRecord对象，里面包含了注册的receiver的列表registeredReceivers。BroadcastQueue的enqueueParalleBroadcastLocked方式会把BroadcastRecord加入到BroadcastQueue内部的并行发送队列mParallelBroadcasts中。

scheduleBroadcastsLocked方法会把Intent发送给接收者，它用handler发了一个消息，真正负责执行的是processNextBroadcast函数。

我们来看processNextBroadcast的代码片断，从并行发送的队列中取出第一个BroadcastRecord，遍历BroadcastRecord中的receiver列表，对每个receiver调用deliverToRegisteredReceiverLocked执行发送Intent的动作，传入参数时target被转成了BroadcastFilter类型。

deliverToRegisteredReceiverLocked再调用performReceiveLocked，其中r是BroadcastRecord，filter是传入的BroadcastFilter。第一个参数filter.receiverList.app是ProcessRecord类型，第二个参数filter.receiverList.receiver是IIntentReceiver类型。

perforReceiveLocked会借助ProcessRecord和IIntentReceiver，跨进程binder调用客户端进程中InnerReceiver的performReceive方法。这里的app.thread是IApplicationThread类型，它会调到ActivityThread里的scheduleRegisteredReceiver。

从前面动态注册receiver的过程可知，这里的IIntentReceiver是在客户端new出的InnerReceiver，接下来看InnerReceiver的perforReceive的实现。

mDispatcher是ReceiverDispatcher的弱引用，InnerReceiver的performReceive实际上是调用ReceiverDispatcher的performReceive。ReceiverDispatcher的performReceive会构建一个Args，这个Args是Runnable类型，然后用主线程的Handler去执行这个Args。这里mActivityThread是Handler类型，它是LoadedApk的成员，实际上就是主线程的Handler。

在Args的run函数中会直接调用BroadcastReceiver的onReceive函数。这里的receiver就是在registerReceiver时传入ReceiverDispatcher中的BroadcastReceiver。