Android:系統在產生某個事件時發送廣播,應用程序使用廣播接收者接收這個廣播,就知道系統產生了什麼事件。 Android系統在運行的過程當中,會產生不少事件,好比開機、電量改變、收發短信、撥打電話、屏幕解鎖
無序廣播:全部跟廣播的intent匹配的廣播接收者均可以收到該廣播,而且是沒有前後順序(同時收到) 有序廣播:全部跟廣播的intent匹配的廣播接收者均可以收到該廣播,可是會按照廣播接收者的優先級來決定接收的前後順序 優先級的定義:-1000~1000 最終接收者:全部廣播接收者都接收到廣播以後,它才接收,而且必定會接收 abortBroadCast:阻止其餘接收者接收這條廣播,相似攔截,只有有序廣播能夠被攔截
BroadcastReceiver的生命週期,從對象調用它開始,到onReceiver方法執行完成以後結束。另外,每次廣播被接收後會從新建立BroadcastReceiver對象,並在onReceiver方法中執行完就銷燬,若是BroadcastReceiver的onReceiver方法中不能在10秒內執行完成,Android會出現ANR異常。因此不要在BroadcastReceiver的onReceiver方法中執行耗時的操做。 若是須要在BroadcastReceiver中執行耗時的操做,能夠經過Intent啓動Service來完成。但不能綁定Service。 若是咱們在Activity中註冊了BroadcastReceiver,當這個Activity銷燬的時候要主動撤銷註冊不然會出現異常。
Ref:http://blog.csdn.net/qq_27280457/article/details/51840678
Android廣播機制概述html
Android廣播分爲兩個方面:廣播發送者和廣播接收者,一般狀況下,BroadcastReceiver指的就是廣播接收者(廣播接收器)。app
廣播做爲Android組件間的通訊方式,可使用的場景以下:
1.同一app內部的同一組件內的消息通訊(單個或多個線程之間);異步
2.同一app內部的不一樣組件之間的消息通訊(單個進程);post
3.同一app具備多個進程的不一樣組件之間的消息通訊;.net
4.不一樣app之間的組件之間消息通訊;線程
5.Android系統在特定狀況下與App之間的消息通訊。code
從實現原理看上,Android中的廣播使用了觀察者模式,基於消息的發佈/訂閱事件模型。所以,從實現的角度來看,Android中的廣播將廣播的發送者和接受者極大程度上解耦,使得系統可以方便集成,更易擴展。具體實現流程要點粗略歸納以下:htm
1.廣播接收者BroadcastReceiver經過Binder機制向AMS(Activity Manager Service)進行註冊;對象
2.廣播發送者經過binder機制向AMS發送廣播;blog
3.AMS查找符合相應條件(IntentFilter/Permission等)的BroadcastReceiver,將廣播發送到BroadcastReceiver(通常狀況下是Activity)相應的消息循環隊列中;
4.消息循環執行拿到此廣播,回調BroadcastReceiver中的onReceive()方法。
對於不一樣的廣播類型,以及不一樣的BroadcastReceiver註冊方式,具體實現上會有不一樣。但整體流程大體如上。
由此看來,廣播發送者和廣播接收者分別屬於觀察者模式中的消息發佈和訂閱兩端,AMS屬於中間的處理中心。廣播發送者和廣播接收者的執行是異步的,發出去的廣播不會關心有無接收者接收,也不肯定接收者究竟是什麼時候才能接收到。顯然,總體流程與EventBus很是相似。
在上文說列舉的廣播機制具體可使用的場景中,現分析實際應用中的適用性:
第一種情形:同一app內部的同一組件內的消息通訊(單個或多個線程之間),實際應用中確定是不會用到廣播機制的(雖然能夠用),不管是使用擴展變量做用域、基於接口的回調仍是Handler-post/Handler-Message等方式,均可以直接處理此類問題,若適用廣播機制,顯然有些「殺雞牛刀」的感受,會顯太「重」;
第二種情形:同一app內部的不一樣組件之間的消息通訊(單個進程),對於此類需求,在有些教複雜的狀況下單純的依靠基於接口的回調等方式很差處理,此時能夠直接使用EventBus等,相對而言,EventBus因爲是針對統一進程,用於處理此類需求很是適合,且輕鬆解耦。能夠參見文件《Android各組件/控件間通訊利器之EventBus》。
第3、4、五情形:因爲涉及不一樣進程間的消息通訊,此時根據實際業務使用廣播機制會顯得很是適宜。
Ref:http://www.cnblogs.com/lwbqqyumidi/p/4168017.html