京東技術中臺Flutter實踐之路（二）

移動網際網路歷經高速發展的黃金10年，多樣的市場需求催化了前端技術不斷升級改造，真正的前端大統一時代正在來臨，不管你願不願意相信，大前端技術的發展趨勢已是定勢，前進的腳步無可改變。 眾所周知，iOS、Android、Web分別代表著前端技術需要考慮的必要方向，傳統的移動網際網路開發需要同時考慮多個平臺對應的技術研發資源儲備，公司開發同一個業務，需要至少三個獨立團隊參與評審及開發，測試也需要至少三倍工作量以完成對應平臺的程式碼測試，這樣的生產效率已無法滿足業務快速迭代的需要，生產成本之高也嚴重考驗著企業的承受能力，且多個平臺的一致性體驗並不盡如人意，因此，僅使用一套程式碼，同時適配多個平臺的能力就顯得極為重要。 目前，Hybrid、RN、weex、小程式等框架陸續推出，各網際網路大廠也在積極嘗試跨端開發技術的實踐應用，已有很多業務使用到跨端技術，但各個框架各有優劣，且仍然離不開原生開發；而Flutter框架推出後，以其效能高，多端平臺的UI一致性高，及開發除錯效率高等強優勢，越來越吸引著原生開發者的注意，併成為其首選的跨平臺技術框架。

近年，京東技術中臺也在移動應用跨端開發領域進行了深度探索與實踐，JDReact已廣泛應用於京東係數十APP的幾百個業務內，京東小程式開放平臺也於2020年4月正式釋出推廣， 而備受矚目的Flutter，我們早在2017年的官方非正式版推出後，即投入調研開發，並在物流APP內實現驗證上線，其高效的除錯效率，極低的UI試錯成本，以及接近原生的流暢性體驗，都給了我們很大的吸引力。2018年初，我們將現有的混合APP進行了一次重構，歷時兩個月，實現了第一個純Flutter APP正式上線，研發人力縮減25%，開發效率得到了明顯的提升。 在這次重構中，我們也意識到，雖然Flutter具有很令人興奮的優勢，但也存在明顯的缺點，例如，Flutter技術生態尚不成熟，開發者初期投入，一般都會面臨大量時間投入在框架的基礎建設中，人力消耗反而很高。為了避免京東內部團隊重複建設，構建高可複用的Flutter基礎設施，從根本上實現真正的降本提效，京東技術中臺成立了專項團隊進行JDFlutter的研發與建設，專注於Flutter基礎生態建設，為內部Flutter開發者提供包含專業開發工具鏈、SDK、元件的一站式開發解決方案。

我們的目標：解決實戰開發問題，打造暢快開發體驗，共建Flutter生態。

內容回顧：乾貨 | 京東技術中臺的Flutter實踐之路 （一）

JDFlutter歷經2019年的發展與積累，以提供混合路由+Flutter元件+技術支援的方式，已經與京東App，影片App，物流App，到家App，一號店APP，7Fresh，掌櫃寶，極速版APP等數十個開發團隊進行交流，並建立了合作關係。期間我們發現，App開發團隊在使用Flutter改造業務時，普遍會碰到如下問題，導致開發效率非但沒有得到提升，App容錯能力等反而會降低：

2020年初，技術與資料中臺-共享技術部重點投入資源，全面升級JDFlutter，以JDFlutter容器+開發工具+全新元件平臺+Demo App+技術社群等矩陣型產品，為開發者提供了一站式移動應用跨端開發解決方案，幫助Flutter開發者降低接入及開發成本，助力提升業務效率。

01 容器

容器是我們在作業系統和業務執行邏輯之間的中間層，它隔離了作業系統和應用邏輯的直接聯絡，也隔離業務和基礎元件之間的依賴，讓開發者無需關心各個作業系統的差異，只需面向容器API程式設計即可，這樣做的好處有以下幾點：

02 動態化

