1.总体设计
一般来说我们都知道EventBus 使用起来非常的简单，但是如果不使用可不可以嘛，答案肯定是可以的，但是会增加很多额外的代码。普通的BroadCastReceiver 其实就可以满足最基本的需求。然后广播使用相对比较麻烦，会增加业务量。
说实话若不是EventBus的出现，BroadCastReceiver（广播）还是有一定的市场的，比较其中的设计思路有很多大同，都使用观察者模式见下图
观察者模式的核心是被观察者持有观察者的引用，观察者对被观察者的变化做出反应。
然后我们回来看一下EventBus设计的特点，一般来说我们常见的观察者与被观察者都是成对出现的，这样会减少代码的耦合，不会有很多观察者观察同一事件。在观察多个事件变化时候通常会有多个被观察者。然而EventBus将自身作为一个事件处理中心，故此EventBus翻译为事件总线，是非常恰当的。
EventBus自身作为一个被观察者，高度抽象了原有的各个被观察者，将原有的被观察者都集中一起，这样不要写很多重复的BroadCastReceiver代码，只需要在有事件变化的时候EventBus自身做出处理便可以。下面我们分析一下注册的流程。
2.Register 流程
其中维护两个特别的map 见下图，subscriptionsByEventType 是以事件为key，method和threadType以及subscrber（activity或者fragment）为构造的subscription作为value。（是不是典型的观察者模式，被观察者持有订阅者的引用😄）
typesBySubscriber是以subscriber为key，event作为value的 map。
注册的过程就是讲需要被观察的事件统一绑定到EventBus,一般来说事件是被观察的一方，所以activity或是fragment被设计成观察者。这样Eventbus 在收到事件/event 变化的时候会直接作出变化。
3.post 流程
首先从PostingThreadState 这个对象中取出发送信息的状态，其中包含一个事件的发送队列。
练的核心方法是postSingleEvent，那么我们看下这个方法
其中逻辑核心代码postSingleEventForEventType 故名思议就是根据不同事件类型事件/event发给其中的订阅了该事件的订阅者
通过event取出相应的订阅者列表。这时候代码是不是看起来很容易理解，前面我们说过的维护的map subscriptionsByEventType，这个时候就上场表演了，直接根据不同事件类型取出 所有订阅者subscriptions，其中subscription的构造就包括了其中的 subscriber （一般是activity /fragment）引用,方法，方法类型。这样直接执行便使得我们预先注册的onEvent方法生效了。
本次的EventBus大体就到这里了。总结起来就是activity（中方法）作为订阅者接收订阅事件通知，但是其实各种操作都在EventBus之中完成了调用。无论是订阅者还是事件发布者都只与EventBus有关。代码耦合度低，易于管理。
