Android之粘性廣播理解

原文：http://blog.csdn.net/weidi1989/article/details/8016688

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

1. <receiver android:name=".IncomingSMSReceiver">  
2.      <intent-filter>  
3.           <action android:name="android.intent.action.BOOT_COMPLETED"/>  
4.           <action android:name="android.provider.Telephony.SMS_RECEIVED"/>  
5.      </intent-filter>  
6. </receiver>  

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

1. IntentFilter filter = new IntentFilter("android.provider.Telephony.SMS_RECEIVED");  
2. Receiver receiver = new Receiver();  
3. 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撥號等功能，明白上面的話實現起來就輕而易舉了。