1、BroadCast

廣播是相對消耗時間、空間最多的一種方式，但是大家都知道，廣播是四大元件之一，許多系統級的事件都是通過廣播來通知的，比如說網路的變化、電量的變化，簡訊傳送和接收的狀態，所以，如果與android系統進行相關的通知，還是要選擇本地廣播；在BroadcastReceiver的 onReceive方法中，可以獲得Context 、intent引數，這兩個引數可以呼叫許多的sdk中的方法，而eventbus獲得這兩個引數相對比較困難；

因此廣播相對於其他的方式而言，廣播是重量級的，消耗資源較多的方式。他的優勢體現在與sdk連線緊密，如果需要同 android 互動的時候，廣播的便捷性會抵消掉它過多的資源消耗，但是如果不同android互動，或者說，只做很少的互動，使用廣播是一種浪費；

廣播作為Android元件間的通訊方式，可以使用的場景如下：
        1.同一app內部的同一組件內的訊息通訊（單個或多個執行緒之間）；
        2.同一app內部的不同元件之間的訊息通訊（單個程序）；
        3.同一app具有多個程序的不同元件之間的訊息通訊；
        4.不同app之間的元件之間訊息通訊；
        5.Android系統在特定情況下與App之間的訊息通訊。

廣播的不可替代性在於它可以跨程序進行通訊，也就是不同APP之間可以通過廣播進行傳遞資料，並且在OnReceiver中更容易使用Context和Intent物件來執行必要的操作。單就同一app內部的訊息通訊而言，使用廣播是較為消耗資源和笨重的。

2、Handler

handler一般用於執行緒間通訊，它可以分發Message物件和Runnable物件到主執行緒中， 每個Handler例項，都會繫結到建立他的執行緒中(一般是位於主執行緒)，它有兩個作用：
        1.安排訊息或Runnable 在某個主執行緒中某個地方執行；
        2.安排一個動作在不同的執行緒中執行。

本篇只討論handler中與Message相關的的訊息通訊，一般Handler的使用方法即在呼叫執行緒內建立Handler的內部類，並重寫handlerMessage(Message msg) 方法，而在釋出訊息時使用sendMessage方法進行釋出，在處理時通過switch(msg.what)進行訊息分發並進行相應的處理。這裡，Hander內部類和其定義類是繫結的，這就造成了事件釋出者和接受者之間的高耦合。而Handler的最大好處是發生問題時，可以非常明確、快速的進行定位，通過msg.what很容易就可以理清每一條訊息流的邏輯。

3、EventBus

EventBus的使用方法就不再多做介紹，詳細請了解Android開源框架：Android EventBus 的使用

EventBus的優勢在於排程靈活。不依賴於 Context，使用時無需像廣播一樣關注 Context 的注入與傳遞，也解除了Handler所帶來的耦合，父類對於通知的監聽和處理可以繼承給子類，這對於簡化程式碼至關重要；通知的優先順序，能夠保證 Subscriber 關注最重要的通知；粘滯事件（sticky events）能夠保證通知不會因 Subscriber 的不在場而忽略。可繼承、優先順序、粘滯，是 EventBus 比之於廣播、觀察者等方式最大的優點，它們使得建立結構良好組織緊密的通知系統成為可能。

但EventBus也有很明顯的缺陷，在EventBus中事件的分發是通過註解函式的引數型別確定的，因此在事件釋出遭到大量濫用時，特別有多個訂閱者、多個相同引數時，很難從事件釋出者開始理清訊息流，無法快速的找出是哪個訂閱者接受並處理了訊息導致的問題，這就要求了參與者必須對整個通知過程有著良好的理解。當程式程式碼適量時，這是一個合理的要求，然而當程式太大時，這將成為一種負擔。在EventBus中一定要寫好必要的註釋資訊，否則在後續工作交接中會產生很多不必要的麻煩。

原文：https://www.cnblogs.com/JasonLGJnote/p/11876183.html