web跨平臺(tái)架構(gòu)模式是什么

這篇文章主要講解了“web跨平臺(tái)架構(gòu)模式是什么”，文中的講解內(nèi)容簡單清晰，易于學(xué)習(xí)與理解，下面請(qǐng)大家跟著小編的思路慢慢深入，一起來研究和學(xué)習(xí)“web跨平臺(tái)架構(gòu)模式是什么”吧！

1. 基于庫/模式庫封裝

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

在我還沒有接觸 Web 開發(fā)之前，我是一個(gè) Qt 粉(Qt 是一個(gè)跨平臺(tái)的 C++  應(yīng)用程序開發(fā)框架。因?yàn)椋畮啄昵皩?duì)于桌面應(yīng)用的開發(fā)，你并沒有太多的選擇，要么 GTK 要么 Qt。而我還是一個(gè) KDE 粉，順帶還是一個(gè) OpenSuSE  粉，因?yàn)橛兄罘€(wěn)定的桌面環(huán)境。

過去，CPU 的性能沒有這么好，JavaScript 引擎速度沒有這么快，Web 瀏覽器只是個(gè)輔助工具。若是想開發(fā)跨平臺(tái)應(yīng)用，得從底層庫開始。

嗯，所以，開發(fā)游戲的人們，選擇了Qt、wxWidgets、Gtk+  等框架，作為應(yīng)用的基礎(chǔ)設(shè)施。我習(xí)慣于將這樣的工具稱為模式庫，因?yàn)樗鼈兂橄罅烁鞣N模式到代碼中，否則怎么跨平臺(tái)呢?

1.1 IDE 封裝模式庫細(xì)節(jié)

在有了 IDE 之后，我們已經(jīng)不關(guān)注于這些底層細(xì)節(jié)了。但是，我們?nèi)匀皇腔谶@些模式庫。

2. 通過交叉編譯構(gòu)建

交叉編譯是指，在一個(gè)平臺(tái)上生成另一個(gè)平臺(tái)上的可執(zhí)行代碼。

在我的大學(xué)校園里，我接觸最多的就是嵌入式應(yīng)用的交叉編譯，所以我一點(diǎn)兒也不喜歡這個(gè)東西。因?yàn)樗悴簧鲜强缙脚_(tái)的，還依賴于特定 MCU、SoC 的  IDE，我的代碼只能運(yùn)行在特定的平臺(tái)上。

當(dāng)我因?yàn)樨毟F的緣故，我以為我離交叉編譯遠(yuǎn)了——畢竟，你開始一個(gè)需要三臺(tái)機(jī)器  Windows、macOS、GNU/Linux，又或者是通過持續(xù)集成服務(wù)器來做這樣的事情。當(dāng)我只有一臺(tái)機(jī)器的時(shí)候，只有卡卡的虛擬機(jī)能解決我的矛盾。

直到去年，我使用 Golang 寫了 Coca ，我重新認(rèn)識(shí)了一下交叉編譯。在 macOS 下，我可以直接編譯出可以在 GNU/Linux、Windows  操作系統(tǒng)下運(yùn)行的

語言運(yùn)行環(huán)境

通過平臺(tái)封裝細(xì)節(jié)，而后提供語言作為 API 來給外部系統(tǒng)調(diào)用。

3. 操作系統(tǒng)之上：語言解釋器

這一點(diǎn)實(shí)際上是非常容易理解的，比如我們?nèi)粘Ｊ褂玫?Ruby、Python 等語言，都能歸屬于此類。

它們封裝了操作系統(tǒng)底層的各種細(xì)節(jié)，提供了各種 API 抽象。除去部分平臺(tái)特定代碼，只需要拿起源碼，便能直接到另外一個(gè)平臺(tái)上運(yùn)行。

而對(duì)于那些沒有解釋器的操作系統(tǒng)來說，可以采用諸如 Pyinstaller 便可以打包成目標(biāo)平臺(tái)的可執(zhí)行文件。

4. 嵌入式運(yùn)行時(shí)

考慮到嵌入式設(shè)備的特殊性，  我將嵌入式運(yùn)行時(shí)，視為一個(gè)獨(dú)立的模式。因?yàn)樵谇度胧皆O(shè)備上跑語言解釋器，你一定需要一個(gè)操作系統(tǒng)。反過來，針對(duì)于不同的硬件情況，還需要定制大量的  API。采用這一類架構(gòu)模式的開源應(yīng)用有：采用 Lua 語言的 NodeMCU，采用 JavaScript 語言的 IoT.js 等。

5. 基于應(yīng)用軟件

毫無疑問，這是游戲領(lǐng)域使用 Lua 作為腳本語言，還是 Web 世界被廣泛使用的 JavaScript 的一種跨平臺(tái)架構(gòu)模式。

瀏覽器 / Electron

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

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

工具運(yùn)行時(shí)：Emacs

PS：Emacs 即是最好的編輯器，也是最好的操作系統(tǒng)。

除了瀏覽器之外，Emacs 還內(nèi)置了一個(gè)名為 Emacs Lisp 的直譯式腳本語言，通過這個(gè)語言來擴(kuò)展這個(gè)操作系統(tǒng)的功能。

