2018 年 12 月 ，Google 宣佈 Flutter 1.0 版本正式發佈。截至目前， Flutter 在 Github 上已獲得 88000+ 的關注和 11000+ 的 Fork ，其發展速度相當驚人，是今年移動端最火熱的開發框架之一。
Flutter 大火背後的原因是什麼？爲什麼越來越多的企業和開發者會選擇使用 Flutter？Flutter 會成爲跨平臺開發的終極之選嗎？
近日，InfoQ 有幸採訪到字節跳動移動平臺部 Flutter 架構師、知名博客 Gityuan 博主袁輝輝，他針對上述問題作了迴應。他表示“ Flutter 並非跨平臺終極之選，最初選擇 Flutter，不是因爲它一定會成爲未來終極之選，而是因爲它有可能成爲不一樣的未來。”此外，他還會在即將召開的 QCon 全球軟件開發大會 2020（北京站）上分享《字節跳動 Flutter 大規模業務落地與架構優化實戰》，感興趣的讀者可以關注。
以下爲袁輝輝的採訪內容整理。
Flutter 大火的原因
有人說 Flutter 大火主要原因是它選擇了 Dart 語言，Dart 有着高性能的表現和可快速分配內存的能力，能同時支持 JIT 和 AOT 模式，允許在帶類型的語言中支持形變和有狀態熱重載，能編譯出高效率的 ARM 機器碼指令，Dart 作爲面向對象的語言也能讓絕大多數開發者更快速上手。我認可 Dart 語言有一定的優勢，但這樣的優勢並非 Dart 獨有，我想這更不會是大家選擇 Flutter 的核心原因，這是因果倒置。事實上，Dart 是 2011 年推出的，在 Flutter 出現之前，Dart 曾一度幾乎被人遺忘。正是因爲近年來 Flutter 的火爆，才讓 Dart 重新進入大衆的視線。Flutter 當初選擇 Dart，或者僅因爲 Google 的 Flutter 和 Dart 這兩個團隊離得比較近，交流比較方便。
我認爲 Flutter 之所以大火，主要是以下幾個原因：
一、現有跨平臺技術存在缺陷
在移動互聯網時代，Android 和 iOS 兩大陣營長期共存，再加上體系成熟的 Web 前端技術，導致出現同一個應用需多端重複開發的人力成本問題。正因如此，移動時代下的跨平臺技術是一個需要長期研究的課題。如果當下的跨平臺技術已經有比較完美的解決方案，可能就沒有新技術萌芽的機會。而事實上，目前業界比較成熟的跨平臺技術都存在一定的缺陷，比如小程序（WebView）渲染耗時過長，白屏率會影響轉化收益，能實現的功能非常受限；再比如 React Native 的性能不足、問題排除難、維護成本高等。而 Flutter 的出現，讓這些跨平臺開發問題有所改善，它還是Google開源的技術，自身也具備一定的熱度。另外，一直備受關注且神祕的 Fuchsia 系統在 UI 框架上使用的也是Flutter，可作爲長期戰略投入，這也增強了大家對 Flutter 的信心。
二、研發效率就是競爭力
移動互聯網進入下半場，出現字節跳動等新巨頭，在沒有歷史包袱的情況下，更願意嘗試技術上限更高的新技術。從校招和社招的難度上不難發現：客戶端的人才相比之前更爲稀缺，尤其是 iOS 工程師。而下半場會有更多競爭和更爲激烈的賽道，比如教育等方向。Flutter 本身非常適合從零開始的沒有歷史包袱的應用開發，對於新業務尤其是在團隊人力緊缺的情況下，在技術選型上考慮 Flutter，能加快產品在多端落地、快速試錯。
三、集漂亮與流暢集於一身
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 端能力支持的。
字節跳動對於客戶端技術還是非常重視的，外界也多有調侃“ APP 工廠”，字節跳動有很多客戶端工程師，之前客戶端深入點的基礎技術更多是搞插件化、熱修復、性能優化、安全加固等，跨平臺方向一直都是前端工程師在不遺餘力地推進，屬於大前端方向。而 Flutter 是客戶端更有主導的跨平臺技術方案。另外說明，字節跳動並不是說只有一套跨平臺技術棧，公司內部也是多套跨端技術棧並存，也包括自研的方案。
在字節跳動，跨平臺技術並沒有形成大規模的落地，之前也提到沒有歷史包袱，所以在面對跨平臺技術選型的時候，更關注跨平臺技術的技術上限以及發展潛力，自渲染技術的 Flutter 可以理解爲更徹底更純粹的跨平臺技術，伴隨着媲美原生的流暢度，這便是我們選擇 Flutter 的初心。
Flutter 落地過程中的“坑”
截至目前，字節跳動有很多業務落地了 Flutter 技術方案，包括今日頭條、西瓜視頻、皮皮蝦等20多個業務在使用 Flutter 開發，有純 Flutter 工程，也有 Flutter 與 Native 的混合工程。如果大家想要了解更多業務落地情況，後續我會在今年的QCon北京2020大會上分享。
Flutter雖潛力上限很高，但仍需打磨和雕琢，我們在 Flutter 推動過程中遇到很多問題，比如包體積過大的問題、性能達不到預期、對混合工程的支持不夠友好、各宿主 Flutter 引擎版本不一致、基礎庫不完善、Flutter 改造後各項數據打平等。除此之外，還有很多非技術的困難，比如業務團隊並不認可 Flutter 新技術，工程師缺乏 Flutter 經驗，擔憂審覈風險等，都會影響業務方是否採用 Flutter 技術，每一個困難都需要去解決，不然就難以落地。下面就其中兩個難點，我來展開聊一下。
一、包體積問題
字節跳動內的大型 APP，比如今日頭條、抖音等對包體積的增量非常敏感，Flutter 的包體積涉及兩個部分，一個是一次性 Flutter 引擎的包體積問題，一個是每次寫 Dart 代碼比寫 OC 代碼代碼增量的問題。這兩個問題對我們來說都非常棘手，我們成立了包體積優化專項進行全力攻堅，同時跟 Google 工程師多次會議溝通，不斷精簡包體積。最終我們通過一系列優化手段，包含 Data 壓縮、編譯優化、Skia 裁剪、BoringSSL/ICU庫/文字渲染/libwebp等庫裁剪取得了不少的效果；通過實踐我們發現用 OC 代碼和 Dart 代碼寫相同的業務邏輯，Dart 生成的機器碼指令比 OC 多，主要在生成的二進制指令頭、指令冗餘、指令對齊的精簡，以及 StackMap 和 CodeSourceMap 的精簡等方面。同時我們也向 Google 反饋了這些情況。關於指令精簡，可以查看 Issue 進展 https://github.com/flutter/flutter/issues/40345，裏面有記錄詳細的推進過程。
二、性能優化問題
這是我們遇到的棘手問題之一，我們用 Flutter 官方提供的性能分析工具 Timeline 來分析一個比較詭異的性能問題，始終無法發現任何異常。困擾已久，後來乾脆重新擼了一遍 Timeline 整個性能分析工具的源碼，最終找到了其缺陷，並向 Flutter 社區提及，合入了10個 PR ，https://github.com/flutter/flutter/issues/47771，基於此讓我有幸成爲了 Flutter Member ，後續會持續向社區貢獻更多力量。
Flutter 是一個自渲染的跨平臺技術，有着很高的性能上限，但並不代表現在性能各方面都很優秀，畢竟 Flutter 作爲一個“新生兒”，還是有一些需要進一步改造的地方。除性能工具改造之外，其實在 Flutter 落地場景中，我們也解決了不少性能問題，同時優化了自身的引擎，比如 UI 預加載策略、Flutter Turbo 技術、Vsync調度策略等，讓引擎提速，爭取讓 Flutter 性能發揮到極致。
Flutter 在業務層面的發展阻力
引入 Flutter 之後，在公司的業務也創造了不少價值。主要體現在這幾個方面：其一，Flutter 多端一致性上表現良好，能做到所見即所得，無需針對某一平臺做額外適配工作；其二，熱重載技術使得設計團隊和工程團隊可以非常快速的修改和調試 UI，設計師只需要關注一個平臺實現，UI 驗收效率明顯提高，跨端開發可以提高工程師的人效（有團隊初步估算人效大致提升了1.8倍）；其三，性能流暢度提升，相較於 H5 版本首屏時間有較大提升，最後，產品商業化數據都有明顯的收益，能直觀地看到 Flutter 給公司帶來的創收。
不過，現階段 Flutter 的發展仍有一些阻力：
一、Flutter 採用的是 Dart 語言，沒能引入前端成熟的生態體系
作爲前端工程師可能更希望是 Flutter 上層採用的是 JavaScript 或者 TypeScript，未來可考慮提供高性能的 Dart 與 JS 互轉能力。另外，Flutter 開發對於前端開發工程師而言，還是有一些挑戰的，純前端不一定能 Cover 的技術，比如 Flutter 的一個硬件相關的 Plugin 只在某款手機出現 Bug，如果社區沒有現存解決方案，可能就需要花比較大的時間成本去學習 Native 技術，或者請教客戶端工程師。
二、開源庫相對比較欠缺，更新頻次不足
Flutter生態還不夠完善，新業務接入需要自己造輪子，尤其是在業務團隊對 Flutter 掌握不夠熟練的情況下，會增加額外的成本，Flutter 在大中型企業會更容易推廣起來，有人力可以去造輪子讓公司內其他的業務複用；另外，Flutter 文檔有點少，能借鑑的經驗不多，未來需加強和鼓勵更多開發者加入到生態共建。
三、跟原生系統生態存在着一定的競爭關係
有朋友跟我說起過這樣一件事，看到 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 更重要的是需要提升工程化能力以及生態圈的建設，才能吸引更多的開發者加入。
採訪嘉賓介紹：
袁輝輝，就職於字節跳動，在移動平臺部擔任 Flutter 架構師，主要負責 Flutter 性能架構。曾在小米、聯想、IBM 任職，從事 Android 系統框架底層優化與開發工作。他是知名博客 Gityuan 的博主，對 Android/Flutter 有着深刻的理解，編寫了近 200 篇高質量相關原創技術文章。
活動推薦：
在QCon北京2020的分享中，袁輝輝老師將介紹如何改進 Flutter 面臨的問題和挑戰，如何優化 Flutter 架構，如何提升體驗，點擊瞭解詳情。