移動開發的跨平臺技術演進

　　移動開發的跨平臺技術演進

　　1. 跨平臺技術的誕生

　　我是2010年開始從事的Android開發，當時會Android和iOS開發的不多，也不火，全部人都在「摸着河底過河」，項目更沒有第三方框架一說，大都是本身寫的，不像如今各類的框架滿天飛。隨着移動開發的發展，互聯網公司也是層出不窮，有些公司迫於競爭，想要更迅速的更省成本的進行開發，就再也不知足Android端一套代碼，iOS端一套代碼。與此同時，其餘技術領域和各大公司也都覬覦着這份大蛋糕，紛紛推出相關的技術，這樣跨平臺技術應運而生，而且開始在公司中生根發芽。

　　Android和iOS生態太大了，咱們能夠把它們比做第一級生態，想要顛覆這兩個系統的曾經出現過，但都失敗了，所以創建次級生態是最穩妥的策略，Android平臺更加開放，所以次級生態的中心就是Android，次生態的形式多種多樣，好比在Android系統的基礎上魔改創建本身的生態，再或者推出各類跨平臺技術創建生態。跨平臺技術產生的框架實在太多了，不少還沒等咱們去學去了解，它們就沒落了，成爲了跨平臺技術的發展的一個過分產物。跨平臺技術的產物是不靠譜仍是趨勢，我想讀完本篇文章你會有本身的理解。

　　跨平臺技術的分類沒有標準的答案，這裏把它們分類爲5種，分別Web App、Hybrid App、語言編譯轉換、原生渲染、自繪UI。下面分別介紹它們。

　　2. Web App

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

　　性能低，操做體驗很差

　　沒法調用原生API，不少功能沒法實現，

　　依賴於網絡，網速慢時體驗不好，而且沒有離線功能，優化很差的話會消耗流量

　　只能作爲一個臨時的入口，用戶留存率低

　　在Web App的基礎上，又出現了幾個進化者，這裏主要介紹PWA。

　　2.1 PWA

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

　　用Service Worker + HTTPS +Cache Api + indexedDB 等一系列web技術實現離線加載和緩存

　　實現了推送和通知

　　能夠直接添加到手機的桌面上

　　使用Service Worker能夠進行後臺同步

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

　　遊覽器對PWA技術支持還不夠全面， 不是每一款遊覽器都能100%的支持PWA

　　國內一些手機廠商對Android系統各類魔改，對PWA的兼容性很差，甚至不支持PWA

　　平臺的競爭，iOS對PWA的支持力度遠遠低於Android，因此PWA在iOS上的體驗打了折扣。PWA面對相似的微信小程序和快應用的競爭中，並無優點。

　　3. Hybrid App

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

　　關於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等等，咱們大概來了解一下。

　　3.1 Cordova

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

　　Cordova一樣使用WebView來展現界面，插件是Cordova中不可或缺的一部分，Apache Cordova維護了名爲Core Plugins的插件，這些核心插件爲App提供訪問設備功能，如電池，相機，聯繫人等。除了核心插件以外，還有一些第三方插件可使用，你也能夠開發一個本身的插件。

　　3.2 Ionic

　　Ionic Framework是一個開源UI工具包，最先的目標是使用HTML，CSS和JavaScript等Web技術開發移動應用程序。因爲Web技術的這一基礎，Ionic能夠在網絡運行的任何地方運行，好比 iOS，Android，瀏覽器，Electron，PWA等等。

　　目前，Ionic Framework已與Angular正式集成，但對Vue和React的支持正在開發中。

　　3.3 VasSonic

　　VasSonic是由騰訊VAS團隊開發的輕量級高性能混合框架，旨在加速在Android和iOS平臺上運行的H5首屏。VasSonic不只支持服務器呈現的靜態或動態網站，並且還完美兼容Web離線資源。VasSonic使用自定義的url鏈接而不是原始網絡鏈接來請求索引html，所以它能夠提早或並行請求資源以免等待視圖初始化。在這種並行的狀況下，VasSonic能夠經過WebKit或Blink內核讀取和呈現部分數據，而無需花費太多時間等待數據流的結束。

