Android事件驱动编程（一）

虽然在Android开发具有某些事件驱动的特性，但它还远不是纯粹的事件驱动架构。这算是好事还是坏事呢？正如在软件开发领域中任何事情一样，想回答它并不容易：这取决于具体情况。

首先我们来给事件驱动编程下一个定义。事件驱动编程是一种编程范式，程序的执行流程是由动作（actions，例如用户交互，其他线程发送的消息等等）触发的事件（event）决定的。在这个意义上，Android是部分事件驱动：我们都知道的onClick监听器或者Activity的生命周期，都是应用中由动作触发的事件。我为什么说它不是纯粹的事件驱动系统呢？默认情况下，每个事件被绑定在特定的controller上面，因此很难在其他地方使用该事件（例如onClick事件是定义为View服务的，因此它的使用范围很有限）。

等一下，你在讨论的是一个全新的编程范式，使用这个新框架或者方法总会带来成本的，那么它能带来什么好处呢？答案是肯定的，为了说明它，我将首先说一说传统Android开发存在的一些限制。

很多情况下我们工程代码会很容易演变成下图所示的结构：

那么事件驱动编程如何使用呢？下面让我们来看看另一种系统架构设计：

概念上讲，上面的系统具有一个Event Bus，不同的实体订阅这个Event Bus，要么发送事件，要么监听事件－分别作为生产者或者消费者。任何订阅者可以在不知道业务逻辑的情况下执行动作。想象一下，想象某种具体的可能性：一个Fragment可以在不知道任何操作背后业务逻辑的情况下，只需要收到一个事件，就可以重新执行渲染并更新屏幕显示。想象一下代码解耦并得到一个简洁的，划分良好的架构的可能性。

Android支持这种编程范式吗？好吧，部分支持。就如上面提到的，Android SDK本身提供了一个简化的事件处理技术，但我们想要更多的支持。在这里有一些名字我想提一下：

两个函数库都试用过，我更喜欢EventBus。Greenrobot声称EventBus在性能上比Otto更好，并提供了很多额外的特性。

下一篇文章将讲解在EventBus中如何实现基本的功能。