京東技術中台的Flutter實踐之路

在 2019 年，Flutter 推出了多個正式版本，支援的終端越來越多，使用的項目也越來越多。Flutter 正在經曆從小範圍嘗鮮到大面積應用的過程，越來越多的研發團隊加入到 Flutter 的學習熱潮中，京東作為網際網路大廠之一也積極參與了 Flutter 的跨端方案研究。本文将介紹京東在 Flutter 上的應用方案和相關優化成果。

為什麼考慮Flutter技術方案

其實京東很早就開始研究并實踐跨端的開發解決方案，最早使用的是Hybrid App的技術方案，從2015年低開始逐漸轉向RN技術棧，目前應該是業内RN技術平台應用最廣泛、配套設施比較完善的公司之一。從2018年中開始，我們也關注到了Flutter技術，最吸引我們的特性是高性能和相容性。這兩點也是目前RN技術相對不足的地方。高性能指的是複雜場景和互動下的渲染性能，相容性指的是不同終端平台上的布局和體驗的一緻性，這點在碎片化嚴重的android平台上尤其重要。

京東在Flutter的實踐

随着2018年底Google正式釋出了Flutter預覽版本，京東内部也越來越多的研發團隊有用Flutter進行開發業務的訴求。我們正式啟動研發并内部釋出了JDFlutter引擎。在官方Flutter引擎之上，我們做了額外的優化和功能擴充：

Flutter工程改造：對Flutter開發環境和dart代碼管理進行優化，可以無縫內建到現有APP中并支援自動化dart編譯打包，便于開發和調試。
路由及多頁面管理：對原生頁面和flutter頁面實作了集中路由管理，可以雙向傳參、跳轉并且進行了共享記憶體優化。
擴充UI元件庫：官方支援的Material和Cupertino樣式不能滿足需求，我們内部實作了自定義樣式的元件庫。
原生能力擴充：對官方原生能力進行了擴充，封裝了包括網絡、登陸、埋點等等基礎能力的打通并提供了50+原生擴充API。
Android端動态化支援：在Android端實作了動态化支援，可以線上熱更新業務。iOS端暫不支援動态化。

目前京東商城、京東視訊、京東到家、京東物流、7Fresh等APP都有業務采用JDFlutter進行開發。

JDFlutter架構設計

JDFlutter整體的架構結構，主要包含：基礎架構、元件、工具三部分，如圖所示：

基礎架構

JDFlutter基礎架構分為三層架構，包含JDFlutter基礎層，通用業務層，業務層。

基礎層：提供了Flutter的基礎元件支援，包括元件管理，狀态管理等；基礎層完全獨立，對業務沒有依賴。
通用業務層：提供了通用型業務元件支援，例如登入元件，支付元件等；通用業務層依賴于基礎層。
業務層：即具體業務邏輯實作層，根據業務需要進行不同元件的組合，實作業務頁面的快速開發。

核心元件

元件管理：元件之間通過标準的協定接口進行通信，降低元件耦合，便于維護及元件更新；
狀态管理：實作資料和界面分離，統一狀态管理，以資料的變化來驅動界面的改變，更有利于資料的持久化和儲存，同時也有利于UI元件的複用；
Hybrid Router：主要解決Flutter和Native之間交叉跳轉的問題，減少記憶體開銷，共享同一個Flutter Engine。

工具介紹

編譯釋出：優化Flutter原有的編譯邏輯，管理依賴Flutter原生依賴關聯，打包Flutter和原生代碼，實作自動化建構釋出。
資源管理：管理圖檔資源，将資源轉換成Flutter類，便于資源的讀取操作，類似Andorid的R類；
模版代碼生成：減少Flutter的代碼編寫，自動生成Flutter 元件的架構模闆代碼，提升代碼編寫效率；
JSON轉換：将JSON資料轉換成Flutter code，并提供json轉Flutter對象的API，減少動手編寫Flutter code及解析。

JDFlutter業務開發實踐

