上一篇
startService启动源码分析
1.Service生命周期
上篇讲到了startService的生命周期，这篇的话，讲第二种Service的启动方式，bindService。
2.BindService时序图
老规矩，看代码前先放图。相较startService，bindService的过程稍微复杂些。这里先介绍一下新增的几个类。
ServiceDispatcher 应用端的Service连接的管理类。管理连接的binder的状态。
InnerConnection IServiceConnection.Stub的子类。连接状态控制Client和Service传输的binder媒介。
ActiveServices system_server端Service行为的管理类。
ServiceConnection 重写它的两个回调方法onServiceConnected()和onServiceDisconnected()，能在Service绑定和解绑时得到回调。
BindService时序图
3.源码分析
虚拟框架公司在国内搭了一个AOSP源码查询的网站，更新的代码已经到Android Q。所以之后的话可以直接看Q的代码。
和startService类似，bindService事实上通过mBase调用到ContextImpl的bindService。一路调用到ActivityManager.getService().startService。前篇已经说过，这个通过IPC调用到System_service进程的ActivityManagerService。
ContextImpl
@Override
public boolean bindService(Intent service, ServiceConnection conn,
int flags) {
warnIfCallingFromSystemProcess();
return bindServiceCommon(service, conn, flags, mMainThread.getHandler(), getUser());
}
private boolean bindServiceCommon(Intent service, ServiceConnection conn, int flags, Handler
handler, UserHandle user) {
// Keep this in sync with DevicePolicyManager.bindDeviceAdminServiceAsUser.
IServiceConnection sd;
if (conn == null) {
throw new IllegalArgumentException("connection is null");
}
if (mPackageInfo != null) {
//这里通过将传入的ServiceConnection进行缓存封装，得到一个IServiceConnection对象。
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().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();
}
}
这里先看一下getServiceDispatcher的操作。这里以context为key值，保存了连接类ServiceConnection和传输类IServiceConnection的值。
LoadedApk
public final IServiceConnection getServiceDispatcher(ServiceConnection c,
Context context, Handler handler, int flags) {
synchronized (mServices) {
LoadedApk.ServiceDispatcher sd = null;
ArrayMap map = mServices.get(context);
if (map != null) {
if (DEBUG) Slog.d(TAG, "Returning existing dispatcher " + sd + " for conn " + c);
sd = map.get(c);
}
if (sd == null) {
sd = new ServiceDispatcher(c, context, handler, flags);
if (DEBUG) Slog.d(TAG, "Creating new dispatcher " + sd + " for conn " + c);
if (map == null) {
map = new ArrayMap<>();
mServices.put(context, map);
}
map.put(c, sd);
} else {
sd.validate(context, handler);
}
return sd.getIServiceConnection();
}
}
ActivityManagerService还是直接调用ActiveServices的bindServiceLocked方法。
ActivityManagerService
public int bindService(IApplicationThread caller, IBinder token, Intent service,
String resolvedType, IServiceConnection connection, int flags,
String callingPackage, int userId) throws TransactionTooLargeException {
return bindIsolatedService(caller, token, service, resolvedType, connection, flags,
null, callingPackage, userId);
}
public int bindIsolatedService(IApplicationThread caller, IBinder token, Intent service,
String resolvedType, IServiceConnection connection, int flags, String instanceName,
String callingPackage, int userId) throws TransactionTooLargeException {
enforceNotIsolatedCaller("bindService");
// 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");
}
// 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");
}
}
}
synchronized(this) {
return mServices.bindServiceLocked(caller, token, service,
resolvedType, connection, flags, instanceName, callingPackage, userId);
}
}
public void updateServiceGroup(IServiceConnection connection, int group, int importance) {
synchronized (this) {
mServices.updateServiceGroupLocked(connection, group, importance);
}
}
bindServiceLocked的过程，创建了一个bindings不为空的ServiceRecord对象，往下传递。我们启动Service的时候，需要传递标志位Context.BIND_AUTO_CREATE。所以这里可以看到，如果Service不在运行状态，又跑入了上一篇描述的bringUpServiceLocked流程。这里不再此描述此流程。可以回看上一篇。
ActiveServices
int bindServiceLocked(IApplicationThread caller, IBinder token, Intent service,
...
try {
...
mAm.startAssociationLocked(callerApp.uid, callerApp.processName,
callerApp.getCurProcState(), s.appInfo.uid, s.appInfo.longVersionCode,
s.instanceName, s.processName);
// Once the apps have become associated, if one of them is caller is ephemeral
// the target app should now be able to see the calling app
mAm.grantEphemeralAccessLocked(callerApp.userId, service,
UserHandle.getAppId(s.appInfo.uid), UserHandle.getAppId(callerApp.uid));
//这里对ServiceRecord的bindings做了赋值
//上一篇realStartServiceLocked方法没有触发requestServiceBindingsLocked
//但是这里就会不一样了.
//需要注意的是，这里pendingStarts会为空，所以后面的sendServiceArgsLocked不触发
AppBindRecord b = s.retrieveAppBindingLocked(service, callerApp);
ConnectionRecord c = new ConnectionRecord(b, activity,
connection, flags, clientLabel, clientIntent,
callerApp.uid, callerApp.processName, callingPackage);
IBinder binder = connection.asBinder();
s.addConnection(binder, c);
b.connections.add(c);
if (activity != null) {
activity.addConnection(c);
}
b.client.connections.add(c);
c.startAssociationIfNeeded();
...
//我们知道，如果需要Service不在运行状态的时候触发，需要设置标志Context.BIND_AUTO_CREATE
if ((flags&Context.BIND_AUTO_CREATE) != 0) {
s.lastActivity = SystemClock.uptimeMillis();
if (bringUpServiceLocked(s, service.getFlags(), callerFg, false,
permissionsReviewRequired) != null) {
return 0;
}
}
...
} finally {
Binder.restoreCallingIdentity(origId);
}
return 1;
}
和上一篇的realStartServiceLocked行为不同的是，因为上面赋值了bindings，所以在Service的onCreate后，会触发scheduleBindService而不再是上篇的scheduleServiceArgs。
ActiveServices
private final void realStartServiceLocked(ServiceRecord r,
ProcessRecord app, boolean execInFg) throws RemoteException {
//Service的进程拉起和onCreate触发不再复述
//请看上一篇
...
//这里由于上面对bindings做了赋值，所以能触发
requestServiceBindingsLocked(r, execInFg);
//pendingStarts会为空，所以什么都没做
sendServiceArgsLocked(r, execInFg, true);
...
}
private final void requestServiceBindingsLocked(ServiceRecord r, boolean execInFg)
throws TransactionTooLargeException {
for (int i=r.bindings.size()-1; i>=0; i--) {
IntentBindRecord ibr = r.bindings.valueAt(i);
if (!requestServiceBindingLocked(r, ibr, execInFg, false)) {
break;
}
}
}
private final boolean requestServiceBindingLocked(ServiceRecord r, IntentBindRecord i,
boolean execInFg, boolean rebind) throws TransactionTooLargeException {
...
try {
...
r.app.thread.scheduleBindService(r, i.intent.getIntent(), rebind,
r.app.getReportedProcState());
}
...
}
熟悉的ApplicationThread->H->ActivityThread三连招。
ApplicationThread
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);
}
H
case BIND_SERVICE:
Trace.traceBegin(Trace.TRACE_TAG_ACTIVITY_MANAGER, "serviceBind");
handleBindService((BindServiceData)msg.obj);
Trace.traceEnd(Trace.TRACE_TAG_ACTIVITY_MANAGER);
ActvityThread
private void handleBindService(BindServiceData data) {
Service s = mServices.get(data.token);
if (DEBUG_SERVICE)
Slog.v(TAG, "handleBindService s=" + s + " rebind=" + data.rebind);
if (s != null) {
try {
data.intent.setExtrasClassLoader(s.getClassLoader());
data.intent.prepareToEnterProcess();
try {
//与StartService不同的是，这里会调用
//AMS的publishService
if (!data.rebind) {
IBinder binder = s.onBind(data.intent);
ActivityManager.getService().publishService(
data.token, data.intent, binder);
} else {
s.onRebind(data.intent);
ActivityManager.getService().serviceDoneExecuting(
data.token, SERVICE_DONE_EXECUTING_ANON, 0, 0);
}
ensureJitEnabled();
} 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);
}
}
}
}
AMS的publishService行为被触发。
上面可以看到，Service已经创建并且调用onCreate方法。下面我们看下scheduleServiceArgs做了什么。
ActivityManagerService
public void publishService(IBinder token, Intent intent, IBinder service) {
// Refuse possible leaked file descriptors
if (intent != null && intent.hasFileDescriptors() == true) {
throw new IllegalArgumentException("File descriptors passed in Intent");
}
synchronized(this) {
if (!(token instanceof ServiceRecord)) {
throw new IllegalArgumentException("Invalid service token");
}
mServices.publishServiceLocked((ServiceRecord)token, intent, service);
}
}
ActiveServices
void publishServiceLocked(ServiceRecord r, Intent intent, IBinder service) {
final long origId = Binder.clearCallingIdentity();
...
try {
//这里是之前传入的IServiceConnection对象
//所以我们直接往回找就好
c.conn.connected(r.name, service, false);
}
...
}
在LoadedApk里，可以找到类InnerConnection，看它的connected行为。
InnerConnection
public void connected(ComponentName name, IBinder service, boolean dead)
throws RemoteException {
LoadedApk.ServiceDispatcher sd = mDispatcher.get();
if (sd != null) {
sd.connected(name, service, dead);
}
}
ServiceDispatcher
public void connected(ComponentName name, IBinder service, boolean dead) {
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) {
...
// If there is a new viable service, it is now connected.
if (service != null) {
mConnection.onServiceConnected(name, service);
} else {
// The binding machinery worked, but the remote returned null from onBind().
mConnection.onNullBinding(name);
}
}
一路找下来，其实就是把之前缓存的ServiceConnection，触发回调onServiceConnected。
这篇的话，是基于Q的代码看bindService的行为流程。这方面android P和Android Q基本没有差异。
整个流程的话，和上篇startService类似。不同的是因为初始化的ServiceRecord的参数不同，所以触发了bind，后面publishService操作，主要是为了向发起bind的进程传递binder信息。这个的话按图理解流程，应该来说还是相当清晰的。
Service篇的话就这两篇，startService和bindService。Service其他相关的当前应当不会写相关博客。