EventBus2.0-3.0的简单使用与详解

最新推荐文章于 2024-01-11 14:31:05 发布

qq18811561684

最新推荐文章于 2024-01-11 14:31:05 发布

阅读量1.6k

点赞数 1

本文链接：https://blog.csdn.net/qq18811561684/article/details/72496104

版权

EventBus是一个轻量级的发布/订阅事件库，用于简化Android组件间通信。文章介绍了EventBus的基本概念，强调了解耦和线程模式的重要性。对比了EventBus 2.0和3.0的差异，包括注册方式、性能优化和线程模式的改变，如Async、BackgroundThread、MainThread、PostThread等。同时提醒了在使用EventBus时应注意的生命周期管理和线程安全问题。

摘要由CSDN通过智能技术生成

EventBus是一个用于简化Andorid、Fragment、Threads、Service之间信息传递的一个发布/订阅事件集。

EventBus是由大名鼎鼎的greenrobot出品的一个用于Android中事件发布/订阅的库。简单点说就是用于Fragment，Activity，Service，线程之间进行数据传递，它为开发者提供除了 intent、handler、boardcast这几种传递数据的方式之外的一种选择，其优点在于几乎不怎么消化资源，并且代码优雅简洁。

传统的Android组件之间的通信方式有：Activity之间使用Intent；Service向Activity发送broadcast；Fragment和Activity之间相互持有对方的引用（随后可以调用对方的相关方法进行事件传递）。传统的事件传递的问题在于：通信方式没有实现解耦，是硬编码在组件中的。组件一旦发生修改，对应的通信方式就需要跟着修改。其实不管什么场景下，我们最好能够使得自己编写的代码最大限度的解耦，这是一个很好的习惯，避免无用功，提高代码利用率

使用EventBus的建议：

并不建议将应用中所有的事件都通过EventBus进行发送，尤其对于一对一的组件之间通信，建议不要使用EventBus。EventBus的使用场景更像是一种广播，当我们向EventBus发送一个事件，则该事件将会传递给多个该事件的订阅者，比如Service向Activities发送事件。跟LoacalBroadCast有点近似
在Activity和Fragment中使用EventBus时，要注意在组件的生命周期开始时registered EventBus，在生命周期结束时unregistered EventBus。否则容易导致OOM；

使用EventBus的好处在于：

简化组件之间的通信方式
让业务代码更加简洁（但是需要配合相应注解进行使用）
可以指定事件处理方法的执行线程，和订阅者的优先级（跟广播类似）
足够的稳定，已经被很多Android应用使用。

//使用Eventbus2.0与3.0的区别

EventBus 2.x 必须定义以onEvent开头的几个方法，代码中语境比较突兀，且有可能会导致拼写错误，例如数据同步事件

EventBus 3.0 函数名字不再受到权限，而且可以在一个函数中体现出在哪个线程执行，并且可指定接收事件的优先级

EventBus 2.x 注册方式也比较繁琐。EventBus 3.0 注册方式只有一个

EventBus 2.x 是采用反射的方式对整个注册的类的所有方法进行扫描来完成注册，当然会有性能上的影响。EventBus 3.0中EventBus提供了EventBusAnnotationProcessor注解处理器来在编译期通过读取@Subscribe()注解并解析、处理其中所包含的信息，然后生成java类来保存所有订阅者关于订阅的信息，这样就比在运行时使用反射来获得这些订阅者的信息速度要快

EventBus 四个Subscriber

首先在将四种方式之前不得不说一下ThreadMode, ThreadMode 是EventBus中一个很重要的概念，其本身是一个enum，他同样提供了四个默认属性值：Async，BackgroundThread，MainThread，PostThread；而在3.0中则改为ASYNC，BACKGROUND，MAIN，POSTING。分别对应四个方法。

onEvent
对应 PostThread，当使用onEvent作为订阅函数时，发布者在哪个线程发布事件，onEvent就会在哪个线程接收事件。因为函数执行的线程不确定，这就要求用户最好不要执行耗时操作，可能会出现线程阻塞或者事件分发不及时的问题。
注意一点：方法的修饰符最好使用 public