JDFlutter為業務研發團隊提供了全流程的開發解決方案：

配置混合工程

Flutter和原生混合開發有兩種情況，其一，開發Flutter業務的同學，需要和原生做互動，是以需要有Flutter和原生的混合編譯環境；其二，使用原生SDK開發業務的同學，需要和Flutter業務一起內建打包，此時需對Flutter透明，以減少對Flutter編譯環境的依賴，并且，隻依賴原生編譯環境即可，此時我們将Flutter編譯成aar依賴，放入原生項目中即可。接下來，我們将重點介紹Android和iOS的混合編譯環境配置。

Android平台配置

建立一個flutter module

flutter create -t module --org com.example my_flutter

在原生根項目的settings.gradle加入如下配置資訊

// MyApp/settings.gradle
include ':app'                        // assumed existing content
setBinding(new Binding([gradle: this]))              // new
evaluate(new File(                                   // new
settingsDir.parentFile,                              // new
  'my_flutter/.android/include_flutter.groovy'       // new
))

在原生App子產品中加入flutter依賴

dependencies {
  implementation project(':flutter')
}

這樣就可以原生項目一起編譯了。具體可以參照官方文檔：

http://github.com/flutter/flu

…這樣的方式雖可以滿足混編需求，但還不是特别友善，開發完項目後，還需要去Android Studio項目中進行編譯，比較麻煩，是以我們也可以把Flutter項目settings.gradle改造，在Flutter開發環境下直接運作包含原生代碼的混合項目，改造方式如下

// MyApp/settings.gradle
//projectName 原生子產品名稱
//projectPath 原生項目路徑
include ":$projectName"
project(":$projectName").projectDir = new File("$projectPath")

這樣改造之後即可在Flutter IDE中直接編譯Flutter混合工程，并進行調試，也可以運作futter run來啟動Flutter混合工程，不過在配置的時候，需要注意Flutter中 gradle編譯環境和原生編譯環境的一緻性，如果不一緻可能會導緻編譯錯誤。

iOS平台配置

建立flutter module

flutter create -t module my_flutter

進入iOS工程目錄，初始化pod環境（如果項目工程已經使用Cocoapods，跳過此步驟）

pod init

編輯Podfile檔案

#在Podfile檔案添加的新代碼
flutter_application_path = '/{flutter module目錄}/my_flutter'
eval(File.read(File.join(flutter_application_path, '.ios', 'Flutter', 'podhelper.rb')), binding)

安裝pod

pod install

打開工程(*.xcworkspace) 配置build phase，為編譯Dart 代碼添加編譯選項打開iOS項目，選中項目的Build Phases選項，點選左上角+号按鈕，選擇New Run Script Phase，将下面的shell腳本添加到輸入框中：

"$FLUTTER_ROOT/packages/flutter_tools/bin/xcode_backend.sh" build
"$FLUTTER_ROOT/packages/flutter_tools/bin/xcode_backend.sh" embed

搭建PUB私服倉庫

Flutter開發中使用的元件，一般公司内部會采用共享的方式，以避免重複開發，而Flutter元件共享，即需要使用pub倉庫。由于公司内部的業務元件不适合上傳到pub官方倉庫，是以，需要搭建私服倉庫，以解決各個業務研發團隊，對Flutter元件共享需要。感興趣的同學可以研究下官方pub倉庫的源碼

http://pub.dartlang.org/

，其對Google Cloud 環境有很大的依賴，也可以基于

https://github.com/kahnsen/pub_server

來搭建一個簡易版本的私服倉庫，以滿足上傳和下載下傳功能，pub協定相對比較簡單，我們可以在源碼增加協定接口來實作更多功能。運作pub_server

~ $ git clone https://github.com/dart-lang/pub_server.git
~ $ cd pub_server
~/pub_server $ pub get
...
~/pub_server $ dart example/example.dart -d /tmp/package-db
Listening on http://localhost:8080

