一、Service 插件化思路

很可惜，Small不支持Service的插件化，但是在项目中我们确实有这样的需求，那么就需要研究一下如何自己来实现Service的插件化。在讨论如何实现Service的插件化之前，必须有三点准备：

掌握Service的基本知识，包括Service的生命周期、如何启动和结束Service，bindService和startService之间的区别和联系，这一部分就不过多介绍了，大家可以看一下 Carson_Ho 大神这篇文章，介绍的很全面 Android四大组件：Service服务史上最全面解析。
了解Service启动的内部原理，对源码进行一次简单的走读，主要是对Service调用者、所有者以及AMS之间的三方通信有一个清晰的认识，大家可以看一下我之前写的这篇文章 Framework 源码解析知识梳理(5) - startService 源码分析。
掌握动态代理的知识，这里在前面分析Retrofit的时候也有介绍过，Retrofit 知识梳理(2) - Retrofit 动态代理内部实现。

在插件化知识梳理(6) - Small 源码分析之 Hook 原理这篇文章中，我们一起学习了如何实现Activity的插件化，简单地来说，实现原理就是：

在调用startActivity启动插件Activity后，通过替换mInstrumentation成员变量，拦截这一启动过程，在后台偷偷地把startActivity时传入的intent中的component替换成为在AndroidManifest.xml中预先注册的占坑Activity，再通知ActivityManagerService。
当ActivityManagerService完成调度后，有替换客户端中的ActivityThread中的mH中的mCallback，将占坑的Activity重新恢复成插件的Activity。

而Service的插件化也可以采用类似的方式，大体的思路如下：

在调用startService启动插件Service时，通过拦截ActivityManagerProxy的对应方法，将Intent中的插件Service类型替换成预先在AndroidManifest.xml中预先注册好的占坑Service。
当AMS通过ApplicationThreadProxy回调占坑Service对应的生命周期时，我们再在占坑Service中的onStartCommand中，去创建插件Service的实例，如果是第一次创建，那么先调用它的onCreate方法，再调用它的onStartCommand方法，否则，就只调用onStartCommand方法就可以了。
在调用stopService停止插件Service时，同样通过拦截ActivityManagerProxy的对应方法，去调用插件Service的onDestroy，如果此时发现没有任何一个与占坑Service关联的插件Service运行时，那么就可以停止插件Service了。

二、具体实现

传了一个简单的例子到仓库，大家可以简单地对照着看一下，下面，我们开始分析具体的实现。

2.1 准备工作

初始化的过程如下所示：

    public void setup(Context context) {
        try {
            //1.通过反射获取到ActivityManagerNative类。
            Class<?> activityManagerNativeClass = Class.forName("android.app.ActivityManagerNative");
            Field gDefaultField = activityManagerNativeClass.getDeclaredField("gDefault");
            gDefaultField.setAccessible(true);
            Object gDefault = gDefaultField.get(activityManagerNativeClass);

            //2.获取mInstance变量。
            Class<?> singleton = Class.forName("android.util.Singleton");
            Field instanceField = singleton.getDeclaredField("mInstance");
            instanceField.setAccessible(true);

            //3.获取原始的对象。
            Object original = instanceField.get(gDefault);

            //4.动态代理，用于拦截Intent。
            Class<?> iActivityManager = Class.forName("android.app.IActivityManager");
            Object proxy = Proxy.newProxyInstance(context.getClassLoader(), new Class[]{ iActivityManager }, new IActivityManagerInvocationHandler(original));
            instanceField.set(gDefault, proxy);

            //5.读取插件当中的Service。
            loadService();

            //6.占坑的Component。
            mStubComponentName = new ComponentName(ServiceManagerApp.getAppContext().getPackageName(), StubService.class.getName());
        } catch (Exception e) {
            e.printStackTrace();
        }
    }

这里最主要的就是做了两件事：

2.1.1 对 ActivityManagerNative.getDefault() 调用的拦截

这里应用到了动态代理的知识，我们用Proxy.newProxyInstance所创建的proxy对象，替代了ActivityManagerNative中的gDefault静态变量。在 Framework 源码解析知识梳理(1) - 应用程序与 AMS 的通信实现中，我们分析过，它其实是一个AMS在应用程序进程中的代理类。通过这一替换过程，那么当调用ActivityManagerNative.getDefault()方法时，就会先经过IActivityManagerInvocationHandler类，我们就可以根据invoke所传入的方法名，在方法真正被调用之前插入一些自己的逻辑（也就是前文所说的，将启动插件Service的Intent替换成启动占坑Service的Intent），最后才会通过Binder调用到达AMS端，以此达到了“欺骗系统”的目的。

