这是一个创建于 670 天前的主题，其中的信息可能已经有所发展或是发生改变。
对前端图形化部分比较感兴趣，之前也没经验，打算用纯前端写了一个高性能的流程图软件，顺便利用下之前做过性能优化的经验，深入下。
主要目标是，高性能、操作简洁高效、多类图形都可以画的（主要平时画图需要各类软件切换，很麻烦）。
目前已经实现流程图部分的功能，马上就会上思维导图，后续打算实现表格和图表类功能。
前端用的是 vue 、自研 canvas 架构、后端用的 nestjs 。
后续如果大家对前端图形化或者性能优化感兴趣，有空挺想做一部分分享，顺便也记录下开发的过程。
也欢迎大家给给建议，有哪些不足地方欢迎指正。
体验地址： https://firra.cn
第 1 条附言 2024-03-02 03:38:38 +08:00
补充几个比较关键的问题：
Q:为什么需要注册体验？
A:这是大家问得最多的问题，1 、我主要当成一个完整的产品来实现，包含了前后端； 2 、技术的研究成果体现在使用的广泛性(当前的认知水准，仅个人的想法，不代表大家)，包含了开源，商业化等，目前选择了后者来验证；所以基于以上选择了需要登录体验，如果有介意的可以忽略。
Q:这类产品为什么会有性能问题？
A:这是一个相当有话题性的问题，我试图尽量简单的回答下，图形化软件可以说是目前最消耗性能的前端软件之一，主要体现在 1 、工程化，超大型单页应用，基本所有代码集成在了一个页面上； 2 、交互复杂，包括各类移动参数提示，吸附，快捷键，动画等等，基本每项都有大量的交互逻辑； 3 、渲染复杂，因为这类软件往往都有图层的概念，所以当图形过多时，在添加，删除，更新，成组，改变图层等操作后，会涉及到大量的渲染计算，所以如果采用 html+svg ，不可避免会导致大量的重排重绘，最终卡顿，这也是为什么 draw.io 和 processon ，或者基于 draw.io 开源技术的产品在数据量多时会非常卡顿的原因； 4 、计算复杂，在显示位置，图形包围框(包括 AABB 和 OBB 的计算)，文本操作等等都包括大量的计算，比如移动一根线条吸附到旋转了 45 度的矩形任意边上，这个场景就需要计算出矩形的 OBB ，线条移动点时候需要计算如何吸附到 OBB 的边上，如果再加上移动时和其他图形的对齐，位置信息计算，就会更加复杂，而实际的复杂情况会远远大于上述例子； 5 、缓存多，内存占用大，常见的场景有(1)大画布，多图形，往往渲染图形远远小于实际图形，那多出来的实例就会占用大量内存；(2)操作缓存，比如撤回，前进操作；(3)全量地图，在操作的同时需要渲染实时的画布地图；所以在这么多个方面需要关注的情况下，必然会是一个容易产生的性能问题的软件。
Q:为什么要专注性能？
A:通过上一个问题就可以很清楚的知道，性能是一个不得不专注且复杂的事情，如果没有处理好，直接导致的就是体验问题，所以更准确的是，性能是基础，是我们在开发软件时所需要专注的事情之一。
Q:相比于市面上的其他软件有什么优势，比如 draw.io ，processon ？
A:需要从几个方面说下：1 、产品上，定位为逻辑梳理绘图工具，在一块画布上能够尽可能的把想要的逻辑梳理清楚，不会局限于只画流程图，包括思维导图、图表、表格等等的展现，这块基本就避免了在梳理一个比较庞大的逻辑时，需要用到不同软件来配合，比如我在开发软件的期间，会有逻辑梳理、草图说明、数据表梳理等等，显然不管是 draw.io 还是 processon 都很难满足，当然目前很多白板可以实现前面的例子，比如 miro ，但是白板更多的定位在于表达的展现，所以在做一些比较精细化的梳理时，并没有过多的关注； 2 、技术上，由于产品定位很大程度就决定了技术的差异，draw.io 和 processon 更多的是基于 HTML+SVG 的渲染技术，Firra 主要用的是 canvas 来渲染交互，所以在交互性能、画布大小、能力可扩展性都有很明显的差异。3 、体验效率上，这块是基于产品和技术的差异综合决定出来的，比如能做的事情，操作的便捷程度，体验是否顺滑，我相信这是很多人使用了多款流程图软件后，发现并不能满足自己的需求，最终回归到 PPT 来绘图的原因。
上面几个回答只代表个人的思考结果，有不准确的地方欢迎指正，我们可以继续探讨。
Q:为什么需要注册体验？
A:这是大家问得最多的问题，1 、我主要当成一个完整的产品来实现，包含了前后端； 2 、技术的研究成果体现在使用的广泛性(当前的认知水准，仅个人的想法，不代表大家)，包含了开源，商业化等，目前选择了后者来验证；所以基于以上选择了需要登录体验，如果有介意的可以忽略。
Q:这类产品为什么会有性能问题？
A:这是一个相当有话题性的问题，我试图尽量简单的回答下，图形化软件可以说是目前最消耗性能的前端软件之一，主要体现在 1 、工程化，超大型单页应用，基本所有代码集成在了一个页面上； 2 、交互复杂，包括各类移动参数提示，吸附，快捷键，动画等等，基本每项都有大量的交互逻辑； 3 、渲染复杂，因为这类软件往往都有图层的概念，所以当图形过多时，在添加，删除，更新，成组，改变图层等操作后，会涉及到大量的渲染计算，所以如果采用 html+svg ，不可避免会导致大量的重排重绘，最终卡顿，这也是为什么 draw.io 和 processon ，或者基于 draw.io 开源技术的产品在数据量多时会非常卡顿的原因； 4 、计算复杂，在显示位置，图形包围框(包括 AABB 和 OBB 的计算)，文本操作等等都包括大量的计算，比如移动一根线条吸附到旋转了 45 度的矩形任意边上，这个场景就需要计算出矩形的 OBB ，线条移动点时候需要计算如何吸附到 OBB 的边上，如果再加上移动时和其他图形的对齐，位置信息计算，就会更加复杂，而实际的复杂情况会远远大于上述例子； 5 、缓存多，内存占用大，常见的场景有(1)大画布，多图形，往往渲染图形远远小于实际图形，那多出来的实例就会占用大量内存；(2)操作缓存，比如撤回，前进操作；(3)全量地图，在操作的同时需要渲染实时的画布地图；所以在这么多个方面需要关注的情况下，必然会是一个容易产生的性能问题的软件。
Q:为什么要专注性能？
A:通过上一个问题就可以很清楚的知道，性能是一个不得不专注且复杂的事情，如果没有处理好，直接导致的就是体验问题，所以更准确的是，性能是基础，是我们在开发软件时所需要专注的事情之一。
Q:相比于市面上的其他软件有什么优势，比如 draw.io ，processon ？
A:需要从几个方面说下：1 、产品上，定位为逻辑梳理绘图工具，在一块画布上能够尽可能的把想要的逻辑梳理清楚，不会局限于只画流程图，包括思维导图、图表、表格等等的展现，这块基本就避免了在梳理一个比较庞大的逻辑时，需要用到不同软件来配合，比如我在开发软件的期间，会有逻辑梳理、草图说明、数据表梳理等等，显然不管是 draw.io 还是 processon 都很难满足，当然目前很多白板可以实现前面的例子，比如 miro ，但是白板更多的定位在于表达的展现，所以在做一些比较精细化的梳理时，并没有过多的关注； 2 、技术上，由于产品定位很大程度就决定了技术的差异，draw.io 和 processon 更多的是基于 HTML+SVG 的渲染技术，Firra 主要用的是 canvas 来渲染交互，所以在交互性能、画布大小、能力可扩展性都有很明显的差异。3 、体验效率上，这块是基于产品和技术的差异综合决定出来的，比如能做的事情，操作的便捷程度，体验是否顺滑，我相信这是很多人使用了多款流程图软件后，发现并不能满足自己的需求，最终回归到 PPT 来绘图的原因。
上面几个回答只代表个人的思考结果，有不准确的地方欢迎指正，我们可以继续探讨。
 | 1 lisongeee 2024-02-26 21:20:51 +08:00 好奇这个是一定要登录才能体验吗？ |
 | 3 markyangd 2024-02-28 00:19:31 +08:00 还要填手机号才能体验，直接劝退！ |
 | 4 aliyun2017 2024-02-29 10:54:08 +08:00 一直用 https://draw.io/挺好用的 可以做个 pwa |
 | 5 johnman 2024-02-29 16:29:55 +08:00 要注册确实劝退 尝试登录使用了一下，感觉完成度还挺高的。 最近自己也在做类似的需要前端画图的项目。用的是 Konva |
 | 6 shunia 2024-03-01 11:10:20 +08:00 |
Select Language