没了SharedArrayBuffer，多线程Web应用该如何优雅降级？

在现代 Web 开发中，为了追求极致的性能，我们经常会利用 Web Workers 开启多线程计算。而 SharedArrayBuffer（简称 SAB）则是多线程共享内存、实现零拷贝通信的绝对核心。

然而，由于 Spectre 和 Meltdown 漏洞的出现，浏览器对 SharedArrayBuffer 施加了极其严格的限制。目前，它不仅要求页面必须处于**跨源隔离（Cross-Origin Isolated）**状态（即配置 Cross-Origin-Opener-Policy: same-origin 和 Cross-Origin-Embedder-Policy: require-corp 响应头），在一些低版本浏览器、特定的移动端 WebView（如微信内置浏览器、旧版 iOS UIWebView）中，更是直接不提供支持。

如果你的业务场景（如 WebAssembly 音视频解码、大型 3D 渲染引擎、复杂数据计算）重度依赖多线程共享内存，面对这些“残缺”的环境，该如何设计优雅的降级方案？

特征检测：准确判断运行环境

在采取任何降级措施之前，我们首先需要精确判断当前环境是否真正支持 SharedArrayBuffer。不能仅仅依靠 typeof SharedArrayBuffer，因为有些环境虽然存在该全局对象，但由于未开启跨源隔离，在尝试实例化时会直接抛出错误。

function checkSharedArrayBufferSupport() {
  try {
    if (typeof SharedArrayBuffer === 'undefined') {
      return false;
    }
    // 尝试分配 1 字节内存
    const sab = new SharedArrayBuffer(1);
    // 部分环境可能禁用了 Atomics
    if (typeof Atomics === 'undefined') {
      return false;
    }
    return true;
  } catch (e) {
    return false;
  }
}

const isSABSupported = checkSharedArrayBufferSupport();

方案一：数据所有权转移（Transferable Objects）

如果无法共享内存，最直接的替代方案是主线程与 Worker 之间的数据传输。

传统的 postMessage 会对数据进行结构化克隆（Structured Clone），这在数据量巨大（如几兆甚至几十兆的像素数据或网格数据）时，会产生严重的内存开销和主线程卡顿。此时，应当采用 可转移对象（Transferable Objects）。

工作原理

转移所有权意味着将内存块的控制权直接从主线程“剪切”到 Worker，或者反过来。这个过程是瞬间完成的，没有任何拷贝开销。

代码实现

// 主线程
const worker = new Worker('worker.js');
const buffer = new ArrayBuffer(1024 * 1024 * 10); // 10MB 的数据

// 填充一些数据
const view = new Uint8Array(buffer);
view[0] = 42;

// 将 buffer 作为第二个参数传入，表示转移所有权
worker.postMessage({ data: buffer }, [buffer]);

// 此时，主线程中的 buffer 长度变为 0，已经无法再读取或写入
console.log(buffer.byteLength); // 0

// worker.js
self.onmessage = function(e) {
  const buffer = e.data.data;
  const view = new Uint8Array(buffer);
  
  // 在 Worker 中处理数据
  view[0] = view[0] * 2;
  
  // 处理完毕后，再转移回主线程
  self.postMessage({ data: buffer }, [buffer]);
};

优缺点分析

• 优点：速度极快，接近零拷贝；兼容性极好，所有支持 Web Worker 的浏览器均支持 Transferable。
• 缺点：内存是非共享的。同一时间只有一个线程能够拥有这块内存的使用权。对于需要主线程和子线程频繁、双向、异步读写同一块物理内存的场景，代码逻辑会变得非常繁琐。

方案二：构建内存抽象层（Adapter Pattern）

为了让上层业务代码无需频繁判断环境，我们可以封装一个抽象的内存容器类 SharedMemoryAdapter，根据环境自动切换底层实现。

设计思路

• SAB 支持时：内部包装 SharedArrayBuffer，各线程直接通过 TypedArray 读写，利用 Atomics 保证线程安全。
• SAB 不支持时：内部包装普通 ArrayBuffer，每次写入后，手动通过 postMessage（利用 Transferable 或结构化克隆）将差异同步给其他线程。

简化代码示例

class SharedMemoryAdapter {
  constructor(size) {
    if (isSABSupported) {
      this.isShared = true;
      this.buffer = new SharedArrayBuffer(size);
    } else {
      this.isShared = false;
      this.buffer = new ArrayBuffer(size);
    }
    this.view = new Uint8Array(this.buffer);
  }

  // 写入数据
  set(index, value) {
    this.view[index] = value;
  }

  // 读取数据
  get(index) {
    return this.view[index];
  }

