感謝參考原文-http://bjbsair.com/2020-04-01/tech-info/18580.html
2018 年 12 月 ，Google 宣布 Flutter 1.0 版本正式發(fā)布。截至目前， Flutter 在 Github 上已獲得 88000+ 的關(guān)注和 11000+ 的 Fork ，其發(fā)展速度相當驚人，是今年移動端最火熱的開發(fā)框架之一。
Flutter 大火背后的原因是什么？為什么越來越多的企業(yè)和開發(fā)者會選擇使用 Flutter？Flutter 會成為跨平臺開發(fā)的終極之選嗎？
近日，InfoQ 有幸采訪到字節(jié)跳動移動平臺部 Flutter 架構(gòu)師、知名博客 Gityuan 博主袁輝輝，他針對上述問題作了回應。他表示“ Flutter 并非跨平臺終極之選，最初選擇 Flutter，不是因為它一定會成為未來終極之選，而是因為它有可能成為不一樣的未來?！贝送?，他還會在即將召開的 QCon 全球軟件開發(fā)大會 2020（北京站）上分享《字節(jié)跳動 Flutter 大規(guī)模業(yè)務落地與架構(gòu)優(yōu)化實戰(zhàn)》，感興趣的讀者可以關(guān)注。
以下為袁輝輝的采訪內(nèi)容整理。
Flutter 大火的原因
有人說 Flutter 大火主要原因是它選擇了 Dart 語言，Dart 有著高性能的表現(xiàn)和可快速分配內(nèi)存的能力，能同時支持 JIT 和 AOT 模式，允許在帶類型的語言中支持形變和有狀態(tài)熱重載，能編譯出高效率的 ARM 機器碼指令，Dart 作為面向?qū)ο蟮恼Z言也能讓絕大多數(shù)開發(fā)者更快速上手。我認可 Dart 語言有一定的優(yōu)勢，但這樣的優(yōu)勢并非 Dart 獨有，我想這更不會是大家選擇 Flutter 的核心原因，這是因果倒置。事實上，Dart 是 2011 年推出的，在 Flutter 出現(xiàn)之前，Dart 曾一度幾乎被人遺忘。正是因為近年來 Flutter 的火爆，才讓 Dart 重新進入大眾的視線。Flutter 當初選擇 Dart，或者僅因為 Google 的 Flutter 和 Dart 這兩個團隊離得比較近，交流比較方便。
我認為 Flutter 之所以大火，主要是以下幾個原因：
一、現(xiàn)有跨平臺技術(shù)存在缺陷
在移動互聯(lián)網(wǎng)時代，Android 和 iOS 兩大陣營長期共存，再加上體系成熟的 Web 前端技術(shù)，導致出現(xiàn)同一個應用需多端重復開發(fā)的人力成本問題。正因如此，移動時代下的跨平臺技術(shù)是一個需要長期研究的課題。如果當下的跨平臺技術(shù)已經(jīng)有比較完美的解決方案，可能就沒有新技術(shù)萌芽的機會。而事實上，目前業(yè)界比較成熟的跨平臺技術(shù)都存在一定的缺陷，比如小程序（WebView）渲染耗時過長，白屏率會影響轉(zhuǎn)化收益，能實現(xiàn)的功能非常受限；再比如 React Native 的性能不足、問題排除難、維護成本高等。而 Flutter 的出現(xiàn)，讓這些跨平臺開發(fā)問題有所改善，它還是 Google 開源的技術(shù)，自身也具備一定的熱度。另外，一直備受關(guān)注且神秘的 Fuchsia 系統(tǒng)在 UI 框架上使用的也是 Flutter，可作為長期戰(zhàn)略投入，這也增強了大家對 Flutter 的信心。
二、研發(fā)效率就是競爭力
移動互聯(lián)網(wǎng)進入下半場，出現(xiàn)字節(jié)跳動等新巨頭，在沒有歷史包袱的情況下，更愿意嘗試技術(shù)上限更高的新技術(shù)。從校招和社招的難度上不難發(fā)現(xiàn)：客戶端的人才相比之前更為稀缺，尤其是 iOS 工程師。而下半場會有更多競爭和更為激烈的賽道，比如教育等方向。Flutter 本身非常適合從零開始的沒有歷史包袱的應用開發(fā)，對于新業(yè)務尤其是在團隊人力緊缺的情況下，在技術(shù)選型上考慮 Flutter，能加快產(chǎn)品在多端落地、快速試錯。
三、集漂亮與流暢集于一身
Flutter “一出生”就以“UI 漂亮、像素級可控、性能流暢、可媲美原生性能”等特點吸引廣大開發(fā)者的眼球，自渲染引擎甚至具備開發(fā)游戲的能力。移動下半場，沒有人口紅利，競爭更為激烈，如何能更好地滿足用戶對高品質(zhì)、高流暢的需求，便是移動端一種強有力的競爭力。跨平臺技術(shù)想要擁有更高的流暢度，采用自渲染技術(shù)的方案便是更優(yōu)解，也是一個更為徹底的跨平臺技術(shù)方向。
字節(jié)跳動選擇 Flutter 的初心
說到這里，先分享一下 Flutter 最初是如何誕生的故事。Flutter 創(chuàng)始人 Eric 之前在 Chrome 團隊工作，期間遇到一些難以解決的問題， 希望 Web 中的一部分能夠擁有更加平滑的體驗， 為此他花了幾周時間做了一個實驗，不考慮 Web 的兼容方式，刪除了大量為了兼容訪問的代碼和一些 Web 開發(fā)者不常用的功能， 刪除到有不少 Web 元素的渲染已經(jīng)不支持了，然后做了一個基準測試，得出結(jié)論是某些關(guān)注指標的速度快了 20 倍。于是，Eric 決定再做點什么，后面投入了大量研究和開發(fā)，便有了現(xiàn)在的 Flutter 。
聽到這里給人的感覺是，對于 Web 工程師而言 Flutter 應該容易上手。我跟公司很多正在使用或者調(diào)研 Flutter 的業(yè)務團隊做過溝通，發(fā)現(xiàn)客戶端比前端的同學對 Flutter 接受度更高，我個人從 Android 端技術(shù)出身，的確覺得學習 Flutter 還是非常容易上手的，但公司內(nèi)前端的同學對 Flutter 使用的吐槽會多一點。所以，我認為 Flutter 更像是以客戶端視角的跨平臺技術(shù)，F(xiàn)lutter 與其說是大前端技術(shù)，不如說是大移動端技術(shù)。Flutter 發(fā)展的 Roadmap 也是先全面支持 Android/iOS 端能力，再進一步完善 Web 端能力支持的。
字節(jié)跳動對于客戶端技術(shù)還是非常重視的，外界也多有調(diào)侃“ APP 工廠”，字節(jié)跳動有很多客戶端工程師，之前客戶端深入點的基礎技術(shù)更多是搞插件化、熱修復、性能優(yōu)化、安全加固等，跨平臺方向一直都是前端工程師在不遺余力地推進，屬于大前端方向。而 Flutter 是客戶端更有主導的跨平臺技術(shù)方案。另外說明，字節(jié)跳動并不是說只有一套跨平臺技術(shù)棧，公司內(nèi)部也是多套跨端技術(shù)棧并存，也包括自研的方案。
在字節(jié)跳動，跨平臺技術(shù)并沒有形成大規(guī)模的落地，之前也提到?jīng)]有歷史包袱，所以在面對跨平臺技術(shù)選型的時候，更關(guān)注跨平臺技術(shù)的技術(shù)上限以及發(fā)展?jié)摿?，自渲染技術(shù)的 Flutter 可以理解為更徹底更純粹的跨平臺技術(shù)，伴隨著媲美原生的流暢度，這便是我們選擇 Flutter 的初心。
Flutter 落地過程中的“坑”
截至目前，字節(jié)跳動有很多業(yè)務落地了 Flutter 技術(shù)方案，包括今日頭條、西瓜視頻、皮皮蝦等 20 多個業(yè)務在使用 Flutter 開發(fā)，有純 Flutter 工程，也有 Flutter 與 Native 的混合工程。如果大家想要了解更多業(yè)務落地情況，后續(xù)我會在今年的 QCon 北京 2020 大會上分享。
Flutter 雖潛力上限很高，但仍需打磨和雕琢，我們在 Flutter 推動過程中遇到很多問題，比如包體積過大的問題、性能達不到預期、對混合工程的支持不夠友好、各宿主 Flutter 引擎版本不一致、基礎庫不完善、Flutter 改造后各項數(shù)據(jù)打平等。除此之外，還有很多非技術(shù)的困難，比如業(yè)務團隊并不認可 Flutter 新技術(shù)，工程師缺乏 Flutter 經(jīng)驗，擔憂審核風險等，都會影響業(yè)務方是否采用 Flutter 技術(shù)，每一個困難都需要去解決，不然就難以落地。下面就其中兩個難點，我來展開聊一下。
一、包體積問題
字節(jié)跳動內(nèi)的大型 APP，比如今日頭條、抖音等對包體積的增量非常敏感，F(xiàn)lutter 的包體積涉及兩個部分，一個是一次性 Flutter 引擎的包體積問題，一個是每次寫 Dart 代碼比寫 OC 代碼代碼增量的問題。這兩個問題對我們來說都非常棘手，我們成立了包體積優(yōu)化專項進行全力攻堅，同時跟 Google 工程師多次會議溝通，不斷精簡包體積。最終我們通過一系列優(yōu)化手段，包含 Data 壓縮、編譯優(yōu)化、Skia 裁剪、BoringSSL/ICU 庫 / 文字渲染 /libwebp 等庫裁剪取得了不少的效果；通過實踐我們發(fā)現(xiàn)用 OC 代碼和 Dart 代碼寫相同的業(yè)務邏輯，Dart 生成的機器碼指令比 OC 多，主要在生成的二進制指令頭、指令冗余、指令對齊的精簡，以及 StackMap 和 CodeSourceMap 的精簡等方面。同時我們也向 Google 反饋了這些情況。關(guān)于指令精簡，可以查看 Issue 進展 https://github.com/flutter/flutter/issues/40345 ，里面有記錄詳細的推進過程。
二、性能優(yōu)化問題
這是我們遇到的棘手問題之一，我們用 Flutter 官方提供的性能分析工具 Timeline 來分析一個比較詭異的性能問題，始終無法發(fā)現(xiàn)任何異常。困擾已久，后來干脆重新擼了一遍 Timeline 整個性能分析工具的源碼，最終找到了其缺陷，并向 Flutter 社區(qū)提及，合入了 10 個 PR ，基于此讓我有幸成為了 Flutter Member ，后續(xù)會持續(xù)向社區(qū)貢獻更多力量。
https://github.com/flutter/flutter/issues/47771
Flutter 是一個自渲染的跨平臺技術(shù)，有著很高的性能上限，但并不代表現(xiàn)在性能各方面都很優(yōu)秀，畢竟 Flutter 作為一個“新生兒”，還是有一些需要進一步改造的地方。除性能工具改造之外，其實在 Flutter 落地場景中，我們也解決了不少性能問題，同時優(yōu)化了自身的引擎，比如 UI 預加載策略、Flutter Turbo 技術(shù)、Vsync 調(diào)度策略等，讓引擎提速，爭取讓 Flutter 性能發(fā)揮到極致。
Flutter 在業(yè)務層面的發(fā)展阻力
引入 Flutter 之后，在公司的業(yè)務也創(chuàng)造了不少價值。主要體現(xiàn)在這幾個方面：其一，F(xiàn)lutter 多端一致性上表現(xiàn)良好，能做到所見即所得，無需針對某一平臺做額外適配工作；其二，熱重載技術(shù)使得設計團隊和工程團隊可以非?？焖俚男薷暮驼{(diào)試 UI，設計師只需要關(guān)注一個平臺實現(xiàn)，UI 驗收效率明顯提高，跨端開發(fā)可以提高工程師的人效（有團隊初步估算人效大致提升了 1.8 倍）；其三，性能流暢度提升，相較于 H5 版本首屏時間有較大提升，最后，產(chǎn)品商業(yè)化數(shù)據(jù)都有明顯的收益，能直觀地看到 Flutter 給公司帶來的創(chuàng)收。
不過，現(xiàn)階段 Flutter 的發(fā)展仍有一些阻力：
一、Flutter 采用的是 Dart 語言，沒能引入前端成熟的生態(tài)體系
作為前端工程師可能更希望是 Flutter 上層采用的是 JavaScript 或者 TypeScript，未來可考慮提供高性能的 Dart 與 JS 互轉(zhuǎn)能力。另外，F(xiàn)lutter 開發(fā)對于前端開發(fā)工程師而言，還是有一些挑戰(zhàn)的，純前端不一定能 Cover 的技術(shù)，比如 Flutter 的一個硬件相關(guān)的 Plugin 只在某款手機出現(xiàn) Bug，如果社區(qū)沒有現(xiàn)存解決方案，可能就需要花比較大的時間成本去學習 Native 技術(shù)，或者請教客戶端工程師。
二、開源庫相對比較欠缺，更新頻次不足
Flutter 生態(tài)還不夠完善，新業(yè)務接入需要自己造輪子，尤其是在業(yè)務團隊對 Flutter 掌握不夠熟練的情況下，會增加額外的成本，F(xiàn)lutter 在大中型企業(yè)會更容易推廣起來，有人力可以去造輪子讓公司內(nèi)其他的業(yè)務復用；另外，F(xiàn)lutter 文檔有點少，能借鑒的經(jīng)驗不多，未來需加強和鼓勵更多開發(fā)者加入到生態(tài)共建。
三、跟原生系統(tǒng)生態(tài)存在著一定的競爭關(guān)系
有朋友跟我說起過這樣一件事，看到 Flutter 這么火，Android 開發(fā)團隊就問他，“大家為什么要用 Flutter 開發(fā) App，我們 Android 哪一點不好，告訴我們，我們可以改進它”。姑且不說他們對跨平臺理解不夠，但至少能看出原生平臺對跨端技術(shù)的擔憂，不少 Android 團隊在推出 Kotlin Multiplatform ，希望能爭奪更多市場。
另外，蘋果商店的審核風險也是大家所擔憂的，官方的公告原意是說應用程序的核心特性和功能必須包含在軟件的二進制文件中，而不是通過類似 HTML5 的技術(shù)來實現(xiàn)動態(tài)更新，蘋果要打壓的是動態(tài)更新技術(shù)，考慮到 Flutter 的合規(guī)性，Google 主動把 Flutter 的 iOS 動態(tài)化能力去掉了，F(xiàn)lutter 最終打包生成的產(chǎn)物就是 IPA，F(xiàn)lutter 其實是完全符合規(guī)范的，甚至還有使用 Flutter 開發(fā)的應用還被 Apple 推薦過。相反，React Native、Weex、H5 等技術(shù)都是一種動態(tài)化解決方案，這正是蘋果要管控的，目前蘋果的態(tài)度更多的是不提倡，但也不保證不封殺。即便如此，蘋果不希望原生開發(fā)生態(tài)被其他跨平臺技術(shù)搶占，蘋果也在不斷推行 SwiftUI 框架，力圖抵擋 Flutter 等跨平臺技術(shù)對原生開發(fā)的餐食。Flutter 未來要加強推進步伐，讓更多的大型 App 通過 Flutter 技術(shù)得到收益，只有用戶群體上來，未來的地位和話語權(quán)才會更高，就像現(xiàn)在小程序，原則上是不符合蘋果的審核要求的，但各大型應用基本都上線了小程序功能，目前來看不至于說蘋果把小程序直接干掉。
Flutter 并非跨平臺終極之選
從 Hybrid App 到 React Native，再到 Flutter，跨平臺技術(shù)層出不窮。目前來看，F(xiàn)lutter 是跨平臺開發(fā)的最熱門技術(shù)，但我并不認為 Flutter 就一定是跨平臺開發(fā)的終極之選，它有著歷史局限性，我只能說 Flutter 可能是當下最有潛力的跨平臺技術(shù)。如果你對性能流暢度有高要求，或者有多個產(chǎn)品希望快速在多端試錯迭代，我會推薦你嘗試 Flutter。
未來一段時間，還應該是多套跨平臺技術(shù)并存的時代， 目前 Flutter 也沒有全面做到可以碾壓其他跨平臺技術(shù)，可根據(jù)團隊以及業(yè)務特點來考慮更適合的方案。 有一定客戶端經(jīng)驗的同學入手 Flutter 會更快一些，如果團隊在 React Native 上有很好落地，業(yè)務沒有遇到性能等瓶頸，且團隊缺少客戶端能力，建議先做技術(shù)調(diào)研和沉淀，不要盲目追求新技術(shù)，只有當團隊有能力且業(yè)務有需求的情況下，建議再考慮切換技術(shù)棧。
我們前面提到過，一直備受關(guān)注且神秘的 Fuchsia 系統(tǒng)在 UI 框架上使用的也是 Flutter。Fuchsia 是 Google 開發(fā)的下一代操作系統(tǒng)。Fuchsia 是采用全新模塊化設計思想、跨平臺框架技術(shù)的系統(tǒng)。它能支持快捷裁剪定制，更能適應未來的多元化設備，包含手機、平板、筆記本、路由器、智能設備、機器人等，F(xiàn)uchsia 有可能成為一個全新的跨全平臺的通用操作系統(tǒng)。
在現(xiàn)階段，開始嘗試探索和積累沉淀 Flutter 技術(shù)能力，并在業(yè)務上使用 Flutter 技術(shù)的應用，從戰(zhàn)略上來將已經(jīng)處于領先。選擇 Flutter，正可謂是“進可攻退可守”，往前進一步，F(xiàn)lutter 應用未來可無縫遷移到 Fuchsia 系統(tǒng)，借用 Fuchsia 系統(tǒng)的能量擴展到更廣泛的用戶場景；退一步，F(xiàn)lutter 技術(shù)自身在 Android/iOS 平臺的表現(xiàn)相比其他跨平臺技術(shù)已經(jīng)是很優(yōu)秀。
最初選擇 Flutter，不是因為它一定會成為未來終極之選，而是它有可能成為不一樣的未來。
Flutter 展望：終將走向多端一體化
回顧整移動操作系統(tǒng)的演變歷程，從塞班功能機到 Android/iOS 智能機，從小屏手機到全面屏、劉海屏、水滴屏。任何系統(tǒng)的演變最終體現(xiàn)在輸入和輸出兩個環(huán)節(jié)，接收到輸入信號后經(jīng)過操作系統(tǒng)處理后輸出信息給用戶。從按鍵式交互到觸屏式交互，伴隨著塞班系統(tǒng)到 Android 系統(tǒng)的轉(zhuǎn)變，未來的交互方式一定會更加生物智能化，當下的觸屏交互可以理解成人類的觸覺輸入方式，未來將朝著人們更常見的聽覺（語音）輸入和視覺（身體姿勢、表情等）輸入，甚至嗅覺（氣味變化）輸入，這些都會伴隨著新的操作系統(tǒng)而誕生。屏幕從小尺寸到大尺寸，并沒有引發(fā)操作系統(tǒng)變革，因為技術(shù)創(chuàng)新是非連續(xù)性，非連續(xù)性才會引發(fā)第二曲線，誕生新技術(shù)。從 1960 年大型機，到 1990 年個人筆記本，再到現(xiàn)在的智能手機，設備本身越來越小。未來的設備如果發(fā)展非連續(xù)變革，可能不再需要實體硬件，隨處可輸出，一張白紙、一面墻，到那時操作系統(tǒng)的 UI 架構(gòu)必然會有全新的變化。
隨著科技的發(fā)展，5G 時代的到來，人工智能的日趨成熟，端到底會有哪些變化？是否會出現(xiàn)新的操作系統(tǒng)？系統(tǒng)的 UI 架構(gòu)是否會出現(xiàn)新的變革？Android/iOS 平臺是否能與之并存？搭載 Flutter UI 框架的 Fuchsia 系統(tǒng)能否在 IOT 領域以及新的交互方式大放異彩，再領風騷？是否有萬物互聯(lián)互通的超級平臺出現(xiàn)？
技術(shù)在不斷演變中螺旋前進，平臺自身也隨之演進，未來 Flutter 會朝著多端一體化的方向發(fā)展，能支持更多的端（包括平板、筆記本、智能設備等）。作為一套跨平臺的 UI 框架，F(xiàn)lutter 采用自渲染的技術(shù)方案，是一個上限很高的跨平臺技術(shù)，但 Flutter 更重要的是需要提升工程化能力以及生態(tài)圈的建設，才能吸引更多的開發(fā)者加入。
采訪嘉賓介紹：
袁輝輝，就職于字節(jié)跳動，在移動平臺部擔任 Flutter 架構(gòu)師，主要負責 Flutter 性能架構(gòu)。曾在小米、聯(lián)想、IBM 任職，從事 Android 系統(tǒng)框架底層優(yōu)化與開發(fā)工作。他是知名博客 Gityuan 的博主，對 Android/Flutter 有著深刻的理解，編寫了近 200 篇高質(zhì)量相關(guān)原創(chuàng)技術(shù)文章。
