建站
咨詢
售后
建站咨詢
新聞中心
2019 年無疑是 Flutter 技術(shù)如火如荼發(fā)展的一年。每一個(gè)移動開發(fā)者都在為 Flutter 帶來的“快速開發(fā)、富有表現(xiàn)力和靈活的 UI、原生性能”的特色和理念而癡狂，從超級 App 到獨(dú)立應(yīng)用，從純 Flutter 到混合棧，開發(fā)者們在不同的場景下樂此不疲的探索和應(yīng)用著 Flutter 技術(shù)，也在面臨著各種各樣不同的挑戰(zhàn)。
網(wǎng)站建設(shè)哪家好，找成都創(chuàng)新互聯(lián)公司！專注于網(wǎng)頁設(shè)計(jì)、網(wǎng)站建設(shè)、微信開發(fā)、小程序定制開發(fā)、集團(tuán)企業(yè)網(wǎng)站建設(shè)等服務(wù)項(xiàng)目。為回饋新老客戶創(chuàng)新互聯(lián)還提供了十堰免費(fèi)建站歡迎大家使用！
為什么是 Flutter？
阿里巴巴集團(tuán)內(nèi)也有越來越多的業(yè)務(wù)和團(tuán)隊(duì)開始嘗試 Flutter 技術(shù)棧，從閑魚的一支獨(dú)秀引領(lǐng)潮流，到如今淘 寶特價(jià)版 、盒馬、優(yōu)酷、飛豬等BU業(yè)務(wù)相繼入局，F(xiàn)lutter的業(yè)務(wù)應(yīng)用在集團(tuán)內(nèi)也已經(jīng)逐漸形成趨勢。
那么，是什么原因讓集團(tuán)內(nèi)越來越多的開發(fā)者選擇擁抱Flutter技術(shù)棧？Flutter的哪些優(yōu)勢吸引了集團(tuán)Native開發(fā)者們通過Flutter開發(fā)并交付業(yè)務(wù)？
從技術(shù)上看，個(gè)人認(rèn)為Flutter最核心的3個(gè)特點(diǎn)最為吸引開發(fā)者：
-
極高的開發(fā)與交付效率，良好的開發(fā)體驗(yàn)
-
優(yōu)秀的跨多端多平臺能力
-
極強(qiáng)的 UI 表現(xiàn)力
先說一下 開發(fā)效率 。從集團(tuán)電商業(yè)務(wù)屬性出發(fā)，業(yè)務(wù)響應(yīng)效率及其背后的研發(fā)效率從來都是最為重要的指標(biāo)。 在保證體驗(yàn)的前提下，盡可能的提高研發(fā)效率，就意味著更高的生產(chǎn)力。
傳統(tǒng)的 Native 業(yè)務(wù)研發(fā) iOS/Android 雙端需要分別投入，研發(fā)成本高，端差異性大且依賴端側(cè)發(fā)版，這也是為什么集團(tuán)電商業(yè)務(wù)的活動類技術(shù)棧一直較為依賴前端體系，從H5到Weex到小程序，很大程度上就是在追求研發(fā)和交付效率以及靈活性。
如今 Flutter 很好的解決了跨端一致性問題，一套代碼無差異的同時(shí)跑在 iOS 與 Android 兩端；開發(fā)體驗(yàn)基本接近前端，支持 on device 的 Hot Reload ，去年年底 Flutter 又推出了在 Android Studio 中通過插件實(shí)現(xiàn)實(shí)時(shí)預(yù)覽并支持交互的 Hot UI 能力，以及 Layout Explorer 可視化布局，讓Flutter的開發(fā)效率和前端效率基本持平。
電商業(yè)務(wù)發(fā)展到當(dāng)前階段，已經(jīng)不再僅僅局限于移動端場景，越來越多的業(yè)務(wù)需求對跨端跨平臺性提出了更高的要求。釘釘/千牛桌面端應(yīng)用場景，甚至天貓精靈、線下門店等業(yè)務(wù)場景，從長遠(yuǎn)看都需要一個(gè)比 Web 性能一致性更好適配成本更低的多端方案。
目前跨多端技術(shù)方案主要依賴于瀏覽器和前端體系，但瀏覽器本身的沙盒屬性、與系統(tǒng)較低的結(jié)合度、以及在低端設(shè)備上較差的性能都降低了研發(fā)效率和用戶體驗(yàn)，提高了業(yè)務(wù)的交付門檻。
可以說目前集團(tuán)內(nèi)的跨多端多平臺方案是實(shí)質(zhì)缺失的。Flutter 從設(shè)計(jì)上就天然支持多平臺開發(fā)，它的底層基于 Skia 跨平臺圖形引擎，向上構(gòu)建出了一整套平臺無關(guān)的渲染體系和事件處理體系，并緊貼 Native 研發(fā)模式自定義了基于 widgets 的聲明+響應(yīng)式編程范式，對系統(tǒng)能力依賴度低，并具備出色的跨平臺還原度；支持多平臺也是 Flutter 的戰(zhàn)略目標(biāo)之一。
目前除了 iOS 和 Android ，官方宣布支持的平臺有 Mac、Windows 和 Web，Linux 也在開發(fā)中，它的技術(shù)特性也讓將 Flutter移植到 Linux based IoT 平臺上成本很低，同時(shí) Flutter 還是未來 Google 的下一代操作系統(tǒng) Fuschia 的官方應(yīng)用研發(fā)框架。
可以說Flutter已經(jīng)具備了成為下一代跨多端多平臺研發(fā)模式的一切條件，圍繞Flutter建立集團(tuán)的多端多平臺研發(fā)體系是非?？尚械倪x擇。
最后講一下 UI 表現(xiàn)力 。電商業(yè)務(wù)重體驗(yàn)，重交互，尤其對于流量精細(xì)化運(yùn)營場景，富交互的游戲化表現(xiàn)方式已經(jīng)成為流量促活的重要手段。
在 UI 表現(xiàn)力方面，前端體系一直具備著優(yōu)勢，通過 CSS3 強(qiáng)大的動畫能力，開發(fā)者可以非常容易的實(shí)現(xiàn)復(fù)雜的動畫效果和交互體驗(yàn)，而基于 Native UI ，需要借助各種動畫特效三方庫，雙端開發(fā)體驗(yàn)不一致，實(shí)現(xiàn)復(fù)雜且交付效率低。
Flutter很好的解決了這個(gè)問題，從補(bǔ)間（Tween）動畫、基于物理屬性的動畫，到相對復(fù)雜的頁面間Hero動畫、parallax交錯(cuò)動畫等特效，F(xiàn)lutter都可以跨平臺低成本的高效實(shí)現(xiàn)。
這里貼一個(gè)去年年底Flutter Interact大會上GSkinner公布的基于Flutter實(shí)現(xiàn)的交互Demo讓大家直觀感受一下：
可以看到 Flutter 的強(qiáng)大 UI 表現(xiàn)力，可以幫助開發(fā)者快速高效低成本的開發(fā)出極為炫酷的 UI ，非常適合電商領(lǐng)域重 UI 視覺交互的各類場景，幫助業(yè)務(wù)構(gòu)建出富有表現(xiàn)力的頁面。
Flutter體系化建設(shè)現(xiàn)狀
目前集團(tuán)內(nèi)有多個(gè)業(yè)務(wù) BU 均已開始嘗試應(yīng)用 Flutter 技術(shù)棧，涵蓋了從電商詳情業(yè)務(wù)、導(dǎo)購頻道，到 Feeds 流、游戲化交互以及國際化等多個(gè)業(yè)務(wù)場景。
目前 Flutter 技術(shù)在集團(tuán)應(yīng)用的痛點(diǎn)在于，研發(fā)基礎(chǔ)設(shè)施的中臺基建不夠完善，研發(fā)支撐能力與數(shù)據(jù)運(yùn)維能力未實(shí)現(xiàn)標(biāo)準(zhǔn)化，集團(tuán) Flutter 開發(fā)者生態(tài)還未完全拉通，暫時(shí)未能形成合力。 這些問題將是我們后面在集團(tuán)層面建設(shè) Flutter 技術(shù)體系的重點(diǎn)。
另一方面從行業(yè)趨勢上看，F(xiàn)lutter 技術(shù)已經(jīng)成為越來越多行業(yè)伙伴重點(diǎn)投入的技術(shù)建設(shè)方向。
字節(jié)跳動、美團(tuán)等公司均建設(shè)了自己的 Flutter 工程化體系，并服務(wù)了各自的業(yè)務(wù)場景； 騰訊也基于 Flutter 在多個(gè) App 上進(jìn)行了應(yīng)用嘗試，并在 Flutter 渲染能力服務(wù)小程序的場景下做了有益探索。
行業(yè)伙伴們在 Flutter 技術(shù)上的投入力度和決心，一方面讓我們對 Flutter 技術(shù)的應(yīng)用前景和社區(qū)更有信心，另一方面也讓我們感到聯(lián)合集團(tuán)各方力量共建 Flutter 生態(tài)的必要性和緊迫性。
? 手淘的嘗試和思考
最后，簡單講一下我們從18年到現(xiàn)在在 Flutter 上做的探索和思考。
手淘從18年10月開始探索 Flutter 渲染引擎應(yīng)用在小程序場景；19年下半年開始建設(shè) Flutter 基礎(chǔ)能力，并服務(wù)了淘寶特價(jià)版業(yè)務(wù)，在引擎、圖片庫、內(nèi)存優(yōu)化和加載性能等關(guān)鍵技術(shù)上做了沉淀；同時(shí)通過對 Flutter 的引擎改造，封裝出 Flutter 2D Canvas 能力，向上支持小程序 Canvas 組件及小游戲引擎，服務(wù) 2D/2.5D 游戲化業(yè)務(wù)，并在業(yè)務(wù)場景中落地。
在這個(gè)過程中，我們也沉淀了解決內(nèi)存問題和圖片問題等方案，以及 Flutter 技術(shù)與 Web 技術(shù)的對比與思考，取得了一定的技術(shù)及業(yè)務(wù)價(jià)值。
通過這些嘗試，加深了我們對 Flutter 技術(shù)的掌控力和理解。在我們看來， Flutter 的橫空出世，完全可以被看作吹響了 Native 體系復(fù)興的號角。
在保持 Native 性能優(yōu)勢的前提下，F(xiàn)lutter 帶來了優(yōu)秀的跨端一致性、貼近前端的研發(fā)效率，以及強(qiáng)大的 UI 表現(xiàn)力，為集團(tuán)業(yè)務(wù)使用 Native技術(shù)棧帶來了新的可能。
從業(yè)務(wù)應(yīng)用上看： Flutter 目前帶來的最大價(jià)值是研發(fā)效率的提升。在基建和 native 擴(kuò)展能力完備的前提下，開發(fā)基于 Flutter 的純 Dart 業(yè)務(wù)的人效比之前各端分別開發(fā)的效率提高了接近 2 倍，單位時(shí)間內(nèi)的需求響應(yīng)能力也相應(yīng)提高了接近2倍，目前已在閑魚和特價(jià)版業(yè)務(wù)開發(fā)中得到了很好的工程化驗(yàn)證。
從適應(yīng)場景看： Flutter 目前比較適合承載富圖文內(nèi)容，如詳情、Feeds 流、用戶主頁等常規(guī)業(yè)務(wù)開發(fā)，以及 2D/2.5D 游戲場景以及富動效業(yè)務(wù)。
Flutter 通過單端技術(shù)?？梢酝瑫r(shí)滿足以前需要 iOS、Android 以及前端技術(shù)棧分別負(fù)責(zé)的業(yè)務(wù)場景，甚至可以通過端云一體化的開發(fā)模式使用 Dart 負(fù)責(zé)一部分服務(wù)端業(yè)務(wù)邏輯開發(fā)，可以幫助業(yè)務(wù)團(tuán)隊(duì)拓展業(yè)務(wù)邊界的同時(shí)，實(shí)現(xiàn)前后端研發(fā)能力閉環(huán)。
Flutter 目前的限制在于，動態(tài)性能力及前期的投入成本。 前期投入成本主要指技術(shù)學(xué)習(xí)與團(tuán)隊(duì)研發(fā)模式升級的成本，涉及到技術(shù)路線選擇，是我們和每個(gè)業(yè)務(wù)團(tuán)隊(duì)需要一起思考和判斷的，這里不展開談。
動態(tài)性能力是 Flutter 的相對短板， 目前能夠通過 Flutter 模板化技術(shù)實(shí)現(xiàn)基于模板的組件級動態(tài)化能力，但基于性能、審核及對原生 Flutter 體系的侵入性等多種因素，目前還不能去直接實(shí)現(xiàn)UI + 邏輯動態(tài)化能力。
Flutter Web 方案雖然不存在審核限制，但受限于瀏覽器 DOM API 與 widgets 體系的差異性，目前仍舊存在較嚴(yán)重的性能瓶頸和渲染差異性，僅可作為降級的備用方案，暫時(shí)無法作為動態(tài)化的主要實(shí)現(xiàn)方案。
未來在動態(tài)化方向的探索也將是個(gè)長期的博弈過程。 如果后面我們可以解決好 Flutter 動態(tài)化的問題，那么 Flutter 完全有機(jī)會成為集團(tuán)業(yè)務(wù)的核心研發(fā)模式之一。
綜上我們認(rèn)為，入局 Flutter 的時(shí)機(jī)已成熟，合力共建 Flutter 集團(tuán)移動生態(tài)，這件事情大有可為。
AliFlutter - 經(jīng)濟(jì)體移動小組Flutter共建項(xiàng)目
在這樣的背景下，經(jīng)濟(jì)體移動技術(shù)小組今年也將端側(cè)架構(gòu)治理的重點(diǎn)方向放在 了 Flutter 上。移動技術(shù)小組從戰(zhàn)略角度提出了 AliFlutter 項(xiàng)目，目標(biāo)非常明確：
-
從經(jīng)濟(jì)體層面拉通 Flutter 體系建設(shè)，打造 Flutter 的公共技術(shù)基礎(chǔ)設(shè)施，制定 Flutter 容器、中間件與 API 標(biāo)準(zhǔn)，建設(shè) Flutter 研發(fā)支撐與數(shù)據(jù)運(yùn)維能力，復(fù)用關(guān)鍵技術(shù)；
-
聯(lián)合各 BU 構(gòu)建經(jīng)濟(jì)體Flutter技術(shù)社區(qū)，沉淀共享集團(tuán) Flutter 技術(shù)及業(yè)務(wù)組件、能力與解決方案，服務(wù)集團(tuán) Flutter 業(yè)務(wù)，共建集團(tuán) Flutter 技術(shù)生態(tài)；
-
在經(jīng)濟(jì)體層面構(gòu)建 Flutter 的對外影響力，聯(lián)合各 BU 一致對外，打造阿里在行業(yè)內(nèi)的 Flutter 技術(shù)制高點(diǎn)。
為經(jīng)濟(jì)體的 Flutter 技術(shù)體系“建基礎(chǔ)、育社區(qū)、扛大旗”，我們責(zé)無旁貸。
未來 AliFlutter 的整體架構(gòu)如下所示：
AliFlutter 建設(shè)的第一步， 就是要構(gòu)建集團(tuán)的 Flutter 基礎(chǔ)設(shè)施、提供公共容器與組件、研發(fā)支撐服務(wù)與標(biāo)準(zhǔn)化研發(fā)流程， 為集團(tuán)的 Flutter 業(yè)務(wù)提供一個(gè)基礎(chǔ)的Flutter公共研發(fā)服務(wù)能力，搭建好技術(shù)共建共享的基礎(chǔ)和平臺；
第二步， 我們要服務(wù)好 Flutter 業(yè)務(wù)應(yīng)用，探索業(yè)務(wù)應(yīng)用模式與 Flutter 技術(shù)特性的結(jié)合點(diǎn)， 并在過程中打磨技術(shù)，形成針對業(yè)務(wù)特點(diǎn)的解決方案與技術(shù)沉淀，真正盤活集團(tuán)內(nèi)的 Flutter 社區(qū)共建氛圍與生態(tài)；
第三步， 面向未來，解決好Flutter應(yīng)用的幾個(gè)核心關(guān)鍵問題： 跨端與交互能力、業(yè)務(wù)研發(fā)效率與業(yè)務(wù)交付效率，通過技術(shù)賦能業(yè)務(wù)，讓 Flutter 真正成為集團(tuán)移動業(yè)務(wù)的核心研發(fā)模式。
接下來，就詳細(xì)講一講每個(gè)階段 AliFlutter 所做的工作和面向未來的思考。
基礎(chǔ)設(shè)施建設(shè)
從19年10月 AliFlutter 項(xiàng)目啟動開始到現(xiàn)在，我們基本構(gòu)建起了一套 Flutter 的公共基礎(chǔ)設(shè)施，包括 Artifacts 與 pub 庫，F(xiàn)lutter 標(biāo)準(zhǔn)容器與 API 標(biāo)準(zhǔn)，并實(shí)現(xiàn)了 Flutter 的構(gòu)建打包自動化，定義了標(biāo)準(zhǔn)的引擎定制工作流與業(yè)務(wù)研發(fā)工作流。目前基礎(chǔ)設(shè)施已經(jīng)具備支撐集團(tuán) Flutter 業(yè)務(wù)研發(fā)的能力，并支持各 BU 按需定制。
? Artifacts倉庫
產(chǎn)物服務(wù)器主要是為了配合引擎定制，加速通過 Flutter 命令獲取 Engine 中間產(chǎn)物的后端服務(wù)，便于統(tǒng)一 Flutter 開發(fā)者的工作環(huán)境。
開發(fā)者可通過設(shè)置 FLUTTER_STORAGE_BASE_URL來將Flutter工具鏈獲取 artifacts 的地址指向該服務(wù)，同時(shí)通過 namespace 便可實(shí)現(xiàn)定制化的獲取 artifacts 的能力以及內(nèi)網(wǎng)加速服務(wù)。
Namespace 設(shè)計(jì)為區(qū)分不同 BU 的引擎產(chǎn)物，同時(shí)提供了公共 namespace 來存儲公共產(chǎn)物，確保定制性和公共能力的按需配置；若后端存儲上不存在需要獲取的產(chǎn)物地址，則會觸發(fā)從 Flutter 官方鏡像做一次獲取并緩存在服務(wù)端。
各 BU 可按需定制引擎，并按規(guī)定的路徑格式上傳至自己 namespace 中，即可實(shí)現(xiàn)從 namespace 中獲取定制版本的引擎中間產(chǎn)物。
? pub倉庫
類似于 Node.js 世界的 npm，F(xiàn)lutter 使用 pub 來管理三方組件與依賴?？紤]到易用性、安全性等需求，為了管理集團(tuán)內(nèi)的公共二方組件，我們也搭建了內(nèi)網(wǎng)環(huán)境的 Flutter pub 庫。該庫的目標(biāo)是成為集團(tuán)的 pub 發(fā)布平臺，管理集團(tuán)內(nèi)所有二、三方 pub package。
用戶可通過設(shè)置 PUB_HOSTED_URL 指向內(nèi)部地址，來實(shí)現(xiàn)通過 Flutter 工具鏈獲取配置以及發(fā)布二方 pub 的能力，用戶也可以通過 Web portal 的方式訪問 pub 庫并查詢已發(fā)布的 pub 組件。
? 容器、中間件與API
對于業(yè)務(wù)的接入而言，現(xiàn)階段核心要解決的問題就是提供一個(gè)統(tǒng)一的 Flutter 運(yùn)行時(shí)容器，以及一系列集團(tuán)標(biāo)準(zhǔn)化移動中間件的 Flutter 封裝與 API 能力，并提供集團(tuán)標(biāo)準(zhǔn)的插件擴(kuò)展方式供業(yè)務(wù)方獨(dú)立開發(fā)業(yè)務(wù)功能。
鑒于集團(tuán)應(yīng)用基本上均以混合棧為主，我們將 FlutterBoost 作為 Flutter 容器混合棧的基礎(chǔ)，并配合集團(tuán)標(biāo)準(zhǔn)路由與導(dǎo)航中間件提供了統(tǒng)一的混合棧路由導(dǎo)航能力，業(yè)務(wù)通過標(biāo)準(zhǔn)路由注冊即可快速實(shí)現(xiàn) Flutter 頁面和 Native 頁面的混合導(dǎo)航能力。
容器通過對接高可用平臺，提供了初始化性能埋點(diǎn)與 Crash 數(shù)據(jù)上報(bào)等標(biāo)準(zhǔn)監(jiān)控能力，為 Flutter 業(yè)務(wù)的技術(shù)性能分析和問題排查提供了基礎(chǔ)。集團(tuán)移動端積累了一整套的標(biāo)準(zhǔn)中間件體系，包括網(wǎng)絡(luò)庫、圖片庫、push 消息、配置下發(fā)、數(shù)據(jù)采集與監(jiān)控等一系列基礎(chǔ)能力，在 Flutter 體系內(nèi)無縫使用移動中間件能力對于業(yè)務(wù)是剛需。
同時(shí)，小程序體系建設(shè)過程中形成的一系列標(biāo)準(zhǔn) API，也很大程度上實(shí)現(xiàn)了一個(gè)完整的小程序運(yùn)行環(huán)境的底層能力抽象，對于 Flutter 體系標(biāo)準(zhǔn)化的訪問系統(tǒng)能力，實(shí)現(xiàn)平臺無關(guān)的跨端能力是個(gè)非常好的補(bǔ)充。
我們聯(lián)合淘寶中間件團(tuán)隊(duì)與小程序團(tuán)隊(duì)，對基礎(chǔ)中間件和小程序 API 實(shí)現(xiàn)做了 Flutter 側(cè)的封裝與標(biāo)準(zhǔn)化，未來也將對 Flutter 中間件和 API 能力進(jìn)行系統(tǒng)支持。
? 標(biāo)準(zhǔn)化Flutter構(gòu)建
由于 Flutter 研發(fā)體系較新，且構(gòu)建 Pipeline 相較傳統(tǒng)的移動構(gòu)建流程又存在一定特殊性，產(chǎn)物構(gòu)建配置復(fù)雜耗時(shí)長易出錯(cuò)，給 Flutter 業(yè)務(wù)的構(gòu)建和發(fā)版帶來了很大阻礙。
因此我們也聯(lián)合研發(fā)支撐部的同學(xué)，以插件的形式實(shí)現(xiàn)了 Flutter 腳本化的構(gòu)建流程，支持雙端自動整包打包和 Flutter Module 打包。
目前 AliFlutter 的構(gòu)建流程默認(rèn)使用 AliFlutter 的 Flutter 倉庫以及集團(tuán)內(nèi)部 pub 倉庫，引擎產(chǎn)物也統(tǒng)一按配置從 artifacts 倉庫獲取，較好的實(shí)現(xiàn)了支持 Flutter 業(yè)務(wù)的自動化構(gòu)建需求。
業(yè)務(wù)應(yīng)用
在夯實(shí) Flutter 集團(tuán)共建基礎(chǔ)之后，第二步，我們 AliFlutter 在業(yè)務(wù)應(yīng)用方面也做了大量工作。
一方面通過原生 Flutter 的工程化能力持續(xù)服務(wù)淘系與集團(tuán)業(yè)務(wù)；另一方面通過 Flutter Canvas 項(xiàng)目服務(wù)了小程序場景及游戲化場景下的互動業(yè)務(wù)
? 淘系與集團(tuán)業(yè)務(wù)支撐
目前淘寶特價(jià)版已完成詳情業(yè)務(wù)的 Flutter 改造并上線，采用 Flutter 使業(yè)務(wù)在需求節(jié)奏不變的情況下人力投入減少一半，對緩解業(yè)務(wù)研發(fā)壓力起到了明顯的作用；同時(shí)應(yīng)用的整體性能和穩(wěn)定性與 Native 基本持平。
后續(xù)特價(jià)版將基于 Flutter 繼續(xù)拓展業(yè)務(wù)改造范圍，并沉淀基于 Flutter 的業(yè)務(wù)域解決方案。
目前盒馬、ICBU 、優(yōu)酷也基于 AliFlutter 進(jìn)行了容器接入升級與業(yè)務(wù)適配，盒馬依托閑魚的 Flutter 游戲引擎實(shí)現(xiàn)了盒馬小鎮(zhèn)業(yè)務(wù)，ICBU 在主鏈路相關(guān)頁面使用了 Flutter，優(yōu)酷則基于 Flutter 實(shí)現(xiàn)了會員訂單頁等場景。
同時(shí)我們也在和釘釘及 Google 一起探索 Flutter 桌面端的解決方案。
? Flutter Canvas
在電商活動營銷中互動場景日益增多，對性能要求持續(xù)提升的前提下，
如何提供一個(gè)高性能且穩(wěn)定的Canvas基礎(chǔ)能力服務(wù)好富交互的互動場景就成為了一個(gè)重點(diǎn)的課題。
在小程序場景中 Canvas 作為承載互動游戲的主要能力發(fā)揮了重要作用。然而受限于小程序架構(gòu)下 app context 和 page context 的隔離設(shè)計(jì)，存在從 app worker 到 page renderer 的通信瓶頸，無法充分發(fā)揮出 web canvas 的性能，如果有一個(gè) native 版的 canvas 實(shí)現(xiàn)將可直接在 native 層對接 app worker ，降低通信成本，充分發(fā)揮 Canvas 的性能。
Flutter 底層基于 Skia，其性能和移動端復(fù)雜異構(gòu)機(jī)型的適配性均得到過長期的檢驗(yàn)，且 Flutter 基于瀏覽器的設(shè)計(jì)實(shí)現(xiàn)了一條平臺無關(guān)的渲染管線，并對瀏覽器實(shí)現(xiàn)做了極大的簡化，提供了很好的可靠性和性能。那么如果能夠?qū)⑦@條渲染管線直接用于向業(yè)務(wù)容器提供 Canvas 能力，通過 binding 方式直接向小程序和小游戲容器提供與 Web Canvas 一致的標(biāo)準(zhǔn) API，一方面可以復(fù)用 Flutter 的底層能力，為非 Dart 環(huán)境提供渲染支持，另一方面可以借助 Flutter 簡化高效的渲染管線實(shí)現(xiàn)提供更好的渲染性能。
目前 Flutter Canvas 已落地手機(jī)淘寶，并在小程序運(yùn)動銀行業(yè)務(wù)進(jìn)行了灰度試點(diǎn)，初步具備了承載小程序 Canvas 業(yè)務(wù)的能力；其性能在 Android 低端機(jī)上的表現(xiàn)有優(yōu)勢，可以作為 Web Canvas 方案的有益補(bǔ)充。
未來 Flutter Canvas 一方面將借助 Flutter 渲染管線的跨平臺與高性能特點(diǎn)，以及 Flutter 對 Vulkan 和 Metal 的適配支持，在移動端獲得更好的適配性以及性能；同時(shí)將繼續(xù)實(shí)現(xiàn) 3D API ，支撐未來互動類的業(yè)務(wù)應(yīng)用。
未來建設(shè)
扎根業(yè)務(wù)之后，接下來的第三步，我們要緊貼 Flutter 體系在阿里集團(tuán)未來的建設(shè)目標(biāo)，持續(xù)回答好Flutter面向未來建設(shè)路徑中的幾個(gè)關(guān)鍵問題。那么首先，F(xiàn)lutter體系在阿里集團(tuán)的建設(shè)目標(biāo)應(yīng)該是什么？個(gè)人以為：
Flutter應(yīng)成為阿里集團(tuán)未來跨多端多平臺的核心業(yè)務(wù)研發(fā)模式之一。
那么，我們目前離這個(gè)目標(biāo)還有多大差距？在我看來，如果要想讓Flutter成為業(yè)務(wù)的核心研發(fā)模式，那么必須解決好 跨端能力、交互能力、業(yè)務(wù)研發(fā)效率以及業(yè)務(wù)交付效率四個(gè)核心問題。
-
從跨端能力看： Flutter雖然已具備了很好的跨多端能力與高還原度，但涉及到平臺能力時(shí)，仍然需要通過各端擴(kuò)展實(shí)現(xiàn)，還未形成小程序體系這樣的標(biāo)準(zhǔn)化的容器和API封裝能力。那么如何更好的解決Flutter的容器化問題，讓業(yè)務(wù)不感知平臺差異性？
-
從交互能力看： Flutter如何利用好自身交互能力的優(yōu)勢，在提供媲美前端的富交互體驗(yàn)的同時(shí)，降低Native富交互特性開發(fā)的門檻，真正吸引Native開發(fā)者使用Flutter技術(shù)開發(fā)業(yè)務(wù)？
-
從業(yè)務(wù)研發(fā)效率看： 雖然 Flutter 的 Hot Reload/Hot UI 機(jī)制已經(jīng)讓開發(fā) Native 頁面的效率追上了前端，但在工程解耦方面仍然有很大提升空間，目前還無法高效的支持多業(yè)務(wù)團(tuán)隊(duì)并行開發(fā)；另一方面如何與現(xiàn)今流行的 Serverless 能力結(jié)合，實(shí)現(xiàn)端云一體研發(fā)模式，使業(yè)務(wù)實(shí)現(xiàn)研發(fā)閉環(huán)，也需要實(shí)踐的檢驗(yàn)。
-
從業(yè)務(wù)交付效率看： 目前 Flutter 仍屬于 Native 方案，依賴端側(cè)發(fā)版，交付效率低，無法很好的承載電商系靈活性和實(shí)效性的需求；那么如何解決Flutter的動態(tài)化，幫助業(yè)務(wù)實(shí)現(xiàn)快速迭代？
解決好這幾個(gè)問題，才能真正讓 Flutter 成為集團(tuán)移動業(yè)務(wù)的核心研發(fā)模式，為集團(tuán)業(yè)務(wù)研發(fā)帶來一個(gè)飛躍性的提升。下面講講我們在這幾個(gè)方向的思考和探索。
? 提升跨端能力： Flutter 容器化
從工程角度看，雖然 Flutter 通過 Skia 跨平臺圖形渲染和自建事件體系基本實(shí)現(xiàn)了對宿主平臺的最小依賴，但對于平臺側(cè)能力，目前 Flutter 還未也沒有必要從應(yīng)用框架角度做到一個(gè)統(tǒng)一的抽象，這就需要我們根據(jù)業(yè)務(wù)的訴求和特點(diǎn)進(jìn)行有選擇的封裝。
小程序 API 就做了一個(gè)非常好的示范，目前阿里小程序體系提供的API達(dá)到了200+，很好的對移動端的UI、多媒體、文件緩存、網(wǎng)絡(luò)、設(shè)備能力、數(shù)據(jù)安全以及業(yè)務(wù)相關(guān)能力進(jìn)行了封裝，讓業(yè)務(wù)開發(fā)者在小程序側(cè)針對API進(jìn)行系統(tǒng)能力調(diào)用，無需關(guān)心平臺實(shí)現(xiàn)。
因此 AliFlutter 容器接下來的規(guī)劃就是從工程體系的角度，提供一套標(biāo)準(zhǔn)化的 API 能力，以規(guī)范并抽象移動端的端基礎(chǔ)能力，使業(yè)務(wù)盡量少甚至不關(guān)心平臺差異性，專注于業(yè)務(wù)；同時(shí)借助標(biāo)準(zhǔn)化 API 的能力，實(shí)現(xiàn)跨多端多平臺部署。
從移動端架構(gòu)角度看，各個(gè)時(shí)期的跨平臺方案都對 API 能力有著共同的訴求，從 H5 到 Weex ，再到后面的小程序，以及 Flutter 等容器環(huán)境，進(jìn)行了多輪的 API 重復(fù)建設(shè)，造成了缺少 API 接口的標(biāo)準(zhǔn)化定義，以及缺少實(shí)現(xiàn)層統(tǒng)一管控的現(xiàn)狀。
如果能夠在 API 的 native 實(shí)現(xiàn)上做到接口統(tǒng)一，再通過各個(gè)容器分別提供接口供業(yè)務(wù)使用，可以更好的做到實(shí)現(xiàn)收口，并在統(tǒng)一實(shí)現(xiàn)層跨容器實(shí)現(xiàn)對系統(tǒng)資源的統(tǒng)一調(diào)度、管控和度量。
? 提升交互能力：U I + 游戲引擎
前文提到過， Flutter 目前最大的價(jià)值在于研發(fā)效率的提升， 這是吸引業(yè)務(wù)團(tuán)隊(duì)?wèi)?yīng)用Flutter技術(shù)的起點(diǎn)；但僅僅依靠研發(fā)提效還遠(yuǎn)遠(yuǎn)不夠，當(dāng)通過各種工程化手段解決好當(dāng)前研發(fā)痛點(diǎn)，提升研發(fā)效率之后，如何說服業(yè)務(wù)繼續(xù)使用Flutter體系進(jìn)行業(yè)務(wù)開發(fā)？Flutter帶來的長遠(yuǎn)價(jià)值在哪里？
個(gè)人認(rèn)為，這個(gè)落腳點(diǎn)應(yīng)該在通過游戲交互能力的泛化，打破 UI 與游戲引擎的邊界，用游戲化的方式創(chuàng)造更有表現(xiàn)力的交互體驗(yàn)，創(chuàng)造新的業(yè)務(wù)玩法和價(jià)值。
大家知道傳統(tǒng)的 UI 和游戲引擎是相互獨(dú)立的兩個(gè)體系，在 H5 應(yīng)用中，往往是通過 DOM 或者上層應(yīng)用框架做 UI，通過建立在 canvas 上的 H5 游戲引擎實(shí)現(xiàn)游戲能力。
如果在游戲應(yīng)用中有 UI 的需求，解決方案一般是自建一套簡單的 UI 體系與事件體系，通過自繪的方式在游戲中疊加 UI ，獨(dú)立游戲引擎亦是如此。
Flutter 從技術(shù)原理上看更像是一個(gè)建立在 Skia 圖形庫上的游戲引擎， 它通過細(xì)粒度的 widgets 設(shè)計(jì)向上構(gòu)建 UI 系統(tǒng)；同樣得益于這樣的細(xì)粒度設(shè)計(jì)，我們也完全可以直接通過 widgets 能力組合出一個(gè)完整的游戲引擎，提供Game，Scene 及 Sprite 動效等 widgets 并擴(kuò)展對應(yīng)的 elements 和 render objects，并與 UI 體系共用一套事件處理機(jī)制、分層與渲染合成機(jī)制。
這樣做就相當(dāng)于打破了原來H5中DOM UI和Canvas游戲的邊界，讓兩個(gè)體系在 widgets 概念下完美融合起來，通過游戲引擎的能力賦能UI實(shí)現(xiàn)更多以前UI體系難以低成本實(shí)現(xiàn)的動效效果（比如一只小盒馬一口吃掉了一個(gè)訂單組件等等）。
我們相信，這個(gè)方向的探索將會進(jìn)一步釋放 Flutter 的技術(shù)潛力，帶來更多的業(yè)務(wù)可玩性與創(chuàng)造性，解放產(chǎn)品和設(shè)計(jì)的想象力，為業(yè)務(wù)創(chuàng)造更多價(jià)值。
? 提升研發(fā)效率：工程解耦與端云一體化
Flutter 工程解耦
前端體系的研發(fā)效率很大程度上來自于基于 URI 的統(tǒng)一路由體系帶來的頁面間解耦性，與頁面內(nèi)基于 Web API 的標(biāo)準(zhǔn)化帶來的內(nèi)聚性。
然而目前的 Flutter 研發(fā)模式，仍需要多個(gè)業(yè)務(wù)團(tuán)隊(duì)工作在同一個(gè)工程下，互相之間存在源碼依賴，未來如果跨業(yè)務(wù)團(tuán)隊(duì)大規(guī)模應(yīng)用Flutter技術(shù)，必將拖慢業(yè)務(wù)的研發(fā)效率。
從工程解耦角度看，目前 AliFlutter 容器通過混合棧與標(biāo)準(zhǔn)路由能力基本實(shí)現(xiàn)了頁面研發(fā)的解耦，未來的容器化建設(shè)通過提供小程序?qū)Φ鹊?API 能力封裝，業(yè)務(wù)對平臺無感知，能夠讓我們有機(jī)會解耦業(yè)務(wù)研發(fā)，實(shí)現(xiàn)與小程序開發(fā)接近的研發(fā)體驗(yàn)和效率。
理想的方案是： 業(yè) 務(wù)可以從業(yè)務(wù)維度創(chuàng)建一個(gè)獨(dú)立的 Dart 工程，只包含業(yè)務(wù)相關(guān)的頁面和邏輯代碼，通過 Flutter 的 Hot UI 開發(fā)頁面，通過IDE提供的基于 Flutter Web 的能力本地預(yù)覽工程并調(diào)試 API 與系統(tǒng)調(diào)用，完成研發(fā)期工作；也可生成預(yù)覽二維碼，使用預(yù)裝有 AliFlutter SDK 環(huán)境的宿主應(yīng)用掃碼預(yù)覽；研發(fā)與構(gòu)建鏈路分離，云端主動拉取業(yè)務(wù)倉庫代碼參與整包構(gòu)建。以此達(dá)到類似小程序研發(fā)方式的前端研發(fā)體驗(yàn)，同時(shí)實(shí)現(xiàn)業(yè)務(wù)間的研發(fā)解耦和并行發(fā)布，提高業(yè)務(wù)的交付效率。
端云一體化
如今 Serverless 概念越來越多的受到業(yè)務(wù)研發(fā)的重視和應(yīng)用，集團(tuán)在新一代的端云一體化研發(fā)模式上的探索這一年多來也做的如火如荼。
結(jié)合輕量級容器環(huán)境、多語言支持能力與統(tǒng)一的 API 服務(wù)端編程，端側(cè)同學(xué)可以很容易的使用客戶端語言如 Java、JS、Swift 甚至 Dart 來開發(fā)服務(wù)端業(yè)務(wù)能力，實(shí)現(xiàn)服務(wù)編排、服務(wù)端 FaaS 業(yè)務(wù)邏輯與 API 自動生成，達(dá)到前后端工程體系歸一，業(yè)務(wù)研發(fā)閉環(huán)的效果。
目前閑魚在 Dart FaaS 云端一體化的探索走在了前面，通過集團(tuán)的容器規(guī)范實(shí)現(xiàn)了Dart function容器，并聯(lián)合服務(wù)端為部分業(yè)務(wù)需要的領(lǐng)域服務(wù)抽象出來 BaaS 層（存儲、消息隊(duì)列等），并封裝了面向前端的 BFF（Backend for Frontend）能力層，使移動端開發(fā)者可以很容易的使用Dart封裝FaaS業(yè)務(wù)邏輯，同時(shí)進(jìn)行移動端和服務(wù)端 FaaS 開發(fā)，大大提高了業(yè)務(wù)研發(fā)效率。
通過將原有的端側(cè)請求接口、組裝數(shù)據(jù)并轉(zhuǎn)換為 ViewModel 的邏輯都后移到了服務(wù)端，經(jīng)過字段映射與頁面編排，移動端可直接獲取 ViewModel 并刷新頁面，通過 BinderAction 雙向交互狀態(tài)數(shù)據(jù)，有效屏蔽了通信細(xì)節(jié)，提高了開發(fā)效率。
云端一體化除了帶來了研發(fā)與協(xié)同效率的提升，同時(shí)也重塑了生產(chǎn)關(guān)系，使端側(cè)業(yè)務(wù)從只關(guān)注端側(cè)體驗(yàn)和邏輯的開發(fā)角色，變成能夠向業(yè)務(wù)整體結(jié)果負(fù)責(zé)；同時(shí)也讓服務(wù)端更專注于領(lǐng)域服務(wù)的沉淀。
Flutter 良好的跨端特性，能夠屏蔽掉端差異化，配合 Flutter 容器化改造，更近一步的簡化了業(yè)務(wù)的全鏈路研發(fā)模式。
未來如何在 FaaS 模式下，沉淀出一套可以服務(wù)集團(tuán)業(yè)務(wù)研發(fā)的通用端側(cè)和服務(wù)端通信調(diào)度框架，讓集團(tuán) Flutter 開發(fā)者和業(yè)務(wù)都能共享到 Serverless 技術(shù)和云端一體化提效的紅利，是需要我們共同去探索和定義的新問題。
? 提升交付效率：Flutter 動態(tài)化
實(shí)現(xiàn)動態(tài)化是交付效率提升的重要方式。
對于電商強(qiáng)運(yùn)營強(qiáng)時(shí)效性特性來說，動態(tài)化幾乎是一個(gè)必備的訴求，但從技術(shù)上看也是一個(gè)非常敏感的需求，是一個(gè)在系統(tǒng)廠商平臺管控下長期博弈的過程。
在我看來，動態(tài)化技術(shù)需要解決的核心問題，是在保證業(yè)務(wù)發(fā)布確定性的前提下，尋求技術(shù)性能、業(yè)務(wù)迭代效率與靈活性三者之間合理的平衡點(diǎn)。
下面講講我們在 Flutter 動態(tài)化上的兩個(gè)思路與嘗試： Flutter 模板化方案與 Web on Flutter。
Flutter 模板化方案
動態(tài)模板化方案是集團(tuán)內(nèi)較為成熟的一套基于Native技術(shù)的模板化方案，專注于 UI 模板渲染，沒有執(zhí)行邏輯和運(yùn)行時(shí)環(huán)境，目前被廣泛應(yīng)用于電商系的一些核心業(yè)務(wù)場景。
同時(shí)該方案提供了配套的組件平臺，支持在線模板編輯、預(yù)覽、測試及發(fā)布整套流程，結(jié)合發(fā)布平臺形成了一整套完善的業(yè)務(wù)開發(fā)生態(tài)閉環(huán)。
在 Flutter 體系下，目前閑魚團(tuán)隊(duì)依據(jù)標(biāo)準(zhǔn)模板協(xié)議在 Flutter 側(cè)實(shí)現(xiàn)了一套 Dart 版 SDK ， 通過模板下發(fā)實(shí)現(xiàn)了Flutter端的輕量級動態(tài)化組件編排能力；并通過一年多的迭代逐步解決了渲染性能與渲染一致性問題，較好的賦能了Flutter業(yè)務(wù)的組件動態(tài)化能力。
那么，未來 Flutter 與動態(tài)模板化方案有沒有更好的結(jié)合點(diǎn)？
答案是肯定的。從 DSL 角度看，目前模板的寫法基本上來自 Android XML ，對組件開發(fā)者尤其是非 Android 開發(fā)者不夠友好，具備一定的學(xué)習(xí)成本；而 Flutter 的結(jié)構(gòu)與屬性均可通過 widgets 表達(dá)，可以極為靈活且平臺中立的用聲明式代碼構(gòu)建UI并綁定數(shù)據(jù)，易于開發(fā)者編寫組件并通過 Flutter 框架獨(dú)立調(diào)試與測試；在移動端運(yùn)行時(shí)，可以按需按場景翻譯成 native 組件或 Flutter 組件。
未來我們也將持續(xù)在這個(gè)方向上做探索。
Web on Flutter
相比貼近 Native 研發(fā)模式的模板組件化渲染方案，Web on Flutter 希望通過類 H5 的 DSL + JS ，借助Flutter的渲染能力，實(shí)現(xiàn)貼前端技術(shù)棧的動態(tài)化能力。
目前基于 Web 渲染的小程序方案存在啟動耗時(shí)高，渲染性能距原生 UI 有較大差距等性能問題，這些問題很大程度上都源自于瀏覽器引擎的設(shè)計(jì)歷史包袱（渲染管線復(fù)雜、CSS multi-pass layout及l(fā)egacy實(shí)現(xiàn)等），以及JS到Native通信效率低（bridge）。
Flutter 的設(shè)計(jì)思路源自瀏覽器，一方面直接吸收了前端框架近年來的演進(jìn)成就，原生支持了聲明式-響應(yīng)式編程范式，提高了移動端的研發(fā)效率；另一方面，F(xiàn)lutter 緊貼 native 開發(fā)模式有限定義了 UI 結(jié)構(gòu)、布局與渲染的必要元素，在滿足native UI開發(fā)模式的前提下簡化了能力定義與布局算法（single-pass layout與repaint boundary等概念），很大程度上簡化了渲染管線的復(fù)雜度，直接為Flutter帶來了接近原生的性能體驗(yàn)。
同時(shí)，F(xiàn)lutter 的 widgets 設(shè)計(jì)巧妙，結(jié)構(gòu)布局屬性等基礎(chǔ)元素均使用 widgets 表達(dá)，且可通過基礎(chǔ) widgets 的組合來構(gòu)成復(fù)雜組件，這種細(xì)粒度+組合能力設(shè)計(jì)讓 Flutter 有極強(qiáng)的表現(xiàn)力，并具備向上對接各種研發(fā)模式的可能性。
因此，通過 widgets 組合小程序 DSL，支持小程序 CSS 有限集，實(shí)現(xiàn)渲染層替換瀏覽器引擎，并對接JS引擎支持JS執(zhí)行能力，是一個(gè)將Flutter應(yīng)用于小程序生態(tài)的合理探索方向。
相比把開發(fā)者慣壞了的瀏覽器，這種方案在 CSS 的能力支持上必然是受限的，無法滿足所有 CSS3 標(biāo)準(zhǔn)的實(shí)現(xiàn)，更多通過緊貼 Flutter widgets 的現(xiàn)有能力以及必要的 widgets 擴(kuò)展，在不破壞 single-pass layout 的前提下組合出 CSS 能力。
但從 Flutter 原生開發(fā)的角度看，只要 Flutter 現(xiàn)有的原生能力能夠滿足業(yè)務(wù)需求，那么受限的 CSS 實(shí)現(xiàn)也一樣可以提供和 Flutter 對等的能力解決業(yè)務(wù)問題。同時(shí)，通過受限的 CSS 可以換來與 Flutter 相當(dāng)?shù)母咝阅?，與基于 Web 的實(shí)現(xiàn)相比，在性能上帶來了質(zhì)變。
我們在18年底通過一個(gè)內(nèi)部項(xiàng)目實(shí)現(xiàn)了這個(gè)思路的原型，通過使用 C++ 重寫 Flutter 的 widgets、rendering、painting 及事件管理等 Dart framework 中的中低層能力，并在 widget 上用 C++ 實(shí)現(xiàn)了 CSSOM + DSL -> Widgets 的響應(yīng)式框架，直接從 C++ 層提供 render 實(shí)現(xiàn)，將傳統(tǒng)由 JS 承擔(dān)的模板展開、tree-diff計(jì)算與渲染工作交給C++層，通過Flutter提供的Widgets tree到RenderObjects tree的diff能力實(shí)現(xiàn)，顯著提高了性能。
從實(shí)現(xiàn)的簡單的demo看，相對小程序的web渲染性能有了大幅的提升。這種方案的問題在于和Google代碼庫分裂后的長期維護(hù)性。 “Flutter和Web生態(tài)如何對接” 這篇文章對集團(tuán)內(nèi)在這個(gè)方向上嘗試的幾種思路做了較為全面的對比，未來我們也將繼續(xù)在這個(gè)方向上做深入和持續(xù)的探索。
總結(jié)與展望
Flutter 體系化建設(shè)目前在淘系剛剛起步，仍然有大量工作需要去做，我們在基礎(chǔ)設(shè)施、工程化以及通過Flutter定義和收斂業(yè)務(wù)域研發(fā)模式上做的許多建設(shè)性的事情，正朝著把Flutter打造為統(tǒng)一移動應(yīng)用基礎(chǔ)研發(fā)框架，助力業(yè)務(wù)回歸移動端研發(fā)模式這個(gè)大目標(biāo)一點(diǎn)點(diǎn)邁進(jìn)。
在移動技術(shù)小組啟動 AliFlutter 項(xiàng)目之前，閑魚技術(shù)部已經(jīng)在 Flutter 技術(shù)建設(shè)上做了大量探索和投入。
一方面通過 Flutter 技術(shù)賦能業(yè)務(wù)提效升級，拿到了很好的業(yè)務(wù)成績；
另一方面沉淀Flutter的技術(shù)與業(yè)務(wù)解決方案，并通過開源反哺社區(qū)，在海內(nèi)外Flutter技術(shù)社區(qū)中建立了顯著的技術(shù)影響力與領(lǐng)導(dǎo)力，也涌現(xiàn)出一眾Flutter技術(shù)專家。
接下來AliFlutter的重點(diǎn)任務(wù)，就是要和閑魚、財(cái)富等先驅(qū)應(yīng)用者以及盒馬、釘釘、飛豬、優(yōu)酷、餓了么、CBU等Flutter的實(shí)踐者一起，在集團(tuán)層面把Flutter的場子建起來，把集團(tuán)Flutter生態(tài)拉起來，讓技術(shù)和經(jīng)驗(yàn)?zāi)軌蚬餐恋砗头窒恚黄饋戆袴lutter技術(shù)體系在阿里的應(yīng)用生態(tài)內(nèi)做大做強(qiáng)，真正成為集團(tuán)業(yè)務(wù)的核心研發(fā)模式，并讓每個(gè)參與者都能從中受益。
我們一直堅(jiān)信 Flutter 技術(shù)的先進(jìn)性和應(yīng)用前景，未來我們將繼續(xù)立足淘系服務(wù)集團(tuán)業(yè)務(wù)，和集團(tuán)開發(fā)者攜手前行，在 Flutter 這個(gè)技術(shù)方向上堅(jiān)定的走下去。
文章名稱：阿里集團(tuán)內(nèi)如何進(jìn)行Flutter體系化建設(shè)？
鏈接URL：http://m.fisionsoft.com.cn/article/ccsigig.html
