摘要：我們將拆分來分析它的工作原理，更重要的是，它在性能方面如何提升加載時間，執(zhí)行速度，垃圾回收，內(nèi)存使用率，平臺訪問，調(diào)試，多線程和可移植性。目前，是圍繞和用例設(shè)計的。多線程在單個線程上運行。目前不支持多線程。被設(shè)計為安全和便攜。

我們將拆分WebAssembly來分析它的工作原理，更重要的是，它在性能方面如何提升JavaScript：加載時間，執(zhí)行速度，垃圾回收，內(nèi)存使用率，平臺API訪問，調(diào)試，多線程和可移植性。

我們構(gòu)建Web應(yīng)用程序的方式正處于革命的邊緣 - 這仍然是初期階段，但我們對Web應(yīng)用程序的看法正在發(fā)生變化。

WebAssembly（又名wasm）是一種高效的，低級的網(wǎng)絡(luò)字節(jié)碼。

WASM使您能夠使用JavaScript以外的語言（例如C，C ++，Rust或其他），在其中編寫程序，然后將其編譯（提前）到WebAssembly。

其結(jié)果是一個加載和執(zhí)行速度非?？斓腤eb應(yīng)用程序。

為了加載JavaScript，瀏覽器必須加載所有文本的.js文件。

WebAssembly在瀏覽器中加載速度更快，因為只有已編譯的wasm文件必須通過互聯(lián)網(wǎng)傳輸。而wasm是一種非常簡潔的二進制格式的低級匯編語言。

今天Wasm比本地代碼執(zhí)行速度慢20％。無論如何，這是一個驚人的結(jié)果。它是一種編譯到沙箱環(huán)境中的格式，并且在很多約束條件下運行，以確保它沒有安全漏洞，或者對它們非常強硬。與真正的本地代碼相比，速度下降很小。更重要的是，未來它會更快。

更好的是，它與瀏覽器無關(guān) - 所有主要引擎都增加了對WebAssembly的支持，并且現(xiàn)在提供類似的執(zhí)行時間。

為了理解WebAssembly與JavaScript相比執(zhí)行得有多快，您應(yīng)該先閱讀我們關(guān)于JavaScript引擎如何工作的文章。

我們來看看V8中會發(fā)生什么樣的快速概述：

在左側(cè)，我們有一些JavaScript源代碼，包含JavaScript函數(shù)。它首先需要進行分析，以便將所有字符串轉(zhuǎn)換為標記并生成抽象語法樹（AST）。AST是JavaScript程序邏輯的內(nèi)存表示。一旦生成這種表示，V8直接轉(zhuǎn)到機器碼。基本上遍歷樹，生成機器代碼，生成你的編譯后的函數(shù)。 沒有真正的嘗試來加速它。

現(xiàn)在，我們來看看V8管道在下一階段的功能：

這次我們有TurboFan，V8的優(yōu)化編譯器之一。當您的JavaScript應(yīng)用程序正在運行時，很多代碼在V8中運行。TurboFan可以監(jiān)控某些內(nèi)容是否運行緩慢，是否存在瓶頸和熱點以優(yōu)化它們。它將它們推送到后端，這是一個優(yōu)化的JIT，它為那些耗時耗力CPU的函數(shù)創(chuàng)建了更快的代碼。

它解決了這個問題，但這里的問題在于，分析代碼并決定優(yōu)化哪些內(nèi)容的過程也會消耗CPU。 這反過來又意味著更高的電池消耗，特別是在移動設(shè)備上。

那么，wasm并不需要所有這些 - 它會被插入工作流程中，如下所示：

在匯編階段，wasm已經(jīng)通過優(yōu)化。最重要的是，解析也不是必需的。你有一個優(yōu)化的二進制文件，可以直接掛接到可以生成機器碼的后端。 所有優(yōu)化都由編譯器在前端完成。

這使得執(zhí)行wasm更有效率，因為流程中的很多步驟都可以簡單地跳過。

例如，編譯成WebAssembly的C++程序的內(nèi)存是連續(xù)的內(nèi)存塊，其中沒有“洞”。有助于提高安全性的wasm的特性之一是執(zhí)行堆棧與線性內(nèi)存分離的概念。在一個C++程序中，你有一堆，你從堆的底部分配，然后從堆頂部開始堆棧。可以帶一個指針，然后在堆棧內(nèi)存中查找，以便玩弄你不應(yīng)該觸摸的變量。

這是很多惡意軟件利用的陷阱。

WebAssembly采用完全不同的模型。執(zhí)行堆棧與WebAssembly程序本身是分開的，因此您無法在其中修改并更改變量等內(nèi)容。而且，這些函數(shù)使用整數(shù)偏移而不是指針。函數(shù)指向一個間接函數(shù)表。然后這些直接計算的數(shù)字跳轉(zhuǎn)到模塊內(nèi)部的函數(shù)中。它是以這種方式構(gòu)建的，以便您可以并排加載多個wasm模塊，并抵消所有索引，并且一切正常。

有關(guān)JavaScript中內(nèi)存模型和管理的更多信息，可以查看關(guān)于該主題的非常詳細的帖子。

