JavaScript是如何工做的:与 WebAssembly比较 及其使用场景

这是专门探索 JavaScript 及其所构建的组件的系列文章的第6篇。

想阅读更多优质文章请猛戳GitHub博客,一年百来篇优质文章等着你！

若是你错过了前面的章节，能够在这里找到它们：

1. JavaScript是如何工做的：引擎，运行时和调用堆栈的概述！
2. JavaScript是如何工做的：深刻V8引擎&编写优化代码的5个技巧
3. JavaScript如何工做:内存管理+如何处理4个常见的内存泄漏
4. JavaScript是如何工做的:事件循环和异步编程的崛起+ 5种使用 async/await 更好地编码方式！
5. JavaScript是如何工做: 深刻探索 websocket 和HTTP/2与SSE +如何选择正确的路径！

此次将讲解 WebAssembly 是如何工做的，更重要的是，它是如何在性能方面与JavaScript进行比较的:加载时间、执行速度、垃圾收集、内存使用、API开放平台、调试、多线程和可移植性。

首先，让咱们看看WebAssembly作什么

首先，咱们有必要了解一下asm.js。2012年，Mozilla 的工程师 Alon Zakai 在研究 LLVM 编译器时突发奇想：许多 3D 游戏都是用 C / C++ 语言写的，若是能将 C / C++ 语言编译成 JavaScript 代码，它们不就能在浏览器里运行了吗？众所周知，JavaScript 的基本语法与 C 语言高度类似。因而，他开始研究怎么才能实现这个目标，为此专门作了一个编译器项目 Emscripten。这个编译器能够将 C / C++ 代码编译成 JS 代码，但不是普通的 JS，而是一种叫作 asm.js 的 JavaScript 变体，性能差很少是原生代码的50%。

以后Google开发了Portable Native Client，也是一种能让浏览器运行C/C++代码的技术。 后来多是由于彼此之间有共同的更高追求，Google, Microsoft, Mozilla, Apple等几家大公司一块儿合做开发了一个面向Web的通用二进制和文本格式的项目，那就是WebAssembly。asm.js 与 WebAssembly 功能基本一致，就是转出来的代码不同：asm.js 是文本，WebAssembly 是二进制字节码，所以运行速度更快、体积更小。

WebAssembly(又称 wasm) 是一种新的字节码格式，主流浏览器都已经支持 WebAssembly。 和 JS 须要解释执行不一样的是，WebAssembly 字节码和底层机器码很类似可快速装载运行，所以性能相对于 JS 解释执行大大提高。 也就是说 WebAssembly 并非一门编程语言，而是一份字节码标准，须要用高级编程语言编译出字节码放到 WebAssembly 虚拟机中才能运行， 浏览器厂商须要作的就是根据 WebAssembly 规范实现虚拟机。

WebAssembly 加载时间

WebAssembly 在浏览器中加载速度更快，由于只有已经编译好的 wasm 文件须要经过internet传输。wasm 是一种低级汇编语言，具备很是简洁的二进制格式。

WebAssembly 执行速度

现在 Wasm 运行速度只比原生代码慢 20%，这是一个使人惊喜的结果。它是这样的一种格式，会被编译进沙箱环境中且在大量的约束条件下运行以保证没有任何安全漏洞或者使之强化。和真正的原生代码比较，执行速度的降低微乎其微。更重要的是，将来将会更加快速。

更好的是，它与浏览器无关——全部主要引擎都增长了对 WebAssembly的支持，且执行速度相差无几。

为了理解与JavaScript相比WebAssembly的执行速度有多快，应该首先阅读关于JavaScript引擎如何工做的文章。

让咱们快速浏览下 V8 的运行机制：

在左边，是一些JavaScript源代码，包含JavaScript函数。首先须要解析它，以便将全部字符串转换为标记并生成抽象语法树(AST)。AST 是JavaScript程序逻辑结构在内存中的表示形式。一旦生成了 AST，V8 直接进入到机器码阶段。其后遍历树，生成机器码，就获得了编译好的函数，在这个过程当中是没有提升遍历速度的。

如今，让咱们看看V8管道在下一阶段的工做:

如今有了V8 的新的优化编译器 (TurboFan), 当 JavaScript应用程序在运行时，不少代码都在 V8 中运行。TurboFan 监测是否有代码运行缓慢，是否存在性能瓶颈和热点(内存使用太高的地方)，以便对其进行优化。它把以上监视获得的代码推向后端即优化过的即时编译器，该编译器把消耗大量 CPU 资源的函数转换为性能更优的代码。

