不可多得的干货！Android插件化主流框架和实现原理

###写在前面&＃xff1b;
这几年移动开发业界兴起的「 插件化技术 」的旋风&＃xff0c;各个大厂都推出了自己的插件化框架&＃xff0c;各种开源框架都评价自身功能优越性&＃xff0c;令人目不暇接。随着公司业务快速发展&＃xff0c;项目增多&＃xff0c;开发资源却有限&＃xff0c;如何能在有限资源内满足需求和项目的增长&＃xff0c;同时又能快速响应问题和迭代新需求&＃xff0c;这就是一个矛盾点。此时&＃xff0c;插件化技术正好风生水起&＃xff0c;去了解各个主流框架实现思路&＃xff0c;看看能对目前工作是否有帮助&＃xff0c;是很有必要的。

主要分为以下几个部分

• 插件化介绍
• 入门知识
• 实现原理
• 主流框架
• 实战
• 小结
• 进阶资料

插件化介绍

百度百科里是这么定义插件的&＃xff1a;「 是一种遵循一定规范的应用程序接口编写出来的程序&＃xff0c;只能运行在程序规定的系统平台下&＃xff0c;而不能脱离指定的平台单独运行。」&＃xff0c;也就是说&＃xff0c;插件可以提供一种动态扩展能力&＃xff0c;使得应用程序在运行时加载原本不属于该应用的功能&＃xff0c;并且做到动态更新和替换。

那么在 Android 中&＃xff0c;何为「 插件化 」&＃xff0c;顾名思义&＃xff0c;就是把一些核心复杂依赖度高的业务模块封装成独立的插件&＃xff0c;然后根据不同业务需求进行不同组合&＃xff0c;动态进行替换&＃xff0c;可对插件进行管理、更新&＃xff0c;后期对插件也可进行版本管理等操作。在插件化中有两个概念需要讲解下&＃xff1a;

• 宿主

  所谓宿主&＃xff0c;就是需要能提供运行环境&＃xff0c;给资源调用提供上下文环境&＃xff0c;一般也就是我们主 APK &＃xff0c;要运行的应用&＃xff0c;它作为应用的主工程所在&＃xff0c;实现了一套插件的加载和管理的框架&＃xff0c;插件都是依托于宿主的APK而存在的。

• 插件

  插件可以想象成每个独立的功能模块封装为一个小的 APK &＃xff0c;可以通过在线配置和更新实现插件 APK 在宿主 APK 中的上线和下线&＃xff0c;以及动态更新等功能。

那么为何要使用插件化技术&＃xff0c;它有何优势&＃xff0c;能给我们带来什么样好处&＃xff0c;这里简单列举了以下几点&＃xff1a;

• 让用户不用重新安装 APK 就能升级应用功能&＃xff0c;减少发版本频率&＃xff0c;增加用户体验。
• 提供一种快速修复线上 BUG 和更新的能力。
• 按需加载不同的模块&＃xff0c;实现灵活的功能配置&＃xff0c;减少服务器对旧版本接口兼容压力。
• 模块化、解耦合、并行开发、 65535 问题。

入门知识

