1.1.1 热修复
1.方案介绍
为了解决Native模块上线后的问题，mPaas提供了热修复功能，实现不发布客户端apk场景下的热修复。目前Android端热修复主要包括andfix和dexpatch，考虑到andfix的版本兼容性，目前主要推荐使用DexPatch。
DexPatch修复原理比较简单，如图1-1所示，在启动后通过RPC拉取当前需要下发的jar包地址，然后通过独立进程去下载jar包文件，下载完成后保存。在二次启动的时候hook系统的classLoader，修改DexPathList, 在其数组的最前面加入一个有修改过的class的dex文件，使其拦截住数组后面的dex文件中同名的class的加载。如下图所示，classloader就会优先加载Patch.dex中的Ding.class，而忽略Classes.dex中的Ding.class, 达到了替换的效果。
图1‑1 热修复原理介绍图
基于这样的原理，DexPatch具有以下特征：
（1）支持范围上：是基于类级别的替换，所以只支持Java模块的patch，不支持非Java模块的patch，比如so模块。
（2）兼容性上：由于是代理了系统的ClassLoader，使用的黑科技较少，所以整体方案兼容性较好。
（3）生效时效性上：只能在下载patch后重启后才能生效，不支持实时生效。
（4）成功率上：由于下载是使用的独立进程，减少了启动阶段主进程闪退对patch下载的影响，提升了下载的成功比例
2.使用介绍
以经常使用的Android热修复为例，以下介绍下在mPaas下使用DexPatch模块的主要步骤以及问题排查思路，方便开发者日常开发和问题排查。
1）触发patch拉取
如图1-2所示，启动阶段调用MPHotpatch.init(), 主要触发Patch信息的RPC请求，如果命中发布Patch发布规则，RPC会返回Patch的jar包下载地址，客户端去触发下载，下载后保存在客户端私有目录/data/user/0/包名/dexpatch/patch/下。
图1‑2 热修复拉取
2）代码操作演示
以组件化模式接入为例，介绍下Patch发布的主要流程。
（1）代码改动前，如图1-3所示
图1‑3 改动前
需要保存改动前的构建产物，方便后续做Patch生成，地址在：build/intermediates/bundle/xxxx-raw.jar
（2）代码改动后，如图1-4所示
图1‑4 改动后
重新编译，保存构建产物，产物地址：build/intermediates/bundle/xxxx-raw.jar
3）生成白名单配置
主要用于热修复包时用于指定修复的类，配置文件为 .txt 格式，如图1-5所示，该配置文件应包含并按顺序包含以下信息：
需要 Patch 的类。以 L 开头，后跟以混淆后真实类名。如果多个类，每行只可写一个。示例：Lxxx.xxx.clazzX 设置 Patch 类型。为 dexpatch。示例：PatchType: dexpatch
设置是否是静态 Bundle。默认为 false，如果是静态链接的 Bundle，需要显式设置为 true。示例：HostDex: true。目前mPaas客户端的模块一般都在静态链接里，一般写true。
图1‑5 白名单配置
4）查看签名
生成patch需要用到项目的打包秘钥，需要提前准备好，可以在打包脚步下找到对应的配置，如图1-6所示。
图1‑6 签名配置
5）生成patch
(1) 通过mPaas自带的ide工具，点击热修复，进入修复页面，如图1-7所示。
图1‑7 生成patch
(2) 按照页面提示，填入之前准备的修复前和修复后的jar包地址，还有白名单配置文件，勾选dexPatch，进入到下一步，如图1-8所示。
图1‑8 选择patch文件
(3) 下一步主要选择打包的配置文件，最近点击完成生成patch文件，如图1-9所示。
图1‑9 选择patch签名
6）生成patch产物
生成patch产物如图1-10所示。
图1‑10 生成patch产物
查看产物，可以使用dex2jar工具反解diff.dex文件，用jd-gui文件查看反解产物是否符合预期，如图1-11所示。
图1‑11 查看patch产物
反解后可以看到修改的模块，如图1-12所示。
图1‑12 反解patch产物
7）上传发布
（1）选择上一步的产物jar包进行上传
图1‑13 patch上传
（2）上传后可以通过白名单进行发布，验证patch的稳定性，如图1-14所示。
图1‑14 patch灰度
8）验证下载
白名单发布后，启动客户端，搜索关键字：DynamicRelease，可以看到在tool进程有触发下载的日志打出。这里需要说明的是，这里触发patch的下载是在tool进程，不在主进程。这样设计的主要原因是怕由于主进程由于启动导致重复闪退，导致patch不能下载成功，单独在tool进程实现下载，尽量提高patch的下载成功比例。然后去下载目录查看，是否下载保存成功，下载目录在:/data/user/0/包名/dexpatch/patch/下。
9）杀进程启动
确认下载保存成功后，杀掉App，重启查看是否生效，重启搜索DexPatchManager，查看patch生效的日志，日志会打印当前是否存在patch以及patch是否加载的日志。
同时我们也可以就实际业务场景进行验证，查看是否生效。如图1-15所示，表示patch已经生效。
图1‑15 patch生效
3 常见问题
1）aar模式集成后patch没生效
aar模式集成的时候，Application需要继承框架的QuinoxlessApplication，指定当前App的Application为框架的实现类才能实现dexpatch的加载。因为QuinoxlessApplication内主要封装了dexpatch模块的初始化和加载，如果没有继承，会导致初始化失败。
2）使用加固后不生效
需要使用加固前的apk生成patch，不能用加固后的包生成patch。因为不同的厂商加固策略不同，还需要在发布前验证在不同加固厂商下的兼容表现。
3) 使用热修复后，RPC有关的调用发生apache http相关crash
在使用patch后，有些项目会遇到 rpcService获取为空。主要由于 apache http client的引入方式不对。需要使用 Android 官网上的方式引入 apache http client，禁止直接使用导入 jar包或者gradle implementation/compile 的方式导入 http client，否则会引起 classloader 加载类混乱。
建议方式：
<uses-library android:name="org.apache.http.legacy" android:required="false"/>
