前言

跨端技術(shù)一直是移動(dòng)端開發(fā)領(lǐng)域的熱門話題，F(xiàn)lutter 作為一種領(lǐng)先的移動(dòng)跨端技術(shù)之一，憑借其快速的渲染引擎、豐富的UI組件庫(kù)和強(qiáng)大的開發(fā)工具，成為了開發(fā)人員的首選之一。

從 Flutter 誕生之初，我們就一直關(guān)注著它的發(fā)展，F(xiàn)lutter 早期版本變更較為頻繁，并且經(jīng)常伴隨著 Breaking Change，另外可用的三方插件較少且不穩(wěn)定。直到2019年，F(xiàn)lutter 的熱度暴漲，國(guó)內(nèi)不少團(tuán)隊(duì)陸續(xù)把 Flutter 引入到了生產(chǎn)環(huán)境使用，社區(qū)也涌現(xiàn)出不少優(yōu)秀的開源項(xiàng)目，我們也決定在這個(gè)時(shí)候做一些技術(shù)上的嘗試。

經(jīng)過(guò)這幾年在 Flutter 技術(shù)上的不斷學(xué)習(xí)、探索和積累，F(xiàn)lutter 已經(jīng)成為了客戶端技術(shù)體系中的重要組成部分。

回顧整個(gè)過(guò)程，我們大致經(jīng)歷了這么幾個(gè)階段：可行性驗(yàn)證、基建一期建設(shè)、小范圍試驗(yàn)、基建二期建設(shè)、大范圍推廣、前端生態(tài)的探索，下文將分別對(duì)每個(gè)階段展開進(jìn)行介紹。

可行性驗(yàn)證

其實(shí)在這之前我們已經(jīng)做過(guò)了一些調(diào)研，但許多結(jié)論都是來(lái)源于網(wǎng)上的一些文章或者其它團(tuán)隊(duì)的實(shí)踐，這些結(jié)論是否靠譜是否真實(shí)還有待商榷，另外，網(wǎng)上的文章大都千篇一律，要么使勁吹捧，要么使勁貶低，要得出相對(duì)客觀的結(jié)論還是得需要我們自己通過(guò)實(shí)踐才能得出。

目標(biāo)

我們確定了以下幾個(gè)維度，用來(lái)評(píng)估 Flutter 是否值得我們進(jìn)一步投入：

• 開發(fā)效率
• UI一致性
• 性能體驗(yàn)
• 學(xué)習(xí)成本
• 發(fā)展趨勢(shì)

由于前期對(duì) Flutter 的熟練度不高，基礎(chǔ)設(shè)施也還沒有搭建起來(lái)，所以在開發(fā)效率上，我們期望的 Flutter 的開發(fā)耗時(shí)能保持在原生開發(fā)耗時(shí)的 1.5 倍以內(nèi)，不然雖然實(shí)現(xiàn)了跨端，但是需求的開發(fā)周期反而被拉長(zhǎng)了，這樣得不償失。在UI一致性上，我們期望同一份代碼在兩端的表現(xiàn)要基本達(dá)到一致，不需要額外的適配成本。在性能方面，盡量保證崩潰、卡頓、內(nèi)存、幀率這些指標(biāo)在可控范圍內(nèi)。

方案

我們希望用較小的代價(jià)完成上述維度的評(píng)估，所以在試驗(yàn)期間的架構(gòu)及基礎(chǔ)設(shè)施方面我們做的比較簡(jiǎn)單。

測(cè)試目標(biāo)

當(dāng)時(shí)我們正在做一個(gè)叫切克的 App，用戶量級(jí)比較小，工程架構(gòu)也相對(duì)簡(jiǎn)單一些，正好可以用來(lái)做一些技術(shù)方面的探索和驗(yàn)證。

我們選擇的是切克的商品詳情頁(yè)，用 Flutter 技術(shù)實(shí)現(xiàn)了一個(gè)一模一樣的商詳，按1:1的流量分配給 Native 和 Flutter。

