前言

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

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

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

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

可行性驗證

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

目標

我們確定了以下幾個維度，用來評估 Flutter 是否值得我們進一步投入：

• 開發(fā)效率
• UI一致性
• 性能體驗
• 學習成本
• 發(fā)展趨勢

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

方案

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

測試目標

當時我們正在做一個叫切克的 App，用戶量級比較小，工程架構(gòu)也相對簡單一些，正好可以用來做一些技術(shù)方面的探索和驗證。

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

項目架構(gòu)

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

關(guān)于混合頁面棧的問題，我們沒有額外處理，因為暫時只測試一個頁面，不會涉及到多頁面混合棧的問題，所以暫時先忽略。

構(gòu)建流程

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

結(jié)論

經(jīng)過一段時間的線上驗證，我對 Flutter 技術(shù)基本有了一個比較全面的了解：

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

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

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

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

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

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

基建一期建設(shè)

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

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

在基建一期完成后，我們的目標是要達到：

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

工程架構(gòu)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Flutter分層架構(gòu)

開發(fā)框架

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

基礎(chǔ)能力

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

狀態(tài)管理

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

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

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

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

收藏詳情和個人主頁

頁面棧管理

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

腳本工具

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

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

如圖：

zflutter

自動化構(gòu)建

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

小范圍試驗

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

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

個人資料頁/留言列表頁

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

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

基礎(chǔ)能力

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

工作流

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

開發(fā)效率

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

性能體驗

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

包體積

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

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

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

基建二期建設(shè)

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

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

Beetle支持Flutter

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

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

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

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

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

為了讓大家更快的熟悉 Flutter 開發(fā)，我們在客戶端內(nèi)部組織了5次 Flutter 快速入門的系列分享：

Flutter快速入門系列

同時也逐步完善內(nèi)部文檔的建設(shè)，包括：FlutterSdk 源碼維護策略、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ā)布的整個過程。

大范圍推廣

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

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

部分頁面如下圖所示：

個人主頁

探索前端生態(tài)

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

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

當時可選的開源方案有：Kraken、MXFlutter、Flutter For Web。

Kraken

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

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

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

MXFlutter

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

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

Flutter For Web

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

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

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

結(jié)論

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

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

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

上線驗證

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

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

上線后，我們對頁面的各項指標進行了對比，使用 Kraken 容器加載比使用 WebView 加載，在首屏加載耗時的指標上平均增加了281毫秒，原因為：當前版本的 Kraken 容器不支持直接加載 HTML，且只能加載單個 JsBundle，導(dǎo)致加載效率比 WebView 差。

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

再次驗證

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

附近的人

最終因為部分問題得不到解決，并且整體性能較差，導(dǎo)致頁面沒能成功上線。

存在的問題包括但不限于下面列舉的一些：

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

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

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

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

• 重大 Bug

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

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

• 調(diào)試成本高

不支持 vue-router，單項目單路由

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

不支持 sourceMap，無法定位源代碼

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

頁面白屏，假死

• 安全性問題

無瀏覽器中的“同源策略”限制

• 兼容性

npm 包不兼容等

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

結(jié)尾

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