一，基本概念
１．廣播隊(duì)列
安卓原生有兩個(gè)廣播隊(duì)列，在AMS中初始化，由構(gòu)造函數(shù)可以看出５個(gè)構(gòu)造參數(shù)意義
前臺(tái)廣播隊(duì)列：mFgBroadcastQueue = new BroadcastQueue(this, mHandler,
"foreground", BROADCAST_FG_TIMEOUT, false)
后臺(tái)廣播隊(duì)列：mBgBroadcastQueue = new BroadcastQueue(this, mHandler,
"background", BROADCAST_BG_TIMEOUT, true);
BroadcastQueue(ActivityManagerService service, Handler handler,
String name, long timeoutPeriod, boolean allowDelayBehindServices) {
mService = service;
mHandler = new BroadcastHandler(handler.getLooper());
mQueueName = name;//廣播隊(duì)列名字
mTimeoutPeriod = timeoutPeriod;//延遲時(shí)間(前臺(tái):10s? 后臺(tái):60s)
mDelayBehindServices = allowDelayBehindServices;
}
二.廣播發(fā)送
廣播發(fā)送者可以決定：
１.通過(guò)設(shè)置flag來(lái)決定是否為前臺(tái)廣播，默認(rèn)是后臺(tái)廣播
2.有序廣播還是無(wú)序廣播。
三.廣播接收器注冊(cè)
3.1靜態(tài)注冊(cè):在manifest文件中注冊(cè)的廣播接收器
3.2動(dòng)態(tài)注冊(cè):context.registerReceiver()注冊(cè)的廣播接收器
四.廣播分發(fā)(調(diào)度)
4.1廣播分發(fā)是AMS調(diào)度的
無(wú)序廣播：首先是將無(wú)序的廣播一次全部分發(fā)給他的動(dòng)態(tài)接收者(如果該廣播有動(dòng)態(tài)注冊(cè)的接收器)，不阻塞，無(wú)延遲。其次將廣播依次發(fā)送給它的靜態(tài)注冊(cè)者。
會(huì)阻塞，有延遲。
有序廣播：不管接收者是動(dòng)態(tài)注冊(cè)還是靜態(tài)注冊(cè)，都是依次分發(fā)。
從系統(tǒng)的角度理解：對(duì)于無(wú)序廣播，動(dòng)態(tài)注冊(cè)的接收器所在的進(jìn)程都活著，系統(tǒng)不用起大量的線程，直接將廣播發(fā)送給接收者，執(zhí)行相關(guān)業(yè)務(wù)邏輯，但是對(duì)于無(wú)序廣播的
靜態(tài)接收者，其所在的進(jìn)程有可能沒(méi)有起來(lái)，系統(tǒng)為了避免短時(shí)間拉起很多進(jìn)程，增加系統(tǒng)負(fù)擔(dān)，采用了依次分發(fā)。對(duì)于有序廣播，不管其接收者是動(dòng)態(tài)靜態(tài)都是按照順序分發(fā)。
4.2分發(fā)過(guò)程中遇到的延遲以及廣播執(zhí)行過(guò)程中的ANR
對(duì)于依次分發(fā)的廣播(包括有序和無(wú)序)，若果一個(gè)廣播發(fā)生了延遲，勢(shì)必會(huì)導(dǎo)致后續(xù)的廣播延遲發(fā)送，這樣會(huì)導(dǎo)致廣播接收者延遲接收，對(duì)那些依賴于廣播的UI交互，體驗(yàn)變得
非常差，比如：一個(gè)progressDialog的消失依賴與一個(gè)廣播，這個(gè)廣播延遲發(fā)送，導(dǎo)致一直等待狀態(tài)。
ANR:
1.廣播的處理是在onReceive中，該回調(diào)是在app的主線程中，如果做了耗時(shí)操作，勢(shì)必會(huì)導(dǎo)致ANR,所以主線程最好只做UI相關(guān)的業(yè)務(wù)，這也是為什么主線程也叫UI線程
2.對(duì)于有序廣播， AMS,AMS收到反饋之后接著調(diào)度下一個(gè)receiver，這種場(chǎng)景下，即使在onreceiver()中開(kāi)啟一個(gè)工作線程去處理業(yè)務(wù)，也可能會(huì)導(dǎo)致ANR，開(kāi)啟該工作線程的作用只是讓主線程不阻塞，但是工作線程如果是耗時(shí)的，如果回調(diào)AMS時(shí)超過(guò)timeout(10s或60s)，則AMS會(huì)讓你的app ANR。
4.3對(duì)于以上問(wèn)題的改進(jìn)
(1) 由當(dāng)前BroadcastReceiver啟動(dòng)新的Service，在新的Service中操作
=>?再啟動(dòng)一個(gè)service,?并非好的方式,?? 正確姿勢(shì):?直接post message到異步handler thread.
(2) 使用goAsync(), 將操作在異步線程中執(zhí)行
==>goAsync只是采用異步,?可以做到不阻塞app的主線程解決部分問(wèn)題, 依然阻塞廣播分發(fā). 無(wú)法解決問(wèn)題,
(3) 在特殊的場(chǎng)景下，廣播阻塞也許會(huì)影響電話、短信等基礎(chǔ)體驗(yàn)，如果不加以規(guī)范控制，后果會(huì)很嚴(yán)重。
==> a.影響電話/短信, 如果電話/短信的實(shí)現(xiàn)方式是要等待串行廣播的onReceive才往下走的話, 那的確會(huì)阻塞, ?但這種情況電話/短信應(yīng)該考慮修改實(shí)現(xiàn)方式;
b. 更多的影響電話/短信的場(chǎng)景, 可能是系統(tǒng)比較繁忙, 比如ams同步鎖搶占比較嚴(yán)重.
(4) 系統(tǒng)廣播的頻繁注冊(cè)和使用問(wèn)題, 以及如何減少?gòu)V播anr
==> 針對(duì)這個(gè)問(wèn)題: ?我說(shuō)幾點(diǎn)建議
(a)?app可以盡可能將自己的實(shí)現(xiàn)采用異步架構(gòu);
(b)?如果只是自己app內(nèi)的通信, 應(yīng)該采用LocalBroadcastManager 來(lái)替代BroadcastReceiver;
(c) 合理使用SharedPreferences, 并非把所有的操作commit改為apply, 就解決了anr.
正確的姿勢(shì)是減少頻繁的commit/apply操作, 盡可能批量化;以及合理的拆分sp文件,
因?yàn)槊恳淮蝧p參數(shù)的commit/apply, 都是全量寫(xiě)文件, 而非增量寫(xiě).
(d) 不要濫用廣播, 更不要什么廣播都監(jiān)聽(tīng), 只為做一個(gè)統(tǒng)計(jì)的功能...
五.進(jìn)程內(nèi)的廣播
localbroadcast
