BroadcastReceiver和EventBus區別是什麼?他倆都挺像的,何時用BroadcastReceiver,何時用EventBus呢?android
Android廣播分爲兩個方面:廣播發送者和廣播接收者,一般狀況下,BroadcastReceiver指的就是廣播接收者(廣播接收器)。app
EventBus是一個發佈 / 訂閱的事件總線。簡單點說,就是兩人約定好怎麼通訊,一人發佈消息,另一個約定好的人立馬接收到你發的消息。框架
用處:相信你們都用過Handle了進行線程通訊,回調方法進行通訊。EventBus就能夠幫減小不少事,無論你在任何地方任何位置發佈一個事件,接收者都能立馬接收到你的消息,不用你考慮android子線程操做UI線程的問題。異步
1、廣播做爲Android組件間的通訊方式,可使用的場景以下:post
一、同一app內部的同一組件內的消息通訊(單個或多個線程之間);this
二、同一app內部的不一樣組件之間的消息通訊(單個進程);線程
三、同一app具備多個進程的不一樣組件之間的消息通訊;接口
四、不一樣app之間的組件之間消息通訊;隊列
五、Android系統在特定狀況下與App之間的消息通訊。進程
2、以上列舉的廣播機制具體可使用的場景中,在實際應用中的適用性:
一、同一app內部的同一組件內的消息通訊(單個或多個線程之間),實際應用中確定是不會用到廣播機制的(雖然能夠用),不管是使用擴展變量做用域、基於接口的回調仍是Handler-post/Handler-Message等方式,均可以直接處理此類問題,若適用廣播機制,顯然有些「殺雞牛刀」的感受;
二、同一app內部的不一樣組件之間的消息通訊(單個進程),對於此類需求,在有些教複雜的狀況下單純的依靠基於接口的回調等方式很差處理,此時能夠直接使用EventBus等,相對而言,EventBus因爲是針對統一進程,用於處理此類需求很是適合,且輕鬆解耦。
三、其餘情形,因爲涉及不一樣進程間的消息通訊,此時根據實際業務使用廣播機制會顯得很是適宜。
3、BroadcastReceiver的具體實現流程以下:
一、廣播接收者BroadcastReceiver經過Binder機制向AMS(Activity Manager Service)進行註冊;
二、廣播發送者經過binder機制向AMS發送廣播;
三、AMS查找符合相應條件(IntentFilter/Permission等)的BroadcastReceiver,將廣播發送到BroadcastReceiver(通常狀況下是Activity)相應的消息循環隊列中;
四、消息循環執行拿到此廣播,回調BroadcastReceiver中的onReceive()方法。
4、使用EventBus框架具體流程以下:
一、初始化時註冊EventBus.getDefault().register(this);
二、用完以後註銷EventBus.getDefault().unregister(this);
三、中間過程主要就是消息推送和接收了,經過EventBus.getDefault().post(param)推送,經過onEventMainThread(param),onEventPostThread(param),onEventBackgroundThread(param),onEventAsync(param)接收並處理。
由此看來,廣播發送者和廣播接收者分別屬於觀察者模式中的消息發佈和訂閱兩端,AMS屬於中間的處理中心。廣播發送者和廣播接收者的執行是異步的,發出去的廣播不會關心有無接收者接收,也不肯定接收者究竟是什麼時候才能接收到。顯然,總體流程與EventBus很是相似。