EventBus和RxBus基本原理

在介绍两者的基本原理之前，我们首先应该了解一个完美的事件总线应该具备哪些功能？

1.容易订阅事件：事件订阅者只要声明自己就好了，当事件发生时自然会被调到。订阅和取消可以方便绑定到Activity和Fragment的生命周期上。

2.容易发送事件：事件发送者直接发送就好了，其他的事都不管。

3.方便的切换线程：有些事必须主线程干，有些事必须非主线程干，所以这个还是要说清楚。

4.性能：随着应用的成长，总线可能会被重度使用，性能一定要好。
我们的需求就是这么简单。

EventBus是个明星项目，github上的star超过10000，网上的分析文章很多。这里只说一下大原理，方便我们分析。详细内容可以参考http://yydcdut.com/2016/03/07/eventbus3-code-analyse/。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效率随订阅者增多而成比例下降。