25、Android热修复与插件化：类加载机制、资源加载、热修复框架原理（Tinker/Replugin）

热修复和插件化，这两个词在Android圈子里火了很久了。说白了，它们都跟「动态」两个字有关——动态修复bug，动态加载模块。我最早接触热修复是在2016年，那时候公司线上出了个空指针崩溃，发版要等一周，老板急得直拍桌子。从那以后，我就开始深入研究这块了。

今天咱们把这两个技术拆开揉碎了讲。核心就三块：类加载机制、资源加载、主流框架原理。你想想看，搞懂了这些，你也能自己写个热修复框架。

一、类加载机制：热修复的基石

Android的类加载器，核心就两个：PathClassLoader 和 DexClassLoader。前者加载已安装的apk，后者可以加载外部的dex/jar文件。

热修复的原理，说白了就是「偷梁换柱」。我们把修复好的类打包成dex，插到类加载器的加载路径最前面。因为ClassLoader是双亲委托机制，但查找时是从数组头部开始遍历的——先找到的类优先使用。

我给你们看一段关键代码，这是Tinker的核心逻辑简化版：

// 反射获取PathClassLoader中的DexPathList
PathClassLoader classLoader = (PathClassLoader) getClassLoader();
Field pathListField = ClassLoader.class.getDeclaredField("pathList");
pathListField.setAccessible(true);
Object pathList = pathListField.get(classLoader);

// 获取dexElements数组
Field dexElementsField = pathList.getClass().getDeclaredField("dexElements");
dexElementsField.setAccessible(true);
Object[] oldElements = (Object[]) dexElementsField.get(pathList);

// 创建新的dexElements，把补丁dex放最前面
Object[] newElements = combineArray(patchElements, oldElements);
dexElementsField.set(pathList, newElements);

这段代码我当年手写过不下十遍。嗯，这里要注意：反射获取的字段名在不同Android版本上可能不一样。比如Android 8.0之后，DexPathList内部结构就变了，你得适配。

二、资源加载：比类加载更麻烦

类加载搞定了，资源加载才是真正的硬骨头。为什么？因为资源有ID，而且这些ID是在编译期生成的。你新加的资源，ID跟原来的可能冲突。

资源热修复的主流方案有两种：

• 方案一：合并资源包——把补丁资源合并到原资源包里，替换Resources对象
• 方案二：创建新的AssetManager——通过反射创建新的AssetManager，加载补丁资源包

我个人的习惯是偏向方案二。为什么呢？因为方案一容易引发资源ID冲突，而且合并过程很耗时。方案二虽然也有坑，但可控性更强。

来看一段Tinker资源加载的核心逻辑：

// 创建新的AssetManager
AssetManager newAssetManager = AssetManager.class.newInstance();

// 反射调用addAssetPath方法
Method addAssetPath = AssetManager.class.getDeclaredMethod("addAssetPath", String.class);
addAssetPath.setAccessible(true);

// 先添加补丁资源包
addAssetPath.invoke(newAssetManager, patchResourcePath);
// 再添加原资源包
addAssetPath.invoke(newAssetManager, originalResourcePath);

// 替换Resources中的AssetManager
Field assetManagerField = Resources.class.getDeclaredField("mAssets");
assetManagerField.setAccessible(true);
assetManagerField.set(resources, newAssetManager);

三、主流框架原理：Tinker vs Replugin

现在市面上主流的热修复框架，Tinker和Replugin是绕不开的两个。它们走的是完全不同的技术路线。

对比维度	Tinker	Replugin
技术路线	Dex差分 + 类加载替换	插件化 + 动态加载
修复粒度	方法级别	组件级别
资源修复	支持（全量替换）	支持（插件独立资源）
四大组件	不支持动态注册	支持动态注册
性能影响	启动时合成dex，略慢	运行时按需加载，影响小

Tinker 的核心思路是「差分合成」。你修复了一个方法，Tinker会生成一个很小的差分包（patch.dex），然后在手机端合成新的dex。这样做的好处是补丁包很小，但坏处是合成过程比较耗时，而且需要重启App才能生效。

Replugin 走的是「插件化」路线。它把每个模块都当成一个独立的插件apk，通过自定义的ClassLoader和资源加载器来动态加载。这样做的好处是支持四大组件，而且不用重启。但坏处是插件和宿主之间的通信比较复杂。

我给你们画一张图，看看这两个框架的核心流程：

四、实战中的选择建议

说了这么多理论，到底该选哪个？我个人的经验是这样的：

• 如果你只是要修复线上bug，选Tinker。它轻量、稳定，补丁包小到可以忽略不计。我之前的项目就是用的Tinker，线上出问题后，半小时就能出补丁包。
• 如果你要做模块化、动态加载，选Replugin。它支持四大组件，可以做插件市场。但代价是学习成本高，而且插件和宿主的通信需要设计好。

最后说一句：热修复和插件化不是银弹。它们能解决动态更新的问题，但也带来了额外的复杂性和风险。我的建议是——能用常规发版解决的，就别上热修复。毕竟，少一个框架就少一个坑。

---

公众号:蓝海资料掘金营，微信deep3321