一、問題

最近遇到一個(gè)問題，發(fā)送廣播（普通廣播）給另一個(gè)應(yīng)用，但是廣播需要要等約1min后才收到。

二、分析原因

原因是系統(tǒng)有個(gè)廣播接收器在接收到廣播后處理了接近50s，所以阻塞了后面的廣播處理。如果大家也出現(xiàn)了廣播阻塞問題，想知道廣播到底堵塞到哪里？這里先給大家分享下這個(gè)問題分析方法：

1、首先，串口設(shè)置輸出log轉(zhuǎn)存到a.txt文件中（名字隨意取），然后在串口打印下面的指令，等一會(huì)將所有的廣播信息收集起來。

dumpsys activity broadcasts

2、然后，根據(jù)自己堵塞的廣播名稱在a.txt文件進(jìn)行過濾，如下代碼所示，有三次發(fā)送。

Line 10070:   #102: act=com.xx.xxx.SHUTDOWN flg=0x10 (has extras)
Line 10078:   #104: act=com.xx.xxx.SHUTDOWN flg=0x10 (has extras)
Line 11031:   #207: act=com.xx.xxx.SHUTDOWN flg=0x10 (has extras)

3、根據(jù)過濾出的三次廣播信息，每一條挨個(gè)返回a.txt原log中查看下處理的時(shí)間，原log信息如下。從時(shí)間上看，第一次#207是正常的，在#104的時(shí)候出現(xiàn)了問題，耗時(shí)：50s426ms。

#102: act=com.xx.xxx.SHUTDOWN flg=0x10 (has extras)+46s57ms dispatch +4ms finishenq=2023-08-09 11:20:36.769 disp=2023-08-09 11:21:22.826 fin=2023-08-09 11:21:22.830extras: Bundle[{STRIPPED=1}]#104: act=com.xx.xxx.SHUTDOWN flg=0x10 (has extras)+50s426ms dispatch +4ms finishenq=2023-08-09 11:20:32.269 disp=2023-08-09 11:21:22.695 fin=2023-08-09 11:21:22.699extras: Bundle[{STRIPPED=1}]#207: act=com.xx.xxx.SHUTDOWN flg=0x10 (has extras)0 dispatch +5ms finishenq=2023-08-09 11:19:06.225 disp=2023-08-09 11:19:06.225 fin=2023-08-09 11:19:06.230extras: Bundle[{STRIPPED=1}]

4、然后在a.txt文件過濾dispatch關(guān)鍵字，在第三步分析在#104的時(shí)候出現(xiàn)了問題，從第二步可以看到#104出現(xiàn)在Line 10078行，然后在過濾出的dispatch的信息中，找到10078行，然后往下找，找到第一個(gè)時(shí)間比較長(zhǎng)的廣播，從下面log看，應(yīng)該是Line 10132行的廣播堵塞了，返回a.txt文件可以找到對(duì)應(yīng)的廣播信息。

Line 10071:     +46s57ms dispatch +4ms finish
Line 10075:     +48s292ms dispatch +127ms finish
Line 10079:     +50s426ms dispatch +4ms finish
Line 10083:     +53s166ms dispatch +121ms finish
...
Line 10132:     +48s652ms dispatch +43s360ms finish
Line 10135:     0 dispatch 0 finish
Line 10178:     0 dispatch +1ms finish

5、找到堵塞的廣播后，以該廣播為關(guān)鍵字在a.txt文件中再次進(jìn)行篩選，可找到注冊(cè)該廣播的包名，進(jìn)而可以找到堵塞的進(jìn)程和應(yīng)用。此時(shí)備注下log分析，把bug分出去就行了。這也是為啥，不能再onReceive中有耗時(shí)操作的原因。