項(xiàng)目架構(gòu)

由于我們的工程不是一個(gè)全新的項(xiàng)目，所以采用的是 Native 與 Flutter 混合開發(fā)的方式，Native 主工程只依賴 Flutter 產(chǎn)物即可，同時(shí)也盡量避免對(duì)原有工程的影響。

關(guān)于混合頁(yè)面棧的問(wèn)題，我們沒有額外處理，因?yàn)闀簳r(shí)只測(cè)試一個(gè)頁(yè)面，不會(huì)涉及到多頁(yè)面混合棧的問(wèn)題，所以暫時(shí)先忽略。

構(gòu)建流程

為了降低驗(yàn)證成本，我們沒有對(duì)接現(xiàn)有的 Native 的持續(xù)集成流程，而是直接在本地構(gòu)建 Flutter 產(chǎn)物，然后上傳到遠(yuǎn)程倉(cāng)庫(kù)。

結(jié)論

經(jīng)過(guò)一段時(shí)間的線上驗(yàn)證，我對(duì) Flutter 技術(shù)基本有了一個(gè)比較全面的了解：

在開發(fā)效率上由于基礎(chǔ)庫(kù)和基建的缺失，在處理 Flutter 業(yè)務(wù)跟 Native 業(yè)務(wù)的交互時(shí)需要更多的適配成本，包括像頁(yè)面跳轉(zhuǎn)、埋點(diǎn)上報(bào)、接口請(qǐng)求、圖片加載等也需要額外的處理，但我們?cè)u(píng)估隨著后續(xù)基建的不斷完善，這部分的效率是可以逐步得到改善的；而在涉及UI開發(fā)方面，得益于熱重載等技術(shù)，F(xiàn)lutter 的開發(fā)效率是要優(yōu)于原生開發(fā)的。整體評(píng)估下來(lái)，在開發(fā)效率方面 Flutter 是符合我們的預(yù)期的。

在UI一致性上，除了在狀態(tài)欄控制和文本在某些情況下需要特殊適配下外，其它控件在兩端的表現(xiàn)基本一致。

在性能表現(xiàn)上，F(xiàn)lutter 會(huì)額外引入一些崩潰，內(nèi)存占用也有所上漲，但還在可接受范圍內(nèi)。

Flutter 的學(xué)習(xí)成本相對(duì)還是比較高，畢竟需要單獨(dú)學(xué)習(xí)一門語(yǔ)言，另外 Flutter 的渲染原理也跟原生有很多差異，需要轉(zhuǎn)變思維才能更快的適應(yīng)，此外 Flutter 還提供了眾多的 Widget 組件，也需要較長(zhǎng)時(shí)間學(xué)習(xí)。

在發(fā)展趨勢(shì)上，F(xiàn)lutter 無(wú)疑是當(dāng)時(shí)增長(zhǎng)最快的跨端技術(shù)之一，社區(qū)的活躍程度以及官方的投入都非常高，國(guó)內(nèi)不少團(tuán)隊(duì)也都在積極推進(jìn) Flutter 技術(shù)的發(fā)展，F(xiàn)lutter 正處在一個(gè)快速的上升期。

整體來(lái)說(shuō)，F(xiàn)lutter 是滿足我們團(tuán)隊(duì)對(duì)跨平臺(tái)技術(shù)的需求的，我們計(jì)劃在接下來(lái)的一段時(shí)間投入更多資源，把 Flutter 的基礎(chǔ)設(shè)施逐漸建立起來(lái)。

基建一期建設(shè)

基建一期內(nèi)容主要包括以下幾個(gè)方面：

• 工程架構(gòu)
• 開發(fā)框架
• 腳本工具
• 自動(dòng)化構(gòu)建

在基建一期完成后，我們的目標(biāo)是要達(dá)到：

