想象你走进一家餐厅后厨。传统厨师（JavaScript）手里是一把万能厨刀，煎炒烹炸样样能行，可一旦遇到“把三万粒蒜末切成均匀细丁”这种重复劳动，就会明显手忙脚乱。老板于是引进了一台台提前装好刀盘的专业料理机——这就是 WebAssembly（简称 WASM）。它不能替代厨师，却在“量大、重复、计算密集”的活儿上接近专业的效率。图像处理像是挑米，视频处理像是接力传菜，多线程像是多位厨师各有分工。这篇文章就用这个“后厨”视角，带你从零看懂 WASM 在图像与音视频处理中的落地方式：像素怎么在料理机里飞快流转、视频帧如何走完一条流水线、多位厨师怎样并行协作，以及真实的性能收益和工程中的坑。读完你就能为自己的项目画出清晰的技术路线图。

岗位关联

理解 WASM 在媒体处理中的落地方式与性能边界，是前端走向高性能 AI 交互应用的必修课——它决定你的滤镜、抠像、实时检测能跑多快、多流畅。

目录
  1. 可视化演示
  2. 认识WASM：后厨里的专业料理机
  3. 图像像素操作：一粒一粒挑米
  4. 视频帧流水线：传菜接力
  5. 多线程并行：多位厨师分工
  6. 性能收益分析：出餐速度翻倍
  7. 工程注意事项：后厨管理手册
  8. AI 应用场景
  9. Python 演示
  10. 常见误区
  11. 面试题

可视化演示

模拟WASM像素级图像处理、视频帧流水线解码与多线程并行计算，对比JS与WASM的性能差异，调节参数观察吞吐变化。

本节配有交互动效（进入视口后自动加载，约 3KB）。

模式1：WASM vs JS像素处理 WASM直接操作像素内存跳过JS桥接 JS需逐像素跨边界调用开销大 Speedup = T_JS / T_WASM WASM内存视图避免拷贝提升数倍。

认识WASM：后厨里的专业料理机

想象一家餐厅后厨：普通厨师拿着一把万能厨刀（JavaScript），什么菜都能切，可一旦要切一千粒蒜末，就得一刀一刀来，手臂发酸、进度缓慢。老板于是引进一台专业料理机——刀盘在工厂里就铸好了，到店只要通电就能高速运转。这台料理机，就是 WebAssembly（WASM）。

WASM 是一种运行在浏览器里的“预编译字节码”。就像料理机的刀盘出厂即定型，C、C++、Rust 写好的重型算法可以预先编译成 .wasm 文件，浏览器下载后不必像 JS 那样边看菜谱（解析源码）边动手，直接“通电运转”。它也因此常被叫做“浏览器里的原生程序”。

不过它终究不是真机器，而是“后厨里的工具”：WASM 运行在浏览器沙箱中，就像后厨与就餐区之间有一道隔窗和传菜口，料理机不能直接接触顾客的资料库（系统资源），一切文件、网络、GPU 操作都要通过浏览器提供的 Web API 中转。它擅长的是把计算密集的体力活做成流水线。

所以 WASM 不是取代 JS 的万能方案，而是在重复性、计算密集的“粗重活”上的专用料理机。前端 AI 相机、Web 端实时滤镜、视频实时抠像，都是它的主战场——这也正是我们接下来要深入的后厨核心区。

η=TJSTWASM\displaystyle \eta = \frac{T_{\text{JS}}}{T_{\text{WASM}}}
η 是“加速倍数”：同一道像素处理工序，用 JS 干要多久、用 WASM 干要多久，两者一比就是收益。
  1. T_JS纯 JavaScript 完成同一段像素循环的耗时，相当于普通厨师手工切完所有蒜末的时间。
    TJS=JS 执行同一算法的时间T_{\text{JS}} = \text{JS 执行同一算法的时间}
  2. T_WASMWASM 执行同样算法的时间，料理机通电即转，没有解析等待。
    TWASM=WASM 执行同一算法的时间T_{\text{WASM}} = \text{WASM 执行同一算法的时间}
  3. η两个时间的比值，大于 1 说明 WASM 更快；工程上先跑基准测试把它量出来再谈优化。
    η=TJSTWASM,η>1⇒WASM 更快\eta = \dfrac{T_{\text{JS}}}{T_{\text{WASM}}},\quad \eta > 1 \Rightarrow \text{WASM 更快}

