代码混淆基础：ProGuard / DexGuard / R8 入门与基础配置

代码混淆，听起来挺玄乎的。说白了，就是把你的代码“改头换面”，让反编译的人看得一头雾水。我之前在给一个金融SDK做安全评估时，发现对方没开混淆，结果核心加密逻辑直接被逆向出来，冷汗都吓出来了。今天我们就来聊聊Android生态里三款主流混淆工具：ProGuard、R8和DexGuard。

为什么需要代码混淆？

APK其实就是一个压缩包。dex文件里的类名、方法名，甚至变量名，默认都带着你写代码时的原始名称。反编译工具一拉，你的业务逻辑、API结构、甚至注释都一览无余。

混淆能做到三件事：

• 重命名：把SecurityUtils.decrypt()变成a.b()——语义信息全丢。
• 控制流混淆：打乱if-else结构，增加花指令，反编译出来一团乱麻。
• 资源压缩：删除无用代码和资源，缩小体积。

嗯，尤其是SDK场景，你的API签名、网络传输层、核心算法必须混淆。不然甲方拿你SDK一解，直接白嫖你代码——这滋味我可尝过。

三款工具初识：该选谁？

我习惯把它们按“保护力度”排个序。先看这张对比表：

特性	ProGuard	R8	DexGuard
集成方式	插件/手动接入	Android Gradle Plugin 内置	商业插件，需替换AGP混淆器
混淆能力	基础（类名/方法名）	基础+内联+裁剪更强	高级（字符串加密/反射隐藏）
资源保护	仅压缩	压缩+部分资源ID混淆	资源名称混淆+加密
性能	较慢（Java实现）	快（Kotlin原生实现）	快（C++内核）
热修复兼容性	需要keep规则	需要keep规则	需专门配置
成本	免费开源	免费内置	商业许可（约$1000+/年）

实战一：用R8做基础混淆

R8从AGP 3.4开始就是默认混淆器。你几乎不需要额外引入依赖。配置都在build.gradle里。

步骤1：启用R8

在模块级build.gradle里，release构建必须开启：

android {
    buildTypes {
        release {
            minifyEnabled true           // 启用混淆
            proguardFiles getDefaultProguardFile('proguard-android-optimize.txt'),
                          'proguard-rules.pro'
        }
        debug {
            // debug不建议开混淆，会影响调试
            minifyEnabled false
        }
    }
}

注意那个getDefaultProguardFile(...)，它指向Android SDK内置的默认规则。我建议你永远不要直接修改这个文件，要改就写在proguard-rules.pro里。

步骤2：编写keep规则

这是最容易翻车的地方。混淆器默认会干掉所有它认为“没用”的代码。但你的SDK对外暴露的API、反射调用的方法、被XML引用的类……必须被保留。

来看一个典型的SDK规则：

# ========== 保留对外公开API接口 ==========
-keep class com.yoursdk.api.** { *; }

# ========== 保留继承自特定基类的类（比如Activity） ==========
-keep class * extends android.app.Activity {
    public <init>(...);
}

# ========== 保留被@Keep注解标记的元素 ==========
-keep @android.support.annotation.Keep class *
-keepclassmembers class * {
    @android.support.annotation.Keep *;
}

# ========== 保留反射常用的方法（比如Gson的TypeToken） ==========
-keep class com.google.gson.reflect.TypeToken { *; }
-keep class * extends com.google.gson.reflect.TypeToken

# ========== 保留JNI方法签名 ==========
-keepclasseswithmembers class * {
    native <methods>;
}

# ========== 保留枚举的values/valueOf（否则会报错） ==========
-keepclassmembers enum * {
    public static **[] values();
    public static ** valueOf(java.lang.String);
}

实战二：ProGuard老项目维护

有些老项目还在用ProGuard。原理跟R8完全一致，只是语法细节稍有不同。你可能会在迁移时遇到几个坑：

1. 语法差异：ProGuard不支持-whyareyoukeeping的分析命令（R8支持）。排查“为什么这个类被保留了”时，R8更友好。
2. 性能差距：同样代码，ProGuard多花1~2分钟很正常。我有个同事直接从ProGuard切R8，构建从4分钟缩到1.5分钟——真香。
3. keep规则通用：proguard-rules.pro完全兼容，直接复制就行。

如果你还在ProGuard上犹豫，我建议直接迁到R8。Android官方也在全力推它，迟早的事。

实战三：DexGuard进阶保护

R8搞不定的场景，DexGuard能给你一层“硬壳”。它不只是改名，还能做到：

• 字符串加密："https://api.pay.com/v3" 这种硬编码会变成密文字节码，运行时才解密。
• 反射调用隐藏：Class.forName("com.android.internal.telephony.ITelephony") 这种敏感反射会被混淆掉类名。
• 资源名称混淆：R.string.app_secret 变成 R.string.a。
• 反调试：检测调试器附加，自动触发保护（比如闪退、清空内存）。

配置方式也类似，只是需要在你自己的build.gradle里替换混淆器：

buildTypes {
    release {
        minifyEnabled true
        // 替换为DexGuard
        proguardFiles 'dexguard-project.txt'
    }
}

DexGuard的商业许可不便宜，我建议你先用R8把基础做好，等真有对抗需求再引入。

知识体系一览

为了让你更直观地看到这三者的关系与应用位置，我画了张流程图：

总结：你的第一份混淆规则

不管选哪个工具，核心思路就是一条：保自己想暴露的，藏自己想保护的。你可以在proguard-rules.pro里只写最必要的keep规则：

# SDK暴露接口
-keep public class com.yoursdk.api.SdkEntry { *; }
# 反射类
-keep class com.yoursdk.internal.ReflectionUtils { *; }
# 防止保留过多
-dontshrink

嗯，就这三行。跑一次release构建，然后拖进jadx里看看。如果API接口类名还是清晰的，就对了；如果它们变了，说明keep规则没生效，回去检查minifyEnabled和规则路径。

下一阶段，我们会深入到R8的高级配置和自定义优化规则。先把今天这基础打牢，后面才不慌。