文章索引：
EventBus 3.0 从入门到精通——初识EventBus
EventBus 3.0 从入门到精通——EventBus的应用场景
EventBus 3.0 从入门到精通——使用详解（一）
通过上一篇文章我们对EventBus有了一个简单的了解，这篇我们继续学习一下EventBus的应用场景。
什么时候可以使用EventBus？
首先因为EventBus是一个发布/订阅框架，所以它使用了观察者模式。
观察者模式定义了一种一对多的依赖关系，让多个观察者对象同时监听某一个主题对象。这个主题对象在状态发生变化时，会通知所有观察者对象，使它们能够自动更新自己。
看观察者模式的定义我们就能看到，EventBus是为了解决数据的同步或者事件的传递而产生的。
所以一般可以在以下几种情况中使用EventBus：
- 一个事件可以同时触发多个对象的数据更新或者UI变化；
- 多个没有直接关联的对象之间的同步操作；
- 对象之间传递复杂事件的解耦
简单分析一下：比如微博的一个点赞事件，当用户在微博页面点赞时触发一个用户点赞事件。事件被触发后需要同时更新微博页面的点赞按钮的UI以及微博点赞列表的数据，并且还要更新用户基本信息中的曾经点赞过的微博的信息等等，它们的优先级基本差不多这个时候就可以使用EventBus来处理这个事件的发布和订阅。再比如我们的App主页面有4个Tab它们是互相独立的模块，但是我在tab1的一个操作会影响到Tab2或者Tab3的UI显示也可以考虑使用EventBus。
总结一下EventBus的优缺点：
优点：
- 灵活性高，不依赖于 Context，无需引用Context更加灵活方便；
- EventBus的事件处理可以继承，这样使得代码更加简洁更符合面向对象的设计；
- EventBus有事件优先级，可以使得Subscriber（订阅者）处理最关注的事件；
- 粘滞事件（sticky events）能够保证事件不会因 Subscriber 占时无法接收事件而丢失；
- 使用简单。EventBus 的注册和反注册，以及事件的定义和接受者的声明都非常的简单和灵活；
- 将事件的发布者和订阅者解耦；
- 轻量级并且性能很好；
缺点：
- 观察者模式可能会造成接口的膨胀，增加工程中类的数量；
- 使用者要对事件有一定的认识，简单的事件或者接口调用最好不要使用EventBus，否者代码的可读性和逻辑上都会很复杂；
总结一下：
App内部的消息通信，在单纯依靠接口调用和回调的方式处理复杂或者不好处理，以及消息存在多个关注对象的情况下可以使用EventBus，而且相对BroadcastReceiver等广播组件而言，EventBus处理起来更加轻量级和解耦。