本文由雲+社群發表
作者：QQ音樂前端團隊
在識別和描述核心元素的過程中，我們分享了構建SessionStack時使用的一些經驗法則，這是一個輕量級但健壯且高效能的JavaScript應用程式，以幫助使用者實時檢視和重現其Web應用程式的缺陷。
這次我們來分析WebAssembly的工作原理，以及在如下幾個方面和JavaScript進行比較：載入時間，執行速度，垃圾回收，記憶體使用情況，平臺API訪問，除錯，多執行緒和可移植性。
WebAssembly的功能
WebAssembly（又名wasm）是一種高效的，低階別的程式語言。 它讓我們能夠使用JavaScript以外的語言（例如C，C ++，Rust或其他）編寫程式，然後將其編譯成WebAssembly，進而生成一個載入和執行速度非常快的Web應用程式。
載入時間
為了載入JavaScript，瀏覽器必須載入所有.js文字檔案。 WebAssembly在瀏覽器中載入速度更快，因為只有已編譯的wasm檔案才通過網際網路傳輸。並且wasm是一種非常簡潔的二進位制格式的低階組合語言，檔案更小。
執行
目前Wasm 比原生程式碼執行速度慢20％。這倒是一個令人吃驚的結果，不過，這是一種編譯到沙盒環境中的格式並且在很多約束條件下執行，以確保它沒有安全漏洞或者很難攻防這個漏洞。與真實的原生程式碼相比，其實速度下降很小。但是，未來它會更快。
更好的是，它與瀏覽器無關 - 所有主要引擎都增加了對WebAssembly的支援，並且現在提供類似的執行時間。我們來看看簡單看看V8中發生了什麼：
V8 Approach: lazy compilation
在左邊，我們有一些JavaScript原始碼，包含JavaScript函式。它首先需要進行分析，以便將所有字串轉換為標記並生成抽象語法樹（AST）。AST是JavaScript程式邏輯的記憶體表示。一旦生成這種表示，V8直接轉到機器碼。一般來說，只需要遍歷樹，生成機器程式碼，便生成了編譯好的函式。從這個過程可以看出，這個階段並沒有編譯速度的優勢。 現在，我們來看看V8管道在下一階段的功能：
V8管道設計
這次我們有TurboFan，V8的優化編譯器之一。當您的JavaScript應用程式正在執行時，很多程式碼在V8中執行。TurboFan可以監控執行緩慢的內容，是否存在瓶頸和熱點以優化它們。它將它們推送到後端，這是一個優化的JIT，它可以優化那些非常耗cpu的程式碼。 雖然它解決了上述問題，但是新的問題在於：分析程式碼並決定優化哪些內容的過程也會消耗CPU。這反過來又意味著更高的電池消耗，特別是在移動裝置上。 然而，wasm不一樣在於，它會被插入工作流程中，如下所示：
記憶體模型
WebAssembly可信和不可信狀態 例如，編譯成WebAssembly的C ++程式的記憶體是連續的記憶體塊，其中沒有“漏洞”。有助於提高安全性的wasm的特性之一是執行堆疊與線性記憶體分離的概念。在一個C ++程式中，你有一個記憶體堆，你從堆的底部分配，然後從堆頂增漲堆大小。這便產生一個很多惡意軟體利用的漏洞：用一個指標就可以在堆疊記憶體中查詢資料從而更改變數，而這些資料本是你不應該訪問到的。
WebAssembly採用完全不同的模型。執行堆疊與WebAssembly程式本身是分開的，因此您無法在其中修改並更改變數等內容。而且，這些函式使用整數偏移而不是指標。函式指向一個間接函式表。然後這些直接計算的數字跳轉到模組內部的函式中。它是以這種方式構建的，以便您可以同時載入多個wasm模組，形成多個索引列表，並且一切正常。 有關JavaScript中記憶體模型和管理的更多資訊，可以檢視關於該主題的非常詳細的帖子。
垃圾回收
您已經知道JavaScript的記憶體管理是使用垃圾回收器處理的。
WebAssembly的情況有點不同。它支援手動管理記憶體的語言。您可以自定義在WASM上的垃圾回收模組，但是這個比較複雜。
目前，WebAssembly是圍繞C ++和RUST用例設計的。由於wasm是非常低階的，因此只有組合語言上一步的程式語言才易於編譯。C可以使用普通的malloc，C ++可以使用智慧指標，Rust使用完全不同的模式（完全不同的主題）。這些語言不使用GC，因此它們不需要所有複雜的執行時內容來跟蹤記憶體。WebAssembly對他們來說是天作之合。
另外，這些語言並不是100％設計用於呼叫複雜的JavaScript事物，如DOM。在C ++中編寫整個HTML應用程式是沒有意義的，因為C ++不是為它設計的。在大多數情況下，當工程師編寫C ++或Rust時，他們的目標是WebGL或高度優化的庫（例如重數學計算）。
但是，將來WebAssembly將支援不附帶GC的語言。
平臺API訪問
取決於執行JavaScript的執行時，可以通過你的JavaScript應用程式來訪問平臺相關的API。例如，如果您在瀏覽器中執行JavaScript，則您有一組Web APIs，Web應用程式可以呼叫它來控制Web瀏覽器/裝置功能並訪問DOM, CSSOM, WebGL, IndexedDB, Web Audio API等。
然而，WebAssembly模組無法訪問任何平臺API。一切都是由JavaScript呼叫的。如果您想訪問WebAssembly模組中的某些平臺特定的API，則必須通過JavaScript呼叫它。
例如，如果你想console.log，你必須通過JavaScript來呼叫它，而不是你的C ++程式碼。這些JavaScript呼叫的成本有所降低。
這並不總是如此。該規範將在未來為平臺API提供wasm，並且您將能夠在沒有JavaScript的情況下發布您的應用程式。
Source maps
當您精簡JavaScript原始碼時，您需要一種正確方式除錯它。這就需要Source Maps。基本上， Source Maps 是一種將組合/縮小檔案對映回未建立狀態的方法。當您為生產而構建時，同時縮小和組合您的JavaScript檔案，您將生成一個包含原始檔案資訊的源對映。當您在生成的JavaScript中查詢某一行和列號時，可以在返回原始位置的源地圖中執行查詢。
WebAssembly目前不支援source maps，因為沒有規範，但最終會支援（可能很快）。 當您在C ++程式碼中設定斷點時，您將看到C ++程式碼而不是WebAssembly。
多執行緒
JavaScript在單個執行緒上執行。有很多方法可以利用Event Loop並利用非同步程式設計。
JavaScript也使用Web Workers，但他們有一個非常具體的用例 - 基本上，可能阻塞主UI執行緒的任何CPU密集計算都可以進入到Web Worker中來提高效能。但是，Web Workers無法訪問DOM。
WebAssembly目前不支援多執行緒。但是，這可能是未來的事情。Wasm將更接近本地執行緒（例如C ++樣式執行緒）。擁有“真實”的執行緒將在瀏覽器中創造出許多新的機會。當然，這將開啟更多濫用可能性的大門。
可移植性
如今，JavaScript幾乎可以在任何地方執行，從瀏覽器到伺服器端甚至嵌入式系統。
WebAssembly被設計為安全和便攜。就像JavaScript一樣。它將執行在支援主機的每個環境中（例如每個瀏覽器）。就像當年的Java的Applets，WebAssembly有相同的可移植性的願景。
哪些場景更合適使用WA
在WebAssembly的第一個版本中，主要關注CPU佔用大的計算（例如處理數學）。想到的最主流的用途是遊戲 - 那裡有大量的畫素操作。您可以使用您習慣的OpenGL在C ++ / Rust中編寫您的應用程式，並將其編譯為wasm。它會在瀏覽器中執行。 看看這個（在Firefox中執行）
這是 Unreal engine.。
另一種使用WebAssembly（效能方面）可能有意義的情況是實現一些庫，這是一個CPU密集型工作。例如，一些影象處理。
如前所述，由於大多數處理步驟都是在編譯期間提前完成的，因此wasm可以減少移動裝置上的電池消耗（取決於引擎）。
將來，即使您實際上沒有編寫編譯程式碼，您也可以使用WASM二進位制檔案。您可以在NPM中找到開始使用此方法的專案。
對於DOM操作和沉重的平臺API使用，使用JavaScript確實很有意義，因為它不會增加額外的開銷，並且具有本地提供的API。
在SessionStack中，我們不斷增強JavaScript的效能，以編寫高度優化且高效的程式碼。我們的解決方案需要提供超快的效能，因為我們不能阻礙客戶應用的效能。將SessionStack整合到生產Web應用程式或網站後，它會開始記錄所有內容：所有DOM更改，使用者互動，JavaScript異常，堆疊跟蹤，失敗的網路請求和除錯資料。所有這些都在您的生產環境中進行，而不會影響產品的任何UX和效能。我們需要大量優化我們的程式碼並儘可能使其非同步。
不僅僅是庫檔案，當在SessionStack中重放使用者回話時，我們會渲染使用者瀏覽器中發生的所有事件，並且我們必須重構整個狀態，允許您在會話時間線中來回跳轉。因為沒有更好的選擇，為了做到這一點，我們大量使用了JavaScript提供的非同步機會。
藉助WebAssembly，我們將能夠將一些最繁重的處理和渲染轉換為更適合作業的語言，並將資料收集和DOM操作保留為JavaScript。
如果你想嘗試下SessionStack，你可以免費開始。有一個免費的計劃)，每月提供1000個會話。
參考:
此文已由騰訊雲+社群在各渠道釋出
獲取更多新鮮技術乾貨，可以關注我們騰訊雲技術社群-雲加社群官方號及知乎機構號