基于Canvas实现的简历编辑器

前言

大家好，我是林三心，用最通俗易懂的话讲最难的知识点是我的座右铭，基础是进阶的前提是我的初心~

大概一个月前，我发现掘金老是给我推荐 Canvas 相关的内容，比如很多 小游戏、流程图编辑器、图片编辑器 等等各种各样的项目，不知道是不是因为我某一天点击了相关内容触发了推荐机制，还是因为现在 Canvas 比较火大家都在卷，本着我可以用不上但是不能不会的原则，我也花了将近一个月的时间通过 Canvas 实现了简历编辑器。

关于 Canvas 编辑器的历史文章:

背景

我是有个基于 DOM 实现的简历编辑器项目的，因为暂时找不到可以用 Canvas 实现的比较有意思的场景，所以才选择了继续做简历编辑器，最开始做简历编辑器就是因为很多简历网站都是要开会员的，要不就是简历的自定义程度比较差，达不到我想要的效果，在学校的某一个晚上突发奇想于是自己做了一个出来。

因为是本着学习的态度以及对技术的好奇心来做的，所以除了一些工具类的包例如 ArcoDesign 、 ResizeObserve 、 Jest 等包之外，关于 数据结构 packages/delta 、插件化 packages/plugin 、核心模块 packages/core 等都是手动实现的。实际上这也是本着 自己学习的项目能自己写就自己写，公司/商业化项目能有已有包就用已有包 的原则来的，在这里的目标是学习而不是做产品，自己学习肯定是希望能够更多地接触相对底层一些的能力，自己可以多踩一些坑会对相关能力有更深的理解，如果是公司的项目那肯定是成熟的产品优先，成熟的产品对于边界 case 的处理以及积攒的 issue 也不是轻易能够比拟的。

开源地址: https://github.com/WindrunnerMax/ResumeEditor
在线 DEMO : https://windrunnermax.github.io/ResumeEditor/

笔记

因为我的主要目标是学习基本的 Canvas 知识和能力，所以很多功能模块都是采用简单的方式实现的，主打一个能用就行。而实际上做好图形编程是一件非常困难的事，如果要做一些复杂的能力我会更倾向于用 konva 等工具包来实现，而即使是简单地实现功能，在写代码的时候我也遇到了很多问题，也记录一些思考来解决问题。

数据结构

数据结构的设计，类似于 DeltaSet ，最终呈现的数据结构形式是扁平化的，但是在 Core 中需要设计 State 来管理树形结构，因为要设计 Undo/Redo 的功能，在不全量存储快照的情况下就意味着必须设计原子化的 Op ，因为想实现的功能有组合这个能力，所以最终实现的形式实际上是树形的结构，而我希望的结构是扁平化的，因为树形结构查找起来比较费劲，需要实现的 Op 类型也会变多，我希望能尽量减少 Op 的类型并且能够做到 History ，所以最终定下的数据结构是 DeltaSet 作为存储，通过 State 来管理整个编辑器状态。

History

原子化的 Op 已经设计好了，所以在设计 History 模块时就不需要全量保存快照了，但是如果每个操作都需要并入 History Stack 的话可能并不是很好，通常都是有 N 个 Op 的一并 Undo/Redo ，所以这个模块应该有一个定时器，如果在 N 毫秒秒内没有新的 Op 加入的话就将 Op 并入 History Stack ，但是当时我在思考一个问题，如果这 N 毫秒内用户进行了 Undo 操作应该怎么办，后来想想实际上很简单，此时只需要清除定时器，将暂存的 Op[] 立即放置于 Redo Stack 即可。

绘制

任何元素都是矩形，数据结构也是据此设计抽象出来的，在绘制的时候分为两层 Canvas 重叠的方式，内层的 Canvas 是用来绘制具体图形的，这里预计需要实现增量更新，而外层的 Canvas 是用来绘制中间状态的，例如选中图形、多选、调整图形位置/大小等，在这里是会全量刷新的，并且后边可能会在这里绘制标尺。在实现交互的过程中我遇到了一个比较棘手的问题，因为不存在 DOM ，所有的操作都是需要根据位置信息来计算的，比如选中图形后调整大小的点就需要在选中状态下并且点击的位置恰好是那几个点外加一定的偏移量，然后再根据 MouseMove 事件来调整图形大小，而实际上在这里的交互会非常多，包括多选、拖拽框选、 Hover 效果，都是根据 MouseDown 、 MouseMove 、 MouseUp 三个事件完成的，所以如何管理状态以及绘制 UI 交互就是个比较麻烦的问题，在这里我只能想到根据不同的状态来携带不同的 Payload ，进而绘制交互。

