前面在 EventBus设计与实现分析——特性介绍 一文中介绍了EventBus的基本用法,及其提供的大多数特性的用法,这让我们对EventBus为用户提供的主要功能有了大体的了解,为我们后续理解EventBus的设计决策提供了良好的基础。这里我们就开始深入到EventBus的实现细节,先来了解其中的订阅者注册的过程。
订阅者的注册
EventBus使用了一种类似于闭包的机制来描述订阅者。即对于EventBus而言,一个订阅者由一个方法
+该方法绑定的上下文(也就是该方法绑定的对象
)+订阅者感兴趣的事件的类型
来描述。具体到实现,即是通过SubscriberMethod
+SubscriberMethod
这样几个类来描述。
我们可以看一下这几个类的定义,首先是Subscription
类:
subscriberMethod
即是我们前面提到的方法,而subscriber
则是上下文object。
然后是SubscriberMethod
类:
订阅者的注册过程,即是构造SubscriberMethod
,继而构造Subscription
,并对这些对象进行存储管理的过程。我们可以通过EventBus.register()
方法的定义具体看一下在EventBus中是怎么做:
通过EventBus.register()
和EventBus.subscribe()
可以看到,register的过程主要做了这样一些事情:
- 查找订阅者对象的所有订阅者方法。方法隶属于类,不以对象的改变而改变,应用程序的一次生命周期中,这些方法总是不变的。
- 构造
Subscription
来描述每一个订阅者,也就是订阅者对象
+一个订阅者方法
。 - 建立事件类型与订阅者之间的映射关系,这主要通过
subscriptionsByEventType
数据结构来描述。对于每一个事件类型,其订阅者会依优先级而排序。不难看出,这个结构主要用于事件的发布,在事件发布时,可以通过这个结构快速地找到每一个订阅者。
这个地方查找正确的插入位置是用的顺序查找的方法,估计是考虑到对于一个事件类型,订阅者一般不会太多,而订阅者的优先级一般不会很分散的缘故。 - 建立订阅者对象与该对象监听的事件类型之间的映射关系,这主要由
typesBySubscriber
数据结构来描述。这个结构则主要用于注销一个对象对事件的监听。注销一个对象对事件得监听时,可以通过这个结构快速地将监听者对象得信息从EventBus中整个的移除出去。 - 处理对Sticky事件的监听。如我们前面所见,这种类型的事件在发布时会通知到每个监听者,同时还会被保存起来,当后面再次注册对这种事件的监听时,监听者会直接得到通知。
EventBus
使用SubscriberMethodFinder
来查找一个类中所有的监听者方法,主要即是findSubscriberMethods()
方法。
如我们前面所见,要使一个类的某个方法成为监听者方法,需要给该方法添加Subscribe annotation,在SubscriberMethodFinder.findSubscriberMethods()
中会查找加了这个annotation的方法。但老版本的EventBus并不是通过annotation来标识一个监听者方法的,而是通过命名模式等方法,因而这里可以看到一种更为灵活的设计,来给用户提供空间,以支持不同的标识监听者方法的方法:
由于在应用程序的整个生命周期中,一个类的监听者方法总是不会变的,因而可以看到在SubscriberMethodFinder
中有创建一个缓存METHOD_CACHE,以监听者类为key,以监听者方法的列表为值。在SubscriberMethodFinder.findSubscriberMethods()
方法中会首先检查这个缓存中是否已经有了对应类的监听者方法,如果有的话会直接返回给调用者,没有的时候才会通过反射等机制来查找。
ignoreGeneratedIndex
用来标记是否要忽略用户定制的监听者方法标识方法。若忽略则直接利用反射机制,也就是Subscribe annotation机制来查找监听者方法,即调用findUsingReflection()
方法;否则会先尝试使用用户定制的机制来查找,查找失败时才会使用反射机制来查找,这也就是调用findUsingInfo()
方法。
在findUsingReflection()
方法中实现了如我们前面提到的用annotation标识监听者方法的方式下,查找监听者方法的过程:
在findUsingReflection()
中,会借助于FindState
来查找所有的监听者方法。FindState
类的角色主要有三个,一是迭代器,用于在监听者类的整个继承体系中遍历每一个类;二是容器,用来存放找到的每一个监听者方法;三是对找到的方法做验证。
findUsingReflectionInSingleClass()
方法找到一个特定类中所有的监听者方法。这里可以清楚地看到EventBus
对于监听者方法的声明的完整限制。一个方法被认定为监听者方法的条件为:
- 方法的可见性被声明为全局可见
public
,同时没有abstract
、static
、bridge
及synthetic
修饰。 - 方法的参数只有一个。
- 有annotation Subscribe的声明。
FindState.checkAdd()
会实施一些额外的限制。主要是关于,类中声明了多个方法监听相同事件的处理;及方法override的处理,即在类的继承体系中,有多个类声明了相同的方法,对相同的事件进行监听。
strictMethodVerification
是一个调试开关,如果开关打开,则当一个类声明了annotation Subscribe,但modifier或参数列表不满足要求时,会直接抛出异常。
我们再来详细地看一下FindState的定义:
moveToSuperclass()是迭代器方法,用于帮助SubscriberMethodFinder在订阅者类的整个继承层次中进行遍历。这里可以看到,这个遍历过程一般不会遍历到Object才停止,如果订阅者类直接或间接继承了java标准库或android框架层的类的话,遍历到那些类的时候就会终止了。checkAdd(Method method, Class<?> eventType)方法施加我们前面提到的额外限制,这个过程大体为:
- 订阅者类的整个继承层次中只有一个方法订阅了某个特定类型的事件,则该方法直接被认定为订阅者方法。
- 继承层次中对同一个事件类型有多个订阅者方法的,只要不同方法的方法名不同,则都会被认定为订阅者方法。
- 继承层次中某个被override的方法被声明了订阅者方法,则继承层次中深度最深的类的方法被认定为订阅者方法。子类比父类在继承层次中的深度要深。
SubscriberMethodFinder中FindState对象并不会总是被重新创建,而是有一个缓冲池,需要的时候从这个池子中获取所需得对象,而在对象用完之后,又会被重新归还到池子中,这些操作的详细过程可以在prepareFindState()和getMethodsAndRelease()这两个方法中看到:
findUsingInfo()和getSubscriberInfo()方法则允许用户插入自定义的订阅者方法声明机制:
所谓的用户自定义订阅者方法声明机制,需要通过实现SubscriberInfoIndex和SubscriberInfo接口来实现,并通过EventBusBuilder在创建EventBus对象时传递进来。SubscriberInfoIndex和SubscriberInfo接口的定义为:
和
至此,EventBus中,注册订阅者的过程就分析完了。