实现60FPS满帧交互的关键是将渲染任务从主线程彻底剥离，使逻辑、绘制、合成各司其职：主线程仅负责调度与合成（创建canvas、接收ImageBitmap、响应输入、rAF驱动），所有耗时计算和离屏绘制均由Worker完成，并通过OffscreenCanvas和高效帧传输策略保障零拷贝与双缓冲。
要实现 60FPS 满帧交互，关键不是让每一帧都“挤进 16.67ms”，而是把渲染任务从主线程彻底剥离，让逻辑、绘制、合成各司其职。OffscreenCanvas 本身不是加速器，它是多线程渲染的“准入凭证”——只有通过它，Worker 才能合法拿到像素操作权。
主线程只管调度与合成
主线程不再执行任何 fillRect、drawImage 或 WebGL 绘制调用。它的唯一图形职责是：
– 创建 visible canvas 元素，并获取 2D 上下文用于最终合成
– 接收 Worker 发来的 ImageBitmap，用 drawImage 渲染到可见画布
– 响应用户输入、更新状态、向 Worker postMessage 传递控制指令（如暂停、缩放、图层开关）
– 使用 requestAnimationFrame 驱动合成循环，确保与屏幕刷新率严格对齐
避免在主线程做任何耗时计算。比如粒子位置更新、路径生成、JSON 动画帧解码，全部移交 Worker。
Worker 中专注逻辑+离屏绘制
Worker 接收主线程移交的 OffscreenCanvas 实例（必须由 transferControlToOffscreen() 创建并转移），然后：
- 调用 getContext('2d') 或 getContext('webgl', { desynchronized: true }) 获取上下文；注意：2D 的 fillText 不可用，WebGL 的 readPixels 会返回黑帧
- 每帧先执行数据更新（如物理模拟、Lottie 关键帧插值、传感器状态映射），再调用绘图 API 渲染到 OffscreenCanvas
- 不频繁调用 transferToImageBitmap() —— 它是同步阻塞操作，单次耗时可达 2–5ms。建议按需触发：仅当画面实际变化（如动画播放中、鼠标拖拽时）或每 2–3 帧截一次
- 用 setTimeout 或 setInterval 控制帧节奏（WebGL 不支持 requestAnimationFrame），目标周期设为 ~16ms，但允许小幅浮动以避开 GC 或调度抖动
高效帧传输与双缓冲策略
直接传 ImageBitmap 是最常用方式，但有成本。更优路径分两种场景：
- 2D 动画为主（如 Lottie、数据图表）：Worker 持续渲染到同一 OffscreenCanvas，主线程用 drawImage(offscreenCanvas, ...) 直接绘制——这是共享引用，零拷贝，无传输开销
- WebGL 复杂渲染（如数字孪生、粒子系统）：Worker 渲染后调用 transferToImageBitmap() 截帧，主线程收到后立即 drawImage；同时 Worker 立即清空并开始下一帧，形成隐式双缓冲
- 若需更高吞吐，可在 Worker 内部维护两个 OffscreenCanvas 轮换使用，一个绘制、一个等待传输，避免帧间等待
规避常见性能陷阱
很多项目卡在 45fps 却查不出原因，往往掉进这些坑：
- 在 Worker 中 new OffscreenCanvas() → 报错 TypeError，必须由主线程移交
- 2D 上下文中反复创建渐变、字体、路径对象 → 改为缓存复用，避免每帧 new CanvasGradient
- 主线程未关闭抗锯齿（imageSmoothingEnabled = false）或未禁用 alpha（{ alpha: false }）→ 增加合成开销
- 未做图层分离：把静态背景和动态前景混在同一 canvas → 改用多个叠加 canvas，静态层只需初始化一次
- 忽略设备差异：移动端低端 GPU（如 Intel UHD 630）平均仅 23fps，需动态降级（减少粒子数、关闭阴影、简化着色器）
