一. 序

EventBus 是一個基於觀察者模式的事件訂閱/釋出框架，利用 EventBus 可以在不同模組之間，實現低耦合的訊息通訊。

EventBus 因為其使用簡單且穩定，被廣泛應用在一些生產專案中。

通常我們就是使用 EventBus 分發一些訊息給訊息的訂閱者，除此之外我們還可以通過 EventBus 將訊息傳遞到不同的執行緒中去執行，處理訊息。這其中還涉及到一些執行緒切換問題、執行緒池的問題，在使用的過程中，還有一些配置的選擇，此時我們需要根據不同的業務場景，來選擇不同的執行緒切換方式。

本文就 EventBus 的幾種執行緒切換方式，以及內部的實現原來，來分析如何使用 EventBus 來切換訊息執行緒。

二. EventBus 的執行緒切換

2.1 EventBus 切換執行緒

EventBus 是一個基於觀察者模式的事件訂閱/釋出框架。利用 EventBus 可以在不同模組之間，實現低耦合的訊息通訊。

EventBus 誕生以來這麼多年，在很多生產專案中都可以看到它的身影。而從更新日誌可以看到，除了體積小，它還很穩定，這兩年就沒更新過，最後一次更新也只是因為支援所有的 JVM，讓其使用範圍不僅僅侷限在 Android 上。

可謂是非常的穩定，穩定到讓人有一種感覺，要是你使用 EventBus 出現了什麼問題，那一定是你使用的方式不對。

EventBus 的使用方式，對於 Android 老司機來說，必然是不陌生的，相關資料太多，這裡就不再贅述了。

在 Android 下，執行緒的切換是一個很常用而且很必須的操作，EventBus 除了可以訂閱和傳送訊息之外，它還可以指定接受訊息處理訊息的執行緒。

也就是說，無論你 post() 訊息時處在什麼執行緒中，EventBus 都可以將訊息分發到你指定的執行緒上去，聽上去就感覺非常的方便。

不過無論怎麼切換，無外乎幾種情況：

• UI 執行緒切子執行緒。
• 子執行緒切 UI 執行緒。
• 子執行緒切其他子執行緒。

在我們使用 EventBus 註冊訊息的時候，可以通過 @Subscribe 註解來完成註冊事件， @Subscribe 中可以通過引數 threadMode 來指定使用那個執行緒來接收訊息。

@Subscribe(threadMode = ThreadMode.MAIN)
fun onEventTest(event:TestEvent){
  // 處理事件
}

threadMode 是一個 enum，有多種模式可供選擇：

1. POSTING，預設值，那個執行緒發就是那個執行緒收。
2. MAIN，切換至主執行緒接收事件。
3. MAIN_ORDERED，v3.1.1 中新增的屬性，也是切換至主執行緒接收事件，但是和 MAIN 有些許區別，後面詳細講。
4. BACKGROUND，確保在子執行緒中接收事件。細節就是，如果是主執行緒傳送的訊息，會切換到子執行緒接收，而如果事件本身就是由子執行緒發出，會直接使用傳送事件訊息的執行緒處理訊息。
5. ASYNC，確保在子執行緒中接收事件，但是和 BACKGROUND 的區別在於，它不會區分發送執行緒是否是子執行緒，而是每次都在不同的執行緒中接收事件。

EventBus 的執行緒切換，主要涉及的方法就是 EventBus 的 postToSubscription() 方法。

private void postToSubscription(Subscription subscription, Object event, boolean isMainThread) {
  switch (subscription.subscriberMethod.threadMode) {
    case POSTING:
      invokeSubscriber(subscription, event);
      break;
    case MAIN:
      if (isMainThread) {
        invokeSubscriber(subscription, event);
      } else {
        mainThreadPoster.enqueue(subscription, event);
      }
      break;
    case MAIN_ORDERED:
      if (mainThreadPoster != null) {
        mainThreadPoster.enqueue(subscription, event);
      } else {
        // temporary: technically not correct as poster not decoupled from subscriber
        invokeSubscriber(subscription, event);
      }
      break;
    case BACKGROUND:
      if (isMainThread) {
        backgroundPoster.enqueue(subscription, event);
      } else {
        invokeSubscriber(subscription, event);
      }
      break;
    case ASYNC:
      asyncPoster.enqueue(subscription, event);
      break;
    default:
      throw new IllegalStateException("Unknown thread mode: " + subscription.subscriberMethod.threadMode);
  }
}

