全网独家盘点安卓热修复方案（含大厂）

安卓热修复是 App 线上救火的核心能力。按“是否必须重启”可先分两类：一类要冷启动（重启 App）才生效，一类能即时生效不重启。按“实现方式”又能分三类：改 native 层方法入口、编译期插桩加开关、类加载替换 dex。下面挨个说清各厂方案长啥样、咋运作、啥短板。

腾讯 Shiply（RFix）多引擎融合热修复方案

Shiply 是腾讯端服务（Tencent Device-oriented Service，简称 TDS）产品联盟的核心成员，为 App 提供一站式的动态发布解决方案，具备多方案融合、端云一体、接入门槛低的特点，旨在降低研发成本并助力业务快速搭建稳定高质量的移动应用 。其热修复 SDK（RFix）采用多方案融合的混合引擎（Tinker + Redirect），支持 dex、res、so 修复（AndroidManifest.xml、RemoteView 等系统管理资源除外），属于“需重启的类加载与插桩混合实现类” 。

从原理看，Tinker 引擎本质是 Android 类加载机制应用与优化，支持 Dex、So 库及资源替换并提供回滚能力；Redirect 引擎为函数插桩方案，通过 DexDiff（公开的差量分析算法，用于比对前后 dex 差异并提取变更）自动提取修复代码，规避编译期内联优化导致的注解失效问题，将插桩修改限制控制在极小范围内 。

使用方法：通过 @ApplicationProxy 注解生成代理 Application，在 attachBaseContext 初始化 RFixInitializer，执行 ./gradlew RFixBuildRelease 产出 patch.apk；补丁安装后冷启动（重启 App）生效，须与原 App 签名一致 。该方案已为公司内 30+ APP 提供支撑，覆盖峰值设备数超 10 亿/天，补丁加载成功率 99.9%+ 。

缺陷说明：混合引擎依赖冷启动生效，无法像 native 方案那样即时修复；DexDiff 与插桩对构建链路有侵入，系统管理资源不在修复范围内 。

阿里巴巴 AndFix（已弃用）原生方法替换方案

注：按“弃用也讲”的框架，将已停止维护的大厂方案置于竞品前作为引子，便于建立认知铺垫。

AndFix 是早期最有代表性的 native 层即时生效方案，目前已停止维护，但作为热修复演进的源头仍值得了解 。它属于“无需重启的 native 层实现，已弃用”。

从原理看，Android 跑在 Art 虚拟机，每个 Java 方法对应一个 ArtMethod 结构体，里面存着方法入口地址、所属类、签名等元数据。AndFix 的套路是，直接把要修复方法的 ArtMethod 入口地址，改成新方法的入口地址，相当于把门牌号指到新房间，不重新加载类，调用原方法时就跑新代码 。

使用方法上，AndFix 通过注解（公开技术资料称其为 @MethodReplace，用于标记需替换的方法和类）标记目标，在 native 层用 C 代码替换 ArtMethod 指针，补丁包下发后即时生效，无需重启 。

缺陷说明：它极度依赖虚拟机内部实现，每个 Android 系统版本的 ArtMethod 结构可能不同，适配成本极高；一旦系统更新改了底层结构，补丁机制直接失效，修复粒度也仅限于方法级替换 。

美团 Robust 编译期插桩即时生效方案

Robust 是美团推出的即时生效 java 层方案，归属“无需重启的插桩实现类” 。它的设计思想借鉴了给每个方法装“开关”的思路。

设计思想上，Robust 在编译阶段对每个方法自动插入判断逻辑：检查是否存在对应“补丁方法”，有则执行补丁、无则走原逻辑，相当于给每个函数加了个实时分流阀 。

从生效原理看，补丁包下发后，下次调用原方法时，插桩逻辑先查补丁表，命中则跳到新代码执行，因此无需重启即可让新逻辑生效 。这种机制让修复动作对运行时干扰极小，因为所有修改都在编译期完成，运行期只是做一次轻量判断。

实现手段上，Robust 采用字节码插桩技术，在编译期通过自定义 Transform 修改字节码，把判断逻辑织入每个方法，不依赖运行时类加载替换，稳定性高 。缺点是会增加包体积和方法数，修复为“覆盖”而非“替换”，在复杂继承场景下需要特别注意补丁方法的上下文一致性，避免出现父类子类逻辑错配。

腾讯 Tinker 与 QQ 空间超级补丁重启生效方案群

下面并列说两个重启生效的 java 层方案，均依赖类加载顺序完成替换。

腾讯 Tinker 差分包合成方案

Tinker 采用“全量合成”思路，归属“需重启的类加载替换类” 。从原理看，它把修复后的类打包成 patch.dex，App 冷启动时通过反射把 patch.dex 插入 ClassLoader 的 dexElements 数组最前面，依据双亲委托机制优先加载修复类，覆盖旧类 。

差分包算法上，Tinker 使用 DexDiff（公开的差量比对算法，仅提取前后 dex 的变更部分）生成极小补丁，并在合成阶段做 dex 压缩与校验优化，降低下发体积与合成耗时，使冷启动替换既能细粒度修复又不明显拖慢启动 。

QQ 空间超级补丁类加载顺序替换方案

QQ 空间超级补丁同样基于类加载顺序，原理与 Tinker 同属“冷启动补丁”路线 。从原理看，它把补丁 dex 插入 dexElements 头部，利用已加载类不被重新加载的限制，在下次启动时优先命中补丁类完成替换 。该方案不赘述合成细节，核心在于缓存顺序替换，兼容性好但同样需用户重启 App 才生效 。

安卓热修复方案对比一览

从对比看：Shiply/RFix（混合引擎、重启生效）、AndFix（native 即时、已弃用）、Robust（插桩即时、java 层）、Tinker（类加载重启、差分包）、QQ 空间超级补丁（类加载重启、顺序替换）。按生效方式分即时与重启，按实现层分 native 与 java，按特点可分方法级替换、全量合成、插桩覆盖，速查即可对应前面各方案归属。