android service插件化之二

------本文转载自Android插件化原理解析——Service的插件化      这一系列的文章实在是写的好! 

3. Service的插件化

现在已经明白了Service组件的工作原理，可对如何实现Service的插件化依然是一头雾水。

从上文的源码分析来看，Service组件与Activity有着非常多的相似之处：它们都是通过Context类完成启动，

接着通过 ActivityMnagaerNative进入AMS，最后又通过IApplicationThread这个Binder IPC到App进程的Binder线程池，

然后通过H转发消息到App进程的主线程，最终完成组件生命周期的回调；

对于Service组件，看起来好像可 以沿用Activity组件的插件化方式：Hook掉ActivityManagerNative以及H类，但事实真的如此吗？

3.1 Service与Activity的异同

Service组件和Activity组件有什么不同？这些不同使得对于插件化方案的选择又有什么影响？

3.1.1 用户交互对于生命周期的影响

首先，Activity与Service组件最大的不同点在 于，Activity组件可以与用户进行交互

；这一点意味着用户的行为会对Activity组件产生影响，对来说最重要的影响就是Activity组件的生命周期；

用户点击按钮从界面A跳转到界面B，会引起A和B这两个Activity一系列生命周期的变化。

而Service组件则代表后台任务，除了内存不足系统回收之外，它的生命周期完全由的代码控制，与用户的交互无关。

这意味着什么？

Activity组件的生命周期受用户交互影响，而这种变化只有Android系统才能感知，因此必须把插件的Activity交给系统管理，

才能拥有完整的生命周期；但Service组件的生命周期不受外界因素影响，那么自然而然，可以手动控制它的生命周期，

就像对于BroadcastReceiver的插件化方式一样！Activity组件的插件化无疑是比较复杂的，

为了把插件Activity交给系统 管理进而拥有完整生命周期，设计了一个天衣无缝的方案骗过了AMS；

既然Service的生命周期可以由自己控制，那么可以有更简单的方案实现它的插件化。

3.1.2 Activity的任务栈

上文指出了Activity和Service组件在处理用户交互方面的不同，这使得对于Service组建的插件化可以选择一种较为简单的方式；

也许你会问，那采用Activity插件化的那一套技术能够实现Service组件的插件化吗？

很遗憾，答案是不行的。虽然Activity的插件化技术更复杂，但是这种方案并不能完成Service组件的插件化——复杂的方案并不意味了它能处理更多的问题。

原因在于Activity拥有任务栈的概念。或许你觉得任务栈并不是什么了不起的东西，但是，这确实是Service组件与Activity组件插件化方式分道扬镳的根本原因。

任务栈的概念使得Activtiy的创建就代表着入栈，销毁则代表出栈；又由于Activity代表着与用户交互的界面，

所以这个栈的深度不可能太 深——Activity栈太深意味着用户需要狂点back键才能回到初始界面，这种体验显然有问题；

因此，插件框架要处理的Activity数量其实是有 限的，所以在AndroidManifest.xml中声明有限个StubActivity就能满足插件启动近乎无限个插件Activity的需求。

但是Service组件不一样，理论情况下，可以启动的Service组件是无限的——除了硬件以及内存资源，

没有什么限制它的数目；如果采用 Activity的插件化方式，就算在AndroidMafenist.xml中声明再多的StubService，

总有不能满足插件中要启动的 Service数目的情况出现。也许有童鞋会说，可以用一个StubService对应多个插件Service，

这确实能解决部分问题；但是，下面的这个区别让这种设想彻底泡汤。

3.1.3 Service无法拥有多实例

Service组件与Activity组件另外一个不同点在于，对同一个Service调用多次startService并不会启动多个Service实例，

而非特定Flag的Activity是可以允许这种 情况存在的，因此如果用StubService的方式，为了实现Service的这种特性，

必须建立一个StubService到插件Service的一 个Map，Map的这种一一对应关系使得使用一个StubService对应多个插件Service的计划成为天方夜谭。

至此，结论已经非常清晰——对于Service组件的插件化，不能简单地套用Activity的方案。

3.2 如何实现Service的插件化？

上文指出，不能套用Activity的方案实现Service组件的插件化，可以通过手动控制Service组件的生命周期实现；

Service的生命周期相当简单：整个生命周期从调用onCreate() 开始起，到 onDestroy() 返回时结束。

