Flutter 和 RN、Weex 等跨平臺技術相比有什麼優勢？

flutter的技術沒有什麼革命性的地方。

但是flutter確實是工程和市場性做的最平衡的東西。也只有google有這能力。

需求就是一次開發: 所有端能用。

市場性比flutter好的：react native。可以複用一堆javascript/css程序員。無縫開寫。但工程型差很多。一次寫完

到處適配。android和ios還好。但是以後的web端。各種屏幕端？還有性能問題了？

工程性比flutter好的：Qt。但是問題就是不會有人用C++寫業務了。

所以。你覺得技術上沒有比已有的技術好是對的。覺得用dart不尊重市場也是對的。但是放在一起就是比其他現有解決方案要好。

並沒有,在我看來就是flutter就是谷歌對着瀏覽器砍了一大刀而砍出來的東西.丟了許多的包袱.

Flutter是谷歌的移動UI框架，它可以快速的爲iOS和Android構建高質量的原生UI。 當前被越來越多的開發人員在使用Flutter。Flutter有四大主要特性：

第一.Flutter具備一個高性能的系統架構，Flutter的代碼最終會被編譯成原生的ARM代碼執行。

第二. Flutter有很好的開發體驗和開發效率，特別hot reload（熱重載）的功能，它可以讓等待代碼編譯的情況成爲過去。

第三. Flutter自帶了整套的material design組件庫，以及主要的iOS系統組件，可以幫助開發者快速的構建他們的移動應用，同時可以達到美觀和可用的效果，

第四. Flutter的同一代碼庫，可以同時部署到iOS跟Android兩大移動平臺，幫助開發者節省開發和部署的時間。

開發人員都知道，開發一款能夠讓用戶真正喜愛的應用是非常難的，有四個重要的點需要考慮：

  1. 快速，無延遲的觸摸反饋。應用程序的速度必須快，不能夠有延遲，這是最基本的要求，
  2. 響應用戶快速變化的需求。應用程序的功能和用戶界面是應該不斷迭代，以滿足用戶變化的需求和市場的情況。
  3. 自然易用。移動應用必須要容易使用，它需要尊重各個平臺上用戶已經形成的使用習慣。
  4. 美觀有表現力，UI設計要能夠表現一個品牌的特點，讓用戶能夠過目不忘，這樣才能夠在非常激烈的市場競爭中脫穎而出。

Flutter框架就是希望幫助開發者能夠更好的解決上述這幾項挑戰。

第一.快速，無延遲的觸摸反饋

Flutter通過兩點來保證一個移動應用做到高性能無延遲，首先Flutter的代碼不論在Android還是在iOS上，都是編譯成原生代碼執行的。FlutterSDK有兩個部分組成，它有一個引擎和一個框架。Flutter代碼引擎是由c和c++代碼編寫，在Android上通過ndk編譯成原生代碼，在iOS上通過llvm編譯成原生代碼，然後Flutter框架本身由dart語言編寫，當部署到生產環境的時候，dart代碼會通過aot（ahead of time）的方式編譯成原生代碼執行。

其次，Flutter在架構上保證了執行的高效率，它的一個技術特點是它不調用系統自帶的UI組件，以此來降低應用程序代碼跟平臺之間的通信造成的性能損耗。

Flutter和react native有明顯的區別，下面是一張用Flutter寫的應用程序和用react native寫的應用程序，分別和操作系統的通信的需求和機制的圖。

上半部分是flutter應用和操作系統的關係，下半部分是react應用和操作系統的關係，大家可以看到flutter應用，它只用移動操作系統提供的畫布，其餘的ui渲染過程都是在自身的應用程序代碼和flutter本身的框架的代碼來完成。這樣的架構不但在性能上存在優勢，同時也讓開發者對整體的ui可以深度控制，可以控制屏幕上的每一個像素。flutter架構上的特點，讓它能夠在型號比較老的手機上也能夠達到每秒60幀的性能。

第二.響應用戶快速變化的需求

其次flutter能夠幫助移動開發者快速響應用戶的需求，這一點對於中國的開發人員特別重要，因爲中國的互聯網發展速度是全球領先的，flutter有幾個特點可以幫助開發者實現快速的產品迭代。

flutter代碼編譯速度非常快，

上面的漫畫是一個非常經典的關於程序編譯時間的梗，開發人員可能也體驗過編譯項目可能要等一分鐘或者幾分鐘，才能把一個很小的ui反映到你正在運行的APP上面，flutter中有個功能叫做hot reload，它能幫助開發者節省不必要的等待時間，讓整個開發體驗更加流暢。 Hot reload不僅僅可以用到比較小的ui改動上，如果你對uI的佈局做了一個大的改動，它也可以在幾乎不到一秒的時間，把這個更新體現到你正在運行的移動應用上面，

