來(lái)源 | OSCHINA 社區(qū)

作者 | 京東云開(kāi)發(fā)者-京東科技 劉振中、周智

一，需求背景：

APP 發(fā)布到市場(chǎng)后，難免會(huì)遇到嚴(yán)重的 BUG 阻礙用戶(hù)使用，因此有在不發(fā)布新版本 APP 的情況下使用熱更新技術(shù)立即修復(fù) BUG 需求。原生 APP（例如：Android & IOS）的熱更新需求已經(jīng)比較成熟，但 Flutter 技術(shù)棧目前還缺少類(lèi)似的技術(shù)方案，因此 Flutter 研發(fā)團(tuán)隊(duì)，也需要類(lèi)似的熱更新技術(shù)。

二，F(xiàn)lutter 熱更新技術(shù)方向分析：

經(jīng)過(guò)分析目前可能有三種可行的方案：1）類(lèi)似 RN 框架；2）頁(yè)面動(dòng)態(tài)組件框架；3）Dart 虛擬機(jī)定制方案；

因?yàn)槠渌绞蕉加虚_(kāi)源的示例，本案將重點(diǎn)以第三種 “Dart 虛擬機(jī)定制方案” 為目標(biāo)，做方案的研究講解。

三，預(yù)備知識(shí)

在開(kāi)始了解技術(shù)方案之前，需要提前了解一些相應(yīng)的技術(shù)概念：

3.1 Flutter 編譯模式

Flutter 開(kāi)發(fā)語(yǔ)言是 Dart，它的編譯模式來(lái)自 Dart 的編譯模式，主要有 JIT (Just In Time) 和 AOT (Ahead Of Time)。

Flutter 編譯模式有：Debug，Release，Profile；

3.2 Flutter 編譯產(chǎn)物分析

Flutter 下的 iOS/Android 工程本質(zhì)上是一個(gè)標(biāo)準(zhǔn)的 iOS/Android 的工程；IOS 平臺(tái)： Flutter 通過(guò)在 BuildPhase 中添加 shell (xcode_backend.sh) 來(lái)生成和嵌入 App.framework 和 Flutter.framework 到 ios; Android 平臺(tái)： Flutter 通過(guò) gradle 來(lái)添加 flutter.jar 和編譯完的二進(jìn)制文件添加到 Android;

3.2.1 引擎層結(jié)構(gòu)分析：

3.2.2 Android 編譯產(chǎn)物的分析

3.2.3 IOS 編譯產(chǎn)物的分析

四，熱更新技術(shù)方案分析

4.1 業(yè)務(wù)代碼分析

根據(jù) “3.3.1” ～“3.3.2” 的分析可以確定無(wú)論是 IOS 還是 Android APP 業(yè)務(wù)代碼都是由四個(gè)段組成：kDartVmSnapshotData、kDartVmSnapshotInstructions、kDartIsolateSnapshotData、kDartIsolateSnapshotInstructions；理論上只要能動(dòng)態(tài)替換加載的代碼段 & 數(shù)據(jù)段代碼即可實(shí)現(xiàn)目標(biāo)。

注釋?zhuān)篿solate, snapshot, vm isolate 含義解釋如下：

4.2 業(yè)務(wù)代碼的加載分析（運(yùn)行時(shí)）

按照 4.1 的分析思路，我們首先需要了解 Flutter 運(yùn)行時(shí)代碼加載的完整流程，經(jīng)過(guò)梳理分析流程如下：

1 ）Android- APP 業(yè)務(wù)代碼的加載流程：

2）IOS- APP 業(yè)務(wù)代碼的加載流程：

4.3 業(yè)務(wù)代碼的編譯生成（編譯時(shí)）

根據(jù)以上的分析，我們知道了 Flutter 業(yè)務(wù)代碼的數(shù)據(jù)結(jié)構(gòu)，也知道了在運(yùn)行時(shí)如何加載，因此我們只需要在編譯時(shí)做更改，產(chǎn)生自己需要的代碼段，和數(shù)據(jù)段文件。在運(yùn)行時(shí)加載自己的構(gòu)建產(chǎn)物即可達(dá)到目標(biāo)。

1）在此以 IOS 構(gòu)建自己的業(yè)務(wù)代碼流程做詳細(xì)分析：

** 有完成構(gòu)建流程可以分析，基本流程是 “Dart Code（業(yè)務(wù)代碼）” -> (通過(guò) Dart 編譯器 gen_snapshot.cc) 生成 snapshot_assemble.S 的匯編文件 -> (通過(guò) xcrun 工具) 生成 snapshot_assemble.o 的 obj 文件 -> (通過(guò) xcun clang 工具鏈) 生成了 App.Framework。

2）Android 的產(chǎn)物構(gòu)建流程和 IOS 類(lèi)似。由于 Android 有其他更簡(jiǎn)單的方案， 因此省略詳細(xì)的構(gòu)建流程分析，大致如下：

4.4 實(shí)現(xiàn)熱更新的方案探索

根據(jù)上面的技術(shù)分析結(jié)果，已經(jīng)可以獨(dú)立生成自己的代碼段，數(shù)據(jù)段文件。通過(guò)需改虛擬機(jī)底層代碼的方式，也可以動(dòng)態(tài)的加載運(yùn)行。但由于 IOS 系統(tǒng)目前底層的系統(tǒng)還不能動(dòng)態(tài)加載可讀寫(xiě)的代碼段數(shù)據(jù)到內(nèi)存中，所以還有技術(shù)難點(diǎn)需要突破。但 Android 端有更簡(jiǎn)單的路徑可以解決，因此下面以 Android 端為例重點(diǎn)分析思路，大致如下圖所示：

由上圖可以得知，Android 端 熱修復(fù)核心步驟如下：

1， 修改 Flutter Engine 代碼，加載指定路徑的 libapp.so 和 flutter_aasets，比如私有目錄 (data/data/files)；

2， 編譯 APK 時(shí)，利用 Gradle Transform 插件，根據(jù) Flutter SDK 的 engine version 動(dòng)態(tài)替換官方的 Flutter engine，最終寫(xiě)入修改后的 engine 到 APK；

3， 生成補(bǔ)丁包：利用 BSdiff 算法比較新舊 APK 文件，生成 patch 補(bǔ)丁包

4， APP 啟動(dòng)時(shí)訪(fǎng)問(wèn)后端接口，根據(jù)參數(shù)（app 的版本號(hào)，補(bǔ)丁包版本號(hào)，md5，flutter SDK 版本號(hào)，Engine 版本號(hào)）拉取補(bǔ)丁包；

5， 合成補(bǔ)丁包：校驗(yàn) md5，app 版本號(hào)，補(bǔ)丁版本號(hào)，安裝時(shí)間；

6， 自定義 Flutter Engine 加載指定路徑的 libapp.so 和 flutter_assets 資源文件；