图像像素操作：一粒一粒挑米

图像处理像挑米：每一粒米是一个像素，要做灰度化、降噪、磨皮，就得一粒粒看清颜色再处理。JS 的做法是“一粒粒夹出来看”，而 WASM 料理机用预磨的刀盘成批处理，效率天差地别。

浏览器把图片画到 Canvas 上之后，我们可以用 getImageData() 拿到一张“食材托盘”——ImageData 对象。它里面装着每个像素的 RGBA 四个数值（红、绿、蓝、透明度），排列规则得像米袋里的大米：一粒米接一粒米，位置固定、长度已知。

逐像素滤镜的套路很固定：先读取整张托盘，遍历每个像素，对每个像素做一系列运算，再把结果写回托盘。比如灰度化的经典公式，就是把彩色变成黑白。关键点在于：WASM 的线性内存（一段连续字节的长条形“冷藏台”）与 ImageData 的数据结构天然吻合，可以把像素数据直接搬进线性内存原地加工，省去 JS 逐对象操作的开销。

挑米快慢取决于米粒数和每粒的检查动作。WASM 把“看一粒米”的固定开销压到极短，两百多万粒米累积下来，整体差距立刻拉开——这也是为什么社区里"JS 60ms、WASM 6ms"的滤镜基准测试比比皆是。

N=W×H,T处理=N×Copf核\displaystyle N = W \times H,\qquad T_{\text{处理}} = \frac{N \times C_{\text{op}}}{f_{\text{核}}}
处理总耗时 = 像素总量 × 每个像素的运算量 ÷ 处理器吞吐。像素越多、单像素运算越重，WASM 的收益越明显。
  1. N = W × H图像宽高像素数相乘得到总像素数，一张 1920×1080 的图就有约 207 万粒“米”。
    N=W×HN = W \times H
  2. C_op每个像素要完成的运算次数，灰度化约 3 次乘法加 2 次加法，模糊则要多次邻域累加。
    Cop=单像素运算量C_{\text{op}} = \text{单像素运算量}
  3. f核处理器每秒能完成的运算吞吐，WASM 编译后的原生指令吞吐远高于解释型 JS 循环。
    f核=每秒可执行的运算数f_{\text{核}} = \text{每秒可执行的运算数}
  4. T处理总耗时公式，量越大、单像素越重，料理机的刀盘优势就越突出。
    T处理=N×Copf核T_{\text{处理}} = \frac{N \times C_{\text{op}}}{f_{\text{核}}}

视频帧流水线：传菜接力

视频不是一张静止的图，而是每秒 24 到 60 盘菜源源不断端出。后厨不能等客人催才开始做，必须形成流水线：洗菜备料（采集帧）→ 切配炒制（像素处理）→ 装盘端出（渲染上屏）。任何一环慢了，整条线都会堵住。

在浏览器里，视频帧的采集来自摄像头（MediaStream）或视频元素，通过 requestVideoFrameCallback 这样的机制拿到每一帧画面。每一帧就是一张独立的 ImageData 托盘，把托盘送进 WASM 料理机做滤镜、人脸检测、背景分割，再写回 Canvas 上屏——一帧一帧连续走完，就成了流畅的视频。

帧率控制的核心只有一个：流水线总耗时决定每秒能出多少盘。单帧“采集 + 处理 + 渲染”只要超过 16.7 毫秒，就会跌破 60fps 出现卡顿；超过 33 毫秒就只有 30fps。WASM 的价值，就是把这三大环节里最重的“处理”环节大幅压缩，给采集和渲染留出宽松的预算。

一条流水线任何环节慢了，整条线都要等。WASM 把最重的“炒制环节”提速五到十倍，出菜节奏才能稳定在每秒 60 盘。做延迟优化时，别只盯着处理环节，采集和渲染的拷贝开销同样要纳入预算。

