移動APP混合框架

主流的跨端方案，一種是，將JavaScriptCore引擎當作虛擬機的方案，表明框架React Native；另外一種是使用非JavaScriptCore虛擬機的方案，表明框架是Flutter。html

怎麼選擇跨端方案

從編程語言角度

JavaScript的歷史和流行程度都遠超Dart,生態也更加完善,開發者也遠多於Dart程序員。因此,從編程語言的角度來看,雖然Dart語言入門簡單,但從長遠考慮,仍是選擇 React Native會更好一些。

從頁面框架角度

同時,從頁面框架和自動化工具的角度來看, React Native也要領先於 Flutter。這,主要得益於web技術這麼多年的積累,其工具鏈很是完善。前端開發者可以很輕鬆地掌握 React Native,並進行移動端App的開發

從性能等角度

相比於 React Native框架, Flutter的優點最主要體如今性能、開發效率和體驗這兩大方面。
Flutter卻不同。它一開始就拋棄了歷史包袱,使用全新的Dart語言編寫,同時支持AOT 和JT兩種編譯方式,而沒有采用HTML/csS/ JavaScript組合方式開發,在執行效率上明顯高於 JavaScriptCore。
除了編程語言的虛擬機，Flutter的優點還體如今Ul框架的實現上。它重寫了Ul框架，從Ul 控件到渲染，所有從新實現了，依賴Skia圖形庫和系統圖形繪製相關的接口，保證了不一樣平臺上能有相同的體驗。

選擇

一旦使用Flutter開發成爲團隊的必選項，那麼其餘技術棧就沒有存在的價值了。
我將跨平臺方案分紅了兩種:一種是,將 JavaScriptcore引擎看成虛擬機的方案,表明框架是 React Native;另外一種是,使用非 JavaScriptcore虛擬機的方案,表明框架是 Flutter。
在我看來，從長遠考慮的話，你能夠選擇Flutter做爲跨平臺開發方案。可是，最終 Flutter是否能成功，還要看谷歌新系統Fuchsia的成敗。

原生

原生應用程序是指某一個移動平臺（好比iOS或安卓）所特有的應用，使用相應平臺支持的開發工具和語言，並直接調用系統提供的SDK API。好比Android原生應用就是指使用Java或Kotlin語言直接調用Android SDK開發的應用程序；而iOS原生應用就是指經過Objective-C或Swift語言直接調用iOS SDK開發的應用程序。

主要優點：

可訪問平臺所有功能（GPS、攝像頭）；
速度快、性能高、能夠實現複雜動畫及繪製，總體用戶體驗好；

主要缺點：

平臺特定，開發成本高；不一樣平臺必須維護不一樣代碼，人力成本隨之變大；前端
內容固定，動態化弱，大多數狀況下，有新功能更新時只能發版；vue
在移動互聯網發展初期，業務場景並不複雜，原生開發還能夠應對產品需求迭代。但近幾年，隨着物聯網時代到來、移動互聯網高歌猛進，突飛猛進，在不少業務場景中，傳統的純原生開發已經不能知足日益增加的業務需求。主要表如今：react
動態化內容需求增大；當需求發生變化時，純原生應用須要經過版本升級來更新內容，但應用上架、審覈是須要週期的，這對高速變化的互聯網時代來講是很難接受的，因此，對應用動態化(不發版也能夠更新應用內容)的需求就變的迫在眉睫。android
業務需求變化快，開發成本變大；因爲原生開發通常都要維護Android、iOS兩個開發團隊，版本迭代時，不管人力成本，仍是測試成本都會變大。ios
總結一下，純原生開發主要面臨動態化和開發成本兩個問題，而針對這兩個問題，誕生了一些跨平臺的動態化框架。git

混合方案一：原生+H5

Cordova
Ionic
微信小程序

