它是一个基于观察者模式的事件发布/订阅框架，开发者可以通过极少的代码去实现多个模块之间的通信，而不需要以层层传递接口的形式去单独构建通信桥梁。从而降低因多重回调导致的模块间强耦合，同时避免产生大量内部类。它拥有使用方便，性能高，接入成本低和支持多线程的优点，实乃模块解耦、代码重构必备良药。
集成EventBus需要三步：
第一步：定义event；
第二步：准备订阅者，包括注册和取消注册，及接收事件的方法等；
第三步：发布事件；
EventBus的线程模式有四种：POSTING，MAIN，BACKGROUND，ASYNC；
POSTING：这种模式就是eventBus默认的模式，我们在使用的时候不需要再订阅者的方法的注解后面加任何东西（选择模式），但是这种只能在同一个线程中接收，也就是说，如果是在主线程中发布消息就只能在主线程中接收消息，如果是在子线程中，那么也只能在相同的子线程中去接收消息；
MAIN：这种模式保证了订阅者指定的那个接收方法肯定要主线程中执行，可以放心的在里面执行更新UI操作。无论发布者是在主线程中还是在那一条子线程中发布消息，这边接收的都在主线程中；
BACKGROUND：这种模式无论发布者是在主线程或者是那一条子线程中发布消息，接收的肯定是在子线程中，并且是这样理解：如果是在主线程中发布消息，那么就会随机开辟一条子线程来接收消息。如果是在子线程中发布消息，那么就会在相同的子线程来接收消息；
ASYNC：这种模式是无论你在那个线程中发布消息都会在不同的线程中接受消息。如果你在主线程中发布消息，就会随机的开辟一条子线程来接收消息；如果是在子线程中发布消息，就会开辟一条不同的子线程来接收消息。
EventBus的粘性事件：
粘性事件的发送：
粘性事件的接收：（需要设置sticky为true，还需要指定线程模式，因为 默认的线程模式为posting）
获取和删除手动粘性的事件：
EventBus的priority事件优先级（优先级越高优先获得消息）：
当多个订阅者（Subscriber）对同一种事件类型进行订阅时，即对应的事件处理方法中接收的事件类型一致，则优先级高（priority 设置的值越大），则会先接收事件进行处理；优先级低（priority 设置的值越小），则会后接收事件进行处理。除此之外，EventBus也可以终止对事件继续传递的功能：
EventBus的用户索引（参考：索引）：
相信对于索引这个词大家不会陌生，很多地方都有用到，那么为什么EventBus会引进索引这个东西，大家都知道EventBus的功能是通过反射机制获取观察者（订阅者）方法来实现的，而反射本身对性能的损耗比起一般的方法来说要大很多，具体慢多少，你们可以写一个程序测试下，大概50倍左右（当然对于CPU的运行速度，没有你想象中夸张）。
索引的生成：
第一步：Using annotationProcessor:
第二步：Using android-apt
第三步：How to use the index
链接：参考
