一、前端三板斧

正式討論「跨端開發(fā)」這個概念前，我們可以先思考一個問題：對大部分前端工作來說，前端主要干些啥？

我個人認為，無論環(huán)境怎么變，前端基本上就是做三件事情：

• fetch data（數(shù)據(jù)獲?。?/li>
• manage state（狀態(tài)管理）
• render page（頁面渲染）

沒了。

也許有人覺得我說的太片面，其實我們可以理一理。往近了說，現(xiàn)在知識付費搞的如火如荼，動不動就搞個「XXX 源碼解析」，分析一下這些課程的主題和目錄，你就會發(fā)現(xiàn)基本都是圍繞著這三個方向展開講的；往遠了說，我們可以分析一下 Web 前端的發(fā)展歷程：

• 1995 年左右，用 HTTP/1.0 拉取數(shù)據(jù)，用第一版的 JavaScript 管理幾個前端狀態(tài)，用裸露的 HTML 標簽展示頁面

• 2005 年左右，用 HTTP/1.1 和 AJAX 拉取數(shù)據(jù)，用 JavaScript 做做表單畫畫特效，用 CSS 美化頁面

• 2010 年左右，用 HTTP/1.1 和 AJAX 拉取數(shù)據(jù)，用 jQuery 操作 DOM 處理前端邏輯，用 CSS 美化頁面

• 2015 年左右，隨著 HTML5 標準的推廣和瀏覽器性能的提升，前端開始進入「學不動了」的時代：

  • 在 fetch data 層面，除了 HTTP/1.1 和 AJAX，HTTPS 來了，HTTP/2 來了，WebSocket 也來了
  • 在 manage state 層面，Angular、React 和 Vue 先后出現(xiàn)，從現(xiàn)在看，React 的狀態(tài)驅(qū)動視圖的理念直接影響了 Flutter 和 SwiftUI 的設計
  • 在 render page 層面，除了傳統(tǒng)的 HTML + CSS，還加入了 CSS3、Canvas 等概念，音視頻功能也得到加強

• 最近幾年，網(wǎng)絡協(xié)議趨于穩(wěn)定，幾年內(nèi)也不會有啥大的變動；國內(nèi) React 和 Vue 的地位基本穩(wěn)固，一堆前端盯著 GitHub 進度條等版本更新；render 層出了不少幺蛾子，好不容易擺脫了 IE6，又來了各種小程序，同一套業(yè)務邏輯寫好幾遍不經(jīng)濟也不現(xiàn)實，這時候各種跨端方案就整出來了

經(jīng)過一番分析，這個三板斧理論看上去已經(jīng)有些道理了，我們順著這個方向再向底層思考：這三大功能是怎么實現(xiàn)的？

• fetch data 方向，最后要靠網(wǎng)絡協(xié)議棧把數(shù)據(jù)發(fā)出去，但是讓一個前端直接搞套接字編程是非常不現(xiàn)實的，所以我們需要把網(wǎng)絡操作封裝為庫，讓應用層調(diào)用
• render page 方向，最后是把相關(guān)圖元信息通過各種圖形 API（OpenGL/Metal/Vulkan/DirectX）發(fā)給 GPU 進行渲染，很多前端的圖形學路程最終都止于一個三角形，用這套技術(shù)棧去畫 UI 也極其不現(xiàn)實，更不要說排版系統(tǒng)這種工程量浩大的工作，所以這些活兒都讓相關(guān)的渲染引擎做了
• manage state 方向，你可以用全局變量管理狀態(tài)，最后的結(jié)局一定被同事打爆，現(xiàn)在主流方案都是采用各種框架和 runtime 進行狀態(tài)管理，而這個 runtime 的宿主環(huán)境，往往就是某個語言的虛擬機，同時，fetch data 的起點，也是同一個虛擬機

經(jīng)過上面的分析我們可以看出，前端的主要技術(shù)核心就兩個：虛擬機和渲染引擎，這也意味著，如果我們想要搞跨端開發(fā)，就必須得統(tǒng)一虛擬機和渲染引擎。

因為谷歌的 Blink 引擎 fork 自蘋果的 WebKit，后文為了描述方便，統(tǒng)一用 WebKit 代替瀏覽器渲染引擎

