尽管Android开发中包含一些事件驱动的特性，但是离纯事件驱动架构还很远。这是好是坏？就像软件开发中的所有问题一样，这个答案也不简单：看情况。

首先，我们来定义一下事件驱动开发。这个编程范型中，执行流由动作触发的事件决定（比如交互，其他线程的消息等）。这个意义上，Android是部分事件驱动的：我们可以认为onClick监听器或Activity生命周期（它们是事件）可以触发应用中的动作。为什么不说它是一个纯事件驱动系统呢？默认情况下，每个事件都绑定到一个特定的控制器，除此之外很难进行其他操作（比如，为视图定义的onClick，作用域是有限的）。

等会，你在说一个新的编程范型。采用框架或方法学总会有成本，它能带来好处吗？是的，我想展示给大家一些传统Android开发的限制。

很多情形下，容易造成下图所示的结构：

Activity可以跟Fragment通信，Fragment可以向Fragment和Service发送消息。组件之间耦合紧密，对其进行更改代价会很高（*）。这样一来，修改往往会涉及到样板代码、实现了在不同层之间回调和通信的函数功能的接口……你应该知道我要说什么了。随着代码量的增长，可维护性和软件工程的规范性都在下降。

如何在这里应用事件驱动编程？下面是值得提倡的一种系统：

概念上，这个系统包含一个事件总线（event bus）。不同的实体订阅事件总线，派发或监听事件 — 它们分别是生产者和消费者。任何订阅者都可以在不了解内部逻辑的情况下执行一个动作。考虑一下特殊的情况。：Fragment重复渲染并更新屏幕可以忽略操作背后的逻辑，只要知道事件发生了就行了。想像一下通过这种系统降低代码耦合性，使架构简洁、分离的可能性。

Android支持这个范型吗？部分支持。上文提到过，SDK原生提供了一个事件处理技巧的子集，但是我们希望能走的更远。这里有一些我想提到的概念：

• greenrobot的EventBus。这个库为Android进行优化过，包含一些高级特性，比如分发线程和订阅者优先级。
• Square的Otto。它原来是Guava的一个分支，它不断演化并且为Android平台进行了改进。

试过之后，对于Otto，我更喜欢EventBus。Greenrobot声明EventBus性能比对手更好，提供了很多附加特性。

下一篇文章将会探索如何在EventBus中实现基本功能。

（*）当表达“用时很多”时，我故意使用“代价很高/expensive”这个词。经济学中的术语通常更有效。