WebAssembly 是一種可以使用非 JavaScript 編程語言編寫代碼并且能在瀏覽器上運(yùn)行的技術(shù)方案贫导。
解釋器與編譯器
編程中的止，通常有兩種翻譯方法將代碼翻譯成機(jī)器語言：解釋器伦泥、編譯器柜候。
-
使用解釋器明场，翻譯的過程基本上是一行一行及時(shí)生效的否过；
解釋器.jpg -
編譯器是另外一種工作方式午笛，它在執(zhí)行前翻譯。
編譯器.jpg - 每種翻譯方法都有利弊
- 解釋器很快的獲取代碼并且執(zhí)行苗桂。不需要在可以執(zhí)行代碼的時(shí)候知道全部的編譯步驟药磺。因此，解釋器感覺與 JavaScript 有著自然的契合煤伟。web開發(fā)者能夠立即得到反饋很重要癌佩。
這也是瀏覽器最開始使用 JavaScript 解釋器的原因之一。
但使用解釋器的弊端是便锨，當(dāng)運(yùn)行相同的代碼時(shí)围辙，如執(zhí)行一個(gè)循環(huán)。那就會(huì)一遍又一遍的做同樣的事情鸿秆！ - 編譯器則有相反的效果酌畜。在程序開始執(zhí)行時(shí)，它可能需要稍微多一點(diǎn)的時(shí)間來了解整個(gè)編譯的步驟卿叽，但當(dāng)運(yùn)行一個(gè)循環(huán)時(shí)會(huì)更快桥胞，因?yàn)樗恍枰貜?fù)地去翻譯每一次循環(huán)里的代碼。
- 作為一個(gè)可以擺脫解釋器低效率的方法考婴，瀏覽器開始引入編譯器贩虾。瀏覽器給
JS引擎添加了一個(gè)新的部分--監(jiān)視器(分析器)，在JS運(yùn)行時(shí)監(jiān)控代碼沥阱，并記錄代碼片段運(yùn)行的次數(shù)缎罢，以及使用的數(shù)據(jù)類型；- 如果相同的代碼塊運(yùn)行了幾次考杉，則被標(biāo)記為
warm策精。如果運(yùn)行次數(shù)比較多，就被標(biāo)記為hot崇棠。 -
warm代碼塊被扔給基礎(chǔ)編譯器咽袜，只能提升一點(diǎn)點(diǎn)的速度。hot代碼塊則被扔給優(yōu)化編譯器枕稀，速度大大提升询刹。
- 如果相同的代碼塊運(yùn)行了幾次考杉，則被標(biāo)記為
性能瓶頸
要了解WebAssembly谜嫉，首先要了解JS引擎的工作原理 ---明確一點(diǎn)，JS沒有強(qiáng)制類型約束凹联！
-
JavaScript文件會(huì)被下載下來 - 然后進(jìn)入
Parser沐兰，Parser會(huì)把代碼轉(zhuǎn)化成AST（抽象語法樹） - 然后根據(jù)抽象語法樹，
Bytecode Compiler字節(jié)碼編譯器會(huì)生成引擎能夠直接閱讀蔽挠、執(zhí)行的字節(jié)碼 - 字節(jié)碼進(jìn)入翻譯器住闯，將字節(jié)碼一行一行的翻譯成效率十分高的
Machine Code
在項(xiàng)目運(yùn)行的過程中，引擎會(huì)對(duì)執(zhí)行次數(shù)較多的
function記性優(yōu)化象泵，其代碼將編譯成Machine Code后打包送到頂部的Just-In-Time(JIT) Compiler(即時(shí)編譯器)寞秃，下次再執(zhí)行這個(gè)function，就會(huì)直接執(zhí)行編譯好的Machine Code偶惠。但是由于JavaScript的動(dòng)態(tài)變量春寿，上一秒可能是Array，下一秒就變成了Object忽孽。那么上一次引擎所做的優(yōu)化绑改，就失去了作用，此時(shí)又要再一次進(jìn)行優(yōu)化兄一。
asm.js
為了解決這個(gè)問題厘线，
WebAssembly的前身，asm.js誕生了出革。asm.js是一個(gè)Javascript的嚴(yán)格子集造壮，合理合法的asm.js代碼一定是合理合法的JavaScript代碼，反之就不成立骂束。同WebAssembly一樣耳璧，asm.js不是用來一行一行寫代碼的，asm.js是一個(gè)編譯目標(biāo)展箱。它的可讀性旨枯、可讀性雖然比WebAssembly好，但對(duì)開發(fā)者來說混驰，仍然是無法接受的攀隔。
asm.js 的靜態(tài)類型約束
function asmJs() {
'use asm';
let myInt = 0 | 0;
let myDouble = +1.1;
}
看似問題解決了，但不管
asm.js對(duì)靜態(tài)類型做得再好栖榨，它始終逃不過Parser --> ByteCode Compiler昆汹，它們是JavaScript代碼在引擎執(zhí)行過程當(dāng)中消耗時(shí)間最多的兩步。而WebAssembly不用經(jīng)過這兩步婴栽。這就是WebAssembly比asm.js更快的原因满粗。
WebAssembly
在2015年，
WebAssembly橫空出世居夹。WebAssembly是經(jīng)過編譯器編譯之后的代碼败潦，體積小、起步快准脂。在語法上完全脫離JavaScript劫扒，同時(shí)具有沙盒化的執(zhí)行環(huán)境。WebAssembly同樣的強(qiáng)制靜態(tài)類型狸膏，是C/C++/Rust的編譯目標(biāo)。
JavaScript vs WebAssembly
- 目前
JIT編譯器在瀏覽器中很常見，JS引擎運(yùn)行一個(gè)程序花費(fèi)的時(shí)間
JS耗時(shí)過程 .jpg
-
Parse源碼轉(zhuǎn)換成解釋器可以運(yùn)行的代碼虎眨； -
Compiling + optimizing花費(fèi)在基礎(chǔ)編譯和優(yōu)化編譯上的時(shí)間叮姑。有一些優(yōu)化編譯的工作不在主線程，這里不包括這些時(shí)間砾脑； -
Re-optimizing當(dāng)預(yù)先編譯優(yōu)化的代碼不能被優(yōu)化的情況下幼驶，JIT將這些代碼重新優(yōu)化，如果不能重新優(yōu)化韧衣，則丟給基礎(chǔ)編譯去做盅藻，這個(gè)過程叫做重新優(yōu)化； -
Execution執(zhí)行代碼的過程畅铭； -
Garbage Collection(GC)清理內(nèi)存的時(shí)間氏淑。
- 運(yùn)行一個(gè)
WebAssembly程序花費(fèi)的時(shí)間
WebAssembly耗時(shí)過程.jpg
-
request -> download圖上面并沒有展示從服務(wù)器上下載所消耗的時(shí)間，WebAssembly設(shè)計(jì)的體積更小硕噩，可以以二進(jìn)制形式表示假残，所以下載執(zhí)行與JavaScript等效的WebAssembly文件需要更少的時(shí)間；
即使使用gzip壓縮的JavaScript文件很小炉擅，但WebAssembly中的等效代碼可能更小辉懒，在網(wǎng)速慢的情況下更能顯示出效果來。 -
Parse -> decodeJS源碼一旦被下載到瀏覽器坑资，將被解析為抽象語法樹（AST）耗帕；通常瀏覽器解析源碼是惰性的，瀏覽器首先會(huì)解析它們真正需要的東西袱贮，沒有及時(shí)被調(diào)用的函數(shù)只會(huì)被創(chuàng)建成存根仿便。
在這個(gè)過程中，AST被轉(zhuǎn)換為該 JS 引擎的中間表示（稱為字節(jié)碼）攒巍。
相反嗽仪，WebAssembly不需要被轉(zhuǎn)換(Parse)，因?yàn)樗呀?jīng)是目標(biāo)代碼（字節(jié)碼）了柒莉，僅僅需要被解碼(decode)并確定沒有任何錯(cuò)誤闻坚。 -
Compiling + optimizing如前所述，JavaScript是在執(zhí)行代碼期間編譯的兢孝。因?yàn)?code>JavaScript是動(dòng)態(tài)類型語言窿凤，相同的代碼在多次執(zhí)行中都有可能都因?yàn)榇a里含有不同的類型數(shù)據(jù)被重新編譯仅偎，這樣會(huì)消耗時(shí)間。
而WebAssembly與機(jī)器代碼更接近雳殊，編譯器不需要在運(yùn)行代碼時(shí)花費(fèi)時(shí)間去觀察代碼中的數(shù)據(jù)類型橘沥，在開始編譯時(shí)做優(yōu)化，更多的優(yōu)化在LLVM最前面就已經(jīng)完成了夯秃，所以編譯和優(yōu)化的工作很少座咆。 -
Re-optimizing有時(shí)JIT拋出一個(gè)優(yōu)化版本的代碼，然后重新優(yōu)化仓洼。JIT 基于運(yùn)行代碼的假設(shè)不正確時(shí)介陶，會(huì)發(fā)生這種情況。例如色建，當(dāng)進(jìn)入循環(huán)的變量與先前的迭代不同時(shí)哺呜，或者在原型鏈中插入新函數(shù)時(shí)，會(huì)發(fā)生重新優(yōu)化箕戳。
在WebAssembly中弦牡，類型是明確的，因此JIT不需要根據(jù)運(yùn)行時(shí)收集的數(shù)據(jù)對(duì)類型進(jìn)行假設(shè)漂羊。也就是說驾锰，WebAssembly不需要重新優(yōu)化的周期。 -
Execution想要編寫執(zhí)行性能好的JavaScript走越，就需要知道JIT是如何做優(yōu)化的椭豫；然而大多數(shù)開發(fā)者并不知道JIT的內(nèi)部原理，即使是那些了解JIT內(nèi)部原理的開發(fā)人員旨指，也很難實(shí)現(xiàn)最佳方案赏酥。有很多時(shí)候，開發(fā)者為了使他們的代碼更易于閱讀會(huì)阻礙編譯器優(yōu)化代碼谆构。
也正因如此裸扶，執(zhí)行WebAssembly代碼通常更快，有些必須對(duì)JavaScript做的優(yōu)化不需要用在WebAssembly上搬素。另外呵晨，WebAssembly是為編譯器設(shè)計(jì)的，它是目標(biāo)程序熬尺，專門給編譯器來閱讀摸屠，并不是當(dāng)做編程語言讓程序員去寫的。
由于程序員不需要直接編程粱哼，WebAssembly提供了一組更適合機(jī)器的指令季二，根據(jù)程序代碼所做的工作，這些指令的運(yùn)行速度可以在10％到800％之間。 -
GC在 JavaScript 中胯舷，JS 引擎使用垃圾回收器來自動(dòng)進(jìn)行垃圾回收處理刻蚯，這對(duì)于控制性能可能并不是一件好事。開發(fā)者不能控制垃圾回收的時(shí)機(jī)桑嘶，所以它可能在非常重要的時(shí)間去工作芦倒，從而影響性能。
WebAssembly根本不支持垃圾回收不翩，內(nèi)存是手動(dòng)管理的（就像 C/C++），雖然可能讓編程更困難麻裳，但確實(shí)提升了性能口蝠。 - 總而言之，這些都是在許多情況下津坑，在執(zhí)行相同任務(wù)時(shí)
WebAssembly將勝過JavaScript的原因妙蔗。
甚至在某些情況下，WebAssembly 不能像預(yù)期的那樣執(zhí)行疆瑰，還有一些更改使其更快眉反。
WebAssembly如何工作
- 不同的機(jī)器架構(gòu)有自己獨(dú)特的匯編語言，也就是說每一種匯編語言都對(duì)應(yīng)特性的機(jī)器架構(gòu)穆役；
- 我們也可以把
WebAssembly當(dāng)做是另外一種目標(biāo)匯編語言寸五，當(dāng)我們的代碼運(yùn)行在用戶機(jī)器的 web 平臺(tái)上時(shí)，我們根本不可能知道用戶機(jī)器的架構(gòu)耿币。
WebAssembly與別的匯編語言不同梳杏，它是一個(gè)概念機(jī)上的機(jī)器語言，而不是在一個(gè)真正存在的物理機(jī)上運(yùn)行的機(jī)器語言淹接，這一點(diǎn)非常重要十性！
正因如此，WebAssembly指令有時(shí)又被稱為虛擬指令塑悼，它比JavaScript代碼更快更直接的轉(zhuǎn)換成機(jī)器代碼劲适，但又不直接與特定硬件的特定機(jī)器代碼對(duì)應(yīng)。 -
WebAssembly被編譯到.wasm文件厢蒜，在瀏覽器下載后霞势，能迅速轉(zhuǎn)換成目標(biāo)機(jī)器的匯編代碼。
使用場景
- 對(duì)性能有很高要求的
App/Module/游戲 - 在Web中調(diào)用
C/C++/Rust/Go的庫
開發(fā)工具
-
AssemblyScript 支持直接將
TypeScript編譯成WebAssembly斑鸦，入門的門檻低支示。 -
Emscripten 可以說是
WebAssembly的靈魂工具，上面說了很多編譯鄙才，這個(gè)就是那個(gè)編譯器颂鸿，將其他的高級(jí)語言，編譯成WebAssembly攒庵。 -
WABT 是個(gè)將
WebAssembly在字節(jié)碼和文本格式相互轉(zhuǎn)換的一個(gè)工具嘴纺，方便開發(fā)者去理解wasm到底是在做什么事败晴。
