移動跨平臺開發框架解析與選型

簡介

在當前移動端跨平臺框架漫天飛的狀況下，不少開發者不知道該選擇哪一種框架來進行開發，哪一種框架適合後期維護、穩定性等問題。本文會帶你們瞭解目前市場上比較流行的一些框架的對比

移動跨平臺開發介紹

傳統移動端開發

現階段，當前市面上的手機無非蘋果和安卓，兩大操做系統能夠說各分天下，傳統的app的開發就是指原生開發，須要ios工程師和安卓工程師各自進行，ios開發一份，安卓開發一份，安卓使用的是JAVA或者是Kotlin，ios使用的是Objective-C或者是SWIFT，這種開發模式也是最多見的開發模式，從智能手機誕生到今天，一直是最主流的開發模式。

Android	Ios
JAVA / Kotlin	Objective-C / SWIFT

傳統移動端開發優缺點

優勢	缺點
速度快、性能高、穩定性強、用戶體驗好	前期開發費用高
能夠訪問手機全部功能	開發效率偏低
支持大量圖形和動畫	後期維護繁瑣
可離線使用	上線時間沒法固定

跨平臺技術的誕生

早在2010年，當時從事 Android 和 iOS 開發的人不多，也不火，全部人都在 「摸着河底過河」，項目更沒有第三方框架一說，大都是本身寫的，不像如今各類的框架滿天飛。隨着移動開發的發展，互聯網公司也是層出不窮，有些公司迫於競爭，想要更快速的更省成本的進行開發，就再也不知足 Android 端一套代碼，iOS 端一套代碼。同時，其餘技術領域和各大公司也都各自推出相關的技術，這樣跨平臺技術隨之誕生，而且開始在公司中生根發芽。
由於Android 和 iOS 生態很大，咱們能夠把它們比做第一級生態，也有廠商想要顛覆這兩個系統，但都失敗了，所以創建次級生態纔是最穩妥的策略，Android 平臺更加開放，所以創建次級生態的中心就是 Android，次生態的形式多種多樣，好比在 Android 系統的基礎上魔改創建本身的生態，再或者推出各類跨平臺技術創建生態。跨平臺技術產生的框架實在太多了，不少還沒等咱們去學去了解，它們就沒落了，也就成爲了跨平臺技術發展的一個過分產物。

移動跨平臺開發演進

爲何要跨平臺開發？

做爲開發不一樣應用而使用不一樣的開發語言，對開發者而言並非一個好事。本質上，跨平臺開發是爲了增長代碼複用，減小開發者對多個平臺差別適配的工做量，下降開發成本，提升業務專一的同時，提供比web更好的體驗，跨平臺開發正是解決了這一問題。

跨平臺開發的優缺點

因爲跨平臺技術須要依賴各類框架，各框架品質也參差不齊，老框架就不說了，新框架教程少、開發時遇到的坑多，有的能填上，有的填不上。這就須要框架背後的大廠和社區的支持了。

優勢	缺點
節省人力、開發成本	性能低於原生
節省開發時間	用戶體驗低於原生
多端的一致性	包體積變大
易上手	跨平臺框架自身bug、缺陷

移動跨平臺開發框架解析

跨平臺技術演進

WebApp

Web App 是指基於 Web 的應用，運行於網絡和標準瀏覽器上，至關於一個網頁而後加一個 App 的殼。2014 年 HTML5 的標準規範制定完成，記得當時在網絡上 Web App 大有取代 Native App 的氣勢，但 Web App 有如下缺點，使得它始終是 「主角的心，配角的命」

• 性能低，操做體驗很差
• 沒法調用原生 API，不少功能沒法實現，
• 依賴於網絡，網速慢時體驗不好，而且沒有離線功能，優化很差的話會消耗流量
• 只能作爲一個臨時的入口，用戶留存率低

在 Web App 的基礎上，又出現了幾個進化者，好比PWA。

WebApp——PWA（Progressive Web App，漸進式加強 Web 應用）

