虽然在Android开发具有某些事件驱动的特性，但它还远不是纯粹的事件驱动架构。这算是好事还是坏事呢？正如在软件开发领域中任何事情一样，想回答它并不容易：这取决于具体情况。
首先我们来给事件驱动编程下一个定义。事件驱动编程是一种编程范式，程序的执行流程是由动作（actions，例如用户交互，其他线程发送的消息等等）触发的事件（event）决定的。在这个意义上，Android是部分事件驱动：我们都知道的onClick监听器或者Activity的生命周期，都是应用中由动作触发的事件。我为什么说它不是纯粹的事件驱动系统呢？默认情况下，每个事件被绑定在特定的controller上面，因此很难在其他地方使用该事件（例如onClick事件是定义为View服务的，因此它的使用范围很有限）。
等一下，你在讨论的是一个全新的编程范式，使用这个新框架或者方法总会带来成本的，那么它能带来什么好处呢？答案是肯定的，为了说明它，我将首先说一说传统Android开发存在的一些限制。
很多情况下我们工程代码会很容易演变成下图所示的结构：
Activities可以和Fragments通信，Fragments可以给其他的Fragments和Services发送消息。各个组件之间耦合严重，修改代码的时间代价昂贵。这经常导致产生样板代码，例如需要在不同层之间传播实现了回调函数的接口，你应该知道我想表达的意思。由于代码量的增加，可维护性和良好的软件工程实践随之降低。
那么事件驱动编程如何使用呢？下面让我们来看看另一种系统架构设计：
概念上讲，上面的系统具有一个Event Bus，不同的实体订阅这个Event Bus，要么发送事件，要么监听事件－分别作为生产者或者消费者。任何订阅者可以在不知道业务逻辑的情况下执行动作。想象一下，想象某种具体的可能性：一个Fragment可以在不知道任何操作背后业务逻辑的情况下，只需要收到一个事件，就可以重新执行渲染并更新屏幕显示。想象一下代码解耦并得到一个简洁的，划分良好的架构的可能性。
Android支持这种编程范式吗？好吧，部分支持。就如上面提到的，Android SDK本身提供了一个简化的事件处理技术，但我们想要更多的支持。在这里有一些名字我想提一下：
EventBus，出自greenrobot。这个函数库专为Android而优化过，并具有某些高级特性例如线程传递和订阅者优先级。
两个函数库都试用过，我更喜欢EventBus。Greenrobot声称EventBus在性能上比Otto更好，并提供了很多额外的特性。
下一篇文章将讲解在EventBus中如何实现基本的功能。