• 基礎(chǔ)能力足夠支撐普通業(yè)務(wù)開發(fā)
• 開發(fā)效率接近原生開發(fā)
• 開發(fā)過(guò)程要基本順暢

工程架構(gòu)

工程架構(gòu)指的是原生工程與 Flutter 工程之間的關(guān)系，以及 Flutter 工程與 Flutter 工程之間的關(guān)系。

原生工程與Flutter工程的關(guān)系

我們知道，使用 Flutter 開發(fā)通常有兩種情況，一種是直接使用 Flutter 開發(fā)一個(gè)新的App，屬于純 Flutter 開發(fā)；一種是在已有的 Native 工程中引入，屬于混合開發(fā)。我們當(dāng)然屬于后者。

而混合開發(fā)又可分為兩種：源碼集成和產(chǎn)物集成。源碼集成需要改變?cè)こ痰捻?xiàng)目結(jié)構(gòu)，并且需要 Flutter 開發(fā)環(huán)境才能編譯，而產(chǎn)物集成則不需要改動(dòng)原工程的項(xiàng)目結(jié)構(gòu)，只需把 Flutter 的構(gòu)建產(chǎn)物當(dāng)作普通的依賴庫(kù)引入即可，原有 Native 工程和 Flutter 工程從物理上完全獨(dú)立。顯而易見的我們選擇產(chǎn)物集成的方式，引入 Flutter對(duì)于原工程以及非 Flutter 開發(fā)人員來(lái)說(shuō)，基本上是毫無(wú)感知的。

所以原生工程與 Flutter 工程之間的關(guān)系如下圖所示：

原生工程與Flutter工程之間的關(guān)系

Flutter工程之間的關(guān)系

根據(jù)已有的客戶端基建的開發(fā)經(jīng)驗(yàn)，我們將所有 Flutter 工程分為了四層：

• 殼工程
• 業(yè)務(wù)層
• 公共層
• 容器層

容器層負(fù)責(zé)提供 Flutter 的基礎(chǔ)運(yùn)行環(huán)境，包括 Flutter 引擎管理、頁(yè)面棧管理、網(wǎng)絡(luò)框架、KV存儲(chǔ)、數(shù)據(jù)庫(kù)訪問(wèn)、埋點(diǎn)框架、Native 與 Flutter 通信通道和其它基礎(chǔ)功能。

公共層包含一些通用的開源庫(kù)、自定義UI組件、部分通用業(yè)務(wù)等。

業(yè)務(wù)層包含用戶信息、商品、發(fā)布等業(yè)務(wù)組件。

殼工程負(fù)責(zé)集成各業(yè)務(wù)組件，最終構(gòu)建出產(chǎn)物集成到 Native 主工程。

其中業(yè)務(wù)層、公共層、容器層都是由若干個(gè)獨(dú)立的工程所組成，整體結(jié)構(gòu)如下：

Flutter分層架構(gòu)

開發(fā)框架

開發(fā)框架是為了提高開發(fā)效率、規(guī)范代碼結(jié)構(gòu)、減少維護(hù)成本等考慮而設(shè)計(jì)的一套軟件框架，包括：基礎(chǔ)能力、狀態(tài)管理、頁(yè)面棧管理等。

基礎(chǔ)能力

開發(fā)框架需要提供各種必要的能力，比如：頁(yè)面跳轉(zhuǎn)、埋點(diǎn)、網(wǎng)絡(luò)請(qǐng)求、圖片加載、數(shù)據(jù)存儲(chǔ)等，為了最大化減少研發(fā)成本，我們?cè)诘讓佣x了一套通用的數(shù)據(jù)交互協(xié)議，直接復(fù)用了現(xiàn)有的 Native 的各項(xiàng)能力，也使得 Native 的各種狀態(tài)與 Flutter 側(cè)能夠保持統(tǒng)一。

狀態(tài)管理

