// 6

if ((app=mAm.startProcessLocked(procName, r.appInfo, true, intentFlags,

hostingType, r.name, false, isolated, false)) == null) {

String msg = "Unable to launch app "

• r.appInfo.packageName + “/”

• r.appInfo.uid + " for service "

• r.intent.getIntent() + “: process is bad”;

Slog.w(TAG, msg);

bringDownServiceLocked®;

return msg;

}

…

}

…

return null;

}

注释1：从ServiceRecord中获取 processName赋值给 procName

注释2：根据 procName和Service的uid来传入到 AMS的 getProcessRecordLocked()中，查询是否存在一个与Service对应的ProcessRecord类型对象。

如果不存在，则在注释5、6中调用 AMS的 startProcessLocked()来创建一个引用程序进程。

如果存在，则在注释3、4中调用 realStartServiceLocked()来启动一个Service。

private final void realStartServiceLocked(ServiceRecord r,

ProcessRecord app, boolean execInFg) throws RemoteException {

…

try {

…

//1

app.thread.scheduleCreateService(r, r.serviceInfo,

mAm.compatibilityInfoForPackageLocked(r.serviceInfo.applicationInfo),

app.repProcState);

r.postNotification();

created = true;

} catch (DeadObjectException e) {

Slog.w(TAG, "Application dead when creating service " + r);

mAm.appDiedLocked(app);

throw e;

} finally {

…

}

…

}

这里也有一个Real方法。app.thread.scheduleCreateService即调用调用主线程的 scheduleCreateService()的方法。

我们知道 app.thread就是 IApplicationThread，通过AIDL，这时候的代码从 SystemServer进程到了 应用程序的进程中。

// ActivityThread.java

public final void scheduleCreateService(IBinder token,

ServiceInfo info, CompatibilityInfo compatInfo, int processState) {

updateProcessState(processState, false);

CreateServiceData s = new CreateServiceData();

s.token = token;

s.info = info;

s.compatInfo = compatInfo;

sendMessage(H.CREATE_SERVICE, s);

}

这里创建了一个 CreateServiceData类，把Service的信息都封装了进去，设置一个 H.CREATE_SERVICE字段，sendMessage出去。

到了 ApplicationThread这里，免不了要使用Handler来将线程切换到主线程去。我们直接来看看 H是怎么处理这个信息的吧

// ActivityThread.java

public void handleMessage(Message msg) {

switch (msg.what) {

case CREATE_SERVICE:

Trace.traceBegin(Trace.TRACE_TAG_ACTIVITY_MANAGER, ("serviceCreate: " + String.valueOf(msg.obj)));

//1

handleCreateService((CreateServiceData)msg.obj);

Trace.traceEnd(Trace.TRACE_TAG_ACTIVITY_MANAGER);

break;

}

}

到了主线程中，调用 handleCreateService():

private void handleCreateService(CreateServiceData data) {

// 获取要启动S
ervice的应用程序的 LoadedApk

LoadedApk packageInfo = getPackageInfoNoCheck(

data.info.applicationInfo, data.compatInfo);

Service service = null;

try {

java.lang.ClassLoader cl = packageInfo.getClassLoader();

//1

service = (Service) cl.loadClass(data.info.name).newInstance();

} catch (Exception e) {

…

}

try {

if (localLOGV) Slog.v(TAG, "Creating service " + data.info.name);

//创建上下文环境

ContextImpl context = ContextImpl.createAppContext(this, packageInfo);

context.setOuterContext(service);

Application app = packageInfo.makeApplication(false, mInstrumentation);

//2

service.attach(context, this, data.info.name, data.token, app,

ActivityManager.getService());

//3

service.onCreate();

//4

mServices.put(data.token, service);

…

} catch (Exception e) {

…

}

}

这里的代码和创建Activity时的非常相似。

注释1：通过LoadedApk的getClassLoader()来获取一个类加载器。然后根据 CreateServiceData 来创建一个 Service实例。

注释2：通过 service.attach()来初始化一个service

注释3：调用这个 service的 onCreate()方法。这里 service就启动了。

注释4：最后，把这个service放到 ActivityThread的成员变量 mServices中，它是一个 ArrayMap。

至此，一个Service的完整的创建启动流程就over了。

下面来讲解绑定一个Service。

2.Service的绑定流程

===============================================================================

因为Service的开启方法有 startService() ， 也有 bindService()

