EventBus, otto, LocalBroadcast的選擇

原文連結

greenrobot的EventBus

square的otto

android support包裡提供的LocalBroadcast

三者都是類似訂閱/釋出的模式，降低了耦合度。與callback比起來，這種事件總線的模式使得兩個類沒有直接的依賴關系，對架構來說進行了解耦，把雙向依賴變成了單向依賴，在大型項目中尤其顯得重要。

Why publish/subscribe

一方面，callback很容易産生記憶體洩露，如I/O、網絡操作持有了Activity/Fragment的引用，導緻不能及時釋放，而團隊中也很難保證每個成員都足夠優秀在寫callback的時候能使用弱引用或靜态變量。相比起來訂閱/釋出者模式則比較簡單，直接在BaseActivity的onDestroy釋放掉，避免了可能的坑。

另外，從可擴充性、可維護性的角度來說，callback也更局限，比如以前某個接口是告訴上層網絡資料拉回來了，現在我們希望擴充，這個接口也支援直接告訴上層資料庫拉回來了，向上層屏蔽資料來源，如果用callback，則在一次回調結束後，沒有辦法再次進行回調了。頁面必須自己去處理資料來源和拉資料的邏輯。

雖然有些over-architect的嫌疑，但是Android-CleanArchitecture 确實是一種很clean的architecture，而其也正是通過觀察者/訂閱者模式來實作了單向依賴。

比較

EventBus的github上就有其和otto的比較： EventBus vs Otto

總的來說，兩者功能差的不多，otto多了Event producers (e.g. for coding cached events)，而EventBus則多了各種線程的處理、訂閱者繼承、sticky event等。

但從性能來說，由于otto使用了基于反射的annotation，而和EventBus産生了一定的差距（内部應該還有一些其他問題導緻的性能差異，待研究）

三者都不支援跨程序，LocalBroadcast内部其實使用的是Handler，是以其實更像是一個utils類。

如果要做選擇的話，LocalBroadcast更輕量，otto相比起api更好用，而EventBus則擁有很棒的線程模型，我投EventBus一票，因為onEvent的各種線程回調真的很友善。