PWA（Progressive Web App）意爲漸進式加強 Web 應用，它不是一門技術，而是一個概念，他的意思就是使用多種技術來加強 Web App 的功能

總結起來，PWA 的主要的能力就是離線、推送、桌面訪問，能夠說 PWA 賦予 Web App 原生的體驗，可是 PWA 一直不溫不火的緣由主要有如下幾點：

• 用 Service Worker + HTTPS +Cache Api + indexedDB 等一系列 web 技術實現離線加載和緩存
• 實現了推送和通知
• 能夠直接添加到手機的桌面上
• 使用 Service Worker 能夠進行後臺同步
• 遊覽器對 PWA 技術支持還不夠全面， 不是每一款遊覽器都能 100% 的支持 PWA
• 國內一些手機廠商對 Android 系統各類魔改，對 PWA 的兼容性很差，甚至不支持 PWA
• 平臺的競爭，iOS 對 PWA 的支持力度遠遠低於 Android，因此 PWA 在 iOS 上的體驗打了折扣。PWA 面對相似的微信小程序和快應用的競爭中，並無優點。

Hybrid App

• 原生 App 的架構圖

• Hybrid App 的架構圖

除了採用原生和 Web 開發 App，還能夠採用 HTML5 + 原生來進行混合開發，這就是 Hybrid。

混合開發也比較好理解，就是H5與原生開發的結合，主要是用js和原生技術相互調用，能夠初步實現跨平臺使用的效果，如今咱們平常使用當中有不少App都是經過這種方式實現的。

關於 Hybrid 的誕生有一個小故事，某個二線互聯網公司的 App 是以原生爲主，HTML5 開發打醬油，隨着應用愈來愈複雜，終於有一天發現原生有一個方法最大數限制，一些頁面須要內嵌 HTML5 的頁面，因而原生和 HTML5 團隊一塊兒作了第一個 Hybrid 項目，這一套代碼兼容三端而且效率很高，所以 Hybrid App 就成了這個公司的主流，業界其餘的公司也都紛紛效仿。

經過原生 SDK 提供的 API，App 能夠與系統底層通訊，以建立 UI 組件或訪問系統服務。這些組件被渲染到手機屏幕，屏幕產生的相應的事件會被傳回給組件。由於每一個平臺的系統組件是不一樣的，你須要爲每一個平臺開發單獨的 App，而 Hybrid App 沒必要這樣，Hybrid App 的原生 UI 組件用來展現交互複雜和渲染要求高的界面，其餘的能夠交給 HTML5 來展現。
Hybrid App 雖然開發效率高，能夠跨平臺，可是 Hybrid 體驗比不上原生，對於須要快速試錯、快速佔領市場的團隊來講，Hybrid App 是一個不錯的選擇，後期團隊穩定下來後，最好仍是要作體驗更好的原生 APP 或者使用其餘體驗更好的跨平臺技術。

Hybrid 相關的技術有不少，好比 PhoneGap、Cordova、Ionic、VasSonic 等等，咱們大概來了解一下。

Hybrid App——Cordova

說到 Cordova，不得不提到他的前身 PhoneGap，PhoneGap 面向 Web 開發人員，經過使用 HTML、CSS 和 Javascript 構建跨平臺 App。同年10月4日，Adobe 收購了 Nitobi Software 和它的 PhoneGap 產品，並對 PhoneGap 進行開源並將其轉到Apache。PhoneGap 2.0 版本時，產品改名爲 Apache Cordova。目前 Cordova 支持的平臺有 Android、iOS、Windows、Mac OS X、Electron。

爲何叫作Cordova呢，是由於PhoneGap在建立時，Nitobi的所在地在溫哥華的科爾多瓦街(Cordova Street)

Cordova的工做原理

第一部分：Cordova Application是Cordova框架獨立於不一樣手機操做系統的一個封裝層。具體包括
1）Web App層是開發人員編寫代碼的主要地方，應用程序以網頁的形式呈現，在一個index.html的本地頁面文件中引用所須要的各類Web資源，如CSS、JavaScript、圖像、影音文件等。應用程序的配置保存在config.xml文件中。

