本文是我在學(xué)習(xí)多個(gè)平臺(tái) UI 框架后的一些感觸，受精力和技術(shù)水平所限浪南，文中定有不足之處笼才，請(qǐng)各位大佬多多指教
如果你覺(jué)得我的文章對(duì)你有幫助，在收藏的過(guò)程中络凿，一定要記得點(diǎn)贊和點(diǎn)在看哦骡送，謝謝你，這對(duì)我真的很重要??絮记！
一摔踱、前端三板斧
正式討論「跨端開(kāi)發(fā)」這個(gè)概念前，我們可以先思考一個(gè)問(wèn)題：對(duì)大部分前端工作來(lái)說(shuō)到千，前端主要干些啥昌渤？
我個(gè)人認(rèn)為，無(wú)論環(huán)境怎么變憔四，前端基本上就是做三件事情：
- fetch data（數(shù)據(jù)獲取）
- manage state（狀態(tài)管理）
- render page（頁(yè)面渲染）
沒(méi)了潜支。
也許有人覺(jué)得我說(shuō)的太片面甸赃，其實(shí)我們可以理一理。往近了說(shuō)冗酿，現(xiàn)在知識(shí)付費(fèi)搞的如火如荼埠对，動(dòng)不動(dòng)就搞個(gè)「XXX 源碼解析」，分析一下這些課程的主題和目錄裁替，你就會(huì)發(fā)現(xiàn)基本都是圍繞著這三個(gè)方向展開(kāi)講的项玛；往遠(yuǎn)了說(shuō)，我們可以分析一下 Web 前端的發(fā)展歷程：
1995 年左右弱判，用 HTTP/1.0 拉取數(shù)據(jù)襟沮，用第一版的 JavaScript 管理幾個(gè)前端狀態(tài)，用裸露的 HTML 標(biāo)簽展示頁(yè)面
2005 年左右昌腰，用 HTTP/1.1 和 AJAX 拉取數(shù)據(jù)开伏，用 JavaScript 做做表單畫(huà)畫(huà)特效，用 CSS 美化頁(yè)面
2010 年左右遭商，用 HTTP/1.1 和 AJAX 拉取數(shù)據(jù)固灵，用 jQuery 操作 DOM 處理前端邏輯，用 CSS 美化頁(yè)面
-
2015 年左右劫流，隨著 HTML5 標(biāo)準(zhǔn)的推廣和瀏覽器性能的提升巫玻，前端開(kāi)始進(jìn)入「學(xué)不動(dòng)了」的時(shí)代：
- 在 fetch data 層面，除了 HTTP/1.1 和 AJAX祠汇，HTTPS 來(lái)了大审，HTTP/2 來(lái)了，WebSocket 也來(lái)了
- 在 manage state 層面座哩，Angular、React 和 Vue 先后出現(xiàn)粮彤，從現(xiàn)在看根穷，React 的狀態(tài)驅(qū)動(dòng)視圖的理念直接影響了 Flutter 和 SwiftUI 的設(shè)計(jì)
- 在 render page 層面，除了傳統(tǒng)的 HTML + CSS导坟，還加入了 CSS3屿良、Canvas 等概念，音視頻功能也得到加強(qiáng)
最近幾年惫周，網(wǎng)絡(luò)協(xié)議趨于穩(wěn)定尘惧，幾年內(nèi)也不會(huì)有啥大的變動(dòng)；國(guó)內(nèi) React 和 Vue 的地位基本穩(wěn)固递递，一堆前端盯著 GitHub 進(jìn)度條等版本更新喷橙；render 層出了不少幺蛾子啥么，好不容易擺脫了 IE6，又來(lái)了各種小程序贰逾，同一套業(yè)務(wù)邏輯寫(xiě)好幾遍不經(jīng)濟(jì)也不現(xiàn)實(shí)悬荣，這時(shí)候各種跨端方案就整出來(lái)了
經(jīng)過(guò)一番分析，這個(gè)三板斧理論看上去已經(jīng)有些道理了疙剑，我們順著這個(gè)方向再向底層思考：這三大功能是怎么實(shí)現(xiàn)的氯迂？
- fetch data 方向，最后要靠網(wǎng)絡(luò)協(xié)議棧把數(shù)據(jù)發(fā)出去言缤，但是讓一個(gè)前端直接搞套接字編程是非常不現(xiàn)實(shí)的嚼蚀，所以我們需要把網(wǎng)絡(luò)操作封裝為庫(kù)，讓?xiě)?yīng)用層調(diào)用
- render page 方向管挟，最后是把相關(guān)圖元信息通過(guò)各種圖形 API（OpenGL/Metal/Vulkan/DirectX）發(fā)給 GPU 進(jìn)行渲染轿曙，很多前端的圖形學(xué)路程最終都止于一個(gè)三角形，用這套技術(shù)棧去畫(huà) UI 也極其不現(xiàn)實(shí)哮独，更不要說(shuō)排版系統(tǒng)這種工程量浩大的工作拳芙，所以這些活兒都讓相關(guān)的渲染引擎做了
- manage state 方向，你可以用全局變量管理狀態(tài)皮璧，最后的結(jié)局一定被同事打爆舟扎，現(xiàn)在主流方案都是采用各種框架和 runtime 進(jìn)行狀態(tài)管理，而這個(gè) runtime 的宿主環(huán)境悴务，往往就是某個(gè)語(yǔ)言的虛擬機(jī)睹限，同時(shí)，fetch data 的起點(diǎn)讯檐，也是同一個(gè)虛擬機(jī)
經(jīng)過(guò)上面的分析我們可以看出羡疗，前端的主要技術(shù)核心就兩個(gè)：虛擬機(jī)和渲染引擎，這也意味著别洪，如果我們想要搞跨端開(kāi)發(fā)叨恨，就必須得統(tǒng)一虛擬機(jī)和渲染引擎。
二挖垛、虛擬機(jī)和渲染引擎
1.網(wǎng)頁(yè)：JS Engine + WebKit
因?yàn)楣雀璧?Blink 引擎 fork 自蘋(píng)果的 WebKit痒钝，后文為了描述方便，統(tǒng)一用 WebKit 代替瀏覽器渲染引擎
網(wǎng)頁(yè)是成本最低上手最快的跨端方案了痢毒。得益于互聯(lián)網(wǎng)開(kāi)放式理念送矩，網(wǎng)頁(yè)天生就是跨端的，無(wú)論什么渲染框架哪替，WebView 都是必不可少的核心組件栋荸。
開(kāi)發(fā)人員的接入成本也極低，主要技術(shù)就是 Web 開(kāi)發(fā)那一套，前端主要頭疼的是各個(gè)渲染引擎的適配問(wèn)題和性能問(wèn)題晌块。
現(xiàn)在主流的 JS Engine 是蘋(píng)果的 JavaScriptCore 和谷歌的 V8爱沟，主流的渲染引擎是蘋(píng)果的 Webkit 和谷歌的 Blink。雖然 W3C 的規(guī)范就擺在那里摸袁，各個(gè)瀏覽器廠商再根據(jù)規(guī)范實(shí)現(xiàn)瀏覽器钥顽，這也是網(wǎng)頁(yè)跨端的基礎(chǔ)。問(wèn)題在于瀏覽器內(nèi)核實(shí)現(xiàn)總有細(xì)微差距靠汁，部分實(shí)現(xiàn)不合規(guī)范蜂大，部分實(shí)現(xiàn)本身就有 Bug，這也是前端擺脫不了適配需求的本質(zhì)原因蝶怔。
另一個(gè)是性能問(wèn)題奶浦。其實(shí) WebKit 本身的渲染速度還是很快的，但是受限于一些瀏覽器特性踢星，比如說(shuō)極其復(fù)雜極其動(dòng)態(tài)的 CSS 屬性澳叉，DOM 樹(shù)和 CSSOM 的合并，主線程必須掛起等待 JS 的執(zhí)行沐悦，這些都會(huì)大大降低性能成洗，前端搞性能優(yōu)化，一般得依據(jù)這些瀏覽器特性進(jìn)行減枝處理藏否，但是再怎么優(yōu)化瓶殃，在頁(yè)面性能和交互體驗(yàn)上，和 Native 還是有很大的距離副签。
2.網(wǎng)頁(yè) PLUS：JS Engine + WebKit + Native 能力
直接拿個(gè) URL 扔到 WebView 里是最簡(jiǎn)單的遥椿，其實(shí)這樣也能解決大部分問(wèn)題，畢竟前端 90% 的工作都是畫(huà) UI 寫(xiě)業(yè)務(wù)邏輯淆储，但是還有 10% 的功能做不到冠场，比如說(shuō)要和 Native 同步狀態(tài)，調(diào)用一些系統(tǒng)功能本砰。
要實(shí)現(xiàn)客戶(hù)端和網(wǎng)頁(yè)雙向通訊的話碴裙，一般都是借助 JSBridge 進(jìn)行通信，《JSBridge 的原理》這篇文章總結(jié)的不錯(cuò)点额，感興趣的同學(xué)可以看一下青团。
JSBridge 只是解決了 Native 和 Web 的互相調(diào)用問(wèn)題，如果我想借助 Native 加強(qiáng) Web 怎么辦咖楣？這時(shí)候就有了一些探索：
預(yù)熱：提前創(chuàng)建和初始化 WebView，甚至實(shí)現(xiàn) WebView 容器池芦昔，減少 WebView 的啟動(dòng)時(shí)間
緩存：把常用的 Web 資源預(yù)先存在 Native 本地诱贿，然后攔截瀏覽器網(wǎng)絡(luò)請(qǐng)求重定向到本地，這樣就可以加快 Web 的資源加載速度（也叫“離線包”方案）；
劫持：比如說(shuō) Web 對(duì)網(wǎng)絡(luò)加載的控制力比較弱珠十，部分有能力的廠商會(huì)把所有的網(wǎng)絡(luò)請(qǐng)求都劫持下來(lái)交給 Native 去做料扰，這樣做可以更靈活的管理 Web 請(qǐng)求
替換：替換一般指替換 Web 的
Img標(biāo)簽和Video標(biāo)簽，這個(gè)最常見(jiàn)的地方就是各大新聞?lì)惪蛻?hù)端焙蹭。因?yàn)樾侣劦膭?dòng)態(tài)性和實(shí)時(shí)性晒杈，新聞都是由各個(gè)編輯/自媒體通過(guò)后臺(tái)編輯下發(fā)的，這時(shí)候要利用 Web 強(qiáng)大的排版功能去顯示文本內(nèi)容孔厉；但是為了加載速度和觀看體驗(yàn)拯钻，圖片和視頻都是 Native 組件替換的
經(jīng)過(guò)上面幾步，網(wǎng)頁(yè)的速度基本可以達(dá)到秒開(kāi)的級(jí)別撰豺，這里面最典型的就是幾大新聞客戶(hù)端粪般，大家可以上手體驗(yàn)一下。
3.小程序：JS Engine + WebKit
小程序污桦，國(guó)內(nèi)的特色架構(gòu)亩歹，本質(zhì)上是微信成為流量黑洞后，想成為流量分發(fā)市場(chǎng)管理和分發(fā)自己的流量凡橱，所以這是個(gè)商業(yè)味道很重的框架小作。
小程序在技術(shù)上沒(méi)什么特別的創(chuàng)新點(diǎn)，本質(zhì)上就是閹割版的網(wǎng)頁(yè)稼钩，所以微信小程序出來(lái)后各個(gè)流量寡頭都推出了自己的小程序顾稀，正如有人吐槽的，小程序的實(shí)現(xiàn)方式有 9 種变抽，底層實(shí)現(xiàn)多樣化础拨，各個(gè)廠實(shí)現(xiàn)還沒(méi)有統(tǒng)一的標(biāo)準(zhǔn)，最后就是給開(kāi)發(fā)者喂屎绍载，我也沒(méi)啥好介紹的诡宗，就這樣吧。
4.React Native：JS Engine + Native RenderPipeLine
React 2013 年發(fā)布击儡，兩年后 React Native 就發(fā)布了塔沃，前幾種跨段方案基本都是基于瀏覽器技術(shù)的，RN 這個(gè)跨段方案的創(chuàng)新性在于它保留了 JS Engine阳谍，在渲染引擎這條路上蛀柴，他沒(méi)有自己造輪子，而是復(fù)用了現(xiàn)有的 Native 渲染管線矫夯。
這樣做的好處在于鸽疾，保留 JS Engine，可以最大程度的復(fù)用 Web 生態(tài)训貌，畢竟 GitHub 上輪子最多的語(yǔ)言就是 JavaScript 了制肮；復(fù)用 Native RenderPipeLine冒窍，好處在于脫離 WebKit 的歷史包袱佑菩，相對(duì)來(lái)說(shuō)渲染管線更短渠概，性能自然而然就上去了穿香。
那么問(wèn)題來(lái)了坷剧，RN 是如何做到跨端的谭确？這個(gè)其實(shí)全部仰仗于 React 的 vdom舵盈。
vdom
前端社區(qū)上有些文章討論 vdom诅迷，總會(huì)從性能和開(kāi)發(fā)便捷性上切入講解翁锡，從純 Web 前端的角度看桩了，這些的確是 vdom 的特點(diǎn)附帽，但是這不是 vdom 真正火起來(lái)的原因。vdom 更大的價(jià)值在于圣猎，人們從 vdom 身上看到跨端開(kāi)發(fā)的希望士葫，所以在 React 出現(xiàn)后 React Native 緊跟著出現(xiàn)是一件非常自然的事情。為什么這么說(shuō)送悔？這個(gè)就要先溯源一下 UI 開(kāi)發(fā)的范式慢显。
UI 開(kāi)發(fā)主要有兩大范式：Immediate Mode GUI（立即模式） 和 Retained Mode GUI（保留模式）。
簡(jiǎn)單來(lái)說(shuō)欠啤，IMGUI 每幀都是全量刷新荚藻，主要用在實(shí)時(shí)性很高的領(lǐng)域（游戲 CAD 等）；RMGUI 是最廣泛的 UI 范式洁段，每個(gè)組件都被封裝到一個(gè)對(duì)象里应狱，便于狀態(tài)管理和復(fù)雜的嵌套布局。無(wú)論是網(wǎng)頁(yè)祠丝、iOS疾呻、Android 還是 Qt 等桌面開(kāi)發(fā)領(lǐng)域，都是基于 RMGUI 的写半。這兩者的具體細(xì)節(jié)差異岸蜗，可以看這篇知乎回答和這個(gè) Youtube 視頻。
我們?cè)倩氐?React Native 中叠蝇，既然 iOS Android 的原生渲染管線都是 RMGUI 范式璃岳，那么總是有相似點(diǎn)的，比如說(shuō) UI 都是樹(shù)狀嵌套布局悔捶，都有事件回調(diào)等等铃慷。這時(shí)候 vdom 的作用就出來(lái)了：
vdom 作為一個(gè)純對(duì)象，可以清晰的提煉出出布局的嵌套結(jié)構(gòu)蜕该，而且這個(gè)抽象描述是平臺(tái)無(wú)關(guān)的犁柜，那么我們就可以利用 JS 生成 vdom，然后將 vdom 映射到 Native 的布局結(jié)構(gòu)上堂淡，最終讓 Native 渲染視圖馋缅，以達(dá)到跨平臺(tái)開(kāi)發(fā)的目的坛怪。
到這里如果你有些編譯原理的知識(shí)，你就會(huì)發(fā)現(xiàn) vdom 和 IR 有些類(lèi)似股囊，同樣都是抽象于平臺(tái)的中間態(tài)，vdom 上接 React 下接 Native RenderPipeLine更啄，IR 上接編譯器前端下接編譯器后端稚疹，我們只要關(guān)心前半段的邏輯處理，臟活累活都讓后半部分做祭务。
Hermes
2019 年 Facebook 為了優(yōu)化 React Native 的性能内狗，直接推出了新的 JS Engine——Hermes，FB 官方博文介紹了很多的優(yōu)點(diǎn)义锥，我個(gè)人認(rèn)為最大的亮點(diǎn)是加入 AOT柳沙，傳統(tǒng)的 JS 加工加載流程是這樣的：
Babel 語(yǔ)法轉(zhuǎn)換 → Minify 代碼壓縮 → install 下載代碼 → Parse 轉(zhuǎn)為 AST → Compile 編譯 → Execute 執(zhí)行
Hermes 加入 AOT 后，Babel拌倍、Minify赂鲤、Parse 和 Compile 這些流程全部都在開(kāi)發(fā)者電腦上完成，直接下發(fā)字節(jié)碼讓 Hermes 運(yùn)行就行柱恤。
這樣做的好處在于数初，可以大大縮短 JS 的編譯時(shí)間，不信的話大家可以用 Chrome 分析幾個(gè)大型網(wǎng)站梗顺，JS 的解析加載時(shí)間基本占時(shí)都是 50% 以上泡孩，部分重型網(wǎng)站可能占時(shí) 90%，這對(duì)桌面應(yīng)用來(lái)說(shuō)還好寺谤，對(duì)于電量和 CPU 都要弱上一線的移動(dòng)平臺(tái)來(lái)說(shuō)仑鸥，這些都是妥妥的性能殺手，Hermes 的加入可以大大改善這一情況变屁。
目前 React Native 0.64 也支持 Hermes 了眼俊，如果有做 RN 業(yè)務(wù)的同學(xué)可以玩一玩，看看在 iOS 上的性能提升有多大敞贡。
5.Flutter: Dart VM + Flutter RnderPipeLine
Flutter 是最近比較火的一個(gè)跨端方案泵琳，也有不少人認(rèn)為這是最終的跨端方案，畢竟桌面軟件時(shí)代誊役，最終勝出跨端方案就是 Qt获列，他們的共同特點(diǎn)就是自帶了一套渲染引擎，可以抹平終端差異蛔垢。
Flutter 的創(chuàng)造還是很有意思的击孩，這里有個(gè) Eric 的訪談，視頻中說(shuō) Eric 差不多有十幾年的 Web 渲染領(lǐng)域工作經(jīng)驗(yàn)鹏漆，有一次在 Chrome 內(nèi)部他們做了個(gè)實(shí)驗(yàn)巩梢，把一些亂七八糟的 Web 規(guī)范去掉后创泄，一些基準(zhǔn)測(cè)試甚至能快 20 倍，因此 Google 內(nèi)部開(kāi)始立項(xiàng)括蝠，F(xiàn)lutter 的出現(xiàn)了鞠抑。至于 Flutter 選擇 Dart 的理由，坊間一直傳說(shuō) Flutter 開(kāi)發(fā)組隔壁就是 Dart 開(kāi)發(fā)組忌警，離得近就好 PY 交易搁拙，反正 Dart 也沒(méi)人用，沒(méi)啥歷史包袱法绵，可以很好的相應(yīng) Flutter 的需求箕速。
Flutter 的架構(gòu)也是比較清晰的：
- 虛擬機(jī)用的 Dart VM，Dart 同時(shí)支持 JIT 和 AOT朋譬，可以同時(shí)保證開(kāi)發(fā)效率和運(yùn)行效率
- 渲染引擎先把 Dart 構(gòu)建的視圖數(shù)據(jù)傳遞給 Skia盐茎，然后 Skia 加工數(shù)據(jù)交給 OpenGL/Metal 這兩個(gè)圖形 API，最終交給 GPU 渲染徙赢，整體上比 WebKit 的渲染流水線清晰不少
從純粹程度上看字柠，F(xiàn)lutter 是做的最徹底的，虛擬機(jī)和渲染引擎都沒(méi)有用業(yè)內(nèi)的成熟方案犀忱，而是自造了一套募谎，好處就是沒(méi)啥適配壓力，壞處就是太新了阴汇，業(yè)務(wù)開(kāi)發(fā)時(shí)往往會(huì)遇到無(wú)輪子可用的尷尬狀態(tài)数冬，如果谷歌大力推廣，國(guó)內(nèi)大廠持續(xù)跟進(jìn)搀庶，前景還是很光明的拐纱。
6.其它方向的探索：JS Engine + Flutter RnderPipeLine？
社區(qū)里有一種聲音哥倔，認(rèn)為 Flutter 最大的敗筆就是不能用 JavaScript 開(kāi)發(fā)秸架。這時(shí)候就會(huì)有人想，如果我們把 Web 技術(shù)和 Flutter 技術(shù)結(jié)合起來(lái)咆蒿，用 JS Engine 對(duì)接世界上最大最活躍的 JS 社區(qū)东抹，用 Flutter 渲染引擎對(duì)接高性能渲染體驗(yàn)，國(guó)安民樂(lè)沃测，豈不美哉缭黔？
目前來(lái)說(shuō)一些大廠還是做了一些探索蒂破，我看了一些分析和項(xiàng)目架構(gòu)馏谨，感覺(jué)就是做了個(gè)低配版的 React Native，React Native 的現(xiàn)有架構(gòu)有一個(gè)性能瓶頸就是跨語(yǔ)言調(diào)用成本比較高附迷，而這些大廠的調(diào)用鏈路多達(dá) 4 步：JS -> C++ -> Dart -> C++惧互，更加喪心病狂哎媚，目前看無(wú)論是上手和推廣都是沒(méi)有直接用 RN or Flutter 方便。
三喊儡、各跨端方案的不足之處
跨端方案不可能只有好處的拨与，各個(gè)方案的壞處也是很明顯的，我下面簡(jiǎn)單列一下：
- 網(wǎng)頁(yè)：性能是個(gè)過(guò)去不的坎兒艾猜，而且 Apple 明確指出不歡迎 WebView 套殼 APP截珍，有拒審危險(xiǎn)
- 網(wǎng)頁(yè) PLUS：技術(shù)投入很高，基本只能大廠玩轉(zhuǎn)
- 小程序：對(duì)開(kāi)發(fā)者不友好箩朴，技術(shù)半衰期極短
- React Native：基本只能畫(huà) UI，一旦做深了秋度，只會(huì) JS 根本解決不了問(wèn)題炸庞，Java OC 都得學(xué)，對(duì)開(kāi)發(fā)者要求比較高
- Flutter：Android 支持很好荚斯，但 iOS 平臺(tái)的交互割裂感還是很強(qiáng)的埠居，而且和 RN 問(wèn)題一樣，一旦做深了事期，必須學(xué)習(xí)客戶(hù)端開(kāi)發(fā)知識(shí)滥壕，對(duì)開(kāi)發(fā)者要求比較高
總的來(lái)說(shuō)，在犧牲一定用戶(hù)體驗(yàn)的前提下兽泣，跨端方案可以提高開(kāi)發(fā)者的開(kāi)發(fā)效率和公司的運(yùn)行效率绎橘，我個(gè)人認(rèn)為，只要某個(gè)方案的 ROI 比較高唠倦，其實(shí)是還是可以投入到生產(chǎn)的称鳞。
四、總結(jié)
本文到此就結(jié)束了稠鼻，我把各個(gè)跨端技術(shù)提煉為為虛擬機(jī)和渲染引擎技術(shù)冈止，然后以這兩個(gè)核心技術(shù)的角度去拆解各個(gè)跨端方案。一旦概念理清候齿，在面對(duì)性能調(diào)優(yōu)等技術(shù)場(chǎng)景時(shí)熙暴，就能抓住主要矛盾，更快更好的發(fā)現(xiàn)問(wèn)題慌盯，解決問(wèn)題周霉。
如果你覺(jué)得我的文章對(duì)你有幫助，在收藏的過(guò)程中润匙，一定要記得點(diǎn)贊和點(diǎn)在看哦诗眨，謝謝你，這對(duì)我真的很重要??孕讳！
最后推薦一波我的個(gè)人博客：supercodepower.com, 目前專(zhuān)注前端技術(shù)匠楚，對(duì)圖形學(xué)也有一些微小研究巍膘，歡迎大家來(lái)撩～
五、推薦閱讀
【答疑解惑】為什么你的 Charles 會(huì)抓包失斢蟛尽峡懈？
webpack 中那些最易混淆的 5 個(gè)知識(shí)點(diǎn)