FPS=1T采集+T处理+T渲染\displaystyle \text{FPS} = \frac{1}{T_{\text{采集}} + T_{\text{处理}} + T_{\text{渲染}}}
FPS 是帧率，等于一帧总耗时的倒数。总耗时越小，每秒能端出的“菜盘”（帧）越多，画面越流畅。
  1. T采集从摄像头或视频源截取一帧画面的耗时，相当于洗菜备料的时间。
    T采集=帧捕获耗时T_{\text{采集}} = \text{帧捕获耗时}
  2. T处理WASM 完成滤镜、抠像等核心计算的耗时，通常是最大的预算大头。
    T处理=WASM 像素处理耗时T_{\text{处理}} = \text{WASM 像素处理耗时}
  3. T渲染把处理后像素写回 Canvas 上屏的耗时，相当于装盘端出的动作。
    T渲染=绘制上屏耗时T_{\text{渲染}} = \text{绘制上屏耗时}
  4. FPS每秒完成的帧数；三者之和超过 16.7ms 就跌下 60fps，超过 33ms 就只有 30fps。
    FPS=1T采集+T处理+T渲染\text{FPS} = \frac{1}{T_{\text{采集}} + T_{\text{处理}} + T_{\text{渲染}}}

多线程并行：多位厨师分工

一道大菜有几百份订单，只有一个厨师再快也有限。后厨的做法是派多位厨师各守一条工作带，每人负责一片区域的食材——这就是多线程并行。我们的可视化演示里，三条工作带同时扫描像素，就是这个过程的缩影。

浏览器里通过 Web Worker 开启多个线程，WASM 配合 SharedArrayBuffer 让多个 Worker 共享同一块线性内存。这就好比多位厨师共用一条长条形冷藏台：半成品放上去、配料取出来，谁负责哪一行像素提前划分好，大家各切各的区域，互不干扰。

但并行不是免费的：任务分配、结果合并、共享内存上的同步（避免两位厨师同时改同一格数据）都有开销，属于“只有一个炉灶”的串行部分。阿姆达尔定律（Amdahl's Law）精确框定了加速上限——可并行部分占比越大、串行部分越小，加人才越划算。

实际工程中，把一帧图像按行切成若干块交给 4 个 Worker，通常只能拿到 2 到 3 倍收益，而不是理想的 4 倍——因为切块、拷贝、同步、合并都是那个“唯一的炉灶”。认清这一点，才不会在优化路上空欢喜。

S(n)=1(1−p)+pn\displaystyle S(n) = \frac{1}{(1-p) + \dfrac{p}{n}}
S(n) 是 n 个线程带来的理论加速比。线程数趋于无穷时，上限收敛到 1/(1-p)，串行部分决定了天花板。
  1. p可并行部分占整个任务的比重，比如图像 90% 的行块可以分给多个厨师。
    p=可并行部分占比p = \text{可并行部分占比}
  2. 1-p必须串行的部分，如任务分配、结果合并、同步等待，只有一个“炉灶”在干活。
    1−p=串行部分占比1-p = \text{串行部分占比}
  3. n并行线程数，相当于后厨同时开几条工作带（Worker 数量）。
    n=线程数n = \text{线程数}
  4. S(n)理论加速比；当 n 趋于无穷，上限趋近 1/(1-p)，这就是并行优化的天花板。
    S(n)=1(1−p)+pnS(n) = \frac{1}{(1-p) + \dfrac{p}{n}}

性能收益分析：出餐速度翻倍

老板最终只看一个指标：出餐速度。引入料理机之后到底快了没有？必须用同一道菜、同一批食材做对比——这就是基准测试（benchmark）。前端社区做了大量这类实验：纯 JS 的高斯模糊要 60 毫秒，WASM 版只要 6 毫秒；人脸关键点检测 JS 勉强 30fps，WASM 加多线程稳定 60fps。