  // 手动同步接口（降级通道）
  syncTo(target) {
    if (this.isShared) return; // 共享内存无需手动同步
    
    // 如果不支持 SAB，则需要将当前的 ArrayBuffer 复制或转移给对方
    // 注意：如果是转移，本端将失去控制权，通常需要重建 buffer
    const copy = this.buffer.slice(0);
    target.postMessage({ type: 'MEM_SYNC', buffer: copy });
  }
}

方案三：WebAssembly 双轨编译策略（Dual-Build Strategy）

很多涉及 SharedArrayBuffer 的场景都是通过 Emscripten 编译的 C++/Rust 项目。在多线程 Wasm 中，线程是通过 pthread 映射到 Web Workers 上的，而共享内存正是由 SharedArrayBuffer 支撑。

如果运行环境不支持 SAB，多线程 Wasm 根本无法加载。为此，我们需要采用双轨编译（Dual-Build）。

实施步骤

1. 编译两套 Wasm 产物：

   • 多线程版本：开启 -pthread 编译参数（生成依赖 SAB 的 Wasm 代码）。
   • 单线程版本：关闭多线程参数，所有任务合并到主线程或单线程 Worker 中同步执行。

2. 动态加载器：
   在前端初始化阶段，进行环境检测，根据检测结果动态加载对应的 .js 包装文件和 .wasm 字节码。

async function initEngine() {
  const useMultithread = checkSharedArrayBufferSupport();
  
  if (useMultithread) {
    console.log('加载多线程高性能版本...');
    const { default: initMultiThread } = await import('./dist/engine.multithread.js');
    return initMultiThread();
  } else {
    console.warn('当前环境不支持共享内存，正在降级加载单线程版本...');
    const { default: initSingleThread } = await import('./dist/engine.singlethread.js');
    return initSingleThread();
  }
}

提示：在单线程降级版本中，原本在 C++ 内部通过 pthread 创建的阻塞任务需要被转换成非阻塞的异步回调（可以借助 Emscripten 的 ASYNCIFY 技术），避免主线程卡死。

方案四：用 Service Worker 强行开启“跨源隔离”

有时，你所面对的环境并非硬件或浏览器版本不支持，而仅仅是因为你无法在生产环境中配置服务器的 HTTP 响应头（例如部署在 GitHub Pages、某些 CDN 上，或者第三方嵌入的 iframe 中），导致浏览器拒绝暴露 SharedArrayBuffer。

这种情况下，可以通过 Service Worker 拦截并修改响应头，在客户端“无损”开启跨源隔离。

核心实现（利用 coi-serviceworker 原理）

在页面最顶层注册一个 Service Worker，拦截所有的网络请求，强行加上 COOP 和 COEP 头。

1. 注册 Service Worker (index.html)

<script>
  if ('serviceWorker' in navigator) {
    navigator.serviceWorker.register('/coi-serviceworker.js').then(registration => {
      // 首次激活时需要刷新页面，使拦截生效
      registration.addEventListener('updatefound', () => {
        try {
          if (navigator.serviceWorker.controller) {
            window.location.reload();
          }
        } catch (e) {}
      });
    });
  }
</script>

2. 拦截请求并注入 Header (coi-serviceworker.js)

self.addEventListener("install", () => self.skipWaiting());
self.addEventListener("activate", (event) => event.waitUntil(self.clients.claim()));

self.addEventListener("fetch", (event) => {
  if (event.request.cache === "only-if-cached" && event.request.mode !== "same-origin") {
    return;
  }

  event.respondWith(
    fetch(event.request)
      .then((response) => {
        if (response.status === 0) {
          return response;
        }

        // 创建新的 Headers 对象，强行注入隔离策略
        const newHeaders = new Headers(response.headers);
        newHeaders.set("Cross-Origin-Embedder-Policy", "require-corp");
        newHeaders.set("Cross-Origin-Opener-Policy", "same-origin");

        return new Response(response.body, {
          status: response.status,
          statusText: response.statusText,
          headers: newHeaders,
        });
      })
      .catch((e) => console.error(e))
  );
});

适用场景与限制

• 适用：因服务器配置受限、CDN 无法改头，但在现代浏览器（如 iOS 15+、Chrome）中运行的场景。
• 限制：此方法无法解决老旧浏览器（如 iOS 14 以下，或者不支持 Service Worker 的嵌入式 Webview）中物理缺失 SharedArrayBuffer 的问题。

总结：如何选择最优方案？

在实际工程落地中，检测机制 + 双轨编译 是最稳妥的商业级方案。虽然写单线程降级代码会增加前期的架构设计成本，但它能确保你的应用在任何极其恶劣的运行环境中，依然能够“活着”呈现在用户面前。