先把问题拆开：加固要防的到底是什么
很多团队在评估加固方案时，会把“有没有混淆”当成唯一指标。混淆确实是最容易看到效果的一环——反编译出来的类名、方法名变成 a、b、c，逻辑读起来费劲。但如果把混淆等同于加固，就容易在另外两个环节留下缺口：包被改动后能否被发现，以及被改动过的包能否顺利安装到用户设备上。
从攻击链看，针对 APK 的常见操作大致分三步：拿到包、读懂包、改包再分发。混淆作用于第二步，完整性校验作用于第三步的“发现”，防二次打包则同时作用于“改包”和“分发”。三者不是替代关系，而是覆盖不同环节。
代码混淆：提高阅读成本，不阻止修改
代码混淆的核心价值是降低逆向分析的效率。标识符重命名、字符串加密、控制流平坦化、无用代码插入，这些手段让攻击者理解业务逻辑的时间变长。对普通开发者来说，这意味着核心算法、接口签名规则、风控判断条件不会一眼被看穿。
但要注意混淆的边界：
- 混淆不改变包的字节结构，攻击者依然可以替换资源、注入代码、修改清单文件。
- 混淆后的代码仍可运行，也就是说被篡改的包照样能编译出来。
- 混淆强度过高会带来崩溃定位困难、堆栈不可读等维护成本，需要保留映射文件并做好版本管理。
所以混淆解决的是“读不读得懂”，而不是“改没改过”。只做混淆，等于只锁了书房门，没装大门报警器。
完整性校验：让“被改过”这件事可被发现
完整性校验的目标是判断当前运行的包是否与发布时一致。常见做法包括校验签名证书指纹、校验关键文件的摘要值、在运行时检查自身安装包信息等。它的价值不在于阻止修改，而在于让修改暴露出来。
实际落地时有几个容易踩的点：
- 校验逻辑本身要抗绕过。如果校验代码集中在明处，攻击者定位后直接跳过即可，因此校验点宜分散、结果宜延迟使用。
- 校验结果要有处置策略。发现不一致时是拒绝启动、限制核心功能，还是上报服务端做风控，需要结合业务场景决定，避免误伤正常用户。
- 签名校验要和渠道包管理配合。多渠道路径下，证书指纹应保持一致，否则校验逻辑本身会成为故障源。
完整性校验与混淆经常搭配使用：混淆保护校验逻辑不被轻易定位，校验则弥补混淆无法发现篡改的短板。
防二次打包：让改过的包装不上、跑不起来
二次打包指攻击者反编译原包、植入广告或恶意代码后重新签名分发。防二次打包要解决的是“改过的包能不能在真实设备上正常使用”。手段通常包括签名一致性校验、安装包指纹绑定、运行时环境检测，以及配合服务端下发策略拒绝异常客户端。
这里的关键认知是：防二次打包不是单点技术，而是“客户端检测 + 服务端裁决”的组合。客户端负责采集与初判，服务端负责最终处置，例如限制登录、降级功能、拒绝下发敏感数据。纯客户端的防护在足够有耐心的攻击者面前会被逐步剥离，服务端裁决则把成本抬高了。
如果团队同时涉及多渠道分发与签名管理，建议把签名一致性和包体校验纳入发布流程，可参考站内的签名与分发相关服务说明，先理清证书与渠道包的关系，再谈防护策略。
三者怎么组合才算“加固”
一个务实的判断标准是：面对“包被反编译”“包被修改”“改过的包被分发”这三种情形，你的方案是否都有对应动作。
- 只有混淆：能拖慢阅读，但改包和分发不受影响。
- 混淆 + 完整性校验：能发现篡改，但发现之后如何处置需要设计。
- 混淆 + 完整性校验 + 防二次打包（含服务端裁决）：形成从“提高成本”到“发现异常”再到“阻断使用”的闭环。
因此，只做混淆通常只能称为“代码保护”，称为“APK 加固”并不准确。加固的本质是把防护点铺在攻击链的多个环节上，而不是把某一个环节做到极致。
落地建议：按风险排优先级
不是所有应用都需要全套方案。可以按业务风险排序：涉及支付、账号资产、独家内容的应用，优先补齐完整性校验与服务端裁决；工具类、内部应用可以先做混淆与基础签名校验，控制维护成本。无论哪种组合，都建议保留映射文件、建立发布包指纹记录，并在灰度阶段验证校验逻辑不会误伤正常安装。
最后提醒一点：加固手段会随系统版本和分发渠道规则变化而调整，方案设计时应保留可替换的余地，避免把某一项检测写死成业务前置条件。