眾所周知，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粘性事件的內部實現機制，總體來說不算復雜，大家看著文章跟著源碼一步步分析應該就很容易理解這部分實現邏輯了。