使用GraalVM native-image编译前对Java应用做Proguard混淆是否有收益？

首先可以明确，你的认知存在部分偏差：ProGuard的功能不止是符号重命名混淆，native-image编译后的二进制也并非完全不存在任何Java层的符号残留，两者搭配使用是存在实际收益的。

1. 认知的正确性边界 #

• 原生二进制确实不会保留完整的Java类、方法、字段的原名称符号用于常规程序执行，但两类场景下符号会残留：
  • 如果你开启了栈追踪输出能力，运行时报错的异常栈里仍然会打印类、方法名，这部分内容如果没有经过ProGuard混淆，会直接暴露原始代码结构
  • 部分反射、资源加载的相关配置如果没有完全裁剪，也可能将原始类名、方法名硬编码到二进制中
• ProGuard除了混淆重命名之外，还有代码裁剪的核心功能：它会移除项目中完全没有被调用到的类、方法、字段，这部分裁剪是在字节码层面完成的，能有效减少输入给native-image的字节码体积，最终也会降低生成的二进制文件的大小，同时加快native-image的编译速度

2. 实际存在的收益场景 #

• 反破解难度提升：即使是原生二进制，有经验的逆向人员仍然可以从字符串常量、异常栈信息、JNI调用关联的符号中反推代码结构，ProGuard的混淆会把这部分残留的符号全部替换成无意义的a、b、c之类的单字符，大幅提升逆向成本
• 二进制体积优化：ProGuard的字节码裁剪可以移除大量未使用的依赖代码，尤其是引入了较多第三方SDK的项目，裁剪后的字节码输入给native-image后，最终生成的二进制体积最多可以减少30%以上
• 规避部分native-image编译问题：部分第三方库包含大量不会被用到的反射、动态代理代码，ProGuard裁剪掉这部分代码后，可以减少native-image编译阶段需要处理的配置项，降低出现编译错误、运行时反射缺失的概率

3. 适用边界说明 #

如果你的项目本身没有逆向防护需求、且代码体积已经很小，使用ProGuard带来的收益会非常有限，反而会增加规则配置成本，这种场景下可以不用额外加ProGuard处理流程。

内容的提问来源于stack exchange，提问作者Bojan Vukasovic