簡介

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

移動跨平台開發介紹

傳統移動端開發

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

傳統移動端開發優缺點

跨平台技術的誕生

早在2010年，當時從事 Android 和 iOS 開發的人很少，也不火，所有人都在 “摸着河底過河”，項目更沒有第三方框架一説，大都是自己寫的，不像現在各種的框架滿天飛。隨着移動開發的發展，互聯網公司也是層出不窮，有些公司迫於競爭，想要更快速的更省成本的進行開發，就不再滿足 Android 端一套代碼，iOS 端一套代碼。同時，其他技術領域和各大公司也都各自推出相關的技術，這樣跨平台技術隨之誕生，並且開始在公司中生根發芽。
因為Android 和 iOS 生態很大，我們可以把它們比作第一級生態，也有廠商想要顛覆這兩個系統，但都失敗了，因此建立次級生態才是最穩妥的策略，Android 平台更加開放，因此建立次級生態的中心就是 Android，次生態的形式多種多樣，比如在 Android 系統的基礎上魔改建立自己的生態，再或者推出各種跨平台技術建立生態。跨平台技術產生的框架實在太多了，很多還沒等我們去學去了解，它們就沒落了，也就成為了跨平台技術發展的一個過度產物。

移動跨平台開發演進

為什麼要跨平台開發？

作為開發不同應用而使用不同的開發語言，對開發者而言並不是一個好事。本質上，跨平台開發是為了增加代碼複用，減少開發者對多個平台差異適配的工作量，降低開發成本，提高業務專注的同時，提供比web更好的體驗，跨平台開發正是解決了這一問題。

跨平台開發的優缺點

由於跨平台技術需要依賴各種框架，各框架品質也良莠不齊，老框架就不説了，新框架教程少、開發時遇到的坑多，有的能填上，有的填不上。這就需要框架背後的大廠和社區的支持了。

移動跨平台開發框架解析

跨平台技術演進

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上就很流暢

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的優缺點

原生渲染

原生渲染——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 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的優缺點

不支持橫豎屏切換：
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高性能

框架對比與選型

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

不管什麼跨平台開發框架，都要去選擇最合適自己團隊的。但不管選擇何種框架，前提還得對原生的開發環境以及開發模式有一定的瞭解，不然也是事倍功半。雖然現在市面上移動端的跨平台開發工具開發出來的App性能都和原生有一定的差距，但還是有他們自己的優勢，並不是所有公司都能長期承擔起原生App開發與維護的成本，這也是他們能長期存在的理由。

結束