動態化作為順應業務高速發展及低成本試錯，實現靈活高效發版和更新的重要手段，近年來顯得尤為重要，甚至成為了衡量移動端框架優劣的核心指標，RN、小程式等之所以能被大規模使用，也和支援動態更新，無需發版安裝有著一定的關係。

Flutter本身在跨平臺和效能方面都表現卓越，但是由於蘋果對於動態程式碼執行的限制，導致Flutter無法實現iOS端的動態化，這可能是它的不足之處（主要是蘋果的政策原因和技術無關）。經過我們的調研，目前市場上動態化實現的方式有兩種，一種是以Dart作為DSL動態下發的方式來實現佈局的動態化，另外一種是用JS來開發UI生成描述資訊，最終由Flutter進行渲染。 JDFlutter在動態化方面也做了一些探索嘗試，我們的目標是採用Flutter環境進行開發除錯，使用動態化框架開發出來的程式碼既能動態化執行，也能在Flutter原生環境中執行，同時不入侵Flutter的底層框架，對Flutter sdk升級保持很好的相容性。 本文簡單闡述實現思路，後續將單獨介紹具體的實現方法。 使用Flutter開發環境進行開發和除錯程式，釋出時採用dart2js技術將Flutter程式碼轉換成js程式碼，釋出到服務端，然後由Flutter容器從服務端下載程式碼，執行js邏輯，將js渲染的佈局資訊，傳遞到Flutter層，最終由Flutter渲染出來。

03 模組注入

我們在JDFlutter封裝了一套應用開發所需的基礎模組：包含網路，圖片，異常，埋點，效能，裝置，掃碼，影片等業務開發所需模組，模組分為兩種型別，一種是基於純dart開發的模組，另外一種是基於native封裝的模組。根據不同的編譯產物我們會注入不同型別的模組來滿足不同執行平臺的需求，如編譯成web產物，會注入純dart的網路模組來代替封裝的native模組。

04 Flutter2Web

體量及規模龐大的線上業務活動，在巨大流量衝擊下，可能會面臨當機的風險，類似情況，服務端普遍會透過如叢集擴容、多機房部署、限流、削峰、降級兜底等預案進行部署。同樣，移動端上線新業務，在未經過大規模驗證的情況下，也可能在個別場景出現異常，需要考慮兜底方案，以減少線上事故的發生。

此時除了動態化修復更新之外，我們使用了Flutter2web工具將Flutter業務轉換成H5，用於降級容災。JDFlutter容器抹平了native和web的API，在程式碼不用做改動的情況下，支援將Flutter應用轉換web應用，執行在JDFlutter的webview中，並提供js channel的支援，web依然可以呼叫原生能力。

05 iOS瘦身

Flutter打出的ipa包一般會比較大，先期京東APP上線的6個Flutter業務整合後，致使iOS客戶端增加了約17M。為了減少包大小，我們借鑑了位元組跳動的做法，對引擎做了改造，將App.framework和Flutter.framwork的部分資料透過動態下發的方式來實現，同時剝離了資原始檔。改造之後，對Flutter業務進行再次打包測試，包體積可減少約28%左右，瘦身效果明顯，且隨著業務數量的增加，瘦身的效果及收益會更為顯著，以下是瘦身方案，後續關於iOS瘦身，也會做詳細的分享。

2020年，正是JDFlutter產品化及規模化發展的元年，京東技術與資料中臺-共享技術部已經投入大量的核心研發人力，對專案進行重點建設；當前JDFlutter的每一項開發任務，都是為了幫助京東的業務研發團隊更快速更順利的實現業務發展目標，不止於此，JDFlutter未來也會更加開放，以專業的商業化解決方案來幫助更多外部開發者。 我們也和Google的Flutter的研發團隊保持著密切的聯絡，對技術問題進行探討和分享，後續對於容器，動態化，Flutter2web，Flutter瘦身，持續整合，Pub倉庫等方面的最新進展及成果，我們會持續為大家帶來專題分享，期待大家的關注與支援。

歡迎加入JDFlutter技術專區探討交流。

QQ群：1022619726

閱讀原文