可以看到，在 postToSubscription() 方法中，對我們配置的 threadMode 值進行了處理。

這端程式碼邏輯非常的簡單，接下來我們看看它們執行的細節。

2.2 切換至主執行緒接收事件

想在主執行緒接收訊息，需要配置 threadMode 為 MAIN。

case MAIN:
  if (isMainThread) {
    invokeSubscriber(subscription, event);
  } else {
    mainThreadPoster.enqueue(subscription, event);
  }

這一段的邏輯很清晰，判斷是主執行緒就直接處理事件，如果是非主執行緒，就是用 mainThreadPoster 處理事件。

追蹤 mainThreadPoster 的程式碼，具體的邏輯程式碼都在 HandlerPoster 類中，它實現了 Poster 介面，這就是一個普通的 Handler，只是它的 Looper 使用的是主執行緒的 「Main Looper」，可以將訊息分發到主執行緒中。

為了提高效率，EventBus 在這裡還做了一些小優化，值得我們借鑑學習。

為了避免頻繁的向主執行緒 sendMessage()，EventBus 的做法是在一個訊息裡儘可能多的處理更多的訊息事件，所以使用了 while 迴圈，持續從訊息佇列 queue 中獲取訊息。

同時為了避免長期佔有主執行緒，間隔 10ms （maxMillisInsideHandleMessage = 10ms）會重新發送 sendMessage()，用於讓出主執行緒的執行權，避免造成 UI 卡頓和 ANR。

MAIN 可以確保事件的接收，在主執行緒中，需要注意的是，如果事件就是在主執行緒中傳送的，則使用 MAIN 會直接執行。為了讓開發和可配置的成都更高，在 EventBus v3.1.1 新增了 MAIN_ORDERED，它不會區分當前執行緒，而是通通使用 mainThreadPoster 來處理，也就是必然會走一遍 Handler 的訊息分發。

當事件需要在主執行緒中處理的時候，要求不能執行耗時操作，這沒什麼好說的，另外對於 MAIN 或者 MAIN_ORDERED 的選擇，就看具體的業務要求了。

2.3 切換至子執行緒執行

想要讓訊息在子執行緒中處理，可以配置 threadMode 為 BACKGROUND 或者 AYSNC，他們都可以實現，但是也有一些區別。

先來看看 BACKGROUND，通過 postToSubscription() 中的邏輯可以看到，BACKGROUND 會區分當前發生事件的執行緒，是否是主執行緒，非主執行緒這直接分發事件，如果是主執行緒，則 backgroundPoster 來分發事件。

case BACKGROUND:
    if (isMainThread) {
        backgroundPoster.enqueue(subscription, event);
    } else {
        invokeSubscriber(subscription, event);
    }
break;

BackgroundPoster 也實現了 Poster 介面，其中也維護了一個用連結串列實現的訊息佇列 PendingPostQueue，

在一些編碼規範裡就提到，不要直接建立執行緒，而是需要使用執行緒池。EventBus 也遵循這個規範，在 BackgroundPoster 中，就使用了 EventBus 的 executorService 執行緒池物件去執行。

為了提高效率，EventBus 在處理 BackgroundPoster 時，也有一些小技巧值得我們學習。

可以看到，在 BackgroundPoster 中，處理主執行緒丟擲的事件時，同一時刻只會存在一個執行緒，去迴圈從佇列中，獲取事件處理事件。

通過 synchronized 同步鎖來保證佇列資料的執行緒安全，同時利用 volatile 標識的 executorRunning 來保證不同執行緒下看到的執行狀態是可見的。

既然 BACKGROUND 在處理任務的時候，只會使用一個執行緒，但是 EventBus 卻用到了執行緒池，看似有點浪費。但是再繼續瞭解 ASYNC 的實現，才知道怎麼樣是對執行緒池的充分利用。

