BroadcastReceiver内的接收在主线程，所以不能执行耗时操作，超过10秒ANR,发起广播不受线程限制，所以广播可以实现线程间通信和进程间通信
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高版本系统对于一些重要的系统广播，比如开机启动，网络连接，电量变化，锁屏等做了限制，如果需要监听这些广播，需要做系统兼容性处理。
普通广播的广播接收器是并行无序执行的，有序广播的广播接收器按照广播优先级串行执行
EventBus 作为 Android 开发中常用的框架，拥有着许多优点：
调度灵活。不依赖于 Context，使用时无需像广播一样关注 Context 的注入与传递。父类对于通知的监听和处理可以继承给子类，这对于简化代码至关重要；通知的优先级，能够保证 Subscriber 关注最重要的通知；粘滞事件（sticky events）能够保证通知不会因 Subscriber 的不在场而忽略。可继承、优先级、粘滞，是 EventBus 比之于广播、观察者等方式最大的优点，它们使得创建结构良好组织紧密的通知系统成为可能。
使用简单。EventBus 的 Subscriber 注册非常简单，调用 eventBus 对象的 register 方法即可，如果不想创建 eventBus 还可以直接调用静态方法 EventBus.getDefault() 获取默认实例，Subscriber 接收到通知之后的操作放在 onEvent 方法里就行了。成为 Publisher 的过程就更简单了，只需要调用合适的 eventBus（自己创建的或是默认的）的 post 方法即可。
快速且轻量。作为 github 的明星项目之一， EventBus 的源代码中许多技巧来改善性能，
eventbus的缺点是他的代码逻辑不是很清楚，在 Subscriber 注册的时候，Subscriber 中的方法会被遍历查找以 onEvent 开头的 public 方法。这将带来一些问题，一旦对代码进行混淆，就无法查找到了。好消息是 EventBus 已经打算使用注解来实现，这应该能够解决代码混淆的问题。
但有一个缺点是观察者独有的，那就是观察者可能会造成接口的膨胀。特别是当程序要求大量形式各异的通知，而程序员有没有做出良好的抽象时，代码中会包含大量的接口，接口数量的增长又会带来命名、注释等等一大堆问题。本质上说观察者要求程序员从零开始实现事件的产生、分发与处理过程，这就要求参与者必须对整个通知过程有着良好的理解。当程序代码适量时，这是一个合理的要求，然而当程序太大时，这将成为一种负担。
广播作为Android组件间的通信方式，可以使用的场景如下：
1.同一app内部的同一组件内的消息通信（单个或多个线程之间）；
2.同一app内部的不同组件之间的消息通信（单个进程）；
3.同一app具有多个进程的不同组件之间的消息通信；
4.不同app之间的组件之间消息通信；
5.Android系统在特定情况下与App之间的消息通信。
相对于第二种情况，同一app内部的不同组件之间的消息通信（单个进程），对于此类需求，在有些教复杂的情况下单纯的依靠基于接口的回调等方式不好处理，此时可以直接使用EventBus等，相对而言，EventBus由于是针对统一进程，用于处理此类需求非常适合，且轻松解耦。
