线上这周已经崩了三次客户在群里拍桌子你最想干的事是什么大部分人第一反应是赶紧把出问题的代码修掉最好能立刻生效。这就是“热修复”这门技术存在的意义——在不下发完整新版本的情况下让已经在线上跑着的程序把出问题的代码替换成修好的版本。移动端、后端服务、前端页面现在都有人在用不同形态的热修复但真正能把原理讲清楚、把坑踩明白的人并不多。今天想跟大家把这个话题聊透热修复到底修的是什么、主流方案各自怎么选、我在Android和后端 Java 上是怎么实际落地并且救过火的、以及那些文档里不会写的坑。适合移动端开发、后端开发、以及负责线上稳定性的一线工程师做技术参考。1. 先把热修复的适用边界划清楚1.1 热修复到底在解决什么问题热修复的核心场景只有一个线上已经发布的程序出现了紧急问题传统发版流程又来不及。移动端尤其典型用户不升级应用是常态新版本发出去两周线上可能还有一半用户跑的是旧包。而应用商店审核、灰度发布、渠道包分发这些环节全部走完少则一两天多则一两周。碰上支付崩溃、核心流程卡死这种P0故障根本等不起。后端的处境其实也没好到哪儿去。Java服务虽然可以重新发布但发布意味着重启意味着连接断开、缓存失效、请求超时。大型微服务体系里为改一行空指针判断去重启一个核心服务代价非常昂贵。所以热修复的本质是让代码在进程不重启、应用不发版的前提下从旧逻辑切换到新逻辑。这里要注意热修复不等于功能开关也不等于动态配置。改个文案、换个接口地址用配置中心和开关就行不需要动用热修复。真正需要热修复的是那些已经写死在代码里的逻辑——判空方式、排序规则、加密算法、业务分支——这些只能用新的代码把旧的代码顶掉。1.2 哪些场景适合、哪些真的不要碰我见过不少团队把热修复当成万能药什么改动都想往里塞结果捅出更大的篓子。根据我自己的经验适合热修复的场景大概这么几类线上崩溃、闪退且根因明确改动范围小。核心业务逻辑出错等待发版会造成巨额损失。安全问题需要紧急封堵比如某个校验逻辑被绕过。纯代码逻辑修复不涉及数据库结构变更。不适合热修复的场景同样要摆在明面上重大架构调整比如把整个网络层换成协程这种改动不可能靠热修完成。数据库表结构变动数据迁移必须伴随发版和备份策略。协议不兼容升级服务端和客户端同时改契约热修只改一端会造成联调混乱。涉及合规和资质的改动该走审核的必须走完整流程。判断标准很简单热修复只适合修逻辑不适合动结构。你在评估需求的时候不妨先问自己三个问题这次改动能不能用一句“把某段逻辑替换掉”来描述改完之后如果效果不对能不能一秒回滚这个改动涉及的数据是否已经存在并需要迁移三问过后答案仍然清晰才适合走热修复。2. 主流热修复方案全景不同技术栈该选哪种2.1 Android端的三种流派对比Android端的热修复方案市面上的主流技术本质上是三套思路类加载方案、底层替换方案、字节码插桩方案。类加载方案的代表是腾讯的Tinker。它的原理是让App在下次启动时用一个新的dex文件整体替换掉旧的dex文件。因为是基于ClassLoader的dexElements数组替换所以支持代码和资源热更改动能力最强。代价是补丁需要合成一个新的完整dex生成的补丁包体积偏大而且必须冷启动后才能生效。底层替换方案的代表是早期的AndFix原理是在Native层直接修改ArtMethod的入口指针让方法调用跳转到新实现。好处是即时生效不用重启App。坏处是兼容性极差Android各个版本的虚拟机内部结构不同几乎是出一版系统就要适配一次现在基本已经退出主流选择。字节码插桩方案的代表是美团的Robust。它在编译期对每个方法都注入了补丁逻辑运行时会检查是否存在对应的补丁有则执行补丁代码没有则走原方法。好处是兼容性较好、也支持即时生效但插桩会带来一定性能损耗而且只支持方法体级别的替换。三种流派我放到一张表里对比你一眼就能看出差别方案代表框架生效方式支持范围补丁大小兼容性性能影响类加载替换Tinker重启后生效代码资源较大较好较低底层NativeAndFix即时生效代码小差低字节码插桩Robust即时生效代码小较好中等选型建议就一条团队人少、追求稳优先走Tinker类加载方案社区资料多踩坑有前车之鉴业务对即时性要求极高完全不能接受重启再考虑Robust方向。2.2 后端JVM的热修原理和边界都不一样后端Java服务的热修复核心路径靠的是JVMTI。JVM提供了一套Native接口允许外部工具在运行时修改已经被JVM加载的类。基于这套机制可以在不重启JVM的情况下重定义某个类的字节码。注意这里的“重定义”是有限制的——只能修改方法体不能增减字段和方法也不能修改类的签名。工具层面最常用的是Arthas。它内置了redefine命令可以把本地编译好的class文件加载到运行中的目标JVM进程里直接替换旧类的实现。这个替换是即时生效的非常适合线上紧急判断题空逻辑这类小bug。后端热修还有一个常规操作是动态脚本加载。Groovy等脚本语言可以在运行期编译并执行Java代码里预留脚本接口紧急逻辑写成脚本从配置中心拉取。这种方式灵活度更高但性能比原生Java差一些而且脚本随便写容易出现安全问题一般只用在规则类、校验类的低QPS场景。2.3 前端和Node系的热更新是另一个物种严格意义上前端常说的HMR模块热替换和我们讨论的线上热修复并不完全是一回事。开发期Vite和Webpack的HMR是为了让本地开发不用刷新页面就生效它面向的是开发体验。线上前端的“热修复”更多是指动态加载远程JavaScript代码或者以模块联邦的方式让运行时拉取新的远程模块。这套玩法的优势和风险都很明显。优势是前端天然有动态执行脚本的能力修复成本极低风险则是远程代码一旦被篡改影响是全量用户而且难以审计。在关键业务上我的建议是远程模块只能加载经过签名校验的内容绝不能裸牵第三方源。3. 实操记录Android端用Tinker完整跑通一次热修复3.1 项目接入前的准备我自己的一个工具型App曾经出现过一次线上崩溃原因是在Android 12的某些机型上读取设备标识的逻辑抛了异常。那次我用Tinker走了一整套流程比较有代表性。第一步是项目接入。首先要确认Gradle和AGP版本匹配Tinker插件对高版本Android Gradle Plugin的适配一直有滞后我习惯用相对保守的版本组合。App模块的build.gradle里加入Tinker相关依赖和插件apply plugin: com.tencent.tinker.patch dependencies { implementation com.tencent.tinker:tinker-android-lib:1.9.14 } tinkerPatch { tinkerEnabled true // 基线APK路径 oldApkFile ${rootProject.rootDir}/app/build/outputs/apk/release/app-release.apk // 使用签名配置 buildConfig { useSign true } }这里有个关键点Tinker生成补丁需要有一个“老包”作为基线。也就是说你在发布1.0版本时必须保留当时的APK文件后续要打补丁时用新代码和这个老包做差异对比才能生成从1.0升级的补丁。所以我一直强调版本构建产物的归档是热修复的基础设施CI流水线里必须把每次发布的APK存好。3.2 初始化与补丁下载逻辑App的Application里需要做Tinker的初始化。补丁文件我放在自己服务器的固定路径下App启动时异步检查并下载。核心代码大致这样public class App extends Application { Override public void onCreate() { super.onCreate(); TinkerInstaller.install(this); loadPatch(); } private void loadPatch() { TinkerInstaller.onReceiveUpgradePatch( getApplicationContext(), patchFile.getAbsolutePath() ); } }实际生产中下载补丁有很多细节下载要断点续传、要对补丁做完整性校验、下载失败不能影响主流程。Tinker内部对补丁文件的安全做了校验但网络层的可靠性需要自己保证。那次我下载补丁用的是公司内部的文件服务加了MD5校验App在Wi-Fi环境下自动拉取没有让用户手动操作。3.3 生成补丁与线上验证修好崩溃代码后我在命令行执行了补丁生成任务./gradlew tinkerPatchRelease生成的补丁文件在build/outputs/apk/release/目录下名字类似patch_signed_7zip.apk。我先在一台与问题机型同系统版本的测试机上装上老APK再把补丁文件推到App的补丁目录杀掉进程重新打开确认崩溃不再出现。接着才分批灰度放量。这里要特别提一个经验补丁只对装了基线APK的用户有效。如果用户装的是比基线版本还老的包补丁不会生效。所以每次发补丁之前一定要确认当前线上存量用户的版本分布。那次我的工具App分发了比较广部分用户停留在更老的版本我就针对老版也打了一份补丁防止修复覆盖不到。4. 后端Java服务热修Arthas redefine一条实操路线4.1 用Arthas重定义线上方法体后端场景我也遇到过必须热修的紧急问题。当时一个订单状态流转的服务上线后我发现某个状态下金额校验写反了导致部分订单金额异常。虽然影响面可以通过接口收敛但核心服务重启一次客户端的重试风暴更让人头疼。权衡之后我决定用Arthas做一次类重定义。先连接到目标JVM进程java -jar arthas-boot.jar 23222查看需要修改的类由哪个ClassLoader加载sc -d com.example.OrderValidator确认ClassLoader的Hash值之后我在本地用相同JDK版本编译好新的OrderValidator.class注意包名和类名必须完全一致方法签名不能有任何变动。然后执行重定义redefine --classLoaderClass sun.misc.Launcher$AppClassLoader /tmp/OrderValidator.class命令执行成功后Arthas会返回重定义结果。从此刻开始新的方法体直接生效不需要重启服务。我立即通过另一条Arthas的watch命令观察线上真实请求是否走了新逻辑确认输出符合预期。4.2 服务端热修的适用范围与回退策略必须说清楚Arthas的redefine是一次“临时续命”不是长久之计。它不能改变类的结构、不能增加方法、不能修改注解。而且一旦JVM发生Full GC或者后续发布新版本重定义的效果就没了。所以后端热修的定位应该是为开发团队争取时间而不是替代正规发布。回退策略同样要想在前头。我在做重定义之前先保留了原始class文件如果修改后出现了新问题直接再用Arthas把旧class重新redefine回去就行。此外所有redefine操作都要记录审计日志谁在什么时间、改了哪个类、为什么改全部留痕。这在多人维护的服务上尤其重要不然出了问题排查的人只会一脸懵。5. 线上踩坑实录我从四次故障里总结的排错清单5.1 热修不生效的几类典型原因很多团队接入了热修复框架结果发现下发补丁后线上问题依旧复现。这时的排查方向往往和热修复框架本身无关。我把踩过的坑整理成了排查对照表现象可能原因排查方向补丁下发后无任何效果用户安装的版本与基线APK不匹配检查存量版本分布确认基线版本一致补丁包加载失败补丁签名校验不过或文件损坏检查补丁生成的签名配置与发布配置是否一致崩溃的还是同一行代码混淆导致类或成员变量名不一致确认补丁构建时的混淆配置与基线包完全一致只有部分机型生效厂商ROM对ClassLoader机制做了修改在问题机型上进行复现验证关注具体系统版本补丁生效但新逻辑不执行方法级插桩补丁的优先级冲突查看框架日志确认补丁是否被其他插件覆盖5.2 实操中容易被忽略的细节第一个细节是资源更新。如果热修复只更新了代码却改了布局文件类加载方案隔离了代码和资源的加载逻辑就必须同时打包资源补丁。我在早期接入时吃过亏只发了代码补丁结果界面文案还是旧的用户以为没修复。现在我的习惯是只要是UI相关的修复宁可代码和资源一起打进补丁也不贪图省事只发代码部分。第二个细节是代码整洁度和版本管理。热修复补丁的生成依赖干净的基线代码所以我要求主干分支永远保持可发布状态。代码改动先合入dev分支验证再合入test分支做回归全部通过后才可能进入release分支。提交代码时把commit信息写清楚补丁构建的来源才可追溯。你甚至可以把补丁构建也做成一个独立流水线只要输入基线和修复分支的版本号就能自动出包。第三个细节是测试策略。补丁的测试用例要和正式版本一样严格不能因为是“补丁”就草草验证。我踩过最深的坑就是补丁只测了目标机型结果在另一个系统版本上因为类加载顺序差异引发了新的崩溃。后来我要求所有补丁上线前都要跑一遍核心链路自动化用例再手动过一遍问题复现路径。5.3 上热修复前先练好这五条基本功基于这些经验我给团队定了五条热修复上线的硬性要求快速回滚预案无论用哪套方案必须提前约定好如何撤销补丁不能出现“修了一个bug引入了三个bug”的恶性循环。补丁签名与完整性补丁文件要带强校验网络传输不能成为攻击入口宁可下载失败不可被篡改。日志埋点补丁下载、校验、加载、生效的每个环节都要有日志输出线上才能快速定位补丁卡在哪一步。自动化构建补丁生成流程必须可重复绝对不能靠某个人在本地手动打补丁传上去。灰度发布先让内部群和少量用户验证补丁再全量放量大批量用户同时更新补丁本身也是一种风险。这五条里灰度发布是我最想强调的。热修复虽然不用发版但同样是一种线上变更。凡是变更必有风险。用热修复救火就好比给飞行中的飞机换引擎你必须在降落伞和备用引擎都准备好之后才动手。我个人在实际操作中的体会是热修复技术最迷人的地方不在于“黑科技”而在于它逼着你把代码规范、版本管理、日志埋点、灰度机制都盘了一遍。如果你发现自己的工程基础连一份可重复的APK都产不出来那再牛的热修复框架也救不了你。先把基本功打牢再考虑热修这才是最稳妥的路。
线上这周已经崩了三次客户在群里拍桌子你最想干的事是什么大部分人第一反应是赶紧把出问题的代码修掉最好能立刻生效。这就是“热修复”这门技术存在的意义——在不下发完整新版本的情况下让已经在线上跑着的程序把出问题的代码替换成修好的版本。移动端、后端服务、前端页面现在都有人在用不同形态的热修复但真正能把原理讲清楚、把坑踩明白的人并不多。今天想跟大家把这个话题聊透热修复到底修的是什么、主流方案各自怎么选、我在Android和后端 Java 上是怎么实际落地并且救过火的、以及那些文档里不会写的坑。适合移动端开发、后端开发、以及负责线上稳定性的一线工程师做技术参考。1. 先把热修复的适用边界划清楚1.1 热修复到底在解决什么问题热修复的核心场景只有一个线上已经发布的程序出现了紧急问题传统发版流程又来不及。移动端尤其典型用户不升级应用是常态新版本发出去两周线上可能还有一半用户跑的是旧包。而应用商店审核、灰度发布、渠道包分发这些环节全部走完少则一两天多则一两周。碰上支付崩溃、核心流程卡死这种P0故障根本等不起。后端的处境其实也没好到哪儿去。Java服务虽然可以重新发布但发布意味着重启意味着连接断开、缓存失效、请求超时。大型微服务体系里为改一行空指针判断去重启一个核心服务代价非常昂贵。所以热修复的本质是让代码在进程不重启、应用不发版的前提下从旧逻辑切换到新逻辑。这里要注意热修复不等于功能开关也不等于动态配置。改个文案、换个接口地址用配置中心和开关就行不需要动用热修复。真正需要热修复的是那些已经写死在代码里的逻辑——判空方式、排序规则、加密算法、业务分支——这些只能用新的代码把旧的代码顶掉。1.2 哪些场景适合、哪些真的不要碰我见过不少团队把热修复当成万能药什么改动都想往里塞结果捅出更大的篓子。根据我自己的经验适合热修复的场景大概这么几类线上崩溃、闪退且根因明确改动范围小。核心业务逻辑出错等待发版会造成巨额损失。安全问题需要紧急封堵比如某个校验逻辑被绕过。纯代码逻辑修复不涉及数据库结构变更。不适合热修复的场景同样要摆在明面上重大架构调整比如把整个网络层换成协程这种改动不可能靠热修完成。数据库表结构变动数据迁移必须伴随发版和备份策略。协议不兼容升级服务端和客户端同时改契约热修只改一端会造成联调混乱。涉及合规和资质的改动该走审核的必须走完整流程。判断标准很简单热修复只适合修逻辑不适合动结构。你在评估需求的时候不妨先问自己三个问题这次改动能不能用一句“把某段逻辑替换掉”来描述改完之后如果效果不对能不能一秒回滚这个改动涉及的数据是否已经存在并需要迁移三问过后答案仍然清晰才适合走热修复。2. 主流热修复方案全景不同技术栈该选哪种2.1 Android端的三种流派对比Android端的热修复方案市面上的主流技术本质上是三套思路类加载方案、底层替换方案、字节码插桩方案。类加载方案的代表是腾讯的Tinker。它的原理是让App在下次启动时用一个新的dex文件整体替换掉旧的dex文件。因为是基于ClassLoader的dexElements数组替换所以支持代码和资源热更改动能力最强。代价是补丁需要合成一个新的完整dex生成的补丁包体积偏大而且必须冷启动后才能生效。底层替换方案的代表是早期的AndFix原理是在Native层直接修改ArtMethod的入口指针让方法调用跳转到新实现。好处是即时生效不用重启App。坏处是兼容性极差Android各个版本的虚拟机内部结构不同几乎是出一版系统就要适配一次现在基本已经退出主流选择。字节码插桩方案的代表是美团的Robust。它在编译期对每个方法都注入了补丁逻辑运行时会检查是否存在对应的补丁有则执行补丁代码没有则走原方法。好处是兼容性较好、也支持即时生效但插桩会带来一定性能损耗而且只支持方法体级别的替换。三种流派我放到一张表里对比你一眼就能看出差别方案代表框架生效方式支持范围补丁大小兼容性性能影响类加载替换Tinker重启后生效代码资源较大较好较低底层NativeAndFix即时生效代码小差低字节码插桩Robust即时生效代码小较好中等选型建议就一条团队人少、追求稳优先走Tinker类加载方案社区资料多踩坑有前车之鉴业务对即时性要求极高完全不能接受重启再考虑Robust方向。2.2 后端JVM的热修原理和边界都不一样后端Java服务的热修复核心路径靠的是JVMTI。JVM提供了一套Native接口允许外部工具在运行时修改已经被JVM加载的类。基于这套机制可以在不重启JVM的情况下重定义某个类的字节码。注意这里的“重定义”是有限制的——只能修改方法体不能增减字段和方法也不能修改类的签名。工具层面最常用的是Arthas。它内置了redefine命令可以把本地编译好的class文件加载到运行中的目标JVM进程里直接替换旧类的实现。这个替换是即时生效的非常适合线上紧急判断题空逻辑这类小bug。后端热修还有一个常规操作是动态脚本加载。Groovy等脚本语言可以在运行期编译并执行Java代码里预留脚本接口紧急逻辑写成脚本从配置中心拉取。这种方式灵活度更高但性能比原生Java差一些而且脚本随便写容易出现安全问题一般只用在规则类、校验类的低QPS场景。2.3 前端和Node系的热更新是另一个物种严格意义上前端常说的HMR模块热替换和我们讨论的线上热修复并不完全是一回事。开发期Vite和Webpack的HMR是为了让本地开发不用刷新页面就生效它面向的是开发体验。线上前端的“热修复”更多是指动态加载远程JavaScript代码或者以模块联邦的方式让运行时拉取新的远程模块。这套玩法的优势和风险都很明显。优势是前端天然有动态执行脚本的能力修复成本极低风险则是远程代码一旦被篡改影响是全量用户而且难以审计。在关键业务上我的建议是远程模块只能加载经过签名校验的内容绝不能裸牵第三方源。3. 实操记录Android端用Tinker完整跑通一次热修复3.1 项目接入前的准备我自己的一个工具型App曾经出现过一次线上崩溃原因是在Android 12的某些机型上读取设备标识的逻辑抛了异常。那次我用Tinker走了一整套流程比较有代表性。第一步是项目接入。首先要确认Gradle和AGP版本匹配Tinker插件对高版本Android Gradle Plugin的适配一直有滞后我习惯用相对保守的版本组合。App模块的build.gradle里加入Tinker相关依赖和插件apply plugin: com.tencent.tinker.patch dependencies { implementation com.tencent.tinker:tinker-android-lib:1.9.14 } tinkerPatch { tinkerEnabled true // 基线APK路径 oldApkFile ${rootProject.rootDir}/app/build/outputs/apk/release/app-release.apk // 使用签名配置 buildConfig { useSign true } }这里有个关键点Tinker生成补丁需要有一个“老包”作为基线。也就是说你在发布1.0版本时必须保留当时的APK文件后续要打补丁时用新代码和这个老包做差异对比才能生成从1.0升级的补丁。所以我一直强调版本构建产物的归档是热修复的基础设施CI流水线里必须把每次发布的APK存好。3.2 初始化与补丁下载逻辑App的Application里需要做Tinker的初始化。补丁文件我放在自己服务器的固定路径下App启动时异步检查并下载。核心代码大致这样public class App extends Application { Override public void onCreate() { super.onCreate(); TinkerInstaller.install(this); loadPatch(); } private void loadPatch() { TinkerInstaller.onReceiveUpgradePatch( getApplicationContext(), patchFile.getAbsolutePath() ); } }实际生产中下载补丁有很多细节下载要断点续传、要对补丁做完整性校验、下载失败不能影响主流程。Tinker内部对补丁文件的安全做了校验但网络层的可靠性需要自己保证。那次我下载补丁用的是公司内部的文件服务加了MD5校验App在Wi-Fi环境下自动拉取没有让用户手动操作。3.3 生成补丁与线上验证修好崩溃代码后我在命令行执行了补丁生成任务./gradlew tinkerPatchRelease生成的补丁文件在build/outputs/apk/release/目录下名字类似patch_signed_7zip.apk。我先在一台与问题机型同系统版本的测试机上装上老APK再把补丁文件推到App的补丁目录杀掉进程重新打开确认崩溃不再出现。接着才分批灰度放量。这里要特别提一个经验补丁只对装了基线APK的用户有效。如果用户装的是比基线版本还老的包补丁不会生效。所以每次发补丁之前一定要确认当前线上存量用户的版本分布。那次我的工具App分发了比较广部分用户停留在更老的版本我就针对老版也打了一份补丁防止修复覆盖不到。4. 后端Java服务热修Arthas redefine一条实操路线4.1 用Arthas重定义线上方法体后端场景我也遇到过必须热修的紧急问题。当时一个订单状态流转的服务上线后我发现某个状态下金额校验写反了导致部分订单金额异常。虽然影响面可以通过接口收敛但核心服务重启一次客户端的重试风暴更让人头疼。权衡之后我决定用Arthas做一次类重定义。先连接到目标JVM进程java -jar arthas-boot.jar 23222查看需要修改的类由哪个ClassLoader加载sc -d com.example.OrderValidator确认ClassLoader的Hash值之后我在本地用相同JDK版本编译好新的OrderValidator.class注意包名和类名必须完全一致方法签名不能有任何变动。然后执行重定义redefine --classLoaderClass sun.misc.Launcher$AppClassLoader /tmp/OrderValidator.class命令执行成功后Arthas会返回重定义结果。从此刻开始新的方法体直接生效不需要重启服务。我立即通过另一条Arthas的watch命令观察线上真实请求是否走了新逻辑确认输出符合预期。4.2 服务端热修的适用范围与回退策略必须说清楚Arthas的redefine是一次“临时续命”不是长久之计。它不能改变类的结构、不能增加方法、不能修改注解。而且一旦JVM发生Full GC或者后续发布新版本重定义的效果就没了。所以后端热修的定位应该是为开发团队争取时间而不是替代正规发布。回退策略同样要想在前头。我在做重定义之前先保留了原始class文件如果修改后出现了新问题直接再用Arthas把旧class重新redefine回去就行。此外所有redefine操作都要记录审计日志谁在什么时间、改了哪个类、为什么改全部留痕。这在多人维护的服务上尤其重要不然出了问题排查的人只会一脸懵。5. 线上踩坑实录我从四次故障里总结的排错清单5.1 热修不生效的几类典型原因很多团队接入了热修复框架结果发现下发补丁后线上问题依旧复现。这时的排查方向往往和热修复框架本身无关。我把踩过的坑整理成了排查对照表现象可能原因排查方向补丁下发后无任何效果用户安装的版本与基线APK不匹配检查存量版本分布确认基线版本一致补丁包加载失败补丁签名校验不过或文件损坏检查补丁生成的签名配置与发布配置是否一致崩溃的还是同一行代码混淆导致类或成员变量名不一致确认补丁构建时的混淆配置与基线包完全一致只有部分机型生效厂商ROM对ClassLoader机制做了修改在问题机型上进行复现验证关注具体系统版本补丁生效但新逻辑不执行方法级插桩补丁的优先级冲突查看框架日志确认补丁是否被其他插件覆盖5.2 实操中容易被忽略的细节第一个细节是资源更新。如果热修复只更新了代码却改了布局文件类加载方案隔离了代码和资源的加载逻辑就必须同时打包资源补丁。我在早期接入时吃过亏只发了代码补丁结果界面文案还是旧的用户以为没修复。现在我的习惯是只要是UI相关的修复宁可代码和资源一起打进补丁也不贪图省事只发代码部分。第二个细节是代码整洁度和版本管理。热修复补丁的生成依赖干净的基线代码所以我要求主干分支永远保持可发布状态。代码改动先合入dev分支验证再合入test分支做回归全部通过后才可能进入release分支。提交代码时把commit信息写清楚补丁构建的来源才可追溯。你甚至可以把补丁构建也做成一个独立流水线只要输入基线和修复分支的版本号就能自动出包。第三个细节是测试策略。补丁的测试用例要和正式版本一样严格不能因为是“补丁”就草草验证。我踩过最深的坑就是补丁只测了目标机型结果在另一个系统版本上因为类加载顺序差异引发了新的崩溃。后来我要求所有补丁上线前都要跑一遍核心链路自动化用例再手动过一遍问题复现路径。5.3 上热修复前先练好这五条基本功基于这些经验我给团队定了五条热修复上线的硬性要求快速回滚预案无论用哪套方案必须提前约定好如何撤销补丁不能出现“修了一个bug引入了三个bug”的恶性循环。补丁签名与完整性补丁文件要带强校验网络传输不能成为攻击入口宁可下载失败不可被篡改。日志埋点补丁下载、校验、加载、生效的每个环节都要有日志输出线上才能快速定位补丁卡在哪一步。自动化构建补丁生成流程必须可重复绝对不能靠某个人在本地手动打补丁传上去。灰度发布先让内部群和少量用户验证补丁再全量放量大批量用户同时更新补丁本身也是一种风险。这五条里灰度发布是我最想强调的。热修复虽然不用发版但同样是一种线上变更。凡是变更必有风险。用热修复救火就好比给飞行中的飞机换引擎你必须在降落伞和备用引擎都准备好之后才动手。我个人在实际操作中的体会是热修复技术最迷人的地方不在于“黑科技”而在于它逼着你把代码规范、版本管理、日志埋点、灰度机制都盘了一遍。如果你发现自己的工程基础连一份可重复的APK都产不出来那再牛的热修复框架也救不了你。先把基本功打牢再考虑热修这才是最稳妥的路。
