Baseline Profiles搭配R8/Proguard混淆时的类映射与性能生效问题

这里核心是混淆了两个不同构建变体的用途，Baseline Profile工具链本身已经和R8做了全链路打通，不存在规则和生产dex类名不匹配的问题，核心逻辑如下：

1. -dontobfuscate规则的作用范围 #

官方要求添加-dontobfuscate的是MacroBenchmark专属的测试目标构建变体，并非生产release构建：

• 这个测试构建的核心用途是跑性能基准测试，要求代码执行逻辑、性能表现和生产release完全一致，因此需要开启minification、对齐release的所有R8优化规则
• 单独加-dontobfuscate只是为了避免混淆后测试代码无法直接调用目标页面、目标方法，导致基准测试流程跑不通。这个构建生成的性能数据用来对比优化效果，它产出的原始profile规则只是中间产物，不会直接打进生产包。

2. R8对Baseline Profile的自动映射处理 #

AGP从7.1版本开始就内置了R8和Baseline Profile的联动转换逻辑，整个过程不需要开发者手动干预：

• 收集到的原始baseline-prof.txt里记录的是测试构建下的类、方法签名，标记了哪些代码路径需要在应用安装时提前做AOT编译
• 构建开启混淆的生产release包时，R8在执行代码压缩、混淆、优化的全流程中，会同步读取原始profile规则，结合自身生成的类/方法映射表，把所有规则里的原始类名、方法签名替换成混淆后的对应名称
• 对于那些被R8裁剪掉、最终不会出现在classes.dex里的无效代码对应的profile规则，R8会自动过滤删除，避免无效规则影响运行时
• 最终打包进生产APK/AAB的Baseline Profile文件，所有规则都和混淆后的dex内容完全匹配，运行时ART虚拟机可以直接读取规则执行提前编译，不会出现类找不到的问题。

3. 常见配置注意事项 #

• 不要把-dontobfuscate规则加到生产release构建的Proguard规则里，否则会直接关闭生产环境的代码混淆，带来安全风险
• 尽量升级AGP到8.0及以上版本，早期7.x版本存在部分场景下profile规则映射不全的问题，8.0之后这套转换逻辑已经完全稳定
• 生成原始profile时，确保测试构建的代码逻辑和生产release完全一致，不要额外添加debug日志、测试专用代码，否则会导致收集到的规则偏离生产实际的代码路径，降低优化效果。

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