自己實現的觀察者模式、BroadcastReceiver和EventBus三者的優缺點是什麼?


個人推薦 EventBus,EventBus 有好幾家實現,我比較喜歡 greenrobot 家出的,這裡說的也是這家的。

BroadcastReceiver 分全局和 local,如果不用跨進程的話不應該用全局 Broadcast 。這裡也只討論 Local Broadcast。

代碼結構

Observable 的耦合性是比較高的,使用者還需要了解你 Observable 的結構,我幾乎沒用過;

LocalBroadcastManager 用一個 Intent 封裝廣播事件;

EventBus 將廣播事件抽像成一個類;

抽象程序上 EventBus 比較好。

使用

Observable 發送方要繼承或定義個內部 Observable,接收方要繼承 Observer ,還要弄點代碼處理不同的通知類型;

LocalBroadcastManager 首先要定義 Action 常量、ExtraKey 常量,發送時要 put 一個或一堆 Extra,接收方要繼承BroadcastReceiver,弄個 IntentFilter ,在 onReceive 函數里用 switch-case 通過 action 判斷類型, get 一個或一堆 Extra 來處理;

EventBus 相對最簡潔,寫個類定義一個 Event 類型,發送方就是 post,接收方就是定義一個函數,參數為對應類型。

線程

Observable 接收方在調用線程處理。

LocalBroadcastManager 所有調用都是在主線程,

EventBus 可以定義在調用線程、主線程、後台線程、非同步。

生命周期

都需要注意接收方生命周期的問題。在不用的時候要 unregister。

Others

EventBus 還有一些額外功能,比如說定義多個接收方接收的順序(LocalBroadcastManager不支持但全局 Broadcast 是支持的 )。


Observer需要把行為綁定在Observee上

Observe(Observee, "event", function() { ... });

BroadcastReceiver,EventBus不需要知道被偵聽對象,這樣就就解耦了。


推薦閱讀:

MVC 架構與 Observer 模式有什麼異同點?
c++ 單例模式的一點疑問,求解答?
在替考的代理模式中到底誰是Proxy?
怎樣才能在寫代碼時沒有一種「如履薄冰」的感覺?
用 C++ 編程時,如果不使用設計模式,多層封裝,採用複雜的數據結構,代碼更直觀,易理解,引入(設計模式)後雖然做到了高度的解耦。但是代碼邏輯複雜了,怎麼平衡好?

TAG:Android開發 | 設計模式 | Android | Android工程師 |