Android进阶 四大组件的工作过程（二）：Service的工作过程
Android进阶 四大组件的工作过程（二）：Service的工作过程
导语
本片文章主要是来介绍Service组件的工作过程的，主要分成Service的启动和Service的绑定两个部分来讲。上一篇文章我们已经介绍了Activity的工作工程，而Service的工作过程也与Activity有一定的相关之处，也会涉及到AMS(ActivityManagerService)
上篇文章:
- Android进阶 四大组件的工作过程（一）：Activity的工作过程
Service的启动过程
Service的启动过程可以分为三个个过程，实际上也和Activity的工作过程相类似了。可以分为从ContextImpl到AMS的调用过程，从AMS到ActivityThread以及ActivityThread启动Service。
从ContextImpl到AMS的调用过程
我们先来看第一个部分，从ContextImpl到AMS的调用过程。如果要启动Service，我们首先会通过ContextWrapper的startService来开启流程。这个ContextWrapper是Context的子类，它实现了Context中的方法，我们就来看ContextWrapper的startService方法：
.......
Context mBase;
.......
public @Nullable ComponentName startService(Intent service) {
return mBase.startService(service);
}
它会调用类型为Context类的startService，Context类是一个抽象类，所以我们需要找到它的实现类，这个具体的实现类实际上我们在根Activity的创建过程中已经提到过了，可以回顾一下：
private Activity performLaunchActivity(ActivityClientRecord r, Intent customIntent) {
ActivityInfo aInfo = r.activityInfo;
if (r.packageInfo == null) {
r.packageInfo = getPackageInfo(aInfo.applicationInfo, r.compatInfo,
Context.CONTEXT_INCLUDE_CODE);
}
ComponentName component = r.intent.getComponent();
if (component == null) {
component = r.intent.resolveActivity(
mInitialApplication.getPackageManager());
r.intent.setComponent(component);
}
if (r.activityInfo.targetActivity != null) {
component = new ComponentName(r.activityInfo.packageName,
r.activityInfo.targetActivity);
}
ContextImpl appContext = createBaseContextForActivity(r);//1-----1
........
}
我们直接看performLaunchActivity中的注释一处，这里就创建出了Context的实现类，并且在之后的attach方法中将其与Activity进行了绑定，可以看一下createBaseContextForActivity方法:
private ContextImpl createBaseContextForActivity(ActivityClientRecord r) {
final int displayId = ActivityClient.getInstance().getDisplayId(r.token);
ContextImpl appContext = ContextImpl.createActivityContext(
this, r.packageInfo, r.activityInfo, r.token, displayId, r.overrideConfig);
........
return appContext;
}
主要就是通过第一行的ContextImpl.createActivityContext方法创建出来的，这个方法里会调用到ContextImpl的构造方法。总之我们最后调用的就是这个ContextImpl的startService方法，这个startService方法又会调用到startServiceCommon方法，我们就直接看这个startServiceCommon方法：
private ComponentName startServiceCommon(Intent service, boolean requireForeground,
UserHandle user) {
try {
validateServiceIntent(service);
service.prepareToLeaveProcess(this);
ComponentName cn = ActivityManager.getService().startService( //1--------1
mMainThread.getApplicationThread(), service,
service.resolveTypeIfNeeded(getContentResolver()), requireForeground,
getOpPackageName(), getAttributionTag(), user.getIdentifier());
..........
} catch (RemoteException e) {
throw e.rethrowFromSystemServer();
}
}
看重点，这里的重点显然就是注释一处的 ActivityManager.getService().startService()方法,看起来它会调用到AMS的startService方法，实际上也正是这样，和Activity的创建一样，是通过远程调用了AMS的方法。
到此为止，就正式进入到了AMS的处理和方法调用过程了，所以接下来让我们看第二部分。
从AMS到ActivityThread
上面提到远程调用到了AMS的startService方法，所以我们继续来看AMS的startService方法：
public ComponentName startService(IApplicationThread caller, Intent service,
String resolvedType, boolean requireForeground, String callingPackage,
String callingFeatureId, int userId)
throws TransactionTooLargeException {
...........
synchronized(this) {
final int callingPid = Binder.getCallingPid();
final int callingUid = Binder.getCallingUid();
final long origId = Binder.clearCallingIdentity();
ComponentName res;
try {
res = mServices.startServiceLocked(caller, service, //1-------1
resolvedType, callingPid, callingUid,
requireForeground, callingPackage, callingFeatureId, userId);
} finally {
Binder.restoreCallingIdentity(origId);
}
return res;
}
}
startService的重头就是继续调用到了注释一处的startServiceLocked方法，接下来会进行一系列的跳转：
ComponentName startServiceLocked(IApplicationThread caller, Intent service, String resolvedType,
int callingPid, int callingUid, boolean fgRequired,
String callingPackage, @Nullable String callingFeatureId, final int userId,
boolean allowBackgroundActivityStarts, @Nullable IBinder backgroundActivityStartsToken)
throws TransactionTooLargeException {
.........
ServiceLookupResult res =
retrieveServiceLocked(service, null, resolvedType, callingPackage,
callingPid, callingUid, userId, true, callerFg, false, false); //1-----1
if (res == null) {
return null;
}
if (res.record == null) {
return new ComponentName("!", res.permission != null
? res.permission : "private to package");
}
ServiceRecord r = res.record; //2-------2
........
final ComponentName realResult =
startServiceInnerLocked(r, service, callingUid, callingPid, fgRequired, callerFg,
allowBackgroundActivityStarts, backgroundActivityStartsToken);//3-------3
}
这里截取了比较重要的三段代码，在注释一处，会通过retrieveServiceLocked方法查找是否有与参数service对应的ServiceRecord（这个ServiceRecord和ActivityRecord类似，是描述Service的一个类），如果没有找到，接下来就会在注释二处会去到res的record参数并将其赋值给ServiceRecord变量，最后将其传入startServiceInnerLocked继续Service的启动。这个startServiceInnerLocked方法接下来又会进行跳转，具体最后会跳转到bringUpServiceLocked方法中，我们直接看这个方法：
private String bringUpServiceLocked(ServiceRecord r, int intentFlags, boolean execInFg,
boolean whileRestarting, boolean permissionsReviewRequired, boolean packageFrozen,
boolean enqueueOomAdj)
throws TransactionTooLargeException {
...........
// Service is now being launched, its package can't be stopped.
try {
AppGlobals.getPackageManager().setPackageStoppedState(
r.packageName, false, r.userId);
} catch (RemoteException e) {
} catch (IllegalArgumentException e) {
Slog.w(TAG, "Failed trying to unstop package "
+ r.packageName + ": " + e);
}
final boolean isolated = (r.serviceInfo.flags&ServiceInfo.FLAG_ISOLATED_PROCESS) != 0;
final String procName = r.processName;
HostingRecord hostingRecord = new HostingRecord(
HostingRecord.HOSTING_TYPE_SERVICE, r.instanceName,
r.definingPackageName, r.definingUid, r.serviceInfo.processName);
ProcessRecord app;
if (!isolated) {
app = mAm.getProcessRecordLocked(procName, r.appInfo.uid); //1------1
if (DEBUG_MU) Slog.v(TAG_MU, "bringUpServiceLocked: appInfo.uid=" + r.appInfo.uid
+ " app=" + app);
if (app != null) {//2-----2
final IApplicationThread thread = app.getThread();
final int pid = app.getPid();
final UidRecord uidRecord = app.getUidRecord();
if (thread != null) {
try {
app.addPackage(r.appInfo.packageName, r.appInfo.longVersionCode,
mAm.mProcessStats);
realStartServiceLocked(r, app, thread, pid, uidRecord, execInFg,
enqueueOomAdj);//3-------3
return null;
} catch (TransactionTooLargeException e) {
throw e;
} catch (RemoteException e) {
Slog.w(TAG, "Exception when starting service " + r.shortInstanceName, e);
}
// If a dead object exception was thrown -- fall through to
// restart the application.
}
}
}
..............
// Not running -- get it started, and enqueue this service record
// to be executed when the app comes up.
if (app == null && !permissionsReviewRequired && !packageFrozen) {//4---------4
// TODO (chriswailes): Change the Zygote policy flags based on if the launch-for-service
// was initiated from a notification tap or not.
if (r.isSdkSandbox) {
final int uid = Process.toSdkSandboxUid(r.sdkSandboxClientAppUid);
app = mAm.startSdkSandboxProcessLocked(procName, r.appInfo, true, intentFlags,
hostingRecord, ZYGOTE_POLICY_FLAG_EMPTY, uid, r.sdkSandboxClientAppPackage);
r.isolationHostProc = app;
} else {
app = mAm.startProcessLocked(procName, r.appInfo, true, intentFlags,//5---------5
hostingRecord, ZYGOTE_POLICY_FLAG_EMPTY, false, isolated);
}
if (app == 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(r, enqueueOomAdj);
return msg;
}
if (isolated) {
r.isolationHostProc = app;
}
}
.........
return null;
}
我们从上往下分析这个方法，在注释一处会获取到Service要在哪个进程里启动，这个属性默认是会在当前进程中运行，我们也可以通过修改Service的process属性来进行修改，这个内容具体是在IPC中提到过。如果这个进程存在，那么接下来就会进入到注释二处的分支处，如果这个进程有线程那么就会执行注释三处的realStartServiceLocked方法。
若需要的进程不存在的话，就会进入到注释四处的分支处，紧接着会运行到注释五处的分支来启动一个新的进程。不过这不是我们的重点，我们继续回到注释三处的方法处。让我们看这个方法：
private void realStartServiceLocked(ServiceRecord r, ProcessRecord app,
IApplicationThread thread, int pid, UidRecord uidRecord, boolean execInFg,
boolean enqueueOomAdj) throws RemoteException {
.........
thread.scheduleCreateService(r, r.serviceInfo,
mAm.compatibilityInfoForPackage(r.serviceInfo.applicationInfo),
app.mState.getReportedProcState());
........
}
我们先不看别的，实际上就是通过上面的一句来推进了Service的启动，这个thread点开来的话我们可以发现是一个IApplicationThread接口，这个接口在哪里实现呢？我们可以看ActivityThread的内部类ApplicationThread：
private class ApplicationThread extends IApplicationThread.Stub {
............
}
这显然是通过AIDL实现的，ApplicationThread类就是这个thread的实现类，具体最后还是调用到了ActivityThread的方法。所以说，到此为止又由AMS进入到了ActivityThread中了。接下来是Service启动的最后一部分。
ActivityThread启动Service
接下来进入到了ActivityThread中，让我们来看他的scheduleCreateService方法：
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);
}
这个方法具体就是触发了自身Handler的方法，我们来看Handler对CREATE_SERVICE标志位的处理：
case CREATE_SERVICE:
if (Trace.isTagEnabled(Trace.TRACE_TAG_ACTIVITY_MANAGER)) {
Trace.traceBegin(Trace.TRACE_TAG_ACTIVITY_MANAGER,
("serviceCreate: " + String.valueOf(msg.obj)));
}
handleCreateService((CreateServiceData)msg.obj);
Trace.traceEnd(Trace.TRACE_TAG_ACTIVITY_MANAGER);
break;
继续看中间的handleCreateService方法：
private void handleCreateService(CreateServiceData data) {
// If we are getting ready to gc after going to the background, well
// we are back active so skip it.
unscheduleGcIdler();
LoadedApk packageInfo = getPackageInfoNoCheck(
data.info.applicationInfo, data.compatInfo);
Service service = null;
try {
if (localLOGV) Slog.v(TAG, "Creating service " + data.info.name);
Application app = packageInfo.makeApplicationInner(false, mInstrumentation);
final java.lang.ClassLoader cl;
if (data.info.splitName != null) {
cl = packageInfo.getSplitClassLoader(data.info.splitName);
} else {
cl = packageInfo.getClassLoader();
}
service = packageInfo.getAppFactory() //1------1
.instantiateService(cl, data.info.name, data.intent);
ContextImpl context = ContextImpl.getImpl(service
.createServiceBaseContext(this, packageInfo));
.............
service.attach(context, this, data.info.name, data.token, app,//2--------2
ActivityManager.getService());
service.onCreate();//3----------3
mServicesData.put(data.token, data);
mServices.put(data.token, service);//4--------4
try {
ActivityManager.getService().serviceDoneExecuting(
data.token, SERVICE_DONE_EXECUTING_ANON, 0, 0); //5-----5
} catch (RemoteException e) {
throw e.rethrowFromSystemServer();
}
} catch (Exception e) {
if (!mInstrumentation.onException(service, e)) {
throw new RuntimeException(
"Unable to create service " + data.info.name
+ ": " + e.toString(), e);
}
}
}
这里我们还是从上往下看首先是通过packageInfo获取到了ClassLoader，这个ClassLoader是用于生成Service实例的。在注释一处就用这个ClassLoader获取到了Service的实例。接着在注释二处通过attach方法将service自身的context进行了绑定。
注释三处，调用了Service的onCreate回调；最后注释四处将当前Service添加入ActivityThread的service列表中便于后续管理。一切都完毕后，调用注释五处的方法通知AMS当前Service创建完毕了，这个方法用于标记服务执行完成，并根据不同的类型和结果执行相应的操作。
到这里为止，Service的启动过程就介绍完毕了。接下来我们来探讨Service的绑定过程。
Service的绑定过程
我们知道Service除了可以用Start启动外，还可以通过Bind方法进行客户端的绑定，接下来我们就来看Service的绑定过程。
Service的绑定过程我们也可以分成两个过程：ContextImpl到AMS的调用过程和Service的绑定过程。
ContextImpl到AMS调用
先来看第一个阶段，这个阶段和之前start过程很像，具体来说就是通过ContextWrapper的bindService方法跳转到ContextImpe的bindService方法，所以这里我们就直接看ContextImpl的bindService方法了：
public boolean bindService(
Intent service, int flags, Executor executor, ServiceConnection conn) {
return bindServiceCommon(service, conn, flags, null, null, executor, getUser());
}
这实际上还是老过程，我们继续看它的bindServiceCommon方法：
private boolean bindServiceCommon(Intent service, ServiceConnection conn, int flags,
String instanceName, Handler handler, Executor executor, UserHandle user) {
// Keep this in sync with DevicePolicyManager.bindDeviceAdminServiceAsUser and
// ActivityManagerLocal.bindSdkSandboxService
IServiceConnection sd;
if (conn == null) {
throw new IllegalArgumentException("connection is null");
}
if (handler != null && executor != null) {
throw new IllegalArgumentException("Handler and Executor both supplied");
}
if (mPackageInfo != null) {
if (executor != null) {
sd = mPackageInfo.getServiceDispatcher(conn, getOuterContext(), executor, flags);
} else {
sd = mPackageInfo.getServiceDispatcher(conn, getOuterContext(), handler, flags);
}
} else {
throw new RuntimeException("Not supported in system context");
}
validateServiceIntent(service);
try {
IBinder token = getActivityToken();
if (token == null && (flags&BIND_AUTO_CREATE) == 0 && mPackageInfo != null
&& mPackageInfo.getApplicationInfo().targetSdkVersion
< android.os.Build.VERSION_CODES.ICE_CREAM_SANDWICH) {
flags |= BIND_WAIVE_PRIORITY;
}
service.prepareToLeaveProcess(this);
int res = ActivityManager.getService().bindServiceInstance( //1------1
mMainThread.getApplicationThread(), getActivityToken(), service,
service.resolveTypeIfNeeded(getContentResolver()),
sd, flags, instanceName, 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();
}
}
这里我们看注释一处，其实这个过程真的是非常类似，接下来就会开始进入到AMS中调用AMS的方法了，接下来我们来看AMS中的调用。
AMS到ActivityThread调用
上面说到了bindServiceInstance方法，接下来就看这个方法：
private int bindServiceInstance(IApplicationThread caller, IBinder token, Intent service,
String resolvedType, IServiceConnection connection, int flags, String instanceName,
boolean isSdkSandboxService, int sdkSandboxClientAppUid,
String sdkSandboxClientAppPackage, String callingPackage, int userId)
throws TransactionTooLargeException {
enforceNotIsolatedCaller("bindService");
enforceAllowedToStartOrBindServiceIfSdkSandbox(service);
// Refuse possible leaked file descriptors
if (service != null && service.hasFileDescriptors() == true) {
throw new IllegalArgumentException("File descriptors passed in Intent");
}
if (callingPackage == null) {
throw new IllegalArgumentException("callingPackage cannot be null");
}
if (isSdkSandboxService && instanceName == null) {
throw new IllegalArgumentException("No instance name provided for isolated process");
}
// Ensure that instanceName, which is caller provided, does not contain
// unusual characters.
if (instanceName != null) {
for (int i = 0; i < instanceName.length(); ++i) {
char c = instanceName.charAt(i);
if (!((c >= 'a' && c <= 'z') || (c >= 'A' && c <= 'Z')
|| (c >= '0' && c <= '9') || c == '_' || c == '.')) {
throw new IllegalArgumentException("Illegal instanceName");
}
}
}
try {
if (Trace.isTagEnabled(Trace.TRACE_TAG_ACTIVITY_MANAGER)) {
final ComponentName cn = service.getComponent();
Trace.traceBegin(Trace.TRACE_TAG_ACTIVITY_MANAGER, "bindService:"
+ (cn != null ? cn.toShortString() : service.getAction()));
}
synchronized (this) {
return mServices.bindServiceLocked(caller, token, service, resolvedType, connection,
flags, instanceName, isSdkSandboxService, sdkSandboxClientAppUid,
sdkSandboxClientAppPackage, callingPackage, userId); //1---1
}
} finally {
Trace.traceEnd(Trace.TRACE_TAG_ACTIVITY_MANAGER);
}
}
还是接着跳转，看注释一处的方法bindServiceLocked：
int bindServiceLocked(IApplicationThread caller, IBinder token, Intent service,
String resolvedType, final IServiceConnection connection, int flags,
String instanceName, boolean isSdkSandboxService, int sdkSandboxClientAppUid,
String sdkSandboxClientAppPackage, String callingPackage, final int userId)
throws TransactionTooLargeException {
if (DEBUG_SERVICE) Slog.v(TAG_SERVICE, "bindService: " + service
+ " type=" + resolvedType + " conn=" + connection.asBinder()
+ " flags=0x" + Integer.toHexString(flags));
.........
AppBindRecord b = s.retrieveAppBindingLocked(service, callerApp); //1-------1
ConnectionRecord c = new ConnectionRecord(b, activity,
connection, flags, clientLabel, clientIntent,
callerApp.uid, callerApp.processName, callingPackage, res.aliasComponent);
.........
ArrayList<ConnectionRecord> clist = mServiceConnections.get(binder);
if (clist == null) {
clist = new ArrayList<>();
mServiceConnections.put(binder, clist);
}
clist.add(c);
boolean needOomAdj = false;
if ((flags&Context.BIND_AUTO_CREATE) != 0) {
s.lastActivity = SystemClock.uptimeMillis();
needOomAdj = true;
if (bringUpServiceLocked(s, service.getFlags(), callerFg, false,//2-------2
permissionsReviewRequired, packageFrozen, true) != null) {
mAm.updateOomAdjPendingTargetsLocked(OomAdjuster.OOM_ADJ_REASON_BIND_SERVICE);
return 0;
}
}
.........
if (s.app != null && b.intent.received) {//3------3
// Service is already running, so we can immediately
// publish the connection.
// If what the client try to start/connect was an alias, then we need to
// pass the alias component name instead to the client.
final ComponentName clientSideComponentName =
res.aliasComponent != null ? res.aliasComponent : s.name;
try {
c.conn.connected(clientSideComponentName, b.intent.binder, false);//4-------4
} catch (Exception e) {
Slog.w(TAG, "Failure sending service " + s.shortInstanceName
+ " to connection " + c.conn.asBinder()
+ " (in " + c.binding.client.processName + ")", e);
}
// If this is the first app connected back to this binding,
// and the service had previously asked to be told when
// rebound, then do so.
if (b.intent.apps.size() == 1 && b.intent.doRebind) {//5--------5
requestServiceBindingLocked(s, b.intent, callerFg, true);//6------6
}
} else if (!b.intent.requested) {//7-----7
requestServiceBindingLocked(s, b.intent, callerFg, false);//8------8
}
maybeLogBindCrossProfileService(userId, callingPackage, callerApp.info.uid);
getServiceMapLocked(s.userId).ensureNotStartingBackgroundLocked(s);
} finally {
Binder.restoreCallingIdentity(origId);
}
notifyBindingServiceEventLocked(callerApp, callingPackage);
return 1;
}
这里我们先介绍一下相关的类代表什么：
- AppBindRecord代表应用程序与服务之间的绑定关系。它记录了应用程序与服务之间的连接信息，包括应用程序的UID、进程名称、包名，以及与服务建立的连接对象。
- ConnectionRecord：这是一个代表应用程序与服务之间连接的类。它包含了连接对象的相关信息，例如连接的应用程序、连接的服务、连接的标志等。
- IntentBindRecord 类表示服务（ServiceRecord）与绑定的 Intent 之间的关联关系记录。
首先在注释一处获得了Service的AppBindRecord信息和ConnectionRecord信息；接着，如果创建的标注为BIND_AUTO_CREATE的话就会进入到注释二处的bringUpServiceLocked方法中，这个方法中又会调用到我们在启动流程中提到的realStartServiceLocked方法，也就是说会自动地创建和启动Service；注释三处的条件代表service已经运行，这样就会紧接着调用到注释四处的connected方法，具体来说是会调用到InnerConncetion的connected方法，并且最终调用到LoadedApk的connected方法:
public void connected(ComponentName name, IBinder service, boolean dead) {
if (mActivityExecutor != null) {
mActivityExecutor.execute(new RunConnection(name, service, 0, dead));
} else if (mActivityThread != null) {
mActivityThread.post(new RunConnection(name, service, 0, dead));
} else {
doConnected(name, service, dead);
}
}
这会调用H(ActivityThread的Handler)的post方法向主线程发送消息，并且解决当前应用程序进程和Service跨进程通信的问题。接下来我们来看注释五到八的内容，其实他们最终调用到的都是requestServiceBindingLocked方法，唯一的差别就是最后一个参数的差别。具体来说这两个分支分别代表当前应用程序是不是第一个和Service绑定的。接下来再看requestServiceBindingLocked方法：
private final boolean requestServiceBindingLocked(ServiceRecord r, IntentBindRecord i,
boolean execInFg, boolean rebind) throws TransactionTooLargeException {
if (r.app == null || r.app.getThread() == null) {
// If service is not currently running, can't yet bind.
return false;
}
if (DEBUG_SERVICE) Slog.d(TAG_SERVICE, "requestBind " + i + ": requested=" + i.requested
+ " rebind=" + rebind);
if ((!i.requested || rebind) && i.apps.size() > 0) {//1------1
try {
bumpServiceExecutingLocked(r, execInFg, "bind",
OomAdjuster.OOM_ADJ_REASON_BIND_SERVICE);
r.app.getThread().scheduleBindService(r, i.intent.getIntent(), rebind,
r.app.mState.getReportedProcState()); //2-----------2
if (!rebind) {
i.requested = true;
}
i.hasBound = true;
i.doRebind = false;
} catch (TransactionTooLargeException e) {
// Keep the executeNesting count accurate.
if (DEBUG_SERVICE) Slog.v(TAG_SERVICE, "Crashed while binding " + r, e);
final boolean inDestroying = mDestroyingServices.contains(r);
serviceDoneExecutingLocked(r, inDestroying, inDestroying, false);
throw e;
} catch (RemoteException e) {
if (DEBUG_SERVICE) Slog.v(TAG_SERVICE, "Crashed while binding " + r);
// Keep the executeNesting count accurate.
final boolean inDestroying = mDestroyingServices.contains(r);
serviceDoneExecutingLocked(r, inDestroying, inDestroying, false);
return false;
}
}
return true;
}
我们先看注释一处的判断条件，i.requested表示当前Intent是否发送过绑定Service的请求。接下来我们还需要稍微分析一下IntentBindRecord。AMS会为每个绑定Service的Intent分配一个IntentBindRecord类型的对象。IntentBindRecord类中又有一个apps列表来存储当前Intent绑定Service的应用程序进程。所以i.apps.size() > 0代表当前Intent绑定Service的应用程序进程大于0。
看注释二处的代码，接下来就和之前一样，跳转到了ActivityThread之中了。
AppBindRecord的结构
为了帮助我们更好地理解，我觉得还是有必要来详细地解析一下AppBindRecord的结构和它与其他辅助类的关系，我们先来看AppBindRecord的源码：
final class AppBindRecord {
final ServiceRecord service; // The running service.
final IntentBindRecord intent; // The intent we are bound to.
final ProcessRecord client; // Who has started/bound the service.
final ArraySet<ConnectionRecord> connections = new ArraySet<>();
// All ConnectionRecord for this client.
void dump(PrintWriter pw, String prefix) {
pw.println(prefix + "service=" + service);
pw.println(prefix + "client=" + client);
dumpInIntentBind(pw, prefix);
}
void dumpInIntentBind(PrintWriter pw, String prefix) {
final int N = connections.size();
if (N > 0) {
pw.println(prefix + "Per-process Connections:");
for (int i=0; i<N; i++) {
ConnectionRecord c = connections.valueAt(i);
pw.println(prefix + " " + c);
}
}
}
AppBindRecord(ServiceRecord _service, IntentBindRecord _intent,
ProcessRecord _client) {
service = _service;
intent = _intent;
client = _client;
}
public String toString() {
return "AppBindRecord{"
+ Integer.toHexString(System.identityHashCode(this))
+ " " + service.shortInstanceName + ":" + client.processName + "}";
}
void dumpDebug(ProtoOutputStream proto, long fieldId) {
long token = proto.start(fieldId);
proto.write(AppBindRecordProto.SERVICE_NAME, service.shortInstanceName);
proto.write(AppBindRecordProto.CLIENT_PROC_NAME, client.processName);
final int N = connections.size();
for (int i=0; i<N; i++) {
ConnectionRecord conn = connections.valueAt(i);
proto.write(AppBindRecordProto.CONNECTIONS,
Integer.toHexString(System.identityHashCode(conn)));
}
proto.end(token);
}
}
可以看到，它的内部有四个成员变量，分别是ServiceRecord类型，IntentBindRecord类型，ProcessRecord类型和一个ConnectionRecord的集合。
而IntentBindRecord中存储有一个ServiceRecord，这是用来描述被绑定的Service的；还有一个Key为ProcessRecord，Value为AppBindRecord的Map。具体差不多就这样如图所述：
ActivityThread绑定Service
直接看ActivityThread的scheduleBindService方法：
public final void scheduleBindService(IBinder token, Intent intent,
boolean rebind, int processState) {
updateProcessState(processState, false);
BindServiceData s = new BindServiceData();
s.token = token;
s.intent = intent;
s.rebind = rebind;
if (DEBUG_SERVICE)
Slog.v(TAG, "scheduleBindService token=" + token + " intent=" + intent + " uid="
+ Binder.getCallingUid() + " pid=" + Binder.getCallingPid());
sendMessage(H.BIND_SERVICE, s);
}
实际上还是老一套，会向自身的Handler发送消息，我们还是看Handler是如何处理这个标志位的：
case BIND_SERVICE:
Trace.traceBegin(Trace.TRACE_TAG_ACTIVITY_MANAGER, "serviceBind");
handleBindService((BindServiceData)msg.obj);
Trace.traceEnd(Trace.TRACE_TAG_ACTIVITY_MANAGER);
break;
显然是会接着调用handleBindService:
private void handleBindService(BindServiceData data) {
CreateServiceData createData = mServicesData.get(data.token);
Service s = mServices.get(data.token);//1---------1
if (DEBUG_SERVICE)
Slog.v(TAG, "handleBindService s=" + s + " rebind=" + data.rebind);
if (s != null) {
try {
data.intent.setExtrasClassLoader(s.getClassLoader());
data.intent.prepareToEnterProcess(isProtectedComponent(createData.info),
s.getAttributionSource());
try {
if (!data.rebind) {//2--------2
IBinder binder = s.onBind(data.intent);
ActivityManager.getService().publishService(
data.token, data.intent, binder);
} else {//3---------3
s.onRebind(data.intent);
ActivityManager.getService().serviceDoneExecuting(
data.token, SERVICE_DONE_EXECUTING_ANON, 0, 0);
}
} catch (RemoteException ex) {
throw ex.rethrowFromSystemServer();
}
} catch (Exception e) {
if (!mInstrumentation.onException(s, e)) {
throw new RuntimeException(
"Unable to bind to service " + s
+ " with " + data.intent + ": " + e.toString(), e);
}
}
}
}
在注释一处获得了要进行绑定的Service对象，如果已经Service已经调用过unbind方法就会进入到注释三处的分支，触发onRebind的回调；不然就会进入到注释二的分支处，先触发onBind回调之后又会调用AMS的publicService方法。我们来看publishServiceLocked方法：
void publishServiceLocked(ServiceRecord r, Intent intent, IBinder service) {
final long origId = Binder.clearCallingIdentity();
try {
if (DEBUG_SERVICE) Slog.v(TAG_SERVICE, "PUBLISHING " + r
+ " " + intent + ": " + service);
if (r != null) {
Intent.FilterComparison filter
= new Intent.FilterComparison(intent);
IntentBindRecord b = r.bindings.get(filter);
if (b != null && !b.received) {
b.binder = service;
b.requested = true;
b.received = true;
ArrayMap<IBinder, ArrayList<ConnectionRecord>> connections = r.getConnections();
for (int conni = connections.size() - 1; conni >= 0; conni--) {
ArrayList<ConnectionRecord> clist = connections.valueAt(conni);
for (int i=0; i<clist.size(); i++) {
ConnectionRecord c = clist.get(i);
........
try {
c.conn.connected(clientSideComponentName, service, false);//1-----1
} catch (Exception e) {
Slog.w(TAG, "Failure sending service " + r.shortInstanceName
+ " to connection " + c.conn.asBinder()
+ " (in " + c.binding.client.processName + ")", e);
}
}
}
}
serviceDoneExecutingLocked(r, mDestroyingServices.contains(r), false, false);
}
} finally {
Binder.restoreCallingIdentity(origId);
}
}
看注释一处，这里就是遍历了Service中的所有ConnectionRecord对象，然后调用conncted方法，这个我们在之前也提到过，最后是会调用到LoadedApk的connected方法:
public void connected(ComponentName name, IBinder service, boolean dead) {
if (mActivityExecutor != null) {
mActivityExecutor.execute(new RunConnection(name, service, 0, dead));
} else if (mActivityThread != null) {
mActivityThread.post(new RunConnection(name, service, 0, dead));
} else {
doConnected(name, service, dead);
}
}
public void doConnected(ComponentName name, IBinder service, boolean dead) {
ServiceDispatcher.ConnectionInfo old;
ServiceDispatcher.ConnectionInfo info;
synchronized (this) {
..........
if (dead) {
mConnection.onBindingDied(name);
} else {
// If there is a new viable service, it is now connected.
if (service != null) {
mConnection.onServiceConnected(name, service);//1------1
} else {
// The binding machinery worked, but the remote returned null from onBind().
mConnection.onNullBinding(name);
}
}
}
上面的RunConnection实际上是LoadedApk的内部类，最后也是会执行doConnected方法。我们看上面的注释一处，这就是执行了我们bindService是传入的ServiceConnection对象的回调方法，这样就完成了整个Service的绑定过程了。
Service工作过程总结
下面是我总结的一张关于Service工作过程的总结，其中省略了一些细节，主要是帮助理解大致的过程。相信大家也可以发现无论是绑定还是启动，其中都有很多的重合处，无非就是从AMS到ActiviyThread，并且都是通过远程调用的方式。如果要抠细节的话可以看一下AppBindRecord和其他辅助类的关系，这样可以帮助我们更好地理解这整个设计。
