核心是将渲染循环完整迁移至Web Worker，主线程仅负责调度与合成；关键在于零拷贝传输、尺寸管控与任务分离三者协同，严格遵循移交链路、帧提交用transferToImageBitmap、主动降DPR及静态/动态层分离。
核心是把整个渲染循环完整迁移到 Web Worker 中，主线程只保留调度和合成职责，不参与任何像素计算或状态更新。OffscreenCanvas 本身不降低内存抖动，真正起作用的是“零拷贝传输 + 尺寸管控 + 任务分离”这三件事的组合。
必须走通的移交链路
这是避免内存反复分配、触发 GC 抖动的前提：
- 主线程先创建真实
<canvas>元素（哪怕不插入 DOM），调用canvas.transferControlToOffscreen()获取 OffscreenCanvas 实例 - 通过
postMessage({ canvas }, [canvas])发送给 Worker，transfer list 必须包含该实例，否则只是浅拷贝，Worker 收到的是空对象 - 移交后，主线程原 canvas 不可再调用
getContext()，所有绘图逻辑必须由 Worker 完全接管
帧提交必须用 transferToImageBitmap
这是消除内存抖动最关键的一环。不能用 toDataURL()、getImageData() 或 toBlob() ——这些方法会触发整帧像素复制，造成大块内存申请与释放，直接引发 GC 频繁抖动。
- Worker 渲染完一帧后，调用
offscreen.transferToImageBitmap()，生成一个可转移的 ImageBitmap 对象 - 用
postMessage(bitmap, [bitmap])发回主线程，仍走 transfer 语义，位图内存所有权直接移交，无拷贝 - 主线程用
ctx.transferFromImageBitmap(bitmap)合成上屏，毫秒级完成，不触发解码、缩放或像素遍历
尺寸与 DPR 必须主动降级
高 DPR 设备（如 iPhone 15 Pro 的 3x）下，4000×3000 原图会生成超 1 亿像素纹理，不仅易闪退，更会导致内存分配失败后频繁重试、GC 暴增。这不是性能问题，而是稳定性问题。
- 在 Worker 中计算安全尺寸：
const safeWidth = Math.min(4096, Math.floor(canvas.clientWidth * dpr)) - 若超限，主动降级 DPR：
const usedDPR = Math.min(dpr, Math.floor(4096 / canvas.clientWidth)) - 创建 OffscreenCanvas 时严格按安全尺寸申请，不依赖设备原生 DPR 全量放大
静态层预合成 + 动态层分离
高频重绘是内存抖动的温床。不要每帧都重画全部内容，尤其背景、网格、坐标轴等不变元素。
- 静态层：在主线程或 Worker 中一次性绘制为 ImageBitmap，缓存复用；或让 Worker 用 OffscreenCanvas 绘一次，
transferToImageBitmap()回传并长期持有 - 动态层（如粒子、弹幕、点位）单独使用另一块 OffscreenCanvas 渲染，仅更新变化部分
- 物理计算（位置更新、碰撞检测、插值）也移入 Worker，避免主线程因同步状态更新而触发 layout 或 paint