To make the pub client use this repository configure your shell via:

    $ export PUB_HOSTED_URL=http://localhost:8080

釋出一個Flutter元件需要修改 pubspec.yaml，增加以下内容:

name: hello_plugin //plugin名稱 
description: A new Flutter plugin. //介紹
version: 0.0.1//版本号
author: xxx <[email protected]>//作者和郵箱
homepage: https://localhost:8080 //元件的介紹頁面
publish_to: http://localhost:8080//倉庫上傳位址

上傳時可以使用如下指令檢查代碼錯誤，并顯示出上傳的目錄結構。

pub publish --dry-run

如果有不想上傳的檔案，可以在根目錄增加一個.gitignore檔案來忽略如下:

/build

Flutter元件的依賴配置，在項目的pubspec.yaml中dependencies:下增加如下資訊：

dependencies:
hello_plugin:
  hosted:
    name: hello_plugin
    url: http://localhost:8080 
    version: 0.0.2

這樣可以在公司内部實作Flutter元件共享，如果不想搭建自己的pub倉庫，也可以采用git依賴，配置如下:

dependencies:
  hello_plugin:
    git:
      url: git://github.com/hello_plugin.git //git位址
      ref: dev-branch //分支

Flutter業務的開發與調試

在Flutter IDE中編譯代碼調試會很友善，直接點選debug按鈕即可進行代碼調試，如果是混合工程在Android studio或者xcode中運作的工程，則沒辦法這麼做，但也可以實作調試：将要調試的App安裝到手機中（安裝debug版本），連接配接電腦，執行如下指令，同步Flutter代碼到裝置的宿主App中

$ cd flutterProjectPath/
$ flutter attach

執行完指令後會進行等待裝置連接配接狀态，然後打開宿主App，進入Flutter頁面，看到如下資訊提示則表示同步成功

zbdeMacBook-Pro:example zb$ flutter attach
Waiting for a connection from Flutter on MI 5X...
Done.
Syncing files to device MI 5X...                             1.2s

🔥  To hot reload changes while running, press "r". To hot restart (and rebuild state), press "R".
An Observatory debugger and profiler on MI 5X is available at: http://127.0.0.1:54422/
For a more detailed help message, press "h". To detach, press "d"; to quit, press "q".

打開

http://127.0.0.1:54422

可以檢視調試資訊，如有代碼改動可以按r來實時同步界面，如果改動沒有實時生效可以按R重新啟動Flutter應用。

JDFlutter熱更新實踐

大部分跨端架構，諸如React Native / Weex / H5等，基本都能做到随時進行熱修複，并随時上線，用于及時修複突發的線上問題，架構非常靈活。Flutter因其AOT的設計，預想會很難達到這種靈活度，但技術上仍具有一定的可行性，正如我們在之前的Flutter介紹文章中提到的，按照先有的API設計，是可以支援熱修複的，但僅限于Android。官方最新的架構上已經支援了熱修複架構，大家可以更新到1.2.1版本檢視，但是官方的功能還比較弱，無法做到版本控制和復原的靈活性，是以JDFlutter并沒有采用。我們可以首先一起看一下Google官方熱修複方案的設計原理：Flutter1.2.1 版本引入了 Dynamic Patch

為了更清楚的了解官方熱修複的原理和過程，我們需要首先深入了解Flutter的業務包結構和整體運作過程：

Flutter App的包結構

可以看到主體代碼集中在asset目錄中，除此之外還有少量Android端的架構java代碼及flutter so引擎庫外：

1、icudtl.dat

2、isolate_snapshot_data

3、isolate_snapshot_instr

Flutter包的初始化流程

Flutter頁面啟動時是如何加載這些代碼的呢？那就要從Flutter的初始化說起了，在頁面啟動前需要調用FlutterMain.startInitialization來做初始化：

可以看到該初始化是要求在主線程完成的，另外主要完成了以下三點：

配置了一些環境資料，比如各個核心包的路徑，主要是提供給其他一些子產品全局調用