這類框架主要原理就是將APP的一部分須要動態變更的內容經過H5來實現，經過原生的網頁加載控件WebView (Android)或WKWebView（iOS）來加載（之後若無特殊說明，咱們用WebView來統一指代android和iOS中的網頁加載控件）。這樣一來，H5部分是能夠隨時改變而不用發版，動態化需求能知足；同時，因爲h5代碼只須要一次開發，就能同時在Android和iOS兩個平臺運行，這也能夠減少開發成本，也就是說，H5部分功能越多，開發成本就越小。咱們稱這種h5+原生的開發模式爲混合開發，採用混合模式開發的APP咱們稱之爲混合應用或Hybrid APP ，若是一個應用的大多數功能都是H5實現的話，咱們稱其爲Web APP 。
目前混合開發框架的典型表明有：Cordova、Ionic 和微信小程序，值得一提的是微信小程序目前是在webview中渲染的，並不是原生渲染，但未來有可能會採用原生渲染。

主要優勢：

混合應用的優勢是動態內容是H5，web技術棧，社區及資源豐富。

主要缺點：

缺點是性能很差，對於複雜用戶界面或動畫，WebView不堪重任。

這類框架主要原理就是將APP的一部分須要動態變更的內容經過H5來實現，經過原生的網頁加載控件WebView (Android)或WKWebView（iOS）來加載（之後若無特殊說明，咱們用WebView來統一指代android和iOS中的網頁加載控件）。這樣一來，H5部分是能夠隨時改變而不用發版，動態化需求能知足；同時，因爲h5代碼只須要一次開發，就能同時在Android和iOS兩個平臺運行，這也能夠減少開發成本，也就是說，H5部分功能越多，開發成本就越小。咱們稱這種h5+原生的開發模式爲混合開發，採用混合模式開發的APP咱們稱之爲混合應用或Hybrid APP ，若是一個應用的大多數功能都是H5實現的話，咱們稱其爲Web APP 。
目前混合開發框架的典型表明有：Cordova、Ionic 和微信小程序，值得一提的是微信小程序目前是在webview中渲染的，並不是原生渲染，但未來有可能會採用原生渲染。

混合方案二：原生+JavaScript

React Native facebook出品
Weex 阿里巴巴出品
快應用

主要優勢：

採用Web開發技術棧，社區龐大、上手快、開發成本相對較低。
原生渲染，性能相比H5提升不少。
動態化較好，支持熱更新。

主要不足：

渲染時須要JavaScript和原生之間通訊，在有些場景如拖動可能會由於通訊頻繁致使卡頓。
JavaScript爲腳本語言，執行時須要JIT(Just In Time)，執行效率和AOT(Ahead Of Time)代碼仍有差距。
因爲渲染依賴原生控件，不一樣平臺的控件須要單獨維護，而且當系統更新時，社區控件可能會滯後；除此以外，其控件系統也會受到原生UI系統限制，例如，在Android中，手勢衝突消歧規則是固定的，這在使用不一樣人寫的控件嵌套時，手勢衝突問題將會變得很是棘手。

React Native

React Native (簡稱RN)是Facebook於2015年4月開源的跨平臺移動應用開發框架，是Facebook早先開源的JS框架 React 在原生移動應用平臺的衍生產物，目前支持iOS和Android兩個平臺。RN使用Javascript語言，相似於HTML的JSX，以及CSS來開發移動應用，所以熟悉Web前端開發的技術人員只需不多的學習就能夠進入移動應用開發領域。
因爲RN和React原理相通，而且Flutter也是受React啓發，不少思想也都是相通的，萬丈高樓平地起，咱們有必要深刻了解一下React原理。React是一個響應式的Web框架，咱們先了解一下兩個重要的概念：DOM樹與響應式編程。
上文已經提到React Native 是React 在原生移動應用平臺的衍生產物，那二者主要的區別是什麼呢？其實，主要的區別在於虛擬DOM映射的對象是什麼？React中虛擬DOM最終會映射爲瀏覽器DOM樹，而RN中虛擬DOM會經過 JavaScriptCore 映射爲原生控件樹。
JavaScriptCore 是一個JavaScript解釋器，它在React Native中主要有兩個做用：
爲JavaScript提供運行環境。
是JavaScript與原生應用之間通訊的橋樑，做用和JsBridge同樣，事實上，在iOS中，不少JsBridge的實現都是基於 JavaScriptCore 。
而RN中將虛擬DOM映射爲原生控件的過程當中分兩步：
佈局消息傳遞；將虛擬DOM佈局信息傳遞給原生；
原生根據佈局信息經過對應的原生控件渲染控件樹；
至此，React Native 便實現了跨平臺。相對於混合應用，因爲React Native是原生控件渲染，因此性能會比混合應用中H5好不少，同時React Native是Web開發技術棧，也只需維護一份代碼，一樣是跨平臺框架。

