针对README中“与greenrobot的EventBus的不同”的话题提出几点自己的看法↓↓↓ about androideventbus HOT 10 CLOSED

这个库优势在于小,并且支持 Tag ,方便索引订阅的方法和 post 的位置

而 greenrobot 的 Eventbus3 ,使用的是编译时注解,效率上是有优势的 (在开启 Index 的情况下, 由运行时解析注解变为在编译时解析注解, 提升的是注册订阅者的时间, 但是并没有提升 post 的时间), 但是必须基于事件,也就是必须每个独立的订阅事件都需要创建单独的实体类 (多个接收端声明同一个事件类型都将被迫接受到这个事件)

这样如果使用普通的数据类型作为传递参数,会非常累,而且想直接定位到订阅的方法,也没 Tag 清晰快速 (实体类有很大的可能被传递到项目中的多个类中作为 JavaBean 使用, 这样通过搜索实体类的方式定位订阅方法的实际位置, 增加了难度, 项目越大越恐怖, 而 Tag 只会在 post 和订阅方法中出现, 所以定位更快更精确),而且个人不是很推荐大量使用 Eventbus ,用的太多,整个项目的架构会很混乱,难以管理,所以这个轻量级框架加上独有的 Tag 我觉得是非常适合我的

如果是组件化框架,使用这个 Eventbus 作为中间件来跨模块通信还是很不错的,因为这个 Tag ,可以根据不同的 Module 来分组,这样哪个 Moudle 的 哪个方法订阅了事件都很清晰,这也是 MVPArms 一直使用这个框架的原因

像楼主说的在实体类中定义 Tag,来区分事件和 Message 的 what 同理,你并没有真正解决同一个事件类型有多个订阅方法的问题,当这个事件 post 时, Eventbus 还是会去查找所有订阅过这个事件的方法,并且挨个调用并传递这个事件给订阅的方法,只是你可以在方法里根据实体类中 Tag 字段的不同,而选择执行或者不执行对应的逻辑

但是多余的性能损耗已经发生了,而且你如果某个事件实体中的 Tag 变多,也难以管理,因为你要事先规划哪个订阅对象的哪个方法用哪个 Tag ,0 还是 1 ? 所以这个框架在这个方面的优势大的多

from androideventbus.

@yangyiRunning

使用方法基本一致吧？ 这就没什么学习成本了吧。

这个库才19.7kb，eventbus 52kb, 。

对于tag，你觉得放在bean里面方面还是放注解方便，肯定是放注解方便啊。

对于很多用户来说，这个库才是比较适合的，个人看法。

from androideventbus.

这库是不维护了么？

from androideventbus.

@DesignQu 我不是库的作者，但是我看最后一次提交已经是1年前的事情了，所以我揣测作者也已经不再维护这个库了。

看这个库的简介，此库是为了弥补EventBus 2.x版本的不足而生，现在EventBus 3.x的版本中那些不足已经不复存在，所以这个库也没有迭代必要了。

from androideventbus.

我觉得这个库很好，应该继续维护下去，可惜了

from androideventbus.

EventBus要是也加入Tag注解就真的无敌了

from androideventbus.

关于楼主说的在 Event 实体类中 加入 Tag 的建议，下面是鸿神的回答，看来他和我的意见是一样的

from androideventbus.

这只是添加一种实现方式，至于你想怎么用，那是自己的选择。这个有点像面向对象里面你是用继承还是组合，你可以用多个Event class 进行分发，也可以通过 tag 字段进行分发。Library 只是提供基本功能，如何选择还是看自己。

from androideventbus.

@hehonghui 鸿神没有说您在注解上 Tag 有问题，说的是在 Event class 中加入 Tag 来达到使用同一个 Event class 分发不同的事件这种方式有问题

from androideventbus.

噢，我可能没有看清楚，忙工作的工程中看到消息所以过来交流一下。如果在 Event class 中添加tag, 再通过这个 tag 来做if-else判断那是不太合适，AndroidEventBus 最初就是要解决同一个Event class 却有不同处理逻辑的问题.

from androideventbus.