Android之粘性廣播理解

銳湃發表於2015-08-31
Android

BroadcastReceiver，作為一個廣播接收者，因為android元件之間訊息的傳遞基於intent，所以廣播接收者想要接收什麼型別的廣播，將receiver標籤下的intent-filter標籤下的action標籤的值置為那個廣播型別即可，如

<receiver android:name=".IncomingSMSReceiver">
     <intent-filter>
          <action android:name="android.intent.action.BOOT_COMPLETED"/>
          <action android:name="android.provider.Telephony.SMS_RECEIVED"/>
     </intent-filter>
</receiver>

上面這段程式碼其實就註冊了兩個廣播接收的型別，系統開機啟動完成時的廣播和簡訊到來的廣播(注意加上簡訊接受許可權)都會被接收到，然後可以再onReceive()方法裡面寫上你想寫的程式碼了。
額外提個事，許可權問題一定要加上，現在的logcat裡面Permission denied的提示都不是紅色的了，改成橙色的，我還以為我這沒出問題，找了半天程式碼的問題，結果後來還是發現許可權配錯了，本來想攔截撥出的電話的，結果沒配許可權怎麼都拿不到資料啊，找了十幾分鍾。雖然相對前些天我找一個上午的許可權問題進步多了，但是我還是這麼認為，玩android許可權問題都要找個十來分鐘的話那就太2了。
除了在清單檔案中配置以外，也可以在程式碼中訂閱

IntentFilter filter = new IntentFilter("android.provider.Telephony.SMS_RECEIVED");
Receiver receiver = new Receiver();
registerReceiver(receiver, filter);

Receiver是你自己寫的繼承自BroadcastReceiver的類。IntentFilter就對應著Action啦。
還有一個細節是sendBroadcast的三種傳送方法。
sendBroadcast(),sendOrderedBroadcast()和sendStickyBroadcast()

sendBroadcast()這個方法的廣播是能夠傳送給所有廣播接收者，按照註冊的先後順序，如果你這個時候設定了廣播接收者的優先順序，優先順序如果恰好與註冊順序相同，則不會有任何問題，如果順序不一樣，會出leaked IntentReceiver 這樣的異常，並且在前面的廣播接收者不能呼叫abortBroadcast()方法將其終止，如果呼叫會出BroadcastReceiver trying to return result during a non-ordered broadcast的異常，當然，先接收到廣播的receiver可以修改廣播資料。


sendOrderedBroadcast()方法顧名思義就是priority的屬效能起作用，並且在佇列前面的receiver可以隨時終止廣播的傳送。還有這個api能指定final的receiver，這個receiver是最後一個接收廣播時間的receiver，並且一定會接收到廣播事件，是不能被前面的receiver攔截的。實際做實驗的情況是這樣的，假設我有3個receiver依序排列，並且sendOrderedBroadcast()方法指定了一個finalReceiver，那麼intent傳遞給這4個Receiver的順序為Receiver1-->finalReceiver-->Receiver2-->finalReceiver-->Receiver3-->finalReceiver。這個特性可以用來統計系統中能監聽某種廣播的Receiver的數目。


sendStickyBroadcast()字面意思是傳送粘性的廣播，使用這個api需要許可權android.Manifest.permission.BROADCAST_STICKY,粘性廣播的特點是Intent會一直保留到廣播事件結束，而這種廣播也沒有所謂的10秒限制，10秒限制是指普通的廣播如果onReceive方法執行時間太長，超過10秒的時候系統會將這個廣播置為可以幹掉的candidate，一旦系統資源不夠的時候，就會幹掉這個廣播而讓它不執行。
下面是廣播接收者的生命週期以及一些細節部分：
1.廣播接收者的生命週期是非常短暫的，在接收到廣播的時候建立，onReceive()方法結束之後銷燬
2.廣播接收者中不要做一些耗時的工作，否則會彈出Application No Response錯誤對話方塊
3.最好也不要在廣播接收者中建立子執行緒做耗時的工作，因為廣播接收者被銷燬後程式就成為了空程式，很容易被系統殺掉
4.耗時的較長的工作最好放在服務中完成
至於廣播接收者接收使用者的簡訊，實現ip撥號等功能，明白上面的話實現起來就輕而易舉了。


轉自：http://blog.csdn.net/way_ping_li/article/details/8016688

相關文章