毫無疑問這種模式的主要目的是，將平臺(tái)語言作為擴(kuò)展的開發(fā)語言。

跨語言

構(gòu)建跨語言平臺(tái)并不是一件容易的事情。這一部分講的主要是跨平臺(tái)移動(dòng)應(yīng)用和跨前后端應(yīng)用。

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

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

PS：順事一吐槽，盡管從架構(gòu)上說 Flutter 更加優(yōu)秀，但是它那該死的布局也只有原生應(yīng)用開發(fā)者會(huì)喜歡了。

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

7. 語言轉(zhuǎn)換器

通過 AST 來進(jìn)行語言轉(zhuǎn)換，再借助于一系列的 wrapper，來封裝目標(biāo)語言上的框架，以實(shí)現(xiàn)使用 A 語言開發(fā) B 語言應(yīng)用的目標(biāo)。這一點(diǎn)常見于 Web  前端開發(fā)領(lǐng)域。

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

框架 wrapper

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

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

這&hellip;&hellip;，好丑。

領(lǐng)域模型復(fù)用

在我最近的一次 Kotlin2js 的實(shí)踐中，我發(fā)現(xiàn)對(duì)于領(lǐng)域模型的轉(zhuǎn)換可能才是語言轉(zhuǎn)換器的核心所在。

即存在一個(gè)單獨(dú)的項(xiàng)目使用 Kotlin 編寫，通過它的多平臺(tái)編譯，把它轉(zhuǎn)為其它平臺(tái)的代碼。這樣一來，便可以輕松地達(dá)到領(lǐng)域模型在其它端的使用。

中間格式/語言

8. 采用虛擬化技術(shù)

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

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

嗯，經(jīng)編譯完生成特定的格式后，通過自已的虛擬機(jī)就可以轉(zhuǎn)譯為可執(zhí)行命令，就是這么簡單直接。

對(duì)于一個(gè)開發(fā)人員來說，我們經(jīng)常接觸到這樣的工具，也寫過一些。我們也通過它們來做一些 GUI 應(yīng)用，比如我用得比較多的 ClassyShark。

9. 中間語言

這一類跨平臺(tái)、跨語言工具并不常用，因?yàn)檗D(zhuǎn)成中間語言再編譯的話，除了微架構(gòu)，并不常見。

暫存器傳遞語言(RTL)

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

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

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

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

WebAssembly

WebAssembly 是便攜式的抽象語法樹，被設(shè)計(jì)來提供比 JavaScript  更快速的編譯及運(yùn)行。對(duì)于性能要求高的應(yīng)用來說，這是一個(gè)非常好的技術(shù)。有了這一項(xiàng)技術(shù)，那么那些使用原生語言開發(fā)的桌面應(yīng)用，就可以更容易地遷移到 Web  平臺(tái)。

現(xiàn)在，你可以將你的 Golang 編寫的代碼編譯到 WASM，然后提供給 JavaScript 調(diào)用了。

10. 代碼生成器

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

我總以為人們會(huì)以一種中間 DSL  或者數(shù)據(jù)格式來作為中間格式，這樣一來，可以實(shí)現(xiàn)解耦的目的，以適應(yīng)未來的變化。但是沒想到還可能直接生成了對(duì)應(yīng)平臺(tái)的代碼。然后，你拿著代碼去各個(gè)平臺(tái)編譯一遍。

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

多重平臺(tái)

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

當(dāng)然了，隨之也提升了 debug 的難度。

11. 雙重平臺(tái)/框架

移動(dòng)端應(yīng)用的第一大挑戰(zhàn)是，面對(duì)不同移動(dòng)平臺(tái)帶來的 API 挑戰(zhàn)。所以，Cordova 站了出來，支持了九個(gè)平臺(tái)，現(xiàn)在只剩下了五個(gè)。

當(dāng)我們開發(fā)一個(gè)基于 Cordova 混合應(yīng)用時(shí)，我們便是基于 WebView + Cordova  之上構(gòu)建我們的應(yīng)用。大家都已經(jīng)很熟悉了，這里就不熟悉說明了。

12. 多重平臺(tái)/框架

即通過一層層的框架和平臺(tái)，來打造自己的能力。它對(duì)于使用者人員來說，可能相當(dāng)?shù)挠押茫菍?duì)于開發(fā)者來說，不一定如此。舉兩個(gè)例子：

小程序應(yīng)用：微信平臺(tái) + WebView + 小程序框架

Ionic 應(yīng)用：WebView + Cordova + Ionic 框架

嗯，隨著層數(shù)的上升，調(diào)試復(fù)雜度會(huì)越來越多，也越需要一個(gè)盡可能的全才。

感謝各位的閱讀，以上就是“web跨平臺(tái)架構(gòu)模式是什么”的內(nèi)容了，經(jīng)過本文的學(xué)習(xí)后，相信大家對(duì)web跨平臺(tái)架構(gòu)模式是什么這一問題有了更深刻的體會(huì)，具體使用情況還需要大家實(shí)踐驗(yàn)證。這里是億速云，小編將為大家推送更多相關(guān)知識(shí)點(diǎn)的文章，歡迎關(guān)注！