它解决了性能的问题，但这种处理方式有个缺点，分析代码和决定优化哪些内容的过程也会消耗CPU，这意味着更高的耗电量，特别是在移动设备上。

可是，wasm 并不须要以上的所有步骤－以下所示是它被插入到执行过程示意图：

在编译阶段，WebAssembly 不须要被转换，由于它已是字节码了。总之，以上的解析不在须要，你拥有优化后的二进制代码能够直接插入到后端（即时编译器）并生成机器码。编译器在前端已经完成了全部的代码优化工做。

因为跳过了编译过程当中的很多步骤，这使得 wasm 的执行更加高效。

WebAssembly 内存模型

例如，编译 成WebAssembly 的c++ 程序的内存是一个连续的内存块，其中没有“漏洞”。wasm 有助于提升安全性的一个特性是执行堆栈与线性内存分离的概念。在 c++ 程序中，若是有一个堆，从堆的底部进行分配，而后从其顶部得到内存来增长内存堆栈的大小。你能够得到一个指针而后在堆栈内存中遍历以操做你不该该接触到的变量。

这是大多数可疑软件能够利用的漏洞。

WebAssembly采用了彻底不一样的内在模式。执行堆栈与 WebAssembly 程序自己是分开的，所以没法在其中修改和更改诸如变量的值。一样，这些函数使用整数偏移量，而不是指针。函数指向一个间接函数表。以后，这些直接的计算出的数字进入模块中的函数。经过这种方式构建的，能够同时加载多个 wasm 模块，偏移全部索引且每一个模块都运行良好。

更多关于 JavaScript 内存模型和管理的文章详见这里。

WebAssembly 垃圾收集

在 JavaScript 中，开发者不须要担忧内存中无用变量的回收。JS 引擎使用一个叫垃圾回收器的东西来自动进行垃圾回收处理。

如今，WebAssembly 根本不支持垃圾回收。内存是手动管理的（就像 C/C++）。虽然这些可能让开发者编程更困难，但它的确提高了性能。

目前，WebAssembly 是专门围绕 C++ 和 RUST 的使用场景设计的。因为 wasm 是很是底层的语言，这意味着只比汇编语言高一级的编程语言会容易被编译成 WebAssembly。C 语言可使用 malloc，C++ 可使用智能指针，Rust 使用彻底不一样的模式（一个彻底不一样的话题）。这些语言没有使用内存垃圾回收器，因此他们不须要全部复杂运行时的东西来追踪内存。WebAssembly 天然就很适合于这些语言。

另外，这些语言并不可以 100% 地应用于复杂的 JavaScript 使用场景好比监听 DOM 变化 。用 C++ 来写整个的 HTML 程序是毫无心义的由于 C++ 并非为此而设计的。大多数状况下，工程师用使用 C++ 或 Rust 来编写 WebGL 或者高度优化的库（好比大量的数学运算）。

然而，未来 WebAssembly 将会支持不带内存垃圾回功能的的语言。

WebAssembly 平台接口访问

依赖于执行 JavaScript 的运行时环境，对特定于平台的api的访问是公开的，能够经过 JavaScript 程序来直接访问这些平台所暴露出的指定接口。例如，若是您在浏览器中运行JavaScript，有一组Web API, Web 应用程序能够调用这些API来控制Web浏览器/设备功能，并访问 DOM、CSSOM、WebGL、IndexedDB、Web Audio API 等等。

然而，WebAssembly 模块不能访问任何平台api。全部的这一切都得由 JavaScript 来进行中转。若是想在 WebAssembly 模块中访问一些特定于平台的api，必须经过JavaScript调用它。

例如，若是想使用 console.log，你必须经过JavaScript调用它，而不是 c++ 代码。而这些 JavaScript 调用会产生必定的性能损失。

状况不会一成不变的。规范将会为在将来为 wasm 提供访问指定平台的接口，这样你就能够不用在你的程序中内置 JavaScript。

从源码转换讲起

JavaScript脚本正变得愈来愈复杂。大部分源码（尤为是各类函数库和框架）都要通过转换，才能投入生产环境。

常见的源码转换，主要是如下三种状况：

