「技術(shù)分享」WebAssembly能否重新定義前端開發(fā)模式？

喜歡站在山上 2020-11-13

展開全文

如果提及近年來讓人最為興奮的新技術(shù)，非WebAssembly 莫屬。作為一種低級的類匯編語言，WebAssembly以緊湊二進制的格式存儲，為C/C++, Rust等擁有低級內(nèi)存的模型語言提供了新的編譯目標(biāo)。正因如此，WebAssembly體積更小，可以以接近原生性能的速度運行。

WebAssembly 技術(shù)本身具有非常多的優(yōu)點，雖始于瀏覽器但已經(jīng)開始不斷地被各個語言及平臺所集成，在實際的工業(yè)化落地中，區(qū)塊鏈、邊緣計算、游戲及圖像視頻等多個領(lǐng)域都依靠 WebAssembly 創(chuàng)造出了讓人稱贊的產(chǎn)品。

WebAssembly的應(yīng)用場景

編譯器（編譯鏈）
多媒體剪輯
游戲
圖像識別
VR+虛擬現(xiàn)實
直播視屏特效
游戲、應(yīng)用分發(fā)服務(wù)
服務(wù)器端運行不受信任的代碼
移動端混合應(yīng)用
P2P應(yīng)用
...

WebAssembly的主要特性

快速、高效、可移植
可讀、可調(diào)試
安全，遵循瀏覽器同源策略和授權(quán)策略，運行在沙箱環(huán)境中
與其他web技術(shù)兼容(JS)

WebAssembly VS Javascript

既然提到了Web技術(shù)，就不得不提另一款在Web項目開發(fā)中大放異彩的腳本語言Javascript。1995 年，Brendan Eich 用了不到 10 天就創(chuàng)建了 Javascript，其最初主要應(yīng)用于表單驗證，而非以速度見長。隨著各類應(yīng)用功能的復(fù)雜化，受限于 JavaScript 語言本身動態(tài)類型和解釋執(zhí)行的設(shè)計，其性能問題逐漸凸現(xiàn)。

2008年，圍繞著瀏覽器性能開展的大戰(zhàn)終于在各大瀏覽器廠商間爆發(fā)，在先后經(jīng)歷了即時編譯器（JITs），以及用Node.js和Electron構(gòu)建應(yīng)用程序的時期后，WebAssembly有望成為JS引擎突破下一性能瓶頸的轉(zhuǎn)折點。

為此，這兩者經(jīng)常被用于比較，甚至一度出現(xiàn)WebAssembly 終將替代 Javascript的言論。的確，作為類匯編語言，WebAssembly解決了Javascript最常為人詬病的性能問題，也正是基于此，WebAssembly注定不適合開發(fā)人員手寫代碼，只能為其他語言提供一個編譯目標(biāo)。

因此，這兩種技術(shù)的關(guān)系不是競爭，反而更像是合作共贏。通過 Javascript API，你可以將 WebAssembly 模塊加載到你的頁面中。也就是說，你可以通過 WebAssembly 來充分利用編譯代碼的性能，同時保持 Javascript 的靈活性。

二者性能對比

下圖為我們展現(xiàn)了JS引擎運行程序和運行Wasm的耗時對比：

JS引擎運行程序時，需要經(jīng)歷源碼轉(zhuǎn)換（parse）、生成字節(jié)碼（compile + optimize）、編譯器優(yōu)化（re-optimize）、代碼執(zhí)行（execute）和內(nèi)存清理（GC）這五個階段：

parse : 將源碼轉(zhuǎn)換成抽象語法樹，傳遞給解釋器。
compile + optimize : 解釋器生成字節(jié)碼，并通過編譯器（JIT）編譯優(yōu)化部分字節(jié)碼，生成機器碼。
re-optimize : 當(dāng)發(fā)現(xiàn)優(yōu)化代碼無法被編譯器優(yōu)化時，重現(xiàn)轉(zhuǎn)給解釋器。
execute : 執(zhí)行代碼的過程。
GC: 清理內(nèi)存的時間。

