flutter 图片转base64_京东技术中台的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 為業務研發團隊提供了全流程的開發解決方案:
配置混合工程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.gradleinclude ':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')
}
這樣就可以原生項目一起編譯了。
具體可以參照官方文檔: https://github.com/flutter/flutter/wiki/Add-Flutter-to-existing-apps
這樣的方式雖可以滿足混編需求,但還不是特別方便,開發完項目后,還需要去 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 倉庫的源碼: https://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 // 作者和郵箱
homepage: https://localhost:8080 // 組件的介紹頁面
publish_to: http://localhost:8080// 倉庫上傳地址
上傳時可以使用如下命令檢查代碼錯誤,并顯示出上傳的目錄結構
pub publish --dry-run如果有不想上傳的文件,可以在根目錄增加一個.gitignore 文件來忽略如下:
/buildFlutter 組件的依賴配置,在項目的 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 attachWaiting 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 的初始化說起了,在頁面啟動前需要調用 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 分區來做個實驗。
- 關閉 Flutter 頁面,在 Task 中殺掉進程,回來后重新打開 Flutter 頁面,就能看到改動的效果,圖片資源是存放在 flutter_asset 目錄的,將圖片放到這個目錄,同樣能更新圖片
上面這個實驗,驗證了方案基本是可行的,但這里只是簡單替換,實際使用中替換還是有很多問題的。那 Google 官方是如何設計的呢?
Google 熱修復設計 熱修復步驟Flutter SDK 1.2.1 中,Google 提供了 ResourceUpdater,用來做包的檢查和下載解壓。升級步驟如下:
- 在頁面初始化時,檢查固定的下載更新目錄有沒有業務升級包,從代碼來看,必須在 manifest 中打開該功能,設置 DynamicPatching
每次 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(下次初始化時)
整體流程 存在的缺陷過于定制化,全部在引擎完成,很難適配一些特殊的需求定制;
- 不支持現在比較主流的升級流程,諸如灰度和白名單等功能;
版本號的維度不好控制,同時不能做版本回滾等操作。
線上出現大量異常后,可以指定對應的 Flutter 業務執行降級策略,讓該業務迅速降級到 H5 頁面。
- Flutter 業務包差量升級:現有的升級模式都是全量包覆蓋,即使壓縮后升級包還是很大,影響升級成功率及用戶流量,后續會采用一些 diff 工具,對比生成差量的 patch,通過服務端下發后,在客戶端合并成完整包,但升級次數較多后會導致最終版本碎片化,需要做好版本之前的維護關系,難度較大。
升級后及時更新頁面:現有方案(包括標準 google 升級方案)沒有辦法做到下載業務包或者替換業務包后及時刷新頁面,需要 restart 進程后重新開啟才能刷新頁面。未來我們會優化引擎,通過釋放底層資源并重新加載,來完成隨時刷新頁面的功能。
Google Flutter 是非常出色的跨端開發技術,現在已經取得了長足的發展。社區生態和框架成熟度也正在快速追趕 RN。相信不久的將來,Flutter+RN 一定會成為跨端開發平臺的絕代雙驕。
團隊介紹京東 ARES 跨端團隊作為京東技術與數據中臺的多端技術平臺團隊,聚焦于跨端開發技術框架和平臺搭建,包括但不限于 RN、Flutter、小程序等技術棧。目前已經廣泛應用于京東商城、京東金融、京東到家、京東拼購等京東系核心 App 內,幫助業務團隊低成本、快速開發自己的業務,以應對市場的瞬息萬變之勢。
活動推薦GMTC 全球大前端技術大會首次落地華南,走入大灣區深圳。
往屆我們請到了來自 Google、Twitter、Instagram、阿里、騰訊、字節跳動、百度、京東、美團等國內外一線公司的頂級前端專家,分享了關于小程序、Flutter、Node、RN、前端框架、前端安全、前端工程化、移動 AI 等 50 多個熱門技術專題。目前深圳站正式啟動,7 折最低價售票通道已經開啟,詳細請咨詢:13269078023(同微信)。
總結
以上是生活随笔為你收集整理的flutter 图片转base64_京东技术中台的Flutter实践之路的全部內容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: 在envi做随机森林_随机森林原理
- 下一篇: 64位java_99.9%的Java程序