Hot reload還有另外一個優點，就是會保持這個應用的當前狀態，所以當改變這ui中的顏色啊字體大小的時候，ui上的數據是沒有被重置的，移動應用還是當前那個狀態。這個特點對於開發導航流程非常複雜的移動APP是特別方便的，因爲不需要再執行一遍流程到你當前改動的那一頁，然後每改動一點，又要重新走一遍流程或者輸入各種用戶數據。除了hot reload之外，flutter還自帶了豐富的widget（組件），幫助開發者迅速實現原型，並且進行迭代。flutter自帶了大量高品質的material design組件，同時flutter也提供基本的iOS 系統組件，讓你的應用符合iOS用戶的使用習慣。

還有就是flutter能夠幫助開發者實現快速迭代的開發，支持在iOS跟Android上同步開發和測試。這裏舉個例子，有一款應用爲百老匯音樂劇漢密爾頓製作的。哈密爾頓在美國是一個非常非常火爆的百老匯音樂劇，他們用flutter開發了一款同主題的移動應用，在iOS和安卓上都同時發佈，並且受到了廣泛的好評。這款應用其實在發佈前一週是出現了一個問題，就是漢密爾頓的團隊發現首頁的設計會產生很大的問題，他們想對首頁進行大改，但是離發佈只有一個禮拜，在傳統的開發方式下，這樣開發時間是無法完成任務的，然而意外的是一週以後他們如期發佈了這款應用，是在實現了所有他們他們想對首頁設計做出改動的情況下，漢密爾頓的主要的開發者前段時間召開的GDP歐洲大會上分享了他們的體會，他說如果當時在兩個平臺上有兩套不同的代碼。是不可能在應用發佈前一週，那麼短的時間內，如此大幅度改動首頁ui。

第三.自然易用的ui

前面介紹flutter其中一個特點是能夠幫助開發者實現快速迭代產品，一款優秀的移動應用程序是應該尊重用戶的基本使用習慣，而不是讓用戶需要去學習那些非常底層的操作，跨平臺設計的目標是在展現品牌特色的同時要做到尊重系統平系統平臺的設計特點。 flutter框架對於作爲一個同時支持iOS和Android兩大移動平臺的SDK，flutter可以實現這兩個平臺上用戶使用很自然的用戶體驗，首先flutter對系統的ui的最底層的基本的交互實現了自動的匹配，開發者不需要多寫一行代碼就可以實現這些匹配，flutter框架還提供了兩套不同風格的ui組件，如果你的應用需要進一步跟操作系統的風格保持一致，你可以選擇在不同的系統上顯示不同風格的系統組件。

第四.美觀有表現力

最後flutter爲了實現在iOS和Android兩大平臺上讓用戶感覺自然的用戶體驗，就是flutter可以幫助開發者實現高度定製的有品牌表現力的uI設計。這一點非常重要，如果大家關注最近這幾年獲獎的應用程序，會發現大量的應用都不是一個簡單的系統風格的設計，這裏舉一個例子，一個應用叫做breakfast，他們獲得material design award，這款應用設計並不是簡單的安卓風格或者是iOS風格，有屬於自己的品牌特色的設計，應用中有大量的定製化設計，這是移動應用設計的一個趨勢，爲了適應這樣的趨勢，flutter做了很好的支持。flutter可以幫助開發者實現高度定製的uI設計，它希望是開發者可以不再對uI設計師的想象力說不。現實中有uI設計師可能有時候也會碰到這樣的問題，ui設計師有一個很好的想法，當把想法告訴開發人員，然後開發人員告訴你是不是有一點想多了，這是一件多麼尷尬的事情，希望以後不會再出現。Flutter希望在框架的層面幫助大家充分發揮自己的創造力。

通過下面架構示意圖瞭解flutter如何在技術層面上可以保證ui的可定製性，

flutter框架是由很多層組成的，最上面一層是material design widgets和cupertino的位置，也就是蘋果風格的系統ui組件，一方面開發者可以直接使用最上層的兩套有ui控件來快速實現接近系統標準風格的應用uI，另一方面開發者也可以通過使用較低幾個層次的組件，或者通過組合不同的高層次的組件來實現高度定製的uI，並且整個framework都是開放源代碼的，所以非常容易讓開發者瞭解每一個組件是怎樣實現的，並且在上面做進行修改。

在每一個flutter應用程序裏面，每一個像素都是由flutter框架和引擎本身繪製的。不受限於系統本身提供的ui控件，所以開發者對於它的應用程序的外觀和交互都是有一個全局的控制能力。