相信了解 Flutter 的同學(xué)一定知道狀態(tài)管理，這也是跟 Native 開發(fā)區(qū)別較大的地方。在開發(fā)較為復(fù)雜的頁(yè)面時(shí)，狀態(tài)維護(hù)是非常繁瑣的，在不引入狀態(tài)管理框架的情況下，開發(fā)效率會(huì)受很大影響，后期的維護(hù)成本以及業(yè)務(wù)交接都是很大的問(wèn)題。

另外，在開發(fā)框架設(shè)計(jì)之初，我們就期望從框架上能夠在一定程度上限定代碼結(jié)構(gòu)、模塊之間的交互方式、狀態(tài)更新方式等，我們期望的是不同的人寫出來(lái)的代碼在邏輯、結(jié)構(gòu)和風(fēng)格上都能保持比較統(tǒng)一，即在提高開發(fā)效率的同時(shí)，也能保證項(xiàng)目后續(xù)的可維護(hù)性和擴(kuò)展性，減少不同業(yè)務(wù)間的交接成本。

基于上述這些需求，在我們對(duì)比了多個(gè)開源項(xiàng)目后，F(xiàn)ishRedux 的整體使用感受正好符合我們的要求。

如下圖，兩個(gè)頁(yè)面的代碼結(jié)構(gòu)基本一致：

收藏詳情和個(gè)人主頁(yè)

頁(yè)面棧管理

在早期版本，F(xiàn)lutter 引擎的實(shí)例占用內(nèi)存較高，為了減少內(nèi)存消耗，大家普遍采用單實(shí)例的模式，而在 Native 和 Flutter 混合開發(fā)的場(chǎng)景下就會(huì)存在一個(gè)問(wèn)題，就是 Native 有自己的頁(yè)面棧，而 Flutter 也維護(hù)著一套自己的頁(yè)面棧，如果 Native 頁(yè)面與 Flutter 頁(yè)面穿插著打開，在沒有特殊處理的情況下，頁(yè)面棧會(huì)發(fā)生錯(cuò)亂。在調(diào)研了業(yè)內(nèi)的各種開源方案后，我們選擇引入 FlutterBoost 用來(lái)管理頁(yè)面混合棧。

腳本工具

為了方便開發(fā)同學(xué)搭建 Flutter 的開發(fā)環(huán)境，同時(shí)能夠管理使用的 Flutter 版本，我們開發(fā)了 zflutter 命令行工具，包含以下主要功能：

• Flutter開發(fā)環(huán)境安裝
• Flutter版本管理
• 創(chuàng)建模版工程（主工程、組件工程）
• 創(chuàng)建模版頁(yè)面（常規(guī)頁(yè)面、列表頁(yè)、瀑布流頁(yè)面）
• 創(chuàng)建頁(yè)面模塊
• 組件工程發(fā)布
• 構(gòu)建Flutter產(chǎn)物
• 腳本自更新

如圖：

zflutter

自動(dòng)化構(gòu)建

客戶端使用的是自研的 Beetle 平臺(tái)（集工程管理、分支管理、編譯、發(fā)布于一體），短時(shí)間內(nèi)要支持上 Flutter 不太現(xiàn)實(shí)，基于此，我們先臨時(shí)自己搭臺(tái)服務(wù)器，通過(guò) gitlab 的 webhook 功能結(jié)合 zflutter 工具簡(jiǎn)單實(shí)現(xiàn)了一套自動(dòng)化構(gòu)建的服務(wù)，待 Beetle 支持 Flutter 組件化開發(fā)功能后，再將工作流切回到 Beetle 平臺(tái)。

小范圍試驗(yàn)

在完成基建一期的開發(fā)工作后，我們決定通過(guò)開發(fā)幾個(gè)實(shí)際業(yè)務(wù)來(lái)試驗(yàn)?zāi)壳暗幕A(chǔ)設(shè)施是否達(dá)到既定目標(biāo)。

