京東技術(shù)大中臺(tái)的 Flutter 跨端實(shí)踐之路
點(diǎn)擊“開(kāi)發(fā)者技術(shù)前線”，選擇“星標(biāo)?”
讓一部分開(kāi)發(fā)者看到未來(lái)
其實(shí)京東很早就開(kāi)始研究并實(shí)踐跨端的開(kāi)發(fā)解決方案，最早使用的是 Hybrid App 的技術(shù)方案，從 2015 年底開(kāi)始逐步轉(zhuǎn)向 RN 技術(shù)棧，目前應(yīng)該是業(yè)內(nèi) RN 技術(shù)平臺(tái)應(yīng)用最廣泛、配套設(shè)施比較完善的公司之一。從 2018 年中開(kāi)始，我們也關(guān)注到了 Flutter 技術(shù)，最吸引我們的特性是高性能和兼容性。這兩點(diǎn)也是目前 RN 技術(shù)相對(duì)不足的地方。高性能指的是復(fù)雜場(chǎng)景和交互下的渲染性能，兼容性指的是不同終端平臺(tái)上的布局和體驗(yàn)的一致性，這點(diǎn)在碎片化嚴(yán)重的 android 平臺(tái)上尤其重要。
Flutter 工程改造： 對(duì) Flutter 開(kāi)發(fā)環(huán)境和 dart 代碼管理進(jìn)行優(yōu)化，可以無(wú)縫集成到現(xiàn)有 APP 中并支持自動(dòng)化 dart 編譯打包，便于開(kāi)發(fā)和調(diào)試。 路由及多頁(yè)面管理： 對(duì)原生頁(yè)面和 flutter 頁(yè)面實(shí)現(xiàn)了集中路由管理，可以雙向傳參、跳轉(zhuǎn)并且進(jìn)行了共享內(nèi)存優(yōu)化。 擴(kuò)展 UI 組件庫(kù)： 官方支持的 Material 和 Cupertino 樣式不能滿足需求，我們內(nèi)部實(shí)現(xiàn)了自定義樣式的組件庫(kù)。 原生能力擴(kuò)展： 對(duì)官方原生能力進(jìn)行了擴(kuò)展，封裝了包括網(wǎng)絡(luò)、登陸、埋點(diǎn)等等基礎(chǔ)能力的打通并提供了 50+ 原生擴(kuò)展 API。 Android 端動(dòng)態(tài)化支持： 在 Android 端實(shí)現(xiàn)了動(dòng)態(tài)化支持，可以線上熱更新業(yè)務(wù)。iOS 端暫不支持動(dòng)態(tài)化。
目前京東商城、京東視頻、京東到家、京東物流、7Fresh 等 APP 都有業(yè)務(wù)采用 JDFlutter 進(jìn)行開(kāi)發(fā)。
JDFlutter 整體的框架結(jié)構(gòu)，主要包含：基礎(chǔ)框架、組件、工具三部分，如圖所示：
基礎(chǔ)層： 提供了 Flutter 的基礎(chǔ)組件支持，包括組件管理，狀態(tài)管理等；基礎(chǔ)層完全獨(dú)立，對(duì)業(yè)務(wù)沒(méi)有依賴。 通用業(yè)務(wù)層： 提供了通用型業(yè)務(wù)組件支持，例如登錄組件，支付組件等；通用業(yè)務(wù)層依賴于基礎(chǔ)層。 業(yè)務(wù)層： 即具體業(yè)務(wù)邏輯實(shí)現(xiàn)層，根據(jù)業(yè)務(wù)需要進(jìn)行不同組件的組合，實(shí)現(xiàn)業(yè)務(wù)頁(yè)面的快速開(kāi)發(fā)。
組件管理： 組件之間通過(guò)標(biāo)準(zhǔn)的協(xié)議接口進(jìn)行通信，降低組件耦合，便于維護(hù)及組件升級(jí)；
狀態(tài)管理： 實(shí)現(xiàn)數(shù)據(jù)和界面分離，統(tǒng)一狀態(tài)管理，以數(shù)據(jù)的變化來(lái)驅(qū)動(dòng)界面的改變，更有利于數(shù)據(jù)的持久化和保存，同時(shí)也有利于 UI 組件的復(fù)用； Hybrid Router： 主要解決 Flutter 和 Native 之間交叉跳轉(zhuǎn)的問(wèn)題，減少內(nèi)存開(kāi)銷，共享同一個(gè) Flutter Engine。
編譯發(fā)布： 優(yōu)化 Flutter 原有的編譯邏輯，管理依賴 Flutter 原生依賴關(guān)聯(lián)，打包 Flutter 和原生代碼，實(shí)現(xiàn)自動(dòng)化構(gòu)建發(fā)布。
資源管理： 管理圖片資源，將資源轉(zhuǎn)換成 Flutter 類，便于資源的讀取操作，類似 Andorid 的 R 類； 模版代碼生成： 減少 Flutter 的代碼編寫，自動(dòng)生成 Flutter 組件的框架模板代碼，提升代碼編寫效率； JSON 轉(zhuǎn)換： 將 JSON 數(shù)據(jù)轉(zhuǎn)換成 Flutter code，并提供 json 轉(zhuǎn) Flutter 對(duì)象的 API，減少動(dòng)手編寫 Flutter code 及解析。
JDFlutter 為業(yè)務(wù)研發(fā)團(tuán)隊(duì)提供了全流程的開(kāi)發(fā)解決方案：
Flutter 和原生混合開(kāi)發(fā)有兩種情況，其一，開(kāi)發(fā) Flutter 業(yè)務(wù)的同學(xué)，需要和原生做交互，因此需要有 Flutter 和原生的混合編譯環(huán)境；其二，使用原生 SDK 開(kāi)發(fā)業(yè)務(wù)的同學(xué)，需要和 Flutter 業(yè)務(wù)一起集成打包，此時(shí)需對(duì) Flutter 透明，以減少對(duì) Flutter 編譯環(huán)境的依賴，并且，只依賴原生編譯環(huán)境即可，此時(shí)我們將 Flutter 編譯成 aar 依賴，放入原生項(xiàng)目中即可。接下來(lái)，我們將重點(diǎn)介紹 Android 和 iOS 的混合編譯環(huán)境配置。
創(chuàng)建一個(gè) flutter module
flutter create -t module --org com.example my_flutter
在原生根項(xiàng)目的 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')
}
這樣就可以原生項(xiàng)目一起編譯了。
具體可以參照官方文檔: https://github.com/flutter/flutter/wiki/Add-Flutter-to-existing-apps
這樣的方式雖可以滿足混編需求，但還不是特別方便，開(kāi)發(fā)完項(xiàng)目后，還需要去 Android Studio 項(xiàng)目中進(jìn)行編譯，比較麻煩，所以我們也可以把 Flutter 項(xiàng)目 settings.gradle 改造，在 Flutter 開(kāi)發(fā)環(huán)境下直接運(yùn)行包含原生代碼的混合項(xiàng)目，改造方式如下：
// MyApp/settings.gradle
//projectName 原生模塊名稱
//projectPath 原生項(xiàng)目路徑
include ":$projectName"
project(":$projectName").projectDir = new File("$projectPath")
這樣改造之后即可在 Flutter IDE 中直接編譯 Flutter 混合工程，并進(jìn)行調(diào)試，也可以運(yùn)行 futter run 來(lái)啟動(dòng) Flutter 混合工程，不過(guò)在配置的時(shí)候，需要注意 Flutter 中 gradle 編譯環(huán)境和原生編譯環(huán)境的一致性，如果不一致可能會(huì)導(dǎo)致編譯錯(cuò)誤。
創(chuàng)建 flutter module
flutter create -t module my_flutter
進(jìn)入 iOS 工程目錄，初始化 pod 環(huán)境（如果項(xiàng)目工程已經(jīng)使用 Cocoapods，跳過(guò)此步驟）
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
打開(kāi)工程 (***.xcworkspace) 配置 build phase，為編譯 Dart 代碼添加編譯選項(xiàng)
打開(kāi) iOS 項(xiàng)目，選中項(xiàng)目的 Build Phases 選項(xiàng)，點(diǎn)擊左上角 + 號(hào)按鈕，選擇 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
Flutter 開(kāi)發(fā)中使用的組件，一般公司內(nèi)部會(huì)采用共享的方式，以避免重復(fù)開(kāi)發(fā)，而 Flutter 組件共享，即需要使用 pub 倉(cāng)庫(kù)。由于公司內(nèi)部的業(yè)務(wù)組件不適合上傳到 pub 官方倉(cāng)庫(kù)，因此，需要搭建私服倉(cāng)庫(kù)，以解決各個(gè)業(yè)務(wù)研發(fā)團(tuán)隊(duì)，對(duì) Flutter 組件共享需要。
感興趣的同學(xué)可以研究下官方 pub 倉(cāng)庫(kù)的源碼: https://pub.dartlang.org/，其對(duì) Google Cloud 環(huán)境有很大的依賴 ， 也可以基于 https://github.com/kahnsen/pub_server 來(lái)搭建一個(gè)簡(jiǎn)易版本的私服倉(cāng)庫(kù)，以滿足上傳和下載功能，pub 協(xié)議相對(duì)比較簡(jiǎn)單，我們可以在源碼增加協(xié)議接口來(lái)實(shí)現(xiàn)更多功能。
運(yùn)行 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
發(fā)布一個(gè) Flutter 組件需要修改 pubspec.yaml，增加以下內(nèi)容：
name: hello_plugin //plugin 名稱
description: A new Flutter plugin. // 介紹
version: 0.0.1// 版本號(hào)
author: xxx // 作者和郵箱
homepage: https://localhost:8080 // 組件的介紹頁(yè)面
publish_to: http://localhost:8080// 倉(cāng)庫(kù)上傳地址
上傳時(shí)可以使用如下命令檢查代碼錯(cuò)誤，并顯示出上傳的目錄結(jié)構(gòu)
pub publish --dry-run
如果有不想上傳的文件，可以在根目錄增加一個(gè).gitignore 文件來(lái)忽略如下：
/build
Flutter 組件的依賴配置，在項(xiàng)目的 pubspec.yaml 中 dependencies: 下增加如下信息
dependencies:
hello_plugin:
hosted:
name: hello_plugin
url: http://localhost:8080
version: 0.0.2
這樣可以在公司內(nèi)部實(shí)現(xiàn) Flutter 組件共享，如果不想搭建自己的 pub 倉(cāng)庫(kù)，也可以采用 git 依賴，配置如下
dependencies:
hello_plugin:
git:
url: git://github.com/hello_plugin.git //git 地址
ref: dev-branch // 分支
在 Flutter IDE 中編譯代碼調(diào)試會(huì)很方便，直接點(diǎn)擊 debug 按鈕即可進(jìn)行代碼調(diào)試，如果是混合工程在 Android studio 或者 xcode 中運(yùn)行的工程，則沒(méi)辦法這么做，但也可以實(shí)現(xiàn)調(diào)試：
將要調(diào)試的 App 安裝到手機(jī)中（安裝 debug 版本），連接電腦，執(zhí)行如下命令，同步 Flutter 代碼到設(shè)備的宿主 App 中
$ cd flutterProjectPath/
$ flutter attach
執(zhí)行完命令后會(huì)進(jìn)行等待設(shè)備連接狀態(tài)，然后打開(kāi)宿主 App，進(jìn)入 Flutter 頁(yè)面，看到如下信息提示則表示同步成功。
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".
打開(kāi) http://127.0.0.1:54422 可以查看調(diào)試信息，如有代碼改動(dòng)可以按 r 來(lái)實(shí)時(shí)同步界面，如果改動(dòng)沒(méi)有實(shí)時(shí)生效可以按 R 重新啟動(dòng) Flutter 應(yīng)用。
大部分跨端框架，諸如 React Native / Weex / H5 等，基本都能做到隨時(shí)進(jìn)行熱修復(fù)，并隨時(shí)上線，用于及時(shí)修復(fù)突發(fā)的在線問(wèn)題，架構(gòu)非常靈活。Flutter 因其 AOT 的設(shè)計(jì)，預(yù)想會(huì)很難達(dá)到這種靈活度，但技術(shù)上仍具有一定的可行性，正如我們?cè)谥暗?Flutter 介紹文章中提到的，按照先有的 API 設(shè)計(jì)，是可以支持熱修復(fù)的，但僅限于 Android。官方最新的架構(gòu)上已經(jīng)支持了熱修復(fù)架構(gòu)，大家可以更新到 1.2.1 版本查看，但是官方的功能還比較弱，無(wú)法做到版本控制和回滾的靈活性，所以 JDFlutter 并沒(méi)有采用。
我們可以首先一起看一下 Google 官方熱修復(fù)方案的設(shè)計(jì)原理：
Flutter1.2.1 版本引入了 Dynamic Patch
為了更清楚的了解官方熱修復(fù)的原理和過(guò)程，我們需要首先深入了解 Flutter 的業(yè)務(wù)包結(jié)構(gòu)和整體運(yùn)行過(guò)程：
可以看到主體代碼集中在 asset 目錄中，除此之外還有少量 Android 端的框架 java 代碼及 flutter so 引擎庫(kù)外：
icudtl.dat
isolate_snapshot_data
isolate_snapshot_instr
Flutter 頁(yè)面啟動(dòng)時(shí)是如何加載這些代碼的呢？那就要從 Flutter 的初始化說(shuō)起了，在頁(yè)面啟動(dòng)前需要調(diào)用 FlutterMain.startInitialization 來(lái)做初始化：
可以看到該初始化是要求在主線程完成的，另外主要完成了以下三點(diǎn)：
配置了一些環(huán)境數(shù)據(jù)，比如各個(gè)核心包的路徑，主要是提供給其他一些模塊全局調(diào)用
檢查 asset 下 Flutter 包的完整性，主要是上面介紹的一些核心包，一旦缺少核心的一些庫(kù)，就會(huì)直接拋異常。開(kāi)發(fā)過(guò)程中我們經(jīng)常因?yàn)榕渲脤?dǎo)致有些文件沒(méi)有打包進(jìn)去，然后會(huì)直接 crash，就是在這里觸發(fā)的，具體代碼如下：
解壓部分 asset 下的資源到 data 分區(qū)，以下是一些片段的代碼，那為什么要解壓呢？放在 asset 下也是可以通過(guò) assetManager 讀取的。這里 google 應(yīng)該是從性能角度要求解壓的，因?yàn)轭l繁的使用 assetManager 讀取 asset 是很容易造成多線程阻塞的，一旦阻塞了將會(huì)導(dǎo)致整個(gè) Flutter 業(yè)務(wù)全部無(wú)法渲染，所以需要解壓一些核心的資源庫(kù)，而不是解壓了所有的資源 (例如圖片就沒(méi)有解壓)
從代碼來(lái)看，先增加要解壓的核心庫(kù)的目錄，然后啟動(dòng) task 從 asset 中解壓庫(kù)到 data 分區(qū)對(duì)應(yīng) app 數(shù)據(jù)下的 app_flutter 目錄，以下是解壓后的目錄結(jié)構(gòu)：
其中 res_timestamp 文件用于標(biāo)記一些時(shí)間戳，算法比較固定，根據(jù)客戶端的安裝時(shí)間及 app 的 version code 生成，也就是說(shuō)當(dāng)用戶打開(kāi) Flutter 頁(yè)面后這個(gè)值就是固定的，如果有任何修改引擎會(huì)默認(rèn)有變化，刪除現(xiàn)有 app_flutter 的包，重新解壓
上面是對(duì) Flutter 程序加載的分析，最終 Flutter 頁(yè)面顯示是需要呈現(xiàn)在原生組件 Flutter View 中的，這個(gè)組件會(huì)和底層 Flutter Native View 進(jìn)行綁定，并最終運(yùn)行上面說(shuō)到的 data 分區(qū)的 Dart 代碼來(lái)渲染 UI。如果使用的是 Flutter Activity，則默認(rèn) Flutter View 是全屏顯示，如需要定制頁(yè)面，需要自己設(shè)計(jì) Activity
了解了這些，其實(shí)熱修復(fù)方案已經(jīng)呼之欲出，替換原有解壓后的 app_flutter 包，殺進(jìn)程，然后重新加載 Flutter 頁(yè)面即可。這里我們可以做個(gè)簡(jiǎn)單的實(shí)驗(yàn)：
先打開(kāi) Flutter 頁(yè)面，默認(rèn)會(huì)加載 asset 下的包，并解壓到 data 分區(qū)。 修改一個(gè) Flutter 工程，并編譯代碼，最終在工程目錄 my_flutter/.android/Flutter/build/intermediates/flutter/release ，可以看到打包生成的文件。 
這么文件目錄中只有 flutter_assets 目錄和 isolate_snapshot_data 文件是包含業(yè)務(wù)代碼和圖片的，其他部分基本不會(huì)變化，所以我們這里要替換的目錄也就是這兩個(gè)，大家可以使用 adb push 命令將資源文件 push 到對(duì)應(yīng)的 data 分區(qū)來(lái)做個(gè)實(shí)驗(yàn)。
adb push my_flutter/.android/Flutter/build/intermediates/flutter/release/isolate_snapshot_data /data/data/app 包名 /app_flutter
關(guān)閉 Flutter 頁(yè)面，在 Task 中殺掉進(jìn)程，回來(lái)后重新打開(kāi) Flutter 頁(yè)面，就能看到改動(dòng)的效果，圖片資源是存放在 flutter_asset 目錄的，將圖片放到這個(gè)目錄，同樣能更新圖片
上面這個(gè)實(shí)驗(yàn)，驗(yàn)證了方案基本是可行的，但這里只是簡(jiǎn)單替換，實(shí)際使用中替換還是有很多問(wèn)題的。那 Google 官方是如何設(shè)計(jì)的呢？
Flutter SDK 1.2.1 中，Google 提供了 ResourceUpdater，用來(lái)做包的檢查和下載解壓。升級(jí)步驟如下：
在頁(yè)面初始化時(shí)，檢查固定的下載更新目錄有沒(méi)有業(yè)務(wù)升級(jí)包，從代碼來(lái)看，必須在 manifest 中打開(kāi)該功能，設(shè)置 DynamicPatching
每次 init 的時(shí)候都會(huì)觸發(fā)檢查 data 分區(qū)的 app_flutter 包，如果不存在就會(huì)從 aaset 目錄解壓出來(lái)，而升級(jí)包的替換就是在這步完成的，按照邏輯會(huì)優(yōu)先檢查升級(jí)目錄有沒(méi)有包存在，如果存在則優(yōu)先從升級(jí)目錄解壓，如果不存在還是從 asset 目錄解壓；
當(dāng)然在檢查到有升級(jí)包時(shí)，會(huì)對(duì)升級(jí)包的一些配置做校驗(yàn)，主要是 manifest.json 文件，里面會(huì)包含 buildNumber/baselineChecksum 字段，同時(shí)也會(huì)對(duì)"isolate_snapshot_data", "isolate_snapshot_instr", "flutter_assets/isolate_snapshot_data"等文件做 CRC32 校驗(yàn)
升級(jí)后的版本時(shí)間戳是從配置的 manifest.json 文件中讀取 patchNumber 和文件下載時(shí)間確定的，完成文件覆蓋后會(huì)重新生成。
以下是升級(jí)包的大概路徑如下
文章上部分介紹了怎么打開(kāi)升級(jí) patch 的功能，因升級(jí)涉及到服務(wù)端，那 Google 是怎么做到關(guān)聯(lián)到服務(wù)器的呢？其實(shí)原理比較簡(jiǎn)單，需要配置客戶端的 manifest 文件的 meta 屬性，增加 PatchServerURL，也就是我們服務(wù)的地址，以及下載模式 PatchDownloadMode 和加載模式 PatchInstallMode，默認(rèn)是 ON_NEXT_RESTART（下次初始化時(shí)）
過(guò)于定制化，全部在引擎完成，很難適配一些特殊的需求定制；
不支持現(xiàn)在比較主流的升級(jí)流程，諸如灰度和白名單等功能； 版本號(hào)的維度不好控制，同時(shí)不能做版本回滾等操作。
服務(wù)端根據(jù)客戶端的唯一標(biāo)識(shí)支持了白名單和灰度下發(fā)升級(jí)包； 優(yōu)化下載和替換流程。Flutter 的升級(jí)包一般有 4-5M，而且從網(wǎng)絡(luò)端獲取，失敗率較高，替換過(guò)程又涉及到文件操作，操作不當(dāng)容易產(chǎn)生 UI 阻塞或者包異常。接入 JDFlutter 的客戶端下載包后，并不會(huì)直接替換文件，而是修改名稱后解壓到 app_flutter 目錄，等待業(yè)務(wù)頁(yè)面重新打開(kāi)或者重新初始化時(shí)再修改成 Flutter 標(biāo)準(zhǔn)名稱的文件。這種操作不存在性能問(wèn)題，另外會(huì)把舊版的文件備份，以便回滾代碼； 同時(shí)并發(fā)運(yùn)行的 Flutter 頁(yè)面較多，需避免因?yàn)樯?jí)出現(xiàn)一些中間狀態(tài)，使得業(yè)務(wù)或者頁(yè)面無(wú)法打開(kāi)的情況； 升級(jí)失敗或者下載后業(yè)務(wù)包有問(wèn)題，出現(xiàn)無(wú)法加載的情況或者文件丟失的情況可以控制回滾代碼； 線上出現(xiàn)大量異常后，可以指定對(duì)應(yīng)的 Flutter 業(yè)務(wù)執(zhí)行降級(jí)策略，讓該業(yè)務(wù)迅速降級(jí)到 H5 頁(yè)面。
Flutter 業(yè)務(wù)包差量升級(jí)：現(xiàn)有的升級(jí)模式都是全量包覆蓋，即使壓縮后升級(jí)包還是很大，影響升級(jí)成功率及用戶流量，后續(xù)會(huì)采用一些 diff 工具，對(duì)比生成差量的 patch，通過(guò)服務(wù)端下發(fā)后，在客戶端合并成完整包，但升級(jí)次數(shù)較多后會(huì)導(dǎo)致最終版本碎片化，需要做好版本之前的維護(hù)關(guān)系，難度較大。 升級(jí)后及時(shí)更新頁(yè)面：現(xiàn)有方案（包括標(biāo)準(zhǔn) google 升級(jí)方案）沒(méi)有辦法做到下載業(yè)務(wù)包或者替換業(yè)務(wù)包后及時(shí)刷新頁(yè)面，需要 restart 進(jìn)程后重新開(kāi)啟才能刷新頁(yè)面。未來(lái)我們會(huì)優(yōu)化引擎，通過(guò)釋放底層資源并重新加載，來(lái)完成隨時(shí)刷新頁(yè)面的功能。
Google Flutter 是非常出色的跨端開(kāi)發(fā)技術(shù)，現(xiàn)在已經(jīng)取得了長(zhǎng)足的發(fā)展。社區(qū)生態(tài)和框架成熟度也正在快速追趕 RN。相信不久的將來(lái)，F(xiàn)lutter+RN 一定會(huì)成為跨端開(kāi)發(fā)平臺(tái)的絕代雙驕。
京東 ARES 跨端團(tuán)隊(duì)作為京東技術(shù)與數(shù)據(jù)中臺(tái)的多端技術(shù)平臺(tái)團(tuán)隊(duì)，聚焦于跨端開(kāi)發(fā)技術(shù)框架和平臺(tái)搭建，包括但不限于 RN、Flutter、小程序等技術(shù)棧。目前已經(jīng)廣泛應(yīng)用于京東商城、京東金融、京東到家、京東拼購(gòu)等京東系核心 App 內(nèi)，幫助業(yè)務(wù)團(tuán)隊(duì)低成本、快速開(kāi)發(fā)自己的業(yè)務(wù)，以應(yīng)對(duì)市場(chǎng)的瞬息萬(wàn)變之勢(shì)。
掃碼加我微信和大佬們零距離
開(kāi)發(fā)者技術(shù)前線 ，匯集技術(shù)前線快訊和關(guān)注行業(yè)趨勢(shì)，大廠干貨，是開(kāi)發(fā)者經(jīng)歷和成長(zhǎng)的優(yōu)秀指南。
