Wasm，全称 WebAssembly，官网描述是一种用于基于堆栈的虚拟机的二进制指令格式。Wasm被设计为一个可移植的目标，用于编译C/C++/Rust等高级语言，支持在Web上部署客户端和服务器应用程序。 Wasm 的开发者参考文档： https://developer.mozilla.org/en-US/docs/WebAssembly 简单的来说就是使用C/C++/Rust等语言编写的代码，经过编译后得到汇编指令，再通过JavaScript相关API将文件加载到Web容器中，一句话解释就是运行在Web容器中的汇编代码。Wasm是一种可移植、体积小、加载快速的二进制格式，可以将各种编程语言的代码编译成Wasm模块，这些模块可以在现代浏览器中直接运行。尤其在涉及到GPU或CPU计算时优势相对比较明显。
1 WebAssembly 的前世今生：从 Mozilla 说起 2 asm.js：WebAssembly 的前身，一种更快的 JS 3 WebAssembly：绕过 JS 直接生成机器码 4 WebAssembly 在 Web 端的应用 5 WebAssembly 在服务端的应用 6 总结
随着Wasm的发展，现在Wasm不仅仅可以用于浏览器，同样可以被应用在server-side程序中，它已经被定义为一个可移植、体积小、加载快的一种通用二进制格式。其指令本身并不直接面向程序开发者，而是被设计为其他编程语言（如Rust、C++、Go）的编译目标，可以在任何具有Wasm运行时的平台上运行。 Wasm在云原生领域的应用生态正在蓬勃发展。Wasm程序可以像容器一样在云原生环境中运行，帮助开发者轻松地构建和部署应用程序。Wasm可以提供更高的性能，更快的启动时间，更低的资源消耗，以及更好的可移植性，是除容器外的另一种对计算和资源的抽象方式。因此Wasm出身就符合云原生的理念，可以很好地在云上运行。目前围绕Wasm相关的云原生相关项目正在涌现。
WebAssembly 可以作为一种部署应用程序的方式，可以在服务器操作系统上运行，且在许多不同的硬件环境中表现出色。与 Kubernetes 相比，WebAssembly 的优点在于简易性和安全性。但是，Kubernetes 始终有其用途，它将始终用于编排微服务和容器。因此，对于某些用例来说，WebAssembly 可以替代 Docker 和容器，但是在高度分布式的云原生环境中，使用 WebAssembly 来编排容器和微服务程度上与 Kubernetes 相同的程度是不可能的。
WebAssembly 的采用情况受到了组件模型的阻碍，这是一个需要解决的关键问题。尽管 WebAssembly 已经被广泛部署以提高应用程序在浏览器或后端运行时的性能，但其全部潜力尚未得到实现。为了实现一次编写、多处部署范例，需要一个通用的标准来将不同语言与其特定的功能集和设计范式集成起来。许多公司和大学的工程师正在开发组件模型、Wasi 提议和语言工具链，这些工程师的目标是将规范放入 W3C 中。
在 Web 3D 渲染场景中，使用建模软件构建好的 3D 模型文件，模型的细节越精细对应的文件体积也会越大，考虑到 Web 下网络传输的影响，往往会对 3D 模型文件应用压缩算法以减少文件体积，此时就需要在 Web 端对经过压缩的模型进行快速高效的解码。WebAssembly 在 CPU 计算密集的场景有着更优的性能，同时结合 Web Worker 一起使用的话，还不会阻塞渲染主线程，非常适合用来实现 3D 模型解码的解码器（以下简称 decoder）。 本文将以 glTF 格式的 3D 模型为例，介绍实际业务场景中是如何应用 WebAssembly 来实现 3D 模型的解码。首先，本文将简要介绍保时捷礼物的业务背景和 glTF 格式相关压缩算法；其次，分别介绍基于 WebAssembly 的 Draco 和 Meshopt 两种压缩算法的解码器实现；最后，在保时捷业务场景中尝试应用 glTF 两种压缩算法，并对 glTF 模型的不同压缩率和模型加载耗时进行了对比。
JavaScript 作为解析型脚本语言，它的运行速度，一直是其被诟病的一个点。WebAssembly 技术的出现，且被各主流浏览器所支持，让我们在 Web 应用中，使用新技术，突破 JavaScript 引擎的速度局限，有了新的可能。JavaScript 是动态类型语言，WebAssembly 是静态语言编译的产物，理论上 WebAssembly 的运行速度，能比 JavaScript 快好几倍。在本文中，我们将讨论如何对 Web 前端应用优化，从而提高框架以及业务代码的整体性能。
随着 5G 时代的到来，多媒体音视频、特效在 5G 时代下会迎来新的云端的挑战，同时也会催生更多的跟云端相关的业务场景。因此我们需要规划云端的建设，把音视频和特效在移动端积累的能力和经验复制扩展到云端，在云端全面打磨提升音视频能力，支持公司更多业务创造更大价值。同时随着 WebAssembly 的逐步成熟，也给了我们将编辑 SDK 放到 Web 运行的机会。 本文首先帮大家回顾一下 WebAssembly 的一些基本情况，然后将介绍 Web 视频编辑所依赖的关键特性的情况，以及再迁移过程中我们遇到的问题和解决思路。
目前 PC Web 侧实现直播推流通常基于 WebRTC 技术，视频编码为 H264/VP8 格式，音频编码为 Opus 格式，而通常的下行直播分发协议如 Flv、Hls 等挟带的视频数据编码格式为 H264，音频数据编码格式为 AAC，这中间存在流媒体服务器需要将 Opus 音频转码为 AAC 音频的工作，增加了流媒体服务器转码成本和转码稳定性问题。如果能够在直播推流时直接推送 AAC 音频数据，就可以省去流媒体服务器音频转码部分的开销。为了解决推流 AAC 的问题，我们选择在 Web 侧自己实现推流能力。 推流主要分三部分工作，音视频采集、编码、上行传输。采集借助浏览器暴露的摄像头、麦克风采集 API，视频编码借助 WebCodec API，传输借助 WebSocket、WebTransport API。只有音频编码的工作由于目前 WebCodec 暂不支持对 AAC 音频格式的编码，需要寻找音频编码的替代方案。 音视频编解码工作是 CPU 密集型任务，业界相关方案实现大多基于 C/C++ 语言编写。这其中，FFmpeg 作为多媒体处理领域强大的软件实现，提供了简洁的 API