網(wǎng)頁是成本最低上手最快的跨端方案了。得益于互聯(lián)網(wǎng)開放式理念，網(wǎng)頁天生就是跨端的，無論什么渲染框架，WebView 都是必不可少的核心組件。

開發(fā)人員的接入成本也極低，主要技術(shù)就是 Web 開發(fā)那一套，前端主要頭疼的是各個渲染引擎的適配問題和性能問題。

現(xiàn)在主流的 JS Engine 是蘋果的 JavaScriptCore 和谷歌的 V8，主流的渲染引擎是蘋果的 Webkit 和谷歌的 Blink。雖然 W3C 的規(guī)范就擺在那里，各個瀏覽器廠商再根據(jù)規(guī)范實現(xiàn)瀏覽器，這也是網(wǎng)頁跨端的基礎。問題在于瀏覽器內(nèi)核實現(xiàn)總有細微差距，部分實現(xiàn)不合規(guī)范，部分實現(xiàn)本身就有 Bug，這也是前端擺脫不了適配需求的本質(zhì)原因。

另一個是性能問題。其實 WebKit 本身的渲染速度還是很快的，但是受限于一些瀏覽器特性，比如說極其復雜極其動態(tài)的 CSS 屬性，DOM 樹和 CSSOM 的合并，主線程必須掛起等待 JS 的執(zhí)行，這些都會大大降低性能，前端搞性能優(yōu)化，一般得依據(jù)這些瀏覽器特性進行減枝處理，但是再怎么優(yōu)化，在頁面性能和交互體驗上，和 Native 還是有很大的距離。

2.網(wǎng)頁 PLUS：JS Engine + WebKit + Native 能力

直接拿個 URL 扔到 WebView 里是最簡單的，其實這樣也能解決大部分問題，畢竟前端 90% 的工作都是畫 UI 寫業(yè)務邏輯，但是還有 10% 的功能做不到，比如說要和 Native 同步狀態(tài)，調(diào)用一些系統(tǒng)功能。

要實現(xiàn)客戶端和網(wǎng)頁雙向通訊的話，一般都是借助 JSBridge 進行通信。JSBridge 只是解決了 Native 和 Web 的互相調(diào)用問題，如果我想借助 Native 加強 Web 怎么辦？這時候就有了一些探索：

• 預熱：提前創(chuàng)建和初始化 WebView，甚至實現(xiàn) WebView 容器池，減少 WebView 的啟動時間

• 緩存：把常用的 Web 資源預先存在 Native 本地，然后攔截瀏覽器網(wǎng)絡請求重定向到本地，這樣就可以加快 Web 的資源加載速度（也叫“離線包”方案）；

• 劫持：比如說 Web 對網(wǎng)絡加載的控制力比較弱，部分有能力的廠商會把所有的網(wǎng)絡請求都劫持下來交給 Native 去做，這樣做可以更靈活的管理 Web 請求

• 替換：替換一般指替換 Web 的 Img 標簽和 Video 標簽，這個最常見的地方就是各大新聞類客戶端。因為新聞的動態(tài)性和實時性，新聞都是由各個編輯/自媒體通過后臺編輯下發(fā)的，這時候要利用 Web 強大的排版功能去顯示文本內(nèi)容；但是為了加載速度和觀看體驗，圖片和視頻都是 Native 組件替換的

經(jīng)過上面幾步，網(wǎng)頁的速度基本可以達到秒開的級別，這里面最典型的就是幾大新聞客戶端，大家可以上手體驗一下。

小程序，國內(nèi)的特色架構(gòu)，本質(zhì)上是微信成為流量黑洞后，想成為流量分發(fā)市場管理和分發(fā)自己的流量，所以這是個商業(yè)味道很重的框架。

小程序在技術(shù)上沒什么特別的創(chuàng)新點，本質(zhì)上就是閹割版的網(wǎng)頁，所以微信小程序出來后各個流量寡頭都推出了自己的小程序，正如有人吐槽的，小程序的實現(xiàn)方式有 9 種，底層實現(xiàn)多樣化，各個廠實現(xiàn)還沒有統(tǒng)一的標準，最后就是給開發(fā)者喂屎，我也沒啥好介紹的，就這樣吧。

React 2013 年發(fā)布，兩年后 React Native 就發(fā)布了，前幾種跨段方案基本都是基于瀏覽器技術(shù)的，RN 這個跨段方案的創(chuàng)新性在于它保留了 JS Engine，在渲染引擎這條路上，他沒有自己造輪子，而是復用了現(xiàn)有的 Native 渲染管線。

