【威哥說】Android界面間傳輸數(shù)據(jù)方式有很多嫉入，除了傳統(tǒng)的接口回調(diào)焰盗、構(gòu)造等方式，Google系統(tǒng)給我們內(nèi)置了一種叫做廣播的機(jī)制咒林，如同名字熬拒，也就是全局的發(fā)送，使用intent可以攜帶各種數(shù)據(jù)垫竞。那么它的原理是什么澎粟？那些細(xì)節(jié)需要我們注意？下面件甥，我們一起來(lái)看Android 廣播的使用捌议。
【正文】
BroadcastReceiver，是一個(gè)廣播接收者引有，因?yàn)閍ndroid組件之間消息的傳遞基于intent瓣颅，所以廣播接收者想要接收什么類型的廣播，將receiver標(biāo)簽下的intent-filter標(biāo)簽下的action標(biāo)簽的值置為那個(gè)廣播類型即可譬正。
除了清單文件中以外宫补，也可以直接在代碼中訂閱：
IntentFilter filter = new IntentFilter("android.provider.Telephony.SMS_RECEIVED");
Receiver receiver = new Receiver();
registerReceiver(receiver, filter);
Receiver是你自己寫的繼承自BroadcastReceiver的類。IntentFilter就對(duì)應(yīng)著Action曾我，這里看到filter和上面清單文件中的一樣粉怕。
還有一個(gè)細(xì)節(jié)是sendBroadcast的三種發(fā)送方法。
sendBroadcast(),
sendOrderedBroadcast()
sendStickyBroadcast()
sendBroadcast()這個(gè)方法的廣播是能夠發(fā)送給所有廣播接收者抒巢，按照注冊(cè)的先后順序贫贝，如果你這個(gè)時(shí)候設(shè)置了廣播接收者的優(yōu)先級(jí)，優(yōu)先級(jí)如果恰好與注冊(cè)順序相同，則不會(huì)有任何問題稚晚，如果順序不一樣崇堵，會(huì)出leaked IntentReceiver 這樣的異常，并且在前面的廣播接收者不能調(diào)用abortBroadcast()方法將其終止客燕，如果調(diào)用會(huì)出BroadcastReceiver trying to return result during a non-ordered broadcast的異常鸳劳，當(dāng)然，先接收到廣播的receiver可以修改廣播數(shù)據(jù)也搓。
sendOrderedBroadcast()方法顧名思義就是priority的屬性能起作用赏廓，并且在隊(duì)列前面的receiver可以隨時(shí)終止廣播的發(fā)送。還有這個(gè)api能指定final的receiver傍妒，這個(gè)receiver是最后一個(gè)接收廣播時(shí)間的receiver幔摸，并且一定會(huì)接收到廣播事件，是不能被前面的receiver攔截的拍顷。實(shí)際做實(shí)驗(yàn)的情況是這樣的抚太，假設(shè)我有3個(gè)receiver依序排列，并且sendOrderedBroadcast()方法指定了一個(gè)finalReceiver昔案，那么intent傳遞給這4個(gè)Receiver的順序?yàn)镽eceiver1-->finalReceiver-->Receiver2-->finalReceiver-->Receiver3-->finalReceiver尿贫。這個(gè)特性可以用來(lái)統(tǒng)計(jì)系統(tǒng)中能監(jiān)聽某種廣播的Receiver的數(shù)目。
sendStickyBroadcast()字面意思是發(fā)送粘性的廣播踏揣，使用這個(gè)api需要權(quán)限android.Manifest.permission.BROADCAST_STICKY,粘性廣播的特點(diǎn)是Intent會(huì)一直保留到廣播事件結(jié)束庆亡，而這種廣播也沒有所謂的10秒限制，10秒限制是指普通的廣播如果onReceive方法執(zhí)行時(shí)間太長(zhǎng)捞稿，超過10秒的時(shí)候系統(tǒng)會(huì)將這個(gè)廣播置為可以干掉的candidate又谋，一旦系統(tǒng)資源不夠的時(shí)候，就會(huì)干掉這個(gè)廣播而讓它不執(zhí)行娱局。
下面是廣播接收者的生命周期以及一些細(xì)節(jié)部分：
1.廣播接收者的生命周期是非常短暫的彰亥，在接收到廣播的時(shí)候創(chuàng)建，onReceive()方法結(jié)束之后銷毀衰齐；
2.廣播接收者中不要做一些耗時(shí)的工作任斋，否則會(huì)彈出Application No Response錯(cuò)誤對(duì)話框；
3.最好也不要在廣播接收者中創(chuàng)建子線程做耗時(shí)的工作耻涛，因?yàn)閺V播接收者被銷毀后進(jìn)程就成為了空進(jìn)程废酷，很容易被系統(tǒng)殺掉；
4.耗時(shí)的較長(zhǎng)的工作最好放在服務(wù)中完成抹缕。
