android廣播服務
⑴ Android 第六講 廣播接收器和服務
兩種方式：靜態注冊和動態注冊
動態注冊：
1）動態注冊：需要定義一個繼承自BroadcastReceiver類的子類，該接收器需要在Activity中的onDestroy中注銷
2）靜態注冊：通過在AndroidManifest.xml中配置
兩種廣播形式：有序廣播和無序廣播
1）無序廣播：接受標准廣播的接收器將同時收到廣播消息，非同步執行，沒有先後順序 sendBroadCast
2）有序廣播：sendOrderedBroadCast，按照一定順序先後被接受順序，由priority屬性決定，abortBroadCast中斷廣播
如果只想在本應用中發送和接受廣播，使用LocalBroadcastReceiver來對廣播進行管理
本地廣播不支持靜態注冊
優點 ：安全高效
Service是Android中的一種組件，和Activity的級別一致，但不能自己運行，只能後台運行，和其他組件交互，服務必須注冊才能使用
本地服務：服務依附在主線程中，節約資源，主線程死掉服務終止
遠程服務：服務在獨立進程中，靈活性好 ，佔用資源高
兩種服務的啟動模式：
1）start方式：調用者和服務之間沒有關聯，調用者退出不會影響服務，startService啟動服務，如果服務不存在，調用onCreat方法，然後onStartCommand被調用。stopService關閉服務，onDestroy方法被調用
2）bind方式：調用者和服務綁定，調用者退出，服務終止bindService啟動服務，onCreate方法創建服務，onBind方法綁定服務，onUnbind方法解綁，onDestory在服務結束時調用
⑵ Android本地廣播的使用
為了解決廣播的安全性問題，Android引入了本地廣播機制，使用該機制發出的廣播只能在應用程序的內部進行傳遞，並且廣播接收器也只能接收來自本應用程序發出的廣播。
本地廣播是無法通過靜態注冊的方式來接收的。我們知道靜態注冊主要是為了在程序未啟動的情況下能接收廣播，而當我們發送本地廣播的時候，程序肯定是已經啟動的了，所以我們需要動態注冊方式創建接收器。
在這里我們創建一個繼承於BroadcastReceiver的類LocalReceiver。onReceive()處理你接收到的廣播內容，在這里我用Toast來創建一個提示接收到消息的彈窗
在activity_main.xml文件創建一個用於發送廣播的按鈕
首先通過本地廣播管理器LocalBroadcastManager的getInstance()方法獲取一個實例，並分別創建過濾器IntentFilter和自定義接收器LocalReceiver的實例。給IntentFilter的實例添加一個action：localbroadcast（接收的廣播的名稱），然後調用LocalBroadcastManager的registerReceiver()方法進行注冊，並將LocalReceiver的實例和IntentFilter的實例都傳進去。這樣本地監聽器就創建完成了。
調用LocalBroadcastManager的sendBroadcast()發送本地廣播。運行程序，點擊Send Button按鈕，我們可以看到彈窗顯示「This is in LocalReceiver」，說明本地廣播發送和接收成功了。
當然，我們最後一定不要忘了取消注冊。我們可以通過調用unregisterReceiver()方法來實現。至此，Android的標准廣播發送就完成了。
1.發送的廣播只能在本程序內傳遞，不必擔心數據泄露
2.其它程序廣播無法發送到本程序的內部，不必擔心安全漏洞隱患
3.本地廣播比系統全局廣播更加高效
⑶ Android開發中廣播的作用及注冊方式,
廣播是一種運用的在應用程序之間傳輸信息的機制。而BroadcastReceiver 是對發送出來的Broadcast進行過濾接受並響應的一類組件。廣播既可以在清單文件AndroidManifest.xml 中注冊，也可以在運行時的代碼中使用Context.registerReceiver（)進行注冊。只要是注冊了，當事件來臨的時候，即使程序沒有啟動，系統也在需要的時候啟動程序。
⑷ 22 AndroidBroadcast廣播機制
廣播(Broadcast)機制用於進程/線程間通信，廣播分為廣播發送和廣播接收兩個過程，其中廣播接收者BroadcastReceiver便是Android四大組件之一。
BroadcastReceiver分為兩類：
從廣播發送方式可分為三類：
廣播在系統中以BroadcastRecord對象來記錄, 該對象有幾個時間相關的成員變數.
廣播注冊，對於應用開發來說，往往是在Activity/Service中調用 registerReceiver() 方法，而Activity或Service都間接繼承於Context抽象類，真正幹活是交給ContextImpl類。另外調用getOuterContext()可獲取最外層的調用者Activity或Service。
[ContextImpl.java]
其中broadcastPermission擁有廣播的許可權控制，scheler用於指定接收到廣播時onRecive執行線程，當scheler=null則默認代表在主線程中執行，這也是最常見的用法
[ContextImpl.java]
ActivityManagerNative.getDefault()返回的是ActivityManagerProxy對象，簡稱AMP.
該方法中參數有mMainThread.getApplicationThread()返回的是ApplicationThread，這是Binder的Bn端，用於system_server進程與該進程的通信。
[-> LoadedApk.java]
不妨令 以BroadcastReceiver(廣播接收者)為key，LoadedApk.ReceiverDispatcher(分發者)為value的ArrayMap 記為 A 。此處 mReceivers 是一個以 Context 為key，以 A 為value的ArrayMap。對於ReceiverDispatcher(廣播分發者)，當不存在時則創建一個。
此處mActivityThread便是前面傳遞過來的當前主線程的Handler.
ReceiverDispatcher(廣播分發者)有一個內部類 InnerReceiver ，該類繼承於 IIntentReceiver.Stub 。顯然，這是一個Binder服務端，廣播分發者通過rd.getIIntentReceiver()可獲取該Binder服務端對象 InnerReceiver ，用於Binder IPC通信。
[-> ActivityManagerNative.java]
這里有兩個Binder服務端對象 caller 和 receiver ，都代表執行注冊廣播動作所在的進程. AMP通過Binder驅動將這些信息發送給system_server進程中的AMS對象，接下來進入AMS.registerReceiver。
[-> ActivityManagerService.java]
其中 mRegisteredReceivers 記錄著所有已注冊的廣播，以receiver IBinder為key, ReceiverList為value為HashMap。
在BroadcastQueue中有兩個廣播隊列mParallelBroadcasts,mOrderedBroadcasts，數據類型都為ArrayList<broadcastrecord style="box-sizing: border-box;">：</broadcastrecord>
mLruProcesses數據類型為 ArrayList<ProcessRecord> ，而ProcessRecord對象有一個IApplicationThread欄位，根據該欄位查找出滿足條件的ProcessRecord對象。
該方法用於匹配發起的Intent數據是否匹配成功，匹配項共有4項action, type, data, category，任何一項匹配不成功都會失敗。
broadcastQueueForIntent(Intent intent)通過判斷intent.getFlags()是否包含FLAG_RECEIVER_FOREGROUND 來決定是前台或後台廣播，進而返回相應的廣播隊列mFgBroadcastQueue或者mBgBroadcastQueue。
注冊廣播：
另外，當注冊的是Sticky廣播：
廣播注冊完, 另一個操作便是在廣播發送過程.
發送廣播是在Activity或Service中調用 sendBroadcast() 方法，而Activity或Service都間接繼承於Context抽象類，真正幹活是交給ContextImpl類。
[ContextImpl.java]
[-> ActivityManagerNative.java]
[-> ActivityManagerService.java]
broadcastIntent()方法有兩個布爾參數serialized和sticky來共同決定是普通廣播，有序廣播，還是Sticky廣播，參數如下：
broadcastIntentLocked方法比較長，這里劃分為8個部分來分別說明。
這個過程最重要的工作是：
BroadcastReceiver還有其他flag，位於Intent.java常量:
主要功能：
這個過主要處於系統相關的10類廣播,這里不就展開講解了.
這個過程主要是將sticky廣播增加到list，並放入mStickyBroadcasts裡面。
其他說明：
AMS.collectReceiverComponents ：
廣播隊列中有一個成員變數 mParallelBroadcasts ，類型為ArrayList<broadcastrecord style="box-sizing: border-box;">，記錄著所有的並行廣播。</broadcastrecord>
動態注冊的registeredReceivers，全部合並都receivers，再統一按串列方式處理。
廣播隊列中有一個成員變數 mOrderedBroadcasts ，類型為ArrayList<broadcastrecord style="box-sizing: border-box;">，記錄著所有的有序廣播。</broadcastrecord>
發送廣播過程:
處理方式：
可見不管哪種廣播方式，都是通過broadcastQueueForIntent()來根據intent的flag來判斷前台隊列或者後台隊列，然後再調用對應廣播隊列的scheleBroadcastsLocked方法來處理廣播；
在發送廣播過程中會執行 scheleBroadcastsLocked 方法來處理相關的廣播
[-> BroadcastQueue.java]
在BroadcastQueue對象創建時，mHandler=new BroadcastHandler(handler.getLooper());那麼此處交由mHandler的handleMessage來處理：
由此可見BroadcastHandler採用的是」ActivityManager」線程的Looper
[-> BroadcastQueue.java]
此處mService為AMS，整個流程還是比較長的，全程持有AMS鎖，所以廣播效率低的情況下，直接會嚴重影響這個手機的性能與流暢度，這里應該考慮細化同步鎖的粒度。
⑸ 在android中服務機制來做什麼發簡訊為什麼需要廣播
Service，後台運行，可交互這樣的一個東西。它跟Activity的級別差不多，但是他不能自己運行，需要通過某一個Activity或者其他Context對象來調用。
什麼時候需要Service呢？比如播放多媒體的時候用戶啟動了其他Activity這個時候程序要在後台繼續播放，比如檢測SD卡上文件的變化，再或者在後台記錄你地理信息位置的改變等等，總是藏在後頭的。
Broadcast 實質就是（發送方）並不在意（接收方）接收到廣播時如何處理。Android 中有各式各樣的廣播，各種廣播在Android 系統中運行，當系統/應用程序運行時便會向 Android 注冊各種廣播，Android 接收到廣播會便會判斷哪種廣播需要哪種事件，然後向不同需要事件的應用程序注冊事件，不同的廣播可能處理不同的事件也可能處理相同的廣播事件，這時就需要Android 系統為我們做篩選。
你要了解的是這個方法吧：public void sendTextMessage (String destinationAddress, String scAddress, String text, PendingIntent sentIntent, PendingIntent deliveryIntent)
destinationAddress： 收件人地址
scAddress： 簡訊中心號碼，null為默認中心號碼
sentIntent： 當消息發出時，成功或者失敗的信息報告通過PendingIntent來廣播。如果該參數為空，則發信程序會被所有位置程序檢查一遍，這樣會導致發送時間延長。
deliveryIntent： 當消息發送到收件人時，該PendingIntent會被廣播。p數據在狀態報告的extended data ("p")中。
如果收件人或者信息為空則拋出 IllegalArgumentException 。
⑹ android的廣播和service有什麼區別啊
廣播的周期很短，你不能在廣播內做耗時操作，而服務卻能。廣播的作用是幫你傳遞一些通知，例如你寫了一個開機廣播，一旦手機開機，廣播就發一則通知告訴手機（你寫的程序），手機（你寫的程序，某個類，某句代碼）啟動服務，這個時候在服務裡面可以做你想做的耗時操作，例如去請求伺服器，載入數據。廣播和服務的區別就是廣播周期短，不能做耗時操作，服務是長時間連接，可以做耗時操作，例如用服務控制音樂的播放等。廣播需要注冊，有兩種方式，一個在配置文件裡面，一個是代碼注冊、服務是寫一個類繼承服務，然後在裡面寫你的操作，外圍實例化服務，去啟動服務。