WebAssembly 對比 JavaScript 及其使用場景

這是 JavaScript 工作原理的第六章。

現在，我們將會剖析 WebAssembly 的工作原理，而最重要的是它和 JavaScript 在效能方面的比對：載入時間，執行速度，垃圾回收，記憶體使用，平臺 API 訪問，除錯，多執行緒以及可移植性。

我們構建網頁程式的方式正面臨著改革－這只是個開始而我們對於網路應用的思考方式正在發生改變。

首先，認識下 WebAssembly 吧

WebAssembly（又稱 wasm） 是一種用於開發網路應用的高效，底層的位元組碼。

WASM 讓你在其中使用除 JavaScript 的語言以外的語言（比如 C, C++, Rust 及其它）來編寫應用程式，然後編譯成（提早） WebAssembly。

構建出來的網路應用載入和執行速度都會非常快。

載入時間

為了載入 JavaScript，瀏覽器必須載入所有文字格式的 js 檔案。

瀏覽器會更加快速地載入 WebAssembly，因為 WebAssembly 只會傳輸已經編譯好的 wasm 檔案。而且 wasm 是底層的類組合語言，具有非常緊湊的二進位制格式。

執行速度

如今 Wasm 執行速度只比原生程式碼慢 20%。無論如何，這是一個令人驚喜的結果。它是這樣的一種格式，會被編譯進沙箱環境中且在大量的約束條件下執行以保證沒有任何安全漏洞或者使之強化。和真正的原生程式碼比較，執行速度的下降微乎其微。另外，未來將會更加快速。

更讓人高興的是，它具備很好的瀏覽器相容特性－所有主流瀏覽器引擎都支援 WebAssembly 且執行速度相關無幾。

為了理解和 JavaScript 對比，WebAssembly 的執行速度有多快，你應該首先閱讀之前的 JavaScript 引擎工作原理的文章。

讓我們快速瀏覽下 V8 的執行機制：

V8 技術：懶編譯

左邊是 JavaScript 原始碼，包含 JavaScript 函式。首先，原始碼先把字串轉換為記號以便於解析，之後生成一個語法抽象樹。

語法抽象樹是你的 JavaScript 程式邏輯的記憶體中圖示。一旦生成圖示，V8 直接進入到機器碼階段。你基本上是遍歷樹，生成機器碼然後獲得編譯後的函式。這裡沒有任何真正的嘗試來加速這一過程。

現在，讓我們看一下下一階段 V8 管道的工作內容：

V8 管道設計

現在，我們擁有 TurboFan ，它是 V8 的優化編譯程式之一。當 JavaScript 執行的時候，大量的程式碼是在 V8 內部執行的。TurboFan 監視執行得慢的程式碼，引起效能瓶頸的地方及熱點（記憶體使用過高的地方）以便優化它們。它把以上監視得到的程式碼推向後端即優化過的即時編譯器，該編譯器把消耗大量 CPU 資源的函式轉換為效能更優的程式碼。

它解決了效能的問題，但是缺點即是分析程式碼及辨別哪些程式碼需要優化的過程也是會消耗 CPU 資源的。這也即意味著更多的耗電量，特別是在手機裝置。

但是，wasm 並不需要以上的全部步驟－它如下所示插入到執行過程中：

V8 管道設計 + WASM

wasm 在編譯階段就已經通過了程式碼優化。總之，解析也不需要了。你擁有優化後的二進位制程式碼可以直接插入到後端（即時編譯器）並生成機器碼。編譯器在前端已經完成了所有的程式碼優化工作。

由於跳過了編譯過程中的不少步驟，這使得 wasm 的執行更加高效。

記憶體模型

WebAssembly 可信和不可信狀態

舉個例子，一個 C++ 的程式的記憶體被編譯為 WebAssembly，它是整段連續的沒有空洞的記憶體塊。wasam 中有一個可以用來提升程式碼安全性的功能即執行堆疊和線性記憶體隔離的概念。在 C++ 程式中，你有一塊動態記憶體區，你從其底部分配獲得記憶體堆疊，然後從其頂部獲得記憶體來增加記憶體堆疊的大小。你可以獲得一個指標然後在堆疊記憶體中遍歷以操作你不應該接觸到的變數。

