在 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 <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一定會成為跨端開發平台的絕代雙驕。
點擊“京東雲”了解京東雲移動跨端開發解決方案
歡迎點擊“鏈接”了解更多精彩內容