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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

WebAssembly 的設(shè)計(jì)目標(biāo)之一是先支持小部分功能并同步進(jìn)行測(cè)試，而不是從一開始就把方方面面都設(shè)計(jì)好。

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

以下是一些新功能。

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

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

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

有一種提高運(yùn)行速度的辦法是，使不同代碼同時(shí)并行運(yùn)行。
不過這有時(shí)候可能會(huì)偷雞不成蝕把米，因?yàn)榫€程間通信可能比任務(wù)本身耗費(fèi)的時(shí)間還多。

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

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

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

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

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

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

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

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

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

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

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