Broadcast应用场景分析

Android基于Linux内核，Linux提供了诸如消息、管道、共享内存、信号量、Socket等多种通信方式。然而Android采用了binder实现进程间通信，而未理睬Linux提供的通信方式，主要是由于binder的两个优点：

效率，其底层使用了共享内存机制，提高了数据读写的效率
安全，从底层着手控制每个进程之间的访问权限，相比Linux在上层来控制访问权限要更加安全

在Android中对binder的使用方式：

1.代理模式，每个Client在访问Service之前都会获取一个Service的代理，然后通过这个代理来调用Service端提供的功能。比方说我们在Activity或者Service中通过
2.采用广播发送/接收的形式，也就是Broadcast和BroadcastReceiver，这种方式本质上属于消息订阅/发布的事件驱动流形式。

代理模式和广播的区别：

两者的区别，体现在同步调用和异步调用上。

代理模式用于点对点通信，即网络通信中的单播模式，效率自然是高。但是该通信方式是即时发起的，只能同步调用
广播虽然效率低一些，但是发送、接收双方无需知道对方是否存在，可以随时发起，且可供异步调用，由此带来的高度可扩展性，简直不要太爽

Android“大神”—罗升阳对广播的表述可谓鞭辟入里：

在Android系统中，为什么需要广播机制呢？广播机制，本质上它就是一种组件间的通信方式，如果是两个组件位于不同的进程当中，那么可以用Binder机制来实现，如果两个组件是在同一个进程中，那么它们之间可以用来通信的方式就更多了，这样看来，广播机制似乎是多余的。然而，广播机制却是不可替代的，它和Binder机制不一样的地方在于，广播的发送者和接收者事先是不需要知道对方的存在的，这样带来的好处便是，系统的各个组件可以松耦合地组织在一起，这样系统就具有高度的可扩展性，容易与其它系统进行集成。
在软件工程中，是非常强调模块之间的高内聚低耦合性的，不然的话，随着系统越来越庞大，就会面临着越来越难维护的风险，最后导致整个项目的失败。Android应用程序的组织方式，可以说是把这种高内聚低耦合性的思想贯彻得非常透彻，在任何一个Activity中，都可以使用一个简单的Intent，通过startActivity或者startService，就可以把另外一个Activity或者Service启动起来为它服务，而且它根本上不依赖这个Activity或者Service的实现，只需要知道它的字符串形式的名字即可，而广播机制更绝，它连接收者的名字都不需要知道。

在App开发中的消息全局通知方案有以下几种：系统广播，观察者和eventbus等第三方开源工具。观察者和eventbus都只能用于应用内的消息通信，他们之间的区别主要在于实现方式的不同。观察者是由用户通过handler自己实现一套，维护和扩展方便，但是一般不支持优先级和sticky等原生广播特性，而且随着业务逻辑复杂度增加，监听接口会迅速膨胀。eventbus等第三方开源工具功能使用简单，功能也要强大一些，支持优先级和sticky等原生广播特性。但是由于是使用第三方库所以在不了解其实现原理的情况下bug调试跟踪会变得困难，而且更新库（接口或者一些属性有变动的话）可能会影响到代码的大面积改动。broadcast不仅支持应用内通信也支持不同应用进程之间的通信。但是由于其底层使用binder来实现，所以效率上与前两者相比要低一些。当然broadcast最大的优势还是在对系统事件的监听上，这是其他两个方案没法办到的。所以关于消息通信方案的选择上，需要根据自己的需求来选择合适的方案。当需要App应用内通信时，优先选择观察者或者Eventbus，当需要进程间通信或者监听系统广播事件时，选择Broadcast。另外再提一下LocalBroadcastManager这个类，它是一个本地广播管理器，估计是Android考虑到原生Broadcast的效率问题而提供的一个轻量级的广播。它主要是解决App应用内通信的问题，采用handler实现，跟观察者的实现方案类似，有兴趣的可以去看下它的源码。
Android提供了BroadcastReceiver这个组件来帮助我们监听广播消息，这里我们来看下BroadcastReceiver的使用场景：

App全局监听，这种主要用于在AndroidManifest中静态注册的广播接收器，一般我们在收到该消息后，需要做一些相应的动作，而这些动作与当前App的组件，比如Activity或者Service的是否运行无关，比如我们在集成第三方Push SDK时，一般都会添加一个静态注册的BroadcastReceiver来监听Push消息，当有Push消息过来时，会在后台做一些网络请求或者发送通知等等。
组件局部监听，这种主要是在Activity或者Service中使用registerReceiver()动态注册的广播接收器，因为当我们收到一些特定的消息，比如网络连接发生变化时，我们可能需要在当前Activity页面给用户一些UI上的提示，或者将Service中的网络请求任务暂停。所以这种动态注册的广播接收器适合特定组件的特定消息处理。

关于BroadcastReceiver使用需要注意的几点：

onReceive中不能执行耗时操作，如果耗时超过10s会弹出ANR。
onReceive中context参数，如果是静态注册的广播，context为ReceiverRestrictedContext，所在如果在这里要启动一个Activity的话（调用startActivity），需要在intent中添加Intent.FLAG_ACTIVITY_NEW_TASK；如果是动态注册的广播，context为当前注册时所在的组件，比如Activity或者Service。
监听系统广播，需要在AndroidManifest中申请权限，此外，Android高版本系统对于一些重要的系统广播，比如开机启动，网络连接，电量变化，锁屏等做了限制，如果需要监听这些广播，需要做系统兼容性处理。
普通广播的广播接收器是并行无序执行的，有序广播的广播接收器按照广播优先级串行执行