解读

国内面试官问“怎么用 ProGuard/R8 混淆”并不是想听“打开 minifyEnabled true”这么简单，而是考察四条线：

1. 混淆链完整度：从 Gradle 配置、规则编写、mapping 管理到上线后回溯；
2. 安全纵深：如何让反编译者“看不懂、改不动、跑不通”；
3. 业务兼容性：不因为过度混淆导致反射、JNI、SDK、热修、组件化、插件化崩溃；
4. 实战落地：国内多渠道包、加固厂商、合规审计、崩溃平台对 mapping.txt 的依赖。

回答必须体现“能抗逆向、能保稳定、能回溯源码”。

知识点

1. ProGuard 与 R8 差异：R8 是 AGP 3.6+ 默认，兼容 ProGuard 语法但算法更激进，合并压缩+优化+混淆+Dex 重写四阶段一体。
2. 混淆维度：名称混淆（类、方法、字段）、控制流扁平化、反射隐藏、字符串加密、资源名混淆、行号抹除、调试信息剔除、注解可见性降级。
3. 规则优先级：-keep 族 > -keepclassmembers > -keepnames；-allowoptimization、-assumenosideeffects 可配合 AAR 内嵌规则。
4. 国内特殊场景：微信/支付宝 SDK 要求保持特定签名；热修 Tinker、Sophix 要求 keep Application 及 loader 组件；加固（乐固、爱加密）后需关 R8 的“水平合并”防二次 Dex 结构破坏。
5. 回溯与合规：mapping.txt 必须随包入库，崩溃平台（Bugly、Firebase、Sentry）需自动还原；工信部 164 号文要求“提供可追溯源码材料”，mapping 属于关键审计证据。
6. 性能权衡：过度 keep 会膨胀 DEX；过度优化会触发 JIT 编译异常；R8 的“全程序优化”可能把枚举转整型，导致 Native 层 valueOf 崩溃。

答案

线上实战采用“R8 + 三段式规则 + 二次加固”方案，步骤如下：

1. 开启开关 release 闭包统一配置：

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

   说明：shrinkResources 依赖 minifyEnabled，先删代码再删资源，APK 可再小 5-8%。

2. 规则分层 a. 基础规则（proguard-rules.pro）

   # 保留四大组件、View 构造函数、Parcelable、枚举
   -keep public class * extends android.app.Activity
   -keepclassmembers class * implements android.os.Parcelable {
       public static final ** CREATOR;
   }
   -keepclassmembers enum * {
       public static **[] values();
       public static ** valueOf(java.lang.String);
   }
   # 抹除日志
   -assumenosideeffects class android.util.Log {
       public static int v(...);
       public static int d(...);
   }
   # 行号调试信息全删
   -renamesourcefileattribute SourceFile
   -keepattributes SourceFile,LineNumberTable
   

   说明：keepattributes 只保留崩溃栈可读的最小信息，同时把文件名统一成 SourceFile，增加逆向难度。

   b. SDK 白名单（proguard-sdk.pro） 将第三方 AAR 内嵌规则自动合并；若 SDK 无规则，则手动补充，例如：

   -keep class com.alipay.** {*;}
   -keepclassmembers class **$Stub {*;}
   

   c. 业务灰度规则（proguard-biz.pro） 组件化项目通过 gradle 脚本动态注入：

   if (project.name.contains("module_pay")) {
       proguardFile file("pay/proguard-pay.pro")
   }
   

   只对内部模块可见的 DTO、Event 做混淆，对外暴露的接口 keep。

3. 字符串加密（可选） R8 本身不做字符串加密，可插桩方案： 在 transformClasses 阶段用 ASM 把常量池里的明文字符串替换为加密数组，运行时通过 JNI 解密。注意 keep 解密 native 方法，防止被优化掉。

4. 资源混淆 启用 AndResGuard 或 AAPT2 的 --shorten-resource-names，把 res/drawable/ic_launcher 变成 r/a/a，降低可读性；同时关 R8 的“资源压缩”避免与 AndResGuard 冲突。

5. mapping 管理 CI 打包时把 mapping.txt 重命名为 ${variantName}-${versionName}-${gitCommitId}.txt，上传到私有 Nexus 仓库；崩溃平台通过符号表 API 自动拉取，研发无人工介入。

6. 加固与重签名 国内上架应用商店需先走加固：乐固→上传 APK→下载加固包→重新对齐 zipalign→V2/V3 签名。加固后禁用 R8 的“Dex 水平合并”选项，防止二次优化破坏壳结构：

   android.enableR8.fullMode=false
   

7. 验证 a. 反编译验证：用 jadx-gui 打开，确认核心业务类名变为 a.b.c，方法名为 a，字符串常量池无敏感 URL。 b. 稳定性验证：跑 Monkey 10 万事件 + 遍历全部反射调用，零崩溃。 c. 性能验证：集成前后包体积下降 32%，启动耗时无回归；使用 perfetto 抓取，无额外 16 ms 掉帧。

通过以上七步，既把反编译者的阅读成本拉到最高，又保证国内渠道合规、热修兼容、崩溃可回溯。

拓展思考

1. Jetpack Compose 与 R8 协同：Compose 编译器生成大量 lambda 和 remembered 调用，R8 的“lambda 合并”可能把跨 Composable 的 lambda 合并成同一类，导致重组时捕获错误。解决方案：keep 所有带 @Composable 注解的方法参数名，关闭 lambda 合并优化。
2. Kotlin 协程调试：默认协程堆栈通过 kotlinx.coroutines.internal 包名反射，混淆后需 keep 相关类，否则调试时堆栈断层。
3. 动态特性模块（Dynamic Feature）（国内叫“插件化”）：R8 在 feature 包与 base 包之间做跨模块优化，可能把 base 的 public API 内联到 feature，导致插件无法独立更新。需使用 -keepmodifiers interface 及 -dontoptimize 局部关闭。
4. 隐私合规新动向：工信部 164 号文要求“提供可追溯源码材料”，mapping.txt 已成为合规审计证据。企业需建立 mapping 归档与访问权限体系，防止泄露被逆向者利用。
5. 未来替代：Google 正在推“App Bundle + 云端符号表”，国内华为、OPPO 商店已跟进。开发者需提前把 mapping 上传到云端，崩溃回溯将完全脱离本地文件，CI/CD 流程需预留接口。