说说Android的广播(4) - 前台队列为什么比后台队列快？
前台队列为什么比后台队列快
讨论超时的细节之前，我们先讲讲对应用开发有帮助的，为什么前台队列比后台队列要快？
应用开发的同学在给系统团队提意见的时候讲，说以前我们都是靠通过将广播消息设成前台广播的方式来做workaround来解决一些广播的性能问题的，你们系统为什么不能将后台广播做得跟前台广播一样快呢？这一定是设计上的问题。
其实，这种前台广播的设计，就是为了加速广播的性能而设计的。二者在设计思想上就有不同。根据应用层实际的需求，决定使用前台广播还是后台广播，本来就是应用设计时候应该考虑的问题。
当然，Android的这个设计对应用开发的要求比较高，我看了一些Android的教程，也没有讲到这么细节的东西。系统还是应该更智能一些。
这里面主要有三点原因：
- 前台队列相对比较空闲
- 前台队列的超时时间是10s，而后台是60s. 后台广播的设计思想就是当前应用优先，尽可能多让收到广播的应用有充足的时间把事件做完。而前台广播的目的是紧急通知，设计上就倾向于当前应用赶快处理完，尽快传给下一个。
- 前台队列不等后台服务，而后台队列要多等后台服务一定的时间。这还是设计思想上的原因。
比如我们举个关机广播的例子，写应用的同学可以参照这个例子来写发送前台广播哈：
Intent intent = new Intent(Intent.ACTION_SHUTDOWN);
intent.addFlags(Intent.FLAG_RECEIVER_FOREGROUND);
mContext.sendOrderedBroadcastAsUser(intent,
UserHandle.ALL, null, br, mHandler, 0, null, null);比起普通广播，只是多加一个intent.addFlags(Intent.FLAG_RECEIVER_FOREGROUND);就可以了。
不过，纸上得来终觉浅，我们看下实际的代码中是如何实现的吧。
广播队列的构造
我们来看AMS中的构造函数里，是如何为前台队列和后台队列配置参数的:
...
mFgBroadcastQueue = new BroadcastQueue(this, mHandler,
"foreground", BROADCAST_FG_TIMEOUT, false);
mBgBroadcastQueue = new BroadcastQueue(this, mHandler,
"background", BROADCAST_BG_TIMEOUT, true);
mBroadcastQueues[0] = mFgBroadcastQueue;
mBroadcastQueues[1] = mBgBroadcastQueue;
...我们可以看到有两点不同：一个是超时时间不同，另一个是allowDelayBehindServices参数不同，前台是false，就是不等待，而后台是true，要等待。
我们来看看BroadcastQueue的构造函数：
BroadcastQueue(ActivityManagerService service, Handler handler,
String name, long timeoutPeriod, boolean allowDelayBehindServices) {
mService = service;
mHandler = new BroadcastHandler(handler.getLooper());
mQueueName = name;
mTimeoutPeriod = timeoutPeriod;
mDelayBehindServices = allowDelayBehindServices;
}timeoutPeriod是超时时间，我们来看看前台和后台的超时时间是如何定义的：
// How long we allow a receiver to run before giving up on it.
static final int BROADCAST_FG_TIMEOUT = 10*1000;
static final int BROADCAST_BG_TIMEOUT = 60*1000;BroadcastRecord中的几个时间点
既然是分析超时，我们先对BroadcastRecord中记录的几个时间点有个印象。
long enqueueClockTime; // the clock time the broadcast was enqueued
long dispatchTime; // when dispatch started on this set of receivers
long dispatchClockTime; // the clock time the dispatch started
long receiverTime; // when current receiver started for timeouts.
long finishTime; // when we finished the broadcast.其中最绕的是dispatchTime和dispatchClockTime，都是开始分发消息时的时间，它们有什么不同呢？
其实，它们的区别仅仅是计时方法不同：
r.dispatchTime = SystemClock.uptimeMillis();
r.dispatchClockTime = System.currentTimeMillis();其他的时间也都一样，凡是叫ClockTime的都是System.currentTimeMillis()，只叫Time的，就是SystemClock.uptimeMillis().
我们看下它们的实际赋值，加深一下印象：
ClockTime就这两个：
r.enqueueClockTime = System.currentTimeMillis();
r.dispatchClockTime = System.currentTimeMillis();非Clock的Time有三个：
r.dispatchTime = SystemClock.uptimeMillis();
r.receiverTime = SystemClock.uptimeMillis();
r.finishTime = SystemClock.uptimeMillis();入队列的时间
入队列的逻辑我们在第三讲中已经分析过了，我们再复习一下：
214 public void enqueueParallelBroadcastLocked(BroadcastRecord r) {
215 mParallelBroadcasts.add(r);
216 r.enqueueClockTime = System.currentTimeMillis();
217 }
218
219 public void enqueueOrderedBroadcastLocked(BroadcastRecord r) {
220 mOrderedBroadcasts.add(r);
221 r.enqueueClockTime = System.currentTimeMillis();
222 }派发的时间
这就是刚才我们看到的同时记两个时间点的那个，在processNextBroadcast中，我们下讲会专门分析这个大派发函数：
先看对于并发队列的派发：
...
654 // First, deliver any non-serialized broadcasts right away.
655 while (mParallelBroadcasts.size() > 0) {
656 r = mParallelBroadcasts.remove(0);
657 r.dispatchTime = SystemClock.uptimeMillis();
658 r.dispatchClockTime = System.currentTimeMillis();
659 final int N = r.receivers.size();
...
662 for (int i=0; i<N; i++) {
663 Object target = r.receivers.get(i);
...
667 deliverToRegisteredReceiverLocked(r, (BroadcastFilter)target, false);
668 }
669 addBroadcastToHistoryLocked(r);
...
672 }
...后面还有针对串行队列的，也是两个同时要赋值哟~
796 // Keep track of when this receiver started, and make sure there
797 // is a timeout message pending to kill it if need be.
798 r.receiverTime = SystemClock.uptimeMillis();
799 if (recIdx == 0) {
800 r.dispatchTime = r.receiverTime;
801 r.dispatchClockTime = System.currentTimeMillis();
...receiver接收到的时间
这段逻辑也是在处理广播消息的主循环processNextBroadcast函数中。
第一处就是刚才看到的位置
796 // Keep track of when this receiver started, and make sure there
797 // is a timeout message pending to kill it if need be.
798 r.receiverTime = SystemClock.uptimeMillis();另一处是超时之后，反正也不打算继续等它了，就把超时那一刻的时间记录成收到的时间吧。这段逻辑位于超时处理的函数broadcastTimeoutLocked中。
1164 Slog.w(TAG, "Timeout of broadcast " + r + " - receiver=" + r. receiver
1165 + ", started " + (now - r.receiverTime) + "ms ago");
1166 r.receiverTime = now;
1167 r.anrCount++;广播处理结束的时间
这个省事了，只在一处出现，就是修史书的时候，具体的函数是addBroadcastToHistoryLocked.
1221 private final void addBroadcastToHistoryLocked(BroadcastRecord r) {
...
1226 r.finishTime = SystemClock.uptimeMillis();
1227
1228 mBroadcastHistory[mHistoryNext] = r;
1229 mHistoryNext = ringAdvance(mHistoryNext, 1, MAX_BROADCAST_HISTORY);
1230
1231 mBroadcastSummaryHistory[mSummaryHistoryNext] = r.intent;
1232 mSummaryHistoryEnqueueTime[mSummaryHistoryNext] = r.enqueueClockTime;
1233 mSummaryHistoryDispatchTime[mSummaryHistoryNext] = r.dispatchClockTime;
1234 mSummaryHistoryFinishTime[mSummaryHistoryNext] = System.currentTimeMillis();
1235 mSummaryHistoryNext = ringAdvance(mSummaryHistoryNext, 1, MAX_BROADCAST_SUMMARY_HISTORY);
1236 }