Otto与EventBus框架比较

最近这几天经常在空闲时间看到了AOP编程，其实也就是对面向事件过程编程，一开始一直很难理解这个名次。不过看到Android正好有面向事件编程，程序解藕的开源库（Otto，EventBus）。所以闲暇时间就去看了一下这两个库的源码，写篇博客记录一下。其实很多时候，沉下心去做一件事就好了，收获会伴随着的。

用法

首先从用法上面来说，两个框架的用法本质上其实是差不多的：注册（register），发布事件（post），接收事件（onEvent…)，事件类，取消注册（unregister)。两个框架都包含这几样东西。另外Otto有个不同点是Otto有个Produce，生成事件的函数。它们的事件都包含sticky事件。下面分别介绍两个简单的使用API。

Otto

public class TestActivity extends Activity{

public static class TestEvent{
}

public void onCreate(Bundle b){
/*...*/

final Bus bus = new Bus();
bus.register(this)
findViewById(R.id.testpost).setOnClickListener(new View.OnClickListener(){
public void onClick(View view){
bus.post(new TestEvent());  //发布事件，消息
}
}
}

@Subscribe public void onTestEvent(TestEvent event){
// TODO process the event.响应TestEvent发出的时候，@Subscribe注释标记订阅。
}

@Produce public TestEvent produceAnswer(){
// Produce 表示产生事件
return new TestEvent();
}
}

EventBus

public class TestActivity extends Activity{

public static class TestEvent{
}

public void onCreate(Bundle b){
/*...*/

final EventBus bus = EventBus.getDefault();
bus.register(this);
findViewById(R.id.testpost).setOnClickListener(new View.OnClickListener(){
public void onClick(View view){
bus.post(new TestEvent());  //发布事件，消息
}
}
}

public void onEvent(TestEvent event){
// 以onEvent开头就是接受事件，订阅
}
}

上面仅仅是范例性的展示，除了这个简单的使用外，在Android比较关键的就是UI线程跟普通的线程。Otto会将处理的线程跟发送的线程保持一致，你也可以自己设置线程，Bus提供了一个那样的参数。而EventBus则可以自己指定线程，有四种方式，可以在onEvent后面加个后缀。比如:onEventMainThread。

另外一方面，EventBus也是提供了一个默认的单例EventBus（EventBus.getDefault())。我觉得这样能够更加方便地在Activity和Activity，Activity和Fragment解藕。

框架流程

本身这两个框架都不是很大，其核心代码都在接口类里面（Bus，EventBus）。这里就用流程的方式表示其具体结构。

Otto的框架流程



EventBus流程



需要特别指出的是。

1. Otto的订阅者运行的线程跟跟发送的线程是一致的，但是EventBus的会根据用户声明订阅的函数的时候指定的线程来去运行。

2. Otto只会查找当前类中的订阅者，跟Produce。但是EventBus会查找父类的订阅者。在post的时候，两个框架都会去查找Event的父类型，毕竟Event也是属于它的父类型类型。

3. 两个框架都采用了很多缓存，比如查找订阅者的时候。事件与对应的订阅者也是缓存着的。

个人看法

如果从源码上来看，两个框架都是比较简单的框架，代码量都比较小。使用起来的话，我觉得EventBus会更加适用一点。但是Otto更加简洁。

这两个框架通过事件驱动来将Activity，Fragment解藕。但是如果在一个Activity内部使用的话，我觉得效果可能不是很好，这个框架目的在于Android组件之间的解藕。

另外两种框架都是使用了一种先解析将订阅者缓存起来，提高查找速度。这个策略在其他的框架中也是使用的非常多。