4. 构建与编译优化

Flutter 的构建与编译优化，核心目标不是“让编译更快”这么简单，而是同时平衡三件事：运行时性能、启动速度、安装包体积。这三者之间存在明确的取舍关系，理解 Dart 的两种编译模式以及构建工具链在背后做了什么，才能做出正确的工程决策。

一、AOT 与 JIT：两种编译模式的本质差异

Dart 代码在 Flutter 中有两条执行路径。JIT（Just-In-Time）在运行时将 Dart 源码或内核文件（dill）编译为机器码，支持热重载，但需要携带编译器与内核文件，启动时存在解释与编译开销。AOT（Ahead-Of-Time）在构建阶段就把 Dart 编译为平台原生机器码，运行时直接执行，启动快、CPU 占用低，但无法热重载。

Flutter 的默认策略是：Debug 模式使用 JIT，Profile 与 Release 模式使用 AOT。这意味着你在开发时享受热重载，在发布时获得原生性能。需要特别注意的是，flutter run --release 在移动端会走 AOT，但在 Web 上走的是 dart2js/dart2wasm，属于另一条链路。

选择模式时可以参考以下判断：需要热重载调试用 Debug/JIT；需要真实性能数据用 Profile/AOT；需要发布上线用 Release/AOT。不要用 Debug 模式的性能数据去推断线上表现，JIT 的启动和帧率数据没有参考价值。

二、Tree Shaking：让未使用的代码不进入产物

Tree Shaking 是 AOT 构建中的关键优化。Dart 编译器会从入口 main() 出发，沿调用图标记所有可达的类、函数和常量，未被标记的代码在生成机器码时被丢弃。这对包体积的影响非常直接：一个引入了大型工具库但只用了其中一两个函数的项目，最终产物不会包含整个库。

但 Tree Shaking 有一个重要限制：它依赖静态可达性分析。通过反射、动态字符串拼接调用、或 dart:mirrors 使用的代码无法被正确标记，可能被误删或在运行时失败。Flutter 中更常见的问题是图标字体：如果你使用 IconData 的动态构造方式，编译器无法识别具体码点，会保留整个 MaterialIcons 字体（约 1.6MB）。正确做法是使用常量图标，构建时 Flutter 会自动生成精简字体子集。

验证 Tree Shaking 是否生效，可以在构建日志中观察 --tree-shake-icons 的输出，或对比开启前后的 APK 体积。如果发现图标字体没有缩小，优先检查是否存在动态 IconData。

三、代码分割与延迟加载

Flutter 的代码分割能力主要体现在两个层面。第一是 deferred as 延迟加载，它允许把部分 Dart 库拆分为独立的 part 文件，在首次使用时才加载。这对包含大型功能模块（如富文本编辑器、地图 SDK、PDF 渲染）的应用非常有效。

import 'package:my_app/heavy_feature.dart' deferred as heavy;

Future<void> openHeavyFeature() async {
  await heavy.loadLibrary();
  heavy.showHeavyPage();
}

需要注意，deferred 加载在移动端 AOT 下会生成额外的 part 文件，首次加载有 IO 与解析开销，因此适合“低频但体积大”的模块，不适合首屏路径。第二是平台资源的分割，Android 的 App Bundle 会按 ABI、屏幕密度、语言自动拆分，用户只下载匹配自己设备的资源。启用方式是使用 flutter build appbundle 而非 flutter build apk。

四、包体积控制的实操手段

包体积优化应该先测量再动手。使用 flutter build apk --analyze-size 可以生成体积分析报告，明确每个部分占用了多少空间。常见的体积构成与对应手段如下：

在 pubspec.yaml 中，可以通过 flutter: 段配置资源与字体的精细控制。对于图片，建议使用 2.0x、3.0x 多倍图目录，让系统按设备密度选择。对于字体，只声明实际使用的字重，避免打包整个字体家族。

五、构建配置的工程化建议

把优化固化到 CI 流程中，比每次手动执行更可靠。建议在构建脚本中统一使用以下参数：

flutter build appbundle \
  --release \
  --tree-shake-icons \
  --split-debug-info=build/symbols \
  --obfuscate \
  --target-platform android-arm,android-arm64

同时建立体积基线：每次发布记录 APK/AAB 体积，设置增长阈值（例如单次增长超过 500KB 触发审查）。体积的突然增长往往对应着新引入的大型依赖或未压缩资源，早发现比上线后补救成本低得多。

总结来看，AOT/JIT 的选择由构建模式决定，工程上应确保发布走 AOT；Tree Shaking 是自动的，但需要避免动态调用破坏可达性分析；代码分割适合低频大模块；包体积控制则依赖测量、拆分与持续监控。把这四件事纳入构建流程，才能在性能与体积之间取得稳定平衡。