本文通过原理分析和实测结果对EventBus和RxBus做详尽的对比，给大家在实际项目中选型做参考。
开始之前先提一下Otto：https://github.com/square/otto
当初Android上的事件总线系统是两强相争，老大是EventBus，老二就是Otto。在EventBus官方的性能测试代码中，只和Otto做了对比测试。这么重要的人物为了么这次没出场呢？是因为它已经停止开发了。Otto的主页上有这么一句话：
This project is deprecated in favor of RxJava and RxAndroid. These projects permit the same event-driven programming model as Otto, but they’re more capable and offer better control of threading.
If you’re looking for guidance on migrating from Otto to Rx, this post is a good start.
该项目已被RxJava和RxAndroid取代。Rx类项目允许与Otto类似的事件驱动编程模型，而且能力更强，操作线程更方便。
如果你正在寻找从Otto迁移到Rx的指导，这个帖子是个很好的开始。
看，Otto临死给后起之秀RxBus投了票，所以我们只需对比EventBus和RxBus。先扯一下Bus这个词，它可以是巴士，也可以是总线。但是细一想，其本质含义都一样，都是把线路各处人或事件，经过bus，运送到他们想要去的地方。所以英语用同一个词表达这两个意思，很有道理。我们可以理解巴士就是一个运人的总线:)
开始对比之前，还是同样的方法，我们先考虑一下，一个完美的事件总线应该具备哪些功能？
- 容易订阅事件：事件订阅者只要声明自己就好了，当事件发生时自然会被调到。订阅和取消可以方便绑定到Activity和Fragment的生命周期上。
- 容易发送事件：事件发送者直接发送就好了，其他的事都不管。
- 方便的切换线程：有些事必须主线程干，有些事必须非主线程干，所以这个还是要说清楚。
- 性能：随着应用的成长，总线可能会被重度使用，性能一定要好。
我们的需求就是这么简单。
EventBus
EventBus是个明星项目，github上的star超过10000，网上的分析文章很多。这里只说一下大原理，方便我们分析。详细内容可以参考这个文章。EventBus官网上说用EventBus只要三步：定义事件，创建订阅者并订阅，发送事件。我们也从这几个步骤入手。
定义事件
每个事件是一个新的类，类中可以带参数，什么都不带，只是一个空的类定义，也没问题。这个设计虽然会大幅增加类的数量(我们的项目中就有100多个event类)，但是清晰易懂，相比在类中定义事件类型变量的方法，使用起来方便很多。创建订阅者
当某个事件发生时，订阅这个事件的订阅者就要被执行。所以创建订阅者时除了要完成函数本身，还要声明订阅的是哪个参数(函数参数)，并声明线程要求、是否粘性等，EventBus中这些信息通过注解声明，使用十分方便。至于如何提取和处理这些信息这样的脏活累活，EventBus都留给了自己。
@Subscribe(threadMode = ThreadMode.MAIN, sticky = true)
public void onEventMainThread(StateEvent event) {
Log.d(TAG, "StateEvent is emitted");
}
- 订阅、取消订阅
eventBus.register(this);
eventBus.unregister(this);
在有订阅者的类中，随时调用register()，就把类中的所有订阅者都激活了。随时调用unregister()，就都解除订阅了。这个结合Android中Activity和Fragment的生命周期使用很方便。刚才说的脏活累活就是register()来完成的。它也是EventBus中最复杂的部分。详细分析请参见其他文章，这里只说原理。register()要做这么几件事：
- 通过注解把类中的所有订阅者和订阅信息提取出来，这里有很多过滤条件保证提取的正确性。
- EventBus中有两个映射表，subscriptionsByEventType中存放所有event和对应的订阅者，typesBySubscriber中存放每个订阅者对应的事件。提取出来的订阅者和信息就被存进了这两个表里。
private final Map<Class<?>, CopyOnWriteArrayList<Subscription>> subscriptionsByEventType;
private final Map<Object, List<Class<?>>> typesBySubscriber;
- 发送事件
所有的的poster被放在3个队列中，mainThreadPoster、backgroundPoster、asyncPoster。这3个队列是用链表实现的，让poster在各自的线程排队，等候处理。如果是POSTING类型的事件，就直接执行了，不用排队。
post事件时，在前面的映射表中可以用事件查到所有此事件的订阅者，把每个订阅者执行一遍。执行时根据线程要求做处理。
- 如果是POSTING，就把函数反射出来直接执行。
- 如果是MAIN，就直接执行，或者放到mainThreadPoster队列中去。
- 如果是BACKGROUND，或者直接执行，或者放到backgroundPoster队列中去。
- 如果是ASYNC，放到asyncPoster队列中去。
对应的线程会执行这些poster。
- EventBus加速黑科技
上面就是EventBus的主要功能了。EventBus中很多代码是为了防止出错和性能优化。例如EventBus中大量使用了池来减少常用元素的创建和删除。前面提到的脏活累活有一部分放到编译期完成，例如这篇文章中提到的，订阅者信息在编译期就都提取出来了，生成一个静态的SUBSCRIBER_INDEX，里面存放了类名索引的类中的订阅者信息，包含订阅的事件名、订阅者方法名、线程、是否粘性、优先级。
回过头来看我们的评价指标：
- 容易订阅事件：完全合格。
- 容易发送事件：完全合格。
- 方便的切换线程：完全合格。
- 性能：完全合格。
那么问题来了，EventBus使用方便，性能优化到位，各方面都很好，为什么会遭到RxBus的挑战，甚至可能被替代呢？
RxBus
希望前面的介绍把EventBus的原理说清楚了。下面我们来看看RxBus。它不是一个库，而是一个文件，最短实现只有短短30行代码。RxBus本身不需要过多分析，它的强大完全来自于它基于的RxJava技术。响应式编程(Reactive Programming)技术这几年特别火，RxJava是它在Java上的实作。RxJava天生就是类似sub/pub的观察者模式，而且很容易处理线程切换。而EventBus做的最重要的两件事就是事件订阅和线程控制。所以才有了RxBus区区30行代码就敢挑战EventBus的老大地位。
从 Kaushik Gopal 2014年12月在blog中一次提出RxBus，不断有人在完善RxBus。我在实际使用中也对原始的RxBus进行了扩充，解决易用性和性能的问题。
由于RxJava已经解决了订阅和线程切换问题，RxBus尚未解决的，也是重点需要解决的是事件分发的效率问题。为此我在AndroidPlayGround中复用EventBus性能测试代码，对EventBus和RxBus做了性能测试。具体参见AndroidPlayground。测试中可以明显发现RxBus效率随订阅者增多而成比例下降。
暂时的结论
- 如果你的项目中已经开始使用EventBus，没有必要特意换用RxBus。
- 如果你的项目计划引入RxJava，并认为统一风格很重要，启用RxBus，抛弃EventBus没有问题。但是请了解RxBus的问题，并关注RxBus的进展，最好能用Rx的方式解决这个问题。
RxBus也在不断进化中，我相信随着大家的努力，我们能够解决RxBus中的问题，但是目前，RxBus在订阅者数量很大的情况下，性能下降非常明显是个事实。当RxBus有了好的解决方案，我会第一时间更新上来。
