前言
代码混淆对于每个入门的 Android 工程师来说都不会太陌生，因为在编译正式版本时，这是一个必不可少的过程。而且使用代码混淆也相当简单，简单到只需要配置一句minifyEnabled true。但是你是否理解混淆的原理，如果问你代码混淆到底做了什么，你会怎么说？
目录
1. 混淆编译器
如果以混淆编译器来划分的话，Android 代码混淆可以分为以下两个时期：
- ProGuard：一个通用的 Java 字节码优化工具，由比利时团队 GuardSquare 开发
- R8：ProGuard 的继承者，专为 Android 设计，编译性能和编译产物更优秀
下图梳理了它们随着 Android Gradle Plugin 版本迭代相应做出的变更：
其中，混淆编译器的变更：
其中：DEX编译器的变更：
如果需要修正 Android Gradle Plugin 的默认行为，可以在gradle.properties中添加配置：
- 启用与禁用 R8
# 显式启用 R8 android.enableR8 = true 复制代码
# 1. 只对 Android Library module 停用 R8 编译器 android.enableR8.libraries = false # 2. 对所有 module 停用 R8 编译器 android.enableR8 = false 复制代码
- 启用与禁用 D8
# 显式启用 D8 android.enableD8 = true 复制代码
# 显式禁用 D8 android.enableD8 = false 复制代码
另外，如果在应用模块的 build.gradle 文件中设置useProguard = false，也会使用 R8 编译器代替 ProGuard。
2. 四大功能
ProGuard 与 R8 都提供了压缩（shrinker）、优化（optimizer）、混淆（obfuscator）、预校验（preverifier）四大功能：
- 压缩（也称为摇树优化，tree shaking）：从 应用及依赖项 中移除 未使用 的类、方法和字段，有助于规避 64 方法数的瓶颈
- 优化：通过代码 分析 移除更多未使用的代码，甚至重写代码
- 混淆：使用无意义的简短名称 重命名 类/方法/字段，增加逆向难度
- 预校验：对于面向 Java 6 或者 Java 7 JVM 的 class 文件，编译时可以把 预校验信息 添加到类文件中（StackMap 和 StackMapTable属性），从而加快类加载效率。预校验对于 Java 7 JVM 来说是必须的，但是对于 Android 平台 无效
使用 ProGuard 时，部分编译流程如下图所示：
- ProGuard 对 .class 文件执行代码压缩、优化与混淆
- D8 编译器执行脱糖，并将 .class 文件转换为 .dex文件
使用 R8 时，部分编译流程如下图所示：
- R8 将脱糖（Desugar）、压缩、优化、混淆和 dex（D8 编译器）整合到一个步骤
- R8 对 .class 文件执行代码压缩、优化与混淆
- D8 编译器执行脱糖，并将 .class 文件转换为 .dex文件
对比以下 ProGuard 与 R8 ：
- 共同点：1、开源
2、R8 支持所有现有 ProGuard 规则文件
3、都提供了四大功能：压缩、优化、混淆、预校验
- 不同点：1、ProGuard 可用于 Java 项目，而 R8 专为 Android 项目设计
2、R8 将脱糖（Desugar）、压缩、优化、混淆和 dex（D8 编译器）整合到一个步骤中，显着提高了编译性能
关于 D8 编译器
将 .class 字节码转化为 .dex 字节码的过程被称为 DEX 编译，最初是由DX 编译器完成。与 DX 编译器相比，新的 D8 编译器的编译速度 更快，输出的 .dex 文件 更小 ，却能保持相同乃至 更出色 的应用运行时性能
3. 使用示例
无论使用 R8 还是 ProGuard，默认不会启用压缩、优化和混淆功能。 这个设计主要是出于两方面考虑：一方面是因为这些编译时任务会增加编译时间，另一方面是因为如果没有充分定义混淆保留规则，还可能会引入运行时错误。因此，最好 只在应用的测试版本和发布版本中启用这些编译时任务，参考使用示例：
// build.gradle ... android { buildTypes { // 测试版本 preview { // 启用代码压缩、优化和混淆（由R8或者ProGuard执行） minifyEnabled true // 启用资源压缩（由Android Gradle plugin执行） shrinkResources true // 指定混淆保留规则文件 proguardFiles getDefaultProguardFile('proguard-android-optimize.txt'), 'proguard-rules.pro' } // 发布版本 release { minifyEnabled true shrinkResources true proguardFiles getDefaultProguardFile('proguard-android-optimize.txt'), 'proguard-rules.pro' } // 开发版本 debug{ minifyEnabled false } } ... } 复制代码
minifyEnabled：（默认情况下）启用代码压缩、优化、混淆与预校验shrinkResources：启用资源压缩proguardFiles、proguardFile：指定 ProGuard 规则文件，前者可以指定多个参数。下面两段配置的作用是一样的。
// 方式一： proguardFiles getDefaultProguardFile('proguard-android-optimize.txt'), 'proguard-rules.pro' // 方式二： proguardFile getDefaultProguardFile('proguard-android-optimize.txt') proguardFile 'proguard-rules.pro' 复制代码
前面提到了：无论使用R8还是ProGuard，压缩、优化和混淆功能都是 默认关闭的。通过以下配置可以灵活控制：
- 整体关闭
minifyEnabled false // 这行就没有效果了 proguardFiles getDefaultProguardFile('proguard-android-optimize.txt'), 'proguard-rules.pro' 复制代码
- 关闭压缩
-dontshrink 复制代码
- 关闭优化（R8 无效）
-dontoptimize 复制代码
注意：R8 不能关闭优化，也不允许修改优化的行为，事实上，R8 会忽略修改默认优化行为的规则。例如设置 -optimizations 和 -optimizationpasses后会得到编译时警告：
AGPBI: {"kind":"warning","text":"Ignoring option: -optimizations","sources":[{"file":"省略..."}],"tool":"D8"} AGPBI: {"kind":"warning","text":"Ignoring option: -optimizationpasses","sources":"省略..."}],"tool":"D8"} 复制代码
- 关闭混淆（建议在开发版本关闭混淆）
-dontobfuscate 复制代码
- 关闭预校验（对 Android 平台无效，建议关闭）
-dontpreverify 复制代码
4. ProGuard 规则文件
R8 延续了 ProGuard 使用规则文件修改默认行为的做法。在很多时候，规则文件也被称为混淆保留规则文件，这是因为该文件内定义的绝大多数规则都是和代码混淆相关的。事实上，文件内还可以定义代码压缩、优化和预校验规则，因此称为 ProGuard 规则文件比较严谨。
在上一节里，我们提到了使用proguardFiles和proguardFile指定 ProGuard 规则文件。对于任何一个项目，它的 ProGuard 规则文件有以下三种来源：
- 1、Android Gradle 插件在编译时，Android Gradle 插件会生成
proguard-android-optimize.txt、proguard-android.txt，位置在/build/intermediates/proguard-files/。这两个文件中除了注释之外，唯一的区别是前者启用了如下代码压缩，而后者关闭了代码压缩，如下所示：
# proguard-android-optimize.txt -optimizations !code/simplification/arithmetic,!code/simplification/cast,!field/*,!class/merging/* -optimizationpasses 5 -allowaccessmodification 相同部分省略... 复制代码
# proguard-android.txt -dontoptimize 相同部分省略... 复制代码
- 其中相同的那部分混淆规则中，下面这一部分是比较特殊的：
-keep class android.support.annotation.Keep -keep class androidx.annotation.Keep // 保留@Keep注解的类，保留...TODO -keep @android.support.annotation.Keep class * {*;} -keep @androidx.annotation.Keep class * {*;} // 保留@Keep修饰的方法 -keepclasseswithmembers class * { @android.support.annotation.Keep <methods>; } -keepclasseswithmembers class * { @androidx.annotation.Keep <methods>; } // 保留@Keep修饰的字段 -keepclasseswithmembers class * { @android.support.annotation.Keep <fields>; } -keepclasseswithmembers class * { @androidx.annotation.Keep <fields>; } // 保留@Keep修饰的构造方法 -keepclasseswithmembers class * { @android.support.annotation.Keep <init>(...); } -keepclasseswithmembers class * { @androidx.annotation.Keep <init>(...); } 复制代码
- 它指定了与
@Keep注解相关的所有保留规则，这里就解释了为什么使用@Keep修饰的成员不会被混淆了吧？ - 2、Android Asset Package Tool 2 (AAPT2)在编译时，AAPT2 会根据对 Manifest 中的类、布局及其他应用资源的引用来生成
aapt_rules.txt，位置在/build/intermediates/proguard-rules/debug/aapt_rules.txt。 例如，AAPT2 会为 Manifest 中注册的每个组件添加保留规则：
Referenced at [项目路径]/app/build/intermediates/merged_manifests/release/AndroidManifest.xml:19 -keep class com.have.a.good.time.MainActivity { <init>(); } 省略... 复制代码
- 在这里，AAPT2 生成了
MainActivity的保留规则，同时它还指出了引用出处：AndroidManifest.xml:19。这是因为 启动 Activity 的过程中，需要使用反射的方式实例化具体的每一个 Activity ，有兴趣可以看下ActivityThread#performLaunchActivity()->Instrumentation#newActivity() - 3、Module创建新 Module 时，IDE 会在该模块的根目录中创建一个
proguard-rules.pro文件。当然，除了这个自动生成的文件，还可以按需创建额外的规则文件。例如，下面的配置对 release 添加了额外的规则文件：
... android { ... buildTypes { release { minifyEnabled true proguardFiles getDefaultProguardFile('proguard-android-optimize.txt'), 'proguard-rules.pro' } } productFlavors { dev{ ... } release{ proguardFile 'release-rules.pro' } } } ... 复制代码
小结一下：
| 规则文件来源 | 描述 |
| Android Gradle 插件 | 在编译时，由 Android Gradle 插件生成 |
| AAPT2 | 在编译时，AAPT2 根据对应用清单中的类、布局及其他应用资源的引用来生成保留规则 |
| Module | 创建新 Module 时，由 IDE 创建，或者另外按需创建 |
如果将 minifyEnabled 属性设为 true，ProGuard 或 R8 会将来自上面列出的所有可用来源的规则组合在一起。为了看到完整的规则文件，可以在proguard-rules.pro 中添加以下配置，输出编译项目时应用的所有规则的完整报告：
-printconfiguration build/intermediates/proguard-files/full-config.txt 复制代码
5. 组件化混淆
在组件化的项目中，需要注意应用 Module 和 Library Module 的行为差异和组件化的资源汇合规则，总结为以下几个重点：
- 编译时会依次对各层 Library Module进行编译，最底层的 Base Module 会最先被编译为 aar 文件，然后上一层编译时会将依赖 Module 输出的 aar 文件/ jar 文件解压到模块的 build 中相应的文件夹中
- App Module 这一层汇总了全部的 aar 文件后，才真正开始编译操作
- 后编译的 Module 会覆盖之前编译的 Module 中的同名资源
使用较高版本的 Android Gradle Plugin，不会将汇总的资源放置在 exploded-aar文件夹。即便如此，Lib Module 的资源汇总到 App Module 的规则是一样的。
我们通过一个简单示例测试不同配置下的混淆结果：
| 配置一 | 配置二 | 配置三 | 配置四 | |
| App Module 开启混淆 | X | X | √ | √ |
| Base Module 开启混淆 | X | √ | X | √ |
将构建的 apk 包拖到 Android Studio 面板上即可分析 Base 类混淆结果，例如配置一的结果：
全部测试结果如下：
| 配置一 | 配置二 | 配置三 | 配置四 | |
| App Module 开启混淆 | X | X | √ | √ |
| Base Module 开启混淆 | X | √ | X | √ |
| （结果）Base 类是否被混淆 | X | X | √ | √ |
可以看到，混淆开启由 App Module 决定， 与Lib Module 无关。
现在我们分别在 Lib Module 和 App Module 的 proguard-rules.pro中添加 Base 类的混淆保留规则，并在 build.gradle中添加配置文件，测试 Base 类是否能保留：
-keep class com.rui.base.Base 复制代码
测试结果如下：
| 配置位置 | Lib Module | App Module |
| （结果）Base 类是否保留 | X | √ |
可以看到：（默认情况）混淆规则以 App Module 中的混淆规则文件为准。
这里就引入两种主流的组件化混淆方案：
- 在 App Module 中设置混淆规则
这种方案将混淆规则都放置到 App Module 的proguard-rules.pro中，最简单也最直观，缺点是移除 Lib Module 时，需要从 App Module 中移除相应的混淆规则。尽管多余的混淆规则并不会造成编译错误或者运行错误，但还是会影响编译效率。
很多的第三方 SDK，就是采用了这种组件化混淆方案。在 App Module 中添加依赖的同时，也需要在proguard-rules.pro中添加专属的混淆规则，这样才能保证release版本正常运行。
- 在 App Module 中设置公共混淆规则，在 Lib Module 中设置专属混淆规则
这种方案将专属的混淆规则设置到 Lib Module 的proguard-rules.pro，但是根据前面的测试，在 Lib Module 中设置的混淆规则是不生效的。为了让规则生效，还需要在 Lib Module 的build.gradle中添加以下配置：
... android{ defaultConfig{ consumerProguardFiles 'consumer-rules.pro' } } 复制代码
其中consumer-rules.pro文件：
-keep class com.rui.base.Base 复制代码
测试结果表明，Base 类已经被保留了。这种使用consumerProguardFiles的方式有以下几个特点：
consumerProguardFiles只对 Lib Module 生效，对 App Module 无效consumerProguardFiles会将混淆规则输出为proguard.txt文件，并打包进 aar 文件- App Module 会使用 aar 文件中的
proguard.txt汇总为最终的混淆规则，这一点可以通过前面提到的-printconfiguration证明
6. 总结
- ProGuard 是 Java 字节码优化工具，而 R8 是专为 Android 设计的，编译性能和编译产物更优秀；
- ProGuard 与 R8 都提供了四大功能：压缩、优化、混淆和预校验。ProGuard 主要是对 .class 文件执行代码压缩、优化与混淆，再由 D8 编译器执行脱糖并转换为 .dex 文件。R8 将压缩、优化、混淆、脱糖和 dex 整合为一个步骤；
- ProGuard 规则文件有三种来源：Android Gradle 插件、AAPT2、Module；
- 默认情况下，混淆规则以 App Module 中的混淆规则文件为准，使用 consumer-rules.pro 文件可以设置 Lib Module 专属混淆规则。