在這裏在總結以下flutter的主要的特點，首先flutter具備一個非常高性能的系統架構，保證應用程序能夠流暢的運行，其次flutter有優秀的開發體驗和開發效率，再次就是flutter有一個美觀非常豐富的，並且是可擴展的組件庫，最後flutter可以用一個代碼庫來編譯成iOS和Android的移動應用，幫助開發人員提高開發效率，快速響應用戶的需求。

Flutter 的革命性在於它親爹是 Google，技術上沒有革命性。

什麼代碼熱更，代碼推送，自繪組件，別的跨平臺 UI 框架很多早都有了，甚至跨的端還比 Flutter 多，舉個例子：Xamarin（含Xamarin.Forms），支持開發Windows（UWP/WPF）、Linux（GTK#）、MacOS、iOS、Android、tvOS、watchOS以及WebAssembly這麼多的GUI應用程序，可以說只要是有顯示屏的設備就沒有不能用Xamarin的時候。

然而在國內，只要是 Google 的東西，無論東西到底如何，

剛一發布公告就一大堆人吹跨世紀的創新；

剛一發布 beta 就一大堆人吹穩定好用可生產環境；

剛一發布正式版就一大堆人吹 IT 界的革命。

其他家的東西尤其是 Microsoft 的，哪怕東西再好，

發佈的時候無人問津；

發佈的時候甚至連篇 blog 介紹都沒；

發佈以後問起來用都沒用過就說不咋樣。

也不看看谷歌歷史上多少東西都是剛一出來賊火，火過一陣子就掛了。輪砍東西 Google 可是不輸 Microsoft 的。

Dart 語言你以爲是新的？根本不是。谷歌推了好幾年了，一開始出來呀各種新聞，但是因爲太難用所以後面根本沒什麼人用，前幾年一度還差點死了，現在藉助 Flutter 好不容易讓 Dart 看勢能撈一波。你們以爲這是個什麼好東西？覺得好用的怕不是 Java 寫多了見怪不怪了。

native 跨平臺 UI 框架想要真的做好離不開對方平臺的官方支持。然而事實是 Apple 推 Swift、Microsoft 推 Xamarin，Google 推 Flutter，每家都想在這個領域分一杯羹，還輪不到別家過來在自己平臺上搞一手。

好用和能用之間差了十萬八千里遠，Flutter 不出所料至今爲止只有對安卓的支持是最好的，而就算是自己親兒子安卓也一大堆的 bug，其他端體驗真的只是“能用”。這不是什麼親兒子不親兒子的問題，而是沒有別家的支持你是根本做不起來的，幻想着 Flutter 統一各平臺 UI 開發真的就是想屁喫，就包括更成熟的 Xamarin 在內也是在想屁喫，不然你覺得爲什麼 Xamarin 發展了這麼多年結果用的最多的是用它寫 UWP，也有一些安卓，iOS 幾乎沒人用它開發。

我尋思着跨平臺 UI 框架未來也就只能通過非 native 的方式來曲線解決了，比如 electron，比如 webassembly。要 native？原生，請。

雖然我對 Flutter 的使用評價相當正面，但這個問題下很多尬吹實在很難看下去。它們就像是說「美國誕生了工業革命」一樣令人尷尬……

