先给结论：混淆是加固的一部分，但不是加固的全部
在实际项目里，经常听到这样的说法：“我们已经开了混淆，应该算加固过了。”这句话只对了一半。代码混淆解决的是可读性问题，让反编译出来的类名、方法名、字符串变得难以理解；而 APK 加固要面对的是另一组问题：包体是否被改动、签名是否被替换、二次打包后能否被识别。两者目标不同，不能互相替代。
把这三件事拆开看，会更容易判断自己的包到底处在什么防护水平。
代码混淆：提高逆向成本，不阻止改动
混淆的典型手段包括标识符重命名、字符串加密、控制流平坦化、无用代码插入等。它带来的直接效果是：攻击者拿到反编译结果后，阅读和定位关键逻辑的成本上升。
- 能解决：类名方法名暴露业务结构、硬编码字符串被直接搜索、关键算法一眼看懂。
- 不能解决：包被解压后重新打包、签名被替换、资源文件被替换、动态调试和内存抓取。
也就是说，混淆之后包依然可以被解开、被修改、被重新签名安装。它降低的是“看懂”的效率，不是“改动”的可能性。如果只做混淆，遇到自动化重打包工具时基本没有抵抗力。
完整性校验：回答“这个包还是不是我发的那个包”
完整性校验的思路是让应用在运行时自己检查自己：签名证书指纹是否匹配、关键 dex 或 so 的摘要是否一致、安装包路径与预期是否相符、是否存在被注入的额外文件。一旦发现不一致，可以采取降级、限制功能或直接退出的策略。
它解决的是篡改检测问题，典型场景包括：
- 包被解包后修改了配置或资源，再重新打包分发。
- 关键代码被替换成带广告或窃取数据的版本。
- 签名被换成攻击者自己的证书，用于第三方渠道分发。
需要注意的是，完整性校验本身也可能被定位和绕过，因此校验点不宜过于集中，校验逻辑最好与业务路径结合，而不是单独放在一个显眼的方法里。同时，校验失败后的处理策略要提前设计，避免误伤正常用户，尤其是经过应用市场二次签名或渠道加固的包。
防二次打包：从“能检测”走到“难利用”
防二次打包更偏向主动防御。常见做法包括签名校验与证书绑定、安装来源与包名一致性检查、关键逻辑放到 native 层、对调试器与注入框架做检测、以及对重打包后常见的 hook 环境做识别。
它和完整性校验的区别在于侧重点：完整性校验偏“发现异常”，防二次打包偏“让重打包后的包跑不起来或跑不完整”。两者经常一起出现，但实现难度和维护成本不同，需要根据业务价值分级，不必对每个模块都上同等强度的防护。
如果团队还在评估整体方案，可以先看 加固服务的能力边界，确认对方提供的是混淆、校验还是运行时防护，避免把“开了混淆”误当成“已完成加固”。
三者怎么组合：一个可落地的顺序
对多数应用来说，合理的推进顺序是：
- 先做混淆，成本最低，能立刻降低代码可读性，但要保留必要的映射文件用于崩溃还原。
- 再加完整性校验，优先覆盖签名与关键代码摘要，明确校验失败后的降级策略。
- 最后补防二次打包，针对高价值模块做运行时检测，避免全量铺开导致兼容性问题。
需要提醒的是，加固不是一次性动作。每次发版、每次更换签名证书、每次接入新的渠道加固，都可能影响校验逻辑，因此要把校验点的回归测试纳入发版流程。关于签名与包体一致性的排查思路，可以参考 签名完整性相关说明 中的检查项。
常见误区
- “混淆等级拉满就等于加固”：混淆强度再高，也不检测包是否被改。
- “加了校验就万无一失”：校验点被定位后同样可以被 patch，需要分散与组合。
- “加固后不用管兼容”：native 层防护与部分机型、系统版本存在兼容风险，必须真机验证。
回到最初的问题：只做混淆不算完整的 APK 加固。混淆、完整性校验、防二次打包分别对应可读性、篡改检测和主动防御三个层面，缺一层就会留下明显缺口。判断自己的包是否“够用”，不妨按这三个问题逐条自测，而不是只看有没有开混淆开关。