共计 2544 个字符，预计需要花费 7 分钟才能阅读完成。
简介： 对于 Android 热修复计划——DexPatch 的介绍与应用阐明
计划介绍
为了解决 Native 模块上线后的问题，mPaaS 提供了热修复性能，实现不公布客户端 apk 场景下的热修复。目前 Android 端热修复次要包含 andfix 和 dexpatch，思考到 andfix 的版本兼容性，目前次要举荐应用 DexPatch。
DexPatch 修复原理比较简单，就是在启动后通过 RPC 拉取以后须要下发的 jar 包地址，而后通过独立过程去下载 jar 包文件，下载实现后保留。在二次启动的时候 hook 零碎的 classLoader，批改 DexPathList，在其数组的最后面退出一个有批改过的 class 的 dex 文件，使其拦挡住数组前面的 dex 文件中同名的 class 的加载。
如下图所示，classloader 就会优先加载 Patch.dex 中的 Ding.class，而疏忽 Classes.dex 中的 Ding.class，达到了替换的成果。
基于这样的原理，DexPatch 具备以下特色：
- 反对范畴上：是基于类级别的替换，所以只反对 Java 模块的 patch，不反对非 Java 模块的 patch，比方 so 模块；
- 兼容性上：因为是代理了零碎的 ClassLoader，应用的黑科技较少，所以整体计划兼容性较好；
- 失效时效性上：只能在下载 patch 后重启后能力失效，不反对实时失效；
- 成功率上：因为下载是应用的独立过程，缩小了启动阶段主过程闪退对 patch 下载的影响，晋升了下载的胜利比例。
操作阐明
以下是对于在 mPaaS 下应用 DexPatch 模块的次要步骤以及问题排查思路，不便开发者日常开发。
- 触发 patch 拉取
===============
启动阶段调用 MPHotpatch.init()，次要触发 Patch 信息的 RPC 申请，如果命中公布 Patch 公布规定，RPC 会返回 Patch 的 jar 包下载地址，客户端去触发下载，下载后保留在客户端公有目录 /data/user/0/ 包名 /dexpatch/patch/ 下。
- 代码操作演示
==========
以组件化模式接入为例，介绍下 Patch 公布的次要流程。
（1）代码改变前
须要保留改变前的构建产物，不便后续做 Patch 生成，地址在：build/intermediates/bundle/xxxx-raw.jar
（2）代码改变后
从新编译，保留构建产物，产物地址：build/intermediates/bundle/xxxx-raw.jar
（3）生成白名单配置
次要用于热修复包时用于指定修复的类，配置文件为 .txt 格局，该配置文件应蕴含并按程序蕴含以下信息：
须要 Patch 的类。以 L 结尾，后跟以混同后实在类名。如果多个类，每行只可写一个。示例：Lxxx.xxx.clazzX 设置 Patch 类型为 dexpatch。示例：PatchType: dexpatch
设置是否是动态 Bundle。默认为 false，如果是动态链接的 Bundle，须要显式设置为 true。示例：HostDex: true（* 目前 mPaaS 客户端的模块个别都在动态链接里，个别写 true）
（4）查看签名
生成 patch 须要用到我的项目的打包秘钥，须要提前准备好，能够在打包脚步下找到对应的配置
（5）生成 patch
① 通过 mPaaS 自带的 IDE 工具，点击热修复，进入修复页面。
② 依照页面提醒，填入之前筹备的修复前和修复后的 jar 包地址，还有白名单配置文件，勾选 dexPatch，进入到下一步
③ 下一步次要抉择打包的配置文件，最近点击实现生成 patch 文件
（6）生成 patch 产物
生成 patch 产物如下：
查看产物，能够应用 dex2jar 工具反解 diff.dex 文件，用 jd-gui 文件查看反解产物是否合乎预期
反解后能够看到批改的模块：
（7）上传公布
① 抉择上一步的产物 jar 包进行上传
② 上传后能够通过白名单进行公布，验证 patch 的稳定性
（8）验证下载
白名单公布后，启动客户端，搜寻关键字：DynamicRelease，能够看到在 tool 过程有触发下载的日志打出。
这里须要阐明的是，这里触发 patch 的下载是在 tool 过程，不在主过程的次要起因是怕因为主过程因为启动导致反复闪退，导致 patch 不能下载胜利，独自在 tool 过程实现下载，尽量进步 patch 的下载胜利比例。
而后去下载目录查看，是否下载保留胜利，下载目录在：/data/user/0/ 包名 /dexpatch/patch/20201023110012@20201023110012.jar
（9）杀过程启动
确认下载保留胜利后，杀掉 App，重启查看是否失效，重启能够搜寻关键字：DexPatchManager，查看 patch 失效的日志，日志会打印以后是否存在 patch 以及 patch 是否加载的日志。
同时咱们也能够就理论业务场景进行验证，查看是否失效。
常见问题
- aar 模式集成后 patch 没失效
=======================
aar 模式集成的时候，须要继承框架的 QuinoxlessApplication，指定 Application 为框架的实现类能力实现 dexpatch 的加载。QuinoxlessApplication 内次要封装了 dexpatch 模块的初始化和加载。
- 应用加固后不失效
============
须要应用加固前的 apk 生成 patch，不能用加固后的包生成 patch。而后还须要验证在不同加固厂商下的兼容体现。
- 应用热修复后，和 RPC 无关的调用产生 apache http 相干的 crash。
===============================================
请应用 Android 官网上的形式引入 apache http client，禁止应用导入 jar 包或者 gradle implementation/compile 的形式导入 http client。否则会引起 classloader 加载类凌乱。
倡议形式：
<uses-library android:name=”org.apache.http.legacy” android:required=”false”/>
E · N · D
作者：荣阳
原文链接![上传失败，undefined]()
本文为阿里云原创内容，未经容许不得转载
