GreenrobotEventBusvsOttoBus

何为EventBus

说到EventBus就不得不提下观察者模式，这个设计模式相信大家都很熟悉了，在这个模式里有2个方面，一个是被观察者，也就是产生事件的一方，另一个是观察者，也就是消费（响应）事件的一方，观察者模式做的事情就是将这2者联系起来，好实现当某个事件发生时，对此事件的感兴趣的观察者能持续得到通知，这样就建立了一种订阅的关系，当然也可以随时取消这种关系。EventBus总起上来说，做的也是同样的事情，只是将这个模式更加发扬光大了，从而在使用方式上更加简单、方便。

在Android里面EventBus时常用来在各模块之间解耦，比如你有一个密码输入框的View，此View在用户输完密码的时候就自动关闭了，于此同时它会post一个PwdInputDoneEvent，然后它的任务就完成了。在这个场景里我们看到，密码输入框不知道，也根本不需要知道谁会处理这个事件、怎么处理，这也符合设计模式的原则：单一职责、最小知道原则。接下来可能我们有个Activity会对这个事件感兴趣，它会在收到这个事件的时候进行下一步的处理。在这里View和Activity之间是互相不知道彼此的，而他们之间的这种订阅关系就是被本文的主角EventBus来维护的。可以看出EventBus既能让你的各个模块之间松散耦合，同时又能高效的彼此通信。

当下在Android世界里比较知名的EventBus相关的库有2个，分别是Greenrobot EventBus和Otto Bus，接下来我们来简单对比下。

两者的基本用法

两者在用法方面也是惊人的相似，以下是大体的步骤：

1. 定义事件类；
2. 在观察者（处理者）类中定义@subscribe public方法，并注册此类的对象到EventBus中；
3. 在合适的地方post相应的事件；
4. 最后不需要的时候，记得unregister观察者；

上面的步骤中，忽略了EventBus的创建过程，在Greenrobot中你可以简单的调用EventBus.getDefault()来返回一个全局公共的实例；在Otto中，你需要利用单例模式创建一个全局的Bus实例，Bus对外暴露了几个公共的ctor，选择一个适合你的。

下面是官方的步骤，供参考：
Greenrobot官方步骤
Otto官方步骤

两者差别

• 订阅方法的不同
  Otto从一开始对此的做法就是采用Java的annotation机制@subscribe来实现的，到现在也没有变化；
  Greenrobot一开始由于考虑到annotation(反射相关)在Android上存在较严重的性能问题，所以在v3之前采用的方式是约定方法名，比如大家熟悉的onEvent，onEventMainThread，onEventBackgroundThread；但从v3开始，时间也过去了好几年了，Android市场的版本分布也发生了比较大的变化，当年的瓶颈、阻碍已经变的不是那么突出了，再加上greenrobot自己搞了个加速的build期技术，所以他开始拥抱@subscribe了，具体的细节可以参考以下链接：
  http://greenrobot.org/release/eventbus-3-release-annotations/
  http://greenrobot.org/eventbus/documentation/subscriber-index/
  http://stackoverflow.com/questions/7417426/why-are-annotations-under-android-such-a-performance-issue-slow
  https://code.google.com/p/android/issues/detail?id=7811
  https://github.com/greenrobot/EventBus/pull/130
  https://github.com/greenrobot/EventBus/issues/126

如果你使用的是v3，那么方法名可以随便取了，不用再像v2时代那样了。

• 观察者方法执行的线程不同
  如果是通过Otto，默认你创建的Bus(比如通过Bus bus = new Bus())，只能在UI线程使用，即register、post、unregister这些方法必须在UI线程中调用，否则会抛异常。当然Otto库也通过ThreadEnforcer接口开放了自定义的能力，使用方可以在enforce(Bus bus)方法中实现自己的逻辑(比如允许任意线程、特定线程等等)，并在创建Bus实例的时候提供进去。到底在哪个线程中执行，说白了就是其post方法在哪个线程调用，观察者方法就在哪个线程中执行。

而如果是v3的EventBus，它支持更细粒度的配置化，在新引入的subscribe annotation中就可见一斑，代码如下：

@Documented
@Retention(RetentionPolicy.RUNTIME)
@Target({ElementType.METHOD})
public @interface Subscribe {
ThreadMode threadMode() default ThreadMode.POSTING;
/**
* If true, delivers the most recent sticky event (posted with
* {@link EventBus#postSticky(Object)}) to this subscriber (if event available).
*/
boolean sticky() default false;
/** Subscriber priority to influence the order of event delivery.
* Within the same delivery thread ({@link ThreadMode}), higher priority subscribers will receive events before
* others with a lower priority. The default priority is 0. Note: the priority does *NOT* affect the order of
* delivery among subscribers with different {@link ThreadMode}s! */
int priority() default 0;
}


EventBus现在可以支持在每一个事件上配置线程策略、sticky与否、事件优先级，这些都是属于比较高级的特性。

另外它默认是支持Event & Subscriber inheritance的，而Otto自称为了性能考虑是不支持这些的，只是在当前类中定义的，不会在类继承链上往上找。

In EventBus, the object oriented paradigm apply to event and subscriber classes. Let’s say event class A is the superclass of B. Posted events of type B will also be posted to subscribers interested in A. Similarly the inheritance of subscriber classes are considered.

• post方法执行的不同
  在Otto中，此方法是这样work的：

Posting to the bus is a synchronous action so when program execution continues it is guaranteed that all subscribers have been called.

翻译下就是：post是个同步操作，也就是说此方法返回的时候，所有感兴趣的观察者方法都已经被执行完毕了。你可以这样理解：当你调post的时候，实际就相当于立马调用了那些对此事件感兴趣的处理方法。

EventBus对此的处理稍微复杂些，可同步可异步，要视情况而定，说再多不如直接看代码来的直截了当，如下：

private void postToSubscription(Subscription subscription, Object event, boolean isMainThread) {
switch (subscription.subscriberMethod.threadMode) {
case POSTING:
invokeSubscriber(subscription, event);
break;
case MAIN:
if (isMainThread) {
invokeSubscriber(subscription, event);
} else {
mainThreadPoster.enqueue(subscription, event);
}
break;
case BACKGROUND:
if (isMainThread) {
backgroundPoster.enqueue(subscription, event);
} else {
invokeSubscriber(subscription, event);
}
break;
case ASYNC:
asyncPoster.enqueue(subscription, event);
break;
default:
throw new IllegalStateException("Unknown thread mode: " + subscription.subscriberMethod.threadMode);
}
}


Otto Bus.post的工作方式只是EventBus默认(threadMode == POSTING)的情况，但EventBus还支持别的threadMode，这时候当post方法结束的时候，对此事件的处理方法可能还没有执行。

总结

比较小的项目或者说Otto的Bus基本上可以满足你需求的时候，建议采用Otto，毕竟库小，使用简单；慢慢地如果你需要更多高级特性，希望支持更多的threadMode，那么你可以考虑迁移到EventBus，另外这2个库的性能据说也有些差别，具体可以看看greenrobot给的对比结果。

最后说下对源码的理解，个人觉得最好的理解方式就是在自己的demo工程里把对应的库用起来，然后挂个断点自己一步步单步感兴趣的库代码，动起来看代码还是比较容易理解的。强烈建议有精力的话看看这2个库的实现，不论是从设计还是实现都还是很赞的，值得细细品味。