插件化知识梳理(10) Service 插件化实现及原理

时间  2019-11-21
标签 插件 知识 梳理 service 实现 原理 繁體版
原文   原文链接

1、Service 插件化思路

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

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

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

而Service的插件化也能够采用相似的方式，大致的思路以下：github

  • 在调用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、具体实现

传了一个简单的例子到仓库，你们能够简单地对照着看一下，下面，咱们开始分析具体的实现。bash

2.1 准备工做

初始化的过程以下所示：app

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端，以此达到了“欺骗系统”的目的。ide

下面是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方法。

这一过程的打印以下图所示：

2.3 中止插件 Service

当咱们经过stopService方法，中止插件Service时，也会和前面相似，先走到拦截的逻辑当中：

而在 onStop方法中，咱们判断它是不是须要中止插件 Service，若是是那么就调用插件 Service的 onDestory()方法，而且判断与占坑 Service相关联的插件 Service是否都已经结束了，若是是，那么就返回 true，让占坑 Service也销毁。
销毁的时候，就是将插件 Service的 Intent替换成占坑 Service：
这时的打印为：

3、总结

以上，就是实现插件化Service的核心思路，实现起来并不简单，须要涉及到不少的知识，这已是插件化学习的第十篇文章了。若是你们能一路看下来，能够发现，其实插件化并无什么神秘的地方，若是咱们但愿实现任意一个组件的插件化，无非就是如下几点：

  • 组件的生命周期。
  • 组件的启动过程，最主要就是和ActivityManagerService的交互过程，这也是最难的地方，要花不少的时间去看源码，并且各个版本的API也可能有所差别。
  • 插件化经常使用技巧，也就是Hook，动态代理之类的知识。
  • 类动态加载的知识。

掌握了以上几点，对于市面上大厂的插件框架基本可以看懂个六七成，可是对于大多数人而言，并无这么多的时间和条件，去分析一些细节问题。我写的这些文章，也只能算是入门水平，和你们一块儿学习基本的思想。真正核心的东西，仍是须要有机会能应用到生产环境中才能真正掌握。

很惋惜，我也没有这样的机会，感受天天工做的时间都是在调UI、解Bug、浪费时间，只能靠着晚上的时间，一点点摸索，写Demo，哎，说出来都是泪，还有半年，继续加油吧！

更多文章，欢迎访问个人 Android 知识梳理系列：

相关文章
相关标签/搜索
每日一句
    每一个你不满意的现在，都有一个你没有努力的曾经。
本站公众号
   欢迎关注本站公众号,获取更多信息
联系我们 最近搜索 最新文章 沪ICP备13005482号-10 MyBatis教程 SQL 教程 MySQL教程 Java 教程 Thymeleaf 教程 Hibernate教程 Spring教程 Redis教程