说说Android的广播(4) - 前台队列为什么比后台队列快?-阿里云开发者社区

开发者社区> 开发与运维> 正文

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

简介: tips:性能攸关的广播,该发前台广播就发。CTS广播性能问题不过,也可以改成用前台广播。

说说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    }

版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。

分享:
开发与运维
使用钉钉扫一扫加入圈子
+ 订阅

集结各类场景实战经验,助你开发运维畅行无忧

其他文章