📚 课程目录第2章 R8配置入门

R8配置入门：build.gradle 里的那几行到底在干啥

做 Android 逆向的兄弟都知道，App 一上混淆，崩溃堆栈就变得跟天书似的。但你要连混淆都不开，那逆向就太没挑战了。所以今天咱们就来聊聊 R8 的配置——说白了，就是 build.gradle 里那几行不起眼的代码，到底怎么把代码拧成麻花，又怎么让你能在出事之后还能找到回来的路。

一句话总结：minifyEnabled 是总开关，proguardFiles 是规则清单。这两个没搞对，后面所有复现技巧都是白扯。

1. 启用 R8：就这一行，但别小看它

先看最基础的部分。在模块的 build.gradle（注意是 app 级别的，不是根目录那个）里，你见过这个：

android {
    buildTypes {
        release {
            minifyEnabled true
            proguardFiles getDefaultProguardFile('proguard-android-optimize.txt'),
                          'proguard-rules.pro'
        }
    }
}

minifyEnabled true 就是告诉 Gradle：“这个版本给我上 R8。” 嗯，它看的是布尔值，不是版本号。从 AGP 3.4.0 开始，默认的代码缩减器已经从 ProGuard 切成了 R8。所以不管你以前用没用过，现在只要你设了 true，R8 就会出手。

我个人习惯，debug 版本也偶尔会开一下 minify，但不是为了混淆，是为了提前暴露 R8 合并代码时可能引发的异常——比如某些反射代码被剪掉了。你想想看，如果等到发版线上才发现，那就晚了。

2. proguardFiles：不是给 ProGuard 用的文件名，是规则清单

名字容易误解，叫 proguardFiles 但实际上 R8 也认它。这里是一个列表，可以传多个文件。上面代码里写了两项：

getDefaultProguardFile('proguard-android-optimize.txt') —— 这是 Android SDK 自带的默认优化规则，路径在 ${ANDROID_HOME}/tools/proguard/ 底下。它包含了基本的 keep、不混淆系统类的规则。
proguard-rules.pro —— 你自己的规则文件。放在模块根目录下，如果没有就创建一个空文件也行。

我曾经遇到过一个 case：团队新人直接在默认规则文件里乱改，结果导致所有第三方库的 keep 规则失效，线上崩溃堆栈全是 a.a.a 那种。嗯，从那以后我每次都会检查 proguardFiles 的顺序和个数——默认文件放最前面，自己的规则放后面，因为后面的覆盖前面的。

3. 表格说话：R8 配置 vs 老 ProGuard 配置

很多人还留着 ProGuard 那套记忆，我来列个对比，一眼就能看明白：

对比项	R8（当前推荐）	ProGuard（AGP 3.4 前）
启用方式	`minifyEnabled true` 自动使用 R8	`minifyEnabled true` + `useProguard true`
规则文件格式	同 ProGuard 规则语法，兼容	ProGuard 规则语法
默认规则文件	`proguard-android-optimize.txt`	`proguard-android.txt`
是否支持优化	内建，且默认开启优化	需额外配置 `-optimizationpasses`
映射文件输出	自动生成 `mapping.txt`	自动生成 `mapping.txt`

注意表格里最下面那一行——mapping.txt。这东西是你日后能不能复现崩溃的关键。没有它，你看到混淆后的类名 a.b.c 只能干瞪眼。

小技巧：可以在 build.gradle 里加一行配置，让每次 release 构建都把 mapping 文件拷贝到项目外备份：
tasks.whenTaskAdded { task -> if (task.name == 'packageRelease') { ... } }
具体实现网上很多，但核心就一点——千万别只靠默认路径，因为 Clean 一下可能就没了。

4. 不止两个文件：你还可以加更多规则文件

很多项目依赖多个第三方库，每个库可能自带 consumer-rules.pro 或通过 proguardFiles 指定额外规则。你可以在 buildTypes 里继续追加：

release {
    minifyEnabled true
    proguardFiles(
        getDefaultProguardFile('proguard-android-optimize.txt'),
        'proguard-rules.pro',
        'extra-rules.pro'
    )
}

甚至对不同 flavor 指定不同文件：

flavorDimensions "version"
productFlavors {
    paid {
        dimension "version"
        proguardFiles 'paid-rules.pro'
    }
    free {
        dimension "version"
        proguardFiles 'free-rules.pro'
    }
}

我见过一个项目，光 proguardFiles 列表就有 5 个文件，互相覆盖导致规则冲突。说白了，规则文件越多，排查越难。我的建议是：只放一个全局自己的规则文件，其余依赖库的 keep 规则用 library 自己的 consumer-rules.pro 就好，不要全都塞到主项目里。

5. 核心知识图谱：R8 配置决策流

下面这张 SVG 图能帮你快速理清配置时的决策路径——从入口到输出文件，每一步的常见坑我都标了：

你看，从 minifyEnabled true 出发，R8 会加载默认规则和你的自定义规则，然后生成三个关键产出：mapping.txt（反混淆必需）、seeds.txt（哪些类/方法没被混淆，方便确认 keep 是否生效）、以及无用代码报告（帮你看哪些代码被删了）。

6. 避坑指南：我曾经踩过的三个坑

坑一：debug 版本也开了 minifyEnabled

当然可以，但你要在 debug 的 buildTypes 里额外配置 proguardFiles 和 mapping 输出。我以前图省事直接复制 release 的配置，结果 debug 运行卡死在启动页，排查了三个小时才发现是某个 keep 规则没写全。所以，debug 开混淆可以，但请单独维护一套 debug 规则。
坑二：默认规则文件被替换

有次我为了性能优化，把 getDefaultProguardFile('proguard-android-optimize.txt') 换成了 'my-optimized.txt'——自以为能定制更激进的优化。结果 App 运行时大量反射调用直接 NoSuchMethodException。后来才明白，默认规则里有很多 Android Framework 层的 keep 规则你是不知道的。别随便换，默认文件永远放第一个。
坑三：混淆后崩溃，手头没有 mapping.txt

这个最痛。有个版本我改了持续集成脚本，结果把所有 release 产物的 mapping 文件都删了。等线上崩溃收敛到某个 NullPointerException 时，堆栈全是 com.a.b.c$d.e() 这种，完全没法还原。那次之后我强制在 CI 流程里把 mapping 上传到云存储，并且本地也保留一份带版本号的压缩包。

警告：R8 的默认行为是 删除所有未使用的代码、资源、并且重新命名类和方法。如果你用了 getDefaultProguardFile('proguard-android-optimize.txt') 还会做内联和常量折叠。这些优化本身没问题，但一旦你某处用到了反射、JNI 回调、Gson/自定义注解，就必须在 proguard-rules.pro 里显式 -keep 住它们。

7. 更进一步：R8 的一些隐式配置选项

除了明面上的 minifyEnabled 和 proguardFiles，你还可以在 gradle.properties 里调 R8 的行为（不常用，但关键 debug 场景会用到）：

# 禁用 R8 全树优化（某些情况下可能导致崩溃）
android.enableR8.fullMode=false

# 允许 R8 输出更详细的日志
android.enableR8.debug=true

为什么会出现 fullMode=false 的需求？因为 R8 的全模式优化会对类层次结构进行合并和重构——曾经我遇到一个 Bug：某个基类被 R8 内联进了子类，然后子类又被继承了另一个不在 keep 列表的类，直接导致 NoClassDefFoundError。调回非全模式就好了。当然，妥协会导致 APK 体积变大一点，但稳定优先。