我們以不影響主流程、能覆蓋常見UI功能、并且能跟 Native 頁(yè)面做AB測(cè)試（主要是方便在出問(wèn)題時(shí)能夠切換到 Native 版本）為條件挑選了個(gè)人資料頁(yè)和留言列表頁(yè)進(jìn)行了 Flutter 化改造，如下圖所示：

個(gè)人資料頁(yè)/留言列表頁(yè)

這兩個(gè)頁(yè)面涵蓋了網(wǎng)絡(luò)請(qǐng)求、圖片加載、彈窗、列表、下拉刷新、上拉加載更多、左滑刪除、埋點(diǎn)上報(bào)、頁(yè)面跳轉(zhuǎn)等常見功能，足以覆蓋日常開發(fā)所需的基礎(chǔ)能力。

經(jīng)過(guò)完整的開發(fā)流程以及一段時(shí)間的線上觀察，我們得出如下結(jié)論：

基礎(chǔ)能力

目前已具備的基礎(chǔ)能力已經(jīng)足夠支撐普通業(yè)務(wù)開發(fā)（開發(fā)過(guò)程中補(bǔ)足了一些缺失的能力）。

工作流

整個(gè)開發(fā)過(guò)程在工程依賴管理和分支管理方面的支持還比較缺失，比較依賴人工處理。

開發(fā)效率

我們?cè)陂_發(fā)前根據(jù)頁(yè)面功能同時(shí)做了純 Native 開發(fā)排期和 Flutter 開發(fā)排期，按單人日的成本來(lái)對(duì)比的話，F(xiàn)lutter 實(shí)際開發(fā)耗時(shí)跟 Native 排期耗時(shí)比為 1.25:2，Native 是按照 Android+iOS 兩端各一人算的，也就是1.25人/日比2人/日，如果后續(xù)對(duì) Flutter 技術(shù)熟悉度提升后相信效率還可以進(jìn)一步提升。

性能體驗(yàn)

線上兩個(gè) Flutter 頁(yè)面的體驗(yàn)效果跟 Native 對(duì)比基本感覺不到差別，但是首次進(jìn)入 Flutter 頁(yè)面時(shí)會(huì)有短暫的白屏等待時(shí)間，這個(gè)是由于 Flutter 環(huán)境初始化導(dǎo)致的延遲，后續(xù)可以想辦法優(yōu)化。

包體積

在引入 Flutter 之后，轉(zhuǎn)轉(zhuǎn)的安裝包體積在兩端都分別有所增加：

• Android增加6.1M
• iOS增加14M

試驗(yàn)結(jié)果基本符合預(yù)期，包體積的增量也在我們的可接受范圍內(nèi)，接下來(lái)將進(jìn)行基建二期的建設(shè)，補(bǔ)足目前缺失的能力。

基建二期建設(shè)

基建二期的內(nèi)容主要包含以下工作：

• 配合工程效率組完成 Beetle 對(duì) Flutter 項(xiàng)目的支持
• 組織客戶端內(nèi)部進(jìn)行 Flutter 技術(shù)培訓(xùn)

Beetle支持Flutter

為了能讓大家更清晰的了解 Beetle 的工程管理機(jī)制，這里先簡(jiǎn)單介紹下客戶端的工程類型：

• Native主工程（又分為 Android 和 iOS）
• Native組件工程（又分為 Android 和 iOS）
• Flutter主工程
• Flutter組件工程（即 Flutter 插件工程）

舉個(gè)例子，當(dāng)有一個(gè)新版本需要開發(fā)時(shí)，先從 Native 主工程創(chuàng)建一個(gè)版本同時(shí)創(chuàng)建一個(gè) Release 分支，即版本分支，然后從版本分支根據(jù)具體需求創(chuàng)建對(duì)應(yīng) Native 組件的版本分支，F(xiàn)lutter 主工程此時(shí)可看作是一個(gè) Native 組件，比如此時(shí)創(chuàng)建了一個(gè) Flutter 主工程的版本分支后，可以進(jìn)入 Flutter 主工程再根據(jù)需要?jiǎng)?chuàng)建對(duì)應(yīng)的 Flutter 組件工程的版本分支。

