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

時間 2019-11-06

標籤乾貨京東技術中臺 flutter 實踐之路简体版

原文原文鏈接

在 2019 年，Flutter 推出了多個正式版本，支持的終端愈來愈多，使用的項目也愈來愈多。Flutter 正在經歷從小範圍嚐鮮到大面積應用的過程，愈來愈多的研發團隊加入到 Flutter 的學習熱潮中，京東做爲互聯網大廠之一也積極參與了 Flutter 的跨端方案研究。本文將介紹京東在 Flutter 上的應用方案和相關優化成果。java

爲何考慮Flutter技術方案

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

京東在Flutter的實踐

隨着2018年末Google正式發佈了Flutter預覽版本，京東內部也愈來愈多的研發團隊有用Flutter進行開發業務的訴求。咱們正式啓動研發並內部發布了JDFlutter引擎。在官方Flutter引擎之上，咱們作了額外的優化和功能擴展：ios

Flutter工程改造：對Flutter開發環境和dart代碼管理進行優化，能夠無縫集成到現有APP中並支持自動化dart編譯打包，便於開發和調試。git
路由及多頁面管理：對原生頁面和flutter頁面實現了集中路由管理，能夠雙向傳參、跳轉而且進行了共享內存優化。github
擴展UI組件庫：官方支持的Material和Cupertino樣式不能知足需求，咱們內部實現了自定義樣式的組件庫。算法
原生能力擴展：對官方原生能力進行了擴展，封裝了包括網絡、登錄、埋點等等基礎能力的打通並提供了50+原生擴展API。shell
Android端動態化支持：在Android端實現了動態化支持，能夠線上熱更新業務。iOS端暫不支持動態化。json

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

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 //分支

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引擎庫外：

一、icudtl.dat

二、isolate_snapshot_data

三、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功能，並框架以外實現了替換包和加載的邏輯，優勢是總體兼容性更強、更靈活。一、服務端根據客戶端的惟一標識支持了白名單和灰度下發升級包；二、優化下載和替換流程。Flutter的升級包通常有4-5M，並且從網絡端獲取，失敗率較高，替換過程又涉及到文件操做，操做不當容易產生UI阻塞或者包異常。接入JDFlutter的客戶端下載包後，並不會直接替換文件，而是修更名稱後解壓到app_flutter目錄，等待業務頁面從新打開或者從新初始化時再修改爲Flutter標準名稱的文件。這種操做不存在性能問題，另外會把舊版的文件備份，以便回滾代碼；三、同時併發運行的Flutter頁面較多，需避免由於升級出現一些中間狀態，使得業務或者頁面沒法打開的狀況；四、升級失敗或者下載後業務包有問題，出現沒法加載的狀況或者文件丟失的狀況能夠控制回滾代碼；五、線上出現大量異常後，能夠指定對應的Flutter業務執行降級策略，讓該業務迅速降級到H5頁面。

熱修復規劃

將來，JDFlutter會繼續在熱修復方面進行探索和驗證，以知足京東業務的快速發展須要。而針對目前的方案，咱們思考了以下的優化點：Flutter業務包差量升級：現有的升級模式都是全量包覆蓋，即便壓縮後升級包仍是很大，影響升級成功率及用戶流量，後續會採用一些diff工具，對比生成差量的patch，經過服務端下發後，在客戶端合併成完整包，但升級次數較多後會致使最終版本碎片化，須要作好版本以前的維護關係，難度較大。

升級後及時更新頁面：現有方案（包括標準google升級方案）沒有辦法作到下載業務包或者替換業務包後及時刷新頁面，須要restart進程後從新開啓才能刷新頁面。將來咱們會優化引擎，經過釋放底層資源並從新加載，來完成隨時刷新頁面的功能。