从 D8 Dexing 到 R8 的代码收缩与字节码混淆机制追踪
D8 和 R8 位于 Android 构建管线的字节码后半段：编译器先把 Kotlin/Java 源码变成 JVM .class，然后 D8/R8 把这些 class 转成 Android Runtime 能执行的 DEX。
D8 是 dexer，核心职责是把 Java bytecode 转成 dex bytecode，并处理 desugaring。R8 是 shrinker/optimizer/minifier，它在 release 场景中接管更复杂的全程序分析：删除无用代码、优化控制流、内联、重命名，再输出优化后的 DEX。
可以把 D8 想象成语言翻译员，把 JVM 方言翻译成 ART 方言；R8 则像一个极其激进的编辑，会删掉未引用章节、合并重复表达、缩短名字，但必须在不改变程序语义的前提下完成。
D8：从 class 到 dex
Android 设备运行的不是 JVM class 文件，而是 DEX：
Kotlin/Java source
|
v
kotlinc / javac
|
v
.class bytecode
|
v
D8
|
v
classes.dex
DEX 与 class 的差异不只是文件格式。DEX 使用寄存器式指令集，适配 Android Runtime 的加载和执行模型；多个 class 会被合并进一个或多个 .dex 文件。
Android 支持的 Java 语言特性也需要 desugaring：
lambda / default interface method / try-with-resources
|
v
desugar to lower-level bytecode pattern
|
v
dex
这就是为什么某些 Java/Kotlin 特性在 Android 低版本上仍能运行：它们在构建期被改写成旧运行时能理解的形式。
R8：全程序收缩与优化
release 构建启用 minify 后，R8 会做更大的图分析：
Program classes + Library classes + Keep rules
|
v
Reachability analysis
|
+-- reachable -> keep
+-- unreachable -> remove
v
Optimization
|
+-- inline
+-- class merging
+-- constant propagation
+-- access modification
v
Minification
|
v
optimized dex + mapping.txt
R8 的入口不是“所有类都保留”，而是从入口点、Android framework 回调、反射保留规则、manifest 组件、JNI 等根节点出发，计算可达图。不可达的类和方法会被删除。
这也是 keep rules 的本质：告诉 R8 某些边在静态字节码里看不见，但运行时会发生。
为什么反射会破坏静态分析
例如：
val clazz = Class.forName("club.zerobug.PaymentService")
val instance = clazz.getDeclaredConstructor().newInstance()
如果类名是字符串拼出来的，R8 很难静态知道 PaymentService 必须保留。没有 keep rule 时，它可能删除这个类，或把类名混淆掉，导致运行时崩溃。
正确方向不是关掉 R8，而是精确声明运行时入口：
-keep class club.zerobug.PaymentService {
public <init>();
}
keep 规则越粗，优化空间越小；规则越精确，产物越小、优化越充分。
mapping.txt 是线上排障的密码本
混淆后，崩溃堆栈可能变成：
at a.b.c(Unknown Source:12)
mapping.txt 记录原始符号和混淆后符号的映射。发布 release 时必须保存对应版本 mapping，并上传到崩溃平台。没有 mapping 的 release 包，线上堆栈几乎不可读。
club.zerobug.payment.PaymentService -> a.b:
void charge(int) -> c
mapping 是构建产物的一部分，应当和 APK/AAB 版本绑定管理。
D8/R8 与增量构建
Debug 构建通常更关注快速 dexing，Release 构建更关注最终体积和性能。D8 支持按 class 粒度的中间 dex，使改动少量 class 时不必重做全部 dex。R8 因为做全程序优化，对增量更敏感，release 构建天然更重。
这解释了工程实践中的差异：
- debug 关闭 minify，缩短本地反馈。
- release 开启 R8，换取体积、启动、运行性能和代码保护。
- 复杂反射/序列化库必须维护 keep rules。
- 自定义字节码插桩要保证输出稳定，否则会放大 dex/r8 重跑范围。
工程风险与观测清单
从 D8 Dexing 到 R8 的代码收缩与字节码混淆机制追踪 一旦进入真实 Android 工程，最大的风险不是单个 API 写错，而是构建行为失去可解释性：一次小改动触发大面积重编译，CI 偶发超时，缓存命中却产物不可信，或者发布后才发现某条 variant 管线没有被覆盖。
因此，学习这个主题时要同时建立两套模型：一套解释底层机制，一套解释工程风险、观测信号、回滚策略和审计边界。前者让你知道系统为什么这样运行，后者让你在生产环境里能证明它确实按预期运行。
关键风险矩阵
| 风险点 | 触发条件 | 直接后果 | 观测方式 | 缓解策略 |
|---|---|---|---|---|
| 输入声明缺失 | 构建逻辑读取未声明文件或环境变量 | UP-TO-DATE 或缓存结果错误 | 使用 --info 和 Build Scan 查看输入变化 |
把所有影响输出的状态建模为 @Input 或 Provider |
| 绝对路径泄漏 | 任务 key 包含本机路径 | CI 与本地缓存无法复用 | 对比不同机器的 cache key 变化 | 使用相对路径敏感性和路径归一化 |
| 配置期副作用 | build script 执行 I/O、Git、网络请求 | 任意命令都变慢，configuration cache 失效 | 执行 help --scan 观察配置期耗时 |
把副作用移动到任务动作并声明输入输出 |
| Variant 污染 | 对所有 variant 注册重型任务 | debug 构建被 release 逻辑拖慢 | 查看 realized tasks 和 task timeline | 使用 selector 精确匹配目标 variant |
| 权限外溢 | 插件或脚本读取 CI secret、用户目录 | 构建不可复现，存在供应链风险 | 审计构建日志和环境变量访问 | 使用最小权限和显式 secret 注入 |
| 并发竞争 | 多个任务写同一输出目录 | 产物互相覆盖或偶发失败 | 检查 overlapping outputs 报告 | 每个任务拥有独立输出目录 |
| 缓存污染 | 不可信分支向远程缓存 push | 全团队复用错误产物 | 统计 remote cache push 来源 | 只允许受信任 CI 写入远程缓存 |
| 回滚困难 | 构建逻辑与业务变更混在一起 | 发布失败时无法快速定位 | 变更审计和构建 scan 对比 | 构建逻辑独立提交、独立验证 |
| 降级缺口 | 新 Gradle/AGP API 无兜底策略 | 升级失败后阻塞全线开发 | 记录兼容矩阵和失败任务 | 保留可回滚版本和迁移开关 |
| 资源释放遗漏 | 自定义任务打开文件句柄或进程未关闭 | Windows/CI 上清理失败或锁文件 | 观察 daemon 日志和文件锁错误 | 使用 Worker API 或 try/finally 释放资源 |
需要持续观测的指标
- 配置阶段耗时是否随模块数量线性或超线性增长。
- 单次本地 debug 构建的关键路径任务是谁。
- CI clean build 与 incremental build 的耗时差距。
- 远程 Build Cache 的 hit rate、miss 原因和下载耗时。
- Configuration Cache 的命中率和失效原因。
- Kotlin/Java 编译任务是否被不相关资源或依赖变化触发。
- 资源合并、DEX、R8、打包任务是否在小改动后全量重跑。
- 自定义插件是否提前实现了无关任务。
- 构建日志中是否出现未声明输入、重叠输出、deprecated API。
- 发布产物是否能追溯到唯一的源码提交、依赖锁和构建扫描。
- 失败是否可稳定复现，还是只在特定机器、特定并发下出现。
- 变更是否影响开发构建、测试构建和发布构建三条路径。
回滚与降级策略
- 构建逻辑变更与业务代码变更分开提交，便于二分定位。
- Gradle、AGP、Kotlin、JDK 升级必须保留兼容矩阵和回滚版本。
- 新插件能力先只接入一个低风险模块，再扩大到全工程。
- 远程缓存先 pull 后 push，确认产物稳定后再允许 CI 写入。
- 新增插桩、生成代码、资源处理逻辑必须提供开关。
- 发布构建失败时，优先回滚构建逻辑版本，而不是清空所有缓存碰运气。
- 对 CI 超时设置分阶段日志，确认卡在配置、依赖解析还是任务执行。
- 对不可恢复的构建产物变更记录迁移步骤，避免开发者本地状态残留。
最小验证矩阵
| 验证场景 | 命令或动作 | 期望信号 |
|---|---|---|
| 空任务配置成本 | ./gradlew help --scan |
配置期没有无关重任务 |
| 本地增量构建 | 连续执行同一 assemble 任务 | 第二次大量任务 UP-TO-DATE |
| 缓存复用 | 清理输出后启用 build cache | 可缓存任务出现 FROM-CACHE |
| Variant 隔离 | 分别构建 debug/release | 只出现目标 variant 相关任务 |
| CI 可复现 | 干净工作区执行 release 构建 | 不依赖本机隐藏文件 |
| 依赖稳定 | 执行 dependencyInsight | 版本选择可解释，无动态漂移 |
| 配置缓存 | --configuration-cache 连跑两次 |
第二次复用配置缓存 |
| 发布审计 | 记录 scan、mapping、签名信息 | 产物可追溯、可回滚 |
审计问题
- 这段构建逻辑是否有明确所有者，还是散落在多个模块脚本里。
- 它是否读取了没有声明为输入的文件、环境变量或系统属性。
- 它是否在配置阶段执行了本应放到任务动作里的工作。
- 它是否对所有 variant 生效，还是只应该对某些 variant 生效。
- 它是否可以在没有网络、没有本地 IDE 状态的 CI 中运行。
- 它是否把权限、密钥、签名文件路径写进了仓库。
- 它是否破坏了并发执行，例如多个任务写同一个目录。
- 它是否能在失败时输出足够日志，帮助定位根因。
- 它是否能通过一个开关降级，避免阻塞全工程构建。
- 它是否有最小复现样例或 TestKit/集成测试覆盖。
- 它是否会让下游模块承担不必要的依赖或任务成本。
- 它是否能在升级 Gradle/AGP 后继续工作，还是依赖内部 API。
反模式清单
- 用
clean掩盖输入输出声明错误。 - 用
afterEvaluate修补本可以用 Provider 表达的依赖关系。 - 用动态版本解决依赖冲突，却让构建不可复现。
- 把所有公共配置塞进一个巨型 convention plugin。
- 在 debug 构建默认开启 release 级别的重型优化。
- 在任务动作里读取
project或全局 configuration。 - 在多个任务中共享同一个临时目录。
- 缓存命中率异常时只重启 CI，不分析 miss reason。
- 把构建扫描链接当作可选附件，而不是性能回归证据。
- 用本地 IDE 成功运行证明 CI 发布链路安全。
最小实操脚本
./gradlew help --scan
./gradlew :app:assembleDebug --scan --info
./gradlew :app:assembleDebug --build-cache --info
./gradlew :app:assembleDebug --configuration-cache
./gradlew :app:dependencies --configuration debugRuntimeClasspath
./gradlew :app:dependencyInsight --dependency <module> --configuration debugRuntimeClasspath
这组命令覆盖配置期、执行期、缓存、配置缓存和依赖解析五条主线。任何 从 D8 Dexing 到 R8 的代码收缩与字节码混淆机制追踪 相关的改动，都应该能用其中至少一条命令解释它带来的行为变化。