绘制状态

在实现绘制的时候，我一直在考虑应该如何实现这个能力，因为上边也说了这里是没有 DOM 的，所以最开始的时候我通过 MouseDown 、 MouseMove 、 MouseUp 实现了一个非常混乱的状态管理，完全是基于事件的触发然后执行相关副作用从而调用 Mask 的方法进行重新绘制。再后来我觉得这样的代码根本没有办法维护，所以改动了一下，将我所需要的状态全部都存储到一个 Store 中，通过我自定义的事件管理来通知状态的改变，最终通过状态改变的类型来严格控制将要绘制的内容，也算是将相关的逻辑抽象了一层，只不过在这里相当于是我维护了大量的状态，而且这些状态是相互关联的，所以会有很多的 if/else 去处理不同类型的状态改变，而且因为很多方法会比较复杂，传递了多层，导致状态管理虽然比之前好了一些可以明确知道状态是因为哪里导致变化的，但是实际上依旧不容易维护。最终我又思考了一下，决定在绘图这里实现类似于 DOM 的能力，因为我想实现的能力似乎本质上就是 DOM 与事件的关联，而 DOM 结构是一种非常成熟的设计了，这其中有一些很棒的点子，例如 DOM 的事件流，我不需要扁平化地调整每个 Node 的事件，而是只需要保证事件是从 ROOT 节点起始，最终又在 ROOT 上结束即可，并且整个树形结构以及状态是靠用户利用 DOM 的 API 来实现的，我们管理之需要处理 ROOT 就好了，这样就会很方便，下个阶段的状态管理是准备用这种方式来实现的。

渲染与事件

在前边我们提到了我们想通过模拟 DOM 来完成 Canvas 的绘制与交互，那么在这里就很明显涉及到 DOM 的两个重要内容，即 DOM 渲染与事件处理。那么就先聊下渲染方面的内容，使用 Canvas 实际上就很像将所有 DOM 的 position 设置为 absolute ，所有的渲染都是相对于 Canvas 这个 DOM 元素的位置绘制，那么我们就需要考虑重叠的情况，那么想一个例子， A 的 zIndex 是 10 ， A 的子元素 B 的 zIndex 是 100 ， C 与 A 是平级的且 zIndex 为 20 ，那么当这三个元素重叠的时候，在最顶部的元素是 C ，也就是说 zIndex 实际上只看平级元素，再假如 A 的 zIndex 是 10 ， A 的子元素 B 的 zIndex 是 1 ，那么在这两个元素重叠的时候，在最顶部的元素是 B ，也就是说子元素通常都是渲染在父元素之上的。那么我们在这里也需要模拟这个行为，但是因为我们没有浏览器的渲染合成层，我们能够操作的只有一层，所以在这里我们需要根据一定的策略进行渲染，在渲染时我们与 DOM 的渲染策略相同，即先渲染父元素再渲染子元素，类似于深度优先递归遍历的渲染顺序，不同的是我们需要在每个节点遍历之前，将子节点根据 zIndex 排序来保证同层级的节点渲染重叠关系。

在渲染的基础上，我们还需要考虑事件的实现，例如我们的选中状态，八向调整元素大小的点一定是在选区节点的上层的，那么假如现在我们需要实现 onMouseEnter 事件的模拟，那么因为 Resize 这八个点位与选区节点是有一定重叠的，所以如果此时鼠标移动到重叠的点因为 Resize 的实际渲染位置更高，所以只应该触发这个点的事件而不应该触发后边的选区节点事件，而实际上由于没有 DOM 结构的存在我们就只能使用坐标计算，那么在这里我们最简单的方法就是保证整个遍历的顺序，也就是说高节点的遍历一定是要先于低节点的，当我们找到这个节点就结束遍历然后触发事件，事件的捕获与冒泡机制我们也需要模拟，实际上这个顺序跟渲染是反过来的，我们想要的是优点顶部的元素，优先更像树的右子树优先后序遍历，也就是把前序遍历的输出、左子树、右子树三个位置调换一下即可，但是问题来了，在 onMouseMove 这种高频事件触发的时候，我们每次都去计算节点的位置并且采用深度优先遍历，是非常耗费性能的，所以在这里实现一个典型的空间换时间，将当前节点的子节点按顺序全部存储起来，如果有节点的变动，就直接通知该节点的所有每一层父节点重新计算，这里做成按需计算即可，这样当另一颗子树不变的时候还可以节省下次计算的时间，并且存储的是节点的引用，不会有太大的消耗，这样就变递归为迭代了，另外因为找到了当前的节点，在模拟捕获与冒泡的时候就不需要再递归触发了，通过两个栈即可模拟。

