ProGuard工作原理：字节码处理与混淆流程

说实话，很多同学用了好几年 ProGuard，只会在 build.gradle 里写个 minifyEnabled true，真要问它怎么工作的，往往答不上来。当年我接手一个遗留项目，混淆一开就崩溃，花了两天排查，才发现是 ProGuard 的一条优化规则把反射调用的类给删了。从那以后，我就特别重视理解这个工具背后的原理。

这一章我们就一起看看，ProGuard 到底对字节码做了什么，混淆的完整流程是怎样一步步走下来的。

1. ProGuard 的本质

ProGuard 本质上是一个 字节码处理工具。它读入编译好的 JAR/AAR 或 class 文件，经过一系列的转换，输出更小、更安全、更高效的字节码。它并不是改源代码，而是操作 class 文件里的指令、常量池、属性表这些底层结构。

这三步是串行执行的，而且默认是全部开启。你可以通过 keep 规则来告诉 ProGuard：“这些部分别动！” 规则文件其实就是一层白名单。

2. 字节码处理流程

ProGuard 的处理流程可以分成 6 个阶段。我画了一张图帮你理清楚整体脉络：

3. 核心步骤详解

下面我把每一步拆开讲，顺便说说我自己的踩坑经验。

3.1 输入阶段

ProGuard 接收所有打包进来的 class 文件。它可以同时处理多个输入源：项目代码、本地库、第三方 SDK 的 AAR 等。你想想看，这里就埋了一个坑：如果某个第三方库没有提供它自己的 ProGuard 规则，你的 keep 规则写漏了，它会被当成“未使用”直接干掉的。

3.2 解析阶段

解析器会扫描所有 class 文件，构建出一张完整的 类引用关系图。这张图记录了谁调用了谁、谁继承了谁、哪些方法被用到。只有被这张图标记为“可达”的代码才会存活下来。我曾经遇到过一个奇怪的问题：某个工具类里定义了 public 静态方法，但代码里没用它，结果它和它的调用者一起被删掉了。后来我用 -whyareyoukeeping 才查清楚原因。

3.3 压缩阶段

压缩就是沿着引用树做垃圾回收。从入口点（即 keep 规则中指定的类）开始遍历，所有遍历不到的节点全部删除。这里要注意：反射 调用在字节码层面是看不见的，你必须用 keep 规则手动保护。

3.4 优化阶段

优化器会做很多微操，比如将短方法内联到调用处、合并接口、移除死代码分支（如永远不为 true 的 if 块）。在一般情况下这些优化是安全的，但如果你用了 -optimizationpasses 设成很高的次数，可能产生难以调试的 bug。我个人建议：默认值（5 pass）就够了，不要为了极致包大小乱调高。

3.5 混淆阶段

这才是大家最熟悉的“混淆”。ProGuard 把类名、方法名、字段名修改为 a、b、c、a.a() 这种短名字。但它会严格遵循 keep 规则：比如你 keep 了某个类名，它就不会被重命名；你 keep 了某个方法，它的方法名保持不变。

这里有一个容易被忽略的知识点：ProGuard 的重命名是基于 字典 的。默认字典是 a、b、c……aa、ab……，你也可以自定义字典（-obfuscationdictionary）。我见过有人把字典改成汉字，结果某些老旧设备解析不了 UTF-8 的类名导致崩溃。嗯，没必要花里胡哨。

3.6 输出阶段

最终输出一个（或多个）优化并混淆后的 JAR/AAR 文件。同时 ProGuard 会生成 mapping.txt 映射日志，记录了原名→混淆名的对应关系。这个文件一定要保留好，否则线上崩溃栈你完全看不懂。
另外还会生成 seeds.txt（哪些类被 keep 住了）和 usage.txt（哪些代码被移除）。这两个文件用来排查问题非常有用。

4. 处理流程的总结表格

阶段	输入	输出	常见问题
1. 输入	class/JAR/AAR	字节码快照	依赖不全导致编译失败
2. 解析	字节码	引用关系图	反射调用未被识别
3. 压缩	引用图	精简后类集合	Keep 规则遗漏
4. 优化	精简字节码	优化后字节码	过度优化改变行为
5. 混淆	字节码	重命名后字节码	反射、JNI 名称失效
6. 输出	混淆字节码	混淆产物+映射文件	mapping.txt 丢失

到这里你可能已经发现了：ProGuard 的本质其实就是一套基于引用图的智能裁剪+改名工具。理解了它执行的每一步，你才能写出精准的规则，而不是全凭感觉乱 keep。