RxBus对比EventBus

本文通过原理分析和实测结果对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有了好的解决方案，我会第一时间更新上来。

原文出自简书：http://www.jianshu.com/p/669eda5dc5a4