为什么你应该停止使用 EventBus?
文中的 EventBus 多指事件总线这种设计模式,而非 EventBus 这个具体的类库。
我经常看到 EventBus 被作为一种通用模式应用在 Android 开发中。Otto 和 EventBus 这样的类库经常被用来省去编写不同层之间来封装代码的模板类。尽管 EventBus 刚开始看起来的确带来了方便,但是很快这些纠缠的事件会被弄成一堆乱麻,很难跟踪更别说调试。
EventBus 通常被宣扬可以降低模块之间的耦合度,但是,事实上带给你的是降低耦合度带来的混乱和困惑。
嵌套的事件
一个常见的弊端是处理嵌套的事件。不要在事件订阅者里面发布事件,这看起来很容易避免,但是经常会不容易理解。一个订阅者很可能会通过调用其他的方法来间接地抛出其他的事件。这样事件会纠缠成一个复杂地难以置信的球,很难进行调试。
Facebook 的 Flux 框架是另外一个事件驱动的设计框架,但是它 明令禁止发送嵌套事件 。希望 Otto 和 EventBus 未来能够检测嵌套事件。
以同步的方式处理生产者
(我不认为这跟 GreenRobot 的 EventBus 有关系。)
这是另外一个在大代码集中很难处理的常见模式。经常在许多 Activity 和 Fragment 里面,我们假定事件可以立即被 EventBus 里面的订阅者进行处理。它们会设置一个基于事件的属性,以假定这个属性不会为空的方式在其他的生命周期函数中使用。
当你这样做的时候,你对于事件的发送传递作了一些大胆的假设,这些所有的假设并不能都被证明一定是这样或者是明确地被 API 备注,这些假设都是不可靠的。
当你重构改变这些处理事件的代码的时候会发生什么呢?很可能重构处理事件代码的那个人进行实现的时候并不知道你的这个假设。
问题的根本在于生产者是否处理好一下两个方面:
- 要求把数据作为依赖。
- 处理好数据未获取到时情况。
在事件处理中组件可以把事件数据作为依赖,仅仅是作为是否可用的依赖。这需要一个随时可用的依赖构造函数或者是通过依赖注入注入数据(这个可以继续深入讨论)。
如果还没有请求到任何数据,组件需要处理好这种还未得到信息的情况(对于 UI 组件通常是处理等待加载的情况)。
其他选择
没有类库或者工具会毫无代价的处理好这些问题,但是一些工具或者设计模式会鼓励你使用正确的处理方式来处理这些问题。
正确地使用 EventBus 可能会避免这些问题。然而,相比大多数其他工具更鼓励实用的做法。尽管使用简单的监听类会增加一些额外的代码,可能会让业务的处理更明确。
对于更加复杂的情况, RxJava 提供了更好的解决办法。 Dan Lew 有一些非常好的博客来介绍这个框架 。
为了减少偏激我更改了标题(原来的标题是 EventBus 一个反面的设计模式)。需要重申的是并不是所有的易错问题都是由 EventBus 导致的。特别是同步获取的问题在任何方式中都有可能发生,但是我认为通过 RxJava 结合一些配置和可空的注解(
@Nullable
)能够更清晰地处理好这个问题。
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
上一篇: Android 一体机模式 规则限制
下一篇: 自动化截图-应用分发时的自动截图方案
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论