Service的绑定过程分成3个部分

1. ContextImpl到AMS的调用过程

2. AMS调用 bindService() 到 publishService() 过程

3. AMS到 ServiceConnection的过程

2.1 ContextImpl到AMS的调用过程

我们先来看一下时序图：

在代码中调用 context.bindService()，就是调用 mBase.bindService()

从之前我们学过， mBase就是 ContextImpl。我们来看看它的 bindService()：

// ContextImpl.java

@Override

public boolean bindService(Intent service, ServiceConnection conn,

int flags) {

warnIfCallingFromSystemProcess();

return bindServiceCommon(service, conn, flags, mMainThread.getHandler(),

Process.myUserHandle());

}

这个方法传入了 Intent，ServiceConntection（Service连接的回调），和 flags，然后这个方法里面带上了 主线程的Handler，传入到 bindServiceCommom里面去：

// ContextImpl.java

private boolean bindServiceCommon(Intent service, ServiceConnection conn, int flags, Handler

handler, UserHandle user) {

IServiceConnection sd;

if (conn == null) {

throw new IllegalArgumentException(“connection is null”);

}

if (mPackageInfo != null) {

//1

sd = mPackageInfo.getServiceDispatcher(conn, getOuterContext(), handler, flags);

} else {

throw new RuntimeException(“Not supported in system context”);

}

validateServiceIntent(service);

try {

…

// 2

int res = ActivityManager.getService().bindService(

mMainThread.getApplicationThread(), getActivityToken(), service,

service.resolveTypeIfNeeded(getContentResolver()),

sd, flags, getOpPackageName(), user.getIdentifier());

if (res < 0) {

throw new SecurityException(

"Not allowed to bind to service " + service);

}

return res != 0;

} catch (RemoteException e) {

throw e.rethrowFromSystemServer();

}

}

在注释1中，通过 LoadedApk.getServiceDispatcher()将传进来的 ServiceConnection封装成一个 IServiceConnection对象。

也就是说 ServiceConnection也是实现了Binder的。

注释2中：调用 ActivityManager.getSerive()即 IActivityManager.bindSerive()，这里代码进入到 AMS层。

2.2 AMS调用 bindService() 到 publishService() 过程

先来看看时序图：

我们来看看 AMS的 bindService()：

// ActivityManagerService

public int bindService(IApplicationThread caller, IBinder token, Intent service,

String resolvedType, IServiceConnection connection, int flags, String callingPackage,

int userId) throws TransactionTooLargeException {

…

synchronized(this) {

return mServices.bindServiceLocked(caller, token, service,

resolvedType, connection, flags, callingPackage, userId);

}

}

省略号中的代码都是异常判断处理。

在 synchronized中调用了 ActiveService.bindServiceLocked()：

// ActivityManagerService.java

