后台在阿里云，你可能被“数据表”、“模型”、“调度”所包围时间等等抽象概念。作为阿里云的前端，如何将这个抽象的概念形象化地呈现给客户或者其他合作伙伴显得尤为重要。同时，阿里云智能事业部的孵化速度和迭代速度也远超大家的想象。综上所述，“人少更复杂”，经常会出现一两个学生在两周内开始孵化一个项目的情况，这时候业界各种构建系统可以减轻一部分工作量，但是遇到可视化“编排”、“流程图”、“关系图”等场景时，就显得捉襟见肘了。通过对此类已被不同业务支持的场景进行盘点，得出DAG面临以下痛点：产品业务逻辑复杂，形态差异大且样式丰富，交互复杂且具有高视觉品质诉求定制化要求高，开发速度快的解决方案小蝴蝶（https://github.com/alibaba/butterfly）脱胎于阿里云数据智能事业部的实际业务场景。在覆盖我们业务需求的同时，还支持多个兄弟部门Component库的抽象前端图，其特点如下：“部件化开发”，定制化强，入门门槛低：利用DOM的便利性，提供非常强大的样式定制和复杂的交互定制能力//继承定制constNode=require('butterfly-dag').Node;classANodeextendsNode{draw(obj){//“part-style”开发，只返回finaldomtome}//随意自己扩展方法}canvas.draw({nodes:[{id:'xxxx',top:100,left:100,Class:ANode//设置基类后，canvas将根据自定义类进行渲染}]})canvas的通用功能一应俱全：Minmap、网格系统、snaplines、帧选择、重做/撤消、画布缩放和平移、线段动画、自动布局和更多的。为了更加细腻和人性化的交互，我们未来会花更多的精力在更智能的交互上：聚焦一些节点&聚焦canvas框架选择，更加智能。控制框选择交互：触摸选择或完全包含；控制可选元素：锚点、节点、线段来处理拖动边缘的组优化性能问题很多人曾经质疑我们，小蝴蝶使用DOM，性能不会很差吗？我们的小蝴蝶专注于流程图。为了保证我们业务的完整性和清晰度，我们的定位是：10000个节点是性能极限，因为如果超过10000个节点，整个业务流程就会变得混乱。同时，我们做了很多性能优化工作：分层渲染。各层互不影响，保证渲染达到更细的粒度，逐步渲染首屏。确保canvas的第一次呈现可以接近局部渲染的Canvas的渲染速度。确保对每个元素的每个更改都以最小的粒度呈现，而不会触发大型重新呈现批处理操作。对画布中所有元素的所有增删查改都优化为批量操作，保证尽可能少地操作DOM，共同构建。我们经常被问到小蝴蝶和G6是什么关系？我们与AntV-G6几乎同时发布。可谓是亦师亦友。我们竞争并共同建设。大家一起努力，共同推动这一领域的发展。我们经常和@聚则交流。为了减少重复建设，我们已经初步制定了一期的方案，也在努力推进中：二期的合作共建，最近一直在思考，小的butterfly胜在定制相对好用好用，但是在性能上无法支持1w以上的节点。G6的渲染引擎是Canvas，性能优秀但缺乏定制化，入门门槛会比较高。能否结合两者的优点，取其精华，去其糟粕。我们的思路是：_第一层_：当鼠标悬浮在上面需要编辑时，DOM层会出现一个对应的节点，覆盖Canvas对应的节点_第二层_：不需要编辑时，Canvas才是真正的渲染engine_thirdlayer_：背景和选框等操作层是不常变化的层。我们已经在积极调查这一领域。这期间我们发现Html转Canvas特性时会丢失部分CSS，但这部分特性可以通过Canvas补救。希望今年能突破这个难关，真正将DOM和Canvas融合，将性能和定制最大化，帮助更多有需要的同学。未来规划感谢阿里云设计中心、DataV兄弟等Contributors近三年的贡献。今年，我们将更加努力提升小蝴蝶底层能力，丰富小蝴蝶生态，努力打造“零”码图编排。结语我们已经积累支持了20+业务，沉淀了100+节点样式，近期会开放给小伙伴。到时候大家可以像“iconfont”一样把它们组合起来，可以大大减少大家的开发时间。三年磨一剑，希望小蝶能帮到你。小蝴蝶已经开源三年了，你们的star是我们的动力：https://github.com/alibaba/butterfly，谢谢大家！同时也欢迎有兴趣的兄弟一起为项目贡献力量。