Weex

Weex是阿里巴巴於2016年發佈的跨平臺移動端開發框架，思想及原理和React Native相似，最大的不一樣是語法層面，Weex支持Vue語法和Rax語法，Rax 的 DSL(Domain Specific Language) 語法是基於 React JSX 語法而創造。與 React 不一樣，在 Rax 中 JSX 是必選的，它不支持經過其它方式建立組件，因此學習 JSX 是使用 Rax 的必要基礎。而React Native只支持JSX語法。

快應用

快應用是華爲、小米、OPPO、魅族等國內9大主流手機廠商共同制定的輕量級應用標準，目標直指微信小程序。它也是採用JavaScript語言開發，原生控件渲染，與React Native和Weex相比主要有兩點不一樣：
快應用自身不支持Vue或React語法，其採用原生JavaScript開發，其開發框架和微信小程序很像，值得一提的是小程序目前已經可使用Vue語法開發（mpvue），從原理上來說，Vue的語法也能夠移植到快應用上。
React Native和Weex的渲染/排版引擎是集成到框架中的，每個APP都須要打包一份，安裝包體積較大；而快應用渲染/排版引擎是集成到ROM中的，應用中無需打包，安裝包體積小，正因如此，快應用才能在保證性能的同時作到快速分發。

混合方案三：原生+自繪

QT for mobile
Flutter 谷歌出品

在本篇中，咱們看看最後一種跨平臺技術：自繪UI+原生。這種技術的思路是，經過在不一樣平臺實現一個統一接口的渲染引擎來繪製UI，而不依賴系統原生控件，因此能夠作到不一樣平臺UI的一致性。注意，自繪引擎解決的是UI的跨平臺問題，若是涉及其它系統能力調用，依然要涉及原生開發。

主要優勢：

性能高；因爲自繪引擎是直接調用系統API來繪製UI，因此性能和原生控件接近。
靈活、組件庫易維護、UI外觀保真度和一致性高；因爲UI渲染不依賴原生控件，也就不須要根據不一樣平臺的控件單獨維護一套組件庫，因此代碼容易維護。因爲組件庫是同一套代碼、同一個渲染引擎，因此在不一樣平臺，組件顯示外觀能夠作到高保真和高一致性；另外，因爲不依賴原生控件，也就不會受原生布局系統的限制，這樣佈局系統會很是靈活。

主要不足：

動態性不足；爲了保證UI繪製性能，自繪UI系統通常都會採用AOT模式編譯其發佈包，因此應用發佈後，不能像Hybrid和RN那些使用JavaScript（JIT）做爲開發語言的框架那樣動態下發代碼。
也許你已經猜到Flutter就屬於這一類跨平臺技術，沒錯，Flutter正是實現一套自繪引擎，並擁有一套本身的UI佈局系統。不過，自繪製引擎的思路並非什麼新概念，Flutter並非第一個嘗試這麼作的，在它以前有一個典型的表明，即大名鼎鼎的QT。

Flutter

