插件化的诞生是为了解决什么问题？
我们不妨好好思考一下，作为客户端开发，平时工作中是否为这样的情况发愁：
所以说，插件化设计之初就是为了不安装新Apk，从而完成应用的更新迭代。
我之前所在的团队也做了插件化，主要的原因还是包体积的诉求，原因有两个：
转换率
上图是2018年谷歌IO披露的包体积与下载转化率之间的关系，时至今日，即使我们的网络状况已经有了很好的提升，但是优化包体积仍然是我们的目标，比如说：
所以我们可以看到，pdd这一方面做的很出色，仅有25m。
讲插件化之前，我们先科普一下其中的概念。
对于一个完整功能的App，我们可以将其划分成为很多模块，每个模块都可以将其划分成为一个Apk。然后将基础功能的Apk提交给应用市场上架，后续我们可以通过基础的Apk，下载其他模块的Apk，从而完成功能的扩展。
基础分包
在整个过程中，我们称提交给应用市场的Apk为宿主，其他模块的Apk称之为插件。
相信没接触过插件化的同学可能会有一些疑问，我们平时打包的时候不是都是一个完整的Apk，为什么可以加载一个单独的Apk？好了，这就是插件化的第一个难点。
作为一个Android开发，我们都知道Android里面的Davilk和Art虚拟机和Java虚拟机不是同一套，所以他们也有着不同的类加载结构。
我们先回顾一下。
Jvm中加载的文件是class文件，再由Jvm翻译成特定平台的机器码。使用的类加载器如下：
整个加载架构如下：
Java类加载器结构
双亲委派机制保证了收到类加载请求的时候，优先让父类加载器去加载，父类加载器处理不了的时候，才会自己去加载，保证了类加载机制的稳定性。
我们上面提过，由于CPU和功耗环境不一致，Android虚拟机和Jvm有着很大的不同，Android里面的虚拟机在4.4.4以后，就是ART虚拟机了。早期的时候，安装的时候，会将dex文件直接编译成.oat这样的机器码，不过这样会有其他问题：
于是，在 Android 7.0 以后，第一次启动的时候，使用 Jit，针对dex，边解释边执行，然后在空闲的时候，将剩余的 dex 文件编译成机器码。
所以，我们可以注意到，每次应用升级的一段时间内，我们的启动时长会出现波动，过了几天以后，又会达到稳定的状态。因此，很多大厂，会针对这个过程优化，如：
我们再来看一下类加载机制，Android里面类加载的单位是dex，类加载器包括：
整个结构是这样的：
Android类加载器
如果是指定路径下的Apk或者jar包，我们需要将 PathClassLoader 替换成 DexClassLoader。到这里，第一个问题的解决思路就很清晰了，我们可以通过 DexClassLoader 加载插件Apk。
DexClassLoader的原理主要是通过DexPathList管理DexFile列表信息，从而加载到具体的类。
DexClassLoader
基于DexClassLoader，通常有两种方案:
单个DexClassLoader指的我们可能有多个插件Dex，多个插件Dex使用同一个DexClassLoader，如图：
将所有的插件中的类都由统一的DexClassLoader加载。
多个DexClassLoader指的是对于多个插件Dex，每一个Dex都会有自己的DexClassLoader，如图：
多ClassLoader结构
由各自DexClassLoader负责相关的插件的类加载。
看一下各自的优缺点：
分类 | 优点 | 缺点 |
单DexClassLoader | 类之间不隔离，可以互相调用 | 需要处理一些适配问题，比如不同插件加载了同一库的不同版本，可能引发兼容性问题 |
多DexClassLoader | 安全、稳定 | 类之间隔离，需要处理互相调用的问题 |
对于我们安卓系统来讲，仅仅能够加载插件中的类显然是不够的，还要能够启动插件中的的四大组件，并正确的执行四大组件的生命周期，为什么不能够执行四大组件的生命周期呢？
这是因为，只有在我们宿主包中Manifest文件中注册的四大组件才能够启动，如果没有注册，就会抛出异常，提醒你在Manifest中注册。这也是我们遇到的第二个问题。
Android 中四大组件包括Activity、Service、广播和ContentProvider，我们主要介绍一下Activity。
如果我们想让对应的Activity启动，一般有如下几种方法：
我们针对这几种分别解释一下。
将所有的四大组件在宿主包中都提前声明，这是最简单粗暴的方式。
但这种方式会丢失插件化的动态性，也就是说，如果想在插件包中，加入宿主包没有注册的Activity，这就会有问题。
那这种方式的优点呢？解决包体积的问题的同时不用处理复杂的组件加载以及伴随的生命周期的问题。
那如果想要保存插件的动态化加载呢？也就是说我们想要在插件包中的 Manifest 文件中进行注册。
默认情况下，如果我们启动一个没有在插件 Manifest 中注册的的 Activity，会发生 error，原因是启动过程中的 Instrumentation 中的 checkStartActivityResult 方法：
public class Instrumentation { public static void checkStartActivityResult(int res, Object intent) { if (!ActivityManager.isStartResultFatalError(res)) { return; } switch (res) { case ActivityManager.START_INTENT_NOT_RESOLVED: case ActivityManager.START_CLASS_NOT_FOUND: if (intent instanceof Intent && ((Intent)intent).getComponent() != null) throw new ActivityNotFoundException( "Unable to find explicit activity class " + ((Intent)intent).getComponent().toShortString() + "; have you declared this activity in your AndroidManifest.xml?"); throw new ActivityNotFoundException( "No Activity found to handle " + intent); ... } }}所以我们传入的Activity必须要在宿主包中注册，这样系统才能检验通过，那怎么才能实现动态化呢？
答案是使用占位Activity，这其实就是使用的代理模式。每次需要启动插件中的Activity的时候，先启动一个占位Activity实例，然后在占位Activity实例里面持有目标Activity的实例对象，从而通过反射或者其他方法调用实例的生命周期。
生命周期处理
这种方法的问题主要如下：
第三种方法我们称之为欺骗系统，具体怎么个欺骗方法呢？
先看一下具体Activity的启动流程，默认大家对Activity的启动流程比较了解了：
Activity启动流程
我们在整个过程中，同样也需要一个占位Activity。
使用步骤如下：
最终，系统以为自己调用的是占位Activity的对象，并且和实际上调用的是PluginActivity进行绑定。
在最终使用之前，我们在插件中的Android资源文件并不能使用，比如说图片、字符串、布局文件等，原因是插件的资源路径并没有被添加。
Apk安装以后，我们都是通过 Resource 对象去访问资源，简单看一下 Resouce 的构造方法：
@Deprecated public Resources(AssetManager assets, DisplayMetrics metrics, Configuration config) { this(null); mResourcesImpl = new ResourcesImpl(assets, metrics, config, new DisplayAdjustments()); }可以看到，构造函数中有一个参数是 AssetManager，我们可以通过在 AssetManager 中，加入我们插件的资源地址，就可以访问到插件中的资源。
现在可以访问具体的资源了，和之前的类加载方式类似，也有两种加载方式：
首先，我们想一下为什么会有资源冲突问题？其实是因为宿主和插件包都是独立编译的，所以打包的时候生成的资源Id会存在相同的情况，这个时候，访问的的时候就存在资源冲突。
我们项目之前采用的 Qigsaw 方案，所以简单介绍一下合并式的方案，资源id是8位16进制数表示：
Qigsaw
如上图：
所以我们对不同的插件包，进行打包的时候，前面的PP字段，可以进行依次递减，可以避免资源冲突的问题。常用的方案有：
Qigsaw使用的第一种方案。
本文是一篇入门插件化的文章，主要回答了插件化是什么，有什么难点，又是怎么解决的，其中没有涉及到很多代码，非常适合入门。
本文链接：http://www.28at.com/showinfo-26-112727-0.html面试官：你对插件化有什么了解？
声明：本网页内容旨在传播知识，若有侵权等问题请及时与本网联系，我们将在第一时间删除处理。邮件：2376512515@qq.com
上一篇： 停止使用 `let` 或为什么它在 JavaScript/TypeScript 中是不必要的
下一篇： 聊一聊Spring事务失效的12种场景
Copyright © 2016-2023 天津谷骐科技有限公司 版权所有 sitemap.xml
违法及侵权请联系：2376512515@qq.com 津ICP备18001702号
津公网安备 12010102000574号