int bindServiceLocked(IApplicationThread caller, IBinder token, Intent service,

String resolvedType, final IServiceConnection connection, int flags,

String callingPackage, final int userId) throws TransactionTooLargeException {

…

try {

…

//1

AppBindRecord b = s.retrieveAppBindingLocked(service, callerApp);

if ((flags&Context.BIND_AUTO_CREATE) != 0) {

s.lastActivity = SystemClock.uptimeMillis();

//2

if (bringUpServiceLocked(s, service.getFlags(), callerFg, false,

permissionsReviewRequired) != null) {

return 0;

}

}

…

//3

if (s.app != null && b.intent.received) {

try {

//4

c.conn.connected(s.name, b.intent.binder, false);

} …

if (b.intent.apps.size() == 1 && b.intent.doRebind) {

//5

requestServiceBindingLocked(s, b.intent, callerFg, true);

}

} else if (!b.intent.requested) {

//6

requestServiceBindingLocked(s, b.intent, callerFg, false);

}

…

}

这个方法里面出现了几个 Record，我们来看一下他们分别描述什么：

• ServiceRecord

用来描述一个 Service

• ProcessRecord

描述一个进程

• ConnectionRecord

描述应用程序进程和 Service建立的一次通信

• AppBindRecord

应用程序进程通过Intent绑定Service时，会通过AppBindRecord来维护Service与应用程序进程之间的关联。

其内部会创建并存储了 谁绑定的Service（ProcessRecord）、被绑定的Service（AppBindRecord）、绑定Service的 Intent（IntentBindRecord）和所有绑定通信记录的信息（ArraySet<ConnectionRecord>）

• IntentBindRecord

用于描述绑定Service的Intent

注：不同的应用进程也可能会创建相同的Intent来绑定同一个Serivce。比如说一些公共的、常用的Service。

注释1：调用了 ServiceRecord.retrieveAppBindingLocked()，获取一个service的 AppBindRecord对象。我们在前面关于AppBindRecord的介绍可以看到，它内部会创建 IntentBindRecord并赋值。

注释2：如果传进来的flags == BIND_AUTO_CREATE就会调用了 bringUpServiceLocked()，其内部会调用 realStartServiceLocked()，这个方法我们学习Service的启动流程的时候学到过，其为与服务端的最后一个方法，它会通过Binder最终到 ActivityThread去，然后调用 Service.onCreate()。这也就是说在Service的绑定流程中也会去启动Serivce。

注释3： s.app != nul表示Service已经运行。其中s是ServiceRecord， app是ProcessRecord。 b.intent.received表示当前应用进程已经接收到绑定Service时返回的Binder，这样应用程序就可以通过Binder来获取要绑定的Service的访问接口。

注释4：调用c.conn的 connected，其中 c.conn就是我们一开始封装好的 IServiceConenction，它的具体实现类为 ServiceDispatcher.InnerConnection，其中ServiceDispatcher是 LoadedApk的内部类，InnerConnection的 connected方法会调用H的post()向主线程发送消息。

注释5：如果当前应用程序进程是第一个与Service进行绑定的，并且Service已经调用过 onUnBind()，则就会调用 requestServiceBindingLocked(...,true)，最后的参数 rebind是true

注释6：如果应用程序进程的Client端没有发送过绑定Service的请求，则也会调用 requestServiceBindingLocked(...,flase)。最后的rebind是flase

我们来看下注释5的 requestServiceBindingLocked()：

// ActivesServices.java

private final boolean requestServiceBindingLocked(ServiceRecord r, IntentBindRecord i,

boolean execInFg, boolean rebind) throws TransactionTooLargeException {

…

//1

if ((!i.requested || rebind) && i.apps.size() > 0) {

try {

bumpServiceExecutingLocked(r, execInFg, “bind”);

r.app.forceProcessStateUpTo(ActivityManager.PROCESS_STATE_SERVICE);

//2

r.app.thread.scheduleBindService(r, i.intent.getIntent(), rebind,

r.app.repProcState);

if (!rebind) {

i.requested = true;

}

i.hasBound = true;

i.doRebind = false;

} catch (TransactionTooLargeException e) {

…

}

}

return true;

}

注释1中的 i.requested表示 是否发送过绑定Service的请求，从bindServiceLocked可以得知已经发送过绑定了，因此 !i.requested == false。从 bindServiceLocked中我们得知 rebind为true。所以这里是可以继续走下去的。

i.apps.size() 中，i指的是 IntenBindRecord，AMS会为每个绑定的Service的Intent分配一个IntentBindRecord对象。我们来看一下IntentBindRecord的代码：

// ActiveServices.java

final class IntentBindRecord {

//被绑定的Service

final ServiceRecord service;

//绑定Service的Intent

final Intent.FilterComparison intent; //

//所有用当前Intent绑定Service应用程序进程

final ArrayMap<ProcessRecord, AppBindRecord> apps

= new ArrayMap<ProcessRecord, AppBindRecord>();

…

}

不同的应用程序进程可能使用同一个Intent来绑定Service，所以我们看到 apps用来存储这些进程。

之前说过 i.apps.size() > 0就是说明已经有Intent绑定了Serivice了。下面来验证 i.apps.size()>0为true。我们回到 bindServiceLocked()的注释1代码处，即 retrieveAppBindingLocked()：

// ServiceRecord.java

public AppBindRecord retrieveAppBindingLocked(Intent intent,

ProcessRecord app) {

Intent.FilterComparison filter = new Intent.FilterComparison(intent);

IntentBindRecord i = bindings.get(filter);

if (i == null) {

//1

i = new IntentBindRecord(this, filter);

bindings.put(filter, i);

}

//2

AppBindRecord a = i.apps.get(app);

if (a != null) {

return a;

}

//3

a = new AppBindRecord(this, i, app);

i.apps.put(app, a);

return a;

}

注释1：创建了 IntentBindRecord

注释2：根据ProcessRecord获取了 AppBindRecord，如果其不为null就会返回。

如果为null就在注释3中，创建一个新的 AppBindRecord，并将其put到 apps中，key为 ProcessRecord。

这里代码也就表明， i.apps.size() > 0是为true的。 这样也就会调用上述 requestServiceBindingLocked(...,true)中，注释2 的代码。

r.app.thread 是 IApplicationThread，所以 它执行的 scheduleBindService()肯定就是通过调用 H类来切换线程到ActivityThread中。

因为这里很熟悉，我们直接看ActivityThread最终会执行什么代码：

// ActivityThread.java

public void handleMessage(Message msg) {

switch (msg.what) {

case BIND_SERVICE:

Trace.traceBegin(Trace.TRACE_TAG_ACTIVITY_MANAGER, “serviceBind”);

handleBindService((BindServiceData)msg.obj);

Trace.traceEnd(Trace.TRACE_TAG_ACTIVITY_MANAGER);

break;

…

}

}

private void handleBindService(BindServiceData data) {

//1

Service s = mServices.get(data.token);

…

if (s != null) {

try {

data.intent.setExtrasClassLoader(s.getClassLoader());

data.intent.prepareToEnterProcess();

try {

//2

if (!data.rebind) {

//3

IBinder binder = s.onBind(data.intent);

//4

ActivityManager.getService().publishService(

data.token, data.intent, binder);

} else {

//5

s.onRebind(data.intent);

ActivityManager.getService().serviceDoneExecuting(

data.token, SERVICE_DONE_EXECUTING_ANON, 0, 0);

}

ensureJitEnabled();

} …

} …

}

}

在 handleBindService()中，我们得知：

注释1：获取要绑定的Service

注释2：BindServiceData这个类的成员变量 rebind的值为false，就会调用注释3的 Service.onBind()方法，到这里Service就绑定成功了。

注释5：否则执行 Service.onRebind()，如果当前应用程序进程第一个与Service绑定，并且Service已经调用过 onUnBind()，则会调用Service的 onReBind()。

handleBindService有两个分支，一个是绑定过的Service的情况，一个是未绑定过Service的情况。这里分析没有绑定过的情况。

也就是注释3、注释4的代码。

注释3我们已经了解了，就是调用Service.onBind()，在接下来的注释4中，调用了 ActivityManagerService.publishService()，这相当于又回到AMS中。

2.3 AMS到 ServiceConnection的过程

我们先来看一下从AMS到ServiceConnection的过程的时序图：

在AMS的publishService里面调用了 ActiveServices.publishServicedLocked()，我们来看看这个方法

// ActiveServices.java

void publishServiceLocked(ServiceRecord r, Intent intent, IBinder service) {

final long origId = Binder.clearCallingIdentity();

try {

…

for (int conni=r.connections.size()-1; conni>=0; conni–) {

…

try {

//1

c.conn.connected(r.name, service, false);

} …

}

}

}

serviceDoneExecutingLocked(r, mDestroyingServices.contains®, false);

}

} …

}

