跨平臺不是一個新的話題，它已經被討論了幾十年了。在最近的一些嘗試，讓我對跨平臺有了一些新的想法。在想法真正落地之前，我梳理了一下不同跨平臺方案的一些特征，便有了它的幾種模式。

故事的開始是這樣的，受整潔架構思維的影響，從 2019 年，我便開始一種合適的模式來共享代碼模式。我嘗試了幾種不同的思路：

使用 Serverless + TypeScript 構建后臺應用，通過將領域模型打包成 npm 包、submodule 實現業務共享

使用 Golang + WASM 構建跨前后端核心域

順帶嘗試了 Rust + WASM，但是 Rust 在這一兩里被后端采用的可能性太低，除非原有的是 C++ 技術棧

Kotlin 開發后端應用，Kotlin2js 轉成前端庫，提供給前端使用

除此，還有更偉大的 Chapi，可以將任意語言轉換為任意語言。當然了，你知道我只是在 YY。

同一語言

[[315996]]

當我們談論到跨平臺的時候，要談論到桌面操作系統、移動端操作系統。桌面操作系統的跨平臺模式和移動端不太一樣 —— 桌面端可以使用同一語言。而移動端 Android 主要使用的是 Java、Kotlin，配合游戲開發等使用的 NDK;iOS 主要使用的是 Objective-C、Swift，它們可以直接編譯、調用 C++ 庫。

在沒有操作系統限制編程語言的時候，我們在同一個世界下，使用著同一種編程語言。

1. 基于庫/模式庫封裝

模式庫，是一系列可復用代碼的合集，如前端的組件，通用的工具函數等等。