這樣做的好處在于，保留 JS Engine，可以最大程度的復用 Web 生態(tài)，畢竟 GitHub 上輪子最多的語言就是 JavaScript 了；復用 Native RenderPipeLine，好處在于脫離 WebKit 的歷史包袱，相對來說渲染管線更短，性能自然而然就上去了。

那么問題來了，RN 是如何做到跨端的？這個其實全部仰仗于 React 的 vdom。

vdom

前端社區(qū)上有些文章討論 vdom，總會從性能和開發(fā)便捷性上切入講解，從純 Web 前端的角度看，這些的確是 vdom 的特點，但是這不是 vdom 真正火起來的原因。vdom 更大的價值在于，人們從 vdom 身上看到跨端開發(fā)的希望，所以在 React 出現(xiàn)后 React Native 緊跟著出現(xiàn)是一件非常自然的事情。為什么這么說？這個就要先溯源一下 UI 開發(fā)的范式。

UI 開發(fā)主要有兩大范式：Immediate Mode GUI（立即模式） 和 Retained Mode GUI（保留模式）。

簡單來說，IMGUI 每幀都是全量刷新，主要用在實時性很高的領域（游戲 CAD 等）；RMGUI 是最廣泛的 UI 范式，每個組件都被封裝到一個對象里，便于狀態(tài)管理和復雜的嵌套布局。無論是網(wǎng)頁、iOS、Android 還是 Qt 等桌面開發(fā)領域，都是基于 RMGUI 的。這兩者的具體細節(jié)差異，可以看這篇知乎回答和這個 Youtube 視頻。

我們再回到 React Native 中，既然 iOS Android 的原生渲染管線都是 RMGUI 范式，那么總是有相似點的，比如說 UI 都是樹狀嵌套布局，都有事件回調(diào)等等。這時候 vdom 的作用就出來了：

vdom 作為一個純對象，可以清晰的提煉出出布局的嵌套結(jié)構(gòu)，而且這個抽象描述是平臺無關(guān)的，那么我們就可以利用 JS 生成 vdom，然后將 vdom 映射到 Native 的布局結(jié)構(gòu)上，最終讓 Native 渲染視圖，以達到跨平臺開發(fā)的目的。

到這里如果你有些編譯原理的知識，你就會發(fā)現(xiàn) vdom 和 IR 有些類似，同樣都是抽象于平臺的中間態(tài)，vdom 上接 React 下接 Native RenderPipeLine，IR 上接編譯器前端下接編譯器后端，我們只要關(guān)心前半段的邏輯處理，臟活累活都讓后半部分做。

Hermes

2019 年 Facebook 為了優(yōu)化 React Native 的性能，直接推出了新的 JS Engine——Hermes，F(xiàn)B 官方博文介紹了很多的優(yōu)點，我個人認為最大的亮點是加入 AOT，傳統(tǒng)的 JS 加工加載流程是這樣的：

Babel 語法轉(zhuǎn)換 → Minify 代碼壓縮 → install 下載代碼 → Parse 轉(zhuǎn)為 AST → Compile 編譯 → Execute 執(zhí)行

Hermes 加入 AOT 后，Babel、Minify、Parse 和 Compile 這些流程全部都在開發(fā)者電腦上完成，直接下發(fā)字節(jié)碼讓 Hermes 運行就行。

這樣做的好處在于，可以大大縮短 JS 的編譯時間，不信的話大家可以用 Chrome 分析幾個大型網(wǎng)站，JS 的解析加載時間基本占時都是 50% 以上，部分重型網(wǎng)站可能占時 90%，這對桌面應用來說還好，對于電量和 CPU 都要弱上一線的移動平臺來說，這些都是妥妥的性能殺手，Hermes 的加入可以大大改善這一情況。

目前 React Native 0.64 也支持 Hermes 了，如果有做 RN 業(yè)務的同學可以玩一玩，看看在 iOS 上的性能提升有多大。

Flutter 是最近比較火的一個跨端方案，也有不少人認為這是最終的跨端方案，畢竟桌面軟件時代，最終勝出跨端方案就是 Qt，他們的共同特點就是自帶了一套渲染引擎，可以抹平終端差異。

