android BroadcastReceiver

BroadcastReceiver 接收来自sendBroadcast()发送的广播。这样发送的广播都为全局广播，应用程序会通过intentfilter进行匹配。有时候，我们不希望发送全局广播，而是希望在应用程序自己内部来进行广播的发送和接收。我们可以使用 LocalBroadcastManager 这个类。使用这个类相当于全局广播来说有如下优点：

1.广播数据在本应用范围内传播，你不用担心隐私数据泄露的问题。

2. 不用担心别的应用伪造广播，造成安全隐患。

3.相比在系统内发送全局广播，它更高效。

广播的注册方式有两种一种是动态注册通过方法Context.registerReceiver()方法注册；另一种是静态注册在android mainfast文件中使用标签<receiver>。

动态注册时候，你应该在 onResume中注册广播，在onPause 卸载广播unRegisterReceiver()或者说反注册。在activity处于onPause状态时，是不会接受intents的，这样做也是为了减小系统不必要的开销。

广播分类：

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

即使是在广播普通的broadcasts的情况下，系统也有可能在某些情况下转换为一次发送一个broadcast给一个receriver。特别是当receivers需要创建进程时，在同一时刻仅仅一个receiver可以运行，避免系统因为这些新建的进程而过载。
   注意：尽管Intent类是用来发送和接受这些broadcasts，这里的Intent broadcast机制和那些通过Context.startActivity()方法来启动activity的intent是完全独立的。一个BroadcastReceiver是没办法观察和捕获一个用于启动activity的intent的；同样的，当你通过intent来发出broadcast时，你也不可能(通过这个intent)找到或者启动一个activity的。这两种操作是完全不同的：通过一个intent来启动一个activity是一个前台操作，会改变用户当前交互的对象；而通过intent来发出broadcast是一个后台操作，用户经常是察觉不到的。
   BroadcastReceiver类(通过一个manifest的<receiver>标签作为一个组件启动)是应用程序全局声明周期重要的一部分。

 

Security：

1.由于Intent为全局的，所以必须确保你自己定义的Intent action 字符串或者其他应用程序中不能有冲突。

2.当应用程序注册了某个广播时，即便设置了IntentFilter还是会接收到来自其他应用程序的广播进行匹配判断。对于动态注册的广播可以通过类似registerReceiver(BroadcastReceiver, IntentFilter, String, android.os.Handler)的接口指定发送者必须具备的permission，对于静态注册的广播可以通过android:exported="false"属性表示接收者对外部应用程序不可用，即不接受来自外部的广播。这个需要通过LocalBroadcastManager来解决

Receiver生命周期：

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

进程的生命周期：

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