作者：Gityuan
連結：

2018 年 12 月，Google 宣佈 Flutter 1.0 版本正式釋出。截至目前， Flutter 在 Github 上已獲得 88000+ 的關注和 11000+ 的 Fork ，其發展速度相當驚人，是今年移動端最火熱的開發框架之一。

Flutter 大火背後的原因是什麼？為什麼越來越多的企業和開發者會選擇使用 Flutter？Flutter 會成為跨平臺開發的終極之選嗎？近日，InfoQ 邀請我談一談對上述問題的看法，我認為“ Flutter 並非跨平臺終極之選，最初選擇 Flutter，不是因為它一定會成為未來終極之選，而是因為它有可能成為不一樣的未來。”

Flutter 大火的原因

有人說 Flutter 大火主要原因是它選擇了 Dart 語言，Dart 有著高效能的表現和可快速分配記憶體的能力，能同時支援 JIT 和 AOT 模式，允許在帶型別的語言中支援形變和有狀態熱過載，能編譯出高效率的 ARM 機器碼指令，Dart 作為物件導向的語言也能讓絕大多數開發者更快速上手。我認可 Dart 語言有一定的優勢，但這樣的優勢並非 Dart 獨有，我想這更不會是大家選擇 Flutter 的核心原因，這是因果倒置。事實上，Dart 是 2011 年推出的，在 Flutter 出現之前，Dart 曾一度幾乎被人遺忘。正是因為近年來 Flutter 的火爆，才讓 Dart 重新進入大眾的視線。Flutter 當初選擇 Dart，或者僅因為 Google 的 Flutter 和 Dart 這兩個團隊離得比較近，交流比較方便。我認為 Flutter 之所以大火，主要是以下幾個原因：

1. 現有跨平臺技術存在缺陷

在移動網際網路時代，Android 和 iOS 兩大陣營長期共存，再加上體系成熟的 Web 前端技術，導致出現同一個應用需多端重複開發的人力成本問題。正因如此，移動時代下的跨平臺技術是一個需要長期研究的課題。如果當下的跨平臺技術已經有比較完美的解決方案，可能就沒有新技術萌芽的機會。而事實上，目前業界比較成熟的跨平臺技術都存在一定的缺陷，比如小程式（WebView）渲染耗時過長，白屏率會影響轉化收益，能實現的功能非常受限；再比如 React Native 的效能不足、問題排除難、維護成本高等。而 Flutter 的出現，讓這些跨平臺開發問題有所改善，它還是 Google 開源的技術，自身也具備一定的熱度。另外，一直備受關注且神秘的 Fuchsia 系統在 UI 框架上使用的也是 Flutter，可作為長期戰略投入，這也增強了大家對 Flutter 的信心。

2. 研發效率就是競爭力

移動網際網路進入下半場，出現一些新興網際網路獨角獸、小巨頭，在沒有歷史包袱的情況下，更願意嘗試技術上限更高的新技術。從校招和社招的難度上不難發現：客戶端的人才相比之前更為稀缺，尤其是 iOS 工程師。而下半場會有更多競爭和更為激烈的賽道，比如教育等方向。Flutter 本身非常適合從零開始的沒有歷史包袱的應用開發，對於新業務尤其是在團隊人力緊缺的情況下，在技術選型上考慮 Flutter，能加快產品在多端落地、快速試錯。

3. 集漂亮與流暢集於一身

Flutter “一出生”就以“UI 漂亮、畫素級可控、效能流暢、可媲美原生效能”等特點吸引廣大開發者的眼球，自渲染引擎甚至具備開發遊戲的能力。移動下半場，沒有人口紅利，競爭更為激烈，如何能更好地滿足使用者對高品質、高流暢的需求，便是移動端一種強有力的競爭力。跨平臺技術想要擁有更高的流暢度，採用自渲染技術的方案便是更優解，也是一個更為徹底的跨平臺技術方向。

位元組跳動選擇 Flutter 的初心

說到這裡，先分享一下 Flutter 最初是如何誕生的故事。Flutter 創始人 Eric 之前在 Chrome 團隊工作，期間遇到一些難以解決的問題，希望 Web 中的一部分能夠擁有更加平滑的體驗，為此他花了幾周時間做了一個實驗，不考慮 Web 的相容方式，刪除了大量為了相容訪問的程式碼和一些 Web 開發者不常用的功能，刪除到有不少 Web 元素的渲染已經不支援了，然後做了一個基準測試，得出結論是某些關注指標的速度快了 20 倍。於是，Eric 決定再做點什麼，後面投入了大量研究和開發，便有了現在的 Flutter 。

