本文要点：

一、前言

1.1 热重载是什么?

熟悉JS的同学，可能会嗤之以鼻，在N年前就已经用上热重载了，但是对客户端开发人员来说，简直是福音。

那先来看下Flutter官方的定义：

简单来说，就是通过将修改后的源代码文件注入到正在运行的 Dart 虚拟机来实现，注入之后， Flutter 会自动重新构建 widget 树。

1.2 为什么需要热重载?

程序猿在刀耕火种的时代，开发调试是这样子的：

当项目不大，人数不多的情况下，画面是非常和谐的，效率也是毋庸置疑的高效。但现实是，在大公司，项目往往很大，编译巨慢无比，同时开发人员众多，有着非常严格的流程制度，导致看起来本没有问题的开发调试流程，变得异常的痛苦，降低了个体的效率，这里强调下，指的是个体的效率，个人认为越是完善的流程体系，对个体的约束往往越强，但从团队的角度去看待效率，一定是能1+ 1 大于 2 的。

而此时的心情是这样子的：

而有了热重载，开发调试是这样子的：

心情也就成这样子的：

1.3 抛出问题

从热重载定义来看，不少人脑子里蹦出不少跟我一样的疑惑：

同时在日常使用热重载的过程中，也会碰到不少这样那样的疑惑：

当你在网上看过大量热重载文章后，又衍生了额外的问题：

不急，本文会对上述疑问进行一一解答。

二、dart的热重载

由于Flutter采用dart作为开发语言，我们先从dart角度来验证下热重载。

2.1 编写验证demo

考虑到dart执行完会关闭当前进程，我们写了个定时器来保证进程存活，同时能看到热重载效果。

2.2 开启VMService

终端下执行 dart --enable-vm-service main.dart，其中的main.dart为2.1中代码文件：

可以看到终端会不断输出"Hello JDFlutter"的字符。

2.3 执行热重载

我们将main.dart文件中打印日志修改为”Hello JD”，同时打开终端输出的Observatory链接地址，如下：

找到我们main.dart的Isolate(读者可以简单理解为是dart中的线程，只不过Isolate没有共享内存)，图中红圈部分，进入后找到ReloadSource：

点击Reload Source后，终端开始输出”Hello JD”的字符，完成了一次热重载过程，如下图：

2.4 自动化热重载

还是以上面为例子基础例子，我们加入文件监听，并且通过发送消息给vm_service来实现热重载，代码如下：

直接运行 dart --enable-vm-service main.dart，期间修改”Hello JDFlutter”为”HelloJD”，运行结果如下：

可以看出，我们成功实现了自动化热重载，上述代码跟Dart虚拟机通信步骤如下：

2.5 Dart虚拟机可做的事情

到这里，大家可以放飞自我，Dart Service提供了大量对外协议，包含断点、获取虚拟机状态，性能等协议，可以参考：Dart虚拟机服务接口。

三、Flutter的热重载

Flutter的热重载，本质是在封装dart热重载并且对不同的设备启动安装加载等流程，接下来准备好在Flutter源码世界里翱翔吧，以下分析基于v1.22.5分支的源码。

俗话说，工欲善其事必先利其器，在源码翱翔久了，容易迷茫，找不到东西南北，看到关键方法，又不知道是不是代码真实的case，需要能验证我们的想法，最简单的办法打断点，有针对性的去看源码。

3.1 IDE断点

Flutter源码的下载也很简单，这里就不赘述了，大家可以上网搜下。Flutter工具链的源码位于packages/flutter_tools下。

本文是通过Android Studio(比较熟)来配置和查看源码，配置如下：

一顿配置下来，就可以用工具链完美的debug指定Flutter工程的源码，接下来就是选好设备，点击debug按钮，如下图：

3.2 整体流程

以下是Flutter热重载流程图：

简述为：

整个过程并没有让App重启，从而达到高效开发调试效果。

3.3 源码分析

3.3.1 run命令流程

我们从flutterrun命令为入口分析，类位于packages/flutter_tools/lib/executable.dart中的main()方法，run命令最终实现类位于packages/flutter_tools/lib/src/commands/run.dart。

