前言：不知道是幸運還是不幸，從職業生涯早期開始就常常在做各種跨平臺開發，從早期的Cordova到現在的ReactNative，從SmartTV到Android、iOS、MacOS以及Windows（還有死去的Windows Phone，我可愛的Lumia 720只能變成老年機了），雖然不敢說全部都融會貫通，但多少也累積了一些心得與想法。趁着記憶力退化忘光光之前，寫篇文章來記錄近年來跨平臺開發的發展史，順便總結一下心得，有些可能年代久遠記憶有誤或用法有更新，還請各位不吝指正。
先送上一首鄧麗君的老歌《往事只能回味》獻給大家。
從事編程那些年經歷的跨平臺開發工具框架演變歷史，你想要的都在這裏。Cordova，Xamarin，Titanium，NativeScript，React Native，Electron，uni-app，Flutter
我做了一個詳細的來龍去脈的分析以及優缺點對比，花了一個通宵整理的，喜歡的話，點個贊支持一下吧，感謝大家關注。
本文是作者AWeiLoveAndroid原創，未經允許，嚴禁轉載。更多幹貨歡迎關注公衆號【Flutter那些事】，精彩多多，別錯過哦。
Cordova & Ionic(底層使用Angular)
說到跨平臺，一般人好像都會先想到這隻小機器人.
Cordova是很早期的跨平臺解決方案，它是從更早期的PhoneGap分支出來的。在我剛開始接觸跨平臺開發的那個年代（大概2012年），它是最熱門的跨平臺解決方案。爲什麼呢？因爲它簡單好上手，而且那時候它的對手是Xamarin跟Titanium，兩者都是要付費的（這兩個後面會作介紹）。
下面看看Cordova的架構圖：
Cordova的架構很簡單，就是一個簡單的Activity（爲了避免麻煩，底下的架構都用Android的觀點來解釋，絕對不是我iOS不熟喔，只是內容有限，就做一部分解讀了），上面搭載一個CordovaWebView Component，他是一個改造過的WebView，加裝了一些Cordova API，讓你藉此和Native的部分交互。你的App基本上就是一個Mobile Web，只是多了一些跟Native交互的能力。
優點：
1.好上手：前端工程師（或Web工程師，那個年代還不是大家都聽過前端這個詞）只要知道怎麼做Mobile Web(只要會Web，然後剛好遇到了Cordova，剛好一拍即合)，就可以無痛的構建出一個跨平臺的App，Ionic入門很容易，用Web寫App簡直就是無腦操作，快得很，寫代碼就是一把梭！聽起來是不是很吸引人呢？
2.Cordova的跨平臺解決方案,尤其是ionic，已經看起來和大部分原生app一樣了。
3.Cordova有豐富的插件去銜接Native平臺(Android和iOS)，你基本上很少去管Native的交互，社區也比較完善，還是很不錯的。
4.使用Ionic可以一套代碼在安卓端、iOS端、網站端、小程序端通吃，做到了“write once, run everywhere”，開發和學習成本極低。
但是事情總是沒有想像中的美好。Cordova這種簡單明瞭的架構是個兩面刃，它也有它的缺點：
Cordova(Ionic)成也WebView，敗也WebView，使用Web性能體驗很差。雖然它開發起來很快，但是終究是個Web，也成不了Native，就好比你再怎麼打扮也成不了吳彥祖，胡歌一樣的道理。那個年代Mobile設備的硬件條件非常有限，還只是1GB RAM的時代，Mobile Web的性能體驗和Native相比起來差距非常大。比如：Android上的Web UI跟Native UI比起來差異很大，比如iOS上的高延遲，掉幀，黑屏等。相同硬體條件下，iOS 上面就沒有那麼明顯的差距，原因歸結於Android和iOS兩個平臺的底層渲染機制架構不同所產生的差異。
後來的改進方案：
Web工程師們也意識到了這個問題的嚴重性，在js或是css部分可以做一些trick來做GPU加速來改善Android上的UI體驗。其中最好的當然就是Inoic了。PS：那個年代我買了第一臺小米手機，體驗一下什麼是：“爲發燒而生”，那個年代小米那個配置確實很牛逼啊（純粹爲了懷舊）。那個年代也是智能手機快速發展的時候，當然隨着而來的就是各種Mobile Web框架了，比如：JQuery Mobile、Bootstrap等等，還有各大廠推出的開源框架和工具，當然還有一些叫不出名字的。Inoic雖然推出的晚一些，不過也算是“長江後浪推前浪”，也算是不錯的了。最新的ionic4控件做的相當完美，爲了一些十分微小的UX細節不斷的改進。另外Ionic4好像有想要解決一些性能問題，推出了一個capacitor的工具，Ionic team是想做一個工具來優化web-based的跨平臺開發體驗。但是Cordova的性能部分（特別是渲染效能）基本上Ionic team這邊應該是不太能做什麼大的改進的，因爲框架就是那樣設計的。或許在js或是css部分可以做一些trick來做加速（他們也確實花了很多工在這上面），但是整體的性能還是依賴於平臺上的WebView。之前有人提出把Cordova webview替換成Chromium，雖然會造成app體積臃腫，不過也在一定程度上提升了性能。當然功能是滿足不了需求的，也可以通過原生插件來進行修補。
【Phonegap、Ionic、Angular和Cordova的區別和聯繫】：
很多人都搞不清楚的問題，在這裏我也幫大家解答一下：Phonegap、Ionic、Angular和Cordova的究竟有什麼區別和聯繫？
Phonegap原本由Nitobi公司開發的，現在由Adobe擁有，它是一個使用HTML、Javascript、CSS等Web API開發跨平臺的移動應用程序的框架。
2011年，Adobe/Nitobi把PhoneGap的源代碼貢獻給Apache軟件基金會（ASF）託管，後來社區將這份開源的代碼取名位：“Cordova”。PhoneGap是Apache Cordova的一個分支。你可以這樣想，Apache Cordova是一臺發動機，運行在PhoneGap上，就像WebKit瀏覽器引擎運行在Chrome瀏覽器和Safari瀏覽器上。
Ionic 是一個全堆棧的混合應用開發框架， Ionic = Cordova + Angular + Ionic UI，Ionic主要功能是負責頁面的實現。
Angular 是一個JavaScript的前端框架。
Cordova提供了一組原生設備相關的API，通過這些API可以使用JavaScript訪問原生的設備功能，如攝像頭、麥克風等。同時Cordova負責將實現的頁面包裝成原生應用（Android是apk的形式；iOS是ipa的形式）。
簡單的打個比方吧：就像你吃柚子一樣，最內層的柚子瓤是Angular，柚子瓤外面的一層皮就是Ionic，而最外層的厚厚的柚子皮就是Cordova。
在那個年代Cordova風風火火了一陣子，但是在在架構及硬體環境下呈現出來的視覺表現，不太樂觀，遠遠比不上原生平臺的體驗，所以給人一種“跨平臺=效果差勁”的錯覺。後來其他的跨平臺推出時的時候，很多開發者都會說：“我之前使用Cordova，那個體驗太差了，我寧願原生的做，也不做跨平臺了”，所以說成了WebView，敗也WebView，樹大招風，Cordova招你惹你了，居然躺槍，看來火起來了在哪裏都被提起，躲都躲不過啊。
Xamarin
接下來登場的是C#家族的框架“Xamarin”了。
Xamarin跟Cordova差不多是同一個時期的產物，它在被微軟收購之前，就已經是小有名氣的跨平臺框架了，不過跟開源的Cordova不同，Xamarin當時是需要收費的，這也可能是它的名氣不如Cordova的原因吧。另一個Xamarin沒有紅起來的原因是：它使用C#當主導開發語言。
PS：我不是針對C#,不是說它不好，我也用過C#寫過程序，很像Java語言的。當年就是借鑑Java語言出道的（Java：你C#可以模仿我的臉，你不能模仿我的靈魂）。在.NET Core還沒出現之前,C#家族的產物都是相對的比較封閉的，開源的資源比較少，相比當時的慢慢火起來的Javascript來說，簡直是太少了，這就造成了Xmamrin先天上的劣勢。
Xamarin android端架構圖：
Xamarin iOS端架構圖：
從圖中可以看出Xamarin比Cordova複雜多了，有一組完整的Android & Java binding，還有一個跨平臺的.NET runtime — Mono。Xamarin大致上分成幾個部分：Xamarin.Android、Xamarin.iOS、Xamarin.Mac（後來纔出現的）以及Xamarin.Forms。
感興趣的可以看看官網介紹：https://dotnet.microsoft.com/apps/xamarin
這裏我又要來順便科普一下，Xamarin和Cordova都出現過改名風波，肯定有人會問的Xamarin的幾個框架之間的關係：
【.NET Framework、.NET Core、Mono、Xamarin之間的區別和聯繫】：
.NET Framework:微軟2002年2月發佈第一個版本，只支持在Windows平臺上開發和運行（重點圈起來：閉源，商業化）。
Mono：Mono是一個開源框架，它是第三方公司Ximian發佈的，最早在2004年6月發佈了Mono 1.0版本，支持在Linux、Windows、Unix、Android等平臺。（野生版的.NET Framework開源實現）
.NET Core：微軟在2014年將.NET Core開源，2016年6月發佈其實現.NET Core 1.0。內容包括跨平臺虛擬機CoreCLR、.NET Framework APIs的實現子集以及新增類庫等。（重點：開源，基於.NET Framework新增一些類庫）
Xamarin：Xamarin的前身是Mono，Mono項目幾經轉手，2011年落入Xamarin公司手中，2016年2月，微軟正式收購Xamarin。支持包括Windows、Linux、macOS、iOS、Android在內的各種主流平臺和操作系統。
爲了更好地說明這個問題，借鑑網友的一張圖表示：
此圖片來源於博主：https://www.cnblogs.com/wer-ltm/p/8776846.html
最後來看看優點：
1.使用C＃編寫代碼，可以重複利用多達96％的源代碼加快工程週期。同時Xamarin使維護和更新變得更加簡單。
2.性能接近原生。它的性能損耗比起Cordova少的多。Cordova必須承擔Web Rendering所帶來的巨大損耗，但Xamarin只有跨語言層面的損耗而已，相較起來相當輕微，這也是它在視覺渲染上帶來的優勢。比如：使用Xamarin.Forms工具構建，該工具可在應用程序運行時將應用程序UI組件轉換爲平臺特定的界面元素。
3.豐富內置功能。Xamarin組件提供了數千個自定義UI控件，各種圖表，圖形，主題和其他強大的功能，可以僅添加到應用程序中點擊次數很少。這包括內置支付處理（如Stripe），信標和可穿戴設備集成，開箱即用推送通知服務，雲存儲解決方案，多媒體串流功能等等
再來看看缺點：
1.與第三方庫和工具的兼容性問題：以前是新的Native API必須等待官方的封裝才能使用，不過現在Xamarin也開源了，但是還是比較慢。另外，儘管Xamarin擁有自己的組件商店，但您可能需要在您的應用中需要特定的功能或整合，而這些平臺並未提供這些功能或整合，所以這一點就很蛋疼了。有些網友也給我反饋過：android和iOS的一些交互細節也會不太好。
2.對原生平臺的最新更新的支持不會很及時。這完全取決於Xamarin開發團隊，這些更改和/或引入新的插件等需要一些時間，儘管Xamarin聲稱提供當天的支持，但仍然可能有些延誤。
2.Xamarin開源生態系統問題。Xamarin社區比iOS或Android的小得多。因此，找到一個有經驗的Xamarin開發人員可能是一個挑戰。
4.應用程序比較大。Xamarin應用程序通常比Native應用程序大，比如：Android的一個簡單的“hello，world”應用程序最多可能需要16 MB。
5.不適用於重圖形應用程序。在Xamarin中構建遊戲，豐富的自定義用戶界面或複雜的動畫變有很大的限制。
6.使用MvvmCross(https://www.mvvmcross.com/)，需要做兩套界面，android性能有所提高，但佔用資源少，第三方的庫轉換麻煩。MvvmCross是專門爲Xamarin和移動生態系統開發的框架。它支持Xamarin.iOS，Xamarin.Android，Xamarin.Mac，Xamarin.Forms，通用Windows平臺（UWP）和Windows Presentation Framework（WPF）。
Titanium
Titanium的logo就是下面這個：
對不起，我跟這個不熟，只記得當初也是要收費的，然後走的是JS to Native Binding的形式，可是聽說雷超級多，就沒有去踩了，如果有曾經用過的朋友們，可以來聊聊你的體驗。我以外的發現了github有開源代碼，難道現在開始開源了？github代碼如下所示：
https://github.com/appcelerator/titanium_mobile
以下優缺點總結來源於博客：
https://devblog.axway.com/mobile-apps/comparing-titanium-and-phonegap/
優點：
1.直接調用原生平臺特性和功能，無需其他的工具。Titanium的目的是爲跨平臺的原生移動開發提供一種更高級的API，所以你可以直接訪問一系列廣泛的原生特性和功能，從用戶界面組件、插座接口到通知系統集成。Titanium的目的是，將Titanium應用程序和純原生應用程序之間在功能方面的差異縮小到幾乎爲零。
2.集成和擴展很方便。由於Titanium可以用插入到與應用程序其餘部分一樣的視圖層次體系的可視組件來擴展，你最終能夠在底層原生平臺上實現任何可能的用戶界面。需要使用特殊的原生代碼，讓表格視圖（TableView）以60fps的速度滾動？你能做到這一點。想無縫地集成遊戲的OpenGL繪製曲面，同時用JavaScript保留運行循環的邏輯？你能做到這一點。你可以把這些用戶界面擴展直接集成到用核心Titanium API編寫的應用程序中。
3.接近原生體驗。使用常用的用戶界面窗口組件時，Titanium應用程序的外觀和感覺也是這種平臺的一個優點。不用進行可視仿真（或通過應用CSS，或者使用OpenGL或Flash渲染用戶界面窗口組件）。當你創建NavigationGroup時，它得到iOS上的實際UINavigationController的支持。動畫和行爲與原生應用程序用戶預期的相一致，因爲你使用同樣的用戶界面控件。
4.入手門檻低。由於Titanium通過JavaScript提供了一種高級的原生編程API，爲用過基於ECMAScript的語言的任何人大大降低了原生編程方面的准入門檻。
缺點：
1.Titanium API的範圍使得添加新平臺有難度。在一種新的原生平臺上實現Titanium API是項艱鉅任務。正由於如此，Titanium平臺只出現在目前被認爲最重要的移動平臺上：iOS、Android和Web。
2.移動Web瀏覽器支持還沒有達到可以投放市場的質量。Titanium在繼續致力於改進我們的用戶界面窗口組件集的性能和感覺上，同時完善核心Titanium API的實現。
3.由於Titanium提供的抽象層很龐大Titanium的內部框架仍存在API實現未達到最佳標準的問題。在一些情況下，一些用戶界面組件還無法做到性能與原生用戶界面組件一樣好，比如佈局高度定製化的非常龐大的表格視圖。優化核心的用戶界面組件對Titanium團隊來說仍是首要的技術任務。
4.另外由於Titanium平臺的宏偉目標，擴展Titanium並非易事。想有效地集成一種新的原生控件或API，深入瞭解Titanium的架構和環境必不可少。開發者體驗、API文檔和麪向模塊開發者的總體指南。
NativeScript
NativeScript是Telerik（做過Kendo UI）推出的，後來轉成開源的形式。他們的想法跟Titanium類似，都是想做JS跟Native之間的binding，而他們採用的是反射（reflection）的形式，NativeScript並不是直接用Java的反射去動態查找API，因爲性能不哈，他會預先生成一個Metadata在apk裏，用於查找和匹配mapping。
優點：
1.用映射的方式達到了極大的擴展性。NativeScript把Android / iOS上的API都映射到NativeScript runtime裏，讓開發者可以直接以Javascript調用這些native API，類似於V8引擎的原理。
這種做法給NativeScript帶來超級強大的擴展性，因爲你可以使用“任何”原生app可以使用的api，包括第三方lib，而且不需要做額外的處理；當平臺有API變更時，所有的變更也都可以馬上被使用（除非反射機制在更新中被破壞了），這個不像Xamarin那樣需要等待團隊去做更新。從這一點上看，還是有一點優勢的。
2.NativeScript在View上也做得不錯，UI上也跟現代的Angular / Vue做結合，帶來了很高的開發效率。除了原生的組件之外，他還提供了一個CSS subset作爲styling使用，這讓它在UI開發上比Native app更加方便。NativeScript一開始是使用Angular來做UI，不過後來他們分離出了三種開發方式：基本的js/ts、Angular、Vue（這就是爲什麼我沒打算研究Weex的原因），而且三種方式都可以享受到data-binding的爽感。
3.NativeScript還有一個很大的優點，它把TypeScript當成一等語言（NativeScript本身也是用TypeScript寫成的）。不過想想這也是理所當然，畢竟在使用反射機制的情況下，如果沒有TypeScript輔助，光是API 反射就會搞死人（沒接觸過TypeScript的朋友，就試想一下用記事本寫Java的感覺吧，哈哈。。。）
缺點：
1.開發者要有一定程度的Native知識。因爲NativeScript runtime是基於v8/JavaScriptCore，而不是Webkit，所以你沒有辦法使用任何的WebAPI（除非有人幫你實現）。舉例來說，常見的XmlHttpRequest或fetch是屬於Webkit這層的實現，在NativeScript裏就需要使用native平臺上的實現來做封裝，這也加重了開發者對於Native相關知識的依賴。
2.它之所以沒有紅，主要的原因是出現的時間點有點差。NativeScript剛推出沒幾個月，還來不及成熟的時候，React Native就夾帶着React社羣的超人氣橫空出世了。如果它能夠早一點出現，也許現今的版圖分佈會不太一樣了。
網友對 NativeScript 的評價：
如果本身是走Angular陣營的話，NativeScript是一個相當值得嘗試的東西。
Election
Electron：PC跨平臺。
Electron的前身叫做Atom-Shell，本來是GitHub發佈開源編輯器Atom時一併發佈的副產物，但是後來這個副產物的影響力遠遠的超過了Atom editor本身，於是便改名爲一個獨立專案，也就是現在的Electron。Electron的本質很簡單，就是Chromium+Node.js的組合，兩者之間透過ipc通訊。
優點：
1.Electron至今已經很成熟了，開發Electron app對js有一定水平的工程師而言就跟喝開水一樣簡單，前端是一個完整的Web環境，而且還是兼容性高、走在時代前端的Chromium，可以使用各種先進的語法以及WebAPI；而後端是Node.js，而且版本也相當高。
2.Electron也不需要擔心跟平臺的互動性不足，得利於豐沛的Node.js生態圈，大部分你需要的功能都可以找到模塊，而像自動更新跟打包發佈這些大多數App都需要的東西， Electron跟他的生態圈也都幫你搞定了。就如同官網的標語，Electron幫你處理了許多瑣事，你只要專心在覈心功能的開發上就好了。
缺點：
1.臃腫。你必須把完整的Chromium帶進去，所以最小的HellowWord壓縮起來也要幾十mb，不過這其實對桌面軟體而言不成問題。
2.消耗內存、以及啓動時間問題。因爲前端用的是Chromium的關係，Electron在內存消耗上一直爲人所詬病，基本上開起來就吃個1xx mb內存是很正常的事，應用複雜度高的話數字也會猛烈攀升。Electron團隊應該是無能爲力，只能看Chromium未來能不能改善這個問題了。同樣的，Electron在啓動時間問題上Electron團隊應該是無能爲力，只能看Chromium未來能不能改善這個問題了，Chromium的啓動時間會成爲一個瓶頸。
【小結】如果要開發一個桌面爲主的跨平臺app，那Electron可以說是當仁不讓的首選。不論是整體的成熟度、社羣的熱門程度、可用的資源、旗艦級的showcase，從各方面來看都令人安心。
uni-app(底層使用Vue)
後來朋友推薦使用HBuilder工具（後來升級爲HBuilderX），開發很方便，然後我就去HBuilder工具官網搜索了一下，發現了一個叫做uni-app的框架，uni-app是一個使用Vue.js開發所有前端應用的框架，開發者編寫一套代碼，可發佈到iOS，Android，H5，以及各種小程序（微信/支付寶/百度/頭條/ QQ /釘釘）等多個平臺，簡直就是Web極致跨端口的工具（算不上真正意義的跨平臺，但是比前面的Cordova感覺要厲害一些，畢竟多吃了紀幾年飯，研究出來的東西就是不一樣啊。。。O(∩_∩)O哈哈~）。可以說uni-app是懶人必備吧，它使用Vue.js編寫你的業務代碼。
先來說說它的優點：
1.使用HBuilderX工具開發，一鍵創建項目模板，快捷方便，HBuilderX和uni-app都是同一家公司推出的，該公司還有其他一些框架，都可以使用HBuilderX創建你要的項目類型以及編寫你的代碼。
2.uni-app對前端開發人員比較友好，封裝的組件和微信小程序的組件一毛一樣，熟悉小程序的朋友應該會覺得很不錯。
3.uni-app拓展能力強，封裝了H5+,支持nvue，也支持原生Android，ios開發。可以將原有的移動應用和H5應用改成uni-app應用。uni-app的App端，內置一個完整小程序引擎，並補充了可選的weex引擎給對性能要求更高的開發者。這也是uni-app在App端能夠正常運行微信小程序代碼的原因。其他Web跨平臺框架做不到這點。
再說說它的缺點：
1.使用Vue開發，你必須要熟悉h5，vue，小程序，學習成本很高。如果不熟悉這些話，需要花時間學習新框架，比如小程序、Vue都要學習。
2.uni-app問世的時間還比較短，移動端平臺的兼容性有很多地方還不是完善，坑很多，在Android平臺上表現較微信小程序和iOS上差，需要完善。
3.性能還是一個問題。畢竟uni-app底層使用的js，就算能夠編譯成原生程序，那個性能和兼容性方面也是個問題，如果只是做Web還行，小程序什麼的還算出色。
React Native(底層使用React)
小弟算是第一批把React Native用在生產環境上的人（當時是0.0.3版，第一個public版，想想我當時膽子還真大）。
ReactNative沒有像NativeScript一樣做反射，而是建構了一組RCTBridge，用來做js跟native之間的交互，要使用native API或native 組件的話都要在native層做橋接，然後導入到js裏面（類似你寫Node的C++ addon的感覺）。
優點：
1.ReactNative能有今天的反響，很大一部分是得利於React生態圈的整體發展優勢，以及有Facebook已經在他們的app上做過產品實踐，這對很多人而言是一劑強心針，再加上諸如Airbnb，Uber等大型公司也紛紛採用，更造成了推波助瀾的效果。
2.打出來的包會比NativeScript的小，架構實現上也比較單純。因爲ReactNative沒有像NativeScript一樣做反射，而是建構了一組RCTBridge，用來做js跟native之間的交互，所以打出來的包會比NativeScript的小，架構實現上也比較單純。
3.ReactNative當初出現時打的口號是“learn once, write everywhere”，讓不同平臺上保有不同的平臺特性。這個中心思想所帶來的架構設計，讓ReactNative可以很輕易的擴展到其他平臺上，例如第三方開發者實現的react-native-macos、react-native-appletv（後來被整合進官方里）、微軟官方開發的react-native-windows（原名是uwp）、Samsung官方的react-native-tizen，幾乎可以說所有平臺上都可以看到ReactNative的影子，具體是否成熟有待研究。
缺點：
1.ReactNative目前其實還不算是在一個穩定的狀態，他們每兩週都會更新一次，這也是開發時要注意的一點。
2.你必須擁有native platform相關的知識。應該說，自從Cordova之後的主流跨平臺方案都會要求要具備一定程度的平臺原生相關知識。雖然說比起NativeScript，ReactNative在沒有任何的原生知識的情況下也是可以編譯打包生成一個可用的app，但是這會大大的限縮了你的可擴展性，而且在不瞭解原生的渲染以及運作方式的情況下，可能會不小心讓CPU發燙成了定時炸彈。
3.每個native module都要自己橋接一次，非常麻煩。
Weex(底層使用Vue)
weex資料太少了，我就不做介紹了，反正我是踩過坑的，後來放棄weex了，文檔不齊全，API缺少，擴展功能不完善，性能也好不到哪裏。。。
Flutter
Flutter是谷歌推出的一個全新的高性能高一致性的跨平臺的開發框架。
【優點：】
1.你只需要使用Dart語言寫一套代碼，即可自動編譯到各個平臺，目前支持Android,iOS,Web(Beta)，Desktop(Alpha)，當然也有Windows PC和linux平臺的兼容支持官方正在研發中。所以你完全不用擔心框架內部是如何幫你實現的。你只需要一個命令行就可以在對應平臺運行你的代碼了，比如：flutter run xxx，這裏的xxx指的是你的平臺設備名稱，比如“flutter run chrome"表示將程序運行在瀏覽器上面。
2.獨立的Skia渲染引擎，高性能高一致性。你的代碼編譯出來的程序可以達到60bps的高性能。
3.豐富的組件支持，你完全可以按照你的想法去做，擴展性非常強大，MD風格的，以及ios風格的組件都有，足夠滿足平時開發需求。而且Flutter基於react以及flex的思想進行佈局。
4.豐富的社區支持。目前常用的組件以及一些第三方包都有大佬開源出來了，足夠應對平時的開發了。如果你不清楚的話，也沒關係，我特意收集了Flutter工具集合，這裏面啥都有，足夠讓你可以快速找到你要的東西，你可以點進來看看：https://github.com/AweiLoveAndroid/Flutter-learning/
5.開源免費的。你可以隨意修改內核引擎代碼，以及組件代碼，定製化的開發，比如閒魚，騰訊，字節跳動等大廠都基於Flutter進行鍼對他們的App開發做了定製化的整合方案，當然你要是感興趣的話，你也可以這麼做。
6.使用Dart語言進行開發。Dart語法很像JS+Java+Swift+Kotlin+C#+TypeScript+JavaScript+PHP，雖然表面上沒有使用web開發，但是你完全不用擔心，你仍然可以進行開發，只是語言寫法不一樣，但是這裏面很多都是熟悉的東西，基本上上手成本也是很低的。
【缺點：】
如果不熟悉原生開發，第三方包滿足不了你的需求的時候，那麼就需要你自己去寫或修改已有的插件，這個需要學習一點原生開發的知識（其實這也是很多跨平臺技術必不可少的步驟），當然如果你們公司有android或ios的程序員，可以讓他們協助寫一個插件，這對於他們來說都是小問題。
網友對 Flutter 的評價：
Flutter是Google的親兒子，目前最火爆的跨平臺框架，也是跨平臺框架中最接近原生的一種框架，也是效率最高的。目前應用在移動端(安卓端，iOS端)，Web也發佈了預覽版，但是還無法真正放在小程序或者Web項目中實戰。目前來看，Web上面還是無法真正的替代ionic框架。雖然脫離了JS強大的社區,但是這一年多以來Dart語言社區也在逐漸長大，pub.dev上面各種Flutter和Dart的開源庫和工具都有，開發項目起來還是不錯的，只是Flutter Web發展還不夠完善，很多Web的一些包一級瀏覽器的功能還不完善。
網友對 Flutter 的評價：
我是做前端的，我朋友是移動端的，他走的Flutter路線，他是做安卓開發的，用的java，他說Flutter接近原生體驗，非常好。而我們公司需要快速上線，還是走的是WebView的路線，我和他同時做一個小Demo出來對比了一下，發現App的性能體驗真的很大，排序如下：原生 >= Flutter > WebView。
最後來提幾個問題？
1.跨平臺最難的就是各平臺之間的差異性這個問題如何解決？
2.Cordova 和 RN, NativeScript 有什麼不同呢?