Beetle 目前已支持 Flutter 工程管理、分支管理、組件依賴管理以及組件的發(fā)布、Flutter 產(chǎn)物的構(gòu)建等，Beetle 的作用貫穿從開發(fā)到上線的整個(gè)工作流。

Flutter技術(shù)培訓(xùn)

為了讓大家更快的熟悉 Flutter 開發(fā)，我們?cè)诳蛻舳藘?nèi)部組織了5次 Flutter 快速入門的系列分享：

Flutter快速入門系列

同時(shí)也逐步完善內(nèi)部文檔的建設(shè)，包括：FlutterSdk 源碼維護(hù)策略、Flutter 入門指南、Flutter 混合開發(fā)方案、Flutter 與 Native 通信方案、Flutter 開發(fā)環(huán)境配置、Flutter 組件化工程結(jié)構(gòu)、Flutter 開發(fā)與調(diào)試、Flutter 開發(fā)工作流、ZFlutter 工具使用介紹、Flutter 開發(fā)之 Beetle 使用指南等，涵蓋了從環(huán)境搭建、開發(fā)調(diào)試到構(gòu)建發(fā)布的整個(gè)過(guò)程。

大范圍推廣

在完成基建二期的建設(shè)后，整體基礎(chǔ)設(shè)施已經(jīng)能夠支撐我們常見的業(yè)務(wù)，開發(fā)工作流也基本順暢，于是我們開始了在內(nèi)部大范圍推廣計(jì)劃。

我們先后改造和新開發(fā)了個(gè)人主頁(yè)、我發(fā)布的頁(yè)面、微商詳、奇趣數(shù)碼頁(yè)等業(yè)務(wù)，基本涵蓋了常見的各種類型的頁(yè)面和功能，整體開發(fā)效率與原生單端開發(fā)效率持平，但是在特別復(fù)雜的頁(yè)面的性能表現(xiàn)上，F(xiàn)lutter 的表現(xiàn)相對(duì)要差一些。

部分頁(yè)面如下圖所示：

個(gè)人主頁(yè)

探索前端生態(tài)

在跨端技術(shù)領(lǐng)域我們知道 Web 技術(shù)是天然支持的，如果能把前端生態(tài)引入到 Flutter 中，那么對(duì)客戶端來(lái)說(shuō)，在業(yè)務(wù)的支持度上會(huì)更上一個(gè)臺(tái)階，Web 的體驗(yàn)得到提升的同時(shí)客戶端也具備了動(dòng)態(tài)化，基于此背景我們開始探索 Flutter 在 Web 上的可能性。

技術(shù)調(diào)研

當(dāng)時(shí)可選的開源方案有：Kraken、MXFlutter、Flutter For Web。

Kraken

Kraken 是一款基于 W3C 標(biāo)準(zhǔn)的高性能渲染引擎。Kraken 底層基于 Flutter 進(jìn)行渲染，通過(guò)其自繪渲染的特性，保證多端一致性。上層基于 W3C 標(biāo)準(zhǔn)實(shí)現(xiàn)，擁有非常龐大的前端開發(fā)者生態(tài)。

Kraken 的最上層是一個(gè)基于 W3C 標(biāo)準(zhǔn)而構(gòu)建的 DOM API，在下層是所依賴的 JS 引擎，通過(guò) C++ 構(gòu)建一個(gè) Bridge 與 Dart 通信。然后這個(gè) C++ Bridge 把 JS 所調(diào)用的一些信息，轉(zhuǎn)發(fā)到 Dart 層。Dart 層通過(guò)接收這些信息，會(huì)去調(diào)用 Flutter 所提供的一些渲染能力來(lái)進(jìn)行渲染。

