发布Android应用到Google Play前如何测试ProGuard是否正常工作？

你提到的自定义带混淆的debug构建类型的方案完全可行，这也是Android官方推荐的本地化验证ProGuard配置的标准操作。

这套自定义构建类型的核心价值，就是保留debug构建的全部调试优势——支持断点调试、安装部署速度快、默认开启日志输出，同时开启和正式版本一致的代码压缩、资源压缩、混淆规则，最大程度复现正式包的构建效果，从根源上避免“本地调试正常、上线后故障”的问题。

在实际用这个方案测试时，有几个细节需要注意，否则很容易出现测试结果和正式包不一致的情况：

• 统一ProGuard配置文件：你当前的debugMini构建用的是未开启代码优化的proguard-android.txt，但release构建配置里用的是带优化逻辑的proguard-android-optimize.txt。如果你的正式版本要开启代码优化功能，测试时也需要替换成同一个默认规则文件，否则两套配置的压缩逻辑、混淆规则不统一，很可能测试时一切正常，正式打包就出问题。
• 确认ProGuard流程真正生效：开启开关不代表流程跑通了，构建完成后可以去对应构建类型的输出目录（app/build/outputs/mapping/debugMini/）检查有没有生成mapping映射文件、被移除代码清单、资源压缩日志，这些文件正常生成，才说明ProGuard确实执行了压缩和混淆操作。

除了自定义构建类型测试，你在正式发布到Google Play前，还可以按这个流程完成全链路验证：

1. 用自定义的混淆debug包安装到测试机，走完全部核心业务路径（包括登录、核心操作、第三方SDK调用这些容易触发反射逻辑的模块），确认没有类找不到、方法不存在、资源被误删的报错。
2. 本地直接跑一次完整的签名release构建，把生成的安装包安装到测试机上跑一遍流程——很多开发者会跳过这步，以为测了混淆debug包就够了，但release构建除了ProGuard处理，还会执行签名对齐、资源AOT编译等额外流程，很容易出现测试包没暴露的问题。
3. 提前给容易被ProGuard误删的逻辑加保留规则：比如反射调用的类、序列化/反序列化的实体类、WebView的JS交互接口、第三方SDK要求保留的接口，不要等线上报错了再补规则。

你之前观察到的“Android Studio直接运行正常、发布后应用故障”的现象，本质就是debug构建默认不启用ProGuard，所有代码都完整保留，不管是直接调用还是反射调用都能正常找到；而开启ProGuard后，如果没有配置对应的保留规则，运行时需要动态查找的类、方法会被直接移除或者重命名，自然就会出现运行时崩溃。

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