一、问题
最近遇到一个问题，发送广播（普通广播）给另一个应用，但是广播需要要等约1min后才收到。
二、分析原因
原因是系统有个广播接收器在接收到广播后处理了接近50s，所以阻塞了后面的广播处理。如果大家也出现了广播阻塞问题，想知道广播到底堵塞到哪里？这里先给大家分享下这个问题分析方法：
1、首先，串口设置输出log转存到a.txt文件中（名字随意取），然后在串口打印下面的指令，等一会将所有的广播信息收集起来。
java
复制代码
dumpsys activity broadcasts
2、然后，根据自己堵塞的广播名称在a.txt文件进行过滤，如下代码所示，有三次发送。
java
复制代码
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、根据过滤出的三次广播信息，每一条挨个返回a.txt原log中查看下处理的时间，原log信息如下。从时间上看，第一次#207是正常的，在#104的时候出现了问题，耗时：50s426ms。
java
复制代码
#102: act=com.xx.xxx.SHUTDOWN flg=0x10 (has extras)
+46s57ms dispatch +4ms finish
enq=2023-08-09 11:20:36.769 disp=2023-08-09 11:21:22.826 fin=2023-08-09 11:21:22.830
extras: Bundle[{STRIPPED=1}]
#104: act=com.xx.xxx.SHUTDOWN flg=0x10 (has extras)
+50s426ms dispatch +4ms finish
enq=2023-08-09 11:20:32.269 disp=2023-08-09 11:21:22.695 fin=2023-08-09 11:21:22.699
extras: Bundle[{STRIPPED=1}]
#207: act=com.xx.xxx.SHUTDOWN flg=0x10 (has extras)
0 dispatch +5ms finish
enq=2023-08-09 11:19:06.225 disp=2023-08-09 11:19:06.225 fin=2023-08-09 11:19:06.230
extras: Bundle[{STRIPPED=1}]
4、然后在a.txt文件过滤dispatch关键字，在第三步分析在#104的时候出现了问题，从第二步可以看到#104出现在Line 10078行，然后在过滤出的dispatch的信息中，找到10078行，然后往下找，找到第一个时间比较长的广播，从下面log看，应该是Line 10132行的广播堵塞了，返回a.txt文件可以找到对应的广播信息。
java
复制代码
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、找到堵塞的广播后，以该广播为关键字在a.txt文件中再次进行筛选，可找到注册该广播的包名，进而可以找到堵塞的进程和应用。此时备注下log分析，把bug分出去就行了。这也是为啥，不能再onReceive中有耗时操作的原因。