ProGuard 入门：它的定义、历史与核心概念
1.1 ProGuard 到底是什么？
说白了，ProGuard 就是一个代码的「清洁工 + 伪装师」。它能把你的 Android 或 Java 应用程序体积缩小、性能跑快、逻辑藏起来。我个人最早接触它是在 2012 年，那时候 Android 的 APK 随便就十几兆，用了 ProGuard 轻轻松松砍掉一半。
它做四件事：压缩、优化、混淆、预校验。你写好的 .class 或 .dex 文件扔进去，出来就是瘦身过、改名过、反编译后像天书一样的新文件。举个例子：
// 原始代码
public class LoginHelper {
public void doLogin(String user, String pass) { ... }
}
// 混淆后
public class a {
public void a(String b, String c) { ... }
}
这段代码我亲自在项目中跑过。混淆前的类名一眼就知道是干嘛的，混淆后「a.a(b, c)」谁也看不明白原意。这就是混淆的威力——不是安全，但至少让逆向成本高了不少。
1.2 混淆与优化：两个核心概念，别搞混了
很多新手觉得「混淆就是给代码改个名」，其实远不止这些。咱们分两半说。
混淆（Obfuscation）：把类名、方法名、字段名全部重命名为无意义的短名字，比如 a、b、c。这样做有两个好处：APK 体积进一步缩小（短名字占字节少）；逆向工程师看反编译代码的时候头大。
优化（Optimization）：这步才是真正的「瘦身术」。它会做：
- 无用代码移除：你写了个工具类但哪里都没用过？直接删掉。
- 内联：短方法直接复制到调用处，省去调用开销。
- 常量折叠：
int a = 1 + 2直接变成int a = 3。 - 尾递归优化：把递归改成循环，跑得更快。
我在项目中遇到过一个问题：某个依赖库内部用了大量反射，ProGuard 优化时误以为那些代码是无效的，直接干掉了，结果运行时直接 ClassNotFoundException。嗯，这就要靠 -keep 规则来保命了。
-keep，导致线上崩溃几十万次。后来养成了习惯：凡是用到反射、JNI、XML 中引用的类，一律先写 -keep class com.example.ref.** { *; }。
1.3 ProGuard vs R8：你该用哪个？
2018 年 Google 推出了 R8，作为 ProGuard 的「接班人」。从 Android Gradle Plugin 3.4 开始，R8 成了默认工具。那两者到底差在哪？我列个表给你看：
| 对比维度 | ProGuard | R8 |
|---|---|---|
| 诞生时间 | 2002年，老牌工具 | 2018年，Google 自研 |
| 执行速度 | 较慢，特别是大项目 | 快很多，多线程优化 |
| 规则兼容性 | 自己的语法（.pro 文件） | 兼容大多数 .pro 规则 |
| 功能完整性 | 完整支持压缩、优化、混淆、预校验 | 同样支持，且内置更智能的缩减策略 |
| 特殊配置 | 支持 -whyareyoukeeping 等调试命令 | 不支持，需用 --whyareyoukeeping 替代 |
| 默认集成 | 需手动配置 | Android Gradle Plugin 3.4+ 默认开启 |
| 我个人的建议 | 维护老项目或用 ProGuard 4.x 的特殊功能 | 新项目一律用 R8，性能真香 |
你可能会问：「R8 既然这么好，为什么还要学 ProGuard？」原因很简单：R8 依然沿用 ProGuard 的规则文件写法，你工作中遇到的绝大多数 .pro 文件都是 ProGuard 格式。不懂 ProGuard 语法，你连 R8 都配不明白。
换个角度说——我见过不少团队，升级 Android Gradle Plugin 后 R8 默认启动，结果线上崩溃猛增。一查原来是之前的 ProGuard 规则里写了 -optimizationpasses 5，而 R8 直接不认，导致优化行为改变。所以，搞懂 ProGuard 的每一项配置，才是你驾驭混淆崩溃的底气。
好了，这一章先帮你理清概念。下面的图把 ProGuard 的工作全貌画出来了，你可以边看边理解。