对于非绑定服务，就是从startService调用到stopService或者stopSelf调用。对于绑定服务，就是 bindService调用到unbindService调用；

如果要手动控制Service组件的生命周期，只需要模拟出这个过程即可；而实现这一点并不复杂：

 1.如果以startService方式启动插件Service，直接回调要启动的Service对象的onStartCommand方法即可；

如果用stopService或者stopSelf的方式停止Service，只需要回调对应的Service组件的onDestroy方法。

 2.如果用bindService方式绑定插件Service，可以调用对应Service对应的onBind方法，获取onBind方法返回的Binder对象，

然后通过ServiceConnection对象进行回调统计；unBindService的实现同理。

3.2.1 完全手动控制

现在已经有了实现思路，那么具体如何实现呢？

必须在startService,stopService等方法被调用的时候拿到控制权，才能手动去控制Service的生命周期；

要达到这一 目的非常简单——Hook ActivityManagerNative即可。在Activity的插件化方案中就通过这种方式接管了startActivity调用，相信读者 并不陌生。

Hook掉ActivityManagerNative之后，可以拦截对于startService以及stopService等方法的调用；

拦截之后，可以直接对插件Service进行操作：

 1.拦截到startService之后，如果Service还没有创建就直接创建Service对象（可能需要加载插件），

然后调用这个Service的onCreate,onStartCommond方法；如果Service已经创建，获取到原来创建的Service对象并执行其 onStartCommand方法。

 2.拦截到stopService之后，获取到对应的Service对象，直接调用这个Service的onDestroy方法。

这种方案简直简单得让人不敢相信！很可惜，这么干是不行的。

首先，Service存在的意义在于它作为一个后台任务，拥有相对较高运行时优先级；

除非在内存及其不足威胁到前台Activity的时候，这个组 件才会被系统杀死。上述这种实现完全把Service当作一个普通的Java对象使用了，

因此并没有完全实现Service所具备的能力。

其次，Activity以及Service等组件是可以指定进程的，而让Service运行在某个特定进程的情况非常常见——

所谓的远程 Service；用上述这种办法压根儿没有办法让某个Service对象运行在一个别的进程。

Android系统给开发者控制进程的机会太少了，要么在AndroidManifest.xml中通过process属性指定，

要么借助Java的Runtime类或者native的fork；这几种方式都无法让以一种简单的方式配合上述方案达到目的。

3.2.2代理分发技术

既然希望插件的Service具有一定的运行时优先级，那么一个货真价实的Service组件是必不可少的——

只有这种被系统认可的真正的Service组件才具有所谓的运行时优先级。

因此，可以注册一个真正的Service组件ProxyService，让这个Service承载一个真正的Service组件所具备的能力 （进程优先级等）；

当启动插件的服务比如PluginService的时候，统一启动这个ProxyService，当这个ProxyService 运行起来之后，

再在它的onStartCommand等方法里面进行分发，执行PluginService的onStartCommond等对应的方法；把这种方案形象地称为「代理分发技术」

 

代理分发技术也可以完美解决插件Service可以运行在不同的进程的问题——可以在AndroidManifest.xml中注册多个ProxyService，

指定它们的process属性，让它们运行在不同的进程；当启动的插件Service希望运行在一个新的进程时，

可以选择 某一个合适的ProxyService进行分发。也许有童鞋会说，那得注册多少个ProxyService才能满足需求啊？

理论上确实存在这问题，但事实上，一个App使用超过10个进程的几乎没有；因此这种方案是可行的。

3.3 Service插件化的实现

现在已经设计出了Service组件的插件化方案，接下来以startService以及stopService为例实现这个过程。

3.3.1 注册代理Service

需要一个货真价实的Service组件来承载进程优先级等功能，因此需要在AndroidManifest.xml中声明一个或者多个（用以支持多进程）这样的Sevice：

<service        android:name="com.weishu.upf.service_management.app.ProxyService"        android:process="plugin01"/>

3.3.2 拦截startService

要手动控制Service组件的生 命周期，需要拦截startService,stopService等调用，

并且把启动插件Service全部重定向为启动ProxyService（保留原始插件Service信息）；这个拦截过程需要HookActvityManagerNative。

