前言

插件化技术最初源于免安装运行apk的想法，这个免安装的apk可以理解为插件

支持插件化的app可以在运行时加载和运行插件，这样便可以将app中一些不常用的功能模块做成插件，一方面减小了安装包的大小，另一方面可以实现app功能的动态扩展

插件化技术也得到了长足的发展；与此同时，React Native，PWA，App Bundle，以及最近的Flutter也如火如荼；由于实现插件化需要太多的黑科技，它给项目的维护成本和稳定性增加了诸多不确定性

我个人认为，2017年手淘Atlas插件化项目的开源标志着插件化的落幕;2018年Android 9.0上私有API的限制几乎称得上是盖棺定论了——曾经波澜壮阔的插件化进程必将要退出历史主流;如今的插件化技术朝两个方向发展：其一，插件化的工程特性：模块化/解耦被抽离，逐渐演进为稳定、务实的的组件化方案；其二，插件化的黑科技特性被进一步发掘，inline hook/method hook大行其道，走向双开，虚拟环境等等

虽然插件化终将落幕，但是它背后的技术原理包罗万象，值得每一个希望深入Android的小伙伴们学习

插件化的由来

为了满足产品中一些功能动态部署的需求，我们在android插件化开发方面进行了一些探索，并完成了一套比较成熟的插件管理框架

这套框架的主要特点：

● 支持插件的热更新（即插件更新后无需重启框架）

● 低侵入性（插件中资源加载及Activity跳转与原生应用开发基本一致）

下面结合以上两个特性对相关技术进行一些讲解希望能抛砖引玉

插件的热更新

插件框架的设计类似OSGI，每一个插件使用一个独立的类加载器进行加载；插件升级时会创建一个新的加载器来加载新版本所以即使框架不重启也不影响新版本的使用

在DVM中ClassLoader符合双亲委托加载模式，DexclassLoader同样遵守了这规则，Android中常用的类加载器关系如下：

● BootClassLoader: parentClassLoader=null, 负责加载系统类（比如：java.lang.* 、android.app.Activity等）

● PathClassLoader: parentClassLoader=BootClassLoader 负责加载我们自己的apk包中的类， 这里我们将其命名为 HostAppClassLoader

● ClassLoader.getSystemClassLoader() parentClassLoader=BootClassLoader 该类加载器自身并不加载任何类，根据具体使用场景可以在创建自定义ClassLoader时使用,但该框架中我们并没用到这个类

该框架中类加载器的关系如下：

● BootClassLoader->HostAppClassLoader-> FrameworkClassloader(DexCalssLoader)->APKPlugigClassLoader(DexCalssLoader)

● FrameworkClassloader 负责加载插件框架的实现类。为了使插件SDK可以自动升级，插件框架自身也是动态加载的，我们开发时加到项目中的jar包只是框架接口

插件化详解

ClassLoader Injection

简单来说，插件化场景下，会存在同一进程中多个 ClassLoader 的场景：

● 宿主 ClassLoader：宿主是安装应用，运行即自动创建

● 插件 ClassLoader：使用 new DexClassLoader 创建

我们称这个过程叫做 ClassLoader 注入;

● 完成注入后，所有来自宿主的类使用宿主的 ClassLoader 进行加载，所有来自插件 Apk 的类使用插件 ClassLoader 进行加载

● 而由于 ClassLoader 的双亲委派机制，实际上系统类会不受 ClassLoader 的类隔离机制所影响，这样宿主 Apk 就可以在宿主进程中使用来自于插件的组件类了

Runtime Container

● ClassLoader 注入后，就可以在宿主进程中使用插件 Apk 中的类，但是我们都知道 Android 组件都是由系统调用启动的，未安装的 Apk 中的组件，是未注册到 AMS 和 PMS 的，就好比你直接使用 startActivity 启动一个插件 Apk 中的组件，系统会告诉你无法找到

● 我们的解决方案很简单，即运行时容器技术，简单来说就是在宿主 Apk 中预埋一些空的 Android 组件，以 Activity 为例，我预置一个 ContainerActivity extends Activity 在宿主中，并且在 AndroidManifest.xml 中注册它

