EventBus的缺点及改进升级

 

EventBus很屌，被广泛用于事件分发、工程解耦，现在已经出到了第3版EventBuds3。网上对它的介绍太多了，我这里就不详细展开了。有不熟悉的可以阅读以下这篇文章：

《老司机教你“飙”EventBus3》 https://blog.csdn.net/natural_story/article/details/51444299

EventBus确实很棒，用那么小小的三五十KB轻量代码实现了那么强大的功能，可以把很多复杂混乱的APP整理得干净漂亮很多。用我的话说，EventBus的SLOGAN是：脏活我来干，优雅你来装。

这话一点不错。大型APP里，既要解耦，又要代码书写灵活，永远是一对矛盾体。辛辛苦苦拆得干干净净的两个组件A和B，突然需求一变，A要B干点事，那就要引入接口依赖了。在我看来就是“打洞”，光生生的一面墙，打上一两个三四个黑黢黢的不规则的洞，是很不雅观的，而且是比较费劲的，又脏又累。EventBus就是干这种苦活的。于是用了EventBus，程序员又可以装逼了（你看，我的代码多么解耦,多么优雅）。

然而本文并不是靠吹嘘EventBus来装逼的，相反，我要数落一下它的缺点，并推介一下EventBus4（本人命名的，未得到官方背书）。

缺点如下：

1. 事件只能通过事件的类名来区分；

这恐怕是EventBus最坑爹的设计了，EventBus吹捧者们难道没注意到它这一点吗？这至少带来了3大问题：

1. 操作麻烦，每一个事件，都要定义一个类；
2. 增加方法数；
3. 导致事件发送者和接收者都依赖耦合事件类；

1. 事件发生者只能单向广播，无法获得接收者对事件的处理结果；

EventBus能确保事件被送达给感兴趣的监听者。但这一过程是单向的。就像直流电一样，电流永远是从正极流向负极，无法“交流”(在现代社会中，交流电远比直流电用途广嘛)。谁规定的Event应该单向传递呢。很多时候，Event发送者把Event发送出去了，是很希望得到反馈的：小王&