说说Android的广播(4) - 前台队列为什么比后台队列快？说说Android的广播(4) - 前台队列为什么比后台队列快？

讨论超时的细节之前，我们先讲讲对应用开发有帮助的，为什么前台队列比后台队列要快？

应用开发的同学在给系统团队提意见的时候讲，说以前我们都是靠通过将广播消息设成前台广播的方式来做workaround来解决一些广播的性能问题的，你们系统为什么不能将后台广播做得跟前台广播一样快呢？这一定是设计上的问题。

其实，这种前台广播的设计，就是为了加速广播的性能而设计的。二者在设计思想上就有不同。根据应用层实际的需求，决定使用前台广播还是后台广播，本来就是应用设计时候应该考虑的问题。

当然，android的这个设计对应用开发的要求比较高，我看了一些android的教程，也没有讲到这么细节的东西。系统还是应该更智能一些。

这里面主要有三点原因：

前台队列相对比较空闲

前台队列的超时时间是10s，而后台是60s. 后台广播的设计思想就是当前应用优先，尽可能多让收到广播的应用有充足的时间把事件做完。而前台广播的目的是紧急通知，设计上就倾向于当前应用赶快处理完，尽快传给下一个。

前台队列不等后台服务，而后台队列要多等后台服务一定的时间。这还是设计思想上的原因。

比如我们举个关机广播的例子，写应用的同学可以参照这个例子来写发送前台广播哈：

比起普通广播，只是多加一个intent.addflags(intent.flag_receiver_foreground);就可以了。

不过，纸上得来终觉浅，我们看下实际的代码中是如何实现的吧。

我们来看ams中的构造函数里，是如何为前台队列和后台队列配置参数的:

我们可以看到有两点不同：一个是超时时间不同，另一个是allowdelaybehindservices参数不同，前台是false，就是不等待，而后台是true，要等待。

我们来看看broadcastqueue的构造函数：

timeoutperiod是超时时间，我们来看看前台和后台的超时时间是如何定义的：

既然是分析超时，我们先对broadcastrecord中记录的几个时间点有个印象。

其中最绕的是dispatchtime和dispatchclocktime，都是开始分发消息时的时间，它们有什么不同呢？

其实，它们的区别仅仅是计时方法不同：

其他的时间也都一样，凡是叫clocktime的都是system.currenttimemillis()，只叫time的，就是systemclock.uptimemillis().

我们看下它们的实际赋值，加深一下印象：

clocktime就这两个：

非clock的time有三个：

入队列的逻辑我们在第三讲中已经分析过了，我们再复习一下：

这就是刚才我们看到的同时记两个时间点的那个，在processnextbroadcast中，我们下讲会专门分析这个大派发函数：

先看对于并发队列的派发：

后面还有针对串行队列的，也是两个同时要赋值哟~

这段逻辑也是在处理广播消息的主循环processnextbroadcast函数中。

第一处就是刚才看到的位置

另一处是超时之后，反正也不打算继续等它了，就把超时那一刻的时间记录成收到的时间吧。这段逻辑位于超时处理的函数broadcasttimeoutlocked中。

这个省事了，只在一处出现，就是修史书的时候，具体的函数是addbroadcasttohistorylocked.