环境搭建：Android Studio 集成与命令行配置
说实话，很多团队把 ProGuard 或 R8 的配置看得太简单了——加个 minifyEnabled true 就完事。结果上线后各种 ClassNotFoundException、NoSuchMethodError 满天飞。我在项目里见过好几次这种翻车现场，所以这一章咱们把整个环境搭建好好捋一遍，确保后面的优化能踩在实地上。
为什么这步很重要？
你想想看，如果基础环境没配对，后面所有的优化手段都是空中楼阁。R8 和 ProGuard 的配置路径、规则文件加载顺序、是否开启缩减……这些细节错一个，轻则混淆不到位，重则直接闪退。我以前接手过一个遗留项目，build.gradle 里同时写了 proguard-android-optimize.txt 和 proguard-rules.pro，但顺序反了，结果 R8 根本没用上自定义规则，线上包被逆向得像白纸一样——惨痛教训。
Android Studio 中的集成配置
咱们从最基础的 build.gradle 配置说起。通常在 app 模块的 build.gradle.kts（或 .groovy）里，你会看到类似这样的代码：
android {
buildTypes {
release {
minifyEnabled true // 开启混淆+缩减
proguardFiles getDefaultProguardFile('proguard-android-optimize.txt'),
'proguard-rules.pro'
// 如果你还想用 R8 的完全模式（默认就是 R8）
// 不需要额外声明，AGP 3.4+ 自动使用 R8
}
}
}
这里有个小细节——proguardFiles 方法的参数顺序有讲究。我习惯把默认规则放前面，自定义规则放后面，因为后面的文件会覆盖前面的同名配置。如果写反了，你自定义的 -keep 可能会被默认规则里的 -dontwarn 悄悄覆盖掉。
| 配置项 | 作用 | 我的建议 |
|---|---|---|
minifyEnabled true | 开启代码缩减和混淆 | release 必开，debug 通常关掉方便调试 |
proguardFiles | 指定规则文件路径 | 默认文件 + 自定义文件，顺序别搞反 |
consumerProguardFiles | 库模块向主模块传递规则 | 如果你开发 SDK，这个很关键 |
useProguard（旧版） | 强制使用 ProGuard 取代 R8 | AGP 3.6+ 已经废弃，别用了 |
minifyEnabled false，否则你每改一行代码都要等好几分钟混淆——我见过有人这么干，然后跑过来问我为啥编译慢得像蜗牛。
库模块的消费者规则
如果你的项目依赖了自己写的内部 library，记得在 library 的 build.gradle 里加上：
android {
defaultConfig {
consumerProguardFiles 'consumer-rules.pro'
}
}
这个文件里的规则会自动合并到主 app 的 ProGuard/R8 规则里。我在维护公司通用 SDK 时，曾经漏掉这一步，结果主工程混淆把 SDK 里的反射代码全混淆了，线上服务端 JSON 解析直接炸了——所以说，库一定要自己带好护身符。
命令行配置：用 gradlew 控制 R8
有时候你需要在 CI 或本地命令行里单独跑 R8 来分析问题。我常用的几招：
- 查看 R8 版本：
或者直接看 AGP 版本，R8 是捆绑在 AGP 里的。./gradlew :app:tasks --group 'build' | grep -i r8 - 强制生成混淆映射文件：
（全模式会移除更多无用类，但映射文件内容会略有不同）./gradlew :app:assembleRelease -Pandroid.enableR8.fullMode=false - 手动触发 ProGuard（不推荐）：
（这个 task 在 AGP 7.x 已移除，只是告诉你历史上有这么个东西）./gradlew :app:transformClassesAndResourcesWithProguardForRelease
./gradlew clean，不然可能碰到“明明改了规则但没生效”的灵异事件。
校验你的配置是否生效
环境搭好了，怎么确认 R8/ProGuard 真的在干活？我通常看三个文件：
- mapping.txt —— 原始类名 → 混淆后类名的映射，路径
build/outputs/mapping/release/ - seeds.txt —— 所有被
-keep保留的类/方法，没有它说明你的 keep 规则全丢了 - usage.txt —— 被移除的代码清单，可以检查有没有误删
在 build.gradle 里加个选项可以让这些文件更详细：
android {
buildTypes {
release {
proguardFiles ...
// 可选：打印更多日志
// 低版本用 -printmapping，R8 自动生成上面三个文件
}
}
}
我有个小习惯：每次改了规则后，先跑一次 release 构建，然后打开 seeds.txt 搜一下自己的主 Activity——如果不在里面，那肯定出问题了。
- ✔️ minifyEnabled = true 且位于 release 闭包内？
- ✔️ proguardFiles 顺序正确？
- ✔️ build 之后生成了 mapping.txt？
- ✔️ 主入口类出现在 seeds.txt 中？
- ✔️ usage.txt 里没有出现你需要的类？
避坑指南（都是我的亲身经历）
- 我曾经把
minifyEnabled写成了minifyEnabled = false——然后上线后包体积跟 debug 一样大，还被领导批评说“优化了个寂寞”。其实只要检查 APK 里的类名就能看出来：未被混淆的类名全是原始包名，一眼就能发现。 - 我曾经同时开启了 R8 全模式和旧的
proguard-android-optimize.txt——结果 R8 报了一堆 Warning 说某些优化规则冲突。后来我干脆删掉了proguard-android-optimize.txt，只保留默认proguard-android.txt，因为 R8 的全模式已经内置了大部分优化。 - 我曾经在 library 模块里写了
-keep class *——相当于告诉 R8 不要动任何一个类，那混淆就等于没开。正确的做法是只 keep 住对外暴露的接口和序列化类。