聽到這裡給人的感覺是，對於 Web 工程師而言 Flutter 應該容易上手。我跟公司很多正在使用或者調研 Flutter 的業務團隊做過溝通，發現客戶端比前端的同學對 Flutter 接受度更高，我個人從 Android 端技術出身，的確覺得學習 Flutter 還是非常容易上手的，但公司內前端的同學對 Flutter 使用的吐槽會多一點。所以，我認為 Flutter 更像是以客戶端視角的跨平臺技術，Flutter 與其說是大前端技術，不如說是大移動端技術。Flutter 發展的 Roadmap 也是先全面支援 Android/iOS 端能力，再進一步完善 Web 端能力支援的。

位元組跳動對於客戶端技術還是非常重視的，位元組跳動有很多客戶端工程師，之前客戶端深入點的基礎技術更多是搞外掛化、熱修復、效能最佳化、安全加固等，跨平臺方向一直都是前端工程師在不遺餘力地推進，屬於大前端方向。而 Flutter 是客戶端更有主導的跨平臺技術方案。另外說明，位元組跳動並不是說只有一套跨平臺技術棧，公司內部也是多套跨端技術棧並存，也包括自研的方案。

在位元組跳動，跨平臺技術並沒有形成大規模的落地，之前也提到沒有歷史包袱，所以在面對跨平臺技術選型的時候，更關注跨平臺技術的技術上限以及發展潛力，自渲染技術的 Flutter 可以理解為更徹底更純粹的跨平臺技術，伴隨著媲美原生的流暢度，這便是我們選擇 Flutter 的初心。

Flutter 落地過程中的“坑”

截至目前，位元組跳動有很多業務落地了 Flutter 技術方案，包括今日頭條、西瓜影片、皮皮蝦等 20 多個業務在使用 Flutter 開發，有純 Flutter 工程，也有 Flutter 與 Native 的混合工程。如果大家想要了解更多業務落地情況，後續我會在今年的 QCon 北京 2020 大會上分享。

Flutter 雖潛力上限很高，但仍需打磨和雕琢，我們在 Flutter 推動過程中遇到很多問題，比如包體積過大的問題、效能達不到預期、對混合工程的支援不夠友好、各宿主 Flutter 引擎版本不一致、基礎庫不完善、Flutter 改造後各項資料打平等。除此之外，還有很多非技術的困難，比如業務團隊並不認可 Flutter 新技術，工程師缺乏 Flutter 經驗，擔憂稽核風險等，都會影響業務方是否採用 Flutter 技術，每一個困難都需要去解決，不然就難以落地。下面就其中兩個難點，我來展開聊一下。

1. 包體積問題

位元組跳動內的大型 APP，比如今日頭條、抖音等對包體積的增量非常敏感，Flutter 的包體積涉及兩個部分，一個是一次性 Flutter 引擎的包體積問題，一個是每次寫 Dart 程式碼比寫 OC 程式碼程式碼增量的問題。這兩個問題對我們來說都非常棘手，我們成立了包體積最佳化專項進行全力攻堅，同時跟 Google 工程師多次會議溝通，不斷精簡包體積。最終我們透過一系列最佳化手段，包含 Data 壓縮、編譯最佳化、Skia 裁剪、BoringSSL/ICU 庫 / 文字渲染 /libwebp 等庫裁剪取得了不少的效果；透過實踐我們發現用 OC 程式碼和 Dart 程式碼寫相同的業務邏輯，Dart 生成的機器碼指令比 OC 多，主要在生成的二進位制指令頭、指令冗餘、指令對齊的精簡，以及 StackMap 和 CodeSourceMap 的精簡等方面。同時我們也向 Google 反饋了這些情況。關於指令精簡，可以檢視 Issue 進展，裡面有記錄詳細的推進過程：

2. 效能最佳化問題