1. 压缩，减少体积。好比jQuery 1.9的源码，压缩前是252KB，压缩后是32KB。
2. 多个文件合并，减小HTTP请求数。
3. 其余语言编译成JavaScript。最多见的例子就是CoffeeScript。

这三种状况，都使得实际运行的代码不一样于开发代码，除错（debug）变得困难重重。

一般，JavaScript的解释器会告诉你，第几行第几列代码出错。可是，这对于转换后的代码毫无用处。举例来讲，jQuery 1.9压缩后只有3行，每行3万个字符，全部内部变量都改了名字。你看着报错信息，感到毫无头绪，根本不知道它所对应的原始位置。

这就是Source map想要解决的问题。

Source map

简单说，Source map就是一个信息文件，里面储存着位置信息。也就是说，转换后的代码的每个位置，所对应的转换前的位置。有了它，出错的时候，除错工具将直接显示原始代码，而不是转换后的代码。这无疑给开发者带来了很大方便。

因为没有规范定义Source map，因此目前 WebAssembly 并不支持，但最终会有的(可能快了)。当你在 C++ 代码中设置了断点，你将会看到 C++ 代码而不是 WebAssembly。至少，这是 WebAssembly 源码映射的目标。

多线程

JavaScript 是单线程的。有一些方法能够利用事件循环并利用异步编程，这个以前在 JavaScript是如何工做的:事件循环和异步编程的崛起+ 5种使用 async/await 更好地编码方式 已经讲过了。

JavaScript 也使用 Web Workers 可是只有在极其特殊的状况下－大致上，能够把任何可能阻塞 UI 主线程的密集的 CPU 计算移交给 Web Worker 执行以得到更好的性能。可是，Web Worker 不可以访问 DOM。

目前 WebAssembly 不支持多线程。可是，这有多是接下来 WebAssembly 要实现的。Wasm 将会接近实现原生的线程（好比，C++ 风格的线程）。拥有真正的线程将会在浏览器中创造出不少新的机遇。而且固然，会增长滥用的可能性。

可移植性

如今JavaScript几乎能够在任何地方运行，从浏览器到服务器端，甚至在嵌入式系统中。

WebAssembly的设计宗旨是安全、便携。就像JavaScript。它将运行在每一个支持 wasm 的环境中(例如，每一个浏览器)。

WebAssembly 拥有和早年 Java 使用 Applets 来实现可移植性的一样的目标。

WebAssembly 使用场景

WebAssembly 的最第一版本主要是为了解决大量计算密集型的计算的（好比处理数学问题）。最为主流的应用场景就是游戏——处理大量的像素。你可使用你熟悉的 OpenGL 绑定来编写 C++/Rust 程序，而后编译成 wasm。以后，它就能够在浏览器中运行。

在浏览器中

• 更好的让一些语言和工具能够编译到 Web 平台运行。
• 图片/视频编辑。

• 游戏：

  • 须要快速打开的小游戏
  • AAA 级，资源量很大的游戏。
  • 游戏门户（代理/原创游戏平台）
• P2P 应用（游戏，实时合做编辑）
• 音乐播放器（流媒体，缓存）
• 图像识别
• 视频直播
• VR 和虚拟现实
• CAD 软件
• 科学可视化和仿真
• 互动教育软件和新闻文章。
• 模拟/仿真平台(ARC, DOSBox, QEMU, MAME, …)。
• 语言编译器/虚拟机。
• POSIX用户空间环境，容许移植现有的POSIX应用程序。
• 开发者工具（编辑器，编译器，调试器...）
• 远程桌面。
• VPN。
• 加密工具。
• 本地 Web 服务器。
• 使用 NPAPI 分发的插件，但受限于 Web 安全协议，可使用 Web APIs。
• 企业软件功能性客户端（好比：数据库）

脱离浏览器

• 游戏分发服务（便携、安全）。
• 服务端执行不可信任的代码。
• 服务端应用。
• 移动混合原生应用。
• 多节点对称计算

原文:https://blog.sessionstack.com...

编辑中可能存在的bug无法实时知道，过后为了解决这些bug,花了大量的时间进行log 调试，这边顺便给你们推荐一个好用的BUG监控工具Fundebug。

你的点赞是我持续分享好东西的动力，欢迎点赞！

欢迎加入前端你们庭，里面会常常分享一些技术资源。