檢查 asset 下 Flutter 包的完整性，主要是上面介紹的一些核心包，一旦缺少核心的一些庫，就會直接抛異常。開發過程中我們經常因為配置導緻有些檔案沒有打包進去，然後會直接 crash，就是在這裡觸發的，具體代碼如下：

解壓部分 asset 下的資源到 data 分區，以下是一些片段的代碼，那為什麼要解壓呢？放在 asset 下也是可以通過 assetManager 讀取的。這裡 google 應該是從性能角度要求解壓的，因為頻繁的使用 assetManager 讀取 asset 是很容易造成多線程阻塞的，一旦阻塞了将會導緻整個 Flutter 業務全部無法渲染，是以需要解壓一些核心的資源庫，而不是解壓了所有的資源 (例如圖檔就沒有解壓)

從代碼來看，先增加要解壓的核心庫的目錄，然後啟動 task 從 asset 中解壓庫到 data 分區對應 app 資料下的 app_flutter 目錄，以下是解壓後的目錄結構：

其中 res_timestamp 檔案用于标記一些時間戳，算法比較固定，根據用戶端的安裝時間及 app 的 version code 生成，也就是說當使用者打開 Flutter 頁面後這個值就是固定的，如果有任何修改引擎會預設有變化，删除現有 app_flutter 的包，重新解壓

運作原理

上面是對Flutter程式加載的分析，最終Flutter頁面顯示是需要呈現在原生元件Flutter View中的，這個元件會和底層Flutter Native View 進行綁定，并最終運作上面說到的data分區的Dart代碼來渲染UI。如果使用的是Flutter Activity，則預設Flutter View是全屏顯示，如需要定制頁面，需要自己設計Activity。

熱修複實驗

了解了這些，其實熱修複方案已經呼之欲出，替換原有解壓後的app_flutter包，殺程序，然後重新加載Flutter頁面即可。這裡我們可以做個簡單的實驗：采用adb指令push一些修改過的并編譯的dart代碼到app_flutter目錄：

先打開Flutter頁面，預設會加載asset下的包，并解壓到data分區
修改一個Flutter工程，并編譯代碼，最終在工程目錄my_flutter/.android/Flutter/build/intermediates/flutter/release中看到打包生成的檔案

這麼檔案目錄中隻有 flutter_assets 目錄和 isolate_snapshot_data 檔案是包含業務代碼和圖檔的，其他部分基本不會變化，是以我們這裡要替換的目錄也就是這兩個，大家可以使用 adb push 指令将資源檔案 push 到對應的 data 分區來做個實驗。

adb push my_flutter/.android/Flutter/build/intermediates/flutter/release/isolate_snapshot_data /data/data/app包名  /app_flutter

關閉 Flutter 頁面，在 Task 中殺掉程序，回來後重新打開 Flutter 頁面，就能看到改動的效果，圖檔資源是存放在 flutter_asset 目錄的，将圖檔放到這個目錄，同樣能更新圖檔

上面這個實驗，驗證了方案基本是可行的，但這裡隻是簡單替換，實際使用中替換還是有很多問題的。那 Google 官方是如何設計的呢？

Google熱修複設計

熱修複步驟

Flutter SDK 1.2.1中，Google提供了ResourceUpdater，用來做包的檢查和下載下傳解壓。更新步驟如下：

在頁面初始化時，檢查固定的下載下傳更新目錄有沒有業務更新包，從代碼來看，必須在manifest中打開該功能，設定DynamicPatching

從邏輯上來看，隻有在頁面 onResume 或者 App 重新開啟的時候會下載下傳更新包，整體下載下傳是通過 http 請求完成的，整體實作代碼大家可以參考 ResourceUpdater 中 DownloadTask 的實作部分，這裡就不細說了。

每次 init 的時候都會觸發檢查 data 分區的 app_flutter 包，如果不存在就會從 aaset 目錄解壓出來，而更新包的替換就是在這步完成的，按照邏輯會優先檢查更新目錄有沒有包存在，如果存在則優先從更新目錄解壓，如果不存在還是從 asset 目錄解壓；

