Flutter 编译模式：JIT 与 AOT 的本质差异

回到总览：性能、测试、排障相关模块：Flutter 产物瘦身、AOT 拆包与符号化堆栈还原 (Deobfuscation) · Flutter Impeller 渲染引擎架构与 Shader 编译卡顿消除原理

一句话定义

Flutter 在 debug/profile 用 JIT（Just-In-Time，Dart VM 运行时编译、支持热重载） ，在 release 用 AOT（Ahead-Of-Time，把 Dart 预编译成机器码 libapp.so/App.framework，并做 tree-shaking 瘦身） ——两种模式决定了「能不能热重载」「启动快不快」「包多大」，也是 10 瘦身页里 AOT 拆包与符号化的前置因果。

代码索引

对应 Lab：flutter-jit-aot —— debug(JIT) 与 release(AOT) 产物、启动耗时、热重载差异对比

为什么需要

• 为什么开发时能「热重载」秒级生效，发布后却不行？
  • 一句话答：热重载依赖 JIT：Dart VM 在运行时把改动的代码增量编译并注入正在跑的 isolate，保留原有状态；release 是 AOT 原生机器码，没有 VM 解释/再编译能力，无法在运行中替换代码，所以热重载只在 JIT 模式可用。
• 为什么 release 包启动明显更快、体积却更可控？
  • 一句话答：AOT 在构建期完成编译并做 tree-shaking（剥掉未达代码），运行时不需 JIT 预热、直接跑机器码，启动更快；且死代码被移除，体积更小（详见 10 瘦身页）。
• 为什么线上 Flutter 崩溃堆栈是 #00 0x... 而不是 main.dart:45？
  • 一句话答：release 的 libapp.so 是 AOT 产物，调试符号被剥离（同 10 页 --split-debug-info），必须用构建时保留的 symbols 经 flutter symbolize 还原——这正是 AOT 产物的「副作用」，也是 10 页要解决的。

底层机制

1. JIT 与 AOT 的编译时机差异

• 可能输出（构建模式对照）

  flutter run --debug     # JIT：支持热重载，体积大、启动慢
  flutter build apk --release  # AOT：libapp.so，启动快、可瘦身、符号剥离

• 预期现象：debug 包内含 Dart VM 与 JIT 路径，首帧需编译预热；release 包无 VM、直接执行 AOT 机器码，启动直接进入渲染。

2. 热重载为何只能活在 JIT

热重载的核心是「保留状态增量替换」：VM 把改动的函数重新编译，把新旧代码在 isolate 里做增量替换，不重建 Widget 树状态。

• 预期现象：状态（如输入框文字、页面滚动位置）保留，只刷新受影响的 UI；AOT 模式没有这套运行时编译/注入机制，故不支持。
• 限制：改动全局变量初始化、main()、静态字段、枚举等「结构性」代码时，热重载会失效，需热重启（Restart）。

3. AOT 的 tree-shaking 与产物瘦身因果

AOT 编译前先摇树：只保留从入口可达的代码，不可达的分支/未用库被丢弃，直接减小 libapp.so。

• 可能输出（与 10 页呼应）

  flutter build apk --release --obfuscate --split-debug-info=./build/symbols
  # AOT 摇树 + 混淆 + 符号剥离 → 更小且更安全

• 预期现象：未使用的第三方库函数、dead code 不进产物；混淆与符号剥离进一步减小/保护产物——这就是 10 瘦身页的「因」，AOT 是前提。

Android / Flutter / iOS / Backend 对照

维度	Flutter	Android（ART）	iOS	Backend
开发期	JIT（热重载）	解释/JIT 混合	编译期 AOT	JVM JIT / GraalVM AOT
发布期	AOT（机器码）	ART 安装时/运行时编译	AOT（App Store）	多 JIT；GraalVM 可 AOT
热更/热载	JIT 热重载	无（需发版/Instant Run 弃）	无	热部署（部分容器）
体积影响	AOT 摇树瘦身	ART 编译缓存	无 JIT	AOT 镜像较大

