--- theme: smartblue highlight: androidstudio --- ## 0x0、引言 **Android代码混淆**，老生常谈了，不过大部分Android仔对它的认识可能还处于这样的阶段(比如：写这篇文章前的我)： - 1、日常开发Debug包时不用混淆，正式发布Release包前开启代码混淆； - 2、混淆好处① → 类、方法、变量名变成短且无意义的名字，提高反编译后代码的阅读成本； - 3、混淆好处② → 删除无用的类、方法与属性，缩减了APK包的大小； - 4、混淆好处③ → 对字节码进行优化，移除无用指令，应用运行更快； - 5、怎么混淆 → 主项目的 **`build.gradle`** 设置 **`minifyEnabled true`**，**`proguard-rules.pro`** 加入混淆规则； - 6、混淆规则哪里来 → 网上搜索通用混淆模板复制粘贴，项目依赖到的第三方库官方文档复制粘贴；大都止步于此，好一点的还知道下 **`ProGuard`** 听过 **`R8`**，了解 **`混淆配置语法`**，会 **`自定义混淆规则`**。会上面这些，日常开发已经 **很够用了**，但是现在IT行业这么 **"卷"**，面试时，面试官问下： > 混淆具体做了啥？有看过混淆源码吗？说下底层原理... 也说得过去吧 (手动狗头保命~) ![][1] 所以本节稍微深入点探索下Android中的代码混淆~ ![][2] ---------- ## 0x1、日常使用 > **Tips**：照惯例，写下简单例子演示日常使用，走走过场，只对混淆原理感兴趣的可以跳过这Part~ ### 1. 混淆前后的APK对比新建项目，引下Kotlin相关依赖，协程等 (app层级的build.gradle)： ```kotlin dependencies { implementation fileTree(dir: "libs", include: ["*.jar"]) implementation "org.jetbrains.kotlin:kotlin-stdlib:$kotlin_version" implementation 'androidx.core:core-ktx:1.3.0' implementation 'androidx.appcompat:appcompat:1.1.0' implementation 'androidx.constraintlayout:constraintlayout:1.1.3' implementation 'org.jetbrains.kotlinx:kotlinx-coroutines-core:1.3.7' implementation 'org.jetbrains.kotlinx:kotlinx-coroutines-android:1.3.7' } ``` 新建MainActivity.kt，请求URL，加载内容： ```kotlin class MainActivity : AppCompatActivity(), CoroutineScope by MainScope() { override fun onCreate(savedInstanceState: Bundle?) { super.onCreate(savedInstanceState) setContentView(R.layout.activity_main) et_url.setText("https://www.baidu.com") bt_load.setOnClickListener { launch { tv_content.text = "开始加载请求..." tv_content.text = "加载完毕，网页内容如下：\n\n\n ${loadUrl(et_url.text.toString())}" } } } private suspend fun loadUrl(url: String) = withContext(Dispatchers.IO) { var content = "" (URL(url).openConnection() as HttpURLConnection).apply { requestMethod = "GET" content = dealResponse(inputStream) disconnect() } return@withContext content } private fun dealResponse(inputStream: InputStream): String { val reader = BufferedReader(InputStreamReader(inputStream)) return StringBuffer().apply { var str = reader.readLine() while (null != str) { append(str) str = reader.readLine() } }.toString() } override fun onDestroy() { super.onDestroy() cancel() } } ``` **运行下康康**： ![][3] app层级的build.gradle加下release的签名和编译配置： ``` signingConfigs { release { storeFile file('test.jks') storePassword '123456' keyAlias 'test' keyPassword '123456' } } buildTypes { release { // 启用代码压缩、优化及混淆 minifyEnabled true // 启用资源压缩，需配合 minifyEnabled=true 使用 shrinkResources true // 指定混淆保留规则 proguardFiles getDefaultProguardFile('proguard-android-optimize.txt'), 'proguard-rules.pro' // 包签名 signingConfig signingConfigs.release } } ``` 执行 **`gradle assemble`** 打下包，静待打包完毕，先康康Debug包： ![][4] 23333，**裸奔**，把APK直接拖到反编译工具 **`jadx-gui`** 里，看代码无压力： ![][5] 再康康Release包： ![][6] 体积着实少了一些，而且变量名都变成了abcd，顺带提下这个**`Load Proguard mappings`**，点击加载混淆文件(mapping.txt)后可以去掉代码混淆： ![][7] 同样拖到jadx-gui里康康： ![][8] 可读性明显降低~ ---------- ### 2. 混淆后App Crash日志定位问题不知道你有没有想过：**混淆后的APK如果报错，日志信息会是怎样的呢**？改下代码验证下，直接在点击处抛出一个空指针异常试试康： ![][9] 单凭这里的b.b.a.a.onClick(Unknow Srouce:2)，似乎很难直接定位到错误代码的真实位置。一种低效的解决方法：自行对照混淆后生成的 **`mapping.txt`** 文件，比如直接搜上面的b.b.a.a： ![][10] 顺着往下看不难发现问题所在，但日常开发不建议用此法，这里好找只是因为示例代码简单，推荐另一种方法： **`去混淆`**，如果你的应用有发布到Google Play的话，可以照着官方文档走： [对崩溃堆栈轨迹进行去混淆处理或符号化解析][11] ![][12] 没有上传到Google Play也没关系，直接用 **`android-sdk/tools/proguard/bin/proguardgui.bat`**： ![][13] ProGuard和R8的混淆都可以去，老版本的脚本可能不支持R8，更新下sdk即可，不想更新的也可以直接用我提供的脚本包去R8混淆，下载地址(提取码: 1234)：[R8-Retrace.7z][14]，使用流程如下图所示： ![][15] 去混淆前后对比： ![][16] 可以的，日常使用就讲到这里，接着过一下混淆的详细规则。 ---------- ## 0x2、混淆规则详解 > **Tips**：没必要死记，点赞mark下，要用的时候再回来查就好，遗漏的欢迎在评论区提出~ ### 1. 混淆设置参数 ```bash -optimizationpasses 5 # 代码混淆的压缩比例，值介于0-7，默认5 -verbose # 混淆时记录日志 -dontoptimize # 不优化输入的类文件 -dontshrink # 关闭压缩 -dontpreverify # 关闭预校验(作用于Java平台，Android不需要，去掉可加快混淆) -dontoptimize # 关闭代码优化 -dontobfuscate # 关闭混淆 -ignorewarnings # 忽略警告 -dontwarn com.squareup.okhttp.** # 指定类不输出警告信息 -dontusemixedcaseclassnames # 混淆后类型都为小写 -dontskipnonpubliclibraryclasses # 不跳过非公共的库的类 -printmapping mapping.txt # 生成原类名与混淆后类名的映射文件mapping.txt -useuniqueclassmembernames # 把混淆类中的方法名也混淆 -allowaccessmodification # 优化时允许访问并修改有修饰符的类及类的成员 -renamesourcefileattribute SourceFile # 将源码中有意义的类名转换成SourceFile，用于混淆具体崩溃代码 -keepattributes SourceFile,LineNumberTable # 保留行号 -keepattributes *Annotation*,InnerClasses,Signature,EnclosingMethod # 避免混淆注解、内部类、泛型、匿名类 -optimizations !code/simplification/cast,!field/ ,!class/merging/ # 指定混淆时采用的算法 ``` ---------- ### 2. 保持不被混淆的设置 **语法组成**： ``` [保持命令] [类] { [成员] } ``` **保持命令**： ``` -keep # 防止类和类成员被移除或被混淆； -keepnames # 防止类和类成员被混淆； -keepclassmembers # 防止类成员被移除或被混淆； -keepclassmembernames # 防止类成员被混淆； -keepclasseswithmembers # 防止拥有该成员的类和类成员被移除或被混淆； -keepclasseswithmembernames # 防止拥有该成员的类和类成员被混淆； ``` **类**： - **`具体的类`** - **`访问修饰符`** → public、private、protected - **`通配符(*)`** → 匹配任意长度字符，但不包含包名分隔符(.) - **`通配符(**)`** → 匹配任意长度字符，且包含包名分隔符(.) - **`extends`** → 匹配实现了某个父类的子类 - **`implements`** → 匹配实现了某接口的类 - **`$`** → 内部类 **成员**： - **匹配所有构造器** → <init> - **匹配所有域** → <field> - **匹配所有方法** → <methods> - **`访问修饰符`** → public、private、protected - 除了 `*` 和 `**` 通配符外，还支持 `***` 通配符，匹配任意参数类型 - **`...`** → 匹配任意长度的任意类型参数，如void test(...)可以匹配不同参数个数的test方法 **常用自定义混淆规则范例**： ```bash # 不混淆某个类的类名，及类中的内容 -keep class cn.coderpig.myapp.example.Test { *; } # 不混淆指定包名下的类名，不包括子包下的类名 -keep class cn.coderpig.myapp* # 不混淆指定包名下的类名，及类里的内容 -keep class cn.coderpig.myapp* {*;} # 不混淆指定包名下的类名，包括子包下的类名 -keep class cn.coderpig.myapp** # 不混淆某个类的子类 -keep public class * extends cn.coderpig.myapp.base.BaseFragment # 不混淆实现了某个接口的类 -keep class * implements cn.coderpig.myapp.dao.DaoImp # 不混淆类名中包含了"entity"的类，及类中内容 -keep class **.*entity*.** {*;} # 不混淆内部类中的所有public内容 -keep class cn.coderpig.myapp.widget.CustomView$OnClickInterface { public *; } # 不混淆指定类的所有方法 -keep cn.coderpig.myapp.example.Test { public ; } # 不混淆指定类的所有字段 -keep cn.coderpig.myapp.example.Test { public ; } # 不混淆指定类的所有构造方法 -keep cn.coderpig.myapp.example.Test { public ; } # 不混淆指定参数作为形参的方法 -keep cn.coderpig.myapp.example.Test { public (java.lang.String); } # 不混淆类的特定方法 -keep cn.coderpig.myapp.example.Test { public test(java.lang.String); } # 不混淆native方法 -keepclasseswithmembernames class * { native ; } # 不混淆枚举类 -keepclassmembers enum * { public static **[] values(); public static ** valueOf(java.lang.String); } #不混淆资源类 -keepclassmembers class **.R$* { public static ; } # 不混淆自定义控件 -keep public class * entends android.view.View { *** get*(); void set*(***); public ; } # 不混淆实现了Serializable接口的类成员，此处只是演示，也可以直接 *; -keepclassmembers class * implements java.io.Serializable { static final long serialVersionUID; private static final java.io.ObjectStreamField[] serialPersistentFields; private void writeObject(java.io.ObjectOutputStream); private void readObject(java.io.ObjectInputStream); java.lang.Object writeReplace(); java.lang.Object readResolve(); } # 不混淆实现了parcelable接口的类成员 -keep class * implements android.os.Parcelable { public static final android.os.Parcelable$Creator *; } # 注意事项： # # ① jni方法不可混淆，方法名需与native方法保持一致； # ② 反射用到的类不混淆，否则反射可能出问题； # ③ 四大组件、Application子类、Framework层下的类、自定义的View默认不会被混淆，无需另外配置； # ④ WebView的JS调用接口方法不可混淆； # ⑤ 注解相关的类不混淆； # ⑥ GSON、Fastjson等解析的Bean数据类不可混淆； # ⑦ 枚举enum类中的values和valuesof这两个方法不可混淆(反射调用)； # ⑧ 继承Parceable和Serializable等可序列化的类不可混淆； # ⑨ 第三方库或SDK，请参考第三方提供的混淆规则，没提供的话，建议第三方包全部不混淆； ``` ---------- ### 3. 混淆规则的叠加不知道你有没有想过：**上面日常使用的创建的代码示例，proguard-rules.pro没有配置混淆规则，却混淆了？** 其实是因为 **`混淆规则是叠加的`**，而混淆规则的来源不止主模块里的proguard-rules.pro，还有这些： - ① **`/proguard-rules.pro`** 不止主模块有proguard-rules.pro，子模块也可以有，因为规则是叠加的，故某个模块的配置都可能影响其它模块。 - ② **`proguard-android-optimize.txt`** AGP编译时生成，其中包含了对大多数Android项目都有用的规则，并且启用 **`@Keep*`** 注解。 AGP提供的规则文件还有proguard-defaults.txt或proguard-android.txt，可通过 **getDefaultProguardFile** 进行设置，不过建议还是使用这个文件(多了些优化配置)。 - ③ **`/build/intermediates/proguard-rules/debug/aapt_rules.txt`** 自动生成，AAPT2会根据对应用清单中的类、布局及其他应用资源的引用，生成保留规则，如不混淆每个Activity。 - ④ AAR库 → **`/proguard.txt`** - ⑤ Jar库 → **`/META-INF/proguard/`** 如果想查看所有规则 **叠加后的混淆规则**，可在主目录的 **`proguard-rules.pro`** 添加下述配置： ```bash # 输出所有规则叠加后的混淆规则 -printconfiguration ./build/outputs/mapping/full-config.txt ``` ---------- ### 4. 资源压缩资源压缩其实分为两步：**资源合并** 与 **资源移除**，前者无论是否配置 shrinkResources true，AGP构建APK时都会执行，当存在两个或更多名称相同的资源才会进行资源合并，AGP会从重复项中选择 **优先级更高** 的文件，并只将此资源传递给AAPT2，以供在APK中分发。级联优先顺序： > 依赖项 → 主资源 → 渠道 → 构建类型比如：重复资源存在于主资源及渠道中，Gradle会选择渠道中的资源；但如果重复资源在同一层次出现，如src/main/res/和src/main/res2中有重复资源，Gradle就会报资源合并错误。对应打包Task中的 **`processDebugResources`**，将aapt编译后的flat产物和合并后的清单文件进行链接处理生成 **._ap** 文件(包含资源文件、清单文件、资源关系映射表文件resources.arsc) 及 **R.java** 文件(保存了资源类型、资源名称及地址的映射关系)。说完资源合并，接着说下资源移除，开启资源压缩后，所有未被使用的资源默认会被移除，如果你想定义那些资源需要保留，可以在 `res/raw/` 路径下创建一个xml文件，如 **`keep.xml`**，配置示例如下 (此文件不会打包到APK中，支持通配符*，此类文件可有多份)： ```xml tools:keep="@layout/l_used*_c,@layout/l_used_a,@layout/l_used_b*" tools:discard="@layout/unused2" tools:shrinkMode="strict"/> ``` 另外，还可以在build.gradle中添加 **`resConfigs`** 来移除不需要的备用资源文件，如只保留中文： ``` android { ... defaultConfig { resConfigs "zh-rCN" // 不用支持国际化只需打包中文资源 } } ``` ---------- ## 0x3、从脱糖引出ProGuard、DX、D8、R8 > **Tips**：此结点内容部分抽取自 [《Android CPU, Compilers, D8 & R8》][17]，阅读原文可能更加容易理解~ 我们都知道Java是跨平台的，一次编译，到处运行，同一套Java代码可以在Windows、Linux、Mac上运行，背后依赖于不同平台/版本的 **`JVM`**（Java虚拟机），Java代码编译后生成 **`.class`** 字节码文件，再由JVM翻译成特定平台的 **`机器码`**，然后运行。 JVM的内部组成图如下： ![][18] - **类加载器**：加载编译后的.class，链接、检测损坏的字节码，定位并初始化静态变量及静态代码； - **运行时数据**：栈、堆、方法变量等； - **执行引擎**：执行已经加载的代码、清理生成的所有垃圾(gc)；运行程序时，**`Interpreter`**(解释器) 会将字节码解释为机器码然后运行，当发现有重复执行的代码时，会切换为 **`JIT编译器`**。JIT编译器会将重复的代码编译为本地机器码，当同样的方法被调用时，直接运行本地机器码，从而提高系统性能。 ![][19] JVM的设计是面向无限电量/存储的设备，Android设备与之相比，太弱鸡了(电量、内存大小、存储等小的可怜)。不能直接使用，于是Google自己设计了一套用于Android平台的Java虚拟机——**`Dalvik`**，支持已转换为 **.dex** (Dalvik Executable) 压缩格式的Java应用程序的运行。与JVM字节码基于栈不同，**Dalvik基于寄存器**(变量都存储在寄存器中)，后者更加高效且需要更少的空间。 .java和.kt代码文件被Java、Kotlin编译器协作编译为.class，而后编译为.dex文件，最后打包到.apk文件中。把APK安装到设备上，当点击应用图标时，系统会启动一个新的Dalvik进程，并将应用包含的dex代码加载进来，在运行时交由Interpreter或JIT编译，然后就可以看到应用的界面了： ![][20] 在Dalvik中，应用的每次运行都需要执行编译操作，而这段时间是计入程序的执行时间，所以程序的启动速度会有点慢，当然也有好处，应用安装速度快。在Android 4.4.4后，Google开始引入 **Dalvik** 的替代品——**ART**，从**JIT**(Just In Time，即时编译) 到 **AOT** (Ahead-Of-Time，预编译)，应用在首次安装时用**dex2oat**将 **`dex`** 编译为 **`.oat`** 二进制文件。 ![][21] 点击应用图标启动时，ART直接加载.oat文件并运行，启动速度明显提升，避免了重复编译，减少了CPU的使用频率，也降低了功耗，当然缺点也是有的：**更长的应用安装时间** 和 **更大的存储空间占用**。除了应用安装会触发dex2oat编译外，OTA升级、系统启动(首次/非首次)、系统空闲时也可能会触发，具体要看对应系统的配置。上面说过Android虚拟机采用 **基于寄存器的指令集(opcodes)**，这样会存在一个问题，更高版本Java新引入的语法特性不能在上面直接使用。为了让我们能使用上Java 8的特性，Google使用 **`Transformation`** 来增加了一步编译过程 → **`脱糖(desugaring)`**。 > 当使用当前Android版本不支持的高版本jdk语法时，在编译期转换为其支持的低版本jdk语法。脱糖实现的大概发展历程如下： ![][22] 至此，相信你对ProGuard、DX、D8和R8在混淆过程中起的作用有了一个基础的认知~ ---------- ## 0x4、用 ProGuard 还是 R8? 答：如果没有历史包袱，直接**R8**，毕竟兼容绝大部分的ProGuard规则，更快的编译速度，对Kotlin更友好。还是简单描述下两者吧： - **`ProGuard`** → 压缩、优化和混淆Java字节码文件的免费工具，开源仓库地址：[proguard][23] - **`R8`** → ProGuard的替代工具，支持现有ProGuard规则，**更快更强**，**AGP 3.4.0**或更高版本，默认使用R8混淆编译器。如果不想用R8，想用回ProGuard的话(**可以但没必要**)，可以在 **`gradle.properties`** 文件中添加下述配置禁用R8： ```bash android.enableR8=false android.enableR8.libraries=false ``` 编译APK时可能会报错： ![][24] 在 **`proguard-rules.pro`** 文件中加上 **`-ignorewarnings`** 即可解决。另外，使用ProGuard或R8构建项目会在 **`build\outputs\mapping\release`** 输出下述文件： - **mapping.txt** → 原始与混淆过的类、方法、字段名称间的转换； - **seeds.txt** → 未进行混淆的类与成员； - **usage.txt** → APK中移除的代码； - **resources.txt** → 资源优化记录文件，哪些资源引用了其他资源，哪些资源在使用，哪些资源被移除； **Tips**：上述文件不一定都有，R8可以在 **`proguard-rules.pro`** 文件添加下述配置输出对应文件： ```bash # 输出mapping.txt文件 -printmapping ./build/outputs/mapping/mapping.txt # 输出seeds.txt文件 -printseeds ./build/outputs/mapping/seeds.txt # 输出usage.txt文件 -printusage ./build/outputs/mapping/usage.txt ``` ---------- ## 0x5、D8干了啥？接着跟下源码，康康D8具体都做了啥，在上一节[《补齐Android技能树——从AGP构建过程到APK打包过程》][25] 中我们摸清了APK的打包Task链，打包成Dex经历的Task有三个： - **transformClassesWithDexBuilderForDebug** → 将class打包成dex - **transformDexArchiveWithExternalLibsDexMergerForDebug** → 打包第三库的dex - **transformDexArchiveWithDexMergerForDebug** → 打包最终的dex 三个Task最终都是通过DX或D8来打dex，跟下第一个Task：**`DexArchiveBuilderTransform.transform()`** ![][26] 这里拿到需要 **待脱糖的文件列表**，接着往下就来到熟悉的：**处理目录下的class** 和 **.jar里的class** 了。 ![][27] 这里把待脱糖的文件列表传到 **`convertToDexArchive()`** 里了，跟下： ![][28] 跟 **`launchProcessing()`** → **`dexArchiveBuilder.convert()`** ![][29] 抽象类，跟下具体实现类 **`D8DexArchiveBuilder.convert()`**， ![][30] D8Command类是D8命令行配置类，就是将上面进行的这些配置转换成 **`d8打包命令`** 而已： ![][31] 命令行配置参数详解可以参见官方文档：[d8][32]，这里就不去刨d8的源码了，知道D8起做的作用是：**`脱糖 + 将.class字节码转换成dex`** 就好。 ---------- ## 0x6、R8又干了啥？不知道，细心你的有没有发现，D8竟在r8的包里： ![][33] 接着在 **`TaskManager.java`** 搜下D8，经过各种跳转，来到源头：**`createPostCompilationTasks()`**，可以看到在创建D8相关的Transform前还做了一些其他的操作~ ![][34] ### ① R8 - 执行前从注释不难看出，这些Tasks就是用来把.class转dex文件的，还加了一些可选步骤如混淆、jacoco(代码覆盖率工具)，还创建了一个 **`TransformManager`** 实例，用来管理各种TransformManager。继续： ![][35] 这里引起了我的好奇，**可能创建脱糖Task**？脱糖不是在D8里进行的吗？跟一下代码： ![][36] ![][37] 这里的DESUGAR，猜测是旧版本的D8兼容，AS 3.0引入的，而现在默认是D8，所以这里其实不会创建脱糖Task。继续： ![][38] 获取外部扩展，**合并Java资源**，对合并算法感兴趣的可以点进去 **`MergeJavaResourcesTransform.transform()`** 看下，这里不展开讲~ ![][39] 继续往下走： ![][40] ---------- ### ② R8 - Java代码压缩再往下走，就碰到关键词R8了： ![][41] 这里有下述三个maybe： - **maybeCreateJavaCodeShrinkerTransform** → Java代码压缩 - **maybeCreateResourcesShrinkerTransform** → 资源压缩 - **maybeCreateDexSplitterTransform** → dex分割先看第一个： ![][42] ![][43] 这里区分PROGUARD和R8，创建不同的混淆TransformTask，关注 **`createR8Transform()`** 核心代码如下： ```java // 前面获取dex的文件列表、混淆列表等，初始化R8Transform实例时传入 R8Transform transform = new R8Transform( variantScope, userMainDexListFiles, userMainDexListProguardRules, inputProguardMapping, variantScope.getOutputProguardMappingFile()); // 处理混淆规则，callback用于在混淆后执行后续操作 return applyProguardRules( variantScope, inputProguardMapping, variantScope.getOutputProguardMappingFile(), testedVariantData, transform, callback); ``` 跟下 **`applyProguardRules()`**，关注下述核心代码(前面的是和测试相关的)： ```java // This is a "normal" variant in an app/library. applyProguardConfigForNonTest(transform, variantScope); ``` 跟下此方法： ![][44] 补充其他混淆规则的来源，如AAPT生成的混淆文件，判断如果是AAR的话，直接keep。 ![][45] 跟下 **R8Transform.transform()**，又是参数，最后调用下述方法： ![][46] 最后在 **`r8Tool.kt`** 中定位到了此方法，核心代码如下： ```kotlin // 初始化了一个r8CommandBuilder实例 val r8CommandBuilder = CompatProguardCommandBuilder(!useFullR8, D8DiagnosticsHandler(messageReceiver)) // 然后调用一系列方法，如混淆相关 addMainDexRules() setMainDexListConsumer() addProguardConfigurationFiles() addProguardConfiguration() setProguardMapOutputPath() // 配置相关：是否禁用缩小、摇树、脱糖、编译模式 setDisableMinification(toolConfig.disableMinification) setDisableTreeShaking(toolConfig.disableTreeShaking) setDisableDesugaring(toolConfig.disableDesugaring) setMode(compilationMode) setProgramConsumer(programConsumer) ... // 初始化r8ProgramResourceProvider实例，用来给R8提供所有资源 val r8ProgramResourceProvider = R8ProgramResourceProvider() // 各种传参设置 // 最后调用R8.run() ClassFileProviderFactory(libraries).use { libClasspath -> r8CommandBuilder.addLibraryResourceProvider(libClasspath.orderedProvider) R8.run(r8CommandBuilder.build()) } ``` 具体的逻辑，可以追溯到 **`R8.class → run()`**，做了这些事： - **代码删除**：通过语法树静态分析技术、发现并删除未使用的代码，如未实例化的Class等； - **代码优化**：对运行时代码进行优化，删除死代码、未使用的参数，选择性内联、类合并等； - **代码混淆**：优化标识符名字，减少代码量，会判断混淆规则中是否允许修改标识符名字； - **行号重新映射** 等。短短333行的处理代码，逻辑复杂，恐怖如斯，感兴趣的自己看吧，我是啃不动了... ### ③ R8 - 资源压缩接着跟下第二个 **`maybeCreateResourcesShrinkerTransform()`**： ![][47] 跟下 **`ShrinkResourcesTransform.transform()`**， ![][48] 跟下 **`SplitterRunnable.run()`**，看下具体是怎么压缩资源的，核心代码如下： ```java // ① 创建资源优化记录文件 File reportFile = null; if (params.mappingFile != null) { File logDir = params.mappingFile.getParentFile(); if (logDir != null) { reportFile = new File(logDir, "resources.txt"); } } // ② 分析资源及使用情况 analyzer.analyze(); // ③ 重写.ap_文件(上面AAPT2生成的)，去掉没有用到的资源，实际上是没有删除本地资源的！ analyzer.rewriteResourceZip(params.uncompressedResourceFile, params.compressedResourceFile); // ③ 导出统计数据 ``` 解压AAPT生成的.ap_文件，然后判断是是否为未使用资源，是的话移除，感兴趣可以跟下 **`rewriteResourceZip()`**。 ---------- ### ④ R8 - 调D8拆Dex 只有使用了 **`Multidex`** 才会走这里，跟下代码： ![][49] 跟下 **`DexSplitterTransform.transform()`** ![][50] 跟下 **`DexSplitterTool.Builder`** ![][51] 跟下 **`DexSplitter.run()`** ![][52] 跟下 **`DexSplitterHelper.run()`** ![][53] 所以最后还是用的D8打Dex，总算把大概的过程过完了~ ![][54] ---------- ## 0x7、自定义混淆字典之前在反编译人家的APP时看到标识符竟然不是abcd，而是中文和特殊字符，怎么做到的呢？其实不难，自定义一个混淆字典就好，在app的proguard-rules的同级目录创建一个文件，比如 **dictionary**，内容示例如下： ```bash ﹢ ﹣ × ÷ ...太长省略 ``` 接着在 **`proguard-rules`** 添加下述配置： ``` -obfuscationdictionary ./dictionary -classobfuscationdictionary ./dictionary -packageobfuscationdictionary ./dictionary ``` 再接着 **`gradle assemble`** 打下包，用jadx打开生成的Release APK康康： ![][55] 23333，**效果极佳**，喜欢反编译别人APK的同学看到了，不会打我吧！ ![][56] ---------- ## 0x8、模块化混淆 **混淆的开启由app模块控制，与子模块无关**。建议 **在app模块设置公共混淆规则，子模块设置专属混淆规则**，子模块区分project和aar： ``` # Project类型，配置方法同app模块 buildTypes { release { minifyEnabled false proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro' } } # AAR类型 android { defaultConfig { consumerProguardFiles 'lib-proguard-rules.txt' } ... } ``` 当然，你想让混淆规则都由app模块控制也是可以的，移除模块时记得删掉对应的混淆就好~ ---------- **小结** **淦**(gàn)，看源码到吐血，Gradle相关的东西真的是无底洞啊，学完一个又一个，还有著名的ASM字节码插桩，基于APK构建过程Task的HOOK的各种开源性能优化/检测工具等。不学了，学不动了，休息下，我在想写一个 **`依赖库自动检测+混淆自动生成的插件`** 会不会很好玩呢？当然，只是想想。不过源码过完流程了解了心里有底，再看别人这些开源项目时就不会跟看天书一样了~ ![123.gif-581kB][57] **参考文献**： - [写给Android开发者的混淆使用手册][58] - [Android CPU, Compilers, D8 & R8][59] - [关于D8/R8那些事：Desugaring脱糖、APK包体积优化等][60] - [Android 兼容 Java 8 语法特性的原理分析][61] - [库模块可以包含自己的 ProGuard 配置文件][62] - [缩减、混淆处理和优化应用][63] - [Android | 代码混淆到底做了什么？][64] [1]: https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/69f697e6578b481da8537a47aceac945~tplv-k3u1fbpfcp-zoom-1.image [2]: https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/c6335b6146ab4f1cbc45f382a3ec3df9~tplv-k3u1fbpfcp-zoom-1.image [3]: https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/4827e7841e7e4f25a88f9a2f148bf1a2~tplv-k3u1fbpfcp-zoom-1.image [4]: https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/e198521a045d4046b793d07573e0aec9~tplv-k3u1fbpfcp-zoom-1.image [5]: https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/a4e2c748cc1e462cad241c0d797ff0b6~tplv-k3u1fbpfcp-zoom-1.image [6]: https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/746abd988b7e4691a6fc18a58afde193~tplv-k3u1fbpfcp-zoom-1.image [7]: https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/807b30f81b9f4372a6bea3a66658223a~tplv-k3u1fbpfcp-zoom-1.image [8]: https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/8f055eeda9a54e92b0453b4171fa0a2c~tplv-k3u1fbpfcp-zoom-1.image [9]: https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/e33282e8e7a44f60a29d1ad7cc0e2651~tplv-k3u1fbpfcp-zoom-1.image [10]: https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/9d7c9553f17544d48587adb46bb2cda8~tplv-k3u1fbpfcp-zoom-1.image [11]: https://support.google.com/googleplay/android-developer/answer/6295281?hl=zh-cn [12]: https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/01b7a4a279c64ce9b381043a47b802e9~tplv-k3u1fbpfcp-zoom-1.image [13]: https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/95c71b528b2a414a9eaf1b2de40051cf~tplv-k3u1fbpfcp-zoom-1.image [14]: https://pan.baidu.com/s/1XHhAVfCK72aGJ6dd7D52xA [15]: https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/8eea3fb14aa246e0afc97b12dfd7aa33~tplv-k3u1fbpfcp-zoom-1.image [16]: https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/286f3c80ceac49e68fd3fb01d63d6084~tplv-k3u1fbpfcp-zoom-1.image [17]: https://juejin.cn/post/6844903936227278861 [18]: https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/03f5aa45cd3d41beb4eee149fb7fa65e~tplv-k3u1fbpfcp-zoom-1.image [19]: https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/155c994097e74351a60cf119f6b52846~tplv-k3u1fbpfcp-zoom-1.image [20]: https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/eaebc2618bbd423e85bc85d6d1fd2290~tplv-k3u1fbpfcp-zoom-1.image [21]: https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/9be26e768a844b889a5090918f32ee5f~tplv-k3u1fbpfcp-zoom-1.image [22]: https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/2278354bbf9340e89a43b99be4e69887~tplv-k3u1fbpfcp-zoom-1.image [23]: https://github.com/Guardsquare/proguard [24]: https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/580dab9fd21848518a65c19314c2f870~tplv-k3u1fbpfcp-zoom-1.image [25]: https://juejin.cn/post/6963527524609425415 [26]: https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/7f9803846487414086439b74a90c74f7~tplv-k3u1fbpfcp-zoom-1.image [27]: https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/6f6c00a1196c4724b117ce17a40c369d~tplv-k3u1fbpfcp-zoom-1.image [28]: https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/4912269a23ef467ca2dfe6685cc6ea35~tplv-k3u1fbpfcp-zoom-1.image [29]: https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/cc5bf01b8df3400e8a71d8b178e6b45f~tplv-k3u1fbpfcp-zoom-1.image [30]: https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/fc25c4b2717f4172ba5bf92da24624ca~tplv-k3u1fbpfcp-zoom-1.image [31]: https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/01a401436d9e40b282149ed70e8eca0c~tplv-k3u1fbpfcp-zoom-1.image [32]: https://developer.android.google.cn/studio/command-line/d8?hl=zh-cn [33]: https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/2ae68c027a8d484f8181bf1f09e1767a~tplv-k3u1fbpfcp-zoom-1.image [34]: https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/3637ad9f30e84f2f9ac6863ed021c209~tplv-k3u1fbpfcp-zoom-1.image [35]: https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/70585138aa934b76ba0d98118cd8bc0f~tplv-k3u1fbpfcp-zoom-1.image [36]: https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/7079bae17b1743e8be83126ccda2383e~tplv-k3u1fbpfcp-zoom-1.image [37]: https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/b32432515f70415ea1cab52e74198302~tplv-k3u1fbpfcp-zoom-1.image [38]: https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/c4d569df9646483a84a3ffe4b50b5291~tplv-k3u1fbpfcp-zoom-1.image [39]: https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/7680beef20ef4d76ae97808fbf098d7d~tplv-k3u1fbpfcp-zoom-1.image [40]: https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/a2b77db17cb84b72ba0f6d8dd6438f4d~tplv-k3u1fbpfcp-zoom-1.image [41]: https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/02891eec75014864bfc9bee5825e0802~tplv-k3u1fbpfcp-zoom-1.image [42]: https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/e17a7106f746497884e3a91beff19eb3~tplv-k3u1fbpfcp-zoom-1.image [43]: https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/0b6c94553e80429b8eca852ade84b322~tplv-k3u1fbpfcp-zoom-1.image [44]: https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/bd6d5e992736475b94e82b2351a900c8~tplv-k3u1fbpfcp-zoom-1.image [45]: https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/2517c0f70c244bbf8682e5db30ce975d~tplv-k3u1fbpfcp-zoom-1.image [46]: https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/b4358cb901d843b28e06cd31a39d14f9~tplv-k3u1fbpfcp-zoom-1.image [47]: https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/e702d4c6c6c04d8d9cbc00cbf9d69402~tplv-k3u1fbpfcp-zoom-1.image [48]: https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/39cccb48c5c94ce7a083e04eb7a1addd~tplv-k3u1fbpfcp-zoom-1.image [49]: https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/c29ae086c1534576b4c285a7326436af~tplv-k3u1fbpfcp-zoom-1.image [50]: https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/d7707cf247dd49ed941986258c49883d~tplv-k3u1fbpfcp-zoom-1.image [51]: https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/a6fe8a4e9bca4ea8b8b6f85b0aa3e24e~tplv-k3u1fbpfcp-zoom-1.image [52]: https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/2b7666c260b145bb8b56086dcc1702ed~tplv-k3u1fbpfcp-zoom-1.image [53]: https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/816cb01ebbd54e02aefb5463b1d4eb4a~tplv-k3u1fbpfcp-zoom-1.image [54]: https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/d35476dfebea41f793b4143041f90ad6~tplv-k3u1fbpfcp-zoom-1.image [55]: https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/2b617951af7643d3a7b82bb0fbdaa3ae~tplv-k3u1fbpfcp-zoom-1.image [56]: https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/f5e91c21d03f49ad9454e1a5e1a99dba~tplv-k3u1fbpfcp-zoom-1.image [57]: https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/3ac245b40d5d4509a3eca7c38021972b~tplv-k3u1fbpfcp-zoom-1.image [58]: https://juejin.cn/post/6844903503177990158 [59]: https://juejin.cn/post/6844903936227278861 [60]: https://blog.csdn.net/vitaviva/article/details/109422961 [61]: https://tech.meituan.com/2019/10/17/android-java-8.html [62]: https://developer.android.com/studio/projects/android-library?hl=zh-cn#Considerations [63]: https://developer.android.com/studio/build/shrink-code?hl=zh-cn [64]: https://juejin.cn/post/6930648501311242248