您已經(jīng)知道JavaScript的內(nèi)存管理是使用垃圾收集器處理的。

WebAssembly的情況有點不同。它支持手動管理內(nèi)存的語言。您可以將自己的GC與您的wasm模塊一起發(fā)貨，但這是一項復(fù)雜的任務(wù)。

目前，WebAssembly是圍繞C++和RUST用例設(shè)計的。由于wasm是非常低級的，因此編程語言只是匯編語言之上的一個步驟就很容易編譯。 C可以使用普通的malloc，C++可以使用智能指針，Rust使用完全不同的范例（完全不同的主題）。這些語言不使用GC，因此它們不需要所有復(fù)雜的運行時間內(nèi)容來跟蹤內(nèi)存。 WebAssembly對他們來說是天作之合。

另外，這些語言并不是100％設(shè)計用于調(diào)用DOM等復(fù)雜的JavaScript事物。在C++中編寫整個HTML應(yīng)用程序是沒有意義的，因為C++不是為它設(shè)計的。在大多數(shù)情況下，當工程師編寫C++或Rust時，他們的目標是WebGL或高度優(yōu)化的庫（例如繁重的數(shù)學(xué)計算）。

但是，將來WebAssembly將支持不附帶GC的語言。

取決于執(zhí)行JavaScript的運行時，訪問特定于平臺的API將被公開，可通過JavaScript應(yīng)用程序直接訪問。例如，如果您在瀏覽器中運行JavaScript，則您有一組Web API，Web應(yīng)用程序可以調(diào)用它來控制Web瀏覽器/設(shè)備功能并訪問DOM，CSSOM，WebGL，IndexedDB，Web Audio API等。

那么，WebAssembly模塊無法訪問任何平臺API。一切都是由JavaScript調(diào)解的。如果您想訪問WebAssembly模塊中的某些平臺特定的API，則必須通過JavaScript調(diào)用它。

例如，如果您想使用console.log，則必須通過JavaScript調(diào)用它，而不是使用C ++代碼。這些JavaScript調(diào)用的成本有所降低。

這并不總是如此。該規(guī)范將在未來為平臺API提供wasm，并且您將能夠在沒有JavaScript的情況下發(fā)布您的應(yīng)用程序。

當您壓縮JavaScript代碼時，您需要一種正確調(diào)試它的方法。這就是Source Maps來拯救的地方。
基本上，源地圖是一種將組合/縮小文件映射回未建立狀態(tài)的方法。當您為生產(chǎn)而構(gòu)建時，同時縮小和組合您的JavaScript文件，您將生成一個包含原始文件信息的源映射。當您在生成的JavaScript中查詢某一行和列號時，可以在返回原始位置的源地圖中執(zhí)行查找。

WebAssembly目前不支持源地圖，因為沒有規(guī)范，但最終（可能很快）。

當您在C++代碼中設(shè)置斷點時，您將看到C++代碼而不是WebAssembly。至少，這是目標。

JavaScript在單個線程上運行。有很多方法可以利用Event Loop并利用異步編程，如我們關(guān)于該主題的文章中詳細介紹的那樣。

JavaScript也使用Web Workers，但他們有一個非常具體的用例 - 基本上，任何激烈的CPU計算會阻止主UI線程，把他們放到Web Worker中將會受益。但是，Web Workers無法訪問DOM。

WebAssembly目前不支持多線程。但是，這可能是未來的事情。 Wasm將接近本地線程（例如C++樣式線程）。擁有“真實”的線程將在瀏覽器中創(chuàng)造出許多新的機會。當然，這將打開更多濫用可能性的大門。

如今，JavaScript幾乎可以在任何地方運行，從瀏覽器到服務(wù)器端甚至嵌入式系統(tǒng)。

WebAssembly被設(shè)計為安全和便攜。就像JavaScript一樣。 它將運行在支持主機的每個環(huán)境中（例如每個瀏覽器）。

WebAssembly具有與Java初期嘗試實現(xiàn)的Appliets相同的目標

在WebAssembly的第一個版本中，主要關(guān)注CPU占用大的計算（例如處理數(shù)學(xué)）。想到的最主流的用途是游戲 - 那里有大量的像素操作。您可以使用您習(xí)慣的OpenGL綁定在C ++ / Rust中編寫您的應(yīng)用程序，并將其編譯為wasm。它會在瀏覽器中運行。

看看這個（在Firefox中運行） - http://s3.amazonaws.com/mozil...。這是運行虛幻引擎。

另一種使用WebAssembly（性能方面）可能有意義的情況是實現(xiàn)一些庫，這是一個CPU密集型工作。例如，一些圖像處理。

如前所述，由于大多數(shù)處理步驟在編譯期間已提前完成，因此可以減少移動設(shè)備上的電池消耗（取決于引擎）。

將來，即使您實際上沒有編寫編譯代碼，您也可以使用WASM二進制文件。您可以在NPM中找到開始使用此方法的項目。

對于DOM操作和沉重的平臺API使用，使用JavaScript確實很有意義，因為它不會增加額外開銷，并且API本身提供。