下面是InvocationHandler的具体实现，构造函数中传入的是原始的ActivityManagerProxy对象。

    private class IActivityManagerInvocationHandler implements InvocationHandler {

        private Object mOriginal;


        public IActivityManagerInvocationHandler(Object original) {
            mOriginal = original;
        }

        @Override
        public Object invoke(Object proxy, Method method, Object[] args) throws Throwable {
            String methodName = method.getName();
            switch (methodName) {
                case "startService":
                    Intent matchIntent = null;
                    int matchIndex = 0;
                    for (Object object : args) {
                        if (object instanceof Intent) {
                            matchIntent = (Intent) object;
                            break;
                        }
                        matchIndex++;
                    }
                    if (matchIntent != null && ServiceManager.getInstance().isPlugService(matchIntent.getComponent())) {
                        Intent stubIntent = new Intent(matchIntent);
                        stubIntent.setComponent(getStubComponentName());
                        stubIntent.putExtra(KEY_ORIGINAL_INTENT, matchIntent);
                        //将插件的Service替换成占坑的Service。
                        args[matchIndex] = stubIntent;
                    }
                    break;
                case "stopService":
                    Intent stubIntent = null;
                    int stubIndex = 0;
                    for (Object object : args) {
                        if (object instanceof Intent) {
                            stubIntent = (Intent) object;
                            break;
                        }
                        stubIndex++;
                    }
                    if (stubIntent != null) {
                        boolean destroy = onStopService(stubIntent);
                        if (destroy) {
                            //如果需要销毁占坑的Service，那么就替换掉Intent进行处理。
                            Intent destroyIntent = new Intent(stubIntent);
                            destroyIntent.setComponent(getStubComponentName());
                            args[stubIndex] = destroyIntent;
                        } else {
                            //由于在onStopService中已经手动调用了onDestroy，因此这里什么也不需要做，直接返回就可以。
                            return null;
                        }
                    }
                    break;
                default:
                    break;
            }
            Log.d("ServiceManager", "call invoke, methodName=" + method.getName());
            return method.invoke(mOriginal, args);
        }
    }

先看startService，args参数中保存了startService所传入的实参，这里面就包含了启动插件Service的Intent，我们将目标Intent的Component替换成为占坑的Component，然后将原始的Intent保存在KEY_ORIGINAL_INTENT字段当中，最后，通过原始的对象调用到ActivityManagerService端。

2.1.2 加载插件 Service 类

这里其实就是用到了前面介绍的DexClassLoader的知识，详细的可以看一下前面的这两篇文章插件化知识梳理(7) - 类的动态加载入门，插件化知识梳理(8) - 类的动态加载源码分析。
最终，我们会将插件Service的Class对象保存在一个mLoadServices的Map当中，它的Key就是插件Service的包名和类名。

    private void loadService() {
        try {
            //从插件中加载Service类。
            File dexOutputDir = ServiceManagerApp.getAppContext().getDir("dex2", 0);
            String dexPath = Environment.getExternalStorageDirectory().toString() + PLUG_SERVICE_PATH;
            DexClassLoader loader = new DexClassLoader(dexPath, dexOutputDir.getAbsolutePath(), null, ServiceManagerApp.getAppContext().getClassLoader());
            try {
                Class clz = loader.loadClass(PLUG_SERVICE_NAME);
                mLoadedServices.put(new ComponentName(PLUG_SERVICE_PKG, PLUG_SERVICE_NAME), clz);
            } catch (Exception e) {
                e.printStackTrace();
            }
        } catch (Exception e) {
            e.printStackTrace();
        }
    }

2.2 启动插件 Service

接下来，在宿主中通过下面的方式启动插件Service类：

    public void startService(View view) {
        Intent intent = new Intent();
        intent.setComponent(new ComponentName(ServiceManager.PLUG_SERVICE_PKG, ServiceManager.PLUG_SERVICE_NAME));
        startService(intent);
    }

按照前面的分析，首先会走到我们预设的“陷阱”当中，可以看到，这里面的Intent还是插件Service的Component名字：

然而，经过替换，最终调用时的Intent就变成了占坑的Service。

如果一切正常，接下来占坑Service就会启动，依次调用它的onCreate和onStartCommand方法，我们在onStartCommand中，再去回调插件Service对应的生命周期：

public class StubService extends Service {

    @Override
    public void onCreate() {
        super.onCreate();
        Log.d("StubService", "onCreate");
    }

    @Override
    public int onStartCommand(Intent intent, int flags, int startId) {
        Log.d("StubService", "onStartCommand");
        ServiceManager.getInstance().onStartCommand(intent, flags, startId);
        return super.onStartCommand(intent, flags, startId);
    }

    @Override
    public IBinder onBind(Intent intent) {
        return null;
    }

    @Override
    public void onDestroy() {
        super.onDestroy();
        ServiceManager.getInstance().onDestroy();
        Log.d("StubService", "onDestroy");
    }
}

这里，我们取出之前保存在KEY_ORIGINAL_INTENT中原始的Intent，通过它找到对应插件Service的包名和类名，以此为key，在mLoadedServices中找到前面从插件apk中加载的Service类，并通过反射实例化该对象，如果是第一次创建，那么先执行它的onCreate方法，并将它保存在mAliveServices中，之后再执行它的onStartCommand方法。