　　3.4 微信小程序

　　微信小程序的主要開發語言是 JavaScript ，小程序的開發同普通的網頁開發相比有很大的類似性。

　　小程序的運行環境分紅渲染層和邏輯層，這兩層分別由2個線程管理，渲染層的界面使用了WebView 進行渲染，邏輯層採用JsCore線程運行JS腳本。這兩個線程的通訊會經由微信客戶端（Native）中的JSBridage作中轉。邏輯層發送網絡請求也經由Native轉發。

　　其中 WXML 模板和 WXSS 樣式工做在渲染層，JS 腳本工做在邏輯層。

　　微信小程序和PWA都是基於Web技術，原理的區別是小程序相似Hybrid架構，WebView渲染基本的網頁內容，對渲染性能要求較高的組件，經過原生組件來實現，好比相機、視頻、地圖等等，另外傳統Web沒法訪問的本地能力，須要經過JS SDK來實現，而PWA則是使用多種技術加強Web能力，以達到接近Native應用的體驗。

　　微信小程序自己和App就不是競爭關係，更多的是一個推廣渠道，它更像是一張海報，用於快速推廣倒流，而App則是要推廣的對象。微信小程序的缺點很明顯，體驗上沒法跟App相提並論，功能依託並受限於微信，沒法進行拓展。能夠說微信小程序就是創建了次級生態，這個生態中微信說的算，其餘對手的發展會受到威脅。

　　4. 語言編譯轉換

　　語言編譯轉換指的是直接將某個語言編譯爲一個平臺下的二進制文件。比較有名的是Xamarin框架，雖然它在 Android平臺是內嵌了Mono虛擬機來實現的，但在 iOS平臺下是以AOT 的方式編譯爲二進制文件的，因此把它歸到語言編譯轉換類型。

　　4.1 Xamarin

　　Xamarin始創於2011年，2016年被微軟正式收購。Xamarin是Mono項目的一個分支，基於.NET的跨平臺實現的一個開源項目。

　　與PhoneGap等框架不一樣的是，Xamarin能夠在iOS和Android剛推出新的功能時，第一時間調用相應的API，而使用PhoneGap則須要等待PhoneGap封裝的新的功能後才能夠調用相應的API。

　　C#代碼寫的Andriod應用在運行的在Mono虛擬機中，ART能夠經過ACWs（Andriod Callable Wrappers）的方式執行到Mono中的C#代碼。C#代碼要是想調用系統功能或者Java的實現類庫，能夠藉助MCW（Managed Callable Wrapper）的方式來實現。MCW是JNI的橋樑，可使用託管代碼調用Andriod代碼。

　　5. 原生渲染

　　原生渲染在本篇文章中指的是由JavaScript開發而且由原生控件渲染，表明有React Native、Weex、快應用。

　　5.1 React Native

　　Facebook曾在移動端寸步難行，他們認爲能夠不借助任何原生開發手段來實現Facebook的移動應用，所以在早期選擇了HTML5，後來發現HTML5的效率始終沒法和原生相比，所以在2015年發佈了React Native。

　　React Native是Facebook早先開源的 Web UI框架React在原生移動應用平臺的衍生產物，底層對Android和iOS平臺的原生代碼進行封裝，經過使用JavaScript就能夠編寫出原生代碼。

　　Virtual DOM是DOM在內存中的一種輕量級表達方式，能夠經過不一樣的渲染引擎生成不一樣平臺下的UI。React Native與原生框架經過Bridge進行通訊，若是使用Chrome瀏覽器進行調試，那麼全部的JavaScript代碼將運行在Chrome V8引擎中，經過WebSocket和原生代碼進行通訊。

　　5.2 Weex

　　Weex 是阿里開源的一款跨平臺移動開發工具，它可以完美兼顧性能與動態性，讓移動開發者經過簡捷的前端語法寫出原生級別的性能體驗，並支持iOS、Android、YunOS及Web等多端部署。目前 Vue.js 和 Rax 這兩個前端框架被普遍應用於 Weex 頁面開發，所以Weex支持Vue語法和Rax語法，而React Native只支持JSX語法。

