寫給前端的跨平臺方案、跨端引擎的本質

作者： 神說要有光zxg 來源：神光的程式設計祕籍

近些年來，前端領域的跨端技術越來越多了：react native、weex、flutter、electron、kraken 等等。

那麼多跨端方案，他們有沒有通用的思路?我們能不能從這麼多方案中找出本質的原理?

本文會嘗試探究探究以下問題：

• 什麼是跨平臺

• 有哪些方案是跨平臺的

• 跨端和跨平臺的區別是什麼

• 前端領域有哪些跨端方案

• 跨平臺、跨端的通用原理是什麼

什麼是跨平臺

我們知道，cpu 有不同的架構和指令集，上層也有不同的作業系統，一個系統的可執行檔案在另一個系統上就是不可執行的，比如 windows 的 exe 檔案在 mac 上就不能直接執行。不同的系統就是不同的運行平臺。可執行檔案是不跨平臺的。

不同平臺提供的 api 不同，所以程式碼邏輯可能也不同，需要不同平臺單獨維護程式碼。這樣就帶來了幾個問題：

• 多平臺各自開發，怎麼保證功能是一致的

• 多平臺各自開發，那是不是得各自測試，開發和測試的人力都是多份的

所以出現了跨平臺的一些技術，目標是一份程式碼跑在任意平臺。

我們先來看一些各領域的跨平臺方案：

瀏覽器

作業系統不同，瀏覽器上跑的網頁的程式碼確實同一份。瀏覽器就是一種歷史悠久的跨平臺方案。

網頁跨平臺不意味著瀏覽器也是跨平臺的，瀏覽器的可執行檔案還是每個平臺單獨開發和編譯的，但是他們支援的網頁解析邏輯一樣，這樣上面跑的網頁就是跨平臺的。

瀏覽器提供了一個容器，遮蔽了底層差異，提供了統一的 api(dom api)，這樣就可以實現同一份程式碼跑在不同平臺的統一的容器裡。這個容器叫做瀏覽器引擎，由 js 引擎、渲染引擎等構成。

docker

docker 是一種虛擬化技術，可以在作業系統之上加一個虛擬層，在這層之上劃分一到多個容器，容器裡再去跑系統、app，這樣可以實現硬體和軟體的分離，動態分配硬體資源給容器，並且方便 app 運行環境的整體遷移(儲存成映象)。

docker 很明顯也是一種跨平臺技術，同一個映象可以跑在任何作業系統的 docker 上。只要不同作業系統實現同樣的容器即可。

jvm

java 是一門編譯 + 解釋的語言，java 源碼編譯成位元組碼，然後位元組碼直接在 vm 上解釋執行。

java 為什麼這麼火呢?主要是因為跨平臺。

c、c++ 這種語言寫的程式碼需要編譯成不同作業系統上的可執行檔案來跑，而且每個平臺的程式碼可能還不一樣，需要寫多份。

java 因為提供了 jvm 容器，只要把源碼編譯成 jvm 能解釋的位元組碼就行了，而且 jdk 提供了統一的 api，分別由不同作業系統的底層 api 來實現，這樣對於 java 程式碼來說，不同作業系統的程式碼是一致的。

jvm 也是通過容器的技術實現了一份程式碼跑在多個平臺，而且 jre 提供了統一的 api，遮蔽掉了底層的差異。

node、deno

node 和 deno 也是跨平臺的技術，通過提供一套一致的 api，讓其上的 js 程式碼可以跨平臺。這些 api 也是不同平臺各自實現的。

electron

electron 內建了 chromium，併為其注入了 node 的 api 和一些 GUI 相關的 api，是基於兩大跨平臺技術綜合而成的跨平臺方案。基於這些方案的組合使得 electron 支援用前端技術開發桌面端。

跨平臺方案的優缺點

跨平臺方案的優點很明顯，就是一份程式碼跑在不同平臺的同樣的容器內，不用不同平臺單獨開發，節省成本。

但是跨平臺方案也有缺點：

• 因為多了一層容器，所以效能相比直接呼叫系統 api 會有所下降

• 為了實現多平臺的一致，需要提供一套統一的 api，這套 api 有兩個難題：

• api 怎麼設計。要綜合不同平臺的能力，取一個合適的集合來實現。設計上有一定難度。node、deno、java 都抽象了作業系統的能力，提供了各自的跨平臺 api

• 部分 api 很難做到多平臺的一致性

• 當容器沒有提供的能力需要擴展的時候比較麻煩，比如 js 引擎的 bridge、 jvm 的 jni、node 的 c++ addon 等都是為這個容器擴展能力的方式

前端領域的跨端方案

跨平臺指的是跨作業系統，而跨端是指客戶端。

客戶端的特點就是有介面、有邏輯，所以包含邏輯跨端和渲染跨端。主要的客戶端有 web、安卓、ios、iot 裝置等。

