Google不喜歡MPEG，於是推出了VP8。但打一開始他們就沒在將其打造成一個真正的開放標準上做任何努力。
Google不喜歡HTTP，於是推出了SPDY。但現在只有Chrome和Google的網頁應用支持，目前也沒有任何跡象能成進入標準組織。你可以想象微軟的IE自己鼓搗了一套HTTP標準然後只和微軟自己的IIS服務通訊嗎?
Google不喜歡所有非IE瀏覽器的NPAPI插件模型，於是推出了完全不兼容的插件API和原生代碼的Native Client
Google不喜歡JPG和PNG，於是推出了WebP圖形格式
google不喜歡原生Android 和 Ios，於是退出了Flutter
而現在Google又開始不喜歡Javascript了，於是推出了Dart
估計接下來Google還會不喜歡CSS甚至是HTML。
很多前端開發者應該都尋找過跨平臺的App解決方案，包括沒有同時獨立開發iOS和Android雙端原生app的開發者，應該都接觸過或者看到過Google的Flutter框架。我對於iOS原生開發與基於Vue.js的web開發比較熟悉，並在一個正在進行的藍牙硬件項目中應用了Flutter框架，經歷的漫長的適應，在本文中我將以iOS原生開發者與web開發者的視角看待Flutter框架，簡單羅列Flutter的優勢與缺點。
Flutter優點
Flutter的優點非常明顯，如果你選擇一個跨平臺框架，與衆多基於html的跨平臺框架相比，Flutter絕對是體驗最好，性能與構建思路幾乎最接近原生開發的框架。
-
性能強大，流暢
Flutter對比weex和react native相比，性能的強大是有目共睹的。基於dom樹渲染原生組件，很難與直接在原生視圖上繪圖比肩性能，Google作爲一個輪子大廠，直接在兩個平臺上重寫了各自的UIKit，對接到平臺底層，減少UI層的多層轉換，UI性能可以比肩原生，這個優勢在滑動和播放動畫時尤爲明顯。 -
路由設計優秀
Flutter的路由傳值非常方便，push一個路由，會返回一個Future對象（也就是Promise對象），使用await或者.then就可以在目標路由pop，回到當前頁面時收到返回值。這個反向傳值的設計基本是甩了微信小程序一條街了。彈出dialog等一些操作也是使用的路由方法，幾乎不用擔心出現傳值困難 -
單例模式
Flutter支持單例模式，單例模式的實現也非常簡單。單例模式很好的解決了一些問題。相比之下，js的單例則並不是一個真正的單例，或者說不是一個簡單的單例，這也是受限於js所運行的環境。單例模式並不總是合理的，容易被濫用。但是在App的初期開發中，往往一個容易實現的單例可以幫助我們快速完成一些邏輯的搭建。 -
優秀的動畫設計
Flutter的動畫簡單到不可思議，動畫對象會根據屏幕刷新率每秒產生很多個（一般是60個）浮點數，只需要將一個組件屬性通過補間（Tween）關聯到動畫對象上，Flutter會確保在每一幀渲染正確的組件，從而形成連貫的動畫。這種十分暴力的操作在Flutter上卻看不到明顯的卡頓，這也是Flutter的一個魔力所在。相比之下其他跨平臺框架幾乎不能設計動畫……往往會遭遇非常嚴重的性能問題。 -
UI跨平臺穩定
Google直接在兩個平臺上在底層重寫了UIKit，不依賴於Css等外部解釋器，幾乎不存在UI表達不理想，渲染不正常的情況，可以獲得非常穩定的UI表達效果。Css換個瀏覽器就有不同的表現，基於Css的跨平臺框架很難獲得穩定的UI表現。 -
可選靜態的語言，語言特性優秀
Dart是一個靜態語言，這也是相對於js的一個優勢。Dart可以被編譯成js，但是看起來更像java。靜態語言可以避免錯誤，獲得更多的編輯器提示詞，極大的增加可維護性。很多js庫也已經用ts重寫了，Vue3.0的底層也將全部使用ts編寫，靜態語言的優勢不言而喻。
Flutter缺點
-
假裝跨平臺，躲不開原生代碼
這是最大的問題，跨平臺框架說白了就是UI跨平臺，最後還是在原生平臺運行，本來兩個平臺就有天壤之別，一套代碼就想吃掉iOS和Android在實際應用之中其實根本就不現實。Flutter具有與原生代碼互相調用的能力固然非常科學，但是問題反而顯得更加明顯——我一個前端工程師上哪裏去知道什麼是UIViewController，什麼是Activity呢？我要是雙端都熟悉，學習Flutter就顯得很沒有必要。這是一個很矛盾的點，特別是在團隊裏，只有幾個前端突然想學Flutter，是絕對做不來大項目的，如果有原生開發者，那就沒必要搞Flutter了。 -
組合而不是繼承的思路
Flutter提倡“組合”，而不是“繼承”。在iOS開發中，我們經常會繼承UIView，重寫UIView的某個生命週期函數，再添加一些方法和屬性，來完成一個自定義的View。但是在Flutter中這些都是不可能的——屬性都是final的，例如你繼承了了一個Container，你是不能在它的生命週期中修改他的屬性的。你始終需要嵌套組合幾種Widget，例如Row，Container，ListView等Widget。這種方法非常不符合直覺，初學時很難想明白如何構建一個完整的組件。 -
Widget的類型難以選擇
Flutter的Widget分爲StatefulWidget和StatelessWidget兩種，一種是帶狀態的一種是不帶狀態的，剛開發的時候很難想明白用哪個，因爲StatelessWidget也能存值，其實區別就在於框架重構UI的時候會使用State來重構，如果是StatelessWidget，暫時存進去的值就沒了。但是問題遠不止這麼簡單，好在只是有點麻煩，並不影響產品性能。 -
糟糕的UI控件API
雖然google儘可能的讓我們通過構造函數定製化Widget，但是也難免有遺漏的。例如，又一次我想修改一個Appbar的高度，居然沒有找到關於高度的屬性，通過閱讀源碼發現，高度是寫死（const）的。上文已經說過，無法通過生命週期來改變組件屬性，自己寫Appbar顯得非常沒必要，畢竟我還是想使用Appbar的各種方便的功能。最後我只能把他的源碼全部複製出來，直接修改高度來使用。初學框架，和一些初級開發者是不可能有迅速閱讀源碼的能力的（作爲框架也不應該產生如此問題）。一些定製化的UI的Api設計經常有缺失，好在我已經基本習慣了。除了Appbar這種複雜的組件，自己寫一個小組件也並不費事。 -
糟糕的資源管理設計
這裏是最蠢的，Flutter支持動態加載不同分辨率的圖片，但是目錄設計太鬼畜了。簡單的說，Sketch導出的多分辨率資源，幾乎不可能直接拖到Flutter裏用，極其，極其，麻煩。 -
牆
畢竟國情在此，要用Flutter，先買梯子。雖然有“在中國使用Flutter”指南，但是太麻煩，沒梯子開發Flutter，難度係數太高了，總不能碰到每個問題都花一整天尋找替代方案吧，先買好梯子圖個安心……
總結
Flutter主要的坑就在於需要非常瞭解原生的環境，其實跨平臺的框架都是如此，想要通過跨平臺的API就拿下雙端的開發任務，對認真學習的原生開發者來說也是不公平的。
主要的優勢則在於動畫流暢，很多開發者反應比原生安卓還流暢（存疑），至少在iOS上是看不到卡頓的，安卓上動畫也很穩定，性能上展示了Google的硬實力
作者：馬嘉倫
鏈接：https://www.jianshu.com/p/c51fc925bfd1
來源：簡書
簡書著作權歸作者所有，任何形式的轉載都請聯繫作者獲得授權並註明出處。