本文整理自享学团队直播课《热修复（四）：Android N 混编问题》。 前一篇把「类替换」这条链用反射实现了一遍：补丁 dex 转成一组 Element，插到 PathClassLoader 内部 DexPathList 的 dexElements 数组最前面，类加载按顺序先命中补丁，旧类被顶掉。这套做法在 Android 6.0 上跑通了。但到了 Android 7.0，它可能整个失效：不是代

本文整理自享学团队直播课《热修复（三）：反射实现运行期热修复》。 上一篇把「类替换」这条链的原理走完了：补丁 dex 用反射转成一组 Element，插到 PathClassLoader 内部 DexPathList 维护的 dexElements 数组最前面，类加载按顺序先命中补丁，旧类被顶掉。这一篇不再讲原理，而是亲手用反射写出来HotFix.installPatch 并进行应用测试。 整个

本文整理自享学团队直播课《热修复（二）：dex 补丁热修复原理》。 上一篇我们把这四种主流的方案（QZone、Tinker、AndFix、Robust）的原理讲了一遍。那一篇的核心差异记住这一个就可以了：AndFix 走方法替换（native 层改 ArtMethod），Robust 走字节码插桩，QZone 和 Tinker 走类替换。 类加载方案的核心动作只有一件事： 把补丁 dex 用反射转

本文整理自享学团队直播课《热修复（一）：常用热修复解决方案》。 一、为什么一定要有热修复 线上版本出了逻辑错误，或者直接导致崩溃的 bug，传统做法是重新打包发布一个新版本。这条路的成本并不在打包本身，而在用户什么时候愿意升级。 微信是国内升级率最高的应用之一。可即便是它，一个新版本也要 10 天以上才能覆盖到 50% 的用户。剩下的用户在干嘛？在等，等你下个版本强制更新，或者干脆一直用老版本。你