1.引言
事件总线是对发布-订阅模式的一种实现,它是一种集中式事件处理机制。
允许不同的组件之间进行彼此通信而又不需要相互依赖，达到一种解耦的目的。
事件总线处理流程
Pulishers -> Events -> Event Bus -> Events -> Subscribers
2.事件本质
2.1 事件是由事件源和事件处理组成
事件源 发出事件的对象
事件处理器 对事件的处理
2.2 发布订阅模式
定义对象间一种一对多的依赖关系，使得每当一个对象改变状态，则所有依赖于它的对象都会得到通知并被自动更新。
发布订阅模式主要有两个角色：
发布方（Publisher）：也称为被观察者，当状态改变时负责通知所有订阅者。
订阅方（Subscriber）：也称为观察者，订阅事件并对接收到的事件进行处理。
发布订阅模式有两种实现方式：
简单的实现方式：由Publisher维护一个订阅者列表，当状态改变时循环遍历列表通知订阅者。
委托的实现方式：由Publisher定义事件委托，Subscriber实现委托。
总的来说，发布订阅模式中有两个关键字，通知和更新。
被观察者状态改变通知观察者做出相应更新。
目的 当对象改变时需要通知其他对象做出相应改变的问题。
3. 实现发布订阅模式
3.1 事件源统一
事件源应该至少包含事件发生的时间和触发事件的对象。事件源统一
3.2 事件处理器
事件处理要与事件源进行绑定
4. 实现事件总线
目的：建立一个集中式的事件处理机制，且各个模块之间相互不产生依赖。
4.1 分析问题
事件发布方定义事件委托
事件订阅方定义事件处理逻辑
显示的订阅事件
问题：
事件发布方和事件订阅方还存在着依赖（体现在订阅者要显示的进行事件的注册和注销上）。主要是以下三个方面的问题。
如何精简步骤？
如何解除发布方与订阅方的依赖？
如何避免在订阅者中同时处理多个事件逻辑？
精简步骤，通常会提取共性。也就是我们针对事件源和事件处理提取出来的两个接口。
想要解除依赖，那就要在发布方和订阅方之间添加一个中介。
想要避免订阅者同时处理过多事件逻辑，那我们就把事件逻辑的处理提取到订阅者外部。
4.2 解决问题
4.2.1. 实现IEventHandler
避免在订阅者中同时处理多个事件逻辑
方案：针对不同的事件源IEventData实现不同的IEventHandler
4.2.2. 统一注册事件
根据事件源来区分事件，然后定义相应的事件处理，最后通过反射来进行事件的统一注册。
4.2.3. 解除依赖
Event Bus就相当于一个介于Publisher和Subscriber中间的桥梁。它隔离了Publlisher和Subscriber之间的直接依赖，接管了所有事件的发布和订阅逻辑，并负责事件的中转。
Event Bus 分析
如果EventBus要接管所有事件的发布和订阅，那它则需要有一个容器来记录事件源和事件处理。那又如何触发呢？有了事件源，我们就自然能找到绑定的事件处理逻辑，通过反射触发。
事件总线定义的方法
事件总线主要定义三个方法，注册、取消注册、事件触发。还有一点就是通常会在构造函数中通过反射去进行事件源和事件处理的绑定。
5. 小结
- 事件总线维护一个事件源与事件处理的映射字典；
- 通过单例模式，确保事件总线的唯一入口；
- 利用反射完成事件源与事件处理的初始化绑定；
- 提供统一的事件注册、取消注册和触发接口。