RunCommand在构造函数中默认开启了hot标识，如果需要关闭，要新增入参--no-hot。

从run命令的流程，可以看出，主要是做了默认参数设置，参数校验，flutter设备初始，模式判断等，热重载是从HotRunner.run中开始执行。

3.3.2 热重载流程-首次启动

在HotRunner中，流程也并不复杂：

可以看出，HotRunner做了三件事：

第二步会涉及到不同平台不同做法，对iOS和Android来说，分别对应xcrun和adb，不是本文重点，流程也比较长，有机会再展开讲，重点说第一步和第三步。

编译生成dill文件

最终调用到_compile方法，代码太过于繁琐，我们直接断点看，如下：

从断点信息可以获知，dart文件会被转为kernel文件app.dill，以下截取部分app.dill内容，可以看出app.dill是一份完整的代码文件，包含了main.dart的内容，右边为main.dart源文件，左边为app.dill文件内容：

生成的app.dill是一份全量的代码，接下来编译不同设备(Android、iOS)的安装包，同时运行指定的包。

此时生成app.dill的进程，我们暂且称为“编译进程”，后续热重载增量的dill，也是驱动该进程生成。

attach设备

在上述的第二步，设备在启动运行App时，会打开App中DartVM的Observatory服务，本质是一个websocket服务，按照自定义的jsonrpc2.0协议进行通信，在attach时，会通过URI连接上设备服务，如下图：

连上DartVM服务后，会注册几个热重载事件：reloadSources，reloadMethod，hotRestart，这几个事件并不是注册到App中的Dart虚拟机，而是提供给fluttertool其他命令使用，如下图：

同时通过DartVM服务，来初始设备中flutter产物，设备中产物路径是临时生成，用XXX代替，产物路径为：

具体代码如下：

3.3.3 触发热重载

下面分别从源码角度，看看到底做了什么?

开发者在执行flutter run或者flutter attach后，在终端中输入r，即可体验到重载效果，如果在AndroidStudio和VSCode中，直接Ctrl+S或者Cmd+S即可。

对应到源码入口：

不管是HotReload还是HotRestart，最终都是调用HotRunner.restart方法，一路跟进，最终会到某个具体设备update方法，并再次调用上述《热重载流程-首次启动》中的_compile方法，通知编译进程生成增量的dill文件app.dill.incremental.dill。那这个增量文件到底是什么呢?demo中修改字符串"FlutterDemo Home Page"为"Flutter Demo Home Page2"，来看看dill文件内容：

第一张图为修改前，第二种为修改后，第三张为增量的dill内容。可以看出增量的dill文件仅包含改动的dart文件代码。

生成增量的dill后，会通过_DevFSHttpWriter写入设备，如下图：

当同步完增量文件，最后还需要通知DartVM去刷新UI界面，这个步骤就跟我们上述的2.4节内容类似：

vmService.reloadSources最终调用了_call方法，这是一个dart官方库，如下：

HotRestart与HotReload区别

Flutter官方提供两种快速调试方法，一种是HotReload，另一种是HotRestart。前者无感知局部刷新，体验最好，但是缺点也很明显，适用比较局限，可以参考官网给出样例：HotReload，主要有这几种场景不适用：

而在HotRestart流程中，相比HotReload流程，增加了清除资源操作，同时不再生成增量的dill文件，每次改动都是生成全量的app.dill文件，该细节就不展开，感兴趣读者可以debug源码看。

上述可以看出HotRestart额外处理了一些事情，包括杀掉非UI的isolate，重置UI的isolate等。

对于dill文件同步到设备中位置，不同设备不一样：

至此，热重载源码就告一段落，很多奇技淫巧并不能一一展现，值得大家动手去看看。

四、总结

经过上述一顿探索，文章最早提出的几个疑问，想必都有了答案。这里只是介绍了Flutter源码的冰山一角，更多源码还需要继续探索，通过阅读源码，可做的事情很多：

总之，可做的事情很多，那我们看源码的意义就非常清晰：

五、参考资料