這是我們遇到的棘手問題之一，我們用 Flutter 官方提供的效能分析工具 Timeline 來分析一個比較詭異的效能問題，始終無法發現任何異常。困擾已久，後來乾脆重新擼了一遍 Timeline 整個效能分析工具的原始碼，最終找到了其缺陷，並向 Flutter 社群提及，合入了 10 個 PR ，基於此讓我有幸成為了 Flutter Member ，後續會持續向社群貢獻更多力量：

Flutter 是一個自渲染的跨平臺技術，有著很高的效能上限，但並不代表現在效能各方面都很優秀，畢竟 Flutter 作為一個“新生兒”，還是有一些需要進一步改造的地方。除效能工具改造之外，其實在 Flutter 落地場景中，我們也解決了不少效能問題，同時最佳化了自身的引擎，比如 UI 預載入策略、Flutter Turbo 技術、Vsync 排程策略等，讓引擎提速，爭取讓 Flutter 效能發揮到極致。

Flutter 在業務層面的發展阻力

引入 Flutter 之後，在公司的業務也創造了不少價值。主要體現在這幾個方面：其一，Flutter 多端一致性上表現良好，能做到所見即所得，無需針對某一平臺做額外適配工作；其二，熱過載技術使得設計團隊和工程團隊可以非常快速的修改和除錯 UI，設計師只需要關注一個平臺實現，UI 驗收效率明顯提高，跨端開發可以提高工程師的人效（有團隊初步估算人效大致提升了 1.8 倍）；其三，效能流暢度提升，相較於 H5 版本首屏時間有較大提升，最後，產品商業化資料都有明顯的收益，能直觀地看到 Flutter 給公司帶來的創收。

不過，現階段 Flutter 的發展仍有一些阻力：

1. Flutter 採用的是 Dart 語言，沒能引入前端成熟的生態體系

作為前端工程師可能更希望是 Flutter 上層採用的是 JavaScript 或者 TypeScript，未來可考慮提供高效能的 Dart 與 JS 互轉能力。另外，Flutter 開發對於前端開發工程師而言，還是有一些挑戰的，純前端不一定能 Cover 的技術，比如 Flutter 的一個硬體相關的 Plugin 只在某款手機出現 Bug，如果社群沒有現存解決方案，可能就需要花比較大的時間成本去學習 Native 技術，或者請教客戶端工程師。

2. 開源庫相對比較欠缺，更新頻次不足

Flutter 生態還不夠完善，新業務接入需要自己造輪子，尤其是在業務團隊對 Flutter 掌握不夠熟練的情況下，會增加額外的成本，Flutter 在大中型企業會更容易推廣起來，有人力可以去造輪子讓公司內其他的業務複用；另外，Flutter 文件有點少，能借鑑的經驗不多，未來需加強和鼓勵更多開發者加入到生態共建。

3. 跟原生系統生態存在著一定的競爭關係

有朋友跟我說起過這樣一件事，看到 Flutter 這麼火，Android 開發團隊就問他，“大家為什麼要用 Flutter 開發 App，我們 Android 哪一點不好，告訴我們，我們可以改進它”。姑且不說他們對跨平臺理解不夠，但至少能看出原生平臺對跨端技術的擔憂，不少 Android 團隊在推出 Kotlin Multiplatform ，希望能爭奪更多市場。另外，蘋果商店的稽核風險也是大家所擔憂的，官方的公告原意是說應用程式的核心特性和功能必須包含在軟體的二進位制檔案中，而不是透過類似 HTML5 的技術來實現動態更新，蘋果要打壓的是動態更新技術，考慮到 Flutter 的合規性，Google 主動把 Flutter 的 iOS 動態化能力去掉了，Flutter 最終打包生成的產物就是 IPA，Flutter 其實是完全符合規範的，甚至還有使用 Flutter 開發的應用還被 Apple 推薦過。相反，React Native、Weex、H5 等技術都是一種動態化解決方案，這正是蘋果要管控的，目前蘋果的態度更多的是不提倡，但也不保證不封殺。即便如此，蘋果不希望原生開發生態被其他跨平臺技術搶佔，蘋果也在不斷推行 SwiftUI 框架，力圖抵擋 Flutter 等跨平臺技術對原生開發的蠶食。Flutter 未來要加強推進步伐，讓更多的大型 App 透過 Flutter 技術得到收益，只有使用者群體上來，未來的地位和話語權才會更高，就像現在小程式，原則上是不符合蘋果的稽核要求的，但各大型應用基本都上線了小程式功能，目前來看不至於說蘋果把小程式直接幹掉。