我們來逐條看一看，有哪些對 Flutter 自身「革命性」的讚揚屬於張冠李戴吧：

  • 「解決 reflow 問題的高效單向佈局算法」——這跟安卓裏那個「先跑一趟 measure，再跑一趟 layout」的經典操作有本質區別嗎？在安卓 View 的 measure 階段，就完全是「父節點向子節點傳佈局約束，子節點向父節點返回寬高尺寸」這麼一回事呀。
  • 「既能 JIT 又能 AOT」——別的不說，早在 2014 年，Java 在安卓上就能用 AOT 編譯的機器碼替代 JIT 了。這說法同樣明顯忽略了谷歌自己過去的技術成果，扛着紅旗反紅旗啊。
  • 「超越 React Native 的聲明式 UI」——恰恰相反，相比起 React，Flutter 的 Widget 機制是爲性能犧牲了易用性的，典型例子就是 StatefulWidget 在 API 設計上的令人困惑之處。個人認爲這地方說難聽點都快屬於抽象泄漏（Leaky Abstraction）了。因爲它沒有隱藏 build 機制的複雜性，還把下層的 Render Tree 直接通過 BuildContext 暴露給了 Widget Tree。
  • 「極強的可擴展性」——Flutter 本身完全基於 Skia 繪製，如果想嵌入一些外部的平臺 UI，在開發成本上是明顯高於帶有 Native Module 的 React Native 的。好在現在 PlatformView 得到了推廣，並且 Dart VM 也開放了動態鏈接 API，情況有所好轉，但相關的文檔和社區實踐仍然較爲匱乏。後面有機會我可能會單獨寫篇文章介紹一下後者。
  • 「能做遊戲」——雖然確實可以，但 Flutter 整個框架根本不是爲遊戲場景去優化的，大量工作都是爲了更好地渲染傳統的 UI 界面，從而實現局部刷新、渲染緩存、長列表、流式排版等能力。舉例說來，UI 場景是非常強調局部刷新的。假如某個靜態頁面中有個 GIF 在放，那麼 Flutter（以及所有的瀏覽器引擎）都能保證每幀只有那麼一小塊地方會重繪。而遊戲引擎可不會管這麼多，因爲遊戲幾乎每幀像素都不一樣，要畫下一幀的時候直接全量重繪就好。它們的優化方向一般是「如何支持大量同屏物體運動」之類，放着不動也會持續逐幀重繪，耗電量很感人的。所以「Flutter 的革命性在於能做遊戲」這種說法就像是說「杜蕾斯的革命性在於可以套在槍管上防潮」一樣，人家設計出來可不是用來讓你套在這裏的……
  • 「Dart 語言」——Dart 本身的語言特性有什麼革命性的地方嗎？去看看前一段時間推出的 10 Years of Dart 吧。這裏面負責 Dart VM 的 Vyacheslav Egorov 多次表明這就是個照着經典理論來的的工程實現（當然引擎做得好也是很不容易的）。

注意上面澄清的這些問題，其實都確實是 Flutter 自己的「特性」，但不是它原創的「革命性的特性」。在這點上相信沒什麼好繼續擡槓的吧。

但是俗話說得好，既要防止左，也要警惕右。這個問題下更離譜的是一個拿 Xamarin 來貶低 Flutter 的匿名高贊回答，踩一捧一這套玩得很熟練嘛。按羅翔老師的說法，一根手指指向別人，四根手指就指向自己。既然一定要對線，我們就來數一數 Xamarin 自己有哪些問題吧：

  • 仍然是 RN 的思路，在 iOS 和安卓上都得用 C# 寫特定於平臺的代碼，沒有利用好 C# 生態裏的 SkiaSharp 去從底到上地繪製 UI（話說 SkiaSharp 這東西是真的神奇，我對 Skia 很多用法的瞭解反倒都是在 SkiaSharp 社區查到的）。
  • 基於 XAML 的經典 MVVM 設計思想，還是十年前（Xamarin 在 2011 年推出）的產物，在 React 組件化思想普及的今天已經落後了。支持聲明式嵌套組件（Widget）的框架設計優於嚴格地把佈局和邏輯分離開（區分 XML 和 JS）的設計，這早就是前端社區的共識了。
  • 開發期的 Hot Reload 平臺限制多多，而且只支持 XAML 代碼，對 C# 業務邏輯無效，跟 Flutter 的方案不是一個量級的東西（後面會提到）。
  • C# 和 Visual Studio 不管對 iOS、安卓還是 Web 開發者都非常陌生，官方甚至從來都對自家的 VSCode 不管不顧。你看看 Flutter 可是暗渡陳倉，同時兼容了前端愛用的 VSCode 和移動端必備的 Android Studio 呢。在批判「谷歌動輒始亂終棄拋棄開發者」之前，能不能自己先照照鏡子？

如果你稍微認真看看 Xamarin 的架構圖，就能看出它其實就相當於一個 C# 版的 React Native：

如果圖不夠，這裏還摘錄了一句微軟文檔的原文：

Xamarin.Forms allows developers to create user interfaces in XAML with code-behind in C#. These user interfaces are rendered as performant native controls on each platform.

我不是說 RN 式依賴平臺控件的架構不好，它們各有所長。但光是這一點，就足以反駁匿名回答裏「Flutter 除了背靠 Google 以外一無是處毫無創新，裏頭全是 Xamarin 早就做出來的東西」這種信口開河的觀點了。

說實話，我是非常反感「Flutter 能火反映了中國程序員無腦跟風追隨 Google（的低劣民族性）」這種話術的。你看難道 Xamarin 在國外就很火嗎？

