1. 前言
自閒魚引入Flutter後，越來越多的業務場景在Flutter上使用。Flutter的亞秒級熱過載一直是開發者的神兵利器，提供給開發者快速修改UI，增加功能，修復bug，不需要重新啟動應用，即可看到改動效果。
熱過載（HotReload）到底是如何實現的呢？
本文帶你一步步揭開Hot Reload神秘面紗。
2. 原始碼分析
2.1 FlutterTools除錯
想了解HotReload如何執行，首先，我們需要掌握flutter_tools的除錯方法。
我們建立一個名為fluttertest的簡單Flutter專案作為例子。
使用AndroidStudio開啟fluttertools(/flutter/packages/fluttertools)，斷點設定為HotRunner.restart()方法
新增新的Debug Configurations，woking directory設定為fluttertest專案地址
觸發flutter_tools debug按鈕，待app啟動後，簡單改動fluttertest程式碼
在flutter_tools Debug Console中輸入r，開始除錯。
斷點成功！
2.1 HotReload基本流程
那麼HotReload如何執行呢？
當我們使用執行HotReload，無論是透過控制檯輸入r啟動，或是點選閃電執行，最終是執行flutter_tools中的HotRunner.restart(fullRestart: false)方法（上文斷點處）。
restart()方法中，呼叫了_reloadSources(pause: pauseAfterRestart)，正是HotReload的主要程式碼之處。
（/flutter/packages/fluttertools/lib/src/runhot.dart）
Future<OperationResult> _reloadSources({ bool pause = false })
_reloadSources方法中：
首先_updateDevFS()會將工程中檔案逐一掃描，檢查是否有刪除、新增或者改動，掃描完成後，生成kernel files，命名為app.dill.incremental.dill檔案，透過HTTP埠傳送給DartVM;
將掃描生成的.dill檔案路徑，透過RPC介面呼叫_reloadSources，進行資源載入；
確認VM資源過載成功，將FlutterDevice UI執行緒重置，透過RPC介面，觸發flutter widgets樹重建、重繪；
理解這個流程，前提需要明確Flutter的編譯模式。
編譯模式大體可以分為兩種，AOT編譯與JIT編譯。JIT全稱是Just In Time，程式碼可以在程式執行時期編譯，因為要在程式執行前進行分析、編譯，JIT編譯可能會導致程式執行時間較慢；而AOT編譯，全稱Ahead Of Time，是在程式執行前就已經編譯，從開發者修改程式碼到編譯的過程較慢，但執行時不需要進行分析、編譯，因此執行速度更快。
Flutter使用了獨特的編譯模式，開發階段下，使用Kernel Snapshot模式(對應JIT編譯)，將dart程式碼生成標記化的原始碼，執行時編譯，解釋執行；release階段，ios使用AOT編譯，編譯器將dart程式碼生成彙編程式碼，最終生成app.framwork，android使用了Core JIT編譯，dart轉化為二進位制模式，在VM啟動前載入。
因此，基於開發階段的Kernel Snapshot編譯模式下，我們可以得知Hot Reload掃描專案檔案，將有改動的dart檔案轉化為標記化原始碼kernel files，傳送到正在執行的DartVM，DartVM替換資源，然後通知Flutter Framework重建、重新佈局、重新繪製WidgetsTree，即可看到改動效果。
到這裡，我們已經瞭解HotReload基本執行流程，但app.dill.incremental.dill是怎樣的檔案，又怎麼和舊檔案替換的呢？
2.2 增量程式碼掃描
在啟動應用後，啟動HotReload之前，編譯成功後，專案目錄/fluttertest/build檔案中，自動生成了app.dill檔案。
透過strings命令解析，發現是標記化的原始碼，其中包含完整的業務程式碼。
(篇幅較長，只擷取了一部分)
同時，透過adb shell檢查，發現裝置中/data/data/com.loommo.fluttertest/com.loommo.fluttertest/appflutter/flutterassets下，生成三個檔案；
其中，kernel_blob.bin透過strings命令解析，發現內容與app.dill一致；
首次啟動應用後，生成的完整業務程式碼檔案app.dill，在裝置上體現為kernel_blob.bin；
我們啟動HotReload，_updateDevFS()這一步驟執行完畢後，
（/flutter/packages/flutter_tools/lib/src/devfs.dart）
Future<int> update({@required String mainPath,String target,AssetBundle bundle,DateTime firstBuildTime,bool bundleFirstUpload = false,bool bundleDirty = false,Set<String> fileFilter,@required ResidentCompiler generator,String dillOutputPath,bool fullRestart = false,String projectRootPath,@required String pathToReload,})
檢查專案，可以發現專案目錄/fluttertest/build/下新增了app.dill.incremental.dill檔案，透過strings命令解析後，發現僅包含我們所改動的dart檔案。
同時，透過adb shell檢查，發現裝置中/data/data/com.loommo.fluttertest/cache/fluttertestYAYDGJ/fluttertest/lib下，也增加了一個main.dart.incremental.dill ，透過strings命令解析。
果然，與app.dill.incremental.dill內容一致。
而/data/data/com.loommo.fluttertest/com.loommo.fluttertest/appflutter/flutterassets/kernel_blob.bin 沒有改變。
上文中可以知道Flutter Tools生成app.dill.incremental.dill檔案後，透過RPC呼叫_reloadSources，實際觸發的是，Flutter Engine中DartVM Reload方法，該方法中，對.incremental.dill進行增量編譯，替換編譯產物，實現改動檔案的更新。
(/engine/src/thirdparty/dart/runtime/vm/isolatereload.cc)
void IsolateReloadContext::Reload(bool force_reload,const char* root_script_url,const char* packages_url_)
有興趣的同學可以仔細閱讀原始碼。
2.3 WidgetsTree重建
從上文我們可以知道，Hot reload將資源過載完成後，通知flutter framework，觸發widgets樹的重新建立、重新佈局、重新繪製。
那麼，Flutter是如何觸發widgets樹的重建呢？
Flutter framework中BindingBase註冊了名為reassemble的Dart VM服務，用於外部與正在執行的Dart VM通訊，服務觸發後能夠觸發根節點樹重建操作。
服務觸發後，由根節點開始一步步實現widgets樹重建。
BindingBase.reassembleApplication-> WidgetsBinding. performReassemble -> BuildOwner.reassemble -> Element.reassemble 。
（/flutter/packages/flutter/lib/src/foundation/binding.dart）
Future<Null> reassembleApplication()
3. 結語
Flutter不同於以往Native開發，廣受讚譽的，其一便是亞秒級熱過載，理解HotReload的原理，有助於輔助我們日常開發，更為後續動態化方案提供理論支援。