一，需求背景：
APP 发布到市场后，难免会遇到严重的 BUG 阻碍用户使用，因此有在不发布新版本 APP 的情况下使用热更新技术立即修复 BUG 需求。原生 APP（例如：Android & IOS）的热更新需求已经比较成熟，但 Flutter 技术栈目前还缺少类似的技术方案，因此 Flutter 研发团队，也需要类似的热更新技术。
二，Flutter 热更新技术方向分析：
经过分析目前可能有三种可行的方案：1）类似 RN 框架；2）页面动态组件框架；3）Dart 虚拟机定制方案；
|--------------|--------------------------------------------------------------------------------------------|-------------------------------------------------|---------------------------------------------------------------|-----------------------------|
| 方案名称 | 原理 | 优点 | 缺点 | 开源方案 |
| 类似 RN 的方案 | 用 JS 以 Flutter 语法写 dart，然后用 JavaScript 把 XML DSL 转为 Flutter 的原子 widget 组件，然后再让 Flutter 来渲染 | 由于 ios 系统内置支持 js，ios 上完全可以实现更新 | 1) 由于跨语言执行，对于性能有影响；学习成本高 2) Android 端需要额外引入 JS 库 | 手 Q 的 MXFlutter，58 同城的 Fair |
| 页面动态组件方案 | 编译期时插桩 / 预埋好 DynamicWidget 到代码中，然后动态下发 Json 数据，通过协定好的语义匹配到 JSON 内的数据，动态替换 Widget 内容来实现更新 | 能支持 Android/iOS 两端的更新 | 1）UI 更新相对较容易，业务逻辑动态化较麻烦；2）语义解析器开发成本相对较大，且不易维护 3）需要一整套前后端服务和工具 | 天猫的 Tangram，淘宝的 DinamicX 等 |
| Dart 虚拟机定制方案 | 通过分析 Dart 虚拟机的原理，修改 Flutter Engine 层 Java/C++ 代码实现热更新的目标； | 性能影响小，动态性很高，技术上可以替换所有 Flutter 页面（包括 UI，逻辑，资源文件） | 由于使用的是定制引擎，需要维护不同版本的 Flutter 引擎代码； | 未开源 |
因为其他方式都有开源的示例，本案将重点以第三种 "Dart 虚拟机 定制方案" 为目标，做方案的研究讲解。
三，预备知识
在开始了解技术方案之前，需要提前了解一些相应的技术概念：
3.1 Flutter 编译模式
Flutter 开发语言是 Dart，它的编译模式来自 Dart 的编译模式，主要有 JIT (Just In Time) 和 AOT (Ahead Of Time)。
|--------|--------------------------------------------------|----------------------------------|---------------------------------------------------------------------|
| 编译模式名称 | 特点 | 优点 | 缺点 |
| JIT | 即时编译，典型例子 V8，它可以即时编译运行 JS，只需要输入源代码字符串，就可以编译运行代码 | 可以动态下发和执行代码，不用管 CPU 架构，可以提供动态化内容 | 1, 大量字符串代码让 JIT 编译器花费时间和内存；2, 性能不好； |
| AOT | 预先编译，典型例子 C/C++，通过 GCC 编译成二进制代码，然后安装取得权限后才可以加载执行 | 事先编译好的，加载和执行速度快 | 1, 编译时区分 CPU 架构；2, 生成的二进制代码包比较大；3, 二进制代码需要取得权限才可以执行，无法在 ios 系统上动态更新 |
Flutter 编译模式有：Debug，Release，Profile；
|--------------|--------------------------------------------------------------|
| Flutter 编译模式 | 特点 |
| Debug | 对应 JIT 模式，支持设备和模拟器；打开了断言，支持快速开发，支持 HotReload；并未对包大小，执行速度做优化； |
| Release | 对应 AOT 模式，支持真机，不支持模拟器；禁止了所有断言调试信息；对包大小，启动和执行速度进行了优化； |
| Profile | 类似 Release 模式，保留了一些调试功能，帮助性能分析； |
3.2 Flutter 编译产物分析 Flutter 下的 iOS/Android 工程本质上是一个标准的 iOS/Android 的工程；IOS 平台： Flutter 通过在 BuildPhase 中添加 shell (xcode_backend.sh) 来生成和嵌入 App.framework 和 Flutter.framework 到 ios; Android 平台： Flutter 通过 gradle 来添加 flutter.jar 和编译完的二进制文件添加到 Android;3.2.1 引擎层结构分析：
3.2.2 Android 编译产物的分析
3.2.3 IOS 编译产物的分析
四，热更新技术方案分析
4.1 业务代码分析
根据 "3.3.1" ～"3.3.2" 的分析可以确定无论是 IOS 还是 Android APP 业务代码都是由四个段组成：kDartVmSnapshotData、kDartVmSnapshotInstructions、kDartIsolateSnapshotData、kDartIsolateSnapshotInstructions；理论上只要能动态替换加载的代码段 & 数据段代码即可实现目标。
|----------------------------------|------------------|------------------------------------------|-------------|
| 名称 | 注释 | 作用 | 注释 |
| kDartIsolateSnapshotData | Dart isolate 数据段 | 类信息，全局变量，函数指针等 | 允许动态下发 |
| kDartIsolateSnapshotInstructions | Dart isolate 指令段 | 包含由 Dart isolate 执行的 AOT 代码 | IOS 不允许动态下发 |
| kDartVmSnapshotData | vm isolate 数据段 | isolate 之间共享的 Dart 堆 (heap) 的初始状态 | 允许动态下发 |
| kDartVmSnapshotInstructions | vm isolate 指令段 | 包含 VM 中所有 Dart isolate 之间共享的通用程序的 AOT 指令 | IOS 不允许动态下发 |
注释：isolate, snapshot, vm isolate 含义解释如下：
|------------|----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| 名称 | 含义 |
| isolate | Dart 是单线程，isolate 跟线程差不多，可以理解为 Dart 中的线程。isolate 与线程的区别：线程与线程之间是共享内存的，而 isolate 和 isolate 之间是内存不共享的。不存在锁竞争问题，两个 Isolate 完全是两条独立的执行线，且每个 Isolate 都有自己的事件循环，它们之间只能通过发送消息通信，所以它的资源开销低于线程。 |
| snapshot | 将类信息、全局变量、函数指令直接以序列化的方式存在磁盘中，称为 Snapshot（快照）。 |
| vm isolate | 同一个进程里可以有很多 isolate，但两个 isolate 的堆区是不能共享的，所以官方设计了 VM isolate，也就是 kDartVmSnapshot，用来多个 isolate 之间的交互。 |
4.2 业务代码的加载分析（运行时）
按照 4.1 的分析思路，我们首先需要了解 Flutter 运行时代码加载的完整流程，经过梳理分析流程如下：1 ）Android- APP 业务代码的加载流程：
2）IOS- APP 业务代码的加载流程：
4.3 业务代码的编译生成（编译时）
根据以上的分析，我们知道了 Flutter 业务代码的数据结构，也知道了在运行时如何加载，因此我们只需要在编译时做更改，产生自己需要的代码段，和数据段文件。在运行时加载自己的构建产物即可达到目标。1）在此以 IOS 构建自己的业务代码流程做详细分析：
** 有完成构建流程可以分析，基本流程是 "Dart Code（业务代码）" -> (通过 Dart 编译器 gen_snapshot.cc) 生成 snapshot_assemble.S 的汇编文件 -> (通过 xcrun 工具) 生成 snapshot_assemble.o 的 obj 文件 -> (通过 xcun clang 工具链) 生成了 App.Framework。2）Android 的产物构建流程和 IOS 类似。由于 Android 有其他更简单的方案， 因此省略详细的构建流程分析，大致如下：
4.4 实现热更新的方案探索
根据上面的技术分析结果，已经可以独立生成自己的代码段，数据段文件。通过需改虚拟机底层代码的方式，也可以动态的加载运行。但由于 IOS 系统目前底层的系统还不能动态加载可读写的代码段数据到内存中，所以还有技术难点需要突破。但 Android 端有更简单的路径可以解决，因此下面以 Android 端为例重点分析思路，大致如下图所示：
由上图可以得知，Android 端 热修复核心步骤如下：
1， 修改 Flutter Engine 代码，加载指定路径的 libapp.so 和 flutter_aasets，比如私有目录 (data/data/files)；
2， 编译 APK 时，利用 Gradle Transform 插件，根据 Flutter SDK 的 engine version 动态替换官方的 Flutter engine，最终写入修改后的 engine 到 APK；
3， 生成补丁包：利用 BSdiff 算法比较新旧 APK 文件，生成 patch 补丁包
4， APP 启动时访问后端接口，根据参数（app 的版本号，补丁包版本号，md5，flutter SDK 版本号，Engine 版本号）拉取补丁包；
5， 合成补丁包：校验 md5，app 版本号，补丁版本号，安装时间；
6， 自定义 Flutter Engine 加载指定路径的 libapp.so 和 flutter_assets 资源文件；