收益公式本身很朴素：改造前的耗时除以改造后的耗时。高斯模糊的例子就是 60ms ÷ 6ms = 10 倍。类似的高收益案例集中在三类任务：计算密集（每个像素都要大量运算）、访存规律（按顺序读写连续内存）、可向量化（同样的操作套在大量数据上）。

但收益不是白来的，场景选择是分水岭。字符串解析、DOM 操作、网络请求等待这类任务，WASM 几乎没有优势——料理机不会帮你接电话。适合的才是好的：先写一小段基准测试验证收益，再决定是否把某个模块整个搬进 WASM，避免“为了 WASM 而 WASM”。

结论像选菜：适合料理机的是“重复、量大、有规整结构”的硬菜（滤镜、抠像、编解码），不适合硬搬的是琐碎轻量的家常小炒。把基准测试当作后厨的秤，先称一称再决定上哪道菜。

S加速=T基线T优化\displaystyle S_{\text{加速}} = \frac{T_{\text{基线}}}{T_{\text{优化}}}
S 是加速倍数：基线耗时越久、优化后耗时越短，倍数越高。这个比值必须用真实基准测试量出来。
  1. T基线改造前纯 JS 实现的处理耗时，作为“出餐速度”的参照。
    T基线=纯 JS 版本耗时T_{\text{基线}} = \text{纯 JS 版本耗时}
  2. T优化WASM（可加多线程）改造后的耗时。
    T优化=WASM 版本耗时T_{\text{优化}} = \text{WASM 版本耗时}
  3. S加速收益倍数，同为高斯模糊，基线 60ms、优化后 6ms，S = 10。
    S加速=T基线T优化=10S_{\text{加速}} = \frac{T_{\text{基线}}}{T_{\text{优化}}} = 10

工程注意事项：后厨管理手册

料理机再快，后厨管理混乱也会翻车：食材储备不足会断供，高峰没有预案会撞车，停电没有 backup 会停业。WASM 工程的落地，同样要盯住内存、加载、降级、工具链这四本“管理手册”。

第一本是内存。WASM 的线性内存在 JS 堆之外，需要手动申请和释放。一帧 1080p 的 RGBA 图像约 8.3 兆字节，如果做多帧环形缓冲、多线程各留副本，内存会成倍上涨，忘记释放就会泄漏——相当于冷藏台被半成品堆满，后厨失去周转空间。

第二本是加载。.wasm 产物要按需加载，配合流式编译（WebAssembly.instantiateStreaming）边下载边编译，避免首屏被大文件堵死——就像食材分批进货、边卸货边开切，而不是等整车货卸完才开工。第三本是降级：老浏览器不认识 WASM 时，要优雅回退到纯 JS 实现，保证功能不消失。最后是工具链：Emscripten 编译 C/C++、wasm-bindgen 编译 Rust，导出的函数要封装成异步 API 给前端调用。

后厨规则写清楚，料理机才能真正成为招牌。把内存生命周期管好、产物渐进加载、环境降级兜底、工具链配置顺手，WASM 媒体处理才能从“实验室里的演示”变成“线上稳定运行的功能”。

M帧缓冲=W×H×4 字节\displaystyle M_{\text{帧缓冲}} = W \times H \times 4\ \text{字节}
一帧画面占用的内存 = 像素数 × 每像素 4 字节（RGBA 四通道）。多帧、多线程会让这个数字成倍放大。
  1. W × H单帧图像的像素总数，1080p 约 207 万。
    W×H=单帧像素数W \times H = \text{单帧像素数}
  2. 4 字节RGBA 四个颜色通道各占 1 字节，这是浏览器像素格式的默认规格。
    4 字节=每像素 RGBA 占用4\ \text{字节} = \text{每像素 RGBA 占用}
  3. M帧缓冲单帧画面的线性内存占用；多帧缓冲、多线程副本会成倍叠加，必须纳入预算。
    M帧缓冲=W×H×4 字节≈8.3 MB (1080p)M_{\text{帧缓冲}} = W \times H \times 4\ \text{字节} \approx 8.3\ \text{MB (1080p)}

AI 应用场景

在线证件照本地一键美化

