摘要：目前，是圍繞和用例設(shè)計(jì)的。多線程在單個(gè)線程上運(yùn)行。目前不支持多線程。

本文由云+社區(qū)發(fā)表
作者：QQ音樂(lè)前端團(tuán)隊(duì)

在識(shí)別和描述核心元素的過(guò)程中，我們分享了構(gòu)建SessionStack時(shí)使用的一些經(jīng)驗(yàn)法則，這是一個(gè)輕量級(jí)但健壯且高性能的JavaScript應(yīng)用程序，以幫助用戶實(shí)時(shí)查看和重現(xiàn)其Web應(yīng)用程序的缺陷。

這次我們來(lái)分析WebAssembly的工作原理，以及在如下幾個(gè)方面和JavaScript進(jìn)行比較：加載時(shí)間，執(zhí)行速度，垃圾回收，內(nèi)存使用情況，平臺(tái)API訪問(wèn)，調(diào)試，多線程和可移植性。

WebAssembly（又名wasm）是一種高效的，低級(jí)別的編程語(yǔ)言。 它讓我們能夠使用JavaScript以外的語(yǔ)言（例如C，C ++，Rust或其他）編寫程序，然后將其編譯成WebAssembly，進(jìn)而生成一個(gè)加載和執(zhí)行速度非常快的Web應(yīng)用程序。

為了加載JavaScript，瀏覽器必須加載所有.js文本文件。 WebAssembly在瀏覽器中加載速度更快，因?yàn)橹挥幸丫幾g的wasm文件才通過(guò)互聯(lián)網(wǎng)傳輸。并且wasm是一種非常簡(jiǎn)潔的二進(jìn)制格式的低級(jí)匯編語(yǔ)言，文件更小。

目前Wasm 比本地代碼執(zhí)行速度慢20％。這倒是一個(gè)令人吃驚的結(jié)果，不過(guò)，這是一種編譯到沙盒環(huán)境中的格式并且在很多約束條件下運(yùn)行，以確保它沒(méi)有安全漏洞或者很難攻防這個(gè)漏洞。與真實(shí)的本地代碼相比，其實(shí)速度下降很小。但是，未來(lái)它會(huì)更快。

更好的是，它與瀏覽器無(wú)關(guān) - 所有主要引擎都增加了對(duì)WebAssembly的支持，并且現(xiàn)在提供類似的執(zhí)行時(shí)間。我們來(lái)看看簡(jiǎn)單看看V8中發(fā)生了什么：

在左邊，我們有一些JavaScript源代碼，包含JavaScript函數(shù)。它首先需要進(jìn)行分析，以便將所有字符串轉(zhuǎn)換為標(biāo)記并生成抽象語(yǔ)法樹（AST）。AST是JavaScript程序邏輯的內(nèi)存表示。一旦生成這種表示，V8直接轉(zhuǎn)到機(jī)器碼。一般來(lái)說(shuō)，只需要遍歷樹，生成機(jī)器代碼，便生成了編譯好的函數(shù)。從這個(gè)過(guò)程可以看出，這個(gè)階段并沒(méi)有編譯速度的優(yōu)勢(shì)。 現(xiàn)在，我們來(lái)看看V8管道在下一階段的功能：

這次我們有TurboFan，V8的優(yōu)化編譯器之一。當(dāng)您的JavaScript應(yīng)用程序正在運(yùn)行時(shí)，很多代碼在V8中運(yùn)行。TurboFan可以監(jiān)控運(yùn)行緩慢的內(nèi)容，是否存在瓶頸和熱點(diǎn)以優(yōu)化它們。它將它們推送到后端，這是一個(gè)優(yōu)化的JIT，它可以優(yōu)化那些非常耗cpu的代碼。 雖然它解決了上述問(wèn)題，但是新的問(wèn)題在于：分析代碼并決定優(yōu)化哪些內(nèi)容的過(guò)程也會(huì)消耗CPU。這反過(guò)來(lái)又意味著更高的電池消耗，特別是在移動(dòng)設(shè)備上。 然而，wasm不一樣在于，它會(huì)被插入工作流程中，如下所示：

WebAssembly可信和不可信狀態(tài) 例如，編譯成WebAssembly的C ++程序的內(nèi)存是連續(xù)的內(nèi)存塊，其中沒(méi)有“漏洞”。有助于提高安全性的wasm的特性之一是執(zhí)行堆棧與線性內(nèi)存分離的概念。在一個(gè)C ++程序中，你有一個(gè)內(nèi)存堆，你從堆的底部分配，然后從堆頂增漲堆大小。這便產(chǎn)生一個(gè)很多惡意軟件利用的漏洞：用一個(gè)指針就可以在堆棧內(nèi)存中查找數(shù)據(jù)從而更改變量，而這些數(shù)據(jù)本是你不應(yīng)該訪問(wèn)到的。

WebAssembly采用完全不同的模型。執(zhí)行堆棧與WebAssembly程序本身是分開的，因此您無(wú)法在其中修改并更改變量等內(nèi)容。而且，這些函數(shù)使用整數(shù)偏移而不是指針。函數(shù)指向一個(gè)間接函數(shù)表。然后這些直接計(jì)算的數(shù)字跳轉(zhuǎn)到模塊內(nèi)部的函數(shù)中。它是以這種方式構(gòu)建的，以便您可以同時(shí)加載多個(gè)wasm模塊，形成多個(gè)索引列表，并且一切正常。 有關(guān)JavaScript中內(nèi)存模型和管理的更多信息，可以查看關(guān)于該主題的非常詳細(xì)的帖子。

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

