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

ARES發表於2019-09-04
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')
}
複製程式碼

這樣就可以原生專案一起編譯了。

具體可以參照官方文件：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倉庫的原始碼 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 <xxx@xxx.com>//作者和郵箱
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一定會成為跨端開發平臺的絕代雙驕。

團隊介紹

京東 ARES 跨端團隊作為京東技術與資料中臺的多端技術平臺團隊，聚焦於跨端開發技術框架和平臺搭建，包括但不限於 RN、Flutter、小程式等技術棧。目前已經廣泛應用於京東商城、京東金融、京東到家、京東拼購等京東系核心 App 內，幫助業務團隊低成本、快速開發自己的業務，以應對市場的瞬息萬變之勢。

相關文章