在我還沒有接觸 Web 開發之前，我是一個 Qt 粉(Qt 是一個跨平臺的 C++ 應用程序開發框架。因為，十幾年前對于桌面應用的開發，你并沒有太多的選擇，要么 GTK 要么 Qt。而我還是一個 KDE 粉，順帶還是一個 OpenSuSE 粉，因為有著最穩定的桌面環境。

過去，CPU 的性能沒有這么好，JavaScript 引擎速度沒有這么快，Web 瀏覽器只是個輔助工具。若是想開發跨平臺應用，得從底層庫開始。

嗯，所以，開發游戲的人們，選擇了Qt、wxWidgets、Gtk+ 等框架，作為應用的基礎設施。我習慣于將這樣的工具稱為模式庫，因為它們抽象了各種模式到代碼中，否則怎么跨平臺呢?

1.1 IDE 封裝模式庫細節

在有了 IDE 之后，我們已經不關注于這些底層細節了。但是，我們仍然是基于這些模式庫。

2. 通過交叉編譯構建

交叉編譯是指，在一個平臺上生成另一個平臺上的可執行代碼。

在我的大學校園里，我接觸最多的就是嵌入式應用的交叉編譯，所以我一點兒也不喜歡這個東西。因為它算不上是跨平臺的，還依賴于特定 MCU、SoC 的 IDE，我的代碼只能運行在特定的平臺上。

當我因為貧窮的緣故，我以為我離交叉編譯遠了——畢竟，你開始一個需要三臺機器 Windows、macOS、GNU/Linux，又或者是通過持續集成服務器來做這樣的事情。當我只有一臺機器的時候，只有卡卡的虛擬機能解決我的矛盾。

直到去年，我使用 Golang 寫了 Coca ，我重新認識了一下交叉編譯。在 macOS 下，我可以直接編譯出可以在 GNU/Linux、Windows 操作系統下運行的

語言運行環境

通過平臺封裝細節，而后提供語言作為 API 來給外部系統調用。

3. 操作系統之上：語言解釋器

這一點實際上是非常容易理解的，比如我們日常使用的 Ruby、Python 等語言，都能歸屬于此類。

它們封裝了操作系統底層的各種細節，提供了各種 API 抽象。除去部分平臺特定代碼，只需要拿起源碼，便能直接到另外一個平臺上運行。

而對于那些沒有解釋器的操作系統來說，可以采用諸如 Pyinstaller 便可以打包成目標平臺的可執行文件。

4. 嵌入式運行時

考慮到嵌入式設備的特殊性， 我將嵌入式運行時，視為一個獨立的模式。因為在嵌入式設備上跑語言解釋器，你一定需要一個操作系統。反過來，針對于不同的硬件情況，還需要定制大量的 API。采用這一類架構模式的開源應用有：采用 Lua 語言的 NodeMCU，采用 JavaScript 語言的 IoT.js 等。

5. 基于應用軟件

毫無疑問，這是游戲領域使用 Lua 作為腳本語言，還是 Web 世界被廣泛使用的 JavaScript 的一種跨平臺架構模式。

瀏覽器 / Electron

Web 應用，是我們使用最廣泛的跨平臺應用了。甚至于，你并不需要使用同一個廠商的瀏覽器，就可以運行起同一個 Web 應用。而這些正是瀏覽器提供了 JavaScript + HTML + CSS。JavaScript，是少數幾個可以直接抄起記事本就能擼代碼，并能跑起來的語言 —— 畢竟操作系統都提供了 Web 瀏覽器。

而正由于前端技術的速度發展，生態變得日益完善，使得諸如于 Electron 這樣的框架，讓越來越多的公司采用它來作為桌面應用開發框架，最具代表性的便是：Visual Studio Code。

工具運行時：Emacs

PS：Emacs 即是最好的編輯器，也是最好的操作系統。

除了瀏覽器之外，Emacs 還內置了一個名為 Emacs Lisp 的直譯式腳本語言，通過這個語言來擴展這個操作系統的功能。

毫無疑問這種模式的主要目的是，將平臺語言作為擴展的開發語言。

跨語言

構建跨語言平臺并不是一件容易的事情。這一部分講的主要是跨平臺移動應用和跨前后端應用。

6. 借助DSL / 語言封裝差異

在過去的幾年里，跨平臺的移動應用框架非常火熱，其中呈上升趨勢的便是：React Native 和 Flutter。盡管兩個框架的運行機制不是很相同，但是考慮到都是框架 + 語言來封裝 Android + iOS 平臺的差異性，我還是把它們劃到同一類。

PS：順事一吐槽，盡管從架構上說 Flutter 更加優秀，但是它那該死的布局也只有原生應用開發者會喜歡了。

然而，要開發這樣一個 DSL 或者語言，并不是一件容易的事情。從某種意義上來說，我們至少需要 Android x 1 + iOS x 1 + Web x 1 + AppDev x 1。

7. 語言轉換器

通過 AST 來進行語言轉換，再借助于一系列的 wrapper，來封裝目標語言上的框架，以實現使用 A 語言開發 B 語言應用的目標。這一點常見于 Web 前端開發領域。

直接從 A 語言轉換 B 語言，并沒有太大的問題。但是，在轉換的時候，我們需要考慮一下核心是什么?

框架 wrapper

這一類的工具過于小眾了，而且它永遠跟不上前端的變化速度。除此，它的寫法可能有些奇怪，舉個 Scala.js-React 的示例：

val Hello =ScalaComponent.builder[String]("Hello").render_P(name => <.div("Hello there ", name)).build

這……，好丑。

領域模型復用

在我最近的一次 Kotlin2js 的實踐中，我發現對于領域模型的轉換可能才是語言轉換器的核心所在。

即存在一個單獨的項目使用 Kotlin 編寫，通過它的多平臺編譯，把它轉為其它平臺的代碼。這樣一來，便可以輕松地達到領域模型在其它端的使用。

中間格式/語言

8. 采用虛擬化技術

你知道我在說 JVM，畢竟：Write once, run anywhere。不過 JVM 只是其中的一個，除了它還有 .NET、Parrot 等。

程序語言級別的虛擬化，會將高階語言轉譯成一種名為位元組碼(Bytecode)的語言，透過虛擬機器轉譯成為可以直接執行的命令。

嗯，經編譯完生成特定的格式后，通過自已的虛擬機就可以轉譯為可執行命令，就是這么簡單直接。

對于一個開發人員來說，我們經常接觸到這樣的工具，也寫過一些。我們也通過它們來做一些 GUI 應用，比如我用得比較多的 ClassyShark。

9. 中間語言

這一類跨平臺、跨語言工具并不常用，因為轉成中間語言再編譯的話，除了微架構，并不常見。

暫存器傳遞語言(RTL)

這里讓我們先用暫存器傳遞語言作為一個示例，我沒有這方面的經驗。我隱隱約約覺得存在一些情況，需要它，但是我還沒有找到合適的例子證明。

暫存器傳遞語言(英語：register transfer language，縮寫為 RTL)，又譯為暫存器轉換語言、寄存器轉換語言，一種中間語言，使用于編譯器中。

(set (reg:SI 140)(plus:SI (reg:SI 138)(reg:SI 139)))

GCC 的前端(frontend)會先將程式語言轉譯成 RTL，之后再利用后端(backend)轉化成機器碼。

WebAssembly

WebAssembly 是便攜式的抽象語法樹，被設計來提供比 JavaScript 更快速的編譯及運行。對于性能要求高的應用來說，這是一個非常好的技術。有了這一項技術，那么那些使用原生語言開發的桌面應用，就可以更容易地遷移到 Web 平臺。

現在，你可以將你的 Golang 編寫的代碼編譯到 WASM，然后提供給 JavaScript 調用了。

10. 代碼生成器

我不知道為什么又扯到了這個話題。

我總以為人們會以一種中間 DSL 或者數據格式來作為中間格式，這樣一來，可以實現解耦的目的，以適應未來的變化。但是沒想到還可能直接生成了對應平臺的代碼。然后，你拿著代碼去各個平臺編譯一遍。

沒的毛病，挺好的，效率更高。

多重平臺

事實上，我相信上面的大部分模式，你都是的懵逼。它們都過于 NB，以致于不是一般人能做的。所以，我們就有了多重平臺技術。它利用了各種平臺提供的能力，以幫助自己更好地構建跨平臺能力。

當然了，隨之也提升了 debug 的難度。

11. 雙重平臺/框架

移動端應用的第一大挑戰是，面對不同移動平臺帶來的 API 挑戰。所以，Cordova 站了出來，支持了九個平臺，現在只剩下了五個。

當我們開發一個基于 Cordova 混合應用時，我們便是基于 WebView + Cordova 之上構建我們的應用。大家都已經很熟悉了，這里就不熟悉說明了。

12. 多重平臺/框架

即通過一層層的框架和平臺，來打造自己的能力。它對于使用者人員來說，可能相當的友好，但是對于開發者來說，不一定如此。舉兩個例子：

小程序應用：微信平臺 + WebView + 小程序框架

Ionic 應用：WebView + Cordova + Ionic 框架

嗯，隨著層數的上升，調試復雜度會越來越多，也越需要一個盡可能的全才。

結論

沒有銀彈。