2）WebView層用來呈現用戶界面，即web頁面的展示。例如，在Android平臺是經過WebView控件實現web頁面的呈現。

3）Plugins主要用於在JavaScript代碼中調用各平臺native的功能。Cordova項目已經包含一些核心的plugin，如電池、攝像頭、通信錄等。開發人員也能夠開發自定義的plugin，來實現所須要的功能。

第二部分：Mobile OS就是具體的手機操做系統層了，Cordova目前支持大部分的手機OS：ios、Android、windowsphone、黑莓等等；

實際上咱們能夠這麼理解所謂的「跨平臺」：
Cordova預先幫咱們預先封裝了各類mobile os上最經常使用的本地api調用，而後以統一的JavaScript api形式提供給webapp開發者調用。對於開發者來講，不須要關注系統底層調用實現細節，也就實現了所謂的「跨平臺」。實際上，各平臺涉及到本地能力的調用的時候，都被封裝成了各類插件。

用cordova寫的app，運行起來的體驗吧。在性能上有如下幾個問題
1.某些複雜效果下感受有卡頓。
2.許多css3特效不流暢，可是在PC上就很流暢

優勢	缺點
跨平臺，開發簡單，學習成本低	WebView性能低下時，用戶體驗差，反應慢
框架多，插件多，可自定義插件	國外的框架，中文文檔資源少
發展最先，社區資源豐富	調試不方便，既不像原生那種調試，也不像純web那種熱重載式的調試
相同代碼經過編譯就能跑在各平臺，大大提升了多平臺開發的效率	App store相關政策存在風險？

Hybrid App——Ionic

Ionic是一個開源的移動應用程序開發框架，它能夠輕鬆地使用web技術構建高質量的跨平臺的移動應用。可讓咱們快速開發移動App、移動端WEB頁面、微信公衆平臺應用，混合app web頁面。

Ionic最初只支持Angular，在2019年時推出的Ionic4正式版對 React 和 Vue 全面支持。目前最新版本是Ionic5。

Ionic的本質就是一個UI框架，若是把Cordova和Ionic做比較，實際上是沒有什麼可比性的。

Hybrid App——vasSonic

VasSonic取名於世嘉遊戲形象音速小子，是騰訊VAS(SNG增值產品部QQ會員)團隊研發的一個輕量級的高性能的Hybrid框架，專一於提高頁面首屏加載速度，完美支持靜態直出頁面和動態直出頁面，兼容離線包等方案。

語言編譯轉換

Xamarin 是一個開放源代碼平臺，用於經過 .NET 構建適用於 iOS、Android 和 Windows 的新式高性能應用程序。 Xamarin 是一個抽象層，可管理共享代碼與基礎平臺代碼的通訊。 Xamarin 在提供便利（如內存分配和垃圾回收）的託管環境中運行。

Xamarin 使開發人員能夠跨平臺共享其應用程序（平均 90%）。 此模式容許開發人員以一種語言編寫全部業務邏輯（或重複使用現有應用程序代碼），但在每一個平臺上實現本機性能和外觀。

Xamarin 應用程序能夠在電腦或 Mac 上進行編寫並編譯爲本機應用程序包，如 Android 上的 .apk 文件，
或 iOS 上的 .ipa 文件。

Xamarin 的工做原理

Xamarin.Android 應用程序從 C# 編譯爲中間語言 (IL)，隨後在啓動應用程序時，再實時編譯 (JIT)爲本機程序集。 Xamarin.Android 應用程序在 Mono 執行環境中與 Android 運行時 (ART) 虛擬機並行運行。 Xamarin 向 Android. 和 Java. 命名空間提供 .NET 綁定。 Mono 執行環境經過.NET可調用包裝器 (MCW) 調入這些命名空間，並向 ART 提供 Android 可調用包裝器 (ACW)，這使兩種環境能夠相互調用代碼。

在講述Xamarin.Android架構以前，須要先了解一些Android應用程序的背景知識：