回到正題，個人認爲 Flutter 確實有這麼幾個具備很大突破的地方：

  • Flutter 真正意義上把簡化的瀏覽器引擎打到了 App 裏，徹底解決 UI 控件的兼容性問題——這和遊戲引擎的做法類似，但要知道實現「從管理 OpenGL 的紋理 Buffer 到排版複雜的的 UI 佈局再到配套應用層語言的運行時與開箱即用的工業級 UI 組件庫」這麼一大堆東西，傳統上從來都是 OS 廠商的職責，以前任何一個第三方的移動端跨平臺技術團隊，都沒有足夠的資源和技術積累來挑戰這件事（我知道的應該只有桌面端背景的 Qt 吧，但它拿 C++ 作爲業務開發語言太勸退了），只有搞瀏覽器出身的這批人敢。
  • Flutter 切實地通過 Hot Reload 解決了傳統移動端開發的效率問題。這是需要框架團隊和語言引擎團隊緊密協作，聯手投入大量工作的。如果你看過 Dart 團隊的分享，會發現他們非常關注所謂的 Development Cycle，也就是從修改完代碼到看見反饋的這個週期——這個週期必須越短越好！爲此 Dart VM 爲 Flutter 量身定做了很多重大特性，典型之處就是把解釋器的 parsing 過程拆分到 PC 端，每次修改代碼後，只增量地編譯並傳輸二進制的 AST 數據（.dill 文件）到設備上。這種重度侵入性的設計使我在嘗試「把 Dart VM 從 Flutter 裏抽出來單獨使用」的時候遇到了不小的麻煩，但好處也很明顯，那就是 Flutter 不管是 Hot Reload 還是 Hot Restart，都很難遇到那種被大型單體應用編譯速度拖累的問題，還能在 AOT 模式下具備高性能。
  • Flutter 在開發者生態上，找到了 App 團隊和前端團隊之間的雙贏點。成功的 Hybrid 架構落地，離不開兩種背景的開發者協作。而至少在我們這裏，作爲協作者的 App 團隊總體是認可並願意投入資源到這種架構的（相比之下對於很多「根紅苗正」的移動端背景技術負責人來說，RN 的性能問題和碎片化兼容問題一直有爭議，移動端團隊踩到坑很可能就想給你換回去）。而前端團隊從 JS 換到 Dart，並不會比從 Vue 換到 React 更難。不過這裏講下去肯定多少涉及一些非技術層面的問題，就不展開了。

如圖所示，爲保證極速加載的開發體驗，Flutter 拆分了經典的「詞法分析-語法分析-解釋執行」過程。它先在 PC 端編譯 Dart 源碼爲二進制 AST，將其通過 RPC 協議增量發送到設備上，動態替換掉受影響的 Library 後執行重繪，整個過程中應用的運行時狀態保持不變。當然原有狀態可能失效，這時需要 Hot Restart。

誠然，Flutter 很多地方缺乏理想中的精緻性，不少細節處的 API 都需要你繞一下然後拼起來。但這裏討論的不是某種單一的語言特性，而是工作流，是技術棧，是解決方案的投入產出比！個人感受是，作爲一套應用開發技術棧來說，Flutter（在我們的場景下）不管是 Dart 在語言特性上相比於 TS 和 Kotlin 的劣勢，還是 Widget API 的嵌套寫法相比於 JSX 的不便之處，都是相對次要的、非決定性的、可權衡接受的——當然切記這要具體問題具體分析，不是在跟你佈道啊。

哦對了，既然是在知乎，那怎麼能忘了這裏的財富密碼呢？Flutter 最大的革命性當然在於，它可是已經支持全場景分佈式微內核的鴻蒙 OS 了哦！其實說起來在安卓和 iOS 上，我都抽離搭建過 Flutter Engine 裏的 Skia 上下文初始化過程。基於我自己的經驗，個人認爲這篇介紹如何將 Flutter 移植到鴻蒙的文章，其敘述是嚴謹可靠的。全文亮點很多，特別是這一句非常有風度：

由於鴻蒙……在很多基礎概念上與 Android 有相似之處，我們可以從 Flutter 的 Android 版實現入手，完成對鴻蒙的移植。

差不多了，這篇回答的跨度有點大，最後做個總結吧：

  • Flutter 當然是具備革命性的。但誇要誇對地方，不然看起來像低級紅高級黑。如果你是工程負責人，要從系統的角度去分析評判框架，不要浮於復讀公關稿和表層 API 這種層面的東西。
  • 不要凡是見到國內流行的東西就鄙夷，這多少有點「逆向民族主義」的味道。多想想這不是世界範圍內的普遍現象，別人是不是也這樣，程度如何。
  • 當你熟悉的框架不受主流認可時，首先應該反思它爲什麼幹不過人家，爲什麼會變成冷門，而不是靠着這個小衆性來孤芳自賞地（匿名）彰顯優越感。

推薦閱讀：
相關文章