前言

最近在倒腾 D2C 这玩意，刚开始接手的时候，感觉有点无从下手，因为面对的是 Sketch 超复杂的数据结构和极少的文档参考，所以基本是黑盒摸索，各种 Sketch 属性和结构需要不断的 尝试 来找到合适的解析方式。好在社区开源有一款不错的开源工具 Picasso 。在黑暗中给我带来了一丝光亮。

但 Picasso 在实际项目使用过程中依然存在着不足，比如无法实现 组件 识别，无法完成 循环节点识别 无法更加 语义化 节点的 classname。而且其中也有不少的结构布局的 bug。接下来的系列文章我将会介绍站在巨人的肩膀上来实现一个较为完整可用的 D2C 工具。其中也会包含一些 Picasso 的源码解析和我自己的一些优化改进。

架构设计

Picasso介绍的架构设计是这样的：

Picasso 整体是一个 Sketch 插件，所以架构内的所有功能都是基于 sketch 插件来完成的。但这样就只能个人当做工具使用，而我的目的是可以达成团队协同使用以及规划后期类似于 imgcooke 的低代码能力设计。这时，就需要平台化架构：

职责划分

1. Sketch 插件

插件侧可以调用 sketch 提供的一些原生 API，可以更加方便的对 Symbol、图片 等图层进行解析和处理。这块最简单的方案就是分布式插件，每个用户每台电脑上装一个Sketch插件，然后各自运行。这样的好处就是不需要中心化来处理，也不需要单独部署装有 Sketch 的插件解析服务器，但弊端也是显而易见的，每个用户都需要装载特定版本的Sketch，还是有点麻烦的。另一种就是类似转转的中心化了：

具体采用哪个方案可以视公司情况而定。不过插件的核心功能也就是对图层进行预处理，后面会详细介绍。

2. Server

server 层一方面接受 Sketch 插件处理好的 Sketch JSON 并把他进行数据处理和装换，转成一个基本符合转出标准代码的 DSL。这之间要做很多事情，我们的组件识别和循环节点标记就是在这个阶段完成的。

另一方面是需要对处理好的DSL进行代码转换，这里就是可以通过写不同的转换函数实现多端转换的能力。

3. DSL Editor

DSL Editor 是对 Server 生成好的 DSL 进行人工干预的过程，目的是可视化编辑 DSL 达到更符合研发标准的高可维护性代码。最后再将编辑好的DSL输送给 Server，进行多端转换。

本章总结

现在业界有不少在探索 D2C 的公司，但开源的规范也好还是源码也罢，都极其少有。最近也出来了京东的Deco和转转的马良，但千篇一律的都是在介绍一些宏观的规划和设计，缺少些细节的描述和代码表达，所以，当我们再去设计一款 D2C 产品时，这些内容也只能起到一个导航的作用，改变不了开发的门槛和难度。

另外，顺便想说一句，D2C 是否一定需要 智能化？在我理解来看，如果可以通过深度学习来完成视觉稿的只能组件识别当然是好事，但对很多中小企业来说，这个门槛太高了。但回归 智能化 的本质我们来设想一下，有没有一种可能，ATM 里面不再是智能芯片，而是蹲着一个“人”，当人流量不大的时候，这个人完全可以满足业务需求。当然我说的不是人肉还原视觉稿，而是通过特征枚举。

后面我也会介绍如何通过特征枚举来完成组件识别的能力。