GWT编译器draftCompile与optimize 0参数有什么区别

各自实际作用 #

• optimize：是数值型档位参数，取值范围0-9，仅控制编译器代码优化阶段的执行强度：
  • 档位越低，跳过的优化流程越多，0档直接关闭全部优化动作，包括方法内联、死代码裁剪、常量折叠、类型特化这些耗时较长的优化pass，9档跑完全量优化逻辑
  • 这个参数不会改动编译流程中优化阶段以外的任何步骤，比如多版本适配编译、代码校验、产物附加信息生成这些流程不受它影响
• draftCompile：是面向开发调试场景的布尔型快捷开关，设计目标就是最大化压缩开发时的编译等待时间，它的调整范围覆盖整个编译流程，不止改优化等级：
  • 自动将优化等级设为最低，效果和optimize 0一致
  • 跳过编译后的代码混淆校验、压缩一致性校验等发布前才需要的静态检查步骤
  • 针对多permutation编译场景（即需要适配不同浏览器、不同本地化语言的项目），默认只编译当前开发环境匹配的单个适配版本，不会全量编译所有目标版本
  • 跳过全量sourcemap生成、编译统计报告生成这类非必要的附加产物输出

二者效果对比与搭配规则 #

• 二者效果完全不等同：draftCompile的作用范围远大于单独设置optimize 0，后者只是前者生效时自动配置的其中一个子项而已
• 不需要刻意搭配使用：
  • 开启draftCompile时无需额外传入optimize 0，前者已经默认启用最低优化等级，重复传参不会带来额外的编译速度提升
  • 仅设置optimize 0时，不会触发draftCompile包含的跳过非优化流程的逻辑，编译速度会明显慢于开启draftCompile的状态

测试无速度差异的原因 #

测试时同时传入optimize 0+draftCompile和仅传optimize 0编译时长无明显差异，基本是因为当前遗留项目已经做了如下配置：

• 提前关闭了多permutation全量编译，比如手动指定了仅编译单个浏览器适配版本、关闭了多语言全量构建
• 全局关闭了编译后静态校验、全量sourcemap生成、编译报告输出这类附加步骤
  这种场景下draftCompile能额外跳过的流程本来就没有执行，自然感知不到速度差，和参数本身的逻辑无关。

编译提速参考 #

• 本地开发调试场景：直接开启draftCompile即可，无需额外调整optimize参数，能获得最快的编译速度
• 测试包构建场景：如果需要保留基础校验逻辑、避免编译出的包有隐性兼容问题，可以手动设置optimize 0，不开启draftCompile，平衡编译速度和产物可靠性
• 正式发布场景：关闭draftCompile，使用默认的高优化等级即可，保证产物运行性能

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