WebAssembly学习笔记

可以从FFmpeg入手，因为这个是我们实际工作中要用到的。

https://github.com/ffmpegwasm/ffmpeg.wasm

如何自己构建wasm文件？

How can I build my own ffmpeg.wasm?

In fact, it is ffmpeg.wasm-core most people would like to build.

To build on your own, you can check build.sh inside https://github.com/ffmpegwasm/ffmpeg.wasm-core repository.

Also you can check this series of posts to learn more fundamental concepts:

WASM的应用场景

经调研，WASM的应用场景一般是如下几个方向：

1、游戏领域&ToB大屏业务：

目前应用最广的游戏引擎之一Unity就是通过WASM来实现将游戏打包部署到浏览器端的。

不过因为浏览器目前只支持WebGL2，是基于比较老的OpenGL ES2的，已经是比较落伍的标准了，在渲染上天然存在缺陷，因此即使选择WASM部署到浏览器上，其效果也会差不少，我自测的时候，就发现锯齿会很严重，且有很多重要特性在WebGL下是无法工作的，比如支持高写实渲染的HDRP管线就不能支持。

ToB可视化领域比较知名的Ray Data基于Unity做了一个RayDataWeb版本，就是将Unity构建为WASM的形式，展示在网页上。我注册了一个RayData的试用账号，访问官方的“智慧城市模板”，抓包可以看到下载了一个10M大小的wasm文件：WebPro.wasm.unityweb；另外查看页面的DOM结构，中间主体画布的Canvas结构命名，也能看到Unity的身影：

1
2
3

<div id="unity-container" style="width: 100%; height: 100%;">
   <canvas id="unity-canvas" style="width: 100%; height: 100%; cursor: default;" __spector_context_type="webgl2" width="1920" height="1080"></canvas>
</div>

RayData使用Unity主要是出于一次开发，双端部署(PC端、Web端)的需求，因为是ToB业务，该方案的一些缺点是他们可以容忍的(生成的wasm文件巨大，有几十M)，但是对于我们ToC业务则是不可接受的。

参考：https://blog.unity.com/technology/webassembly-is-here

2、在线音视频处理：

这是当前WASM应用比较广的一个方向，也和近几年音视频的流行相关。一般是通过WASM在浏览器端应用视频剪辑工具FFmpeg进行音视频的录屏、编解码、流处理、帧提取等。

比如Zoom就应用了WASM。

参考：

https://www.infoq.com/news/2020/08/zoom-web-chrome-apis/

https://ffmpegwasm.netlify.app/

3、在线IDE或者设计软件：

比如著名的设计软件Figma，就使用了WASM对设计资源的加载进行了加速：

参考：https://www.figma.com/blog/webassembly-cut-figmas-load-time-by-3x/

另外一个说法，是WASM适合解决内容创作类的场景：

内容消费和内容创作：现在电子设备分工越来越明确，随着移动应用的兴起，内容消费的功能都在往移动设备上迁移。PC 已经是越来越存粹的效率工具了。两个有本质的区别：移动界面是消费级应用，界面要好看，要容易操作，比如方便触屏的大按钮；而桌面软件会越来越朝向生产力方向发展，强调的是专业和效率。

https://www.zhihu.com/question/276815517/answer/2397676926

内容创作类的场景需要接近原生的体验，因此WASM有发挥之地，但是也只能安居一隅之地。

内容创作类的，如果做不好，就成了页游与端游的体验差距。

4、机器学习场景：

比如tensorflow.js就用到了WASM，但是针对60M以上的模型，其性能还是弱于基于GPU的着色器的，而且估计等到WebGPU在浏览器中正式推广后，该差距还会进一步被加大。

参考：https://blog.tensorflow.org/2020/03/introducing-webassembly-backend-for-tensorflow-js.html

因此WASM一般适用于前端CPU计算密集型场景。

针对可视化方面，多为绘图UI类的场景，这种场景下的计算压力一般都是通过从GPU角度去解决(即通过WebGL绘制，如有计算也是通过着色器Shader进行并行绘图计算)，因此目前尚未找到合适的切入场景。