當然在檢查到有更新包時，會對更新包的一些配置做校驗，主要是 manifest.json 檔案，裡面會包含 buildNumber/baselineChecksum 字段，同時也會對"isolate_snapshot_data", "isolate_snapshot_instr", "flutter_assets/isolate_snapshot_data"等檔案做 CRC32 校驗。

更新後的版本時間戳是從配置的 manifest.json 檔案中讀取 patchNumber 和檔案下載下傳時間确定的，完成檔案覆寫後會重新生成。

以下是更新包的大概路徑如下：

如何配置伺服器

文章上部分介紹了怎麼打開更新patch的功能，因更新涉及到服務端，那Google是怎麼做到關聯到伺服器的呢？其實原理比較簡單，需要配置用戶端的manifest檔案的meta屬性，增加PatchServerURL，也就是我們服務的位址，以及下載下傳模式PatchDownloadMode和加載模式PatchInstallMode，預設是ON_NEXT_RESTART（下次初始化時）

整體流程

存在的缺陷

過于定制化，全部在引擎完成，很難适配一些特殊的需求定制；
不支援現在比較主流的更新流程，諸如灰階和白名單等功能；
版本号的次元不好控制，同時不能做版本復原等操作。

JDFlutter如何實作熱修複

實作原理

JDFlutter的整體實作原理，其實和Google是一樣的，目前來看不修改引擎的前提下，隻有這種方案最簡單，但是我們沒有使用Google的這套更新架構，預設關閉了patch功能，并架構之外實作了替換包和加載的邏輯，優點是整體相容性更強、更靈活。1、服務端根據用戶端的唯一辨別支援了白名單和灰階下發更新包；2、優化下載下傳和替換流程。Flutter的更新包一般有4-5M，而且從網絡端擷取，失敗率較高，替換過程又涉及到檔案操作，操作不當容易産生UI阻塞或者包異常。接入JDFlutter的用戶端下載下傳包後，并不會直接替換檔案，而是修改名稱後解壓到app_flutter目錄，等待業務頁面重新打開或者重新初始化時再修改成Flutter标準名稱的檔案。這種操作不存在性能問題，另外會把舊版的檔案備份，以便復原代碼；3、同時并發運作的Flutter頁面較多，需避免因為更新出現一些中間狀态，使得業務或者頁面無法打開的情況；4、更新失敗或者下載下傳後業務包有問題，出現無法加載的情況或者檔案丢失的情況可以控制復原代碼；5、線上出現大量異常後，可以指定對應的Flutter業務執行降級政策，讓該業務迅速降級到H5頁面。

熱修複規劃

未來，JDFlutter會繼續在熱修複方面進行探索和驗證，以滿足京東業務的快速發展需要。而針對目前的方案，我們思考了如下的優化點：Flutter業務包差量更新：現有的更新模式都是全量包覆寫，即使壓縮後更新包還是很大，影響更新成功率及使用者流量，後續會采用一些diff工具，對比生成差量的patch，通過服務端下發後，在用戶端合并成完整包，但更新次數較多後會導緻最終版本碎片化，需要做好版本之前的維護關系，難度較大。

更新後及時更新頁面：現有方案（包括标準google更新方案）沒有辦法做到下載下傳業務包或者替換業務包後及時重新整理頁面，需要restart程序後重新開啟才能重新整理頁面。未來我們會優化引擎，通過釋放底層資源并重新加載，來完成随時重新整理頁面的功能。

未來展望

Google Flutter是非常出色的跨端開發技術，現在已經取得了長足的發展。社群生态和架構成熟度也正在快速追趕RN。相信不久的将來，Flutter+RN一定會成為跨端開發平台的絕代雙驕。

原創：京東雲技術新知

原文連結：

https://www.cnblogs.com/jdclouddeveloper/p/11691543.html