------本文转载自 Android插件化原理解析——Service的插件化 这一系列的文章实在是写的好!
1, 概述
本文将探讨Android四大组件之一——Service组件的插件化方式。
与Activity, BroadcastReceiver相比,Service组件的不同点在哪里呢?能否用与之相同的方式实现Service的插件化?
如果不行,它们的差别在哪里,应该如何实现Service的插件化?
接下来将围绕这几个问题展开,最终给出Service组件的插件化方式;
阅读本文之前,可以先clone一份understand-plugin-framework,参考此项目的service-management模块。本编文章的源码基于android 6.0.
2, Service工作原理
连Service的工作原理都不了解,谈何插件化?知己知彼。
Service分为两种形式:以startService启动的服务和用bindService绑定的服务;
由于这两个过程大体相似,这里以稍复杂的bindService为例分析Service组件的工作原理。
绑定Service的过程是通过Context类的bindService完成的,这个方法需要三个参数:
第一个参数代表想要绑定的Service的Intent,第二个参数是一个ServiceConnetion,
可以通过这个对象接收到Service绑定成功或者失败的回调;第三个参数则是绑定时候的一些FLAG;
Context的具体实现在ContextImpl类,ContextImpl中的bindService方法直接调用了bindServiceCommon方法,此方法源码如下:
private boolean bindServiceCommon(Intent service, ServiceConnection conn, int flags,
UserHandle user) {
IServiceConnection sd;
if (conn == null) {
throw new IllegalArgumentException("connection is null");
}
if (mPackageInfo != null) {
// important
sd = mPackageInfo.getServiceDispatcher(conn, getOuterContext(),
mMainThread.getHandler(), 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();
int res = ActivityManagerNative.getDefault().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 new RuntimeException("Failure from system", e);
}
}
大致观察就能发现这个方法最终通过ActivityManagerNative借助AMS进而完成Service的绑定过程,
在跟踪AMS的bindService源码之前,关注一下这个方法开始处创建的sd变量。这个变量的类型是IServiceConnection,
如果读者还有印象,在广播的管理一文中也遇到过类似的处理方式——IIntentReceiver;
所以,这个IServiceConnection与 IApplicationThread以及IIntentReceiver相同,
都是ActivityThread给AMS提供的用来与之进行通信的 Binder对象;这个接口的实现类为LoadedApk.ServiceDispatcher。
这个方法最终调用了ActivityManagerNative的bindService,而这个方法的真正实现在AMS里面,源码如下:
public int bindService(IApplicationThread caller, IBinder token, Intent service,
String resolvedType, IServiceConnection connection, int flags, String callingPackage,
int userId) throws TransactionTooLargeException {
enforceNotIsolatedCaller("bindService");
// 略去参数校检
synchronized(this) {
return mServices.bindServiceLocked(caller, token, service,
resolvedType, connection, flags, callingPackage, userId);
}
}
bindService这个方法相当简单,只是做了一些参数校检之后直接调用了ActivityServices类的bindServiceLocked方法:
int bindServiceLocked(IApplicationThread caller, IBinder token, Intent service,
String resolvedType, IServiceConnection connection, int flags,
String callingPackage, int userId) throws TransactionTooLargeException {
final ProcessRecord callerApp = mAm.getRecordForAppLocked(caller);
// 参数校检,略
ServiceLookupResult res =
retrieveServiceLocked(service, resolvedType, callingPackage,
Binder.getCallingPid(), Binder.getCallingUid(), userId, true, callerFg);
// 结果校检, 略
ServiceRecord s = res.record;
final long origId = Binder.clearCallingIdentity();
try {
// ... 不关心, 略
mAm.startAssociationLocked(callerApp.uid, callerApp.processName,
s.appInfo.uid, s.name, s.processName);
AppBindRecord b = s.retrieveAppBindingLocked(service, callerApp);
ConnectionRecord c = new ConnectionRecord(b, activity,
connection, flags, clientLabel, clientIntent);
IBinder binder = connection.asBinder();
ArrayList<ConnectionRecord> clist = s.connections.get(binder);
// 对connection进行处理, 方便存取,略
clist.add(c);
if ((flags&Context.BIND_AUTO_CREATE) != 0) {
s.lastActivity = SystemClock.uptimeMillis();
if (bringUpServiceLocked(s, service.getFlags(), callerFg, false) != null) {
return 0;
}
}
// 与BIND_AUTO_CREATE不同的启动FLAG,原理与后续相同,略
} finally {
Binder.restoreCallingIdentity(origId);
}
return 1;
}
这个方法比较长,这里省去了很多无关代码,只列出关键逻辑;首先它通过retrieveServiceLocked方法
获取到了intent匹配到的需要bind到的Service组件res;然后把ActivityThread传递过来的IServiceConnection
使用ConnectionRecord进行了包装,方便接下来使用;最后如果启动的FLAG为BIND_AUTO_CREATE,
那么调用bringUpServiceLocked开始创建Service,跟踪这个方法:(非这种FLAG的代码已经省略,可以自行跟踪)
private final String bringUpServiceLocked(ServiceRecord r, int intentFlags, boolean execInFg,
boolean whileRestarting) throws TransactionTooLargeException {
// 略。。
final boolean isolated = (r.serviceInfo.flags&ServiceInfo.FLAG_ISOLATED_PROCESS) != 0;
final String procName = r.processName;
ProcessRecord app;
if (!isolated) {
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);
// 1. important !!!
realStartServiceLocked(r, app, execInFg);
return null;
} catch (TransactionTooLargeException e) {
throw e;
} catch (RemoteException e) {
Slog.w(TAG, "Exception when starting service " + r.shortName, e);
}
}
} else {
app = r.isolatedProc;
}
// Not running -- get it started, and enqueue this service record
// to be executed when the app comes up.
if (app == null) {
// 2. important !!!
if ((app=mAm.startProcessLocked(procName, r.appInfo, true, intentFlags,
"service", r.name, false, isolated, false)) == null) {
bringDownServiceLocked(r);
return msg;
}
if (isolated) {
r.isolatedProc = app;
}
}
// 略。。
return null;
}
这个方案同样也很长,但是实际上非常简单:注意注释的两个important的地方,
如果Service所在的进程已经启动,那么直接调用realStartServiceLocked方法来真正启动Service组件;
如果Service所在的进程还没有启动,那么先在AMS中记下这个要启动的Service组件,然后通过startProcessLocked启动新的进程。
先看Service进程已经启动的情况,也即realStartServiceLocked分支:
private final void realStartServiceLocked(ServiceRecord r,
ProcessRecord app, boolean execInFg) throws RemoteException {
// 略。。
boolean created = false;
try {
synchronized (r.stats.getBatteryStats()) {
r.stats.startLaunchedLocked();
}
mAm.ensurePackageDexOpt(r.serviceInfo.packageName);
app.forceProcessStateUpTo(ActivityManager.PROCESS_STATE_SERVICE);
app.thread.scheduleCreateService(r, r.serviceInfo,
mAm.compatibilityInfoForPackageLocked(r.serviceInfo.applicationInfo),
app.repProcState);
r.postNotification();
created = true;
} catch (DeadObjectException e) {
mAm.appDiedLocked(app);
throw e;
} finally {
// 略。。
}
requestServiceBindingsLocked(r, execInFg);
// 不关心,略。。
}
这个方法首先调用了app.thread的scheduleCreateService方法,知道,这是一个IApplicationThread对象,
它是App所在进程提供给AMS的用来与App进程进行通信的Binder对象,这个Binder的 Server端在
ActivityThread的ApplicationThread类,因此,跟踪ActivityThread类,这个方法的实现如下:
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);
}
它不过是转发了一个消息给ActivityThread的H这个Handler,H类收到这个消息之后,
直接调用了ActivityThread类的handleCreateService方法,如下:
private void handleCreateService(CreateServiceData data) {
unscheduleGcIdler();
LoadedApk packageInfo = getPackageInfoNoCheck(
data.info.applicationInfo, data.compatInfo);
Service service = null;
try {
java.lang.ClassLoader cl = packageInfo.getClassLoader();
service = (Service) cl.loadClass(data.info.name).newInstance();
} catch (Exception e) {
}
try {
ContextImpl context = ContextImpl.createAppContext(this, packageInfo);
context.setOuterContext(service);
Application app = packageInfo.makeApplication(false, mInstrumentation);
service.attach(context, this, data.info.name, data.token, app,
ActivityManagerNative.getDefault());
service.onCreate();
mServices.put(data.token, service);
try {
ActivityManagerNative.getDefault().serviceDoneExecuting(
data.token, SERVICE_DONE_EXECUTING_ANON, 0, 0);
} catch (RemoteException e) {
// nothing to do.
}
} catch (Exception e) {
}
}
看到这段代码,是不是似曾相识?!没错,这里与Activity组件的创建过程如出一辙!
所以这里就不赘述了,可以参阅 Activity生命周期管理。
需要注意的是,这里Service类的创建过程与Activity是略微有点不同的,虽然都是通过ClassLoader通过反射创建,
但是Activity却把创建过程委托给了Instrumentation类,而Service则是直接进行。
OK,现在ActivityThread里面的handleCreateService方法成功创建出了Service对象,并且调用了它的onCreate方法;
到这里的Service已经启动成功。scheduleCreateService这个Binder调用过程结束,
代码又回到了AMS进程的realStartServiceLocked方法。这里不得不感叹Binder机制的精妙,
如此简洁方便高效的跨进程调用,在进程之间来回穿梭,游刃有余。
realStartServiceLocked方法的代码如下:
private final void realStartServiceLocked(ServiceRecord r,
ProcessRecord app, boolean execInFg) throws RemoteException {
// 略。。
boolean created = false;
try {
synchronized (r.stats.getBatteryStats()) {
r.stats.startLaunchedLocked();
}
mAm.ensurePackageDexOpt(r.serviceInfo.packageName);
app.forceProcessStateUpTo(ActivityManager.PROCESS_STATE_SERVICE);
app.thread.scheduleCreateService(r, r.serviceInfo,
mAm.compatibilityInfoForPackageLocked(r.serviceInfo.applicationInfo),
app.repProcState);
r.postNotification();
created = true;
} catch (DeadObjectException e) {
mAm.appDiedLocked(app);
throw e;
} finally {
// 略。。
}
requestServiceBindingsLocked(r, execInFg);
// 不关心,略。。
}
这个方法在完成scheduleCreateService这个binder调用之后,执行了一个requestServiceBindingsLocked方法;
看方法名好像于「绑定服务」有关,它简单地执行了一个遍历然后调用了另外一个方法:
private final boolean requestServiceBindingLocked(ServiceRecord r, IntentBindRecord i,
boolean execInFg, boolean rebind) throws TransactionTooLargeException {
if (r.app == null || r.app.thread == null) {
return false;
}
if ((!i.requested || rebind) && i.apps.size() > 0) {
try {
bumpServiceExecutingLocked(r, execInFg, "bind");
r.app.forceProcessStateUpTo(ActivityManager.PROCESS_STATE_SERVICE);
r.app.thread.scheduleBindService(r, i.intent.getIntent(), rebind,
r.app.repProcState);
// 不关心,略。。
}
return true;
}
可以看到,这里又通过IApplicationThread这个Binder进行了一次IPC调用,
跟踪ActivityThread类里面的ApplicationThread的scheduleBindService方法,
发现这个方法不过通过Handler转发了一次消息,真正的处理代码在handleBindService里面:
private void handleBindService(BindServiceData data) {
Service s = mServices.get(data.token);
if (s != null) {
try {
data.intent.setExtrasClassLoader(s.getClassLoader());
data.intent.prepareToEnterProcess();
try {
if (!data.rebind) {
IBinder binder = s.onBind(data.intent);
ActivityManagerNative.getDefault().publishService(
data.token, data.intent, binder);
} else {
s.onRebind(data.intent);
ActivityManagerNative.getDefault().serviceDoneExecuting(
data.token, SERVICE_DONE_EXECUTING_ANON, 0, 0);
}
ensureJitEnabled();
} catch (RemoteException ex) {
}
} catch (Exception e) {
}
}
}
要Bind的Service终于在这里完成了绑定!绑定之后又通过ActivityManagerNative这个Binder进行一次IPC调用,
查看AMS的publishService方法,这个方法简单第调用了publishServiceLocked方法,源码如下:
void publishServiceLocked(ServiceRecord r, Intent intent, IBinder service) {
final long origId = Binder.clearCallingIdentity();
try {
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;
for (int conni=r.connections.size()-1; conni>=0; conni--) {
ArrayList<ConnectionRecord> clist = r.connections.valueAt(conni);
for (int i=0; i<clist.size(); i++) {
ConnectionRecord c = clist.get(i);
if (!filter.equals(c.binding.intent.intent)) {
continue;
}
try {
c.conn.connected(r.name, service);
} catch (Exception e) {
}
}
}
}
serviceDoneExecutingLocked(r, mDestroyingServices.contains(r), false);
}
} finally {
Binder.restoreCallingIdentity(origId);
}
}
还记得之前提到的那个IServiceConnection吗?在bindServiceLocked方法里面,
把这个IServiceConnection放到了一个ConnectionRecord的List中存放在ServiceRecord里面,
这里所做的就是取出已经被Bind的这个Service对应的IServiceConnection对象,然后调用它的connected方法;
这个IServiceConnection也是一个Binder对象,它的Server端在LoadedApk.ServiceDispatcher里面。
代码到这里已经很明确了,接下来的过程非常简单,感兴趣的读者自行查阅LoadedApk.ServiceDispatcher的connected方法,
一路跟踪弄清楚ServiceConnection回调过程,完成最后的拼图!
最后提一点,以上分析了Service所在进程已经存在的情况,如果Service所在进程不存在,
那么会调用startProcessLocked方法创建一个新的进程,并把需要启动的Service放在一个队列里面;
创建进程的过程通过Zygote fork出来,进程创建成功之后会调用ActivityThread的main方法,
在这个main方法里面间接调用到了AMS的 attachApplication方法,在AMS的attachApplication里面
会检查刚刚那个待启动Service队列里面的内容,并执行 Service的启动操作;
之后的启动过程与进程已经存在的情况下相同;可以自行分析。