本文将探讨Android四大组件之一——Service组件的插件化方式。
与Activity, BroadcastReceiver相比，Service组件的不同点在哪里呢？能否用与之相同的方式实现Service的插件化？
如果不行，它们的差别在哪里，应该如何实现Service的插件化？
接下来将围绕这几个问题展开，最终给出Service组件的插件化方式；
阅读本文之前，可以先clone一份understand-plugin-framework，参考此项目的service-management模块。本编文章的源码基于android 6.0.
连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的启动操作；
之后的启动过程与进程已经存在的情况下相同；可以自行分析。