現在主流的跨端方案有 react native、weex、flutter、kraken 以及各家自研的跨端引擎等。

react native

跨端包括邏輯跨端和渲染跨端，rn 的邏輯跨端是基於 js 引擎，通過 bridge 注入一些裝置能力的 api，而渲染跨端則是使用安卓、ios 實現 react 的 virtual dom 的渲染。

其中 native api 和元件(灰色畫出的部分)並沒有做到雙端一致，而且有的時候擴展圖中灰色部分需要原生配合，混雜 rn 程式碼和自己擴展的程式碼導致程式碼比較難管理。最著名的事件就是 airbnb 從最大的 react native 支持者到棄用 react native。

weex

weex 也是類似的思路來實現跨端的，不過他對接的上層 ui 框架是 vue，而且努力做到了雙端的元件 和 api 的一致性(雖然後續維護跟不上了)。架構和上圖類似。

flutter

flutter 是近些年流行的跨端方案，跨的端包括安卓、ios、web 等。它最大的特點是渲染不是基於作業系統的元件，而是直接基於繪相簿(skia)來繪製的，這樣做到了渲染的跨端。邏輯的跨端也不是基於 js 引擎，而是自研的 dart vm 來跨端，通過 dart 語言來寫邏輯，

kraken

跨端包括兩部分，渲染跨端和邏輯跨端。有時候只需要渲染跨端、有時候只需要邏輯跨端，有的時候需要完整的跨端引擎，這 3 種情況都有各自的適用場景。

kraken 就是一個跨端渲染引擎，基於 flutter 的繪圖能力實現了 css 的渲染，實現了渲染的跨端。

自研渲染引擎

跨端引擎很依賴底層實現的元件和 api，用開源方案也一樣得擴展這部分，所以有一定規模的團隊都會選擇自研。

自研跨端引擎會和 rn、weex 不同：

• 渲染部分不需要實現 virtual dom 的渲染，而是直接對接 dom api，上層應用基於這些 dom api 實現跨端渲染。這樣理論上可以對接任意前端框架。

• 邏輯部分也是基於 js 引擎，通過 binding 直接注入一些 c++ 實現的 api，或者運行時通過 bridge 來注入一些安卓、ios 實現的 api。

自研跨端引擎的好處是元件和 api 可以自己擴展，更快的響應業務的需求。其中元件和 api 的雙端一致性，以及統一的 api 的設計都是難點。

跨端的通用原理是什麼

其實跨端和跨平臺的思路類似，都是實現一個容器，給它提供統一的 api，這套 api 由不同的平臺各自實現，保證一致的功能。

具體一些的話，跨端分為渲染和邏輯跨端，有的時候只需要單獨的渲染跨端方案(比如 karen)和邏輯跨端方案，有的時候需要完整的跨端引擎。

weex、react native 的渲染部分都是通過實現了 virtual dom 的渲染，用安卓、ios 各自的渲染方式實現，邏輯部分使用 js 引擎，通過 bridge 注入一些安卓、ios 的 api。

flutter 則是直接使用 skia 繪相簿繪製，並且邏輯跨端使用 dart vm。

但是不管具體實現怎樣，思路都大同小異：跨端引擎需要實現一個渲染引擎、實現一個 vm，基於這套架構實現各種元件和 api，跨端容器上層對接一個 ui 框架，再上層的業務程式碼可以基於容器的 api 實現跨端的渲染和邏輯

web container

這兩天 web container 比較火，其實也是一種跨平臺技術，它是在瀏覽器裡面實現的容器，通過 wasm 實現了 node 的 api，這樣在這個容器裡面可以跑 node 程式碼。其實思路比較常見，但是是一個新場景。

瀏覽器容器之上又跑了個容器，容器套娃。

總結

我們聊了跨平臺和跨端的區別，跨平臺是指跨作業系統，而跨端則是指跨客戶端。

跨平臺技術聊了 docker、瀏覽器、jvm、node、deno、electron、web container 等，他們都是跨平臺(作業系統)的方案，跨平臺有優點也有缺點，缺點就在於 api 的設計比較難，node、deno、java 等都有自己的一層 api 設計;api 一致性的保障也比較困難;其次就是擴展方式複雜一些(jvm 的 jni、node 的 c++ addon 等)。

跨端方案聊了 react native、weex、flutter、kraken 等，有的是綁定了 react、vue 等前端框架，直接從 virtual dom 渲染，有的是實現了 dom api，可以對接任意前端框架。當然可以單獨做渲染或邏輯跨端。渲染跨端或者用安卓、ios 提供的方式，或者自己繪製，邏輯跨端或者用 js 引擎(可以對接前端框架)或者用 dart vm。

希望這篇文章可以讓你理解跨端和跨平臺的容器的思路和優缺點，遇到一些新技術(比如 web container)也能快速的理解。