Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

针对README中“与greenrobot的EventBus的不同”的话题提出几点自己的看法↓↓↓ #49

Closed
yangyiRunning opened this issue May 11, 2017 · 10 comments

Comments

@yangyiRunning
Copy link

  • 针对“与greenrobot的EventBus的不同”中所指出的第一个问题,EventBus 3.x之后已经通过引入注解解决了这个问题,解放了方法名,方法名可以根据开发者的业务自己定义,体现代码的自文档性。
  • 针对“与greenrobot的EventBus的不同”中所指出的第二个问题,个人认为二次封装,引入tag没有必要,tag(或者叫type)之类的区别事件post源头的字段完全可以放在User或者UserEvent的实体类中,post事件时传且仅传实体类,多个post传递到一个Subscriber之后通过取出类中的tag(或者type)来通过if或switch来区别post的源头。

综上,本库之前相比于EventBus的优势随着EventBus的升级而式微,EventBus已经足够精简和友好了,没有必要再针对其进行二次封装,徒增学习成本和维护成本。

@RockyQu
Copy link

RockyQu commented May 19, 2017

这库是不维护了么?

@yangyiRunning
Copy link
Author

yangyiRunning commented May 25, 2017

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

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

@tpnet
Copy link

tpnet commented Jun 15, 2017

@yangyiRunning

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

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

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

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

@RockyQu
Copy link

RockyQu commented Jun 15, 2017

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

@KobeBryant824
Copy link

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

@JessYanCoding
Copy link

JessYanCoding commented Aug 21, 2017

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

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

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

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

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

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

@JessYanCoding
Copy link

JessYanCoding commented Jul 11, 2018

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

@hehonghui
Copy link
Owner

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

@JessYanCoding
Copy link

JessYanCoding commented Jul 11, 2018

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

@hehonghui
Copy link
Owner

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

Repository owner deleted a comment from Blankj Aug 12, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

6 participants