摘要：現(xiàn)狀年月日，主流的四大瀏覽器達成了共識并宣布的最小可行產(chǎn)品已經(jīng)完成。更快的函數(shù)調(diào)用當前，在中調(diào)用函數(shù)比想象的要慢。直接操作目前，沒有任何方式能夠操作。這就導致了部分應用可能會因此而推遲發(fā)布時間。結束現(xiàn)如今已經(jīng)相當快速。

本文是圖說 WebAssembly 系列文章的最后一篇。如果您還未閱讀之前的文章，建議您從第一篇入手。

2017 年 2 月 28 日，主流的四大瀏覽器達成了共識并宣布 WebAssembly 的最小可行產(chǎn)品（MVP）已經(jīng)完成。這是 WebAssembly 搭載在瀏覽器上的第一個穩(wěn)定初始版本。

這也為瀏覽器提供了一個穩(wěn)定的 WebAssembly 核心。雖然該核心還不好漢社區(qū)組正在計劃的所有功能，但它也確實提供了足夠的功能，使得 WebAssembly 快速且可用。

從這一刻開始，開發(fā)者也可以開始發(fā)布 WebAssembly 代碼了。對于較早版本的瀏覽器，開發(fā)者可以回退到使用 asm.js 版本的代碼。因為 asm.js 是 JavaScript 的子集，所以任何 JavaScript 引擎都可以運行它。
如果使用 Emscripten 的話，還可以把相同的應用編譯為 WebAssembly 版本和 asm.js 版本的代碼。

即使是最初的發(fā)行版本，WebAssembly 也是高性能的。但是隨著問題的修復和新功能的添加，它在未來將會擁有更高性能。

隨著瀏覽器逐步改進對 WebAssembly 的支持，性能提升也會慢慢的顯現(xiàn)。目前，瀏覽器廠商們正在獨自改進下面這些問題。

當前，在 JavaScript 中調(diào)用 WebAssembly 函數(shù)比想象的要慢。這是因為這個過程必須經(jīng)歷一個稱為彈跳（Trampolining）的過程。JIT 并不知道如何直接處理 WebAssembly，所以它必須把 WebAssembly 轉(zhuǎn)移到知道如何處理它的地方去。這在引擎內(nèi)部是一個很慢的過程，該過程會建立用來運行 WebAssembly 代碼的準備過程。

這個種處理方式可能比直接由 JIT 處理慢 100 倍。

如果將一個大型任務交給 WebAssembly 模塊來完成的話，我們可能不會注意到這種開銷。
但是如果我們在 WebAssembly 和 JavaScript 之間來回多次調(diào)用，那么這個問題就凸顯出來了。

JIT 必須在更快的加載時間和更快的運行之間做出權衡。
如果花費更多的時間在編譯和優(yōu)化，雖然可以提升運行速度，但是也降低了啟動性能。

一個基本事實是，大多數(shù)的代碼的運行次數(shù)其實都還達不到需要優(yōu)化的地步。
不過，目前有許多正在進行的研究，在尋找預編譯和這樣的基本事實之間的平衡點。

由于 WebAssembly 并不需要推測數(shù)據(jù)類型，所以引擎也不需要在運行時監(jiān)視這些數(shù)據(jù)類型的變化。
這也就給了我們更多的選擇余地，例如把編譯和運行并行化。

此外，最近新增的 JavaScript API 允許對 WebAssembly 進行流式編譯。也就是說，引擎可以在 .wasm 還沒下載完成的時候就開始對已下載的內(nèi)容進行編譯。

在 Firefox，我們正在開發(fā)雙編譯系統(tǒng)。一個編譯器會提前運行，并把代碼優(yōu)化工作做得相當不錯。等到運行代碼的時候，另一個編譯器會在后臺進行全優(yōu)化工作。一旦代碼優(yōu)化完成，便會立即替換掉舊代碼。

WebAssembly 的設計目標之一是先支持小部分功能并同步進行測試，而不是從一開始就把方方面面都設計好。

因此，它還有更多功能值得期待，不過新功能還沒進行周全的考慮。只有所有瀏覽器廠商都積極參與才能把新功能寫進規(guī)范。

以下是一些新功能。

目前，WebAssembly 沒有任何方式能夠操作 DOM 。所以我們不能像使用 element.innerHTML 一樣，從 WebAssembly 里更新一個 DOM 節(jié)點。

相反，必須通過 JavaScript 才能改變 DOM 節(jié)點。
也就是說，必須把新值返回給 JavaScript 調(diào)用方?；蛘咴?WebAssembly 中調(diào)用 JavaScript 函數(shù)。這是可以實現(xiàn)的，因為 JavaScript 和 WebAssembly 函數(shù)都可以做為 WebAssembly 模塊的導入。

不管使用哪種方式，繞道 JavaScript 肯定比直接操作 DOM 要慢。這就導致了部分 WebAssembly 應用可能會因此而推遲發(fā)布時間。

有一種提高運行速度的辦法是，使不同代碼同時并行運行。
不過這有時候可能會偷雞不成蝕把米，因為線程間通信可能比任務本身耗費的時間還多。

但是如果能夠在不同線程之間共享內(nèi)存，那么這種情況就會好很多。為此，WebAssembly 可以使用 JavaScript 的新接口 SharedArrayBuffer 來實現(xiàn)內(nèi)存共享。一旦瀏覽器開始支持 SharedArrayBuffer，WebAssembly 工作小組就立馬可以開始為之制定相關標準。

SIMD（Single Instruction, Multiple Data）是“單指令多數(shù)據(jù)”的縮寫。它是實現(xiàn)并行化的另一種方式。

SIMD 可以接受一個大型數(shù)據(jù)結構（比如一個包含不同數(shù)值的向量），然后對其中的不同數(shù)據(jù)同時應用相同的指令。這種方式可以大幅提升游戲或者 VR 中的各種復雜計算。

這對普通的網(wǎng)頁應用開發(fā)者可能沒那么重要。但是對于像游戲等多媒體應用開發(fā)者就顯得尤為重要了。

很多語言都支持異常處理，但是 WebAssembly 尚未有相關異常處理的規(guī)范。

如果你使用 Emscripten 編譯代碼，你會發(fā)現(xiàn)它會模擬某些編譯器優(yōu)化級別的異常處理。
不過這會導致編譯變慢，但是你可以通過 DISABLE_EXCEPTION_CATCHING 標志來關閉它。

如果 WebAssembly 本身就能夠處理異常，那么這種異常模擬就沒必要了。

也有一些未來的功能并不會影響性能，但是卻能提升 WebAssembly 的開發(fā)體驗。

一等的源碼開發(fā)工具。目前，在瀏覽器中調(diào)試 WebAssembly 就像直接調(diào)試匯編。雖然還是能夠調(diào)試，但是基本上很少開發(fā)者能夠把它跟源碼關聯(lián)起來。所以，我們正在研究該如何改進工具支持，從而實現(xiàn)可以直接調(diào)試源碼。

垃圾回收。如果能夠事先定義數(shù)據(jù)的類型，那么就能夠把這類代碼變成 WebAssembly 。所以使用 TypeScript 這類語言編寫的代碼，是可以跟 WebAssembly 兼容的。不過，目前唯一的困難是 WebAssembly 還不知道該如何與現(xiàn)有的垃圾回收機制結合，就像 JavaScript 引擎內(nèi)置的垃圾回收一樣。

ES6 模塊集成。瀏覽器目前正在完善使用 script 來加載模塊的功能。等到該功能完成后，把