WebAssembly的情況有點(diǎn)不同。它支持手動(dòng)管理內(nèi)存的語(yǔ)言。您可以自定義在WASM上的垃圾回收模塊，但是這個(gè)比較復(fù)雜。

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

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

但是，將來(lái)WebAssembly將支持不附帶GC的語(yǔ)言。

取決于執(zhí)行JavaScript的運(yùn)行時(shí)，可以通過(guò)你的JavaScript應(yīng)用程序來(lái)訪問(wèn)平臺(tái)相關(guān)的API。例如，如果您在瀏覽器中運(yùn)行JavaScript，則您有一組Web APIs，Web應(yīng)用程序可以調(diào)用它來(lái)控制Web瀏覽器/設(shè)備功能并訪問(wèn)DOM, CSSOM, WebGL, IndexedDB, Web Audio API等。

然而，WebAssembly模塊無(wú)法訪問(wèn)任何平臺(tái)API。一切都是由JavaScript調(diào)用的。如果您想訪問(wèn)WebAssembly模塊中的某些平臺(tái)特定的API，則必須通過(guò)JavaScript調(diào)用它。

例如，如果你想console.log，你必須通過(guò)JavaScript來(lái)調(diào)用它，而不是你的C ++代碼。這些JavaScript調(diào)用的成本有所降低。

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

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

WebAssembly目前不支持source maps，因?yàn)闆](méi)有規(guī)范，但最終會(huì)支持（可能很快）。 當(dāng)您在C ++代碼中設(shè)置斷點(diǎn)時(shí)，您將看到C ++代碼而不是WebAssembly。

JavaScript在單個(gè)線程上運(yùn)行。有很多方法可以利用Event Loop并利用異步編程。

JavaScript也使用Web Workers，但他們有一個(gè)非常具體的用例 - 基本上，可能阻塞主UI線程的任何CPU密集計(jì)算都可以進(jìn)入到Web Worker中來(lái)提高性能。但是，Web Workers無(wú)法訪問(wèn)DOM。

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

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

WebAssembly被設(shè)計(jì)為安全和便攜。就像JavaScript一樣。它將運(yùn)行在支持主機(jī)的每個(gè)環(huán)境中（例如每個(gè)瀏覽器）。就像當(dāng)年的Java的Applets，WebAssembly有相同的可移植性的愿景。

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

http://s3.amazonaws.com/mozil...。

這是 Unreal engine.。

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

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

將來(lái)，即使您實(shí)際上沒(méi)有編寫編譯代碼，您也可以使用WASM二進(jìn)制文件。您可以在NPM中找到開始使用此方法的項(xiàng)目。

對(duì)于DOM操作和沉重的平臺(tái)API使用，使用JavaScript確實(shí)很有意義，因?yàn)樗粫?huì)增加額外的開銷，并且具有本地提供的API。

在SessionStack中，我們不斷增強(qiáng)JavaScript的性能，以編寫高度優(yōu)化且高效的代碼。我們的解決方案需要提供超快的性能，因?yàn)槲覀儾荒茏璧K客戶應(yīng)用的性能。將SessionStack集成到生產(chǎn)Web應(yīng)用程序或網(wǎng)站后，它會(huì)開始記錄所有內(nèi)容：所有DOM更改，用戶交互，JavaScript異常，堆棧跟蹤，失敗的網(wǎng)絡(luò)請(qǐng)求和調(diào)試數(shù)據(jù)。所有這些都在您的生產(chǎn)環(huán)境中進(jìn)行，而不會(huì)影響產(chǎn)品的任何UX和性能。我們需要大量?jī)?yōu)化我們的代碼并盡可能使其異步。

不僅僅是庫(kù)文件，當(dāng)在SessionStack中重放用戶回話時(shí)，我們會(huì)渲染用戶瀏覽器中發(fā)生的所有事件，并且我們必須重構(gòu)整個(gè)狀態(tài)，允許您在會(huì)話時(shí)間線中來(lái)回跳轉(zhuǎn)。因?yàn)闆](méi)有更好的選擇，為了做到這一點(diǎn)，我們大量使用了JavaScript提供的異步機(jī)會(huì)。

借助WebAssembly，我們將能夠?qū)⒁恍┳罘敝氐奶幚砗弯秩巨D(zhuǎn)換為更適合作業(yè)的語(yǔ)言，并將數(shù)據(jù)收集和DOM操作保留為JavaScript。

如果你想嘗試下SessionStack，你可以免費(fèi)開始。有一個(gè)免費(fèi)的計(jì)劃)，每月提供1000個(gè)會(huì)話。

參考:

https://www.youtube.com/watch...

https://www.youtube.com/watch...

此文已由騰訊云+社區(qū)在各渠道發(fā)布

獲取更多新鮮技術(shù)干貨，可以關(guān)注我們騰訊云技術(shù)社區(qū)-云加社區(qū)官方號(hào)及知乎機(jī)構(gòu)號(hào)