• Android應用程序試運行在Dalvik虛擬機中的，每個應用程序對應一個單獨的虛擬機實例，其代碼在虛擬機的解釋下得以執行。
• Dalvik主要是完成對象生命週期管理，堆棧管理，線程管理，安全和異常管理，以及垃圾回收等等重要功能。
• 不一樣於Java虛擬機運行java字節碼，Dalvik虛擬機運行的是其專有的文件格式

Android Callable Wrappers（ACW）
使用C#開發的Android應用程序在運行的時候，C#代碼是在Mono虛擬機中執行的，而Mono虛擬機是寄宿在Dalvik虛擬機中運行的，全部的C#代碼都經過ACW的方式被調用。
因爲須要打包Mono環境，使用C#開發的Android應用的APK文件會比原生開發的大，執行效率也會差一些。

Managed Callable Wrapper（MCW）
若是須要在C#中調用一些系統的功能或者Java實現的類庫，該如何調用那？ 答案就是MCW，MCW就是一個JNI橋樑，可使用.NET調用Android的代碼。MCW將整個Android.* 以及相關的命名空間經過 jar綁定的方式暴露出來，使得C#能夠調用。

Xamarin.iOS 應用程序徹底預先 (AOT) 地從 C# 編譯爲本機 ARM 程序集代碼。 Xamarin 使用選擇器和註冊器（共同稱爲「綁定」），使 Objective-C 和 C# 能夠進行通訊。

對於開發者來講，Xamarin.IOS相對於Xamarin.Android就要簡單不少了，咱們用C#開發的iOS應用程序在被編譯成IL代碼以後，而後轉交給Apple complier直接編譯成iOS的本地機器碼，也就是說C#寫的iOS應用程序和Objective-C 寫的是同樣的。
透過 Ahead-of-Time (AOT) 編譯程序，直接將Xamarin.iOS程序編譯爲ARM的執行檔。編譯封裝完成的應用程序被直接編譯爲原生的二進制執行文件。

Xamarin.Forms實現原理
在Xamarin Studio中構建Xamarin.Forms跨平臺的應用的時候，會生成Android以及iOS單獨的項目工程，二者共享業務邏輯以及一些UI界面，在打包生成App的時候，是分開進行的，二者互不影響。每一個平臺的實現原理與上面講的是同樣的。

Xamarin的性能


Xamarin.Forms 支持的平臺

• iOS 9 或更高版本。
• Android 4.4 (API 19) 或更高版本。 但建議使用 Android 5.0 (API 21) 做爲最小 API。 這可確保與全部 Android 支持庫徹底兼容，同時仍面向大多數 Android 設備。
• 適用於 .NET Standard 2.0 支持的 Windows 10 通用 Windows 平臺(UWP)版本 10.0.16299.0或更高版本。 可是，推薦使用 10.0.18362.0 版或更高版本。
• Samsung Tizen（英特爾MeeGo系統與三星LiMo系統的混合體。）
• macOS 10.13 或更高版本

Xamarin的優缺點

優勢	缺點
性能接近原生	國內開發文檔欠缺
Xamarin.Forms代碼複用高達94%	第三方SDK的引用相對複雜
強大的企業支持	Xamarin社區不完善
完整的開發生態系統	不適用於重圖形應用程序

原生渲染

原生渲染——React Native

React Native (簡稱RN)是Facebook於2015年4月開源的跨平臺移動應用開發框架，是Facebook早先開源的JS框架 React 在原生移動應用平臺的衍生產物，支持iOS和安卓兩大平臺。RN使用Javascript語言，相似於HTML的JSX，以及CSS來開發移動應用，所以熟悉Web前端開發的技術人員只需不多的學習就能夠進入移動應用開發領域。
React Native原理

咱們接下來以ios爲例，簡單講一下React Natvie的原理。