Kraken 是不依賴 Flutter Widget，而是依賴 Flutter Widget 的底層渲染數(shù)據(jù)結(jié)構(gòu) —— RenderObject。Kraken 實(shí)現(xiàn)了很多 CSS 相關(guān)的能力和一些自定義的 RenderObject，直接將生成的 RenderObject 掛載在 Flutter RenderView 上來(lái)進(jìn)行渲染，通過(guò)這樣的方式能夠做到非常高效的渲染性能。

MXFlutter

MXFlutter 是一套使用 TypeScript/JavaScript 來(lái)開發(fā) Flutter 應(yīng)用的框架。

MXFlutter 把 Flutter 的渲染邏輯中的三棵樹（即：WidgetTree、Element、RenderObject ）中的第一棵（即：WidgetTree），放到 JavaScript 中生成。用 JavaScript 完整實(shí)現(xiàn)了 Flutter 控件層封裝，實(shí)現(xiàn)了輕量的響應(yīng)式 UI 框架，支撐JS WidgetTree 的 build邏輯，build 過(guò)程生成的UI描述， 通過(guò)Flutter 層的 UI 引擎轉(zhuǎn)換成真正的 Flutter 控件顯示出來(lái)。

Flutter For Web

Flutter 在 Web 平臺(tái)上以瀏覽器的標(biāo)準(zhǔn) API 重新實(shí)現(xiàn)了引擎。目前有兩種在 Web 上呈現(xiàn)內(nèi)容的選項(xiàng)：HTML 和 WebGL。

• 在 HTML 模式下，F(xiàn)lutter 使用 HTML、CSS、Canvas 和 SVG 進(jìn)行渲染。
• 在 WebGL 模式下，F(xiàn)lutter 使用了一個(gè)編譯為 WebAssembly 的 Skia 版本，名為 CanvasKit。

HTML 模式提供了最佳的代碼大小，CanvasKit 則提供了瀏覽器圖形堆棧渲染的最快途徑，并為原生平臺(tái)的內(nèi)容提供了更高的圖形保真度。

結(jié)論

我們對(duì)以上方案從接入成本、渲染性能、包體積、開發(fā)生態(tài)、學(xué)習(xí)成本等多維度進(jìn)行了對(duì)比：

• 接入成本：Kraken ≈ MXFlutter ≈ Flutter For Web
• 渲染性能：Kraken > MXFlutter > Flutter For Web
• 包體積增量：Flutter For Web < Kraken < MXFlutter
• 開發(fā)生態(tài)：Kraken ≈ MXFlutter > Flutter For Web
• 學(xué)習(xí)成本：Flutter For Web < Kraken ≈ MXFlutter

最終選擇了 Kraken 作為我們的首選方案。

上線驗(yàn)證

為了使 Kraken 順利接入轉(zhuǎn)轉(zhuǎn)App，我們做了以下幾個(gè)方面的工作：

• 升級(jí) FlutterSdk 到最新版，滿足接入 Kraken 的基礎(chǔ)條件
• 統(tǒng)一客戶端容器接口，使得 Kraken 容器能夠完美繼承 Web 容器的能力
• 自己維護(hù) Kraken 源碼，及時(shí)修復(fù)官方來(lái)不及修復(fù)的問(wèn)題，方便增加轉(zhuǎn)轉(zhuǎn)特有的擴(kuò)展能力
• 制定 Kraken 容器與 Web 容器的降級(jí)機(jī)制
• 兼容 HTML 加載，保持跟 Web 容器一致的加載方式
• 添加監(jiān)控埋點(diǎn)，量化指標(biāo)，指導(dǎo)后續(xù)優(yōu)化方向
• 選擇一個(gè)簡(jiǎn)單 Web 頁(yè)并協(xié)助前端同學(xué)適配