大部分情況下，JS在執(zhí)行階段將字節(jié)碼編譯成機器碼，這一階段十分耗時。（這是由于JS的動態(tài)性所導(dǎo)致，相同的代碼會被不同的類型重新編譯）。而Wasm不需要被解析，也不需要在運行時動態(tài)檢測數(shù)據(jù)類型，由于它已經(jīng)是字節(jié)碼了，所以只需要簡單解碼，即可包含所有的類型信息。

正是因為Wasm的大部分優(yōu)化工作已經(jīng)在LLVM的前端部分完成了，所以編譯優(yōu)化的工作很少，這便是其高性能的主要體現(xiàn)。

編譯模型(LLVM)

LLVM（Low-Level-Virtural-Machine）, 底層虛擬機架構(gòu)，優(yōu)點包括：

模塊化設(shè)計（三段式：前端、優(yōu)化器、后端），代碼更為清晰和便于排查問題，前端負(fù)責(zé)語法解析，生成字節(jié)碼；優(yōu)化器負(fù)責(zé)優(yōu)字節(jié)碼；后端負(fù)責(zé)生成相應(yīng)平臺的機器碼；
語言無關(guān)的中間代碼，可以無限擴展而又不傷害可調(diào)試性；
作為工具和函數(shù)庫，易于實現(xiàn)新的基于編程語言的優(yōu)化編譯器或VM。

WebAssembly 與LLVM結(jié)合

WebAssembly與LLVM結(jié)合，不需要為各個語言額外添加前端編譯工具，中間的IL可以不斷地優(yōu)化，僅需添加一個'后端'，就可以讓大部分語言編譯成wasm。這個'后端'不同于之前提到的后端，它不會直接生成機器碼，它生成的wasm，會由瀏覽器wasm運行時負(fù)責(zé)編譯運行。

這就是WebAssembly的編譯原理，既然WebAssembly的核心目標(biāo)是與Javascript等Web技術(shù)兼容，那么其兼容到底程度如何？下面，我們將通過項目實戰(zhàn)來驗證。

注：具體的代碼和Demo示例將在grapecity的公開課中進行演示，歡迎各位同學(xué)點擊文末“了解更多”觀看。

項目實戰(zhàn)：WebAssembly + Javascript

在進入項目實戰(zhàn)之前，大家需要理解一個核心概念，即JavaScript為何能完全控制WebAssembly代碼，并執(zhí)行下載和編譯運行：

Module（模塊）：該模塊表示一個已經(jīng)被瀏覽器編譯為可執(zhí)行機器碼的wasm二進制序列。模塊是無狀態(tài)的，它可以被緩存在IndexedDB中或者在workers之間共享，也能夠像JS一樣導(dǎo)入導(dǎo)出。
Memory（內(nèi)存）：連續(xù)大小可變的字節(jié)數(shù)組，能夠被Wasm和JS同步讀寫。它可以用來在JS和Wasm之間傳遞數(shù)據(jù)，進行通信。
Table（表格）：帶類型的大小可變的數(shù)組，表格里存儲了不能作為原始字節(jié)存儲在內(nèi)存里的對象的引用。
Instance（實例）：一個模塊及其在運行時的所有狀態(tài)，包括內(nèi)存，表格，以及導(dǎo)入的值。

可見，JavaScript API為開發(fā)者提供了創(chuàng)建模塊、內(nèi)存、表格和實例的能力。

通過一個WebAssembly實例，JavaScript能夠調(diào)用該實例暴露的函數(shù)，把JavaScript函數(shù)導(dǎo)入到WebAssembly實例中，WebAssembly也能調(diào)用JavaScript函數(shù)。

另外，WebAssembly不能直接讀寫DOM，只能調(diào)用JavaScript，并且只能傳入整形和浮點型的原始數(shù)據(jù)作為參數(shù)。因此，JavaScript能夠完全控制WebAssembly代碼實現(xiàn)下載、編譯、運行， JavaScript開發(fā)者也可以把WebAssembly想象成一個生成高性能函數(shù)的JavaScript特性。