wordpress邮箱验证登录页面北京网站优化推广方案

一、问题

最近遇到一个问题，发送广播（普通广播）给另一个应用，但是广播需要要等约1min后才收到。

二、分析原因

原因是系统有个广播接收器在接收到广播后处理了接近50s，所以阻塞了后面的广播处理。如果大家也出现了广播阻塞问题，想知道广播到底堵塞到哪里？这里先给大家分享下这个问题分析方法：

1、首先，串口设置输出log转存到a.txt文件中（名字随意取），然后在串口打印下面的指令，等一会将所有的广播信息收集起来。

dumpsys activity broadcasts

2、然后，根据自己堵塞的广播名称在a.txt文件进行过滤，如下代码所示，有三次发送。

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。

#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关键字，在第三步分析在#104的时候出现了问题，从第二步可以看到#104出现在Line 10078行，然后在过滤出的dispatch的信息中，找到10078行，然后往下找，找到第一个时间比较长的广播，从下面log看，应该是Line 10132行的广播堵塞了，返回a.txt文件可以找到对应的广播信息。

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中有耗时操作的原因。