C 系列的語言，通過編譯，連接等操做後，會獲得一個二進制格式的可執行文，所謂的運行程序，實際上是運行這個二進制程序。
而 JavaScript 是一種腳本語言，它不會通過編譯、連接等操做，而是在運行時才動態的進行詞法、語法分析，生成抽象語法樹(AST)和字節碼，而後由解釋器負責執行或者使用 JIT 將字節碼轉化爲機器碼再執行。整個流程由 JavaScript 引擎負責完成。這個引擎就是蘋果提供的 JavaScript Core 的框架。
因爲JavaScript 是一種單線程的語言，它不具有自運行的能力，所以老是被動調用。不少介紹 React Native 的文章都會提到 「JavaScript 線程」 的概念，實際上，它表示的是 Objective-C 建立了一個單獨的線程，這個線程只用於執行 JavaScript 代碼，並且 JavaScript 代碼只會在這個線程中執行。
因爲 JavaScript Core 是一個面向 Objective-C 的框架，在 Objective-C 這一端，咱們對 JavaScript 上下文知根知底，能夠很容易的獲取到對象，方法等各類信息，固然也包括調用 JavaScript 函數。真正複雜的問題在於，JavaScript 不知道 Objective-C 有哪些方法能夠調用。

React Native 解決這個問題的方案是在 Objective-C 和 JavaScript 兩端都保存了一份配置表，裏面標記了全部 Objective-C 暴露給 JavaScript 的模塊和方法。這樣，不管是哪一方調用另外一方的方法，實際上傳遞的數據只有 ModuleId、MethodId 和 Arguments 這三個元素，它們分別表示類、方法和方法參數，當 Objective-C 接收到這三個值後，就能夠經過 runtime 惟一肯定要調用的是哪一個函數，而後調用這個函數。
React Native的優缺點

優勢	缺點
複用了 React 的思想，有利於前端開發者涉足移動端。	作不到 Write once, Run everywhere
可以利用 JavaScript 動態更新的特性，快速迭代。	不能作到徹底屏蔽 iOS 端或 Android 的細節
相比於原平生臺，開發速度更快，相比於 Hybrid 框架，性能更好。	因爲 Objective-C 與 JavaScript 之間切換存在固定的時間開銷，因此性能一定不及原生

React Native的現狀和將來
2018年，React Native的貢獻者數量在GitHub所有倉庫的中排名第二。

React Native的社區一直在發佈激動人心的新項目，並經過諸如React Native Windows，React NativemacOS和React Native Web之類的倉庫來探索Android和iOS之外的平臺。

原生渲染——Weex

Weex是alibaba於2015年推出的一款跨平臺開發框架，其 致力於使開發者能基於通用跨平臺的 Web 開發語言和開發經驗，來構建 Android、iOS 和 Web 應用。簡單來講，在集成了 WeexSDK 以後，你可使用 JavaScript 語言和前端開發經驗來開發移動應用。
Weex使用的前端框架

Weex 渲染引擎與 DSL 語法層是分開的，Weex 並不強依賴任何特定的前端框架。目前 Vue.js 和 Rax 這兩個前端框架被普遍應用於 Weex 頁面開發，同時 Weex 也對這兩個前端框架提供了最完善的支持。

Weex的基本結構

Weex的基本結構能夠說是4層，也能夠說是3層
Vue和Rax是目前Weex使用的兩大前端框架（DSL領域特定語言（Domain-specific Language））
中間的這層JS Framework是用來抹平上層前端框架差別的，他會把一些渲染類的指令對接到weex Core，weexCore有點相似於瀏覽器自己的那個webCore。
weexCore再往下是對接Native的渲染引擎，也就是說你用前端寫的Vue組件，最終被渲染成ios和android原生的組件。
Weex各模塊的實現和依賴

JS Framework和Weex Core是Weex的核心。
Vue是用js寫的，JS Framework乾的不少是一些偏瀏覽器的事情，可是依然是用js寫的，weex Core是C / C++寫的一層，原生是和平臺的語言有關。
調用方面，JS Framework會透一些DOM API之類的東西，透到vue這層。
在內部，就是JS Framework和Weex Core中間會有Bridge API作內部通訊，包含模塊的調用，事件的響應，還有DOM渲染指令等。
從Weex到native直接就是一個native級別的調用，渲染原生組件。
Weex的優缺點

