一. 序
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，有多種模式可供選擇：
- POSTING，默認值，那個線程發就是那個線程收。
- MAIN，切換至主線程接收事件。
- MAIN_ORDERED，v3.1.1 中新增的屬性，也是切換至主線程接收事件，但是和 MAIN 有些許區別，后面詳細講。
- BACKGROUND，確保在子線程中接收事件。細節就是，如果是主線程發送的消息，會切換到子線程接收，而如果事件本身就是由子線程發出，會直接使用發送事件消息的線程處理消息。
- 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。
本文就到這里，本文對你有幫助嗎？留言、轉發、收藏是最大的支持，謝謝！
本文首發自公眾號「承香墨影」，歡迎關注獲取最新的原創文章。公眾號后台回復成長『成長』，將會得到我准備的學習資料，。