首先我们要知道插件化技术是属于比较复杂一个领域&＃xff0c;复杂点在于它涉及知识点广泛&＃xff0c;不仅仅是上层做应用架构能力&＃xff0c;还要求我们对 Android 系统底层知识需要有一定的认知&＃xff0c;这里简单罗列了其中会涉及的知识点&＃xff1a;

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-Nf35aPA2-1623503725283)(//upload-images.jianshu.io/upload_images/788498-6a65108a1e5a7b15.jpg?imageMogr2/auto-orient/strip|imageView2/2/w/492/format/webp)]

首先&＃xff0c;要介绍的是 Binder &＃xff0c;我们都知道 Android 多进程通信核心就是 Binder &＃xff0c;如果没有它真的寸步难行。 Binder 涉及两层技术&＃xff0c;你可以认为它是一个中介者模式&＃xff0c;在客户端和服务器端之间&＃xff0c; Binder 就起到中介的作用。如果要实现四大组件的插件化&＃xff0c;就需要在 Binder 上做修改&＃xff0c; Binder 服务端的内容没办法修改&＃xff0c;只能改客户端的代码&＃xff0c;而且四大组件的每个组件的客户端都不一样&＃xff0c;这个就需要深入研究了。学习Binder的最好方式是 AIDL &＃xff0c;这方面在网上有很多资料&＃xff0c;最简单的方式就是自己写个 aidl 文件自动生成一个 Java 类&＃xff0c;然后去查看这个Java类的每个方法和变量&＃xff0c;然后再去看四大组件&＃xff0c;其实都是跟 AIDL 差不多的实现方式。

其次&＃xff0c;是 App 打包的流程。代码写完了&＃xff0c;执行一次打包操作&＃xff0c;中途经历了资源打包、 Dex 生成、签名等过程。其中最重要的就是资源的打包&＃xff0c;即 AAPT 这一步&＃xff0c;如果宿主和插件的资源id冲突&＃xff0c;一种解决办法就是在这里做修改。

第三&＃xff0c; App 在手机上的安装流程也很重要。熟悉安装流程不仅对插件化有帮助&＃xff0c;在遇到安装 Bug 的时候也非常重要。手机安装 App 的时候&＃xff0c;经常会有下载异常&＃xff0c;提示资源包不能解析&＃xff0c;这时需要知道安装 App 的这段代码在什么地方&＃xff0c;这只是第一步。第二步需要知道&＃xff0c; App 下载到本地后&＃xff0c;具体要做哪些事情。手机有些目录不能访问&＃xff0c; App 下载到本地之后&＃xff0c;放到哪个目录下&＃xff0c;然后会生成哪些文件。插件化有个增量更新的概念&＃xff0c;如何下载一个增量包&＃xff0c;从本地具体哪个位置取出一个包&＃xff0c;这个包的具体命名规则是什么&＃xff0c;等等。这些细节都必须要清楚明白。

第四&＃xff0c;是 App 的启动流程。 Activity 启动有几种方式&＃xff1f;一种是写一个 startActivity &＃xff0c;第二种是点击手机 App &＃xff0c;通过手机系统里的 Launcher 机制&＃xff0c;启动 App 里默认的 Activity 。通常&＃xff0c; App 开发人员喜闻乐见的方式是第二种。那么第一种方式的启动原理是什么呢&＃xff1f;另外&＃xff0c;启动的时候&＃xff0c;Main 函数在哪里&＃xff1f;这个 Main 函数的位置很重要&＃xff0c;我们可以对它所在的类做修改&＃xff0c;从而实现插件化。

第五点更重要&＃xff0c;做 Android 插件化需要控制两个地方。首先是插件 Dex 的加载&＃xff0c;如何把插件 Dex 中的类加载到内存&＃xff1f;另外是资源加载的问题。插件可能是 Apk 也可能是 so 格式&＃xff0c;不管哪一种&＃xff0c;都不会生成 R.id &＃xff0c;从而没办法使用。这个问题有好几种解决方案。一种是是重写 Context 的 getAsset 、 getResource 之类的方法&＃xff0c;偷换概念&＃xff0c;让插件读取插件里的资源&＃xff0c;但缺点就是宿主和插件的资源 id 会冲突&＃xff0c;需要重写 AAPT 。另一种是重写 AMS中保存的插件列表&＃xff0c;从而让宿主和插件分别去加载各自的资源而不会冲突。第三种方法&＃xff0c;就是打包后&＃xff0c;执行一个脚本&＃xff0c;修改生成包中资源id。

第六点&＃xff0c;在实施插件化后&＃xff0c;如何解决不同插件的开发人员的工作区问题。比如&＃xff0c;插件1和插件2&＃xff0c;需要分别下载哪些代码&＃xff0c;如何独立运行&＃xff1f;就像机票和火车票&＃xff0c;如何只运行自己的插件&＃xff0c;而不运行别人的插件&＃xff1f;这是协同工作的问题。火车票和机票&＃xff0c;这两个 Android 团队的各自工作区是不一样的&＃xff0c;这时候就要用到 Gradle 脚本了&＃xff0c;每个项目分别有各自的仓库&＃xff0c;有各自不同的打包脚本&＃xff0c;只需要把自己的插件跟宿主项目一起打包运行起来&＃xff0c;而不用引入其他插件&＃xff0c;还有更厉害的是&＃xff0c;也可以把自己的插件当作一个 App 来打包并运行。

上面介绍了插件化的入门知识&＃xff0c;一共六点&＃xff0c;每一点都需要花大量时间去理解。否则&＃xff0c;在面对插件化项目的时候&＃xff0c;很多地方你会一头雾水。而只要理解了这六点核心&＃xff0c;一切可迎刃而解。

实现原理

在Android中应用插件化技术&＃xff0c;其实也就是动态加载的过程&＃xff0c;分为以下几步&＃xff1a;

• 把可执行文件&＃xff08; .so/dex/jar/apk 等&＃xff09;拷贝到应用 APP 内部。
• 加载可执行文件&＃xff0c;更换静态资源
• 调用具体的方法执行业务逻辑

Android 项目中&＃xff0c;动态加载技术按照加载的可执行文件的不同大致可以分为两种&＃xff1a;

1. 动态加载 .so 库
2. 动态加载 dex/jar/apk文件&＃xff08;现在动态加载普遍说的是这种&＃xff09;

第一点&＃xff0c; Android 中 NDK 中其实就使用了动态加载&＃xff0c;动态加载 .so 库并通过 JNI 调用其封装好的方法。后者一般是由 C/C&＃43;&＃43; 编译而成&＃xff0c;运行在 Native 层&＃xff0c;效率会比执行在虚拟机层的 Java 代码高很多&＃xff0c;所以 Android 中经常通过动态加载 .so 库来完成一些对性能比较有需求的工作&＃xff08;比如 Bitmap 的解码、图片高斯模糊处理等&＃xff09;。此外&＃xff0c;由于 .so 库是由 C/C&＃43;&＃43; 编译而来的&＃xff0c;只能被反编译成汇编代码&＃xff0c;相比中 dex 文件反编译得到的 Smali 代码更难被破解&＃xff0c;因此 .so 库也可以被用于安全领域。

其二&＃xff0c;“基于 ClassLoader 的动态加载 dex/jar/apk 文件”&＃xff0c;就是我们指在 Android 中 动态加载由 Java 代码编译而来的 dex 包并执行其中的代码逻辑&＃xff0c;这是常规 Android 开发比较少用到的一种技术&＃xff0c;目前说的动态加载指的就是这种。

Android 项目中&＃xff0c;所有 Java 代码都会被编译成 dex 文件&＃xff0c;Android 应用运行时&＃xff0c;就是通过执行 dex 文件里的业务代码逻辑来工作的。使用动态加载技术可以在 Android 应用运行时加载外部的 dex 文件&＃xff0c;而通过网络下载新的 dex 文件并替换原有的 dex 文件就可以达到不安装新 APK 文件就升级应用&＃xff08;改变代码逻辑&＃xff09;的目的。

所以说&＃xff0c;在 Android 中的 ClassLoader 机制主要用来加载 dex 文件&＃xff0c;系统提供了两个 API 可供选择&＃xff1a;

• PathClassLoader&＃xff1a;只能加载已经安装到 Android 系统中的 APK 文件。因此不符合插件化的需求&＃xff0c;不作考虑。
• DexClassLoader&＃xff1a;支持加载外部的 APK、Jar 或者 dex 文件&＃xff0c;正好符合文件化的需求&＃xff0c;所有的插件化方案都是使用 DexClassloader 来加载插件 APK 中的 .class文件的。

主流框架

在 Android 中实现插件化框架&＃xff0c;需要解决的问题主要如下&＃xff1a;

• 资源和代码的加载
• Android 生命周期的管理和组件的注册
• 宿主 APK 和插件 APK 资源引用的冲突解决

下面分析几个目前主流的开源框架&＃xff0c;看看每个框架具体实现思路和优缺点。

DL 动态加载框架 ( 2014 年底)

是基于代理的方式实现插件框架&＃xff0c;对 App 的表层做了处理&＃xff0c;通过在 Manifest 中注册代理组件&＃xff0c;当启动插件组件时&＃xff0c;首先启动一个代理组件&＃xff0c;然后通过这个代理组件来构建&＃xff0c;启动插件组件。 需要按照一定的规则来开发插件 APK&＃xff0c;插件中的组件需要实现经过改造后的 Activity、FragmentActivity、Service 等的子类。

优点如下&＃xff1a;

• 插件需要遵循一定的规则&＃xff0c;因此安全方面可控制。
• 方案简单&＃xff0c;适用于自身少量代码的插件化改造。

缺点如下&＃xff1a;

• 不支持通过 This 调用组件的方法&＃xff0c;需要通过 that 去调用。
• 由于 APK 中的 Activity 没有注册&＃xff0c;不支持隐式调用 APK 内部的 Activity。
• 插件编写和改造过程中&＃xff0c;需要考虑兼容性问题比较多&＃xff0c;联调起来会比较费时费力。

DroidPlugin ( 2015 年 8 月)

DroidPlugin 是 360 手机助手实现的一种插件化框架&＃xff0c;它可以直接运行第三方的独立 APK 文件&＃xff0c;完全不需要对 APK 进行修改或安装。一种新的插件机制&＃xff0c;一种免安装的运行机制&＃xff0c;是一个沙箱&＃xff08;但是不完全的沙箱。就是对于使用者来说&＃xff0c;并不知道他会把 apk 怎么样&＃xff09;&＃xff0c; 是模块化的基础。

实现原理&＃xff1a;

• 共享进程&＃xff1a;为android提供一个进程运行多个 apk 的机制&＃xff0c;通过 API 欺骗机制瞒过系统。
• 占坑&＃xff1a;通过预先占坑的方式实现不用在 manifest 注册&＃xff0c;通过一带多的方式实现服务管理。
• Hook 机制&＃xff1a;动态代理实现函数 hook &＃xff0c;Binder 代理绕过部分系统服务限制&＃xff0c;IO 重定向&＃xff08;先获取原始 Object –> Read &＃xff0c;然后动态代理 Hook Object 后–> Write 回去&＃xff0c;达到瞒天过海的目的&＃xff09;。

插件 Host 的程序架构&＃xff1a;

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-GHDsJK2C-1623503725286)(//upload-images.jianshu.io/upload_images/788498-e67b8e22d7284539.png?imageMogr2/auto-orient/strip|imageView2/2/w/1200/format/webp)]

优点如下&＃xff1a;

• 支持 Android 四大组件&＃xff0c;而且插件中的组件不需要在宿主 APK 中注册。
• 支持 Android 2.3 及以上系统&＃xff0c;支持所有的系统 API。
• 插件与插件之间&＃xff0c;插件与宿主之间的代码和资源完全隔阂。
• 实现了进程管理&＃xff0c;插件的空进程会被及时回收&＃xff0c;占用内存低。

缺点如下&＃xff1a;

• 插件 APK 中不支持自定义资源的 Notification&＃xff0c;通知栏限制。
• 插件 APK 中无法注册具有特殊的 IntentFilter 的四大组件。
• 缺乏对 Native 层的 Hook 操作&＃xff0c;对于某些带有 Native 代码的插件 APK 支持不友好&＃xff0c;可能无法正常运行。
• 由于插件与插件&＃xff0c;插件与宿主之间的代码完全隔离&＃xff0c;因此&＃xff0c;插件与插件&＃xff0c;插件与宿主之间的通信只能通过 Android 系统级别的通信方式。
• 安全性担忧&＃xff08;可以修改&＃xff0c;hook一些重要信息&＃xff09;。
• 机型适配&＃xff08;不是所有机器上都能行&＃xff0c;因为大量用反射相关&＃xff0c;如果rom厂商深度定制了framework层&＃xff0c;反射的方法或者类不在&＃xff0c;容易插件运用失败&＃xff09;

Small ( 2015 年底)

Small 是一种实现轻巧的跨平台插件化框架&＃xff0c;基于“轻量、透明、极小化、跨平台”的理念&＃xff0c;实现原理有以下三点。

• 动态加载类&＃xff1a;我们知道插件化很多都从 DexClassLoader 类有个 DexPathList 清单&＃xff0c;支持 dex/jar/zip/apk 文件格式&＃xff0c;却没有支持 .so 文件格式&＃xff0c;因此 Small 框架则是把 .so 文件包装成 zip 文件格式&＃xff0c;插入到 DexPathList 集合中&＃xff0c;改写动态加载的代码。
• 资源分段&＃xff1a;由于 Android 资源的格式是 0xPPTTNNNN &＃xff0c;PP 是包 ID &＃xff0c;00-02 是属于系统&＃xff0c;7f 属于应用程序&＃xff0c;03-7e 则保留&＃xff0c;可以在这个范围内做文章 &＃xff0c; TT 则是 Type 比如&＃xff0c;attr 、layout 、string 等等&＃xff0c;NNNN 则是资源全局 ID。那么这个框架则是对资源包进行重新打包&＃xff0c;每个插件重新分配资源 ID &＃xff0c;这样就保证了宿主和插件的资源不冲突。
• 动态代理注册&＃xff1a;在 Android 中要使用四大组件&＃xff0c;都是需要在 manifest 清单中注册&＃xff0c;这样才可以使用&＃xff0c;那如何在不注册情况也能使用呢&＃xff0c;这里就是用到动态代理机制进行 Hook &＃xff0c;在发送 AMS 之前用占坑的组件来欺骗系统&＃xff0c;通过认证后&＃xff0c;再把真正要调用的组件还原回来&＃xff0c;达到瞒天过海目的。

架构图&＃xff1a;

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-69ZJQlS5-1623503725288)(//upload-images.jianshu.io/upload_images/788498-3a45d1a831f1c88d.png?imageMogr2/auto-orient/strip|imageView2/2/w/362/format/webp)]

优点如下&＃xff1a;

• 所有插件支持内置宿主包中。
• 插件的编码和资源文件的使用与普通开发应用没有差别。
• 通过设定 URI &＃xff0c;宿主以及 Native 应用插件&＃xff0c;Web 插件&＃xff0c;在线网页等能够方便进行通信。
• 支持 Android 、 iOS 、和 Html5 &＃xff0c;三者可以通过同一套 Javascript 接口实现通信。

缺点如下&＃xff1a;

• 暂不支持 Service 的动态注册&＃xff0c;不过这个可以通过将 Service 预先注册在宿主的 AndroidManifest.xml 文件中进行规避&＃xff0c;因为 Service 的更新频率通常非常低。

与其他主流框架的区别&＃xff1a;

DyLA : Dynamic-load-apk &＃64;singwhatiwanna
DiLA : Direct-Load-apk &＃64;FinalLody
APF : Android-Plugin-Framework &＃64;limpoxe
ACDD : ACDD &＃64;bunnyblue
DyAPK : DynamicAPK &＃64;TediWang
DPG : DroidPlugin &＃64;cmzy, 360

• 功能

• 透明度

VirtualAPK (2017年 6 月 )

VirtualAPK 是滴滴开源的一套插件化框架&＃xff0c;支持几乎所有的 Android 特性&＃xff0c;四大组件方面。

架构图&＃xff1a;

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-Fp2xPexA-1623503725291)(//upload-images.jianshu.io/upload_images/788498-28c14d5a5a46ee92.jpg?imageMogr2/auto-orient/strip|imageView2/2/w/1200/format/webp)]

实现思路&＃xff1a;

VirtualAPK 对插件没有额外的约束&＃xff0c;原生的 apk 即可作为插件。插件工程编译生成 apk后&＃xff0c;即可通过宿主 App 加载&＃xff0c;每个插件 apk 被加载后&＃xff0c;都会在宿主中创建一个单独的 LoadedPlugin 对象。如下图所示&＃xff0c;通过这些 LoadedPlugin 对象&＃xff0c;VirtualAPK 就可以管理插件并赋予插件新的意义&＃xff0c;使其可以像手机中安装过的 App 一样运行。

• 合并宿主和插件的ClassLoader 需要注意的是&＃xff0c;插件中的类不可以和宿主重复
• 合并插件和宿主的资源 重设插件资源的 packageId&＃xff0c;将插件资源和宿主资源合并
• 去除插件包对宿主的引用 构建时通过 Gradle 插件去除插件对宿主的代码以及资源的引用

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-xJTuLbpU-1623503725292)(//upload-images.jianshu.io/upload_images/788498-1ff72c634d70c986.png?imageMogr2/auto-orient/strip|imageView2/2/w/1132/format/webp)]

特性如下&＃xff1a;

四大组件均不需要在宿主manifest中预注册&＃xff0c;每个组件都有完整的生命周期。

1. Activity&＃xff1a;支持显示和隐式调用&＃xff0c;支持Activity的theme和LaunchMode&＃xff0c;支持透明主题&＃xff1b;
2. Service&＃xff1a;支持显示和隐式调用&＃xff0c;支持Service的start、stop、bind和unbind&＃xff0c;并支持跨进程bind插件中的Service&＃xff1b;
3. Receiver&＃xff1a;支持静态注册和动态注册的Receiver&＃xff1b;
4. ContentProvider&＃xff1a;支持provider的所有操作&＃xff0c;包括CRUD和call方法等&＃xff0c;支持跨进程访问插件中的Provider。

• 自定义View&＃xff1a;支持自定义 View&＃xff0c;支持自定义属性和style&＃xff0c;支持动画&＃xff1b;
• PendingIntent&＃xff1a;支持PendingIntent以及和其相关的Alarm、Notification和AppWidget&＃xff1b;
• 支持插件Application以及插件manifest中的meta-data&＃xff1b;
• 支持插件中的so。

优秀的兼容性

• 兼容市面上几乎所有的Android手机&＃xff0c;这一点已经在滴滴出行客户端中得到验证。
• 资源方面适配小米、Vivo、Nubia 等&＃xff0c;对未知机型采用自适应适配方案。
• 极少的 Binder Hook&＃xff0c;目前仅仅 hook了两个Binder&＃xff1a;AMS和IContentProvider&＃xff0c;hook 过程做了充分的兼容性适配。
• 插件运行逻辑和宿主隔离&＃xff0c;确保框架的任何问题都不会影响宿主的正常运行。

入侵性极低

• 插件开发等同于原生开发&＃xff0c;四大组件无需继承特定的基类&＃xff1b;
• 精简的插件包&＃xff0c;插件可以依赖宿主中的代码和资源&＃xff0c;也可以不依赖&＃xff1b;
• 插件的构建过程简单&＃xff0c;通过 Gradle 插件来完成插件的构建&＃xff0c;整个过程对开发者透明。

如下是 VirtualAPK 和主流的插件化框架之间的对比。

RePlugin (2017 年 7 月)

RePlugin是一套完整的、稳定的、适合全面使用的&＃xff0c;占坑类插件化方案&＃xff0c;由360手机卫士的RePlugin Team研发&＃xff0c;也是业内首个提出”全面插件化“&＃xff08;全面特性、全面兼容、全面使用&＃xff09;的方案。

框架图&＃xff1a;

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-vZVQ9NhE-1623503725294)(//upload-images.jianshu.io/upload_images/788498-e06beeff5e362d17.jpeg?imageMogr2/auto-orient/strip|imageView2/2/w/1024/format/webp)]

主要优势有&＃xff1a;
极其灵活&＃xff1a;主程序无需升级&＃xff08;无需在Manifest中预埋组件&＃xff09;&＃xff0c;即可支持新增的四大组件&＃xff0c;甚至全新的插件
非常稳定&＃xff1a;Hook 点仅有一处&＃xff08;ClassLoader&＃xff09;&＃xff0c;无任何 Binder Hook&＃xff01;如此可做到其崩溃率仅为“万分之一”&＃xff0c;并完美兼容市面上近乎所有的 Android ROM。
特性丰富&＃xff1a;支持近乎所有在“单品”开发时的特性。包括静态 Receiver、 Task-Affinity 坑位、自定义 Theme、进程坑位、AppCompat、DataBinding等。
易于集成&＃xff1a;无论插件还是主程序&＃xff0c;只需“数行”就能完成接入。
管理成熟&＃xff1a;拥有成熟稳定的“插件管理方案”&＃xff0c;支持插件安装、升级、卸载、版本管理&＃xff0c;甚至包括进程通讯、协议版本、安全校验等。
数亿支撑&＃xff1a;有 360 手机卫士庞大的数亿用户做支撑&＃xff0c;三年多的残酷验证&＃xff0c;确保App用到的方案是最稳定、最适合使用的。

实战

主要是测试各个框架之间上手的容易度如何&＃xff0c;并做不同对比&＃xff0c;这边写了两个 Demo 例子&＃xff0c;一个是基于 Small 框架&＃xff0c;一个基于 VirtualAPK 框架&＃xff0c;从中能看出不同。

Small 实践

要引用官方最新的版本&＃xff0c;不然在宿主和插件合并build.gradle 的时候会出现一个 BUG&＃xff0c;这是个坑位&＃xff0c;注意行走。其次在模块命名上要遵循一定的规则&＃xff0c;比如业务模块用 app.* &＃xff0c;公共库模块用 lib.* &＃xff0c;相当于包名 .app.&＃xff0c;.lib. 。每次在插件中添加一个 activity 组件&＃xff0c;都需要在宿主中配置路由&＃xff0c;然后在重新编译插件一遍&＃xff0c;不然直接运行的话&＃xff0c;在宿主中是找到新添加的 activity 组件&＃xff0c;会报该组件没在系统 manifest 中&＃xff0c;所以每次新增或修改建议插件都重新编译一遍。官方里说了&＃xff0c;对于 Service 支持不太友好&＃xff0c;就没去实践了。

VirtualAPK 实践
有个坑需要注意的是构建环境&＃xff0c;官方说明是要以下版本环境&＃xff0c;Gradle 2.14.1 和 com.android.tools.build 2.1.3&＃xff0c; 之前编译的是用最新的Gradle版本&＃xff0c;导致一直有问题&＃xff0c;至于是否有其他问题&＃xff0c;可以看官方文档。

具体代码
Small Demo &＃xff1a;https://github.com/cr330326/MySmall

VirtualAPK Demo &＃xff1a;https://github.com/cr330326/MyVirtualAPKDemo

小结

文末

那么对于想坚持程序员这行的真的就一点希望都没有吗&＃xff1f;
其实不然&＃xff0c;在互联网的大浪淘沙之下&＃xff0c;留下的永远是最优秀的&＃xff0c;我们考虑的不是哪个行业差哪个行业难&＃xff0c;就逃避掉这些&＃xff0c;无论哪个行业&＃xff0c;都会有他的问题&＃xff0c;但是无论哪个行业都会有站在最顶端的那群人。我们要做的就是努力提升自己&＃xff0c;让自己站在最顶端&＃xff0c;学历不够那就去读&＃xff0c;知识不够那就去学。人之所以为人&＃xff0c;不就是有解决问题的能力吗&＃xff1f;挡住自己的由于只有自己。点击我的GitHub下述资料免费领取
Android希望&＃61;技能&＃43;面试

• 技能
  

• 面试技巧&＃43;面试题
  tps://github.com/a120464/Android-P7/blob/master/Android%E5%BC%80%E5%8F%91%E4%B8%8D%E4%BC%9A%E8%BF%99%E4%BA%9B%EF%BC%9F%E5%A6%82%E4%BD%95%E9%9D%A2%E8%AF%95%E6%8B%BF%E9%AB%98%E8%96%AA%EF%BC%81.md)**
  Android希望&＃61;技能&＃43;面试

• 技能
  [外链图片转存中…(img-iJJ2Xrq9-1623503725295)]

• 面试技巧&＃43;面试题