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

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

前台广播为什么比后台广播快

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

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

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

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

这里面主要有三点原因：

1. 前台队列相对比较空闲

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

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

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

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    }