這是大多數可疑軟體可以利用的漏洞。

WebAssembly 採用了完全不同的記憶體模型。執行堆疊和 WebAssembly 程式本身是隔離開來的，所以你無法從裡面進行修改和改變諸如變數值的情形。同樣地，函式使用整數偏移而不是指標。函式指向一個間接函式表。之後，這些直接的計算出的數字進入模組中的函式。它就是這樣執行的，這樣你就可以同時引入多個 wasm 模組，偏移所有索引且每個模組都執行良好。

更多關於 JavaScript 記憶體模型和管理的文章詳見這裡。

記憶體垃圾回收

你已經知曉 JavaScript 的記憶體管理是由記憶體垃圾回收器處理的。

WebAssembly 的情況有點不太一樣。它支援手動操作記憶體的語言。你也可以在你的 wasm 模組中內建記憶體垃圾回收器，但這是一項複雜的任務。

目前，WebAssembly 是專門圍繞 C++ 和 RUST 的使用場景設計的。由於 wasm 是非常底層的語言，這意味著只比組合語言高一級的程式語言會容易被編譯成 WebAssembly。C 語言可以使用 malloc，C++ 可以使用智慧指標，Rust 使用完全不同的模式（一個完全不同的話題）。這些語言沒有使用記憶體垃圾回收器，所以他們不需要所有複雜執行時的東西來追蹤記憶體。WebAssembly 自然就很適合於這些語言。

另外，這些語言並不能夠 100% 地應用於複雜的 JavaScript 使用場景比如監聽 DOM 變化 。用 C++ 來寫整個的 HTML 程式是毫無意義的因為 C++ 並不是為此而設計的。大多數情況下，工程師用使用 C++ 或 Rust 來編寫 WebGL 或者高度優化的庫（比如大量的數學運算）。

然而，將來 WebAssembly 將會支援不帶記憶體垃圾回功能的的語言。

平臺介面訪問

依賴於執行 JavaScript 的執行時環境，可以通過 JavaScript 程式來直接訪問這些平臺所暴露出的指定介面。比如，當你在瀏覽器中執行 JavaScript，網路應用可以呼叫一系列的網頁介面來控制瀏覽器／裝置的功能且訪問 DOM，CSSOM，WebGL，IndexedDB，Web Audio API 等等。

然而，WebAssembly 模組不能夠訪問任何平臺的介面。所有的這一切都得由 JavaScript 來進行協調。如果你想在 WebAssembly 模組內訪問一些指定平臺的介面，你必須得通過 JavaScript 來進行呼叫。

舉個例子，如果你想要使用 console.log，你就得通過JavaScript 而不是 C++ 程式碼來進行呼叫。而這些 JavaScript 呼叫會產生一定的效能損失。

情況不會一成不變的。規範將會為在未來為 wasm 提供訪問指定平臺的介面，這樣你就可以不用在你的程式中內建 JavaScript。

原始碼對映

當你壓縮了 JavaScript 程式碼的時候，你需要有合適的方法來進行除錯。

這時候原始碼對映就派上用場了。

大體上，原始碼對映就是把合併／壓縮了的檔案對映到未構建狀態的一種方式。當你為生產環境進行程式碼構建的時候，與壓縮和合並 JavaScript 一起，你會生成原始碼對映用來儲存原始檔案資訊。當你想在生成的 JavaScript 程式碼中查詢特定的行和列的程式碼的時候，你可以在原始碼對映中進行查詢以返回程式碼的原始位置。

由於沒有規範定義原始碼對映，所以目前 WebAssembly 並不支援，但最終會有的（可能快了）。

當你在 C++ 程式碼中設定了斷點，你將會看到 C++ 程式碼而不是 WebAssembly。至少，這是 WebAssembly 原始碼對映的目標吧。

多執行緒