優勢	缺點
國內團隊開發，中文文檔齊全	動畫實現、API豐富程度及事件機制上略遜於RN
Vue做爲前端開發語言，學習成本低	不支持橫豎屏切換
與RN不一樣，Weex的框架較輕	阿里將其捐贈給Apache，後續維護頻率低（KPI產品）

不支持橫豎屏切換：
Weex 將原始樣式值轉換爲平臺 UI 系統的座標值，以後原始樣式值被丟棄。這個有必定歷史緣由，且當頁面很是大或複雜時，丟棄後能夠節省不少內存，所以原始樣式值被丟棄。
同時，目前 Weex 不支持百分比佈局，大量豎屏頁面使用 750px 的 viewPortWidth 值爲基準進行開發，頁面裏的座標值都是根據 750px 爲一個屏幕寬度換算後的值。
當屏幕發生旋轉後，好比 iPhone6 手機，旋轉後的 「寬 高」 爲 「667 375」。此時咱們須要原始的樣式值來從新計算出設置給排版引擎的座標值，如前文所說，排版引擎接收的是 iOS UIKit 的座標值。這個時候對於仍然爲 "375px" 的樣式，其計算出的 UIKit 座標值爲：dimension(UIKit) = 375 / 750 * 667 = 333.5仍然爲寬屏下的屏幕寬度一半。
可是由於原始樣式值被丟棄，咱們不能支持橫豎屏切換。

原生渲染——Dcloud（uni-app）

uni-app 是一個使用 Vue.js 開發全部前端應用的框架，開發者
編寫一套代碼，可發佈到iOS、Android、Web（響應式）、以及各類小程序（微信/支付寶/百度/頭條/QQ/釘釘/淘寶）、快應用等多個平臺。

不少人覺得小程序是微信先推出的，其實，DCloud纔是這個行業的開創者。
DCloud於2012年開始研發小程序技術，優化webview的功能和性能，並加入W3C和HTML5中國產業聯盟，推出了HBuilder開發工具，爲後續產業化作準備。
2015年，DCloud正式商用了本身的小程序，產品名爲「流應用」，它不是B/S模式的輕應用，而是能接近原生功能、性能的動態App，而且即點即用。
爲將該技術發揚光大，DCloud將技術標準捐獻給工信部旗下的HTML5中國產業聯盟，並推動各家流量巨頭接入該標準，開展小程序業務。360手機助手率先接入，在其3.4版本實現應用的秒開運行。
隨後DCloud推進大衆點評、攜程、京東、有道詞典、惟品會等衆多開發者爲流應用平臺提供應用。
在2015年9月，DCloud推動微信團隊開展小程序業務，演示了流應用的秒開應用、掃碼獲取應用、分享連接獲取應用等衆多場景案例，以及分享了webview體驗優化的經驗。
微信團隊通過分析，於2016年初決定上線小程序業務，但其沒有接入聯盟標準，而是訂製了本身的標準。
DCloud持續在業內普及小程序理念，推動各大流量巨頭，包括手機廠商，陸續上線相似小程序/快應用等業務。
部分公司接入了聯盟標準，但更多公司因利益紛爭嚴重，標準難以統一。
技術是純粹的，不該該由於商業利益而分裂。開發者面對如此多的私有標準不是一件正確的事情。
形成混亂的局面非DCloud所願。因而咱們決定開發一個免費開源的框架。
既然各巨頭沒法在標準上達成一致，那麼就經過這個框架爲開發者抹平各平臺差別。
這，就是uni-app的由來。

uniapp的特色
uni-app是雙渲染引擎，在 App端內置了一個webview和一個基於 weex 改進的原生渲染引擎，提供了原生渲染能力。

在App端：

• 若是使用vue頁面，則使用webview渲染
• 若是使用nvue頁面(native vue的縮寫)，則使用原生渲染

以往的 weex ，有個很大的問題是它只是一個高性能的渲染器，沒有足夠的API能力（好比各類push sdk集成、藍牙等能力調用），使得開發時很是依賴原生工程師協做，開發者原本想節約成本，結果須要前端、iOS、Android 3類人開發，適得反。

