JavaScript 工做原理之六－WebAssembly 對比 JavaScript 及其使用場景

原文請查閱這裏，略有改動，本文采用知識共享署名 4.0 國際許可協議共享，BY Troland。

本系列持續更新中，Github 地址請查閱這裏。

這是 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。以後，它就能夠在瀏覽器中運行。

瀏覽下（在火孤中運行）－s3.amazonaws.com/mozilla-gam…。這是運行於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 進行性能比對的測試網站。

打個廣告 ^.^

今日頭條招人啦！發送簡歷到 likun.liyuk@bytedance.com ，便可走快速內推通道，長期有效！國際化PGC部門的JD以下：c.xiumi.us/board/v5/2H…，也可內推其餘部門！

本系列持續更新中，Github 地址請查閱這裏。