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程序