Android廣播分為兩個方面：廣播發(fā)送者和廣播接收者，通常情況下，BroadcastReceiver指的就是廣播接收者（廣播接收器）。

　　EventBus是一個發(fā)布 / 訂閱的事件總線。簡單點(diǎn)說，就是兩人約定好怎么通信，一人發(fā)布消息，另外一個約定好的人立馬接收到你發(fā)的消息。

　　用處：相信大家都用過Handle了進(jìn)行線程通信，回調(diào)方法進(jìn)行通信。EventBus就可以幫減少很多事，不管你在任何地方任何位置發(fā)布一個事件，接收者都能立馬接收到你的消息，不用你考慮android子線程操作UI線程的問題。

　　一、廣播作為Android組件間的通信方式，可以使用的場景如下：

　　1、同一app內(nèi)部的同一組件內(nèi)的消息通信（單個或多個線程之間）；

　　2、同一app內(nèi)部的不同組件之間的消息通信（單個進(jìn)程）；

　　3、同一app具有多個進(jìn)程的不同組件之間的消息通信；

　　4、不同app之間的組件之間消息通信；

　　5、Android系統(tǒng)在特定情況下與App之間的消息通信。

　　二、以上列舉的廣播機(jī)制具體可以使用的場景中，在實(shí)際應(yīng)用中的適用性：

　　1、同一app內(nèi)部的同一組件內(nèi)的消息通信（單個或多個線程之間），實(shí)際應(yīng)用中肯定是不會用到廣播機(jī)制的（雖然可以用），無論是使用擴(kuò)展變量作用域、基于接口的回調(diào)還是Handler-post/Handler-Message等方式，都可以直接處理此類問題，若適用廣播機(jī)制，顯然有些“殺雞牛刀”的感覺；

　　2、同一app內(nèi)部的不同組件之間的消息通信（單個進(jìn)程），對于此類需求，在有些教復(fù)雜的情況下單純的依靠基于接口的回調(diào)等方式不好處理，此時可以直接使用EventBus等，相對而言，EventBus由于是針對統(tǒng)一進(jìn)程，用于處理此類需求非常適合，且輕松解耦。

　　3、其他情形，由于涉及不同進(jìn)程間的消息通信，此時根據(jù)實(shí)際業(yè)務(wù)使用廣播機(jī)制會顯得非常適宜。

　　三、BroadcastReceiver的具體實(shí)現(xiàn)流程如下：

　　1、廣播接收者BroadcastReceiver通過Binder機(jī)制向AMS(Activity Manager Service)進(jìn)行注冊；

　　2、廣播發(fā)送者通過binder機(jī)制向AMS發(fā)送廣播；

　　3、AMS查找符合相應(yīng)條件（IntentFilter/Permission等）的BroadcastReceiver，將廣播發(fā)送到BroadcastReceiver（一般情況下是Activity）相應(yīng)的消息循環(huán)隊(duì)列中；

　　4、消息循環(huán)執(zhí)行拿到此廣播，回調(diào)BroadcastReceiver中的onReceive()方法。

　　四、使用EventBus框架具體流程如下:

　　1、初始化時注冊EventBus.getDefault().register(this);

　　2、用完之后注銷EventBus.getDefault().unregister(this);

　　3、中間過程主要就是消息推送和接收了,通過EventBus.getDefault().post(param)推送,通過onEventMainThread(param),onEventPostThread(param),onEventBackgroundThread(param),onEventAsync(param)接收并處理。

　　由此看來，廣播發(fā)送者和廣播接收者分別屬于觀察者模式中的消息發(fā)布和訂閱兩端，AMS屬于中間的處理中心。廣播發(fā)送者和廣播接收者的執(zhí)行是異步的，發(fā)出去的廣播不會關(guān)心有無接收者接收，也不確定接收者到底是何時才能接收到。顯然，整體流程與EventBus非常類似。