上線后，我們對(duì)頁(yè)面的各項(xiàng)指標(biāo)進(jìn)行了對(duì)比，使用 Kraken 容器加載比使用 WebView 加載，在首屏加載耗時(shí)的指標(biāo)上平均增加了281毫秒，原因?yàn)椋寒?dāng)前版本的 Kraken 容器不支持直接加載 HTML，且只能加載單個(gè) JsBundle，導(dǎo)致加載效率比 WebView 差。

通過(guò)跟前端同學(xué)溝通，從開發(fā)效率上來(lái)看，Kraken 工程的開發(fā)周期會(huì)比實(shí)現(xiàn)同樣需求的普通 Web 工程增加1.5到2倍的時(shí)間，主要原因是受到 CSS 樣式、Api 差異，無(wú)法使用現(xiàn)有UI組件，另外 Kraken 的調(diào)試工具目前還不夠完善，使用瀏覽器調(diào)試后還須在客戶端容器中調(diào)試，整體下來(lái)導(dǎo)致開發(fā) Kraken 工程會(huì)比開發(fā)普通Web工程耗費(fèi)更多時(shí)間。

再次驗(yàn)證

由于之前選擇的 Web 頁(yè)面太過(guò)簡(jiǎn)單，不具備代表性，所以我們重新選定了“附近的人”頁(yè)面做為改造目標(biāo)，再次驗(yàn)證 Kraken 在實(shí)際開發(fā)過(guò)程中的效率及性能體驗(yàn)。頁(yè)面如圖所示：

附近的人

最終因?yàn)椴糠謫?wèn)題得不到解決，并且整體性能較差，導(dǎo)致頁(yè)面沒能成功上線。

存在的問(wèn)題包括但不限于下面列舉的一些：

• 表現(xiàn)不一致問(wèn)題

CSS 定位、布局表現(xiàn)與瀏覽器表現(xiàn)不一致

部分 API 表現(xiàn)與瀏覽器不一致(getBoundingClientRect等)

iOS，Android系統(tǒng)表現(xiàn)不一致

• 重大 Bug

頁(yè)面初始化渲染完成，動(dòng)態(tài)修改元素樣式，DOM不重新渲染

滑動(dòng)監(jiān)聽計(jì)算導(dǎo)致 APP 崩潰

• 調(diào)試成本高

不支持 vue-router，單項(xiàng)目單路由

不支持熱更新，npm run build 預(yù)覽

不支持 sourceMap，無(wú)法定位源代碼

真機(jī)調(diào)試只支持 element 和 network；dom 和 element 無(wú)法互相選中；無(wú)法動(dòng)態(tài)修改 dom 結(jié)構(gòu)，無(wú)法直接修改樣式.......

頁(yè)面白屏，假死

• 安全性問(wèn)題

無(wú)瀏覽器中的“同源策略”限制

• 兼容性

npm 包不兼容等

通過(guò)這一系列的探索和嘗試，我們了解到了 Kraken 目前還存在許多不足，如果繼續(xù)應(yīng)用會(huì)帶來(lái)高額的開發(fā)調(diào)試以及維護(hù)成本，所以暫時(shí)停止了在 Kraken 方向上的投入，但我們?nèi)匀辉谶@個(gè)方向上保持著關(guān)注。

結(jié)尾

目前轉(zhuǎn)轉(zhuǎn)在Flutter方向上的實(shí)踐和探索只是一個(gè)起點(diǎn)，我們意識(shí)到仍然有很多工作需要去做。我們堅(jiān)信Flutter作為一項(xiàng)領(lǐng)先的跨端技術(shù)，將為轉(zhuǎn)轉(zhuǎn)業(yè)務(wù)的發(fā)展帶來(lái)巨大的潛力和機(jī)會(huì)。我們將持續(xù)努力，加強(qiáng)技術(shù)建設(shè)，不斷完善實(shí)踐經(jīng)驗(yàn)，推動(dòng)Flutter在轉(zhuǎn)轉(zhuǎn)的應(yīng)用和發(fā)展，為用戶提供更好的產(chǎn)品和體驗(yàn)。