是否该用offscreencanvas取决于内容是否长期不变且绘制开销明显高于drawimage；适用静态ui、重复图元等，不适用于每帧变化的内容。

离屏渲染不是加个 OffscreenCanvas 就能自动变快的，关键在“缓存是否真被复用”和“更新是否真被跳过”。盲目创建离屏画布反而增加内存压力，甚至拖慢首帧。

怎么判断该不该用 OffscreenCanvas

核心看两点：内容是否长期不变、绘制开销是否明显高于 drawImage 调用。比如一个带阴影+渐变+文字的按钮模板，每帧都重绘要调用 12+ 次 2D API；而预画到离屏 Canvas 后，每帧只需 1 次 drawImage，这就是典型适用场景。

• 适合：静态 UI 层（HUD、地图边框）、重复图元（上百个相同图标）、缩放/旋转频繁但内容固定的贴图（如齿轮、瓦片底图）
• 不适合：每帧都变的粒子系统、实时摄像头流、文字内容随用户输入高频刷新的编辑器
• 警惕伪静态：比如“背景”实际随时间有微弱渐变或噪点动画——这种仍需每帧重绘离屏 Canvas，收益归零

OffscreenCanvas 创建与尺寸设置的坑

OffscreenCanvas 实例必须显式设置宽高像素值，不能靠 CSS 缩放，也不能留空。否则 getContext('2d') 返回 null 或绘制区域异常。

Article To Html

文章转信息图。将文章/笔记转化为手机可读的 HTML 信息图，自动匹配视觉风格。触发场景：文章转图、笔记转图、信息图、转小红书图、做张图、可视化这篇文章、文生图。

下载

• 高 DPI 设备下必须同步缩放：若主 Canvas 用 window.devicePixelRatio 做了 2x 渲染，离屏 Canvas 的 width/height 也得设为 canvas.clientWidth * devicePixelRatio
• 用 document.createElement('canvas') 创建更兼容，new OffscreenCanvas() 在 Safari 16.6 之前不支持，且无法在主线程直接获取 transferControlToOffscreen() 句柄
• 避免用 canvas.toDataURL() 频繁调试——它会强制光栅化并拷贝像素，反而触发性能抖动

离屏内容更新时机决定优化成败

很多卡顿其实来自“每次重绘都重建离屏 Canvas”，等于把优化逻辑全绕过了。真正有效的做法是：只在内容实际变更时才重绘离屏画布。

• 监听配置变化：比如主题色切换后，才重绘带渐变的按钮离屏图
• 资源加载完成触发：精灵图加载完毕，立刻批量绘制到离屏 Canvas，而非每帧检查 img.complete
• 手动标记脏区：对分层管理的离屏 Canvas（如“UI-背景层”“UI-图标层”），只更新某一层时，不必清空整个离屏画布，用 clearRect 精确擦除对应区域再重绘
• 别在 requestAnimationFrame 回调里做离屏更新——除非你确认这一帧确实需要变

多层离屏 + drawImage 合成的实操要点

把整屏塞进一个离屏 Canvas 是常见错误。合理拆分为 3–5 个逻辑层（如 background、static-ui、dynamic-ui、effects），每层独立生命周期，才能发挥最大收益。

• 静态层（background、grid）：首次绘制后永不更新，用 ImageBitmap 进一步固化，避免后续 drawImage 解码开销
• 低频层（角色头像框、技能图标底图）：仅在玩家换装、技能升级时更新，平时复用
• 动态层（血条数值、鼠标悬停高亮）：不进离屏，直接在主 Canvas 绘制，配合局部 clearRect 控制脏区
• 合成时注意顺序：先 drawImage 静态层，再叠加动态层，最后画特效——顺序错会导致混合异常或遮挡失效

最易被忽略的是缓存粒度和更新边界。画布越大、层越多，越要明确“谁负责哪块像素”；一旦某层更新逻辑失控，整个离屏策略就退化成内存黑洞。

前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！