Android中的广播机制

   目前在App开发中的消息全局通知方案有以下几种：系统广播，观察者和eventbus等第三方开源工具。

观察者和eventbus都只能用于应用内的消息通信，他们之间的区别主要在于实现方式的不同

。观察者是由用户通过handler自己实现一套，维护和扩展方便，但是一般不支持优先级和sticky等

原生广播特性，而且随着业务逻辑复杂度增加，监听接口会迅速膨胀

。eventbus等第三方开源工具功能使用简单，功能也要强大一些，支持优先级和sticky等原生广播特性

。但是由于是使用第三方库所以在不了解其实现原理的情况下bug调试跟踪会变得困难，

而且更新库（接口或者一些属性有变动的话）可能会影响到代码的大面积改动

。broadcast不仅支持应用内通信也支持不同应用进程之间的通信。但是由于其底层使用binder来实现，

所以效率上与前两者相比要低一些。当然broadcast最大的优势还是在对系统事件的监听上，

这是其他两个方案没法办到的。所以关于消息通信方案的选择上，

需要根据自己的需求来选择合适的方案。当需要App应用内通信时，优先选择观察者或者Eventbus，

当需要进程间通信或者监听系统广播事件时，选择Broadcast。

另外再提一下LocalBroadcastManager这个类，它是一个本地广播管理器，

估计是Android考虑到原生Broadcast的效率问题而提供的一个轻量级的广播。

它主要是解决App应用内通信的问题，采用handler实现，跟观察者的实现方案类似，

什么是广播：

广播广播。广而告之。比如通知栏里显示的QQ啊。音乐啊。未接来电啊、

、都是从他们各自的软件广播出来的事件。android系统接收广播显示。

一、广播的分类，按有无顺序区分，可以分为：标准广播、有序广播。

（1）标准广播。就是多个广播接收者，接收到广播是无序的，没有规定谁先谁后。

按理想状况来说，是同一时间接收到系统发出的广播。

（2）有序广播。在广播接收者，注册添加这条广播时，有增加了优先熟悉的设置。优先级高的先接收，优先级高的广播接收者，还可以控制是否将广播往下继续传递；

为什么用广播：

在Android中，有一些操作完成以后，会发送广播，比如说发出一条短信，

或打出一个电话，如果某个程序接收了这个广播，就会做相应的处理。

这个广播跟我们传统意义中的电台广播有些相似之处

在那里用广播：

关于消息通信方案的选择上，需要根据自己的需求来选择合适的方案。

当需要App应用内通信时，优先选择观察者或者Eventbus，

当需要进程间通信或者监听系统广播事件时，选择Broadcast

如何用广播：

广播的两种注册方式：

静态注册和动态注册

两种注册广播的区别：

1)第一种是常驻型，也就是说当应用程序关闭后，如果有信息广播来，程序也会被系统调用自动运行。

    2)第二种不是常驻型广播，也就是说广播跟随程序的生命周期。

*动态注册优先级

广播的生命周期：

广播接收器仅有一个回调方法：

voidonReceive(ContextcurContext, Intent broadcastMsg)

当一个broadcast信息到达该receiver，Android调用它的onReceive()方法并将含有该广播信息的intent 对象传递它。Broadcast receiver仅仅在执行该方法时才被认为是活跃的。当onReceive()返回后，它又处于非活跃状态。也就是说，它的生命周期为从回调onReceive()方法开始到该方法返回结果后结束。

一个包含活跃的broadcast receiver的进程会被保护起来不被杀死。但是一个仅仅含有非活跃组件的进程，在它消耗的内存被其它进程需要时可能随时被系统杀死。

广播接收器的生命周期只有十秒左右，如果在 onReceive() 内做超过十秒内的事情，就会报ANR(Application No Response) 程序无响应的错误信息。当该broadcast信息的响应很耗时时会存在问题，这时应该单独给他一个线程运行，而不是在其他组件所在的与用户交互的线程中。如果onReceive()生成该线程后返回，整个进程，包括那个新的线程，都被判断为非活跃的（除非该进程里的其他组件是活跃的），归入了可以被杀死的一类。解决该问题的答案是使用onReceive()开始一个service，让该service进行该处理，那样一来，系统就会知道该进程里仍有活跃的处理在进行。