加固后热更新失效了怎么办？我们排查一周找到的解决方案

一、从“补丁正常下发”到“用户疯狂崩溃”

加固后热更新失效，是我们踩过最隐蔽的坑。

事情是这样的：我们的一款金融App接入了Bugly热修复，内测阶段一切正常。为了上架合规，我们给APK做了360加固。加固后重新测试热更新：补丁能下载、能合成，看起来没问题，就发了灰度。

结果灰度的崩溃率从0.2%飙到了9%。用户反馈App启动就闪退，而且只在华为、荣耀的部分机型上复现。我们本地死活复现不出来，连出问题的同款手机都试了——一切正常。

那一周我们排查了类加载时机、补丁合成日志、加固后的DEX结构，最后发现根本原因是：加固改变了ClassLoader的行为，导致补丁类没有被正确加载。

二、加固为什么会搞崩热更新？

要理解这个问题，得先搞明白热更新的核心机制。

2.1 Tinker/Bugly的原理：Dex替换

Tinker的方案是下发差量补丁包，在手机端与基线包的DEX合成完整的新DEX，然后通过自定义ClassLoader，将新DEX插入到dexElements数组的前面。这样系统加载类时，优先从补丁DEX里找，实现了类替换。

关键点在于：这个机制依赖ClassLoader对dexElements的操控。

2.2 加固做了什么

加固工具（360加固、腾讯乐固、梆梆等）会对APK做DEX加密、代码抽取、SO混淆等操作。为了保护代码，加固后的APK在运行时往往会注入自己的ClassLoader，或者修改原有的类加载逻辑。

这就产生了冲突：

• 类被提前加载：加固框架可能在热修复初始化之前就把某些类加载进了内存。等补丁下来时，这些类已经被加载过了，ClassLoader不会再从补丁DEX里重新加载，导致修复失效。
• 双亲委派机制被打乱：加固的自定义ClassLoader可能破坏了双亲委派模型，导致补丁中的类压根找不到，抛出ClassNotFoundException或IncompatibleClassChangeError。
• 匿名内部类问题：加固后，外部类和内部类的加载时机发生变化，可能出现外部类从原包加载、内部类从补丁加载的情况，然后崩溃。

2.3 多渠道打包的“补刀”

我们同时用了Walle多渠道打包。加固后重新签名，渠道信息直接丢失，Bugly统计不到渠道数据。更糟的是，加固后Walle写入的渠道信息被清空，热修复补丁也因为签名变化而加载失败。

三、Tinker/Bugly加固适配方案（亲测有效）

排查一周后，我们总结出一套能跑的方案。以下配置基于Bugly + Tinker + 360加固，其他加固方案同理。

3.1 第一步：开启加固模式

Bugly从1.3.0版本开始支持加固模式（Tinker 1.7.9+）。在tinker-support.gradle中，必须把isProtectedApp设为true：