它要做的事情很简单，就是帮助我们作为插件 Activity 的容器，它从 Intent 接受几个参数，分别是插件的不同信息，如：

● pluginName;

● pluginApkPath;

● pluginActivityName等，

其实最重要的就是 pluginApkPath 和 pluginActivityName，当 ContainerActivity 启动时，我们就加载插件的 ClassLoader、Resource，并反射 pluginActivityName 对应的 Activity 类

当完成加载后，ContainerActivity 要做两件事：

● 转发所有来自系统的生命周期回调至插件 Activity

● 接受 Activity 方法的系统调用，并转发回系统

插件化技术难点

● 反射并执行插件 Apk 中的代码(ClassLoader Injection)

● 让系统能调用插件 Apk 中的组件(Runtime Container)

● 正确识别插件 Apk 中的资源(Resource Injection)

什么是Gradle

Gradle是一个用于构建Android工程的工具，同时它也是一个编程框架；Gradle用于帮助我们自动管理编译流程，它允许我们定义个性化的编译内容，每个工程拥有自己的源码和资源的同时，还能使用一些通用的配置。而且Gradle和Android Studio是分离的，我们可以在不启动Android Studio的同时，单独使用命令行完成工程的编译工作

Gradle语言具有以下特点：

● Groovy语言是一种DSL，即Domain Specific Language，领域相关语言，有自己特有的术语

● Gradle 是一个基于 Apache Ant 和 Apache Maven 概念的项目自动化构建工具；Gradle 就是工程的管理，帮我们做了依赖、打包、部署、发布、各种渠道的差异管理等工作

● Gradle脚本是基于Groovy语言来编译执行的，Java、Groovy、Kotlin等都是基于JVM运行的，所以他们在语法上共性很多，熟悉Java的同学应该对Groovy上手很快

编写方法

在 Android 下的 gradle 插件共分为 两大类：

● 脚本插件：同普通的 gradle 脚本编写形式一样，可以直接写在build.gradle文件中，也可以自己新建一个 gradle 脚本文件中写

● 对象插件：通过插件全路径类名或 id 引用，

主要有三种编写形式，如下所示：

● 在当前构建脚本下直接编写

● 在 buildSrc 目录下编写

● 在完全独立的项目中编写

Gradle有什么优点

Gradle是一款基于JVM的专注于灵活性和性能的开源构建工具

在我们开发软件时，会面临相似的情况就是，我们需要去用IDE来进行编码，当完成一些功能时会进行编译、单元测试、打包等工作，这些工作都需要开发人员手动来实现；而一般的软件都是迭代式开发的，一个版本接着一个版本，每个版本又可能有很多的功能，如果开发每次实现功能时都需要手动的进行编译、单元测试和打包等工作，那显然会非常耗时而且也容易出现问题，因此项目自动化应运而生

它有以下优点：

● 它可以尽量防止开发手动介入从而节省了开发的时间并减少错误的发生

● 自动化可以自定义有序的步骤来完成代码的编译、测试和打包等工作，让重复的步骤变得简单

● IDE可能受到不同操作系统的限制，而自动化构建是不会依赖于特定的操作系统和IDE的，具有平台无关性

● 它能够尽可能防止开发手动介入从而节省了开发的时间并减小错误的发生

● 自动化能够自定义有序的步骤来完成代码的编译、测试和打包等工做，让重复的步骤变得简单

● IDE可能受到不一样操做系统的限制，而自动化构建是不会依赖于特定的操做系统和IDE的，具备平台无关性

结语

技术是无止境的，你需要对自己提交的每一行代码、使用的每一个工具负责，不断挖掘其底层原理，才能使自己的技术升华到更高的层面

Android 架构师之路还很漫长，与君共勉

PS:有问题欢迎指正,可以在评论区留下你的建议和感受；
欢迎大家点赞评论，觉得内容可以的话，可以转发分享一下