nvue 解決了這個問題，讓前端工程師能夠直接開發完整 App，並提供豐富的插件生態和雲打包。這些組合方案，幫助開發者切實的提升效率、下降成本。

自渲染

Flutter

Flutter 是 Google 開源的 UI 工具包，幫助開發者經過一套代碼庫高效構建多平臺精美應用，支持移動、Web、桌面和嵌入式平臺。Flutter 開源、免費，擁有寬鬆的開源協議，適合商業項目。
Flutter的原理

• 原生渲染（RN / Weex）

• Flutter

Flutter 也提供響應式風格的視圖。 Flutter 使用編譯的編程語言即Dart 的方法來避免 JsBridge引發的性能問題,。 Dart 被「提早編譯」（AOT）編譯成多個平臺的本地代碼。 這使得 Flutter無需經過JsBridge就能夠與平臺進行通訊。 編譯爲本機代碼也能夠提升應用程序的啓動時間。

Flutter不使用OEM Widgets（或DOM WebViews），它提供了本身的 Widgets。

Flutter將 Widgets 和渲染器從平臺移動到應用程序中，從而使其能夠自定義和擴展。 Flutter對平臺的需求平臺是一個畫布，在這個畫布中，Widgets 能夠呈如今設備屏幕上，並能夠訪問事件（觸摸，定時器等）和服務（位置，攝像機等）。Dart程序（綠色）和本地平臺代碼（iOS或Android藍色）之間仍然存在一個接口，能夠進行數據編碼和解碼，但這可能比JavaScript Bridge 快幾個數量級。將 Widgets 和渲染器移動到應用程序中會影響應用程序的大小。 Android上Flutter應用程序的最小大小約爲6.7MB，這部分是須要開發者來權衡利弊的。
高效率

Flutter的熱重載可幫快速地進行測試、構建UI、添加功能並更快地修復錯誤。在iOS和Android模擬器或真機上能夠在亞秒內重載，而且不會丟失狀態。
Flutter高一致性

Flutter高性能

框架對比與選型

類型	Cordova	Xamarin	React Native	Weex	Uniapp	Flutter
性能	低	高	較高	中	高	高
上手難度	容易	較高	較高	容易	容易	中
核心	JavaScript	.NET	React	Weex	vue	Dart
框架輕重	輕	較重	較重	較輕	輕	重
特色	適合單頁面	適合開發總體App	適合開發總體App	適合單頁面	適合開發總體App	適合開發總體App
社區	活躍度較低	活躍度低	活躍度高，Facebook維護	活躍度中，目前託管apache	活躍度高，Dcloud維護	活躍度高，Google維護
支持平臺	Android、IOS、Windows、MacOS	Android、IOS、Windows	Android、IOS、Web	Android、IOS、Web	Android、IOS、Web、小程序、快應用	Android、IOS、MacOS、Web、Linux、Windows、Fuchsia
適應性	Web開發學習成本低	.NET C#工程師開發	Web開發學習成本低	Web開發學習成本低	Web開發學習成本低	Java、C++、C#、開發學習成本低

跨平臺技術的分類沒有標準的答案，這裏也只是粗略的進行分類，並對每一個分類的主流框架進行介紹，實際上還有不少框架沒有提到，它們不是沒落了，就是缺點明顯難以使用，再就是大公司的 KPI 產物。跨平臺技術的演進比如百家爭鳴，極大的促進了跨平臺技術的發展。在我看來，這些技術讓不一樣技術分支的程序員均可以參與到移動開發中，享受移動開發的樂趣，從這個角度來看這些跨平臺技術的優劣之分是很難去評判的。

無論什麼跨平臺開發框架，都要去選擇最合適本身團隊的。但無論選擇何種框架，前提還得對原生的開發環境以及開發模式有必定的瞭解，否則也是事倍功半。雖然如今市面上移動端的跨平臺開發工具開發出來的App性能都和原生有必定的差距，但仍是有他們本身的優點，並非全部公司都能長期承擔起原生App開發與維護的成本，這也是他們能長期存在的理由。

結束