手记

Android事件驱动编程(一)

虽然在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而优化过,并具有某些高级特性例如线程传递和订阅者优先级。

  • Otto,出自Square。起初是从Guava fork过来的,后面经过发展,已经在Android平台上进行了完善。

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

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

原文链接:http://www.apkbus.com/blog-705730-60443.html

0人推荐
随时随地看视频
慕课网APP