软件架构模式——事件总线模式

   首先我来解释一下什么是事件总线模式。提到事件总线模式你可能很陌生，不知道是什么，那么咱们换个说法，软件设计模式中有一种叫作观察者模式，其实事件总线模式就是对观察者模式的一种实现，它是一种集中式事件处理机制，容许不一样的组件之间进行彼此通讯而又不须要相互依赖，达到一种解耦的目的，他就是对观察者模式的一种拓展。若是你对观察者模式不太熟悉的话，建议本身找找资料理解一下。接下来我经过Android里面的机制来说解一下事件总线模式。

   在Android开发中，常常会涉及Activity,Fragment，Service等不一样组件或者模块之间的消息传递。使用传统的方法实现，每每代码不够优雅，并且不一样组件和模块之间的耦合严重。随着模块的增多、代码逻辑的不断新增和修改，整个代码的架构就会显得愈来愈混乱。Activity中的不一样的fragment之间须要进行通讯，传统的作法是 将activity做为中介，Fragment A经过getActivity()获取宿主的Activity实例进而能够拿到Fragment B的实例，从而向Fragment B发送消息或者获取数据。好一点的作法是在Fragment中编写接口，让宿主Activity实现该接口，从而在Activity中实现不一样Fragment之间的数据通讯。或者多个Activity页面跳转和数据回传的问题，例如Activity A跳转到Activity B，接着跳转到ActivityC，在C中执行一系列操做以后，须要传递数据或者事件给Activity A，传统的作法是进行接口回调，这样不只增长逻辑复杂性，并且增大页面间的耦合。

   发布者Publisher：发布某种事件的对象。

   事件Event：一个简单的POJO对象。只包含数据，不对数据进行处理。

   事件总线EventBus： 负责订阅者，事件等信息的存储，同时处理事件的流动和分发，经过总线，订阅者和发布者是解耦的，互相不知道对方的存在。

   订阅者Subscriber： 订阅某种类型事件的对象。一般会有一个回调函数用于对接收到的事件进行处理，订阅者能够订阅事件，也能够去掉订阅的事件。订阅者能够引入优先级的概念，优先级高的订阅者能够优先接收到该事件，并能够决定是否继续传递事件给低优先级的订阅者。

   EventBus一共提供了4种线程模型ThreadModel，分别是PostThread, MainThread, BackgroundThread, Async。

   PostThread --------------默认实现，执行发生在发布事件的同一个线程；

   MainThread --------------执行在UI主线程上；

   BackgroundThread、Async---两个都是经过Executors.newCachedThreadPool()线程池来执行的。

   Eventbus做为android开发中的经常使用框架，拥有着许多优势：

   调度灵活：不依赖于Context，使用时无需像广播同样关注Context的注入与传递。父类对于通知的监听和处理能够继承给子类。这对于简化代码相当重要。通知的优先级，可以保证Subscriber关注最重要的通知；粘滞事件可以保证通知不会因Subscriber的不在场而忽略。 可继承，优先级，粘滞是eventBus比之于广播，观察者等方式最大的优势，他们使得建立结构良好组织紧密的通知系统成为可能。

   使用简单：Eventbus的Subscriber注册很是简单，调用eventBus对象的register方法便可，若是不想建立eventBus还能够直接调用静态方法EventBus.getDefault()获取默认实例，Subscriber接收到通知以后的操做放在onEvent方法里就好了。成为Publisher的过程更简单，只须要调用合适的eventBus(本身建立或者是默认的)的post方法便可。

   快速且轻量：观察者这种设计模式应该属于程序员的基本功，因为观察者的实现比较简单，所以性能上是三者中最好的，可是观察者难以控制通知的优先度，特别是一开始没有考虑优先度中途更高需求又加入优先度。另外观察者模式要求观察者在事件发生时在场才能收到通知，这就是的观察者有可能遗漏事件。客观来讲，这并不能算观察者的缺点，由于其余的方式每每也是这样，更加严谨的说法是观察者没有Eventbus优先级、粘滞事件的优势。但有一个缺点是观察者独有的，那就是观察者可能会形成接口的膨胀，特别是当程序要求大量形式各异的通知，而程序员没有作出良好的抽象时，代码中会包含大量的接口。