tinkerSupport {    // 开启tinker-support插件    enable = true        // 【关键】开启加固模式    isProtectedApp = true        // 使用ProxyApplication模式（加固场景推荐）    enableProxyApplication = true        // 其他配置...    baseApk = "${bakPath}/${baseApkDir}/app-release.apk"    baseApkProguardMapping = "${bakPath}/${baseApkDir}/app-release-mapping.txt"    baseApkResourceMapping = "${bakPath}/${baseApkDir}/app-release-R.txt"    tinkerId = "1.0.1-patch"}

isProtectedApp = true会让Tinker适配加固环境下的类加载器，避免补丁加载失败。

3.2 第二步：选择正确的Application接入方式

Bugly提供了两种接入方式，对应enableProxyApplication的值：

我们一开始用了反射模式（enableProxyApplication = true），结果在部分机型上不稳定。换成继承模式后问题解决。

继承模式的具体做法：

1. 修改tinker-support.gradle：

enableProxyApplication = false  // 关闭反射模式

2. 创建SampleApplication继承TinkerApplication：

public class SampleApplication extends TinkerApplication {    public SampleApplication() {        super(ShareConstants.TINKER_ENABLE_ALL,               "com.example.SampleApplicationLike",  // ApplicationLike全限定名              "com.tencent.tinker.loader.TinkerLoader",               false);    }}

3. 创建SampleApplicationLike继承DefaultApplicationLike，把所有Application的代码移到这里：

public class SampleApplicationLike extends DefaultApplicationLike {        public SampleApplicationLike(Application application, int tinkerFlags,                                 boolean tinkerLoadVerifyFlag, long applicationStartElapsedTime,                                 long applicationStartMillisTime, Intent tinkerResultIntent) {        super(application, tinkerFlags, tinkerLoadVerifyFlag,               applicationStartElapsedTime, applicationStartMillisTime, tinkerResultIntent);    }        @Override    public void onCreate() {        super.onCreate();        // 初始化Bugly        Bugly.init(getApplication(), "YOUR_APP_ID", true);    }        @Override    public void onBaseContextAttached(Context base) {        super.onBaseContextAttached(base);        // 必须安装MultiDex        MultiDex.install(base);        // 安装Tinker        Beta.installTinker();    }}

4. 在AndroidManifest.xml中声明SampleApplication：

3.3 第三步：Sophix的加固适配

如果你用的是阿里云的Sophix，适配逻辑类似但细节不同。

Sophix本身支持加固包的热修复，但关键原则是：必须在加固前打补丁包。

最佳实践流程：

1. 拿未加固的基线包和未加固的新包，在服务端生成差量补丁
2. 将补丁发布到线上，作用于已经加固的线上APK

另外，如果用的是梆梆加固，需要在Sophix配置中忽略sophix文件夹，避免加固工具误处理。

3.4 第四步：多渠道打包加固后的签名恢复

加固 + Walle多渠道打包有两个坑：渠道信息丢失、签名被覆盖。

解决方案是用开源工具ProtectedApkResignerForWalle重新签名：

操作步骤：

1. 先禁用Walle的渠道包生成命令，改用./gradlew clean assembleRelease生成单个基线包
2. 将基线包上传到加固平台加固，下载后不要用加固工具自带的签名
3. 下载ProtectedApkResignerForWalle工具，配置签名信息和加固后的APK路径
4. 执行python ApkResigner.py重新签名

tinker-support.gradle中需要保持：

isProtectedApp = true  // 必须开启

3.5 第五步：补丁生成的正确顺序

这是最容易出错的地方。加固场景下，补丁必须基于加固前的包生成，不能基于加固后的包。

正确流程：

1. 保存未加固的基线包APK、mapping文件、R.txt
2. 将未加固的基线包拿去加固、签名、发布到应用商店
3. 修复bug，用未加固的基线包 + 未加固的新包生成补丁
4. 将补丁发布到Bugly/Sophix后台，下发到已加固的用户手机上

错误流程（会导致补丁无效）：

• ❌ 基于加固后的APK生成补丁
• ❌ 用加固后的包作为基线包来diff

四、验证加固后热更新是否正常的Checklist

配置完后，别急着上线。我们总结了一份验证清单：

4.1 功能验证

• 补丁能正常下载（抓包看网络请求）
• 补丁能正常合成（看/data/data/包名/files/tinker/目录是否有补丁文件）
• 修复生效（修复的bug不再出现）
• 覆盖5.0以下和5.0以上机型测试
• 覆盖华为、小米、OPPO、vivo主流机型

4.2 兼容性验证

• 加固前后补丁都能正常加载（用未加固包和加固包分别测试）
• 同一版本不同渠道包都能收到补丁
• 多渠道包加固后渠道信息不丢失（调用WalleChannelReader.getChannel()验证）

4.3 降级验证

• 能手动清除补丁（Beta.cleanPatch()）
• 清除补丁后重启App，bug恢复（证明补丁确实生效过）

五、常见问题速查表

六、服务商加固模式的横向对比

数据来源：官方文档及实测

七、一句话总结

加固后热更新失效，本质是加固框架的ClassLoader与热修复的ClassLoader打架。解决方案也不复杂：开启加固模式、用继承方式接入、补丁必须在加固前生成、加固后重签名恢复渠道信息。

排查一周、崩溃率9%换来的教训是：加固和热更新必须在项目初期就一起接入测试，别等上架了才发现不兼容。希望这份方案能帮你少踩坑。