关于Android代码混淆,你了解多少?
作者:互联网
目录
- 混淆编辑器介绍
- 功能说明
- 编译流程
- 二者区别
- 使用说明
- 规则文件说明
- 组件化混淆
1. 混淆编译器
Android 代码混淆历史时期可以根据使用何种混淆编辑器分为以下两个时期:
- ProGuard:一个通用的 Java 字节码优化工具
- R8:ProGuard 的继承者,专为 Android 设计,编译性能和编译产物更优秀
随着 Android Gradle Plugin 版本迭代相应做出的变更:
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-jd4dRi1m-1618297528736)(https://upload-images.jianshu.io/upload_images/25509081-c3c824afe39ef9af?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)]
Android Gradle Plugin 版本迭代
若需修正 Android Gradle Plugin 的默认行为,可以在gradle.properties中添加配置:
/*
* R8
*/
// 显式启用 R8
android.enableR8 = true
// 只对 Android Library module 停用 R8 编译器
android.enableR8.libraries = false
// 对所有 module 停用 R8 编译器
android.enableR8 = false
/*
* D8
*/
// 显式启用 D8
android.enableD8 = true
// 显式禁用 D8
android.enableD8 = false
// 另外,如果在应用模块的 build.gradle 文件中设置useProguard = false,也会使用 R8 编译器代替 ProGuard。
关于 D8 编译器说明:DX 编译器的升级版( DEX 编译过程:将 .class 字节码转化为 .dex 字节码的过程)。与 DX 编译器相比,D8编译器编译速度**「更快」,输出的 .dex 文件「更小」** 、应用运行时性能**「更高」**。
2. 功能说明
ProGuard 与 R8 都提供了混淆编辑的四大功能:
- 压缩(shrinker):也称摇树优化,tree shaking,从**「应用及依赖项」** 中移除**「未使用」** 的类、方法和字段,有助于规避 64 方法数的瓶颈
- 优化(optimizer):通过代码 「分析」 移除更多未使用的代码,甚至重写代码
- 混淆(obfuscator):使用无意义的简短名称 「重命名」 类/方法/字段,增加逆向难度
- 预校验(preverifier):对于面向 Java 6 或者 Java 7 JVM 的 class 文件,编译时可以把 「预校验信息」 添加到类文件中(StackMap 和 StackMapTable属性),从而加快类加载效率。预校验对于 Java 7 JVM 来说是必须的,但是对于 Android 平台无效
3. 编译流程
3.1 ProGuard编译流程
- ProGuard 对 .class 文件执行代码压缩、优化与混淆
- D8 编译器执行脱糖,并将 .class 文件转换为 .dex文件
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-CTxiQinE-1618297528742)(https://upload-images.jianshu.io/upload_images/25509081-2bf9cd98307694fa?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)]
3.2 R8编译流程
- 「R8 将脱糖(Desugar)、压缩、优化、混淆和 dex(D8 编译器)整合到一个步骤」
- R8 对 .class 文件执行代码压缩、优化与混淆
- D8 编译器执行脱糖,并将 .class 文件转换为 .dex文件
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-66HSewwL-1618297528743)(https://upload-images.jianshu.io/upload_images/25509081-1b6c4ad5fcfa7241?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)]
4. 二者区别
4.1 共同点
- 开源
- 规则文件:R8 支持所有现有 ProGuard 规则文件
- 核心功能类似:都提供了四大功能:「压缩」、「优化」、「混淆」、「预校验」
4.2 不同点
- 应用场景:ProGuard 可用于 Java 项目,而 R8 专为 Android 项目设计
- 编译过程:R8 将脱糖(Desugar)、压缩、优化、混淆和 dex(D8 编译器)整合到**「一个步骤」**中,显著提高了编译性能
5. 使用说明
在 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
}
}
...
}
这里需要特别注意的是:无论使用 R8 还是 ProGuard,默认不会启用压缩、优化和混淆功能。原因:
- 这些编译时任务会增加编译时间
- 如果没有充分定义混淆保留规则,还可能会引入运行时错误。因此,最好 「只在应用的测试版本和发布版本中启用这些编译时任务」
关闭操作如下:
// 整体关闭
minifyEnabled false
// 关闭压缩
-dontshrink
// 关闭优化
-dontoptimize
// 这里需要特别注意的是:R8不能关闭优化,也不允许修改优化的行为,事实上,R8 会忽略修改默认优化行为的规则
// 关闭混淆(建议在开发版本关闭混淆)
-dontobfuscate
// 关闭预校验(对 Android 平台无效,建议关闭)
-dontpreverify
6. 规则文件说明
「R8 延续了 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
7. 组件化混淆
混淆规则
在组件化的项目中,需要注意应用 Module 和 Library Module 的行为差异和组件化的资源汇合规则:
- 编译时会依次对各层 Library Module进行编译,最底层的 Base Module 会最先被编译为 aar 文件,然后上一层编译时会将依赖 Module 输出的 aar 文件/ jar 文件解压到模块的 build 中相应的文件夹中
- App Module 这一层汇总了全部的 aar 文件后,才真正开始编译操作
- 后编译的 Module 会覆盖之前编译的 Module 中的同名资源
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-uxLYUl5q-1618297528745)(https://upload-images.jianshu.io/upload_images/25509081-a823508519e130e6?imageMogr2/auto-orient/strip%7CimageView2/2/w/640)]
组件化资源汇总
Lib Module 汇总到 App Module
使用较高版本的 Android Gradle Plugin,不会将汇总的资源放置在 exploded-aar文件夹。即便如此,Lib Module 的资源汇总到 App Module 的规则是一样的。
我们通过一个简单示例测试不同配置下的混淆结果:
配置一配置二配置三配置四App Module 开启混淆XX√√Base Module 开启混淆X√X√
示例程序:App Module 依赖了 Base Module
将构建的 apk 包拖到 Android Studio 面板上即可分析 Base 类混淆结果,例如配置一的结果:
使用配置一时,Base 类没有被混淆
全部测试结果如下:
配置一配置二配置三配置四App Module 开启混淆XX√√Base Module 开启混淆X√X√(结果)Base 类是否被混淆XX√√
可以看到,「混淆开启由 App Module 决定, 与Lib Module 无关」。
现在我们分别在 Lib Module 和 App Module 的 proguard-rules.pro中添加 Base 类的混淆保留规则,并在 build.gradle中添加配置文件,测试 Base 类是否能保留:
-keep class com.rui.base.Base
测试结果如下:
配置位置Lib ModuleApp Module(结果)Base 类是否保留X√
可以看到:「(默认情况)混淆规则以 App Module 中的混淆规则文件为准」。
根据上述结论,引入了两种主流的组件化混淆方案:
方案1:在 App Module 中设置混淆规则
这种方案将混淆规则都放置到 App Module 的proguard-rules.pro中,最简单也最直观,缺点是移除 Lib Module 时,需要从 App Module 中移除相应的混淆规则。尽管多余的混淆规则并不会造成编译错误或者运行错误,但还是会影响编译效率。
很多的第三方 SDK,就是采用了这种组件化混淆方案。在 App Module 中添加依赖的同时,也需要在proguard-rules.pro中添加专属的混淆规则,这样才能保证release版本正常运行。
方案2:在 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证明
总结
- 应用场景:ProGuard 是Java 字节码优化工具、R8 是专为 Android 设计、编译性能和编译产物更优秀;
- 功能说明:ProGuard 与 R8 都提供了四大功能:压缩、优化、混淆和预校验
- 编译流程:ProGuard主要是对 .class 文件执行代码压缩、优化与混淆,再由 D8 编译器执行脱糖并转换为 .dex 文件。R8 将压缩、优化、混淆、脱糖和 dex 整合为一个步骤;
- 规则文件来源:Android Gradle 插件、AAPT2、Module;
- 混淆规则:以 App Module 中的混淆规则文件为准,使用 consumer-rules.pro 文件可以设置 Lib Module 专属混淆规则。
最后
我们还有一份收录整理的资料PDF+架构视频+面试文档+源码笔记,高级架构技术进阶脑图、Android开发面试专题资料,高级进阶架构资
如果你有需要的话,只需私信我【进阶】即可获取
喜欢本文的话,不妨顺手给我点个赞、评论区留言或者转发支持一下呗~
标签:混淆,文件,代码,R8,Module,编译,规则,Android 来源: https://blog.csdn.net/A_pyf/article/details/115668236