EventBus, otto, LocalBroadcast的选择
来源:互联网 发布:网络三大奇书 编辑:程序博客网 时间:2024/06/08 19:47
原文链接
greenrobot的EventBus
square的otto
android support包里提供的LocalBroadcast
三者都是类似订阅/发布的模式,降低了耦合度。与callback比起来,这种事件总线的模式使得两个类没有直接的依赖关系,对架构来说进行了解耦,把双向依赖变成了单向依赖,在大型项目中尤其显得重要。
Why publish/subscribe
一方面,callback很容易产生内存泄露,如I/O、网络操作持有了Activity/Fragment的引用,导致不能及时释放,而团队中也很难保证每个成员都足够优秀在写callback的时候能使用弱引用或静态变量。相比起来订阅/发布者模式则比较简单,直接在BaseActivity的onDestroy释放掉,避免了可能的坑。
另外,从可扩展性、可维护性的角度来说,callback也更局限,比如以前某个接口是告诉上层网络数据拉回来了,现在我们希望扩展,这个接口也支持直接告诉上层数据库拉回来了,向上层屏蔽数据来源,如果用callback,则在一次回调结束后,没有办法再次进行回调了。页面必须自己去处理数据来源和拉数据的逻辑。
虽然有些over-architect的嫌疑,但是Android-CleanArchitecture 确实是一种很clean的architecture,而其也正是通过观察者/订阅者模式来实现了单向依赖。
比较
EventBus的github上就有其和otto的比较: EventBus vs Otto
总的来说,两者功能差的不多,otto多了Event producers (e.g. for coding cached events),而EventBus则多了各种线程的处理、订阅者继承、sticky event等。
但从性能来说,由于otto使用了基于反射的annotation,而和EventBus产生了一定的差距(内部应该还有一些其他问题导致的性能差异,待研究)
三者都不支持跨进程,LocalBroadcast内部其实使用的是Handler,所以其实更像是一个utils类。
如果要做选择的话,LocalBroadcast更轻量,otto相比起api更好用,而EventBus则拥有很棒的线程模型,我投EventBus一票,因为onEvent的各种线程回调真的很方便。
- EventBus, otto, LocalBroadcast的选择
- EventBus, otto, LocalBroadcast的选择
- EventBus 和Otto的区别
- OTTO-EVENTBUS
- EventBus & Otto
- EventBus & Otto的使用和比较
- EventBus和Otto
- Otto EventBus实践
- otto与EventBus对比
- 一种Android EventBus 类库:otto
- Otto与EventBus框架比较
- 用RxBus替代EventBus、Otto
- 事件总线 —— otto的bus和eventbus对比分析
- Android事件总线分发库的使用EventBus(和Otto一样,只是效率高点)
- 使用事件总线框架EventBus和Otto
- 使用事件总线框架EventBus和Otto
- 使用事件总线框架EventBus和Otto
- 使用LocalBroadcast实现跨Activity的MVVM
- 大数乘法的几种算法分析及比较(2014腾讯南京笔试题)
- 求职之路(2015南京站拿到百度、美团、趋势科技、华为offer)
- 杂感
- Reactivecoco 文档翻译(1) 基本操作方法
- swwuwnzzvfitp
- EventBus, otto, LocalBroadcast的选择
- 一个有趣的SQL:根据登录日志,求系统无人登录时间
- Android Material Design Library系列教程(二)
- 旧手机利用 第二弹 ——网络摄像头
- 海明码学习小结
- EditText的drawableleft跟随其Gravity
- 【Android实战项目】Odoo 邮箱客户端的经历
- Android插件化学习
- [leetcode] 187 Repeated DNA Sequences