我们再尝试一下流式编译。直接使用之前的斐波纳契数字的 fibonacci.wasm 模块。
首先我们需要提供一个简单的 HTTP 服务，用来返回 .wasm 文件。
新建一个 node.js 文件。
const http = require('http');
const url = require('url');
const fs = require('fs');
const path =require('path');
const PORT = 8888; // 服务器监听的端口号；
const mime = {
"html": "text/html;charset=UTF-8",
"wasm": "application/wasm" // 当遇到对 ".wasm" 格式文件的请求时，返回特定的 MIME 头；
};
http.createServer((req, res) => {
let realPath = path.join(__dirname, `.${url.parse(req.url).pathname}`);
// 检查所访问文件是否存在，且是否可读；
fs.access(realPath, fs.constants.R_OK, err => {
if (err) {
res.writeHead(404, { 'Content-Type': 'text/plain' });
res.end();
} else {
fs.readFile(realPath, "binary", (err, file) => {
if (err) {
// 文件读取失败时返回 500；
res.writeHead(500, { 'Content-Type': 'text/plain' });
res.end();
} else {
// 根据请求的文件返回相应的文件内容；
let ext = path.extname(realPath);
ext = ext ? ext.slice(1) : 'unknown';
let contentType = mime[ext] || "text/plain";
res.writeHead(200, { 'Content-Type': contentType });
res.write(file, "binary");
res.end();
}
});
}
});
}).listen(PORT);
console.log("Server is runing at port: " PORT ".");
然后来编写我们的 html 文件，讲到斐波那契数字，我们顺便做一个性能的测试，来比较一下使用 wasm 的方式和原生 js 的求解速度。
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="UTF-8" />
<meta name="viewport" content="width=device-width, initial-scale=1.0" />
<title>斐波纳切数字</title>
</head>
<script>
function fibonacciJS(n) {
if (n < 2) {
return 1;
}
return fibonacciJS(n - 1) fibonacciJS(n - 2);
}
const response = fetch("fibonacci.wasm");
const num = [5, 15, 25, 35, 45];
WebAssembly.instantiateStreaming(response).then(
({ instance }) => {
let { fibonacci } = instance.exports;
for(let n of num) {
console.log(`斐波纳切数字: ${n}，运行 10 次`)
let cTime = 0;
let jsTime = 0;
for(let time = 0; time < 10; time ) {
let start = performance.now();
fibonacci(n)
cTime = (performance.now() - start)
start = performance.now();
fibonacciJS(n)
jsTime = (performance.now() - start)
}
console.log(`wasm 模块平均调用时间：${cTime / 10}ms`)
console.log(`js 模块平均调用时间：${jsTime / 10}ms`)
}
}
)
</script>
<body>
</body>
</html>
然后执行 node node.js 开启 http 服务，接着在浏览器中打开 http://localhost:8888/index.html，控制台中输出如下：
斐波纳切数字: 5，运行 10 次
index.html:34 wasm 模块平均调用时间：0.001499993959441781ms
index.html:35 js 模块平均调用时间：0.005500001134350896ms
index.html:22 斐波纳切数字: 15，运行 10 次
index.html:34 wasm 模块平均调用时间：0.005999993300065398ms
index.html:35 js 模块平均调用时间：0.15650001005269587ms
index.html:22 斐波纳切数字: 25，运行 10 次
index.html:34 wasm 模块平均调用时间：0.6239999900572002ms
index.html:35 js 模块平均调用时间：1.1620000121183693ms
index.html:22 斐波纳切数字: 35，运行 10 次
index.html:34 wasm 模块平均调用时间：70.59700000681914ms
index.html:35 js 模块平均调用时间：126.21099999523722ms
index.html:22 斐波纳切数字: 45，运行 10 次
index.html:34 wasm 模块平均调用时间：8129.7520000021905ms
index.html:35 js 模块平均调用时间：16918.658500007587ms
整理成表格看一下：
可以看到 wasm 很明显的提高了运行速度，运行时间稳定在 js 的一半，当规模达到 45 的时候，wasm 的运行时间比 js 少了整整 8 秒。
这里也可以看出，如果对于计算密集型的应用，wasm 可以大展身手了。
前端应用来看一些目前已经成功落地的 WebAssembly 的应用。
- eBay 的条形码扫描eBay 在原生应用中有专门的 C 库用于条形码的扫描，在 H5 中利用开源 JavaScript 库 BarcodeReader 做了一个带条形码扫描功能的Web版本。问题是它只有在 20％ 的时间表现良好。剩余的 80％ 的时间运行非常缓慢，准确率也不高。最终的解决方案是通过 wasm ，将原有的 c 库引入，以及业界十分有名的、基于 C 语言编写的开源条形码扫描库 ZBar 引入，再加上原本的 js 库，三者协助，最终识别率达到了 100%。产品上线后的最终效果如下图所示。产品在上线使用了一段时间后，eBay 技术团队对应用的条形码扫描情况进行了统计，结果发现有 53% 的成功扫描来自于 ZBar；34% 来自于自研的 C 库。剩下的 13% 则来自于第三方的 JavaScript 库实现。可见，其中通过 Wasm 实现得到的扫描结果占据了总成功次数的 87%。更详细的过程可以参考 WebAssembly在eBay的实践：速度提升50倍。
- AutoCADAutoCAD 是一款由将近 40 年历史的知名桌面端设计软件，被广泛地用于土木建筑、装饰装潢、工业制图等多个领域中。最初基于C 编译为 Java 代码供 Android 设备使用，最后，在 Google Web Toolkit（一个 Google 开发的可以使用 Java 语言开发 Web 应用的工具集）的帮助下，又将这些 Java 代码转译为了 Web 平台可用的 JavaScript 代码。但最后生成的 Web 应用代码库十分庞大，且在浏览器中的运行性能并不可观。这个「粗糙版」的 Web 应用发布于 2014 年。2015 年通过 Asm.js 将原有的 C 代码中的主要功能直接进行编译移植到到 Web 平台，性能有了很大的提告。2018 年 3 月，基于 Wasm 构建的 AutoCAD Web 也成功诞生，https://web.autocad.com/login。
- 谷歌地球Google 地球最初使用 C 语言在 Windows 平台上开发。后来移植到了 Android 和 iOS 平台中。2017 年 4 月 18 日，经过全新设计的 Google 地球 9.0 发布。由于采用了 Native Client 技术，刚发布时仅能在Chrome 中运行。2020 年 2 月 27 日，Google 使用 C 语言通过 WebAssembly 上重写了 Google 地球，从此 Google 地球可以在 Firefox 和 Edge 上运行。
- bilibili 上传视频的封面在 知乎 看到的一个回答。
投稿视频的时候，当你的视频还在上传中，已经可以自由选择AI推荐的封面。这里采用了webassembly AI的前端整合。
webassembly 负责读取本地视频，生成图片；
tensorflow.js 负责加载AI训练过的 model，读取图片并打分。
从完全的服务端架构 => 前端架构 && 服务端兜底。
webassembly支持解析99%以上的视频编码格式，速度提升体验惠及约50%的web投稿用户。
作者：Stois Fu
链接：https://www.zhihu.com/question/265700379/answer/951118579
来源：知乎
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。
由于当前 Wasm 标准下，Wasm 模块不能直接操纵 dom 元素，所以 WebAssembly 主要应用在了一些计算密集型的场景下，视频的解码编码、图像处理、涉及到复杂计算的算法、加密算法等等。
不止于WebWasm 除了应用在浏览器中，也可以应用到 out-of-web 环境中。通过 WASI（WebAssembly System Interface，Wasm 操作系统接口）标准，Wasm 可以直接与操作系统打交道。通过已经在各种环境实现了 WASI 标准的虚拟机，我们就可以将 wasm 用在嵌入式、IOT 物联网以及甚至云，AI 和区块链等特殊的领域和场景中。
有了 WASI 标准，文章最开始介绍的当前应用的架构在未来可能会发生质的改变。
上边架构的最大问题就是各个操作系统不能兼容，同一个app 需要采用不同的语言在不同平台下各实现一次。
比如一款 A 应用，如果想实现跨平台的话，我们需要用 java 完成在安卓上的开发，用 Objective-C 实现 iOS 上的开发，用 C# 实现 PC 端的开发… …也就是下边的样子。
但如果有了 wasm ，我们只需要选择任意一门语言，然后编译成 wasm，就可以分发到各个平台上了。
