一.BroadcastReciver
BroadcastReciver作为Android组件间的通信方式，可以使用的场景如下
- 同一app内部的同一组件内的消息通信（单个或多个线程之间）；
- 同一app内部的不同组件之间的消息通信（单个进程）；
- 同一app具有多个进程的不同组件之间的消息通信；
- 不同app之间的组件之间消息通信；
相对于第二种情况，同一app内部的不同组件之间的消息通信（单个进程），对于此类需求，在有些教复杂的情况下单纯的依靠基于接口的回调等方式不好处理，此时可以直接使用EventBus等，相对而言，EventBus由于是针对统一进程，用于处理此类需求非常适合，且轻松解耦。
1.Android全局广播Broadcast
首先全局广播是重量级别的，并且会消耗很多资源，但是可以跨进程通信，通过以上优缺点可以知道只有一种情况下才会用到它，跨进程的时候，这个特点也是其他方案不能达到的。
2.Android本地广播Broadcast
Local Broadcast也是会消耗很多资源的，但是相比全局广播要轻量一些，他的最大优点是可以拿到Context、Intent等和Android系统紧密相关的上下文，这样就方便数据的传递和接受。
二.BroadcastReciver和EventBus区别
| BroadcastReciver | EventBus |
|---|---|
| 可以在不同进程间发送和接收消息 | 同一进程的消息发送和接收 |
| 都属于异步调用 | 在同一线程中发布和接收是同步调用，如果发布和订阅在不同线程间调用是异步的 |
| 适用于实现系统内全局性的消息传递 | 应用内的消息事件广播 |
| 优势体现在和 SDK 的紧密联系，onReceive() 方法自带了 Context 和 Intent 参数 | 不依赖于 Context，使用时无需像广播一样关注 Context 的注入与传递 |
BroadcastReceiver既然能够在Android四大组件中占有一席之地，自然也有它独有的优势，第一个是系统相关事件的监听，比如开机启动，网络连接，电量变化等，第二个是多进程通信，这些是Observer 或者EventBus很难办到的。
所以BroadcastReceiver的使用需要看具体的使用场景，像单进程多线程这种场景，就不建议用BroadcastReceiver了，有种杀鸡用牛刀的赶脚，使用Observer 或者EventBus更适合；但是对于需要监听系统广播事件的场合，比方说现在很多进程保活机制里面就用到了一些系统广播的监听，就正是BroadcastReceiver大展拳脚的时候了。
Android中内置了多个系统广播：只要涉及到手机的基本操作（如开机、网络状态变化、拍照等等），都会发出相应的广播。每个广播都有特定的Intent - Filter（包括具体的action）
三.观察者模式与 EventBus对比
| 观察者模式 | EventBus |
|---|---|
| 难以控制通知的优先度 | 优先级，能够保证Subscriber关注最重要的通知 |
| 要求观察者在事件发生时在场才能收到通知 | 粘滞事件能够保证通知不会因Subscriber的不在场而忽略 |
| 大多数时候是同步的，比如当事件触发，Subject就会去调用观察者的方法 | 发布-订阅模式大多数时候是异步的（使用消息队列） |
| 观察者模式的订阅者与发布者之间是存在依赖 | 不会 |
可继承，优先级，粘滞是eventBus比之于广播，观察者等方式最大的优点
观察者模式与 EventBus，最大的区别是调度的地方。
虽然两种模式都存在订阅者和发布者（具体观察者可认为是订阅者、具体目标可认为是发布者），但是观察者模式是由具体目标调度的，而发布/订阅模式是统一由调度中心调的，所以观察者模式的订阅者与发布者之间是存在依赖的，而发布/订阅模式则不会。
举个栗子：
观察者模式：我办了一个补习班，学生想来我这学习，必须先报名（注册）。收齐一帮学生，开始教学，学生们听了我的课及时更新了自己的认知。我和学生们紧密相连。每个人我都认识。
发布订阅EventBus模式：我在某视频站上开了一个专栏，把我的课上传上去，喜欢的同学订阅下。后续我只要把最新课程传到视频站上就好了，学生们听了我的课亦能及时新了自己的认知。我和学生们的联系不是那么大了。我也不需要认识他们。
后者比前者多了一个类似中转站的东西（姑且称为“调度中心”），省了我好多事。有学生不愿意学了 ，直接找调度中心退订就好了，不用找我说。我发布的新课程也由调度中心做广播，不用我自己再一个个通知，不会影响到我自己干其他工作。