標籤:自己 建立 時間 就會 文章 adc 應用程式 tin 錯誤
又是一篇基礎總結性的文章來啦,個人強迫症犯了,非得把部落格的四大組件模組給補齊了,總結了一下BoradcastReceiver的各種使用,廢話不多說,開車啦。博主建議自己敲一遍代碼來理解廣播,因為裡面有很多細節的東西需要注意,在學習中博主也犯過一些低級錯誤,不然以後到大項目中,不牢牢掌握好基礎,會浪費很多時間在這上面。或者認真閱讀本篇文章內容
BroadcastReceiver翻譯為廣播接收者,Broadcast是一種廣泛運用在應用程式之間的傳輸資訊的機制,簡單的可以理解為傳統意義上的電台廣播,通俗一點,發布失物招領
廣播機制是一個典型的發布—訂閱模式,也就是我們所說的觀察者模式。廣播最大的特點就是發送方並不關心接收方是否接到資料,也不關心接收方是如何處理資料的,通過這樣的形式來達到接、收雙方的完全解耦合
普通廣播是完全非同步,通過Context的sendBroadcast()方法來發送,訊息傳遞效率比較高,但所有receivers(接收器)的執行順序不確定。缺點是:接收者不能將處理結果傳遞給下一個接收者,並且無法終止廣播Intent的傳播,直到沒有與之匹配的廣播接收器為止。下面以自訂的普通廣播進行示範
一、建立廣播
建立廣播非常簡單,只要繼承BroadcastReceiver並實現onReceive()方法
二、註冊廣播
BroadcastReceiver是四大組件之一,所以毫不疑問需要註冊,BroadcastReceiver的註冊有兩種方法:
1、方法一:通過manifests配置
這裡需要加入intent-filter的action中的name屬性,表示我們監聽的內容。當有廣播發送時,需要判斷該廣播是否和我們監聽的內容一致,如果一致則接收
2、方法二:通過代碼動態配置
三、反註冊廣播
如果你是使用動態註冊廣播的則需要在Activity的onDestroy的時候反註冊廣播
四、發送廣播
這裡我們以一個按鈕來發送廣播,通過sendBroadcast()方法發送我們的建立的Intent自訂廣播
五、運行代碼
運行程式後,我們點擊發送廣播。我們以Log資訊來驗證發出的廣播被我們準確的接收
有序廣播通過Context.sendOrderedBroadcast()來發送,所有的廣播接收器優先順序依次執行,廣播接收器的優先順序通過receiver的intent-filter中的android:priority屬性來設定,數值越大優先順序越高。
當廣播接收器接收到廣播後,可以使用setResult()函數來結果傳給下一個廣播接收器接收,然後通過getResult()函數來取得上個廣播接收器接收返回的結果。當廣播接收器接收到廣播後,也可以用abortBroadcast()函數來讓系統攔截下來該廣播,並將該廣播丟棄,使該廣播不再傳送到別的廣播接收器接收
一、建立廣播
我們建立一個類,存放三個有優先順序的廣播接收者,並在最進階廣播中傳遞結果到下一個廣播
要注意的是:
- 內部類的BroadcastReceiver必須由public static修飾,否則會報錯
二、註冊廣播
這裡的註冊方式和普通廣播是一樣的,這裡的區別在於priority屬性,確定了他們之間的優先順序
要注意的是:
- BroadcastReceiver類名與內部類的名字之間用$符號隔開,否則會報錯
三、發送廣播
和之前的不一樣的地方,這裡是使用sendOrderedBroadcast()發送有序廣播
要注意的是:
- 這裡需要發送的是有序廣播,否則在接收者中通過setResult()和getResult()方法會報錯,因為只有有序廣播才能傳遞結果
四、運行代碼
運行程式後,我們點擊發送廣播。我們以Log資訊來驗證發出的廣播被我們準確的接收,資料被我們準確的傳遞
上面我們提到過有序廣播中可以攔截廣播,那麼我們在上面程式的基礎上修改代碼,中老年服裝在HighPriority接收器中加上攔截廣播
一、建立廣播
通過在BroadcastReceiver中,執行abortBroadcast()方法,廣播就不會繼續往下傳遞了
二、運行代碼
運行程式後,我們點擊發送廣播。我們以Log資訊來驗證我們攔截了廣播
可以看到,後面的Mid和Low廣播都沒有Log資訊,說明我們攔截成功了
三、有序廣播、攔截廣播的拓展——終結廣播
現在有這樣的一個應用情境,按照上面的程式走,只能在第一個廣播中被攔截住了,後面的廣播則不執行。如果這個時候我們需要一個不管有沒有被攔截都必須執行的廣播,我們稱為終結廣播,那應該怎麼辦。同樣的,發送有序廣播也考慮到這一點,通過以下代碼來發送廣播,並指定我們不管有沒有被攔截都必須執行的終結廣播
運行代碼,我們查看Log資訊
可以發現,之前只是有High的Log資訊,因為是被攔截了,而Log資訊多了一條Low,說明我們攔截後,還要執行終結廣播
在API21的Support v4包中新增本地廣播,也就是LocalBroadcastManager。由於之前的廣播都是全域的,所有應用程式都可以接收到,這樣就會帶來安全隱患,所以我們使用LocalBroadcastManager只發送給自己應用內的資訊廣播,限制在進程內使用
它的用法很簡單,只需要把調用context的sendBroadcast、registerReceiver、unregisterReceiver的地方換為LocalBroadcastManager.getInstance(Context context)中對應的函數即可。這裡建立廣播的過程和普通廣播是一樣的過程,這裡就不過多介紹了
一、註冊Receiver
二、反註冊Receiver
三、發送非同步廣播
四、發送同步廣播
sticky廣播通過Context.sendStickyBroadcast()函數來發送,用此函數發送的廣播會一直滯留,當有匹配此廣播的廣播接收器被註冊後,該廣播接收器就會收到此條資訊。使用此函數需要發送廣播時,需要獲得BROADCAST_STICKY許可權
sendStickyBroadcast只保留最後一條廣播,並且一直保留下去,這樣即使已經有廣播接收器處理了該廣播,當再有匹配的廣播接收器被註冊時,此廣播仍會被接收。如果你只想處理一遍該廣播,可以通過removeStickyBroadcast()函數來實現。這裡建立廣播的過程和普通廣播是一樣的過程,這裡就不過多介紹了
當然系統中也會有很多內建的廣播,當符合一定條件時,系統會發送一些定義好的廣播,比如:重啟、充電、來電電話等等。我們可以通過action屬性來監聽我們的系統廣播
這裡建立廣播的過程和普通廣播是一樣的過程,這裡就不過多介紹了。常用的廣播action屬性有
- 螢幕被關閉之後的廣播:Intent.ACTION_SCREEN_OFF
- 螢幕被開啟之後的廣播:Intent.ACTION_SCREEN_ON
- 充電狀態,或者電池的電量發生變化:Intent.ACTION_BATTERY_CHANGED
- 關閉或開啟飛航模式時的廣播:Intent.ACTION_AIRPLANE_MODE_CHANGED
- 表示電池電量低:Intent.ACTION_BATTERY_LOW
- 表示電池電量充足,即電池電量飽滿時會發出廣播:Intent.ACTION_BATTERY_OKAY
- 按下照相時的拍照按鍵(硬體按鍵)時發出的廣播:Intent.ACTION_CAMERA_BUTTON
Android四大組件——BroadcastReceiver普通廣播、有序廣播、攔截廣播、本地廣播、Sticky廣播、系統廣播