Android 9.0系统源码_广播（四）优化系统开机广播耗时时间
前言
近来在对车机智能仓Android系统进行版本性能优化，在优化的过程中发现一个问题：
在系统刚刚启动的时候，很多通过监听系统开机广播【ACTION_BOOT_COMPLETED】进行自启动的应用，需要40秒左右才能收到开机广播并成功进行启动。
一、测试
1.1 开机立即发送测试广播
为了排查这个问题的原因，本人使用adb命令来模拟发送广播，当系统刚刚开机的时候，执行如下adb命令
adb shell am broadcast -a act=android.intent.action.Test
Broadcast completed: result=0
最终发现需要等待40秒左右，才能收到回调。
1.2 开机等待一段时候以后再发送测试广播
进一步测试发现，当系统开机时间达到55秒以后，再次执行同样的adb命令：
发现只需要等待1秒即可收到回调。
1.3 分析测试结果
通过上面的两种测试结果可以很明显看出，这个问题是由于系统启动阶段做了什么事情，才导致广播接收慢的。
要处理这个问题，必须研究下 Android 发送广播的流程，看看到底哪个环节出了问题。另外想要实现软件开机自启动，基本都是通过静态注册的方式来配置广播接收者的。
本系列前篇几篇文章已经很详细的分析过了广播的注册、注销、发送流程；本篇文章我们忽略无序动态广播，简单来梳理一下静态注册的广播接收者广播发送接受的流程。
二、广播的发送流程
/frameworks/base/core/java/android/app/ContextImpl.java
@Override
public void sendBroadcast(Intent intent) {
warnIfCallingFromSystemProcess();
String resolvedType = intent.resolveTypeIfNeeded(getContentResolver());
try {
intent.prepareToLeaveProcess(this);
ActivityManager.getService().broadcastIntent(
mMainThread.getApplicationThread(), intent, resolvedType, null,
Activity.RESULT_OK, null, null, null, AppOpsManager.OP_NONE, null, false, false,
getUserId());
} catch (RemoteException e) {
throw e.rethrowFromSystemServer();
}
}
发送广播一般都是通过调用sendBroadcast 方法，该方法最终调用到 AMS 里面的 broadcastIntent 方法。
// 发送广播
public final int broadcastIntent(IApplicationThread caller,
Intent intent, String resolvedType, IIntentReceiver resultTo,
int resultCode, String resultData, Bundle resultExtras,
String[] requiredPermissions, int appOp, Bundle bOptions,
boolean serialized, boolean sticky, int userId) {
enforceNotIsolatedCaller("broadcastIntent");
synchronized (this) {
// 验证广播的Intent是否合法
// 如果这个时候系统正在启动，还会验证intent所描述的广播是否只发送给动态注册的广播接收者。
// 在系统的启动过程中，PMS可能还未启动，这种情况下，AMS是无法获取静态注册广播接收者的，因此，就禁止发送广播给静态注册的广播接收者
intent = verifyBroadcastLocked(intent);
// 根据caller从缓存mLruProcesses中获取进程对象ProcessRecord
final ProcessRecord callerApp = getRecordForAppLocked(caller);
final int callingPid = Binder.getCallingPid();
final int callingUid = Binder.getCallingUid();
final long origId = Binder.clearCallingIdentity();
int res = broadcastIntentLocked(callerApp,
callerApp != null ? callerApp.info.packageName : null,
intent, resolvedType, resultTo, resultCode, resultData, resultExtras,
requiredPermissions, appOp, bOptions, serialized, sticky,
callingPid, callingUid, userId);
Binder.restoreCallingIdentity(origId);
return res;
}
}
broadcastIntent又会调用broadcastIntentLocked方法，所以我们直接对broadcastIntentLocked方法的流程进行分析。
/frameworks/base/services/core/java/com/android/server/am/ActivityManagerService.java
//发送广播的核心代码
final int broadcastIntentLocked(ProcessRecord callerApp,
String callerPackage, Intent intent, String resolvedType,
IIntentReceiver resultTo, int resultCode, String resultData,
Bundle resultExtras, String[] requiredPermissions, int appOp, Bundle bOptions,
boolean ordered, boolean sticky, int callingPid, int callingUid, int userId) {
......
// Figure out who all will receive this broadcast.
List receivers = null;
List<BroadcastFilter> registeredReceivers = null;
// Need to resolve the intent to interested receivers...
if ((intent.getFlags()&Intent.FLAG_RECEIVER_REGISTERED_ONLY)== 0) {
// 这里先获取静态注册了该intent的receiver，放到receivers队列中
//collectReceiverComponents的实现其实就是调用了PMS的queryIntentReceivers方法查询静态注册了该intent的
//receiver，而PMS是在开机启动时扫描package的时候，从manifest中解析出Receiver，保存到mReceivers这个全局变量中。
receivers = collectReceiverComponents(intent, resolvedType, callingUid, users);
}
if (intent.getComponent() == null) {
// 这里调用 mReceiverResolver.queryIntent 获取动态注册了该intent的receiver，放到registeredReceivers队列中
......
}
......
int NR = registeredReceivers != null ? registeredReceivers.size() : 0;
// 对无序且动态注册的广播加入到广播队列等待分发，这部分广播是可以并行处理的
if (!ordered && NR > 0) {
// 将BroadcastRecord加入到mParallelBroadcasts，调用BroadcastQueue.scheduleBroadcastsLocked进行处理
......
}
......
// 对有序且动态注册的广播以及静态注册的广播进行处理，这部分广播是串行处理的
if ((receivers != null && receivers.size() > 0)
|| resultTo != null) {
BroadcastQueue queue = broadcastQueueForIntent(callerPackage, intent);
BroadcastRecord r = new BroadcastRecord(queue, intent, callerApp,
callerPackage, callingPid, callingUid, callerInstantApp, resolvedType,
requiredPermissions, appOp, brOptions, receivers, resultTo, resultCode,
resultData, resultExtras, ordered, sticky, false, userId);
final BroadcastRecord oldRecord =
replacePending ? queue.replaceOrderedBroadcastLocked(r) : null;
if (oldRecord != null) {
......
} else {
// 这里是核心代码，将构造的BroadcastRecord加入到mOrderedBroadcasts
queue.enqueueOrderedBroadcastLocked(r);
// 调用BroadcastQueue.scheduleBroadcastsLocked，从广播队列中取出广播进行处理
queue.scheduleBroadcastsLocked();
}
} else {
// 没有receivers接收该广播，只作记录，不做其他处理
......
}
return ActivityManager.BROADCAST_SUCCESS;
}
由于这个函数代码非常多，这里我们忽略掉了动态注册的处理以及其他的一些流程，只针对静态注册的 receiver 进行分析；
可以看到 broadcastIntentLocked 中，针对静态注册的 receiver 主要做了 2 件事情：
- collectReceiverComponents 获取到静态注册的 receiver，放到 receivers 队列中；
- 构造 BroadcastRecord，调用 BroadcastQueue.enqueueOrderedBroadcastLocked加入到广播队列中，再调用BroadcastQueue 等待分发。
三、广播的分发流程
广播分发的主要代码在 BroadcastQueue中实现。
/frameworks/base/services/core/java/com/android/server/am/BroadcastQueue.java
public void enqueueOrderedBroadcastLocked(BroadcastRecord r) {
mOrderedBroadcasts.add(r);
enqueueBroadcastHelper(r);
}
可以看到 enqueueOrderedBroadcastLocked 只是简单地把 BroadcastRecord 加入到 mOrderedBroadcasts 队列中。
public void scheduleBroadcastsLocked() {
if (DEBUG_BROADCAST) Slog.v(TAG_BROADCAST, "Schedule broadcasts ["
+ mQueueName + "]: current="
+ mBroadcastsScheduled);
if (mBroadcastsScheduled) {
return;
}
mHandler.sendMessage(mHandler.obtainMessage(BROADCAST_INTENT_MSG, this));
mBroadcastsScheduled = true;
}
private final class BroadcastHandler extends Handler {
@Override
public void handleMessage(Message msg) {
switch (msg.what) {
case BROADCAST_INTENT_MSG: {
if (DEBUG_BROADCAST) Slog.v(
TAG_BROADCAST, "Received BROADCAST_INTENT_MSG");
processNextBroadcast(true);
} break;
}
}
}
scheduleBroadcastsLocked 也只是发送了一个 message 给 Handler，Handler最终调用 processNextBroadcast 进行真正的分发流程。
final void processNextBroadcast(boolean fromMsg) {
synchronized(mService) {
BroadcastRecord r;
......
// 首先，直接遍历mParallelBroadcasts，对并行广播（无序广播+动态注册的receiver）进行处理
while (mParallelBroadcasts.size() > 0) {
r = mParallelBroadcasts.remove(0);
......
final int N = r.receivers.size();
// 遍历广播的所有receivers，进行分发
for (int i=0; i<N; i++) {
Object target = r.receivers.get(i);
// deliverToRegisteredReceiverLocked -> performReceiveLocked -> ActivityThread.scheduleRegisteredReceiver异步处理广播
deliverToRegisteredReceiverLocked(r, (BroadcastFilter)target, false, i);
}
......
}
......
// mPendingBroadcast需要在应用启动完成后进行处理。在AMS.attachApplicationLocked中会调用sendPendingBroadcastsLocked进行分发
if (mPendingBroadcast != null) {
boolean isDead;
synchronized (mService.mPidsSelfLocked) {
ProcessRecord proc = mService.mPidsSelfLocked.get(mPendingBroadcast.curApp.pid);
isDead = proc == null || proc.crashing;
}
// 如果应用启动，会在AMS调用函数处理静态广播，所以这里直接return
if (!isDead) {
// It's still alive, so keep waiting
return;
} else {
Slog.w(TAG, "pending app ["
+ mQueueName + "]" + mPendingBroadcast.curApp
+ " died before responding to broadcast");
mPendingBroadcast.state = BroadcastRecord.IDLE;
mPendingBroadcast.nextReceiver = mPendingBroadcastRecvIndex;
mPendingBroadcast = null;
}
}
boolean looped = false;
// 这里的do-while只会从mOrderedBroadcasts中取出第一个BroadcastRecord进行后续的处理！
do {
......
r = mOrderedBroadcasts.get(0);
boolean forceReceive = false;
// 后面主要是广播分发超时后的处理，以及广播分发给所有receiver后的处理，这里暂时跳过
......
} while (r == null);
// Get the next receiver...
int recIdx = r.nextReceiver++; // 取出一个Receiver
......
final Object nextReceiver = r.receivers.get(recIdx);
// 对动态注册receiver的处理，这里应该是分发有序广播
if (nextReceiver instanceof BroadcastFilter) {
// 通过deliverToRegisteredReceiverLocked调用ActivityThread.scheduleRegisteredReceiver处理广播，暂时跳过
......
}
// 开始对静态注册receiver的处理！！！
ResolveInfo info = (ResolveInfo)nextReceiver;
......
// 如果应用已经启动，则直接分发广播给该应用，并返回
if (app != null && app.thread != null && !app.killed) {
try {
app.addPackage(info.activityInfo.packageName,
info.activityInfo.applicationInfo.versionCode, mService.mProcessStats);
// 通过processCurBroadcastLocked -> ActivityThread.scheduleReceiver -> receiver.onReceive处理当前广播
processCurBroadcastLocked(r, app);
return;
} catch (RemoteException e) {
Slog.w(TAG, "Exception when sending broadcast to "
+ r.curComponent, e);
} catch (RuntimeException e) {
Slog.wtf(TAG, "Failed sending broadcast to "
+ r.curComponent + " with " + r.intent, e);
......
return;
}
}
......
// 如果应用未启动，则在这里启动应用进程，广播将在AMS启动完成后被调用处理
if ((r.curApp=mService.startProcessLocked(targetProcess,
info.activityInfo.applicationInfo, true,
r.intent.getFlags() | Intent.FLAG_FROM_BACKGROUND,
"broadcast", r.curComponent,
(r.intent.getFlags()&Intent.FLAG_RECEIVER_BOOT_UPGRADE) != 0, false, false))
== null) {
Slog.w(TAG, "Unable to launch app "
+ info.activityInfo.applicationInfo.packageName + "/"
+ info.activityInfo.applicationInfo.uid + " for broadcast "
+ r.intent + ": process is bad");
......
return;
}
// 将BroadcastRecord赋值为mPendingBroadcast，等待应用启动完成后处理
mPendingBroadcast = r;
mPendingBroadcastRecvIndex = recIdx;
}
}
processNextBroadcast 是 BroadcastQueue 中分发广播的核心方法，对并行广播和串行广播进行处理。
由于代码太多，本篇博客主要关注静态注册广播的发送流程，所以删掉了大量的代码，只留下了和静态注册广播比较重要的部分。
概括起来，processNextBroadcast 在分发广播中主要做了这几件事情：
1、先处理并行广播队列（无序广播 + 动态注册的 receiver），遍历 mParallelBroadcasts 所有的 BroadcastRecord 以及 Receiver，异步发送广播。
2、再处理串行广播，从 mOrderedBroadcasts 中取出一个 BroadcastRecord，一次只处理其中的一个 Receiver
3、如果当前 receiver 为动态注册，调用 deliverToRegisteredReceiverLocked 进行处理
4、如果当前 receiver 为静态注册，分为两种情况：
4.1、应用已启动：调用 processCurBroadcastLocked 进行处理
4.2、应用未启动：调用 AMS.startProcessLocked 启动应用，将要处理的 BroadcastRecord 保存到 mPendingBroadcast，等待应用启动完成后在 AMS.attachApplicationLocked 中调用 BroadcastQueue.sendPendingBroadcastsLocked，sendPendingBroadcastsLocked方法最终又会调用processCurBroadcastLocked进行处理
四、开机广播接受速度缓慢的原因
其实分析到这里大概就能知道 应用在开机后启动慢的问题所在了。
- 静态注册的广播需要串行处理，如果应用未启动，需要等待应用启动完成后才能处理广播，然后才能继续分发给下一个接收器。
- 系统刚启动时，大量的应用通过静态注册被开机广播拉起来，再加上一些系统状态信息的广播，必然导致客户应用发出的广播需要在队列中等待很长的时间，才能分发并处理。