1. 跨平臺技術(shù)的誕生
我是 2010 年開始從事的 Android 開發(fā)蕉毯，當(dāng)時會 Android 和 iOS 開發(fā)的很少，也不火思犁，所有人都在 “摸著河底過河”代虾，項(xiàng)目更沒有第三方框架一說，大都是自己寫的激蹲，不像現(xiàn)在各種的框架滿天飛棉磨。隨著移動開發(fā)的發(fā)展，互聯(lián)網(wǎng)公司也是層出不窮学辱，有些公司迫于競爭乘瓤，想要更迅速的更省成本的進(jìn)行開發(fā)，就不再滿足 Android 端一套代碼策泣，iOS 端一套代碼衙傀。與此同時，其他技術(shù)領(lǐng)域和各大公司也都覬覦著這份大蛋糕萨咕，紛紛推出相關(guān)的技術(shù)差油，這樣跨平臺技術(shù)應(yīng)運(yùn)而生，并且開始在公司中生根發(fā)芽。
Android 和 iOS 生態(tài)太大了蓄喇，我們可以把它們比作第一級生態(tài)发侵，想要顛覆這兩個系統(tǒng)的曾經(jīng)出現(xiàn)過，但都失敗了妆偏，因此建立次級生態(tài)是最穩(wěn)妥的策略刃鳄，Android 平臺更加開放，因此次級生態(tài)的中心就是 Android钱骂，次生態(tài)的形式多種多樣叔锐，比如在 Android 系統(tǒng)的基礎(chǔ)上魔改建立自己的生態(tài)，再或者推出各種跨平臺技術(shù)建立生態(tài)见秽∮淅樱跨平臺技術(shù)產(chǎn)生的框架實(shí)在太多了，很多還沒等我們?nèi)W(xué)去了解解取，它們就沒落了步责，成為了跨平臺技術(shù)的發(fā)展的一個過度產(chǎn)物≠骺啵跨平臺技術(shù)的產(chǎn)物是不靠譜還是趨勢蔓肯，我想讀完本篇文章你會有自己的理解。
跨平臺技術(shù)的分類沒有標(biāo)準(zhǔn)的答案振乏，這里把它們分類為 5 種蔗包，分別 Web App、Hybrid App慧邮、語言編譯轉(zhuǎn)換调限、原生渲染、自繪 UI误澳。下面分別介紹它們耻矮。
2. Web App
Web App 是指基于 Web 的應(yīng)用，運(yùn)行于網(wǎng)絡(luò)和標(biāo)準(zhǔn)瀏覽器上脓匿，相當(dāng)于一個網(wǎng)頁然后加一個 App 的殼淘钟。2014 年 HTML5 的標(biāo)準(zhǔn)規(guī)范制定完成，在網(wǎng)絡(luò)輿論上 Web App 大有取代 Native App 的氣勢陪毡，但 Web App 有以下缺點(diǎn)米母，使得它始終是 “主角的心，配角的命” ：
- 性能低毡琉，操作體驗(yàn)不好
- 無法調(diào)用原生 API铁瞒，很多功能無法實(shí)現(xiàn)，
- 依賴于網(wǎng)絡(luò)桅滋，網(wǎng)速慢時體驗(yàn)很差慧耍，并且沒有離線功能身辨，優(yōu)化不好的話會消耗流量
- 只能做為一個臨時的入口，用戶留存率低
在 Web App 的基礎(chǔ)上芍碧，又出現(xiàn)了幾個進(jìn)化者煌珊，這里主要介紹 PWA。
2.1 PWA
PWA（Progressive Web App）意為漸進(jìn)式增強(qiáng) Web 應(yīng)用泌豆，它不是一門技術(shù)定庵，而是一個概念，使用多種技術(shù)來增強(qiáng) Web App 的功能：
- 用 Service Worker + HTTPS +Cache Api + indexedDB 等一系列 web 技術(shù)實(shí)現(xiàn)離線加載和緩存
- 實(shí)現(xiàn)了推送和通知
- 可以直接添加到手機(jī)的桌面上
- 使用 Service Worker 可以進(jìn)行后臺同步
總結(jié)起來，PWA 的主要的能力就是離線、推送剑鞍、桌面訪問，可以說 PWA 賦予 Web App 原生的體驗(yàn)谢床，但是 PWA 一直不溫不火的原因主要有以下幾點(diǎn)：
- 游覽器對 PWA 技術(shù)支持還不夠全面， 不是每一款游覽器都能 100% 的支持 PWA
- 國內(nèi)一些手機(jī)廠商對 Android 系統(tǒng)各種魔改，對 PWA 的兼容性不好，甚至不支持 PWA
- 平臺的競爭俱病，iOS 對 PWA 的支持力度遠(yuǎn)遠(yuǎn)低于 Android，所以 PWA 在 iOS 上的體驗(yàn)打了折扣杂曲。PWA 面對類似的微信小程序和快應(yīng)用的競爭中庶艾，并沒有優(yōu)勢袁余。
3. Hybrid App
除了采用原生和 Web 開發(fā) App擎勘，還可以采用 HTML5 + 原生來進(jìn)行混合開發(fā)，這就是 Hybrid颖榜。
關(guān)于 Hybrid 的誕生有一個小故事棚饵，某個二線互聯(lián)網(wǎng)公司的 App 是以原生為主，HTML5 開發(fā)打醬油掩完，隨著應(yīng)用越來越復(fù)雜噪漾，終于有一天發(fā)現(xiàn)原生有一個方法最大數(shù)限制，一些頁面需要內(nèi)嵌 HTML5 的頁面且蓬，于是原生和 HTML5 團(tuán)隊(duì)一起做了第一個 Hybrid 項(xiàng)目欣硼，這一套代碼兼容三端并且效率很高，因此 Hybrid App 就成了這個公司的主流恶阴，業(yè)界其他的公司也都紛紛效仿诈胜。
通過原生 SDK 提供的 API冯事，App 可以與系統(tǒng)底層通信焦匈，以創(chuàng)建 UI 組件或訪問系統(tǒng)服務(wù)。這些組件被渲染到手機(jī)屏幕昵仅，屏幕產(chǎn)生的相應(yīng)的事件會被傳回給組件缓熟。因?yàn)槊總€平臺的系統(tǒng)組件是不同的，你需要為每個平臺開發(fā)單獨(dú)的 App，而 Hybrid App 不必這樣够滑，Hybrid App 的原生 UI 組件用來展示交互復(fù)雜和渲染要求高的界面垦写，其他的可以交給 HTML5 來展示。
Hybrid App 雖然開發(fā)效率高彰触，可以跨平臺梯澜，但是 Hybrid 體驗(yàn)比不上原生，對于需要快速試錯渴析、快速占領(lǐng)市場的團(tuán)隊(duì)來說晚伙，Hybrid App 是一個不錯的選擇，后期團(tuán)隊(duì)穩(wěn)定下來后俭茧，最好還是要做體驗(yàn)更好的原生 APP 或者使用其他體驗(yàn)更好的跨平臺技術(shù)咆疗。
Hybrid 相關(guān)的技術(shù)有很多，比如 PhoneGap母债、Cordova午磁、Ionic、VasSonic 等等毡们，我們大概來了解一下迅皇。
3.1 Cordova
說到 Cordova，不得不提到他的前身 PhoneGap衙熔，PhoneGap 面向 Web 開發(fā)人員登颓，通過使用 HTML、CSS 和 Javascript 構(gòu)建跨平臺 App红氯。2011 年框咙，Apache 收購了 Nitobi Software 和它的 PhoneGap 產(chǎn)品，并對 PhoneGap 進(jìn)行開源痢甘，PhoneGap 2.0 版本時喇嘱，產(chǎn)品更名為 Apache Cordova。目前 Cordova 支持的平臺有 Android塞栅、iOS者铜、Windows、Mac OS X放椰、Electron作烟。
Cordova 的體系結(jié)構(gòu)圖如下所示。
Cordova 同樣使用 WebView 來展示界面庄敛，插件是 Cordova 中不可或缺的一部分俗壹，Apache Cordova 維護(hù)了名為 Core Plugins 的插件，這些核心插件為 App 提供訪問設(shè)備功能藻烤，如電池绷雏，相機(jī)头滔，聯(lián)系人等。除了核心插件之外涎显，還有一些第三方插件可以使用坤检，你也可以開發(fā)一個自己的插件。
3.2 Ionic
Ionic Framework 是一個開源 UI 工具包期吓，最早的目標(biāo)是使用 HTML早歇，CSS 和 JavaScript 等 Web 技術(shù)開發(fā)移動應(yīng)用程序。由于 Web 技術(shù)的這一基礎(chǔ)讨勤，Ionic 可以在網(wǎng)絡(luò)運(yùn)行的任何地方運(yùn)行箭跳，比如 iOS，Android潭千，瀏覽器谱姓，Electron，PWA 等等刨晴。
目前屉来，Ionic Framework 已與 Angular 正式集成，但對 Vue 和 React 的支持正在開發(fā)中狈癞。
3.3 VasSonic
VasSonic 是由騰訊 VAS 團(tuán)隊(duì)開發(fā)的輕量級高性能混合框架茄靠，旨在加速在 Android 和 iOS 平臺上運(yùn)行的 H5 首屏。VasSonic 不僅支持服務(wù)器呈現(xiàn)的靜態(tài)或動態(tài)網(wǎng)站蝶桶，而且還完美兼容 Web 離線資源慨绳。VasSonic 使用自定義的 url 連接而不是原始網(wǎng)絡(luò)連接來請求索引 html，因此它可以提前或并行請求資源以避免等待視圖初始化莫瞬。在這種并行的情況下儡蔓，VasSonic 可以通過 WebKit 或 Blink 內(nèi)核讀取和呈現(xiàn)部分?jǐn)?shù)據(jù)郭蕉，而無需花費(fèi)太多時間等待數(shù)據(jù)流的結(jié)束疼邀。
3.4 微信小程序
微信小程序的主要開發(fā)語言是 JavaScript ，小程序的開發(fā)同普通的網(wǎng)頁開發(fā)相比有很大的相似性召锈。
小程序的運(yùn)行環(huán)境分成渲染層和邏輯層旁振，這兩層分別由 2 個線程管理，渲染層的界面使用了 WebView 進(jìn)行渲染涨岁，邏輯層采用 JsCore 線程運(yùn)行 JS 腳本拐袜。這兩個線程的通信會經(jīng)由微信客戶端（Native）中的 JSBridage 做中轉(zhuǎn)。邏輯層發(fā)送網(wǎng)絡(luò)請求也經(jīng)由 Native 轉(zhuǎn)發(fā)梢薪，小程序的通信模型下圖所示蹬铺。
其中 WXML 模板和 WXSS 樣式工作在渲染層，JS 腳本工作在邏輯層秉撇。
微信小程序和 PWA 都是基于 Web 技術(shù)甜攀，原理的區(qū)別是小程序類似 Hybrid 架構(gòu)秋泄，WebView 渲染基本的網(wǎng)頁內(nèi)容，對渲染性能要求較高的組件规阀，通過原生組件來實(shí)現(xiàn)恒序，比如相機(jī)、視頻谁撼、地圖等等歧胁，另外傳統(tǒng) Web 無法訪問的本地能力，需要通過 JS SDK 來實(shí)現(xiàn)厉碟，而 PWA 則是使用多種技術(shù)增強(qiáng) Web 能力喊巍，以達(dá)到接近 Native 應(yīng)用的體驗(yàn)。
微信小程序本身和 App 就不是競爭關(guān)系箍鼓，更多的是一個推廣渠道玄糟，它更像是一張海報(bào)，用于快速推廣倒流袄秩，而 App 則是要推廣的對象阵翎。微信小程序的缺點(diǎn)很明顯，體驗(yàn)上無法跟 App 相提并論之剧，功能依托并受限于微信郭卫，無法進(jìn)行拓展”臣冢可以說微信小程序就是建立了次級生態(tài)贰军，這個生態(tài)中微信說的算，其他對手的發(fā)展會受到限制蟹肘。
4. 語言編譯轉(zhuǎn)換
語言編譯轉(zhuǎn)換指的是直接將某個語言編譯為一個平臺下的二進(jìn)制文件词疼。比較有名的是 Xamarin 框架，雖然它在 Android 平臺是內(nèi)嵌了 Mono 虛擬機(jī)來實(shí)現(xiàn)的帘腹，但在 iOS 平臺下是以 AOT 的方式編譯為二進(jìn)制文件的贰盗，所以把它歸到語言編譯轉(zhuǎn)換類型。
4.1 Xamarin
Xamarin 始創(chuàng)于 2011 年阳欲，2016 年被微軟正式收購舵盈。Xamarin 是 Mono 項(xiàng)目的一個分支，基于.NET 的跨平臺實(shí)現(xiàn)的一個開源項(xiàng)目球化。
與 PhoneGap 等框架不同的是秽晚，Xamarin 可以在 iOS 和 Android 剛推出新的功能時，第一時間調(diào)用相應(yīng)的 API筒愚，而使用 PhoneGap 則需要等待 PhoneGap 封裝的新的功能后才可以調(diào)用相應(yīng)的 API赴蝇。
Xamarin 的 Andriod 實(shí)現(xiàn)原理如下圖所示。
C# 代碼寫的 Andriod 應(yīng)用在運(yùn)行的在 Mono 虛擬機(jī)中巢掺，ART 可以通過 ACWs（Andriod Callable Wrappers）的方式執(zhí)行到 Mono 中的 C# 代碼句伶。C# 代碼要是想調(diào)用系統(tǒng)功能或者 Java 的實(shí)現(xiàn)類庫芍耘，可以借助 MCW（Managed Callable Wrapper）的方式來實(shí)現(xiàn)。MCW 是 JNI 的橋梁熄阻，可以使用托管代碼調(diào)用 Andriod 代碼斋竞。
5. 原生渲染
原生渲染在本篇文章中指的是由 JavaScript 開發(fā)并且由原生控件渲染，代表有 React Native秃殉、Weex坝初、快應(yīng)用。
5.1 React Native
Facebook 曾在移動端步履維艱钾军，他們認(rèn)為可以不借助任何原生開發(fā)手段來實(shí)現(xiàn) Facebook 的移動應(yīng)用鳄袍，因此在早期選擇了 HTML5，后來發(fā)現(xiàn) HTML5 的效率始終無法和原生相比吏恭，因此在 2015 年發(fā)布了 React Native拗小。
React Native 是 Facebook 早先開源的 Web UI 框架 React 在原生移動應(yīng)用平臺的衍生產(chǎn)物，底層對 Android 和 iOS 平臺的原生代碼進(jìn)行封裝樱哼，通過使用 JavaScript 就可以編寫出原生代碼哀九。
Virtual DOM 是 DOM 在內(nèi)存中的一種輕量級表達(dá)方式，可以通過不同的渲染引擎生成不同平臺下的 UI搅幅。React Native 與原生框架通過 Bridge 進(jìn)行通信阅束，如果使用 Chrome 瀏覽器進(jìn)行調(diào)試，那么所有的 JavaScript 代碼將運(yùn)行在 Chrome V8 引擎中茄唐，通過 WebSocket 和原生代碼進(jìn)行通信息裸。
5.2 Weex
Weex 是阿里開源的一款跨平臺移動開發(fā)工具，它能夠完美兼顧性能與動態(tài)性沪编，讓移動開發(fā)者通過簡捷的前端語法寫出原生級別的性能體驗(yàn)呼盆，并支持 iOS、Android蚁廓、YunOS 及 Web 等多端部署访圃。目前 Vue.js 和 Rax 這兩個前端框架被廣泛應(yīng)用于 Weex 頁面開發(fā)，因此 Weex 支持 Vue 語法和 Rax 語法纳令，而 React Native 只支持 JSX 語法挽荠。
Weex 首先將編寫的 Weex 源碼，通過 transformer 轉(zhuǎn)換成 JS Bundle平绩。然后將 JS Bundle 部署在服務(wù)器，當(dāng)接收到終端（Android漠另、Web 端捏雌、iOS 端）的 JS Bundle 請求時，將 JS Bundle 下發(fā)給終端笆搓。在終端中性湿，由 Weex 的 JS Framework 接收和執(zhí)行 JS Bundle 代碼纬傲，并且執(zhí)行數(shù)據(jù)綁定、模板編譯等操作肤频，然后輸出 JSON 格式的 Virtual DOM叹括，JS Framework 發(fā)送渲染指令給 Native ，提供 callNative 和 callJS 接口宵荒，方便 JS Framework 和 Native 的通信汁雷。
5.3 快應(yīng)用
2018 年 3 月份，由小米报咳，OPPO侠讯，VIVO，華為等 10 家國內(nèi)主流廠商成立了快應(yīng)用聯(lián)盟暑刃∠徜觯快應(yīng)用介于移動網(wǎng)頁和原生應(yīng)用之間，第三方應(yīng)用以移動網(wǎng)頁的形式進(jìn)行開發(fā)岩臣，最終得到原生渲染的效果體驗(yàn)溜嗜。快應(yīng)用框架深度集成進(jìn)各手機(jī)廠商的手機(jī)操作系統(tǒng)中架谎，可以在操作系統(tǒng)層面形成用戶需求與應(yīng)用服務(wù)的無縫連接粱胜，很多只用在原生應(yīng)用中才能使用的功能，在快應(yīng)用中可以很方便的實(shí)現(xiàn)狐树，享受原生應(yīng)用體驗(yàn)焙压，同時不用擔(dān)心分發(fā)留存等問題，資源消耗也比較少抑钟。對于每臺手機(jī)設(shè)備涯曲，應(yīng)用可以從多個系統(tǒng)入口，引用用戶體驗(yàn)產(chǎn)品在塔。
與 React Native 和 Weex 相比主要有兩點(diǎn)不同：
- 快應(yīng)用自身不支持 Vue 或 React 語法幻件，它采用的是 JavaScript 開發(fā)。
- React Native 和 Weex 的渲染引擎是集成到框架中的蛔溃，每一個 APP 都需要打包一份绰沥，安裝包體積較大，快應(yīng)用渲染引擎是集成到 ROM 中的贺待，應(yīng)用中無需打包徽曲，安裝包體積小。
和微信小程序很像麸塞，快應(yīng)用本質(zhì)上也是要建立次級生態(tài)秃臣，快應(yīng)用的架構(gòu)如下圖所示。
快應(yīng)用實(shí)現(xiàn)劃分為編譯時、運(yùn)行時兩個方面奥此，UX 頁面源碼經(jīng)過編譯時得到 JS弧哎，然后經(jīng)過運(yùn)行時得到界面 UI。每一個頁面由 HTML+CSS+JS 組成稚虎，編譯運(yùn)行后得到內(nèi)存中的 DOM 樹撤嫩。多個頁面組成一個項(xiàng)目，編譯后得到 rpk 文件蠢终，最終運(yùn)行時以應(yīng)用形態(tài)呈現(xiàn)序攘。
快應(yīng)用推出 1 年后仍然不溫不火，面對微信小程序蜕径，快應(yīng)用在流量和入口等關(guān)鍵數(shù)據(jù)都無法與小程序匹敵两踏，未來發(fā)展堪憂。
6. 自繪 UI
自繪 UI 指的是通過在不同平臺實(shí)現(xiàn)一個統(tǒng)一接口的渲染引擎來繪制 UI兜喻，而不依賴系統(tǒng)平臺的原生控件梦染，這樣做可以保證不同平臺 UI 的一致性。不用像 React Native 一樣朴皆，隨著不同平臺系統(tǒng)版本的變化帕识，開發(fā)者還需要處理不同平臺的差異，甚至有些特性只能在單個平臺上實(shí)現(xiàn)遂铡，這樣無法保證不同平臺 UI 的一致性肮疗。自繪 UI 框架的代表有 Qt 和 Flutter。
6.1 Qt
Qt 產(chǎn)生的時間很早扒接，Qt 第一版于 1991 年由 Trolltech 發(fā)布伪货。后來在 2008 年，Nokia 斥資 1.5 億美元收購 TrollTech钾怔，將 Qt 應(yīng)用于 Symbian 程序開發(fā)碱呼。2012 年 8 月 9 日，Nokia 將 Qt 以 400 萬歐元的價格出售給 Digia宗侦。2016 年 Qt Group Plc 從 Digia 分拆出來愚臀，2014 年 Qt 開始支持移動端的 Android、iOS矾利、Wp 平臺姑裂。雖然 Qt 在 PC 領(lǐng)域發(fā)展良好，但在移動端表現(xiàn)不佳男旗，很少有人提及或者用 Qt 去開發(fā)移動端舶斧。
6.2 Flutter
Flutter 是谷歌的移動 UI 框架，可以快速在 Android 和 iOS 上構(gòu)建高質(zhì)量的原生用戶界面剑肯， 它的前身是谷歌試驗(yàn)項(xiàng)目 Sky捧毛。
Futter 提出了一切皆 Widget 的概念，除了基本的文本让网、圖片呀忧、卡片、輸入框溃睹，布局方式和動畫等也都是由 Widget 組成的而账。通過使用不同類型的 Widget，就可以實(shí)現(xiàn)復(fù)雜度的界面因篇。
Flutter 框架采用了分層設(shè)計(jì)泞辐，此設(shè)計(jì)的目標(biāo)是幫助開發(fā)者使用更少的代碼完成更多工作。例如竞滓，Material 層是由 widgets 層的普通 widget 組成的咐吼，而 widgets 層本身是通過來自 rendering 層的低級對象構(gòu)建的。
目前在 Flutter 基礎(chǔ)上開發(fā)的框架已經(jīng)開始出現(xiàn)商佑，這也證明了業(yè)界普遍開始認(rèn)可 Flutter锯茄，并開始進(jìn)行嘗試。
總結(jié)
跨平臺技術(shù)的分類沒有標(biāo)準(zhǔn)的答案茶没，這里也只是粗略的進(jìn)行分類肌幽，并對每個分類的主流框架進(jìn)行介紹，實(shí)際上還有很多框架沒有提到抓半，它們不是沒落了喂急，就是缺點(diǎn)明顯難以使用，再就是大公司的 KPI 產(chǎn)物笛求±纫疲跨平臺技術(shù)的演進(jìn)好比百家爭鳴，極大的促進(jìn)了跨平臺技術(shù)的發(fā)展探入。在我看來狡孔，這些技術(shù)讓不同技術(shù)分支的程序員都可以參與到移動開發(fā)中，享受移動開發(fā)的樂趣新症，從這個角度來看這些跨平臺技術(shù)的優(yōu)劣之分是很難去評判的步氏。我更希望有一個框架能統(tǒng)一整個跨平臺技術(shù)，這個框架會是 Flutter 嗎徒爹？還是下一個未知的框架荚醒？你更看好哪個跨平臺技術(shù)呢？