焦点

平时我做富文本相关的功能比较多，所以在实现画板的时候总想按照富文本的设计思路来实现，因为之前也说过要实现 History 以及在编辑面板富文本的能力，所以焦点就很重要，如果焦点不在画板上的时候如果按下 Undo/Redo 键画板是不应该响应的，所以现在就需要有一个状态来控制当前焦点是否在 Canvas 上，经过调研发现了两个方案，方案一是使用 document.activeElement ，但是 Canvas 是不会有焦点的，所以需要将 tabIndex="-1" 属性赋予 Canvas 元素，这样就可以通过 activeElement 拿到焦点状态了，方案二是在 Canvas 上方再覆盖一层 div ，通过 pointerEvents: none 来防止事件的鼠标指针事件，但是此时通过 window.getSelection 是可以拿到焦点元素的，此时只需要再判断焦点元素是不是设置的这个元素就可以了。

无限画布

之前因为没有打算实现平移拖拽也就是无限画布的能力，但是后来真的开始通过这个主框架来实现想做的业务功能的时候发现这样是不行的，所以在后期想把这个能力加上，虽然本身这个能力并不复杂，但是因为最开始没有设计这个能力，导致后边做的时候有点难受，比如 Mask 批量刷新频率不对齐、 ctx 的 translate 应该是偏移值取反、之前多处超出画布不绘制的计算有误等等，就感觉在没有设计的情况下突然增加功能确实是有点难受的，不过好处是不需要大规模重构，只是个别点位的修正。

此外多扯点别的，这个项目除了一些辅助性的工具例如 resize-observer 以及组件库例如 arco-design 都是自己写的，相当于实现了 Canvas 的引擎，特别是在现在的 core-delta-plugin-utils 结构设计下，是完全可以抽离处理作为工具包使用的，当然易用性与性能方面肯定比不上那些有名的开源框架。只不过今天我恰好看到了一个评论说的挺好的：如果是个人能力提升，那么最好是首先理解开源库，然后仿照实现开源库的功能，主要的目标是学习；而如果是商业化的使用，那就变成了知名的开源库优先，这样可以很大程度上降低成本。

性能优化

在实现的过程中，绘制的性能优化主要有:

1. 可视区域绘制，完全超出画布的元素不绘制。

2. 按需绘制，只绘制当前操作影响范围内的元素。

3. 分层绘制，高频操作绘制在上层画布，基础元素绘制在下层画布。

4. 节流批量绘制，高频操作节流绘制，上层画布收集依赖批量绘制。

超链接

众所周知 Canvas 绘制出来就是纯粹的图片，而实际使用导出 PDF 的超链接是可以点击的，而我们当前就单纯只是图片无法做到这一点，所以需要解决这个问题，我想到的一个解决方案是在导出的时候，通过 DOM 生成透明的 a 标签，覆盖在原本的超链接位置，这样就可以实现点击跳转效果了。 PDF 本身也是文件格式，所以是可以借助 PDFKit/PDFjs 等 PDF 排版生成工具来导出的，通过这种方式也可以直接在导出的时候直接将其写入固定位置，并且可以不受浏览器打印的分页限制。

TODO

因为前边提到了我现在还是比较简单的实现方式，所以很多功能都不完善，还有很多想做的能力：

最后

这次对于 Canvas 的体验让我感觉还是不错的，后边我也会写一些在实现的时候碰到的问题以及如何解决问题的文章，不过我目前的主业还是还是写富文本编辑器，富文本编辑器也是天坑中的一员，后边也可能会先写编辑器相关的文章。

开源地 址: https://github.com/WindrunnerMax/ResumeEditor

作者： WindrunnerMax.

结语

我是林三心

广州的兄弟可以约饭哦，或者约球~我负责打铁，你负责进球，谢谢~