常见场景

• 开发迭代：用 --debug/JIT 享受热重载，改 UI/逻辑秒级看效果，避免每次全量重编。
• 发版构建：用 --release/AOT，关掉 JIT 开销、开 tree-shaking 与混淆，拿到小且快的包。
• 启动性能治理：AOT 消除了 JIT 预热，但若 main() 里做重同步初始化仍会拖慢首帧；需配合 04 启动优化页。

常见误配、事故后果与排障

1. 误配：把 debug（JIT）包当 release 发出去

• 现象：包体巨大、启动慢、易卡，且无混淆/符号剥离，代码裸露。
• 排障与修法：发布必须用 --release（AOT）；CI 显式区分 debug/release 产物，禁止把 debug 包推商店。

2. 误配：线上崩溃拿不到可读堆栈（符号未归档）

• 后果：AOT 产物符号剥离，没保留 symbols 就无法 flutter symbolize，崩溃定位不了。
• 排障与修法：同 10 页——CI 把 ./build/symbols 永久归档；崩溃上报后用 flutter symbolize -i crash.txt -d symbols 还原。

3. 事故：期望 release 包也能热重载，做了「运行时换代码」方案

• 后果：AOT 无 JIT/VM 注入能力，这类方案在 release 直接失效或需引入受限的动态化（见 05/08 热更新页）。
• 排障与修法：release 的「逻辑更新」走正规发版或 JS/资源级热更（Flutter 受限），不要假设能像 debug 那样运行时替换 Dart 代码。

相近概念对比

概念	它是什么	易混点
JIT	运行时编译，支持热重载	启动慢、包大、不能发布
AOT	构建期编译成机器码	无热重载，但快且小
tree-shaking	AOT 前的可达性摇树	是 AOT 瘦身的根因，非独立步骤
符号剥离	减小/保护 AOT 产物	必须另存 symbols 才能还原崩溃

对应实验

实验	说明	关键源码
flutter-jit-aot	对比 debug(JIT) 与 release(AOT) 产物、启动耗时与热重载行为	代码内联于 README

复习检查题

1. 热重载为什么只能在 debug（JIT）模式用，release（AOT）不行？ 答：热重载依赖 Dart VM 在运行时把改动的代码增量编译并注入正在运行的 isolate，同时保留原有 State。release 是 AOT 原生机器码，构建期已编译完成、运行时不带 VM 的再编译/注入能力，无法在运行中替换代码，所以热重载是 JIT 专属；release 若改代码只能重新发版（或受限的动态化）。

2. AOT 为什么既能让启动更快、又能让包更小？这两件事的因果是什么？ 答：AOT 在构建期把 Dart 直接编译成机器码，运行时无需 JIT 预热即可执行，所以启动更快；同时编译前会做 tree-shaking，只保留从入口可达的代码，丢弃未用分支与库，使 libapp.so 更小。二者同源——都是「构建期完成编译与裁剪」，运行期不再背负 VM 与死代码。

3. 为什么 Flutter release 崩溃堆栈是地址、而 debug 不是？怎么还原？ 答：release 的 libapp.so 是 AOT 产物，为减小体积做了符号剥离，只剩指令地址；debug(JIT) 带完整符号所以可读。还原要用构建时保留的 symbols 文件，经 flutter symbolize -i crash.txt -d ./symbols 把地址映射回 文件:行号。符号文件必须随发版归档，否则历史崩溃不可读（与 10 瘦身页、12 Native 崩溃页同源）。

速记

• JIT：运行时编译 + 热重载 + 状态保留；代价是慢、大、不可发。
• AOT：构建期编译机器码 + 摇树瘦身；快、小、安全，但无热重载。
• 热重载失效边界：全局/静态/枚举/main 改动需热重启。
• 符号即命脉：release 剥符号，必归档 symbols 才能 flutter symbolize。