EventBus是一个基于发布者/订阅者模式的事件总线框架。
发布者/订阅者模式,也就是观察者模式(定义了对象之间的一种一对多的依赖关系,当一个对象状态发生改变时,它的所有依赖者都会收到通知并自动更新)。在EventBus中,当发布者发布事件时,所有订阅该事件的事件处理方法将被调用。
Github入口
EventBus的优点:
- 解耦和简化Activities, Fragments等组件以及后台线程之间的通信,分离事件发送方和接收方
- 使得代码更简洁,避免出现复杂的依赖性和生命周期问题
- 体积小(大概只有50k 的 jar包)
EventBus的使用:
AS中添加gradle依赖:
如果你的应用app发布打包时开启了混淆,则需要在proguard-rules.pro中添加对应的混淆规则:
使用之前了解EventBus的三个要素:
- Event 事件。它可以是任意的Object类型,你可以自定义一个Class类。
- Subscriber 事件订阅者。在EventBus3.0之前我们必须定义以onEvent开头的几个方法,分别是onEvent、onEventMainThread、onEventBackgroundThread和onEventAsync,而在3.0之后事件处理的方法名可以随意取,不过需要加上注解,并且指定线程模型,默认是。
- Publisher 事件的发布者。我们可以在任意线程里发布事件,一般情况下,使用EventBus.getDefault()就可以得到一个EventBus对象,然后再调用post(Object)方法即可。
EventBus的使用基本上分为简单的3个步骤:定义事件、注册事件订阅者、发布事件。
1.自定义一个事件:
2.注册并订阅事件:
EventBus的注册和反注册需要成对出现,一般在和方法,或者在和方法中。
订阅事件:
这里方法名可以任意取,但必须添加注解(这里指定线程模型为主线程),方法参数即前面自定义的事件类。
3.发布事件:
下面简单例子,点击按钮启动, 在中给页面发送一个消息
注意发送方的页面如果不需要接收事件就不需要进行EventBus的注册,发送方只需要调用这句即可。
EventBus线程模式
EventBus支持订阅者和发布者在不同的线程中调用。你可以使用线程模式来指定调用订阅者方法的线程。EventBus总共支持5种线程模式:
- ThreadMode.POSTING 订阅者方法将在发布事件所在的线程中被调用。这是 默认的线程模式。事件的传递是同步的,一旦发布事件,所有该模式的订阅者方法都将被调用。这种线程模式意味着最少的性能开销,因为它避免了线程的切换。因此,对于不要求是主线程并且耗时很短的简单任务推荐使用该模式。使用该模式的订阅者方法应该快速返回,以避免阻塞发布事件的线程,这可能是主线程。
- ThreadMode.MAIN 订阅者方法将在主线程(UI线程)中被调用。因此,可以在该模式的订阅者方法中直接更新UI界面。如果发布事件的线程是主线程,那么该模式的订阅者方法将被直接调用。使用该模式的订阅者方法必须快速返回,以避免阻塞主线程。
- ThreadMode.MAIN_ORDERED 订阅者方法将在主线程(UI线程)中被调用。因此,可以在该模式的订阅者方法中直接更新UI界面。事件将先进入队列然后才发送给订阅者,所以发布事件的调用将立即返回。这使得事件的处理保持严格的串行顺序。使用该模式的订阅者方法必须快速返回,以避免阻塞主线程。
- ThreadMode.BACKGROUND 订阅者方法将在后台线程中被调用。如果发布事件的线程不是主线程,那么订阅者方法将直接在该线程中被调用。如果发布事件的线程是主线程,那么将使用一个单独的后台线程,该线程将按顺序发送所有的事件。使用该模式的订阅者方法应该快速返回,以避免阻塞后台线程。
- ThreadMode.ASYNC 订阅者方法将在一个单独的线程中被调用。因此,发布事件的调用将立即返回。如果订阅者方法的执行需要一些时间,例如网络访问,那么就应该使用该模式。避免触发大量的长时间运行的订阅者方法,以限制并发线程的数量。EventBus使用了一个线程池来有效地重用已经完成调用订阅者方法的线程。
例子:
MainActivity订阅了MessageEvent事件,定义了5个不同线程模式的订阅者方法。当接收到MessageEvent事件时,订阅者方法将打印当前所在的线程名。
在SecondActivity当中点击发送按钮时,在名为"Publisher"的子线程中给MainActivity发送一个事件:
输出:
EventBus粘性事件
EventBus粘性事件所处理的问题是:发布者先发送了事件,但是此时订阅者还未产生,一段时间后订阅者才订阅了该事件,也就是使得在发送事件之后订阅者再订阅该事件也能收到该事件。
比如需求是在第一个Activity中发送事件,然后启动第二个Activity接收事件进行处理 ,但此时在打开第二个Activity时是接收不到消息的,主要是因为第二个Activity在第一个Activity发送事件时还未完成EventBus的注册,此时就需要使用粘性事件处理。
接收粘性事件的订阅者方法注解必须添加属性:
发布粘性事件使用:
发布一个粘性事件之后,EventBus将一直缓存该粘性事件。如果想要移除粘性事件,那么可以使用如下方法:
例子:
点击MainActivity的按钮时,先发送一个粘性事件,再启动SecondActivity
在打开的SecondActivity中订阅该事件:
输出:
EventBus事件优先级
EventBus支持在定义订阅者方法时指定事件传递的优先级。默认情况下,订阅者方法的事件传递优先级为0。数值越大,优先级越高。在相同的线程模式下,更高优先级的订阅者方法将优先接收到事件。
注意:优先级只有在相同的线程模式下才有效。如果相同的线程模式下的订阅方法都没有指定优先级(默认优先级为 0),则接收事件的方法顺序会按照方法名的字母排序。
指定事件传递优先级需要在订阅方法注解上添加属性:
你可以在高优先级的订阅者方法接收到事件之后取消事件的传递。此时,低优先级的订阅者方法将不会接收到该事件。注意: 订阅者方法只有在线程模式为时,才可以取消一个事件的传递。
取消事件的传递使用方法:
例子:
在MainActivity中指定不同优先级的订阅者方法
在MainActivity中订阅了MessageEvent事件,定义了5个不同优先级的订阅者方法。当接收到MessageEvent事件时,订阅者方法将打印日志消息。优先级为3的订阅者方法中在接收到事件之后取消了事件的传递。
在SecondActivity当中点击按钮时给MainActivity发送一个消息事件:
输出:
可以看到只有优先级5、4、3的被打印出来了,优先级为2、1的事件被取消了。
注意,上面代码是在同一个页面MainActivity中定义了5个不同优先级的方法,假如是在不同页面的话,一旦调用了方法同样会起作用,即此时所有的页面中,凡是订阅该事件的方法优先级取消订阅方法的优先级的统统都不会再接收到事件了(不管线程模式是什么)。
在上面基础上我们在SecondActivity当中来添加几个跟MainActivity中相同优先级的订阅方法:
添加了两个线程模式为优先级分别为3、4的方法,一个线程模式为优先级为默认优先级的方法
运行输出:
MainActivity:
SecondActivity:
可以看到在SecondActivity当中只输出了优先级为4的log, 优先级小于3的被取消了 ,线程模式为的同样被取消了,说明此时不管什么模式只要优先级<=3的会全部被取消。
EventBus订阅者索引
默认情况下,EventBus在查找订阅者方法时采用的是反射。订阅者索引是EventBus 3.0 的一个新特性。它可以加速订阅者的注册,是一个可选的优化。订阅者索引的原理是:使用EventBus的注解处理器在编译期间创建订阅者索引类,该类包含了订阅者和订阅者方法的相关信息。EventBus官方推荐在Android中使用订阅者索引以获得最佳的性能。
要开启订阅者索引的生成,你需要在中使用属性添加EventBus注解处理器,还要设置一个参数来指定要生成的订阅者索引的完全限定类名。
在app的build.gradle中配置:
配置完同步Build一下项目,EventBus注解处理器将为你生成一个订阅者索引类,这个类的位置是在目录下:
看一下这个自动生成的类的内容:
可以看到它其实把每个类中定义的订阅者方法和对应的事件类型都提取出来了,提前放到了这个类中一一对应的保存起来,这样在运行时就不用反射去解析注解了,从而提高性能效率。
最后,在应用自定义的Application类的onCreate()方法中将订阅者索引类添加到EventBus中,并将该EventBus设置成默认的EventBus。示例代码如下所示:
EventBus支持添加多个注解索引类,如果你在依赖的lib中也有一个索引类那么你可以这样:
接下来的使用就跟原来一模一样了。
see more: subscriber-index
HermesEventBus
是由饿了么开源,是一个在基础上开发的、能在进程间收发事件的库,它在使用上和有相同的API,对IPC或者插件开发比较有用。
Github入口
使用比较简单,就不多废话了,直接看官方的说明步骤就可以:
https://github.com/Xiaofei-it/HermesEventBus/blob/master/README-zh-CN.md
HermesEventBus内部的IPC部分是基于它的另一个开源库Hermes实现的,实现原理本质上还是通过实现跨进程通信,他在子进程中绑定了主进程的Service进行通信,只不过开发者无需自己手动实现这个过程了,再借助,使用上就更方便了。
版权声明:
本文来源网络,所有图片文章版权属于原作者,如有侵权,联系删除。
本文网址:https://www.mushiming.com/mjsbk/14699.html