　　Weex首先將編寫的Weex源碼，經過transformer轉換成JS Bundle。而後將JS Bundle部署在服務器，當接收到終端（Android、Web端、iOS端）的JS Bundle請求時，將JS Bundle下發給終端。在終端中，由Weex的JS Framework 接收和執行JS Bundle代碼，而且執行數據綁定、模板編譯等操做，而後輸出JSON 格式的 Virtual DOM，JS Framework發送渲染指令給Native ，提供 callNative 和 callJS 接口，方便 JS Framework 和 Native 的通訊。

　　5.3 快應用

　　2018年3月份，由小米，OPPO，VIVO，華爲等10家國內主流廠商成立了快應用聯盟。快應用介於移動網頁和原生應用之間，第三方應用以移動網頁的形式進行開發，最終獲得原生渲染的效果體驗。快應用框架深度集成進各手機廠商的手機操做系統中，能夠在操做系統層面造成用戶需求與應用服務的無縫鏈接，不少只用在原生應用中才能使用的功能，在快應用中能夠很方便的實現，享受原生應用體驗，同時不用擔憂分發留存等問題，資源消耗也比較少。對於每臺手機設備，應用能夠從多個系統入口，引用用戶體驗產品。

　　與React Native和Weex相比主要有兩點不一樣：

　　快應用自身不支持Vue或React語法，它採用的是JavaScript開發。

　　React Native和Weex的渲染引擎是集成到框架中的，每個APP都須要打包一份，安裝包體積較大，快應用渲染引擎是集成到ROM中的，應用中無需打包，安裝包體積小。

　　和微信小程序很像，快應用本質上也是要創建次級生態。

　　快應用實現劃分爲編譯時、運行時兩個方面，UX頁面源碼通過編譯時獲得JS，而後通過運行時獲得界面UI。每個頁面由HTML+CSS+JS組成，編譯運行後獲得內存中的DOM樹。多個頁面組成一個項目，編譯後獲得rpk文件，最終運行時以應用形態呈現。

　　快應用推出1年後仍然不溫不火，面對微信小程序，快應用在流量和入口等關鍵數據都沒法與小程序匹敵，將來發展堪憂。

　　6. 自繪UI

　　自繪UI指的是經過在不一樣平臺實現一個統一接口的渲染引擎來繪製UI，而不依賴系統平臺的原生控件，這樣作能夠保證不一樣平臺UI的一致性。不用像React Native同樣，隨着不一樣平臺系統版本的變化，開發者還須要處理不一樣平臺的差別，甚至有些特性只能在單個平臺上實現，這樣沒法保證不一樣平臺UI的一致性。自繪UI框架的表明有Qt和Flutter。

　　6.1 Qt

　　Qt產生的時間很早，Qt 初版於 1991 年由 Trolltech 發佈。後來在 2008 年，Nokia 斥資 1.5 億美圓收購 TrollTech，將 Qt 應用於 Symbian 程序開發。2012 年 8 月 9 日，Nokia 將 Qt 以 400 萬歐元的價格出售給 Digia。2016年Qt Group Plc從Digia分拆出來，2014年Qt開始支持移動端的Android、iOS、Wp平臺。雖然Qt在PC領域發展良好，但在移動端表現不佳，不多有人說起或者用Qt去開發移動端。

　　6.2 Flutter

　　Flutter是谷歌的移動UI框架，能夠快速在Android和iOS上構建高質量的原生用戶界面， 它的前身是谷歌試驗項目Sky。

　　Futter提出了一切皆爲控件（Widget）的概念，除了基本的文本、圖片、卡片、輸入框等Widget，佈局方式和動畫等也都是Widget。經過使用不一樣類型的Widget，就能夠實現複雜度的界面。

　　Flutter框架採用了分層設計，此設計的目標是幫助開發者使用更少的代碼完成更多工做。例如，Material層是由widgets層的普通widget組成的，而widgets層自己是經過來自rendering層的低級對象構建的。

　　目前在Flutter基礎上開發的框架已經開始出現，這也證實了業界廣泛開始承認Flutter，並開始進行嘗試。

　　總結

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