本文通過原理分析和實測結果對EventBus和RxBus做詳盡的對比，給大家在實際項目中選型做參考。
開始之前先提一下Otto：https://github.com/square/otto
當初Android上的事件總線系統是兩強相爭，老大是EventBus，老二就是Otto。在EventBus官方的性能測試代碼中，只和Otto做了對比測試。這么重要的人物為了么這次沒出場呢？是因為它已經停止開發了。Otto的主頁上有這么一句話：
This project is deprecated in favor of RxJava and RxAndroid. These projects permit the same event-driven programming model as Otto, but they’re more capable and offer better control of threading.
If you’re looking for guidance on migrating from Otto to Rx, this post is a good start.
該項目已被RxJava和RxAndroid取代。Rx類項目允許與Otto類似的事件驅動編程模型，而且能力更強，操作線程更方便。
如果你正在尋找從Otto遷移到Rx的指導，這個帖子是個很好的開始。
看，Otto臨死給后起之秀RxBus投了票，所以我們只需對比EventBus和RxBus。先扯一下Bus這個詞，它可以是巴士，也可以是總線。但是細一想，其本質含義都一樣，都是把線路各處人或事件，經過bus，運送到他們想要去的地方。所以英語用同一個詞表達這兩個意思，很有道理。我們可以理解巴士就是一個運人的總線:)
開始對比之前，還是同樣的方法，我們先考慮一下，一個完美的事件總線應該具備哪些功能？
- 容易訂閱事件：事件訂閱者只要聲明自己就好了，當事件發生時自然會被調到。訂閱和取消可以方便綁定到Activity和Fragment的生命周期上。
- 容易發送事件：事件發送者直接發送就好了，其他的事都不管。
- 方便的切換線程：有些事必須主線程干，有些事必須非主線程干，所以這個還是要說清楚。
- 性能：隨著應用的成長，總線可能會被重度使用，性能一定要好。
我們的需求就是這么簡單。
EventBus
EventBus是個明星項目，github上的star超過10000，網上的分析文章很多。這里只說一下大原理，方便我們分析。詳細內容可以參考這個文章。EventBus官網上說用EventBus只要三步：定義事件，創建訂閱者并訂閱，發送事件。我們也從這幾個步驟入手。
定義事件
每個事件是一個新的類，類中可以帶參數，什么都不帶，只是一個空的類定義，也沒問題。這個設計雖然會大幅增加類的數量(我們的項目中就有100多個event類)，但是清晰易懂，相比在類中定義事件類型變量的方法，使用起來方便很多。創建訂閱者
當某個事件發生時，訂閱這個事件的訂閱者就要被執行。所以創建訂閱者時除了要完成函數本身，還要聲明訂閱的是哪個參數(函數參數)，并聲明線程要求、是否粘性等，EventBus中這些信息通過注解聲明，使用十分方便。至于如何提取和處理這些信息這樣的臟活累活，EventBus都留給了自己。
@Subscribe(threadMode = ThreadMode.MAIN, sticky = true)
public void onEventMainThread(StateEvent event) {
Log.d(TAG, "StateEvent is emitted");
}
- 訂閱、取消訂閱
eventBus.register(this);
eventBus.unregister(this);
在有訂閱者的類中，隨時調用register()，就把類中的所有訂閱者都激活了。隨時調用unregister()，就都解除訂閱了。這個結合Android中Activity和Fragment的生命周期使用很方便。剛才說的臟活累活就是register()來完成的。它也是EventBus中最復雜的部分。詳細分析請參見其他文章，這里只說原理。register()要做這么幾件事：
- 通過注解把類中的所有訂閱者和訂閱信息提取出來，這里有很多過濾條件保證提取的正確性。
- EventBus中有兩個映射表，subscriptionsByEventType中存放所有event和對應的訂閱者，typesBySubscriber中存放每個訂閱者對應的事件。提取出來的訂閱者和信息就被存進了這兩個表里。
private final Map<Class<?>, CopyOnWriteArrayList<Subscription>> subscriptionsByEventType;
private final Map<Object, List<Class<?>>> typesBySubscriber;
- 發送事件
所有的的poster被放在3個隊列中，mainThreadPoster、backgroundPoster、asyncPoster。這3個隊列是用鏈表實現的，讓poster在各自的線程排隊，等候處理。如果是POSTING類型的事件，就直接執行了，不用排隊。
post事件時，在前面的映射表中可以用事件查到所有此事件的訂閱者，把每個訂閱者執行一遍。執行時根據線程要求做處理。
- 如果是POSTING，就把函數反射出來直接執行。
- 如果是MAIN，就直接執行，或者放到mainThreadPoster隊列中去。
- 如果是BACKGROUND，或者直接執行，或者放到backgroundPoster隊列中去。
- 如果是ASYNC，放到asyncPoster隊列中去。
對應的線程會執行這些poster。
- EventBus加速黑科技
上面就是EventBus的主要功能了。EventBus中很多代碼是為了防止出錯和性能優化。例如EventBus中大量使用了池來減少常用元素的創建和刪除。前面提到的臟活累活有一部分放到編譯期完成，例如這篇文章中提到的，訂閱者信息在編譯期就都提取出來了，生成一個靜態的SUBSCRIBER_INDEX，里面存放了類名索引的類中的訂閱者信息，包含訂閱的事件名、訂閱者方法名、線程、是否粘性、優先級。
回過頭來看我們的評價指標：
- 容易訂閱事件：完全合格。
- 容易發送事件：完全合格。
- 方便的切換線程：完全合格。
- 性能：完全合格。
那么問題來了，EventBus使用方便，性能優化到位，各方面都很好，為什么會遭到RxBus的挑戰，甚至可能被替代呢？
RxBus
希望前面的介紹把EventBus的原理說清楚了。下面我們來看看RxBus。它不是一個庫，而是一個文件，最短實現只有短短30行代碼。RxBus本身不需要過多分析，它的強大完全來自于它基于的RxJava技術。響應式編程(Reactive Programming)技術這幾年特別火，RxJava是它在Java上的實作。RxJava天生就是類似sub/pub的觀察者模式，而且很容易處理線程切換。而EventBus做的最重要的兩件事就是事件訂閱和線程控制。所以才有了RxBus區區30行代碼就敢挑戰EventBus的老大地位。
從 Kaushik Gopal 2014年12月在blog中一次提出RxBus，不斷有人在完善RxBus。我在實際使用中也對原始的RxBus進行了擴充，解決易用性和性能的問題。
由于RxJava已經解決了訂閱和線程切換問題，RxBus尚未解決的，也是重點需要解決的是事件分發的效率問題。為此我在AndroidPlayGround中復用EventBus性能測試代碼，對EventBus和RxBus做了性能測試。具體參見AndroidPlayground。測試中可以明顯發現RxBus效率隨訂閱者增多而成比例下降。
暫時的結論
- 如果你的項目中已經開始使用EventBus，沒有必要特意換用RxBus。
- 如果你的項目計劃引入RxJava，并認為統一風格很重要，啟用RxBus，拋棄EventBus沒有問題。但是請了解RxBus的問題，并關注RxBus的進展，最好能用Rx的方式解決這個問題。
RxBus也在不斷進化中，我相信隨著大家的努力，我們能夠解決RxBus中的問題，但是目前，RxBus在訂閱者數量很大的情況下，性能下降非常明顯是個事實。當RxBus有了好的解決方案，我會第一時間更新上來。