JavaScript 是單執行緒的。有很多方法來利用事件迴圈和使用在之前的文章中有提到的非同步程式設計。

JavaScript 也使用 Web Workers 但是隻有在極其特殊的情況下－大體上，可以把任何可能阻塞 UI 主執行緒的密集的 CPU 計算移交給 Web Worker 執行以獲得更好的效能。但是，Web Worker 不能夠訪問 DOM。

目前 WebAssembly 不支援多執行緒。但是，這有可能是接下來 WebAssembly 要實現的。Wasm 將會接近實現原生的執行緒（比如，C++ 風格的執行緒）。擁有真正的執行緒將會在瀏覽器中創造出很多新的機遇。並且當然，會增加濫用的可能性。

可移植性

現在 JavaScript 幾乎可以執行於任意的地方，從瀏覽器到服務端甚至在嵌入式系統中。

WebAssembly 設計旨在安全性和可移植性。正如 JavaScript 那樣。它將會在任何支援 wasm 的環境（比如每個瀏覽器）中執行。

WebAssembly 擁有和早年 Java 使用 Applets 來實現可移植性的同樣的目標。

WebAssembly 使用場景

WebAssembly 的最初版本主要是為了解決大量計算密集型的計算的（比如處理數學問題）。最為主流的使用場景即遊戲－處理大量的畫素。

你可以使用你熟悉的 OpenGL 繫結來編寫 C++/Rust 程式，然後編譯成 wasm。之後，它就可以在瀏覽器中執行。

瀏覽下（在火孤中執行）－http://s3.amazonaws.com/mozilla-games/tmp/2017-02-21-SunTemple/SunTemple.html。這是執行於Unreal engine（這是一個可以用來開發虛擬現實的開發套件）中的。

另一個合理使用 WebAssembly （高效能）的情況即實現一些處理計算密集型的庫。比如，一些圖形操作。

正如之前所提到的，wasm 可以有效減少移動裝置的電力損耗（依賴於引擎），這是由於大多數的步驟已經在編譯階段提前處理完成。

未來，你可以直接使用 WASM 二進位制庫即使你沒有編寫編譯成它的程式碼。你可以在 NPM 上面找到一些開始使用這項技術的專案。

針對操作 DOM 和頻繁使用平臺介面的情況 ，使用 JavaScript 會更加合理，因為它不會產生額外的效能開銷且它原生支援各種介面。

在 SessionStack 我們一直致力於持續提升 JavaScript 的效能以編寫高質量和高效的程式碼。我們的解決方案必須擁有閃電般的效能因為我們不能夠影響使用者程式的效能。一旦你把 SessionStack 整合進你的網路應用或網站的生產環境，它會開始記錄所有的一切：所有的 DOM 變化，使用者互動，JavaScript 異常，堆疊追蹤，失敗的網路請求和除錯資料。所有的這一切都是在你的生產環境中產生且沒有影響到你的產品的任何互動和效能。我們必須極大地優化我們的程式碼並且儘可能地讓它非同步執行。

我們不僅僅有庫，還有其它功能！當你在 SessionStack 中重放使用者會話，我們必須渲染問題產生時你的使用者的瀏覽器所發生的一切，而且我們必須重構整個狀態，允許你在會話時間線上來回跳轉。為了使之成為可能，我們大量地使用非同步操作，因為 JavaScript 中沒有比這更好的替代選擇了。

有了 WebAssembly，我們就可以把大量的資料計算和渲染的工作移交給更加合適的語言來進行處理而把資料收集和 DOM 操作交給 JavaScript 進行處理。

番外篇

開啟 webassembly 官網就可以在頭部醒目地看到顯示它相容的瀏覽器。分別是火孤，Chrome，Safari，IE Edge。點開 learn more 可以檢視到這是於 2017／2／28 達成一致推出瀏覽器預覽版。現在各項工作開始進入實施階段了，相信在未來的某個時刻就可以在生產環境使用它了。官網上面介紹了一個 JavaScript 的子集 asm.js。另外，這裡有一個 WebAssembly 和 JavaScript 進行效能比對的測試網站。