Flutter 並非跨平臺終極之選

從 Hybrid App 到 React Native，再到 Flutter，跨平臺技術層出不窮。目前來看，Flutter 是跨平臺開發的最熱門技術，但我並不認為 Flutter 就一定是跨平臺開發的終極之選，它有著歷史侷限性，我只能說 Flutter 可能是當下最有潛力的跨平臺技術。如果你對效能流暢度有高要求，或者有多個產品希望快速在多端試錯迭代，我會推薦你嘗試 Flutter。

未來一段時間，還應該是多套跨平臺技術並存的時代，目前 Flutter 也沒有全面做到可以碾壓其他跨平臺技術，可根據團隊以及業務特點來考慮更適合的方案。有一定客戶端經驗的同學入手 Flutter 會更快一些，如果團隊在 React Native 上有很好落地，業務沒有遇到效能等瓶頸，且團隊缺少客戶端能力，建議先做技術調研和沉澱，不要盲目追求新技術，只有當團隊有能力且業務有需求的情況下，建議再考慮切換技術棧。

我們前面提到過，一直備受關注且神秘的 Fuchsia 系統在 UI 框架上使用的也是 Flutter。Fuchsia 是 Google 開發的下一代作業系統。Fuchsia 是採用全新模組化設計思想、跨平臺框架技術的系統。它能支援快捷裁剪定製，更能適應未來的多元化裝置，包含手機、平板、筆記本、路由器、智慧裝置、機器人等，Fuchsia 有可能成為一個全新的跨全平臺的通用作業系統。

在現階段，開始嘗試探索和積累沉澱 Flutter 技術能力，並在業務上使用 Flutter 技術的應用，從戰略上來將已經處於領先。選擇 Flutter，正可謂是“進可攻退可守”，往前進一步，Flutter 應用未來可無縫遷移到 Fuchsia 系統，借用 Fuchsia 系統的能量擴充套件到更廣泛的使用者場景；退一步，Flutter 技術自身在 Android/iOS 平臺的表現相比其他跨平臺技術已經是很優秀。

最初選擇 Flutter，不是因為它一定會成為未來終極之選，而是它有可能成為不一樣的未來。

Flutter 展望：終將走向多端一體化

回顧整移動作業系統的演變歷程，從塞班功能機到 Android/iOS 智慧機，從小屏手機到全面屏、劉海屏、水滴屏。任何系統的演變最終體現在輸入和輸出兩個環節，接收到輸入訊號後經過作業系統處理後輸出資訊給使用者。

從按鍵式互動到觸屏式互動，伴隨著塞班系統到 Android 系統的轉變，未來的互動方式一定會更加生物智慧化，當下的觸屏互動可以理解成人類的觸覺輸入方式，未來將朝著人們更常見的聽覺（語音）輸入和視覺（身體姿勢、表情等）輸入，甚至嗅覺（氣味變化）輸入，這些都會伴隨著新的作業系統而誕生。螢幕從小尺寸到大尺寸，並沒有引發作業系統變革，因為技術創新是非連續性，非連續性才會引發第二曲線，誕生新技術。

從 1960 年大型機，到 1990 年個人筆記本，再到現在的智慧手機，裝置本身越來越小。未來的裝置如果發展非連續變革，可能不再需要實體硬體，隨處可輸出，一張白紙、一面牆，到那時作業系統的 UI 架構必然會有全新的變化。

隨著科技的發展，5G 時代的到來，人工智慧的日趨成熟，端到底會有哪些變化？是否會出現新的作業系統？系統的 UI 架構是否會出現新的變革？Android/iOS 平臺是否能與之並存？搭載 Flutter UI 框架的 Fuchsia 系統能否在 IOT 領域以及新的互動方式大放異彩，再領風騷？是否有萬物互聯互通的超級平臺出現？

技術在不斷演變中螺旋前進，平臺自身也隨之演進，未來 Flutter 會朝著多端一體化的方向發展，能支援更多的端（包括平板、筆記本、智慧裝置等）。作為一套跨平臺的 UI 框架，Flutter 採用自渲染的技術方案，是一個上限很高的跨平臺技術，但 Flutter 更重要的是需要提升工程化能力以及生態圈的建設，才能吸引更多的開發者加入。