Android 热修复原理是什么？主流方案怎么选？

Android 热修复的本质是在不发新版 APK 的情况下，让应用优先执行修复后的代码。常见路线有三类：类加载方案把补丁 dex 插到 dexElements 前面，重启后优先生效；底层替换方案改 ArtMethod 入口，可即时生效但兼容性压力大；插桩方案在编译期埋跳转逻辑，运行时分发到补丁实现。

追问

Tinker 为什么通常需要重启？

Tinker 走类加载和差分合成路线，把补丁 dex、资源或 so 合并后，在下次启动时让 ClassLoader 加载新内容。它稳定、覆盖面广，但不能保证所有改动立即生效。

Sophix、AndFix 这类方案为什么兼容性难？

它们涉及 ART 虚拟机内部结构，比如方法入口、ArtMethod 布局。不同 Android 版本和厂商 ROM 实现差异大，越底层越容易踩兼容坑。

热修复不能修什么？

通常不适合修 Manifest 变更、新增四大组件、资源 ID 大变动、启动早期就崩的代码。补丁也要做签名校验、版本校验和灰度发布，否则有安全风险。

线上怎么选方案？

如果追求稳定和覆盖范围，选 Tinker 类方案；如果业务强依赖即时修复，才考虑商业方案或插桩方案。无论哪种，都要有回滚、灰度和补丁监控。

写段代码

java
// 关键思路：patchElements 放到原 dexElements 前面
Object[] combined = concat(patchElements, dexElements);
setField(pathList, "dexElements", combined);