阶段：前端媒体预处理（边缘计算）

解决的问题：传统证件照工具把原图上传到服务器，由云端 AI 完成抠图、磨皮后再回传，照片出境有隐私风险，往返传输要等 2~3 秒。WASM 把 AI 模型（如人像分割模型）编译成字节码在浏览器本地推理，照片不出设备，点击即出图——就像把料理机搬到顾客桌边现做现吃。

具体案例：某 H5 证件照小程序，将人像分割模型编译为 WASM 并在 Web Worker 中多线程推理，1080p 照片本地处理耗时从服务端往返的 2.8 秒降到 0.6 秒，且完全不依赖网络。

视频会议虚拟背景实时抠像

阶段：实时视频帧处理流水线

解决的问题：虚拟背景要求每一帧都做实时人像分割，纯 JS 逐像素算力不足，只能跑到 15fps 且 CPU 占用极高。WASM 加速 + 多线程分片后，分割模型在浏览器本地跑满 60fps，满足流畅会议体验——就像后厨三条工作带同时出菜，传菜流水线不再堵塞。

具体案例：某 Web 视频会议客户端在低配笔记本上启用 WASM 抠像后，CPU 占用从 80% 降到 30%，帧率稳定在 30fps，人物边缘抖动明显减轻。

PWA 相册批量滤镜与离线处理

阶段：移动端跨平台图像处理

解决的问题：移动端浏览器跑纯 JS 批量滤镜，处理一张 1200 万像素照片要 8 秒，体验不可用。WASM 多线程并行把耗时压到 1.5 秒，配合 Service Worker 可离线使用，让 PWA 接近原生相册的体验——相当于把整套料理流水线搬进手机这个小后厨。

具体案例：某 PWA 滤镜工具对 12MP 照片叠加“模糊 + 磨皮 + 复古”三连滤镜，WASM 管线总耗时 1.8 秒，而纯 JS 基线为 9.6 秒，加速约 5 倍。

Python 演示

python49 行
import randomimport time import numpy as np  def process_pure_python(pixels, width, height):    # 模拟 JS 逐像素循环：一把万能厨刀，一粒一粒挑米    out = [0] * (width * height * 3)    for y in range(height):        for x in range(width):            idx = (y * width + x) * 3            r, g, b = pixels[idx], pixels[idx + 1], pixels[idx + 2]            gray = int(0.299 * r + 0.587 * g + 0.114 * b + 0.5)            out[idx] = out[idx + 1] = out[idx + 2] = gray    return out  def process_numpy(pixels, width, height):    # 模拟 WASM 向量化处理：料理机成批高速运转    arr = np.array(pixels, dtype=np.float64).reshape(height, width, 3)    gray = 0.299 * arr[:, :, 0] + 0.587 * arr[:, :, 1] + 0.114 * arr[:, :, 2]    out = np.stack([gray, gray, gray], axis=2)    out = np.floor(out + 0.5).astype(np.uint8)    return out.reshape(-1).tolist()  def run():    width, height = 320, 240    total = width * height * 3    pixels = [random.randint(0, 255) for _ in range(total)]     t0 = time.perf_counter()    result_py = process_pure_python(pixels, width, height)    t1 = time.perf_counter()     t2 = time.perf_counter()    result_np = process_numpy(pixels, width, height)    t3 = time.perf_counter()     print("pure python loop: {:.3f} s".format(t1 - t0))    print("vectorized numpy: {:.3f} s".format(t3 - t2))    print("speedup:          {:.1f} x".format((t1 - t0) / (t3 - t2)))    assert result_py == result_np, "results differ"    print("outputs match, ok")  if __name__ == "__main__":    run()
目的：用“纯 Python 双重循环 vs numpy 向量化”模拟“JS 逐像素 vs WASM 成批处理”的耗时差异，演示像素级灰度滤镜的核心算法与基准测试方法。
  1. gray = int(0.299 * r + 0.587 * g + 0.114 * b + 0.5)灰度化公式，每个像素的“挑米动作”；无论 JS 还是 WASM，核心运算都是这一行。
  2. arr = np.array(pixels, dtype=np.float64).reshape(height, width, 3)把一维像素流变成连续内存矩阵，模拟 WASM 的线性内存布局。
  3. gray = 0.299 * arr[:, :, 0] + 0.587 * arr[:, :, 1] + 0.114 * arr[:, :, 2]向量化一次性处理整幅图，模拟 WASM 用预编译指令成批干活。
  4. np.floor(out + 0.5).astype(np.uint8)四舍五入并转回字节范围，保证结果和逐像素版完全一致。
  5. time.perf_counter()高精度计时，对应工程里的基准测试，用来量出加速倍数 S。
  6. assert result_py == result_np双向结果一致性校验：提速可以，但不能改变“菜的味道”。

