Android 代码混淆工具怎么选（2026）：每一款到底保护了哪一层

大多数讲 Android 代码混淆工具的文章，都是罗列一堆产品，然后让你自己猜每款到底作用在哪一层。这个分类轴本身就选错了。对逆向者来说，一个 Android 应用至少是三样彼此独立的东西 —— Java/Kotlin 字节码、native 库，以及外围的资源与清单文件 —— 而市面上每款工具覆盖的子集都不一样。

本文按"实际保护了什么"来给工具分类，这样你装完一款之后，能清楚知道自己还剩哪些缺口。

混淆能买到什么，买不到什么

混淆抬高的是理解代码的成本。它不会让代码变得不可读，也挡不住一个有耐心的攻击者。凡是设备能执行的东西，就能被迫在设备上暴露出来。

把话说清楚之后，目标就现实了：让随手反编译变得无利可图、把机密彻底挪出客户端、把重型工具留给真正要紧的那部分。对基础概念还不熟的话，可以先看 代码混淆器是什么，本文下面直接进 Android 的具体层次。

第 1 层：Java 与 Kotlin 字节码

这是默认工具链所在的一层，也是多数团队其实已经被覆盖、却没意识到的一层。

R8 是内置在 Android Gradle Plugin 里的压缩与混淆器，自 AGP 3.4 起已取代 ProGuard 成为默认。它同时做三件事：tree shaking（移除不可达代码）、重命名（类、方法、字段变成 a、b、c）、优化（内联、常量折叠）。在 release 构建里打开 minifyEnabled true 就启用了。对相当大比例的应用来说，这就是它们需要的全部。

ProGuard 作为独立项目仍然存在、也仍然能用，但在现代 Android 上它属于历史选项而非推荐项。为它写的规则可以保留 —— R8 读的是同一套 proguard-rules.pro 语法 —— 除非有明确理由，否则不必迁移工具本身。

DexGuard 是同源的商业版本。在重命名之外，它增加了字符串加密、类加密、控制流混淆、反射隐藏，以及 root 检测、篡改检测这类运行时完整性校验。当"只重命名"不够用时它才是答案 —— 支付、授权、DRM 相邻的逻辑。

Allatori 及同类商业 Java 混淆器处在中间地带：比 R8 多出字符串加密和控制流变换，但没有完整的运行时防护套件，价格也不到 DexGuard 那一档。

关于重命名碰不到什么，需要单独提醒：任何通过反射访问的东西、任何写进清单的东西、任何被库按字符串查找的东西，都碰不到。它们每一个都需要一条 -keep 规则，而每一条 -keep 规则都意味着应用里留了一块明文。规则清单要短、要具体 —— 写成 -keep class ** 等于整件事白做。

第 2 层：native 代码

通过 NDK 把逻辑挪进 C/C++，是难度上的实质性提升。native 代码没有字节码那一层元数据，反编译得到的是汇编，而不是接近原始源码的东西。

Obfuscator-LLVM（OLLVM） 及其仍在维护的分支，在编译期做指令替换、虚假控制流和控制流平坦化。它是 native 混淆的标准起点，可以接进 NDK 工具链。

代价也很具体：构建复杂度上升、二进制体积变大、崩溃日志符号化变难，而且性能敏感路径在控制流平坦化下可能出现明显回退。要挪的是那个确实需要保护的函数，不是整个应用。

第 3 层：资源、清单与打包

代码重命名，对一个写着 API 地址的 strings.xml 毫无作用，对一份把每个组件名字都明文列出的清单同样毫无作用。

资源压缩（shrinkResources true）会移除未使用的资源；它本质是体积优化，顺带缩小了暴露面。资源混淆类工具（如 AndResGuard）会重命名资源路径，早年被大量用于 APK 瘦身，但凡是运行时按名字解析资源的地方都需要回归测试。

Obfuscapk 是一款开源、插件化的混淆工具，作用对象是已经打好包的 APK，而不是编译期。这让它在你无法掌控构建流程的管线里有用，在安全研究中也有用，但它替代不了集成进构建的防护。

这一层最重要的两条规则都很朴素：别把机密打进客户端 —— API key、签名材料、凭据，无论混淆得多好都不行；以及别以为字符串加密解决了问题 —— 运行时会被解密的字符串，运行时就能被读出来。

第 4 层：运行时完整性

混淆是静态的。对于"让应用跑起来、再用 Frida 或改造过的运行时在线上挂钩"的攻击者，它什么也做不了。

运行时防护 —— root 检测、调试器检测、模拟器检测、签名校验、hook 检测 —— 是另一个产品品类，DexGuard 内置了一部分，RASP 厂商单独提供。它买到的是时间而非杜绝：每一道检查本身也是代码，也能被找到并抹掉，这也正是它通常要配合更重的混淆一起用的原因。

Play Integrity API 也属于这一层，但它回答的是另一个问题：它告诉你的服务器，这个应用和设备看起来是不是正品。这道服务端校验比任何客户端检测都更有价值 —— 因为它是攻击者没法从你的 APK 里 patch 掉的那一道。

起点怎么定

• 普通应用、无特殊风险：R8 + 一份收得很紧的 -keep 清单，加上资源压缩。顺手确认 release 构建确实产出并归档了 mapping.txt —— 反混淆崩溃日志要靠它。
• 客户端有敏感逻辑：加上字符串与控制流混淆，并把真正敏感的那个函数用 OLLVM 挪到 native。
• 支付、授权或高滥用目标：带运行时完整性校验的商业套件，再由服务端证明兜底。
• 以上任意一种：都按"客户端是敌占区"来假设，把机密留在服务端。

如果你的分发链路有一部分不走应用商店，打包方式的选择会和上面这些相互作用，取舍可以参考 PWA 与 APK 的对比。

常见问题

只用 R8 够不够？

对多数应用来说够。R8 零成本、无额外构建复杂度地提供了重命名、压缩和优化，足以让随手反编译变得不划算。但它不加密字符串、不混淆控制流、不检测篡改 —— 如果你的威胁模型包含这些，R8 是下限而不是上限。

混淆会不会让崩溃日志用不了？

会改变它，但不是让它失效。R8 会产出 mapping.txt，把混淆后的名字映射回原名；每次发版上传给崩溃平台，堆栈就仍然可读。反过来，某个已发布版本的 mapping 文件丢了，那个版本的崩溃就永久读不懂了。

混淆会让应用变慢吗？

字节码的重命名与压缩通常让应用略小、略快，因为死代码被移除了。控制流平坦化和 native 混淆则相反，可能带来可测量的性能损失，所以应当小范围使用。

混淆能阻止别人二次打包我的 APK 吗？

单靠它不能。对抗二次打包靠的是签名校验和服务端证明，不是重命名。混淆让"改出这个版本"更费劲，完整性校验让"改出来的版本用不了"。

结论

按层选工具，别按品牌选。字节码这一层，R8 对多数团队已经够用；native 与运行时完整性是两笔独立的支出、各有各的代价；资源和清单需要单独过一遍。而所有组合都改变不了那条决定多数结局的规则 —— 发到设备上的机密，等于已经公开的机密。