Service启动原理
本章主要围绕以下几点讲解：
- service启动有哪几种方式？
- service启动流程？
- service启动过程涉及哪些参与者，通信过程是怎样的？
结论：
这章先把Service的启动图摆出来，然后再详细的介绍相对应的代码及原理：
Service启动1
Service启动2
其实Service的启动跟Activity启动类似哈 ：Activity的启动。对以上两图都很熟悉的同学可以直接略过本章，不熟悉的呢跟着继续往下看。
startService
还是先从入口函数startService看起：
// 代码来自Android23中：ContextImpl.java
public ComponentName startService(Intent service) {
return startServiceCommon(service, mUser);
}
private ComponentName startServiceCommon(Intent service,...){
ComponentName cn = ActivityManagerNative.getDefault().startService(
mMainThread.getApplicationThread(), service, service,...);
return cn;
}
最终还是通过AMS调用startService。
接着往下看看AMS中做了什么操作：
//代码来自Android23中：ActivityManagerService.java
public ComponentName startService(IApplicationThread caller, Intent service, ....) {
ComponentName res = mServices.startServiceLocked(caller, service, ...);
return res;
}
//代码来自Android23中：ActiveServices.java
ComponentName startServiceLocked(Intent service, ...) {
ServiceLookupResult res = retrieveServiceLocked(service, ...);
ServiceRecord r = res.record;
......
r.pendingStarts.add(new ServiceRecord.StartItem(r, …));
......
return startServiceInnerLocked(smap, service, r, ...);
}
ComponentName startServiceInnerLocked(ServiceMap smap, Intent service, ...) {
bringUpServiceLocked(r, service.getFlags(), callerFg, false);
......
}
以上代码呢主要是为了引出bringUpServiceLocked函数，具体看下bringUpServiceLocked：
//代码来自Android23中：ActiveServices.java
final String bringUpServiceLocked(ServiceRecord r, ...) {
final String bringUpServiceLocked(ServiceRecord r, ...) {
if (r.app != null && r.app.thread != null) {
sendServiceArgsLocked(r, …);
return null;
}
ProcessRecord app = mAm.getProcessRecordLocked(procName, …);
if (app != null && app.thread != null) {
realStartServiceLocked(r, app, execInFg);
return null;
}
if (app == null) {
app = mAm.startProcessLocked(procName, ...);
}
if (!mPendingServices.contains(r)) {
mPendingServices.add(r);
}
……
}
- 先看service是否启动(通过看ServiceRecord中的app及app.thread不为null)，如果启动则直接调用sendServiceArgsLocked函数，这个函数会回调生命周期onStartCommand()。且return。
- 以下是Service未启动，首先通过procName去AMS中查找进程是否启动(app != null && app.thread != null)，进程已启动则直接启动Service(realStartServiceLocked)，且return。
- 进程未启动(app == null)，则通过AMS去启动进程。具体看 应用进程启动 。
- 把serviceRecord加入到等待队列中，等进程启动后，再会去等待队列中逐一启动。
再回顾下应用进程启动：
应用进程启动
- AMS向Zygote发送启动进程的请求(Socket)。
- Zygote收到后就去启动进程，在应用进程中会调用入口函数(ActivityThread.main())。
- 应用在入口函数中会向AMS发起attachApplication这个binder调用，在这个调用中应用会把自己的binder对象(IApplicationThread)注册到AMS中。
- 这时对应AMS来说应用进程已经准备就绪，接下来就会调用应用注册过来的binder对象(IApplicationThread)向应用发起bindApplication。
- bindApplication其实是让应用初始化Application Application启动。
- Application启动后就会去启动在等待队列中的应用组件了(例如mPendingServices)。见如下代码：
接下来看看代码（启动mPendingServices中的组件）：在AMS调用bindApplication去启动应用进程的Application后会调用attachApplicationLocked函数：
//代码来自Android23中：ActiveServices.java
boolean attachApplicationLocked(ProcessRecord proc, …) {
for (int i=0; i
- 首先就是循环列表，realStartServiceLocked启动Service组件。
- realStartServiceLocked中先把进程对象赋值ServiceRecord(所以我们本章之前判断r.app != null就是在这里赋值的)。
- 通过binder调用应用端的scheduleCreateService(参数中有ServiceRecord,应用端对用map对其保存)，应用端会创建Service 且启用onCreate回调。
- sendServiceArgsLocked这个函数就是用来触发Service的onStartCommand回调的。
应用端如何处理AMS发送过来的 scheduleCreateService 请求的, scheduleCreateService中就是发送了一个CREATE_SERVICE的Message,应用处理该消息调用的handleCreateService：
//代码来自Android23中：ActivityThread.java
private void handleCreateService(CreateServiceData data) {
LoadedApk packageInfo = getPackageInfoNoCheck(...);
Service service = (Service) cl.loadClass(data.info.name).newInstance();
ContextImpl context = ContextImpl.createAppContext(this, …);
Application app = packageInfo.makeApplication(false, …);
service.attach(context, this, ...);
service.onCreate();
mServices.put(data.token, service);
......
}
- 获取LoadedApk，通过它里面的ClassLoader去加载Service类，然后调用类的newInstance去创建一个service对象。
- 创建Context上下文对象，及获取之前进程启动后创建的Application对象。
- attach给service对象赋值上下文等。
- 执行Service onCreate生命周期。
整体逻辑类似Activity启动。
再回到之前代码，看看触发Service的onStartCommand回调的sendServiceArgsLocked是如何实现的：
//代码来自Android23中：ActiveServices.java
private final void sendServiceArgsLocked(ServiceRecord r, ) {
while (r.pendingStarts.size() > 0) {
StartItem si = r.pendingStarts.remove(0);
……
r.app.thread.scheduleServiceArgs(r, …);
}
}
最终呢也是通过应用端的binder对象，调到应用端的scheduleServiceArgs。
继续往下看应用端的处理：
//代码来自Android23中：ActivityThread.java
public final void scheduleServiceArgs(IBinder token, ...) {
ServiceArgsData s = new ServiceArgsData();
......
sendMessage(H.SERVICE_ARGS, s);
}
private void handleServiceArgs(ServiceArgsData data) {
Service s = mServices.get(data.token);
if (s != null) {
……
s.onStartCommand(data.args, data.flags, data.startId);
……
}
}
- 应用端对数据封装后发送了一个SERVICE_ARGS message
- 最终主线程也是调用handleServiceArgs处理该消息，这里就能看到onStartCommand生命周期的回调了。
整体还是比较简单的。
总结
现在再回看下本篇最开始的两张流程图，应该就清晰多了吧。Service的启动跟Activity的启动大致逻辑还是差不多的