常见误区

误区我把代码改成 WASM 就一定能快很多，凡是慢的地方上 WASM 就对了，反正料理机肯定比人手快。

正解WASM 的优势集中在计算密集、内存访问规整的循环上；I/O 等待、DOM 操作、频繁的小函数调用反而会因为加载产物和跨语言调用开销变得更慢。料理机擅长切丝搅馅，但不擅长接电话、递盘子。

为何常见：看到别人 WASM 提速十倍的案例，误以为所有代码都有同等收益，忽略了那些案例大多是计算密集型的滤镜、编解码任务。

误区WASM 差不多等于原生程序，可以直接操作显卡、读写磁盘，不需要浏览器同意。

正解WASM 跑在浏览器沙箱里，只能调用浏览器提供的 Web API（Canvas、WebGL、WebGPU 等），不能做系统调用。就像料理机只能在后厨通过传菜口把菜递给外面，不能直接冲出餐厅送货上门。

为何常见：把“接近原生速度”误解为“有原生权限”，忽视了沙箱这一安全边界是浏览器架构的底线。

误区我把图像切成 8 块开 8 个线程，速度就能提升 8 倍，线程数等于加速倍数。

正解阿姆达尔定律决定了上限：任务分配、同步、结果合并这些串行部分会拖后腿，共享内存还会争抢带宽。实测 8 线程通常只有 3 到 5 倍收益。就像后厨加再多厨师，炉灶和冷藏台就那么多。

为何常见：直觉上做线性外推，忽视了串行瓶颈和共享资源竞争这两个并行计算的基本约束。

误区滤镜效果用 Canvas 2D 的合成 API 或 toDataURL 导出就能搞定，何必手动处理像素，太底层了。

正解toDataURL 是完整的编码导出操作，逐帧调用极其昂贵；复杂滤镜（模糊、磨皮、抠像分割）必须逐像素读写 ImageData，这正是 WASM 料理机的用武之地。用微波炉热菜可以，但做不了满汉全席。

为何常见：只接触过简单的 Canvas 合成，没见过真实滤镜背后逐像素运算的成本，低估了“一粒一粒挑米”的工作量。

面试题

Q1. WASM 本质上是哪种形态的代码？

单选题 · easy

  • A.浏览器的字节码格式← 正确答案
  • B.服务器的脚本语言
  • C.数据库的查询语法
  • D.操作系统的内核模块

答案：A。WASM 是一种预编译的字节码，像料理机出厂铸好的刀盘，浏览器拿到就能高速运转；它不是脚本语言，也不是数据库语法或系统内核。它跑在浏览器沙箱里，是“后厨里的工具”而不是“整个餐厅”。

Q2. 要从 Canvas 获取逐像素数据，应使用哪种对象？

单选题 · easy

  • A.像素缓冲区对象← 正确答案
  • B.序列化字符串对象
  • C.事件监听器对象
  • D.DOM 树节点对象

答案：A。getImageData() 返回的 ImageData 就是一张装满 RGBA 四通道值的“食材托盘”，逐像素读写都靠它。序列化字符串、事件监听器、DOM 节点都不承载像素数据，选 B、C、D 说明混淆了数据载体。

Q3. 单线程视频处理下，帧率 FPS 与帧处理时间的关系是？

