不請自來，見諒。
評(píng)價(jià)某種方式優(yōu)劣，有很多種指標(biāo)，包括空間、時(shí)間等性能因素，還有代碼的復(fù)雜程度，同整個(gè)程序的相性等等。

一般 認(rèn)為本地廣播是三種方式中消耗時(shí)間、空間最多的一種方式，但也是同 android 相性最好的方式。因?yàn)閺V播屬于 android 四大組件之一，在 BroadcastReceiver 中的 onReceive 方法中可以獲得 Context、Intent 參數(shù)。持有這兩個(gè)參數(shù)便可以調(diào)用許多 android sdk 中的方法，這一優(yōu)勢另外兩種方式很難彌補(bǔ)的，無論是 EventBus 還是觀察者，需要獲得 Context 的話，往往都需要進(jìn)行復(fù)雜的參數(shù)傳遞或者是依賴注入。
本地廣播另外的一個(gè)優(yōu)點(diǎn)是，許多系統(tǒng)級(jí)的事件都是使用廣播來進(jìn)行通知的，像常用的電量變化、網(wǎng)絡(luò)狀態(tài)變化、短信發(fā)送接收的狀態(tài)等等。這就使得與 android 系統(tǒng)相關(guān)的通知，廣播往往成了唯一的選擇。

但這并不意味著 android 系統(tǒng)中的通知都應(yīng)該使用廣播，因?yàn)橄鄬?duì)于其它的方式而言，廣播是重量級(jí)的、消耗資源較多的方式。廣播的優(yōu)勢體現(xiàn)在它與 android sdk 鏈接的更緊密，當(dāng)我們需要同 android 交互的時(shí)候，廣播提供的便捷性抵消掉了它過多的資源消耗。但是對(duì)于不需要同 android 交互或是只做很少的交互的時(shí)候，使用廣播往往是一種浪費(fèi)。

并 且在廣播中有一個(gè)常見的坑：錯(cuò)誤的使用 BroadcastReceiver 的 Context。在 android 的 Application、Activity、Service、ContentProvider、BroadcastReceiver 中都可以獲得對(duì)應(yīng)的 Context，但它們并不完全相同。Activity 的 Context 所能做的事是最全的，而其它組件中的 Context 都或多或少的有著功能殘缺。就拿常見的彈出 Dialog 來說，不知道有多少新手試圖使用非 Activity 的 Context 創(chuàng)建 Dialog 最終無功而返。另外，使用 BroadcastReceiver 等非 Activity 組件的 Context 啟動(dòng) Activity 也有可能造成隱蔽的錯(cuò)誤：當(dāng)使用非 Activity 組件的 Context 啟動(dòng) Activity 時(shí)，如果不指定 flag 的話，默認(rèn)會(huì)創(chuàng)建一個(gè)新的 task，而使用 Activity 的 Context 并且不指定 flag 的話，默認(rèn)會(huì)使用原 task。
Dave smith 的博客中有 一篇文章 詳細(xì)的介紹了各種 Context 的區(qū)別：

EventBus 作為 Android 開發(fā)中常用的框架，擁有著許多優(yōu)點(diǎn)：

• 調(diào) 度靈活。不依賴于 Context，使用時(shí)無需像廣播一樣關(guān)注 Context 的注入與傳遞。父類對(duì)于通知的監(jiān)聽和處理可以繼承給子類，這對(duì)于簡化代碼至關(guān)重要；通知的優(yōu)先級(jí)，能夠保證 Subscriber 關(guān)注最重要的通知；粘滯事件（sticky events）能夠保證通知不會(huì)因 Subscriber 的不在場而忽略。可繼承、優(yōu)先級(jí)、粘滯，是 EventBus 比之于廣播、觀察者等方式最大的優(yōu)點(diǎn)，它們使得創(chuàng)建結(jié)構(gòu)良好組織緊密的通知系統(tǒng)成為可能。
• 使 用簡單。EventBus 的 Subscriber 注冊非常簡單，調(diào)用 eventBus 對(duì)象的 register 方法即可，如果不想創(chuàng)建 eventBus 還可以直接調(diào)用靜態(tài)方法 EventBus.getDefault() 獲取默認(rèn)實(shí)例，Subscriber 接收到通知之后的操作放在 onEvent 方法里就行了。成為 Publisher 的過程就更簡單了，只需要調(diào)用合適的 eventBus（自己創(chuàng)建的或是默認(rèn)的）的 post 方法即可。
• 快速且輕量。作為 github 的明星項(xiàng)目之一， EventBus 的源代碼中許多技巧來改善性能，關(guān)于 EventBus 的性能具體如何，可以點(diǎn)可以點(diǎn)擊 這里 查看。

EventBus 的缺點(diǎn)主要集中在它現(xiàn)階段的實(shí)現(xiàn)方式，2.4.0 版是利用反射來實(shí)現(xiàn)的（貌似以前的版本也是？ ）。在 Subscriber 注冊的時(shí)候，Subscriber 中的方法會(huì)被遍歷查找以 onEvent 開頭的 public 方法。這將帶來一些問題，一旦對(duì)代碼進(jìn)行混淆，就無法查找到了，所以一個(gè)程序既用到了 EventBus 又需要進(jìn)行代碼混淆時(shí)，就得設(shè)置混淆規(guī)則：
但這種處理方式，對(duì)于保密度要求高的程序而言也是不可接受的，因?yàn)檫@暴露了方法名，給逆向留下了口子。好消息是 EventBus 已經(jīng)打算使用注解來實(shí)現(xiàn)，這應(yīng)該能夠解決代碼混淆的問題。

觀 察者這種設(shè)計(jì)模式應(yīng)當(dāng)屬于程序員的基本功，由于觀察者的實(shí)現(xiàn)比較簡單，因此性能上是三者中最好的，但觀察者難以控制通知的優(yōu)先度，特別是一開始沒有考慮優(yōu) 先度中途更改需求又加入優(yōu)先度。另外觀察者模式要求觀察者在事件發(fā)生時(shí)在場才能收到通知，這就使得觀察者有可能遺漏事件，一般來說這并不是問題，但是當(dāng)程 序要求觀察者不能遺漏事件時(shí)那就坑了?？陀^來說，這并不能算作觀察者的缺點(diǎn)，因?yàn)槠渌姆绞酵彩沁@樣，更加嚴(yán)謹(jǐn)?shù)恼f法是觀察者沒有 Eventbus 優(yōu)先級(jí)、粘滯事件的優(yōu)點(diǎn)。

但有一個(gè)缺點(diǎn)是觀察者獨(dú)有的，那就是觀察者可能會(huì)造成接口的膨脹。特別是當(dāng)程序要求大量形式各異的通知，而程序員有沒有做出良好的抽象時(shí)，代碼中會(huì)包含大量的接口，接口數(shù)量的增長又會(huì)帶來命名、注釋等等一大堆問題。本質(zhì)上說觀察者要求程序員從零開始實(shí)現(xiàn)事件的產(chǎn)生、分發(fā)與處理過程，這就要求參與者必須對(duì)整個(gè)通知過程有著良好的理解。當(dāng)程序代碼適量時(shí)，這是一個(gè)合理的要求，然而當(dāng)程序太大時(shí)，這將成為一種負(fù)擔(dān)。

綜上來看，廣播、EventBus、觀察者這三種方式有著它們各自優(yōu)缺點(diǎn)，具體使用哪一種還是得依靠具體的情況。說了半天感覺什么都沒有說，摔...