总结了几篇系统底层相关的文章，终于要接触到应用层了，不过需要提前掌握 Binder架构，系统启动流程，进程启动流程 的相关姿势，不然很难理清整个流程。相对于 startAcitivity()，startService() 的流程相对简单，因为不涉及界面相关的操作，便于理清用户进程，AMS 所在进程（也即 SystemServer 进程）和 服务所在进程三者之间的关系。
1. 整体流程
这里借用 gityuan 的一篇文章 里的图：
这个图画的非常好，关键点基本上都标注出来了，涉及到三个进程的交互（当然Remote Service 进程也可以和 Process A 进程是同一个，那样就省略2、3创建进程的步骤）。重点注意整个流程中涉及到通过 Binder 进行跨进程交互的部分，如果不熟悉 Binder 架构，很难理解。下面以从一个 Activity 里面调用 startActivity() 启动服务为例，进行详细分析。
2. ContextImpl.startService()
Activity -> ContextThemeWrapper -> ContextWrapper，ContextWrapper 是个代理类，实际功能都由其成员变量 Context mBase 实现，mBase 实际上是一个 ContextImpl 对象（具体怎么来的，以后的文章会讲到，简单的说是启动Activity 时注入的）。在 Application 或者 Service 里面启动 startService 也是一样，最终都调用到 ContextImpl.startService()：
@Override
public ComponentName startService(Intent service) {
warnIfCallingFromSystemProcess();
return startServiceCommon(service, mUser);
}
private ComponentName startServiceCommon(Intent service, UserHandle user) {
try {
...
// Binder 调用 AMS
ComponentName cn = ActivityManagerNative.getDefault().startService(
mMainThread.getApplicationThread(), service, service.resolveTypeIfNeeded(
getContentResolver()), getOpPackageName(), user.getIdentifier());
...
}
return cn;
} catch (RemoteException e) {
throw e.rethrowFromSystemServer();
}
}
这里有两个关键点：
- ActivityManagerNative.getDefault() 获取了 ActivityManagerService （AMS）的远程代理对象 ActivityManagerProxy，并发起了 startService 的请求
- mMainThread.getApplicationThread()，这里 mMainThread 是一个 ActivityThread 对象，getApplicationThread() 返回 ActivityThread 的成员变量 ApplicationThread mAppThread，ApplicationThread 是 ActivityThread 的一个内部类，看定义：
private class ApplicationThread extends ApplicationThreadNative {
...
}
明显也是一个 Binder 架构，把这个 Binder 对象传递给 AMS，是为了 AMS 与发起 startService 的调用进程通信，后面会具体分析。
到这里，发起 startService 请求的部分就完成了，接下来会通过 Binder 跨进程调用，进入到 AMS 中继续分析。
3. AMS.startService()
通过 Binder
机制，ActivityManagerProxy.startService ----跨进程---> ActivityManagerNative.onTransact() --> AMS.startService()，AMS 是 AMN 的子类，实现了其 startService 方法。
AMS 中的 startService 方法：
@Override
public ComponentName startService(IApplicationThread caller, Intent service,
String resolvedType, String callingPackage, int userId)
throws TransactionTooLargeException {
...
synchronized(this) {
final int callingPid = Binder.getCallingPid();
final int callingUid = Binder.getCallingUid();
final long origId = Binder.clearCallingIdentity();
ComponentName res = mServices.startServiceLocked(caller, service,
resolvedType, callingPid, callingUid, callingPackage, userId);
...
return res;
}
}
这里 IApplicationThread caller 就是发起进程在 AMS 所在的进程中的代理。mService 是 一个 ActiveServices 类型的成员变量，其持有 AMS 的引用。
4. ActiveServices
4.1 startServiceLocked()
这个方法源码比较长，这里只保留关键部分：
ComponentName startServiceLocked(IApplicationThread caller, Intent service, String resolvedType,
int callingPid, int callingUid, String callingPackage, final int userId)
throws TransactionTooLargeException {
...
if (caller != null) {
final ProcessRecord callerApp = mAm.getRecordForAppLocked(caller); // 1. 查找调用进程是否存在
if (callerApp == null) {
throw new SecurityException(
"Unable to find app for caller " + caller
+ " (pid=" + Binder.getCallingPid()
+ ") when starting service " + service);
}
callerFg = callerApp.setSchedGroup != ProcessList.SCHED_GROUP_BACKGROUND;
} else {
callerFg = true;
}
...
ServiceLookupResult res =
retrieveServiceLocked(service, resolvedType, callingPackage,
callingPid, callingUid, userId, true, callerFg, false); // 2. 查找要启动的服务是否已经存在
...
ServiceRecord r = res.record;
return startServiceInnerLocked(smap, service, r, callerFg, addToStarting)
两个关键点已经用注释中标记出来，retrieveServiceLocked() 内部流程也比较复杂，有各种条件、权限的检查等，这里不深入分析了，简单说就是有一个 Map 用来保存用户所有已启动的服务，如果不存在符合条件的 ServiceRecord，就新建一个并保存在 Map 中。最后流程进入到 startServiceInnerLocked() --> bringUpServiceLocked()
4.2 bringUpServiceLocked()
仍然先贴出简化后的代码：
private String bringUpServiceLocked(ServiceRecord r, int intentFlags, boolean execInFg,
boolean whileRestarting, boolean permissionsReviewRequired)
throws TransactionTooLargeException {
if (r.app != null && r.app.thread != null) {
//1. Service 所在的进程和 Service 线程都已经启动的情况
sendServiceArgsLocked(r, execInFg, false);
return null;
}
...
if (!isolated) {
// 2.查找服务对应的进程是否存在
app = mAm.getProcessRecordLocked(procName, r.appInfo.uid, false);
...
if (app != null && app.thread != null) {
try {
app.addPackage(r.appInfo.packageName, r.appInfo.versionCode, mAm.mProcessStats);
// 3. 如果进程已经存在，直接启动服务
realStartServiceLocked(r, app, execInFg);
return null;
} catch (TransactionTooLargeException e) {
throw e;
} catch (RemoteException e) {
Slog.w(TAG, "Exception when starting service " + r.shortName, e);
}
}
}
...
if (app == null && !permissionsReviewRequired) {
// 4. 如果进程不存在，启动进程
if ((app=mAm.startProcessLocked(procName, r.appInfo, true, intentFlags,
"service", r.name, false, isolated, false)) == null) {
...
}
...
}
几个关键点已经注释标明：
- 如果服务所在进程和线程都已经启动（r.app != null && r.app.thread != null），那么调用 sendServiceArgsLocked()，这个方法里的关键代码只有一句：
r.app.thread.scheduleServiceArgs(r, si.taskRemoved, si.id, flags, si.intent);
r.app.thread 就是发起 startService 的进程在 AMS 中的远程代理对象，这里又通过了 Binder 跨进程调用，最终调用到 ApplicationThreadNative.onTransact() --> ApplicationThread.scheduleServiceArgs()：
public final void scheduleServiceArgs(IBinder token, boolean taskRemoved, int startId,
int flags ,Intent args) {
ServiceArgsData s = new ServiceArgsData();
s.token = token;
s.taskRemoved = taskRemoved;
s.startId = startId;
s.flags = flags;
s.args = args;
sendMessage(H.SERVICE_ARGS, s);
}
调用该方法后，ApplicationThread 会把消息 post 到主线程的 handler 处理，对应 SERVICE_ARGS 的处理函数是 handleServiceArgs()，在这个方法里，终于看到了我们熟悉的 Service.onStartCommand() ！这也是为什么当反复启动 Service 的时候，只有 onStartCommand() 会被反复调用。
- 如果服务所在进程已经存在，那么进入 realStartServiceLocked() 启动服务，这里也不贴出大段源码了，关键代码有两处：
app.thread.scheduleCreateService(r, r.serviceInfo,
mAm.compatibilityInfoForPackageLocked(r.serviceInfo.applicationInfo),
app.repProcState);
...
sendServiceArgsLocked(r, execInFg, true);
和第一种情况类似，这里也是两个 Binder 跨进程调用，最终分别调用到 Service 的 onCreate() 和 onStartCommand 生命周期，这又是我们非常熟悉的部分了。
- 如果服务所在进程不存在，那么调用 AMS.startProcessLocked 启动进程。在上一篇 Android 进程启动流程总结 中已经分析了从 AMS.startProcessLocked 开始的流程，这里终于找到了它的调用的源头之一，就是当启动的服务所在进程还不存在时，就要调用 AMS.startProcessLocked 先启动对应的进程。在上篇文章的最后提到，进程启动后会调用 ActivityThread.main() 方法 -->ActivityThread.attach() --> ActivityManagerProxy.attachApplication() --Binder跨进程调用--> AMS.attachApplication() --> AMS.attachApplicationLocked() --> ActiveServices.attachApplicationLocked() --> ActiveServices.realStartServiceLocked()，终于殊途同归！回到了和第2种情况一样的函数。
至此，startService() 的整个流程就走完了。
5. 总结
startService() 的流程看起来有些复杂，但是只要先建立了如第一节所示的三个进程间交互的整体结构图，那么整体思路还是很清晰的，这中间涉及了 Binder 和 Socket 两种跨进程调用（上一篇介绍的进程启动流程里讲到），是把前面学习的 Android 底层架构知识融会贯通的一个非常好的学习范例，也为后面分析更为复杂的 startActivity() 流程打好了基础。
