先把问题拆开：混淆、完整性校验、防二次打包不是同一件事
在加固方案讨论里，最常见的误区是把“代码混淆”直接等同于“APK 加固”。混淆确实能提高逆向阅读成本，但它不检测包体是否被改动，也不阻止别人换签名重新打包。把三件事放在一起看，边界会清楚很多：
- 代码混淆：让反编译后的类名、方法名、字符串、控制流难以理解，抬高静态分析成本。
- 完整性校验：在运行时判断自身代码、资源、签名是否与发布时一致，发现被改动就采取降级或退出策略。
- 防二次打包：针对“解包—改内容—重新签名—再分发”这条链路，让重打包产物无法正常运行或无法通过服务端校验。
三者解决的是不同层面的问题：混淆管“看懂难”，完整性校验管“改了能发现”，防二次打包管“改了也用不了”。只做第一层，后两层就是空的。
只做混淆会留下哪些缺口
混淆后的代码依然可以被动态调试、抓包和 Hook。攻击者不需要读懂全部逻辑，只要定位到关键判断点，就能改掉校验分支、替换资源、插入广告 SDK，然后用自己的证书重新签名分发。对业务来说，典型后果包括：
- 包体被植入第三方 SDK 或广告，用户看到的是你的图标、别人的行为；
- 付费、登录、风控逻辑被绕过，服务端收到的是伪造请求；
- 被替换的包出现崩溃或数据异常，口碑算在原应用头上；
- 渠道包被二次分发，统计与结算数据失真。
这些问题混淆一个都答不了，因为它不产生“这个包是不是我发的”的判断。换句话说，混淆是成本手段，不是验证手段。
完整性校验解决什么：让改动可被发现
完整性校验的核心是把“发布时的状态”变成可验证的基准，常见做法包括对关键 dex、so、资源文件做摘要，对签名证书做指纹比对，并在运行时或关键业务节点触发校验。它要回答的问题是：当前运行的代码和资源，是否与发布版本一致。
落地时有几个容易踩的点：
- 校验点不要只放在启动阶段。只在 Application 启动时校验一次，绕过成本很低；把校验分散到业务关键路径，配合服务端下发策略更稳。
- 失败策略要分级。直接闪退容易被用户当成 bug，可考虑功能降级、限制敏感操作、上报后再决定，具体口径要写进发布规范。
- 基准值要能更新。热修复或资源更新后，旧摘要会失效，需要版本化管理和灰度验证。
完整性校验的价值不只是拦截，更在于把“包被改过”变成可观测事件，便于运营侧统计和响应。
防二次打包解决什么：让重打包产物跑不起来
防二次打包关注签名与包体的一致性。Android 的签名机制决定了重打包必须换证书，因此校验签名指纹是最直接的入口；再叠加对安装来源、包名、渠道信息的交叉判断，可以覆盖大部分改包场景。更完整的做法还包括服务端参与：客户端上报签名摘要与设备信息，服务端比对白名单，异常请求直接拒绝。
需要注意的是，纯客户端校验总能被绕过，所以防二次打包的强度取决于“绕过之后还能不能拿到服务”。把关键能力放到服务端鉴权，比在客户端堆检测更有效。
三者怎么组合：一个可执行的顺序
如果团队刚开始做加固，可以按下面的顺序推进，而不是一上来就买最重的方案：
- 先做混淆，去掉日志与调试开关，降低静态分析收益；
- 加入签名指纹与关键文件摘要校验，建立异常上报；
- 把校验结果接入服务端策略，形成“检测—上报—处置”闭环；
- 再评估是否需要加壳、so 加密等更重的保护，按业务敏感度取舍。
这套顺序的好处是每一步都能独立验证效果：混淆看反编译难度，完整性校验看异常上报量，防二次打包看伪造请求是否被拒绝。具体服务范围可以参考 加固与签名相关服务 的说明，按包体类型和分发渠道选择组合。
结论
只做混淆不算 APK 加固，它只是加固的第一层。混淆提高理解成本，完整性校验提供可验证性，防二次打包切断改包后的可用性，三者解决的是不同问题。判断一个方案是否够用，不要看它“做了几项检测”，而要看它能否回答三个问题：代码是否难读、改动是否被发现、被改后是否还能用。三个都能答上，才谈得上加固。