先把问题说清楚：混淆只是加固的一层
在移动安全讨论里，“加固”经常被当成一个笼统的词。有团队在构建脚本里打开 R8/ProGuard，把类名、方法名改成 a、b、c，就认为 APK 已经加固完成。这个判断并不准确：混淆解决的是“读不懂”，完整性校验解决的是“改没改”，防二次打包解决的是“还是不是你的包”。三者目标不同，缺一层就会留下对应的攻击面。
下面按这三层分别说明它们面对的攻击方式、能挡住什么、以及单独使用时的局限。
代码混淆：提高逆向阅读成本
混淆的典型手段包括标识符重命名、字符串加密、控制流平坦化、无用代码插入等。它直接对抗的是反编译后的可读性：攻击者用 jadx 打开一个未混淆的包，往往能顺着类名和方法名快速定位登录、支付、签名校验逻辑；混淆之后，同样的分析需要更多时间和上下文推断。
混淆能带来的收益：
- 降低业务逻辑被快速理解、被复制实现的风险；
- 让自动化扫描与批量分析工具的效果下降；
- 配合资源压缩，减小包体、缩短下载时间。
但混淆的边界也很清楚：
- 它不阻止修改。攻击者不需要读懂代码，也可以直接替换资源、注入 so 库、改 Manifest 或重打包；
- 它不提供运行时检测。包被改动后，应用自身不会因此报警；
- 它不保护签名。重签名后的包依然能安装运行，混淆对此无能为力。
所以“只做混淆”更准确的说法是：完成了代码可读性层面的处理，但没有建立任何篡改发现机制。对于涉及账号、支付、虚拟资产的 App，这个缺口通常不可接受。
完整性校验：让“被改过”这件事暴露出来
完整性校验的核心是在运行时判断当前安装包是否与发布时一致。常见做法包括：校验 APK 签名证书摘要、比对关键文件或资源的哈希、检查 dex 与 so 的校验值、检测调试状态与常见注入框架痕迹。一旦发现不一致，可以采取降级、限制敏感功能或直接退出的策略。
它解决的是“篡改发现”问题：即使攻击者成功重打包，应用也有机会在启动或关键流程中识别出来。落地时有几点值得注意：
- 校验点要分散。只在一个入口做一次判断，很容易被定位并 patch 掉；把校验逻辑分散到多个业务路径，能显著提高绕过成本。
- 校验值不要硬编码在易读位置。否则攻击者改一个常量就能让校验永远通过。
- 失败策略要设计。直接崩溃容易被定位，静默降级配合服务端风控往往更有效。
- 服务端要参与。客户端校验总能被绕过，关键权益判断应放在服务端，结合设备与版本信息做交叉验证。
需要提醒的是，完整性校验属于“提高成本”而非“绝对防御”。它不能阻止有足够耐心的逆向者，但能把批量重打包、脚本化改包这类低成本攻击挡在门外。
防二次打包：确认“这个包是不是你发的”
二次打包指攻击者取出你的 APK，插入广告 SDK、恶意模块或修改付费逻辑后重新签名分发。防二次打包关注的是来源可信：签名是否为你持有、包名与证书指纹是否匹配、分发渠道是否合法。
常见手段包括：
- 校验签名证书指纹，与预期值比对；
- 使用签名校验与资源校验组合，防止仅替换资源绕过；
- 在服务端记录合法包的版本与签名信息，异常包在接口层被拒绝；
- 对渠道包做差异化标记，便于追溯泄露来源。
它与完整性校验有重叠但不完全相同：完整性校验回答“内容有没有变”，防二次打包回答“这个包的身份对不对”。实践中两者通常一起做，因为攻击者既会改内容，也会换签名。
三层怎么组合：一个可落地的顺序
如果团队刚开始做加固，可以按下面的顺序推进，而不是一次性堆满所有手段：
- 先开混淆并验证兼容性。确认反射、序列化、JNI 调用、WebView 桥接等场景没有被误伤，保留 mapping 文件用于崩溃还原；
- 加入签名与关键文件校验。优先覆盖启动路径和支付、登录等敏感流程，校验点分散布置；
- 建立服务端侧的版本与签名白名单。让异常包即使装上也无法正常使用核心接口；
- 把发布流程固定下来。签名密钥、构建环境、渠道包生成规则都要有明确责任人和记录，避免内部流程漏洞抵消技术手段。
如果团队同时维护多个分发渠道与下载入口，建议把包体校验结果和下载侧的健康度一起看，相关服务说明可参考 站内服务页 中的分发与监测部分。混淆、校验、防重打包三者不是替代关系，而是从“难读”到“可发现”再到“可拒绝”的递进链条。
结论
只做混淆不算完整的 APK 加固。混淆降低的是分析效率，完整性校验提供的是篡改发现能力，防二次打包确认的是包的身份来源。三者叠加，才能让攻击者从“改个包就能用”变成“改了也跑不起来”。对大多数商业应用来说，合理的做法是：混淆作为基础配置，完整性校验与签名校验作为必要层，服务端风控作为最后一道闸门。