public static void hookActivityManagerNative() throws ClassNotFoundException,        NoSuchMethodException, InvocationTargetException,        IllegalAccessException, NoSuchFieldException {    Class<?> activityManagerNativeClass = Class.forName("android.app.ActivityManagerNative");    Field gDefaultField = activityManagerNativeClass.getDeclaredField("gDefault");    gDefaultField.setAccessible(true);    Object gDefault = gDefaultField.get(null);    // gDefault是一个 android.util.Singleton对象; 取出这个单例里面的字段    Class<?> singleton = Class.forName("android.util.Singleton");    Field mInstanceField = singleton.getDeclaredField("mInstance");    mInstanceField.setAccessible(true);    // ActivityManagerNative 的gDefault对象里面原始的 IActivityManager对象    Object rawIActivityManager = mInstanceField.get(gDefault);    // 创建一个这个对象的代理对象, 然后替换这个字段, 让的代理对象帮忙干活    Class<?> iActivityManagerInterface = Class.forName("android.app.IActivityManager");    Object proxy = Proxy.newProxyInstance(Thread.currentThread().getContextClassLoader(),            new Class<?>[] { iActivityManagerInterface }, new IActivityManagerHandler(rawIActivityManager));    mInstanceField.set(gDefault, proxy);}

在收到startService,stopService之后可以进行具体的操作，对于startService来说，就是直接替换启动的插件Service为ProxyService等待后续处理，代码如下：

if ("startService".equals(method.getName())) {    // API 23:    // public ComponentName startService(IApplicationThread caller, Intent service,    //        String resolvedType, int userId) throws RemoteException    // 找到参数里面的第一个Intent 对象    Pair<Integer, Intent> integerIntentPair = foundFirstIntentOfArgs(args);    Intent newIntent = new Intent();    // 代理Service的包名, 也就是自己的包名    String stubPackage = UPFApplication.getContext().getPackageName();    // 这里把启动的Service替换为ProxyService, 让ProxyService接收生命周期回调    ComponentName componentName = new ComponentName(stubPackage, ProxyService.class.getName());    newIntent.setComponent(componentName);    // 把原始要启动的TargetService先存起来    newIntent.putExtra(AMSHookHelper.EXTRA_TARGET_INTENT, integerIntentPair.second);        // 替换掉Intent, 达到欺骗AMS的目的    args[integerIntentPair.first] = newIntent;    Log.v(TAG, "hook method startService success");    return method.invoke(mBase, args);}

3.3.3 分发Service

Hook ActivityManagerNative之后，所有的插件Service的启动都被重定向了到了注册的ProxyService，

这样可以保证们的插件Service有一个真正的Service组件作为宿主；但是要执行特定插件Service的任务，

必须把这个任务分发到真正要启动的Service上去；以onStart为例，在启动ProxyService之后，

会收到ProxyService的onStart回调，可以在这个方法里面把具体的任务交给原始要启动的插件Service组件：

public void onStart(Intent intent, int startId) {    Log.d(TAG, "onStart() called with " + "intent = [" + intent + "], startId = [" + startId + "]");    // 分发Service    ServiceManager.getInstance().onStart(intent, startId);    super.onStart(intent, startId);}

1加载Service

可以在ProxyService里面把任务转发给真正要启动的插件 Service组件，要完成这个过程肯定需要创建一个对应的插件Service对象，

比如PluginService；但是通常情况下插件存在与单独的文件之中，正常的方式是无法创建这个PluginService对象的，

宿主程序默认的ClassLoader无法加载插件中对应的这个类；所以，要创建这个对应的PluginService对象，

必须先完成插件的加载过程，让这个插件中的所有类都可以被正常访问；这种技术在之前专门讨论过,这里选择第一种简单的方案。

public static void patchClassLoader(ClassLoader cl, File apkFile, File optDexFile)        throws IllegalAccessException, NoSuchMethodException, IOException, InvocationTargetException, InstantiationException, NoSuchFieldException {    // 获取 BaseDexClassLoader : pathList    Field pathListField = DexClassLoader.class.getSuperclass().getDeclaredField("pathList");    pathListField.setAccessible(true);    Object pathListObj = pathListField.get(cl);    // 获取 PathList: Element[] dexElements    Field dexElementArray = pathListObj.getClass().getDeclaredField("dexElements");    dexElementArray.setAccessible(true);    Object[] dexElements = (Object[]) dexElementArray.get(pathListObj);    // Element 类型    Class<?> elementClass = dexElements.getClass().getComponentType();    // 创建一个数组, 用来替换原始的数组    Object[] newElements = (Object[]) Array.newInstance(elementClass, dexElements.length + 1);    // 构造插件Element(File file, boolean isDirectory, File zip, DexFile dexFile) 这个构造函数    Constructor<?> constructor = elementClass.getConstructor(File.class, boolean.class, File.class, DexFile.class);    Object o = constructor.newInstance(apkFile, false, apkFile, DexFile.loadDex(apkFile.getCanonicalPath(), optDexFile.getAbsolutePath(), 0));    Object[] toAddElementArray = new Object[] { o };    // 把原始的elements复制进去    System.arraycopy(dexElements, 0, newElements, 0, dexElements.length);    // 插件的那个element复制进去    System.arraycopy(toAddElementArray, 0, newElements, dexElements.length, toAddElementArray.length);    // 替换    dexElementArray.set(pathListObj, newElements);

2 匹配过程

上文中把启动插件Service重定向为启动ProxyService，现在 ProxyService已经启动，

因此必须把控制权交回原始的PluginService；在加载插件的时候，存储了插件中所有的Service组件的信息，

因此，只需要根据Intent里面的Component信息就可以取出对应的PluginService。

private ServiceInfo selectPluginService(Intent pluginIntent) {    for (ComponentName componentName : mServiceInfoMap.keySet()) {        if (componentName.equals(pluginIntent.getComponent())) {            return mServiceInfoMap.get(componentName);        }    }    return null;}

3创建以及分发

插件被加载之后，就需要创建插件Service对应的Java对象了；由于这些类是在运行时动态加载进来的，

肯定不能直接使用new关键字——需要使用反射机制。但是下面的代码创建出插件Service对象能满足要求吗？

ClassLoader cl = getClassLoader();Service service = cl.loadClass("com.plugin.xxx.PluginService1");

Service作为Android系统的组件，最重要的特点是它具有Context；所以，直接通过反射创建出来的这个PluginService

就是一个壳子——没有Context的Service能干什么？因此需要给将要创建的Service类创建出 Conetxt；

但是Context应该如何创建呢？平时压根儿没有这么干过，Context都是系统给创建好的。既然这样，

可以参照一下系 统是如何创建Service对象的；在上文的Service源码分析中，

在ActivityThread类的handleCreateService完成了这个步骤，摘要如下：

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();

可以看到，系统也是通过反射创建出了对应的Service对象，然后也创建了对应的Context，并给Service注入了活力。

如果模拟系统创建Context这个过程，势必需要进行一系列反射调用，那么何不直接反射handleCreateService方法呢？

当然，handleCreateService这个方法并没有把创建出来的Service对象作为返回值返回，

而是存放在ActivityThread的成员变量mService之中，这个是小case，反射取出来就行；所以，创建Service对象的代码如下：

/** * 通过ActivityThread的handleCreateService方法创建出Service对象 * @param serviceInfo 插件的ServiceInfo * @throws Exception */private void proxyCreateService(ServiceInfo serviceInfo) throws Exception {    IBinder token = new Binder();    // 创建CreateServiceData对象, 用来传递给ActivityThread的handleCreateService 当作参数    Class<?> createServiceDataClass = Class.forName("android.app.ActivityThread$CreateServiceData");    Constructor<?> constructor  = createServiceDataClass.getDeclaredConstructor();    constructor.setAccessible(true);    Object createServiceData = constructor.newInstance();    // 写入创建的createServiceData的token字段, ActivityThread的handleCreateService用这个作为key存储Service    Field tokenField = createServiceDataClass.getDeclaredField("token");    tokenField.setAccessible(true);    tokenField.set(createServiceData, token);    // 写入info对象    // 这个修改是为了loadClass的时候, LoadedApk会是主程序的ClassLoader, 选择Hook BaseDexClassLoader的方式加载插件    serviceInfo.applicationInfo.packageName = UPFApplication.getContext().getPackageName();    Field infoField = createServiceDataClass.getDeclaredField("info");    infoField.setAccessible(true);    infoField.set(createServiceData, serviceInfo);    // 写入compatInfo字段    // 获取默认的compatibility配置    Class<?> compatibilityClass = Class.forName("android.content.res.CompatibilityInfo");    Field defaultCompatibilityField = compatibilityClass.getDeclaredField("DEFAULT_COMPATIBILITY_INFO");    Object defaultCompatibility = defaultCompatibilityField.get(null);    Field compatInfoField = createServiceDataClass.getDeclaredField("compatInfo");    compatInfoField.setAccessible(true);    compatInfoField.set(createServiceData, defaultCompatibility);    Class<?> activityThreadClass = Class.forName("android.app.ActivityThread");    Method currentActivityThreadMethod = activityThreadClass.getDeclaredMethod("currentActivityThread");    Object currentActivityThread = currentActivityThreadMethod.invoke(null);    // private void handleCreateService(CreateServiceData data) {    Method handleCreateServiceMethod = activityThreadClass.getDeclaredMethod("handleCreateService", createServiceDataClass);    handleCreateServiceMethod.setAccessible(true);    handleCreateServiceMethod.invoke(currentActivityThread, createServiceData);    // handleCreateService创建出来的Service对象并没有返回, 而是存储在ActivityThread的mServices字段里面, 这里手动把它取出来    Field mServicesField = activityThreadClass.getDeclaredField("mServices");    mServicesField.setAccessible(true);    Map mServices = (Map) mServicesField.get(currentActivityThread);    Service service = (Service) mServices.get(token);    // 获取到之后, 移除这个service, 只是借花献佛    mServices.remove(token);    // 将此Service存储起来    mServiceMap.put(serviceInfo.name, service);}

现在已经创建出了对应的PluginService，并且拥有至关重要的Context对象；接下来就可以把消息分发给原始的PluginService组件了，

这个分发的过程很简单，直接执行消息对应的回调(onStart,onDestroy等）即可；因此，完整的startService分发过程如下：

public void onStart(Intent proxyIntent, int startId) {    Intent targetIntent = proxyIntent.getParcelableExtra(AMSHookHelper.EXTRA_TARGET_INTENT);    ServiceInfo serviceInfo = selectPluginService(targetIntent);    if (serviceInfo == null) {        Log.w(TAG, "can not found service : " + targetIntent.getComponent());        return;    }    try {        if (!mServiceMap.containsKey(serviceInfo.name)) {            // service还不存在, 先创建            proxyCreateService(serviceInfo);        }        Service service = mServiceMap.get(serviceInfo.name);        service.onStart(targetIntent, startId);    } catch (Exception e) {        e.printStackTrace();    }}

至此，已经实现了Service组件的插件化；代码以startService, stopService为例进行了说明，bindService以及unbindService的原理是一样的。

4小节

本文中以绑定服务为例分析了Service组件的工作原理，并指出用户交导致组件生命周期的变化是 Activity与Service的根本差别，

这种差别使得插件方案对于它们必须采取不同的处理方式；最后通过手动控制Service组件的生命周期 结合「代理分发技术」

成功地实现了Service组件的插件化；这种插件化方案堪称「完美」，如果非要吹毛求疵，

那只能说由于同一个进程的所有 Service都挂载在同一个ProxyService上面，如果系统可用内存不够必须回收Service，

杀死一个ProxyService会导致一大票的插件Service歇菜。

实际使用过程中，Service组件的更新频度并不高，因此直接把插件Service注册到主程序也是可以接受的；

而且如果需要绑定远程Service，完全可以使用一个Service组件根据不同的Intent返回不同的IBinder，

所以不实现Service组件的插件化也能满足工 程需要。值得一提的是，对于Service组件的插件化方案实际上是一种「代理」的方式，

用这种方式也能实现Activity组件的插件化，有一些开源的插件方案比如 DL 就是这么做的。

迄今为止，讲述了了Activity、BroadcastReceiver以及Service的插件化方式，不知读者思索过没有，实现插件化的关键点在哪里？

Service，Activity等不过就是一些普通的Java类，它们之所称为四大组件，是因为他们有生命周期；

这也是简单地采用Java的动态加载技术无法实现插件化的原因——动态加载进来的Service等类如果没有它的生命周期，

无异于一个没有灵魂的傀儡。对于Activity组件，由于他的生命周期受用户交互影响，只有系统本身才能对这种交互有全局掌控力，

因此它的插件化方式是Hook AMS，但是生命周期依然交由系统管理；而Service以及BroadcastReceiver的生命周期没有额外的因素影响，

因此选择了手动控制其生命周期的方式。不论是借尸还魂还是女娲造人，对这些组件的插件化终归结底是要赋予组件“生命”。