和前面介紹的 threadMode 一樣，大多數都對應了一個 Poster，而 ASYNC 對應的 Poster 是 AsyncPoster，其中並沒有做任何特殊的處理，所有的事件，都是無腦的拋給 EventBus 的 executorService 這個執行緒池去處理，這也就保證了，無論如何發生事件的執行緒，和接收事件的執行緒，必然是不同的，也保證了一定會在子執行緒中處理事件。

public void enqueue(Subscription subscription, Object event) {
    PendingPost pendingPost = PendingPost.obtainPendingPost(subscription, event);
    queue.enqueue(pendingPost);
    eventBus.getExecutorService().execute(this);
}

到這裡應該就理解了 BACKGROUND 和 ASYNC ，雖然都可以保證在子執行緒中接收處理事件，但是內部實現是不同的。

BACKGROUND 同一時間，只會利用一個子執行緒，來迴圈從事件佇列中獲取事件並進行處理，也就是前面的事件的執行效率，會影響後續事件的執行。例如你分發了一個事件，使用的是 BACKGROUND 但是佇列前面還有一個耗時操作，那你分發的這個事件，也必須等待佇列前面的事件都處理完成才可以繼續執行。所以如果你追求執行的效率，立刻馬上就要執行的事件，可以使用 ASYNC。

那是不是都用 ASYNC 就好了？當然這種一攬子的決定都不會好，具體問題具體分析，ASYNC 也有它自己的問題。

ASYNC 會無腦的向執行緒池 executorService 傳送任務，而這個執行緒池，如果你不配置的話，預設情況下使用的是 Executors 的 newCachedThreadPool() 建立的。

這裡我又要說到編碼規範了，不推薦使用 Executors 直接建立執行緒，之所以這樣，其中一個原因在於執行緒池對任務的拒絕策略。 newCachedThreadPool 則會建立一個無界佇列，來存放執行緒池暫時無法處理的任務，說到無界佇列，拍腦袋就能想到，當任務（事件）過多時，會出現的 OOM。

這也確實是 EventBus 在使用 ASYNC 時，真實存在的問題。

但是其實這裡讓開發者自己去配置，也很難配置一個合理的執行緒池的拒絕策略，拒絕時必然會放棄一些任務，也就是會放棄掉一些事件，任何放棄策略都是不合適的，這在 EventBus 的使用中，表現出來就是出現邏輯錯誤，該收到的事件，收不到了。所以你看，這裡無界佇列不合適，但是不用它呢也不合適，唯一的辦法就是合理的使用 ASYNC，只在必要且合理的情況下，才去使用它。

三. 小結時刻

到這裡基本上 EventBus 在分發事件時的執行緒切換，就講清除了，很多資料裡其實都寫了他們可以切換執行緒，但是對於一些使用的細節，描述的並不清除，正好藉此文，把 EventBus 的執行緒切換的直接講清除。

EventBus 也是簡歷上比較常見的高頻詞，我在面試的過程中，也經常會問面試者，關於它是如何做到執行緒切換的問題。但是正因為它簡單易用，其實很多時候我們都忽略了它的實現細節。

今天就到這裡，小結一下：

1. EventBus 可以通過 threadMode 來配置接收事件的執行緒。

2. MAIN 和 MAIN_ORDERED 都會在主執行緒接收事件，區別在於是否區分，發生事件的執行緒是否是主執行緒。

3. BACKGROUND 確保在子執行緒中接收執行緒，它會通過執行緒池，使用一個執行緒迴圈處理所有的事件。所以事件的執行時機，會受到事件佇列前面的事件處理效率的影響。

4. ASYNC 確保在子執行緒中接收事件，區別於 BACKGROUND，ASYNC 會每次向執行緒池中傳送任務，通過執行緒池的排程去執行。但是因為執行緒池採用的是無界佇列，會導致 ASYNC 待處理的事件太多時，會導致 OOM。

本文就到這裡，本文對你有幫助嗎？留言、轉發、收藏是最大的支援，謝謝！

---

本文首發自公眾號「承香墨影」，歡迎關注獲取最新的原創文章。公眾號後臺回覆成長『成長』，將會得到我準備的學習資料，。

相關推薦