關聯繫列
ReactNative入門系列
React Native組件
本文首發於公衆號「劉望舒」
前言
本來這一篇應該介紹如何搭建Flutter開發環境的，但我想在瞭解Flutter前，不妨瞭解一下跨平臺技術的演進，這樣更有助於學習Flutter，也能認清Flutter的優勢和本質。這篇文章還有一個目的，就是希望大家是玩技術的人，而不是被技術玩的人，對於不同的技術要有自己的判斷。
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就成了這個公司的主流，業界其他的公司也都紛紛效仿。
原生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的體系結構圖如下所示。
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。
Xamarin的Andriod實現原理如下圖所示。
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，就可以實現複雜度的界面。
Flutter框架採用了分層設計，此設計的目標是幫助開發者使用更少的代碼完成更多工作。例如，Material層是由widgets層的普通widget組成的，而widgets層本身是通過來自rendering層的低級對象構建的。
目前在Flutter基礎上開發的框架已經開始出現，這也證明了業界普遍開始認可Flutter，並開始進行嘗試。
總結
跨平臺技術的分類沒有標準的答案，這裏也只是粗略的進行分類，並對每個分類的主流框架進行介紹，實際上還有很多框架沒有提到，它們不是沒落了，就是缺點明顯難以使用，再就是大公司的KPI產物。跨平臺技術的演進好比百家爭鳴，極大的促進了跨平臺技術的發展。在我看來，這些技術讓不同技術分支的程序員都可以參與到移動開發中，享受移動開發的樂趣，從這個角度來看這些跨平臺技術的優劣之分是很難去評判的。我更希望有一個框架能統一整個跨平臺技術，這個框架會是Flutter嗎？還是下一個未知的框架？你更看好哪個跨平臺技術呢？
感謝
https://visualstudio.microsoft.com/xamarin/
https://phonegap.com/
https://cordova.apache.org/
https://github.com/Tencent/VasSonic
https://book.flutterchina.club/chapter1/mobile_development_intro.html
https://developers.weixin.qq.com/miniprogram/dev/quickstart/basic/framework.html
https://docs.microsoft.com/zh-cn/xamarin/android/platform/binding-java-library/
https://blog.csdn.net/baidu_browser/article/details/64440238
http://fex.baidu.com/blog/2015/05/cross-mobile/
https://www.cnblogs.com/yexiaochai/p/4921635.html
https://www.infoq.cn/article/why-is-flutter-revolutionary
https://blog.csdn.net/MeituanTech/article/details/81567238
http://www.uml.org.cn/AJAX/201812283.asp
https://blog.csdn.net/powertoolsteam/article/details/51496229
https://www.jianshu.com/p/32285c709682
https://www.jianshu.com/p/098af61bbe04
https://segmentfault.com/a/1190000012353473?utm_source=tag-newest
https://www.uisdc.com/web-hybrid-native-app
https://www.jianshu.com/p/7e0bd4708ba7
