探究EventBus粘性事件实现机制
- 粘性事件观察者
@Subscribe(threadMode = ThreadMode.MAIN, sticky = true)
fun registerEventBus(o: Any) {
}
- 发送粘性事件
EventBus.getDefault().postSticky(Any())
- 注册
EventBus
EventBus.getDefault().register(this)
接下来我们就来探究下EventBus
的粘性事件是如何实现的。
postSticky()
内部机制
- 如果是发送的粘性事件,会添加到
stickyEvents
中,看下这个属性的实现:
可以看到这个属性是一个Map
集合,其中key为事件类型的class对象,value为对应的事件类型。
- 继续看下
post(Event)
方法:
首先将这个粘性事件添加到
PostingThreadState
(线程私有)的eventQueue
集合中通过
isMainThread
方法判断当前是否为主线程,最终会调用到我们熟悉的Looper.getMainLooper() == Looper.myLooper()
进行判断循环遍历
eventQueue
队列,不断的取出集合元素进行分发,看下postSinleEvent()
方法如何实现:
如果
eventInheritance
为true,会查找当前发送的粘性事件类型的父类型,并返回查找到的集合接下来就会调用
postSingleEventForEventType()
方法来进行最终粘性事件的分发,即通知通过@Subscribe
注解注册的粘性事件观察者,看下具体实现:
- 调用
subscriptionsByEventType
获取注册该事件类型的所有订阅方法,但是由于这个时候我们是先发送的粘性事件再注册EventBus
,而subscriptionsByEventType
中集合元素的填充实在注册EventBus
发生的,所以通过subscriptionsByEventType
获取到的subscriptions
将是null的,所以接下来肯定不会走下面的if代码块中的逻辑了。
postSticky()
小结
上面这么多代码逻辑,其实只干了一件事,就是将这个粘性事件添加到了stickyEvents
这个集合中。之后的逻辑虽多,但和粘性事件没啥关系。
register
内部机制
findSubscriberMethods()
这个方法里面的逻辑就不带大家进行分析了,总之就干了一件事情:
查找当前类通过
@Subscribe
注册的所有事件订阅方法,并返回一个List<SubscriberMethod>
集合,其中SubscriberMethod
就是对每个注册的订阅方法和当前注册类的封装
subscribe
这个方法是关键,深入探究下:
第1、2、3、4步中其实就干了两件事情:
- 填充
subscriptionsByEventType
集合,key为事件类型,value为通过@Subscribe
订阅了该事件类型的方法集合 - 填充
typesBySubscriber
集合,key为注册EventBus的类,value为该类中所有@Subscribe
注解修饰的方法集合
第5步就是实现粘性事件分发的关键地方
- 首先判断当前
@Subscribe
修饰的订阅方法是否为粘性,即@Subscribe(sticky = true)
中sticky
等于true - 是的话就从
stickyEvents
集合中判断是否存在和订阅方法中注册的事件类型相同的事件:
这个
stickyEvents
是不是很熟悉,就是我们之前发送粘性事件时,将粘性事件添加到的方法集合- 如果存在,则就执行该粘性事件的分发,即调用执行该订阅方法,最终会调用到
invokeSubscriber()
方法:
从上面可以看到,最终是通过反射来实现的订阅了粘性事件方法的执行。
register
小结
该方法最终会判断当前是否存在注册EventBus
前发送的粘性事件,且当前注册类中存在订阅该事件类型的方法,然后立即执行。
总结
以上就是EventBus
粘性事件的内部实现机制,总体来说不算复杂,大家看着文章跟着源码一步步分析应该就很容易理解这部分实现逻辑了。
作者:长安皈故里
链接:https://juejin.cn/post/7102815596621856799
来源:稀土掘金
著作权归作者所有。商业转载请联系作者获得授权,非商业转载请注明出处。