Konva 性能优化笔记
本文整理自对 konvajs/konva（及 react-konva）常见优化手段的说明与答疑，便于按条目查阅。
一、优化要点索引（1–10）
| 编号 | 主题 |
|---|---|
| 1 | 绘制与刷新：batchDraw()、draw()、自动 batch |
| 2 | 命中检测：listening: false、旧 API 替代 |
| 3 | 质量与速度：perfectDrawEnabled |
| 4 | 缓存：cache() / clearCache() |
| 5 | Shape 与 Konva.Image、位图化 |
| 6 | 多 Layer、按层重绘 |
| 7 | 命中区域：hitStrokeWidth 等 |
| 8 | 变换、动画与缓存的配合 |
| 9 | 大量节点与视口虚拟化 |
| 10 | 版本与变更（CHANGELOG、FastLayer 等） |
附录
- A：DeepWiki 等对仓库的检索链接（需自行打开查看最新上下文）。
- B：Context7 上 Konva 文档入口：context7.com/websites/ko…（需在 Cursor 中配置 Context7 MCP 或 API 后做程序化检索）。
二、各条说明
1. 绘制与刷新（batchDraw vs draw）
batchDraw()：把「需要重画」的请求合并到下一帧执行，避免同一帧内多次改属性导致重复整层绘制。draw()：立即重绘。- Konva 8+：属性变化等场景下，库会自动触发类似
layer.batchDraw()的行为，很多情况下不必手写batchDraw()。 Stage.batchDraw()：对其子 Layer 逐个调用batchDraw()。
与 debounce / React 的关系
- 不完全是 debounce：debounce 往往是「停手后再等一段时间才执行」；这里是 按动画帧（约 16ms）合并，更像 同一帧内合并多次更新。
- 与 React
setState批处理 直觉相近：都是把短时间内的多次更新合并成一次对外可见的提交，减少重复的全量工作。差别在于 React 合并的是组件树/render，Konva 合并的是画布像素的重绘。
2. 命中检测：listening: false
- 对不需要交互的节点/子树设置
listening: false，可跳过该部分在 hit 画布上的工作，减轻事件拾取成本。 - 旧版
hitGraphEnabled、FastLayer等思路，现多用new Konva.Layer({ listening: false })等方式替代。
3. perfectDrawEnabled
- 在同时存在 fill、stroke、透明度 等叠加时，Konva 可为 边缘更干净（少接缝/锯齿）而采用更重的绘制路径。
- 设置
perfectDrawEnabled: false：关闭这类「更精细但更贵」的画法，换性能；若视觉可接受，可用于性能敏感场景。
4. cache()：离屏位图，不是改节点树
node.cache()：将该节点及其子树先绘制到离屏 canvas，之后重绘时往往相当于drawImage一次，而不是把每个子形状再画一遍。- 属性变化后需
clearCache()再让缓存失效并重算，否则会显示旧内容。 - 可对 Shape / Group / Layer 使用；Stage 本身不能 cache。
- 与图像软件「合并图层」的类比：合并的是这一组在屏幕上的像素结果，不改变你在场景图里的父子结构。
5. Shape vs Konva.Image
- 复杂矢量（多 path、圆角、渐变）每帧都会让 Canvas 执行很多指令。
- 若图形内容相对固定，可事先画成位图（或精灵图），用
Konva.Image显示；每帧常是贴一张图，往往比重复矢量绘制更省。 - 与第 4 条的区别：第 4 条是运行时
cache()自动生成离屏图；第 5 条更强调自备位图或多实例共用同一图像资源。
6. 多 Layer：多块 canvas，按层更新
- 每个
Konva.Layer对应自己的 canvas（可理解为多张层叠的透明纸）。 - 只有某层内容变化时，才重画该层；静态背景层可能长时间不需要重画。
- 即：多 canvas + 按层局部重绘，避免「任何小改动都整屏重画所有内容」。
7. 命中区域：hitStrokeWidth
- Konva 用不可见的 hit 画布做点击/悬停检测。
hitStrokeWidth控制参与命中检测的描边有多粗；过粗会扩大命中区域，也可能增加 hit 相关开销。在仍可接受点击体验的前提下可适当调小。- 注意：这与屏幕上可见的 stroke 宽度可以不是同一概念（仅为拾取服务）。
8. 变换、动画与缓存
- 若动画主要是 平移 / 旋转 / 缩放，而内部几何与样式很少变：有时对复杂子树
cache()后只做变换，会更划算（相当于变换一张位图）。 - 若每帧都在改填充、路径、文字等：缓存会频繁失效重建，反而更慢，此时不宜依赖
cache()。 - 动画路径上仍宜配合
requestAnimationFrame与层的batchDraw()（Konva 的Animation与此一致）。
9. 大量节点与虚拟化
- 节点数极大（如上万）时，全部挂在 Konva 上会又慢又占内存。
- 虚拟化：只创建/保留视口内可见的节点，滚动或缩放时再替换一批。这是应用层策略，不是 Konva 单条 API；目标是让屏幕上同时存在的节点数始终可控（如几百级别），再配合第 2、4、5、6 条手段。
10. 版本与变更
- 关注
CHANGELOG.md中的性能相关说明；例如 7.0.0 曾提到大量移动节点等场景的性能提升。 FastLayer等已废弃，改用listening: false的 Layer 等写法。
三、查阅来源说明
- DeepWiki：曾对
konvajs/konva做仓库问答，主题涵盖 batchDraw、listening、perfectDrawEnabled、cache、分层、命中检测、大量节点与动画等；具体条目以 DeepWiki 页面为准。 - Context7：Konva 文档条目见 context7.com/websites/ko…；在本地用 AI 检索需先安装 Context7 MCP 或配置 API，参见 context7.com/docs/client…。
文档生成目的：个人学习与面试备忘；实施请以当前 Konva 官方文档与项目实测为准。
