R8与ProGuard简介：背景、作用与区别
我是老张，干了快十年安卓开发。说实话，刚入行那会儿我连混淆是什么都不知道。
直到有一次，我参与的一个电商App刚上线一周，就在某第三方市场上被人扒了代码。登录逻辑、支付密钥硬编码，全裸奔。嗯，从那以后，我再也不敢小看混淆这步了。
今天咱们先聊聊ProGuard和R8的来龙去脉。你想想看，一个APK里藏着多少敏感信息？接口地址、加密算法、核心逻辑……不处理一下，跟直接送人没区别。
为什么需要代码混淆？
混淆的本质，说白了就是给你的源码“化妆”。让逆向的人看不懂，但你自己能跑。
- 保护源码：把有意义的类名、方法名改成a、b、c这种
- 减小包体积：去掉没用的代码，缩短名字长度
- 优化性能：内联短方法、合并重复代码
- 降低破解风险：增加逆向分析的门槛
核心目标：以最小的性能代价，换取最大的代码保护效果。
ProGuard：曾经的王者
ProGuard是Java生态里的老牌工具，早在安卓之前就有了。它主要干三件事：
- 混淆（Obfuscate）：改名
- 压缩（Shrink）：删无用代码
- 优化（Optimize）：改字节码
- 预校验（Preverify）：检查就绪
用得最多的其实是混淆和压缩。我早期接手的项目，几乎都在用ProGuard。但有一个痛点：慢。特别是大项目，一次Release构建能跑好几分钟。
我的习惯：Debug阶段我一般关掉混淆，只开压缩。等要打Release包了，再开完整混淆。这样能省不少开发时间。
R8：谷歌的接班人
R8是谷歌在Android Studio 3.4里引入的，说白了就是ProGuard的升级版。它完全兼容ProGuard的配置规则——你原来写的-keep规则，直接拿过来用，不改。
但R8快得多，因为它直接走DEX字节码，不需要先转成Java字节码再转DEX。我实测过，同样配置下，R8比ProGuard快了接近3倍。
一句话总结：ProGuard是老司机，R8是高铁。速度更快，功能更强。
ProGuard和R8的对比
| 维度 | ProGuard | R8 |
|---|---|---|
| 出现时间 | 2002年 | 2019年（Android Studio 3.4） |
| 速度 | 较慢（Java字节码处理） | 快2~3倍（直接DEX处理） |
| 默认工具 | AGP 3.4之前 | AGP 3.4及之后 |
| 配置兼容 | 使用.pro文件 | 完全兼容.pro文件 |
| 资源压缩 | 不支持 | 支持（配合AGP） |
| 优化级别 | 中 | 高（内联、合并更强） |
| 维护状态 | 停止更新 | 持续迭代 |
避坑提示：我见过有人为了兼容性强写ProGuard规则，结果R8反而不认。其实R8对-keep规则解析更严格。如果你从ProGuard迁移到R8，务必重新审查所有keep规则，特别是那些通配符。
R8与ProGuard的核心工作流
下面这张图，我画的是标准混淆流程。你一看就明白：
R8相比ProGuard的独特优势
R8不只是快，它还有一些杀手锏：
- 资源压缩：直接识别未使用的资源文件，一并干掉。ProGuard做不到这一点
- 更激进的优化：比如把一些简单的getter/setter直接内联，减少方法数
- 更好的Lambda支持：对Kotlin和Java 8+的语法糖优化更彻底
- 默认开启：从AGP 3.4开始，只要你开启minifyEnabled，默认走R8
我的经验：如果你想手动切换回ProGuard，可以在gradle.properties里写android.enableR8=false。但我建议你别这么干——除非你遇到了R8的bug。我这两年都没遇到过需要回退的情况了。
什么时候必须保留某个类/方法？
混淆是好事，但有些东西不能动。比如：
- 反射调用的类和方法
- JNI/NDK的本地方法
- JSON解析的Java Bean
- 第三方SDK的入口
- Android组件（Activity/Service等）
我曾经…在一个项目里忘了保留Gson的解析类，结果运行时疯狂崩溃。查了两天才发现是混淆把Bean类的字段名改掉了。所以，-keep规则一定要写全，特别是那些被框架、库反射调用的类。
总结
ProGuard是老牌功臣，R8是新时代的主力军。对我们开发者来说，核心任务不是二选一，而是写好混淆规则。
你想想看，一个完整的混淆配置，既要去掉无用代码，又要保留核心逻辑，还要确保不崩。这活儿不简单，但值得花时间做好。