这个方法传入一个ServiceRecord，然后会去遍历每个绑定这个Service的Intent，每个就是一个 ConnectionRecord，也就是c

调用 c.conn就是获取到每次遍历的 IServiceConnection，它的作用是解决当前应用程序进程和Service跨进程通信的问题。

具体实现为类ServiceDispatcher.InnerConnection，我们来看看 InnerConnection的connected()

g?,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3Jpa2thdGhld29ybGQ=,size_16,color_FFFFFF,t_70)

在AMS的publishService里面调用了 ActiveServices.publishServicedLocked()，我们来看看这个方法

// ActiveServices.java

void publishServiceLocked(ServiceRecord r, Intent intent, IBinder service) {

final long origId = Binder.clearCallingIdentity();

try {

…

for (int conni=r.connections.size()-1; conni>=0; conni–) {

…

try {

//1

c.conn.connected(r.name, service, false);

} …

}

}

}

serviceDoneExecutingLocked(r, mDestroyingServices.contains®, false);

}

} …

}

这个方法传入一个ServiceRecord，然后会去遍历每个绑定这个Service的Intent，每个就是一个 ConnectionRecord，也就是c

调用 c.conn就是获取到每次遍历的 IServiceConnection，它的作用是解决当前应用程序进程和Service跨进程通信的问题。

具体实现为类ServiceDispatcher.InnerConnection，我们来看看 InnerConnection的connected()