单选题 · mid

  • A.帧处理总时长的倒数← 正确答案
  • B.像素总量的平方值
  • C.画布宽度的两倍值
  • D.网络延迟的三倍值

答案：A。FPS = 1 / T帧，流水线总耗时越长，每秒能完成的帧越少。其他选项把帧率与分辨率、宽度、网络挂钩，都不符合“出菜节奏由单盘耗时决定”的基本逻辑。

Q4. WASM 线性内存具有下列哪种结构特征？

单选题 · mid

  • A.连续的字节数组空间← 正确答案
  • B.零散的缓存对象池
  • C.链式的自动扩容表
  • D.硬件的直接显存区

答案：A。WASM 内存是一段连续、线性排列的字节，像后厨的长条形冷藏台，地址连续才能高效寻址和向量化；它不是对象池或链表，也不能直接映射显存——访问 GPU 必须经 WebGL/WebGPU 接口。

Q5. Worker 线程间共享 WASM 内存借助哪种机制？

单选题 · mid

  • A.共享字节缓冲区机制← 正确答案
  • B.本地会话存储机制
  • C.关系数据库同步机制
  • D.浏览器缓存刷新机制

答案：A。SharedArrayBuffer 提供多个 Worker 共享的字节缓冲区，对应多位厨师共用的冷藏台，大家可以直接读写同一块数据；localStorage、数据库、浏览器缓存都是持久化或跨会话机制，不是多线程共享内存。

Q6. 下列哪些任务适合用 WASM 处理图像？

多选题 · mid

  • A.批量像素级滤镜运算← 正确答案
  • B.按钮点击事件响应
  • C.视频帧实时人物抠图← 正确答案
  • D.表单文本内容校验

答案：AC。像素滤镜和实时抠图都是计算密集、数据规整的活儿，适合料理机（WASM）成批处理；按钮事件和表单校验是轻量交互或 I/O，JS 手到擒来，上 WASM 反而有加载与调用开销。

Q7. 阿姆达尔定律指出并行加速比理论上限取决于？

单选题 · hard

  • A.可并行执行部分的占比← 正确答案
  • B.中央处理器缓存容量
  • C.浏览器窗口的分辨率
  • D.操作系统内核的版本

答案：A。S(n) = 1 / ((1-p) + p/n)，当 n 趋于无穷时上限是 1/(1-p)，完全由可并行占比 p 决定。缓存、分辨率、系统版本都不决定串行瓶颈，选其他选项说明没有抓住“唯一的炉灶”这个核心。

Q8. 落地 WASM 媒体处理工程时应关注哪些？

多选题 · hard

  • A.线性内存泄漏的回收← 正确答案
  • B.模块产物的按需加载← 正确答案
  • C.非支持环境的降级← 正确答案
  • D.放弃基准测试对比

答案：ABC。WASM 线性内存在 JS 堆外需手动管理，产物应流式编译按需加载，老浏览器要回退 JS 实现；基准测试必须保留，放弃它就等于蒙眼炒菜，无法确认收益。

Q9. 视频帧流水线中三阶段正确顺序是哪种？

单选题 · easy

  • A.采集-处理-渲染← 正确答案
  • B.渲染-采集-处理
  • C.处理-渲染-采集
  • D.采集-渲染-处理

答案：A。先拿到帧（采集），再做滤镜或检测（处理），最后画到屏幕（渲染）。顺序颠倒就像先上菜再洗菜，逻辑不通；处理必须在渲染之前完成，渲染是流水线的出口。

Q10. 下列关于 WASM 多线程处理的说法正确是？

多选题 · hard

  • A.同步开销会限制加速收益← 正确答案
  • B.共享内存需防范数据竞争← 正确答案
  • C.增加线程总能线性提速
  • D.行列分片适合像素并行← 正确答案

答案：ABD。同步、合并等串行部分按阿姆达尔定律拖后腿；共享内存里多个厨师同时改同一格数据会产生竞争，需要原子操作保护；图像按行列分片后各块独立，天然适合并行；线程无限增加不可能线性提速，C 错在忽略串行瓶颈。