「千呼萬喚始出來」，鋪墊這麼久，如今終於等到本書的主角出場了！
Flutter是Google發佈的一個用於建立跨平臺、高性能移動應用的框架。Flutter和QT mobile同樣，都沒有使用原生控件，相反都實現了一個自繪引擎，使用自身的佈局、繪製系統。那麼，咱們會擔憂，QT mobile面對的問題Flutter是否也同樣，Flutter會不會步入QT mobile後塵，成爲另外一個烈士？要回到這個問題，咱們先來看看Flutter誕生過程：
2017 年 Google I/O 大會上，Google 首次推出了一款新的用於建立跨平臺、高性能的移動應用框架——Flutter。
2018年2月，Flutter發佈了第一個Beta版本，同年五月，在2018年Google I/O 大會上，Flutter 更新到了 beta 3 版本。
2018年6月，Flutter發佈了首個預覽版本，這意味着 Flutter 進入了正式版（1.0）發佈前的最後階段。
觀其發展，在2018年5月份，Flutter 進入了 GitHub stars 排行榜前 100 名，已有 27k star。而今天(2019年5月29日)，已經有65K的Star。經歷了短短2年多的時間，Flutter 生態系統得以快速增加，因而可知，Flutter在開發者中受到了熱烈的歡迎，其將來發展值得期待！
如今，咱們來和QT mobile作一個對比：
生態；從Github上來看，目前Flutter活躍用戶正在高速增加。從Stackoverflow上提問來看，Flutter社區如今已經很龐大。Flutter的文檔、資源也愈來愈豐富，開發過程當中遇到的不少問題均可以在Stackoverflow或其github issue中找到答案。
技術支持；如今Google正在大力推廣Flutter，Flutter的做者中不少人都是來自Chromium團隊，而且github上活躍度很高。另外一個角度，從今年上半年Flutter頻繁的版本發佈也能夠看出Google對Flutter的投入的資源不小，因此在官方技術支持這方面，大可沒必要擔憂。
開發效率；Flutter的熱重載可幫助開發者快速地進行測試、構建UI、添加功能並更快地修復錯誤。在iOS和Android模擬器或真機上能夠實現毫秒級熱重載，而且不會丟失狀態。這真的很棒，相信我，若是你是一名原生開發者，體驗了Flutter開發流後，極可能就不想從新回去作原生了，畢竟不多有人不吐槽原生開發的編譯速度。
基於以上三點，相信讀者和筆者同樣，Flutter將來如何，心中自有定論。到如今爲止，咱們已經對移動端開發技術有了一個全面的瞭解，接下來咱們便要進入本書的主題，你準備好了嗎！

Qt

Qt是一個1991年由Qt Company開發的跨平臺C++圖形用戶界面應用程序開發框架。2008年，Qt Company科技被諾基亞公司收購，Qt也所以成爲諾基亞旗下的編程語言工具。2012年，Qt被Digia收購。2014年4月，跨平臺集成開發環境Qt Creator 3.1.0正式發佈，實現了對於iOS的徹底支持，新增WinRT、Beautifier等插件，廢棄了無Python接口的GDB調試支持，集成了基於Clang的C/C++代碼模塊，並對Android支持作出了調整，至此實現了全面支持iOS、Android、WP，它提供給應用程序開發者構建圖形用戶界面所需的全部功能。可是，QT雖然在PC端得到了巨大成功，備受社區追捧，然而其在移動端卻表現不佳，在近幾年，雖然偶爾能聽到QT的聲音，但一直很弱，不管QT自己技術如何、設計思想如何，但事實上終究是敗了，究其緣由，筆者認爲主要有四：
第一：QT移動開發社區過小，學習資料不足，生態很差。
第二：官方推廣不利，支持不夠。
第三：移動端發力較晚，市場已被其它動態化框架佔領（Hybrid和RN)。
第四：在移動開發中，C++開發和Web開發棧相比有着先天的劣勢，直接結果就是QT開發效率過低。
基於此四點，儘管QT是移動端開發跨平臺自繪引擎的先驅，但卻成爲了烈士。

參考連接github