Web Worker大消息传输瓶颈：如何规避结构化克隆的序列化开销？

避免结构化克隆的可行方案 #

1. 使用Transferable Objects转移二进制数据

如果你的处理后payload可以转换为二进制格式（比如ArrayBuffer、Uint8Array等），可以通过postMessage的第二个参数转移所有权，完全跳过结构化克隆的开销。这种方式下，数据会直接从Worker线程转移到主线程，Worker不再拥有该数据的访问权。

示例代码：

// Web Worker侧
const processedData = new Uint8Array(/* 你的4MiB处理后数据 */);
self.postMessage(processedData, [processedData.buffer]);

// 主线程侧
worker.onmessage = (e) => {
  const receivedData = e.data; // 直接使用，无克隆开销
  // 将数据存入Map
};

如果原始数据是JSON对象，可以先通过TextEncoder转为Uint8Array再转移，主线程用TextDecoder解析，这种方式的开销通常比结构化克隆小。

2. 使用SharedArrayBuffer共享内存

SharedArrayBuffer允许主线程和Worker共享同一块内存区域，无需转移或克隆数据。但必须通过AtomicsAPI同步对共享内存的访问，避免竞态条件。

示例代码：

// 主线程初始化SharedArrayBuffer
const sharedBuffer = new SharedArrayBuffer(4 * 1024 * 1024); // 4MiB
const sharedArray = new Uint8Array(sharedBuffer);
worker.postMessage(sharedArray);

// Web Worker侧处理数据
self.onmessage = (e) => {
  const sharedArray = e.data;
  // 将处理后的数据写入sharedArray
  // 用Atomics通知主线程数据已准备好
  Atomics.store(sharedArray, 0, 1); // 标记数据就绪
};

// 主线程等待数据就绪并读取
worker.onmessage = (e) => {
  // 等待Worker标记数据就绪
  while (Atomics.load(sharedArray, 0) !== 1) {
    Atomics.wait(sharedArray, 0, 0);
  }
  // 直接从sharedArray读取数据并存入Map
};

注意：使用SharedArrayBuffer需要配置跨源隔离策略（设置Cross-Origin-Opener-Policy和Cross-Origin-Embedder-Policy响应头），否则浏览器会禁用该特性。

3. 转移序列化/反序列化的工作到Worker

既然主线程的反序列化是瓶颈，可将原本在主线程的操作（比如存入Map）转移到Worker中执行。主线程只接收操作完成的通知或少量必要数据，完全避免大对象的跨线程传输。

示例代码：

// Web Worker侧处理完数据后直接存入Map
const dataMap = new Map();
dataMap.set(key, processedPayload);
// 只通知主线程操作完成
self.postMessage({ type: 'dataStored', key });

// 主线程侧
worker.onmessage = (e) => {
  if (e.data.type === 'dataStored') {
    // 执行后续操作，无需处理大对象
  }
};

优化结构化克隆的替代方案 #

如果无法使用上述共享/转移方案，可尝试更高效的序列化格式替代默认的结构化克隆：

• 使用MessagePack等二进制序列化库，比JSON的序列化/反序列化速度更快、体积更小
• 将数据序列化为Blob传输，主线程通过FileReader读取，开销可能低于结构化克隆

内容的提问来源于stack exchange，提问作者Raphallal