EventBus主要用来消息/事件的传递，却能实现组建之间的解耦。对比其他的消息传递：
- ** 使用监听器接口（Listener Interface）：**
1、一个实现了监听器接口的类，必须把它自身注册到它想要监听的类中去。这就使监听与被监听之间保持强关联关系，而且不利于单元测试。
2、对比：而EventBus则起到了桥梁作用，想要监听什么对象/事件，在EventBus中去注册（register(Object)）；想要发送某事件的消息，使用EventBus去post（post(Event)）。这样便通过EventBus实现了监听者和被监听者的解耦。
- ** 使用广播（BroadCastReciver）： **
1、使用广播的代码臃肿（还有一种说法：它们内部的实现都需要IPC，单从传递效率上来讲，可能并不太适合上层的组件间通信），而且Intent传递数据时，在编译时并不能检查出所设的extra类型与收到时的类型一致。所以一个很常见的错误便是你或者你团队中的其他人改变了Intent所传递的数据，但忘记了对全部的接收器（receiver）进行更新。这种错误在编译时是无法被发现的，只有在运行时才会发现问题。
2、对比：使用EventBus所传递的消息/事件，是我们自己定义的Event类，由于接受方和发送方都是与这些类实例打交道，所以所有的数据都可以进行类检查，这样任何由于类型不一致导致的错误都可以在编译期被发现。
- startActivityForResult（）和onActivityResult（）方法：
1、传统的Activity间的消息传递便是通过
startActivityForResult和onActivityResult，会产生较多的状态或逻辑判断，而且Intent或Bundle传值还得检测类型，容易发生错误。更复杂些的场景，比如A启动B，B启动C，在C中用户的操作需要更新A和B，那么判断逻辑就更麻烦了。
2、对比：使用EventBus可以很简单地解决以上问题，能够摆脱Activity间通信使用onActivityResult的方法，同样可以摆脱Fragment间通信通过宿主Activity使用Interface的方式，还有Fragment和Activity间通信使用Interface的方式。
EventBus可以用来处理异步并发消息。
Android中有很多执行异步操作的方法：AsyncTask、Loader、Executor等。
** AsyncTask **
AsyncTask被设计成为一个工具类，要求我们尽量执行一些短小的操作，如果需要在线程中执行较长时间的任务，那么建议直接使用java.util.concurrent包中提供的各种API，如Executor、 ThreadPoolExecutor以及FutureTask。** Loader **
Android 3.0引入了Loader，来解决Activity/Fragment生命周期的问题，但Loader仍然要维持Activity/Fragment中的callback接口LoaderManager.LoaderCallbacks（其中包含onCreateLoader()、onLoadFinished()和onLoaderReset方法），在onCreateLoader()中要实现自己的DataLoader，可以继承抽象类AsyncTaskLoader<T>拓展泛型并覆写其loadInBackground()方法。** EventBus **
EventBus中内置了并发处理机制，既支持工作线程向UI线程发送消息/事件，也支持从主线程发消息，工作线程来处理响应。
1、onEvent（T event）对应ThreadMode.PostThread。该方法的执行和事件发送者在同一个线程中，适用于对是否在主线程执行无要求的情况，但post线程为主线程，则不能有耗时操作。
2、onEventMainThread(T event)对应ThreadMode.MainThread。在主线程执行，不论事件从哪个线程发送过来。
3、onEventBackgroundThread(T event)对应ThreadMode.Background Thread如果发送事件的线程不是UI线程，则运行在该线程中。如果发送事件的是UI线程，则它运行在由EventBus维护的一个单独的线程中。多个事件会同步地被这个单独的后台线程所处理。适用于轻微耗时的操作，比如读写数据库。
4、onEventAsync（T event）对应ThreadMode.Async。运行在单独的工作线程中，不论发送事件的线程是否为主线程。跟BackgroundThread不一样，该模式的所有线程是独立的，因此适用于长耗时操作，例如网络访问。
这样通过EventBus就可以不用维护引用和回调接口，从而实现组件间的消息/事件传递。
EventBus处理网络请求并通知UI
因为EventBus提供了多种ThreadMode，我们完全也可以使用EventBus来处理耗时操作。比如在打开一个Activity时，我们暂称为“A”，它会从服务端获取数据并进行显示，我们首先注册EventBus；然后定义onEventMainThread(Response data)方法，接收请求到的数据并刷新界面；另外，还需要调用post(Request rq)来通知我们定义的RequestManger来访问网络并请求数据，当然RequestManger注册并定义了onEventAsync(Request rq)方法，我们在该方法中请求网络数据并最后调用EventBus.post(Response data)方法去通知“A”刷新UI。
EventBus默认创建了线程池为Executors.newCachedThreadPool()，Async和Background模式下都是使用该线程池执行任务，当然我们可以根据情况去定义自己的ExecutorService。
EventBus的一些局限（因为3.0版本有较大的更新，因此以下有些观点是陈旧的，已做更正）
1、EventBus是采用反射的方式对整个注册的类的所有方法进行扫描来完成注册，当然会有性能上的影响。[3.0中EventBus提供了EventBusAnnotationProcessor注解处理器来在编译期通过读取@Subscribe()注解并解析、处理其中所包含的信息，然后生成java类（默认EventBusIndex类在build文件夹中）来保存所有订阅者关于订阅的信息，这样就比在运行时使用反射来获得这些订阅者的信息速度要快］
2、EventBus必须定义以onEvent开头的几个方法，代码中语境比较突兀，且有可能会导致拼写错误。［EventBus 3.0支持注解方式，而且支持注解中设置ThreadMode、sticky事件、优先级］，like this：
@Subscribe(threadMode = ThreadMode.BACKGROUND, sticky = true, priority = 100)
public void test(String str) {
}
3、用EventBus来处理网络请求太过简单粗暴，考虑使用Volley处理网络请求，volley支持请求缓存、请求队列和请求优先级，代码的结构清晰、扩展性强，很适合客户端轻小的请求。关于Volley可以看我的 Volley Demo和源码注释
更好的解决方案（推荐使用EventBus 3.0）
1、Otto同样是事件总线框架(Otto Demo和源码注释)，满足消息/事件传递的同时，也实现了组件间的解耦。跟EventBus一样，采用反射的方式对注册类中的所有方法进行扫描和调用。
2、Otto不同于EventBus的是，它使用注解的方式（@Subscribe、@Produce）来标注方法，这一点比EventBus优雅。
3、Otto没有像EventBus那样强大实现了4种ThreadMode，Otto中在接口ThreadEnforcer以及内部的实现域ANY和MAIN，在MAIN内部有一个是否是主线程的检查，而ANY不做任何检查的事情。因此Otto更多的使用场景是在主线程中，相对是轻量级的。
4、综合上面EventBus处理网络请求的缺陷，因此我觉得比较合理的方案是，使用Volley+Otto组合的方式来处理异步网络请求和UI更新，以及组件间的消息传递。
5、EventBus 3.0版本支持注解以及在编译期扫描事件订阅方法，性能上有较大提升，因此推荐使用EventBus 3.0版本。（这里有EventBus的官方性能测试对比报告：https://github.com/greenrobot/EventBus/blob/master/COMPARISON.md）
更多可以参考我的：EventBus Demo和源码注释
