眾所周知，EventBus是支持粘性事件的，即可以先發(fā)送粘性事件，然后再注冊，代碼如下：

• 粘性事件觀察者

@Subscribe(threadMode = ThreadMode.MAIN, sticky = true)
fun registerEventBus(o: Any) {    
}

• 發(fā)送粘性事件

EventBus.getDefault().postSticky(Any())

• 注冊EventBus

EventBus.getDefault().register(this)

接下來我們就來探究下EventBus的粘性事件是如何實(shí)現(xiàn)的。

postSticky()內(nèi)部機(jī)制

• 如果是發(fā)送的粘性事件，會(huì)添加到stickyEvents中，看下這個(gè)屬性的實(shí)現(xiàn)：

可以看到這個(gè)屬性是一個(gè)Map集合，其中key為事件類型的class對象，value為對應(yīng)的事件類型。

• 繼續(xù)看下post(Event)方法：

• 首先將這個(gè)粘性事件添加到PostingThreadState（線程私有）的eventQueue集合中

• 通過isMainThread方法判斷當(dāng)前是否為主線程，最終會(huì)調(diào)用到我們熟悉的Looper.getMainLooper() == Looper.myLooper()進(jìn)行判斷

• 循環(huán)遍歷eventQueue隊(duì)列，不斷的取出集合元素進(jìn)行分發(fā)，看下postSinleEvent()方法如何實(shí)現(xiàn)：

• 如果eventInheritance為true，會(huì)查找當(dāng)前發(fā)送的粘性事件類型的父類型，并返回查找到的集合

• 接下來就會(huì)調(diào)用postSingleEventForEventType()方法來進(jìn)行最終粘性事件的分發(fā)，即通知通過@Subscribe注解注冊的粘性事件觀察者，看下具體實(shí)現(xiàn)：

• 調(diào)用subscriptionsByEventType獲取注冊該事件類型的所有訂閱方法，但是由于這個(gè)時(shí)候我們是先發(fā)送的粘性事件再注冊EventBus，而subscriptionsByEventType中集合元素的填充實(shí)在注冊EventBus發(fā)生的，所以通過subscriptionsByEventType獲取到的subscriptions將是null的，所以接下來肯定不會(huì)走下面的if代碼塊中的邏輯了。

postSticky()小結(jié)

上面這么多代碼邏輯，其實(shí)只干了一件事，就是將這個(gè)粘性事件添加到了stickyEvents這個(gè)集合中。之后的邏輯雖多，但和粘性事件沒啥關(guān)系。

register內(nèi)部機(jī)制

• findSubscriberMethods()這個(gè)方法里面的邏輯就不帶大家進(jìn)行分析了，總之就干了一件事情：

查找當(dāng)前類通過@Subscribe注冊的所有事件訂閱方法，并返回一個(gè)List<SubscriberMethod>集合，其中SubscriberMethod就是對每個(gè)注冊的訂閱方法和當(dāng)前注冊類的封裝

• subscribe這個(gè)方法是關(guān)鍵，深入探究下：

• 第1、2、3、4步中其實(shí)就干了兩件事情：

  • 填充subscriptionsByEventType集合，key為事件類型，value為通過@Subscribe訂閱了該事件類型的方法集合
  • 填充typesBySubscriber集合，key為注冊EventBus的類，value為該類中所有@Subscribe注解修飾的方法集合

• 第5步就是實(shí)現(xiàn)粘性事件分發(fā)的關(guān)鍵地方

  • 首先判斷當(dāng)前@Subscribe修飾的訂閱方法是否為粘性，即@Subscribe(sticky = true)中sticky等于true
  • 是的話就從stickyEvents集合中判斷是否存在和訂閱方法中注冊的事件類型相同的事件：

  這個(gè)stickyEvents是不是很熟悉，就是我們之前發(fā)送粘性事件時(shí)，將粘性事件添加到的方法集合

  • 如果存在，則就執(zhí)行該粘性事件的分發(fā)，即調(diào)用執(zhí)行該訂閱方法，最終會(huì)調(diào)用到invokeSubscriber()方法：

從上面可以看到，最終是通過反射來實(shí)現(xiàn)的訂閱了粘性事件方法的執(zhí)行。

register小結(jié)

該方法最終會(huì)判斷當(dāng)前是否存在注冊EventBus前發(fā)送的粘性事件，且當(dāng)前注冊類中存在訂閱該事件類型的方法，然后立即執(zhí)行。

總結(jié)

以上就是EventBus粘性事件的內(nèi)部實(shí)現(xiàn)機(jī)制，總體來說不算復(fù)雜，大家看著文章跟著源碼一步步分析應(yīng)該就很容易理解這部分實(shí)現(xiàn)邏輯了。

到此這篇關(guān)于Android EventBus粘性事件實(shí)現(xiàn)機(jī)制的文章就介紹到這了,更多相關(guān)Android EventBus粘性事件內(nèi)容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！

最新評論