Flutter 的創(chuàng)造還是很有意思的，這里有個 Eric 的訪談，視頻中說 Eric 差不多有十幾年的 Web 渲染領域工作經(jīng)驗，有一次在 Chrome 內(nèi)部他們做了個實驗，把一些亂七八糟的 Web 規(guī)范去掉后，一些基準測試甚至能快 20 倍，因此 Google 內(nèi)部開始立項，F(xiàn)lutter 的出現(xiàn)了。至于 Flutter 選擇 Dart 的理由，坊間一直傳說 Flutter 開發(fā)組隔壁就是 Dart 開發(fā)組，離得近就好 PY 交易，反正 Dart 也沒人用，沒啥歷史包袱，可以很好的相應 Flutter 的需求。

Flutter 的架構(gòu)也是比較清晰的：

• 虛擬機用的 Dart VM，Dart 同時支持 JIT 和 AOT，可以同時保證開發(fā)效率和運行效率
• 渲染引擎先把 Dart 構(gòu)建的視圖數(shù)據(jù)傳遞給 Skia，然后 Skia 加工數(shù)據(jù)交給 OpenGL/Metal 這兩個圖形 API，最終交給 GPU 渲染，整體上比 WebKit 的渲染流水線清晰不少

從純粹程度上看，F(xiàn)lutter 是做的最徹底的，虛擬機和渲染引擎都沒有用業(yè)內(nèi)的成熟方案，而是自造了一套，好處就是沒啥適配壓力，壞處就是太新了，業(yè)務開發(fā)時往往會遇到無輪子可用的尷尬狀態(tài)，如果谷歌大力推廣，國內(nèi)大廠持續(xù)跟進，前景還是很光明的。

社區(qū)里有一種聲音，認為 Flutter 最大的敗筆就是不能用 JavaScript 開發(fā)。這時候就會有人想，如果我們把 Web 技術(shù)和 Flutter 技術(shù)結(jié)合起來，用 JS Engine 對接世界上最大最活躍的 JS 社區(qū)，用 Flutter 渲染引擎對接高性能渲染體驗，國安民樂，豈不美哉？

目前來說一些大廠還是做了一些探索，我看了一些分析和項目架構(gòu)，感覺就是做了個低配版的 React Native，React Native 的現(xiàn)有架構(gòu)有一個性能瓶頸就是跨語言調(diào)用成本比較高，而這些大廠的調(diào)用鏈路多達 4 步：JS -> C++ -> Dart -> C++，更加喪心病狂，目前看無論是上手和推廣都是沒有直接用 RN or Flutter 方便。

跨端方案不可能只有好處的，各個方案的壞處也是很明顯的，我下面簡單列一下：

• 網(wǎng)頁：性能是個過去不的坎兒，而且 Apple 明確指出不歡迎 WebView 套殼 APP，有拒審危險
• 網(wǎng)頁 PLUS：技術(shù)投入很高，基本只能大廠玩轉(zhuǎn)
• 小程序：對開發(fā)者不友好，技術(shù)半衰期極短
• React Native：基本只能畫 UI，一旦做深了，只會 JS 根本解決不了問題，Java OC 都得學，對開發(fā)者要求比較高
• Flutter：Android 支持很好，但 iOS 平臺的交互割裂感還是很強的，而且和 RN 問題一樣，一旦做深了，必須學習客戶端開發(fā)知識，對開發(fā)者要求比較高

總的來說，在犧牲一定用戶體驗的前提下，跨端方案可以提高開發(fā)者的開發(fā)效率和公司的運行效率，我個人認為，只要某個方案的 ROI 比較高，其實是還是可以投入到生產(chǎn)的。

本文到此就結(jié)束了，我把各個跨端技術(shù)提煉為為虛擬機和渲染引擎技術(shù)，然后以這兩個核心技術(shù)的角度去拆解各個跨端方案。一旦概念理清，在面對性能調(diào)優(yōu)等技術(shù)場景時，就能抓住主要矛盾，更快更好的發(fā)現(xiàn)問題，解決問題。

作者：鹵蛋實驗室
來源：掘金
著作權(quán)歸作者所有。商業(yè)轉(zhuǎn)載請聯(lián)系作者獲得授權(quán)，非商業(yè)轉(zhuǎn)載請注明出處。