D2C 的一些实践与思考

avatar
阿里巴巴 前端委员会智能化小组 @阿里巴巴
原文链接: zhuanlan.zhihu.com

前言

许多同学对设计稿生成代码(Design2Code,简称 D2C)很感兴趣,但又不知道从何下手,本篇文章我将尝试从一个开发者的视角出发,阐述现阶段 D2C 的几个可行路径以及背后相关的思考。

与传统前端开发不同的是,设计稿生成代码,你往往需要拥有一点设计师的知识,来将设计师与开发者的两个工种之间的桥梁连接起来。而关于连接这个命题,现在市面上也有许多 Startup 在做这方面事情,比如 Zeplin 的设计稿切图标注,期望将设计原型和项目协作工作流更好运作的后起之秀 InVision 等等,这些都是目前国内外连接设计与项目(开发或者协作)相关的效率工具(或平台)。

说回 D2C,目前市面上的设计工具对里面的设计图层往往都已经拥有了最基本的片段代码,比如导出一个片段的 CSS 代码,甚至是导出一个静态页面的 HTML 代码。事实上这部分的能力都是从这些设计工具里获取相应的图层数据,经过一个简单的提取来渲染出来,而这也是最早大家认知的 D2C。

社区 PSD2HTML 效果

几个抓手

我们先抛开上面这段生成的代码的合理性,从实现角度看目前我们有哪几种方式来同样生成这样一段代码。

设计工具 VS 图像

设计工具

目前市面上比较成熟的设计工具(Sketch、Photoshop)大都拥有开发者服务,一些设计工具甚至依赖于自己的三方插件市场来补自身的短板。常见的设计工具开发一般是插件开发,开发者能够基于设计工具提供的 API 来做许多官方能力之外的插件。另外一种是直接解析设计文件,通常设计文件里会存储一些结构化的数据,我们也可以对照这部分的数据来做设计文件里的图层数据解析。

Figma 图层数据 Code 面板

不管是通过设计工具里的插件,还是设计文件直接解析,我们都能通过这两种方式来获取到这里面设计图层的结构化数据,有了这部分结构化描述的数据,我们也可以做一个简单的 D2C 来导出一段 HTML 代码。

Sketch 文件数据信息结构

图像也可以?

不同于设计文件能够提取到一些相关的结构化描述数据,图像的存储我们能够获取到的往往只有一个个像素点,直接提取图像里的图层数据会十分困难。但对于部分简单图像,我们还是能够借助计算机视觉的能力来粗略地提取出来图像里面的图层数据,下图是一个基于文本读光 OCR 识别后通过漫水填充分离出图像里各个图层的思路。

OpenCV 中使用 OCR 提取文本后,漫水填充获取到其他图层

当然这个思路仅局限于部分满足此方案能够正确分割开来图层的图像,对于大部分图像,使用深度学习通过训练大量的设计图像样本来识别出图像里面的图层会是一个不错的思路,这两年业界也有相关的研究能够基于特定的样本提取出图像里的文本、图像、Shape三个简单的设计元素图层。

仅仅是样式翻译?

知道了几种能够提取设计素材里图层数据的途径后,我们再回过头来看上面生成的代码,UI 的还原度可能是满足了,但是生成的代码不太合理,许多文本都被转成了 img 图像标签,在布局结构和命名语义化上也缺乏可维护性,不符合二次开发,这也是以往市面上这类产品受众面低的主要原因,因此在 D2C 里,除了要保障生成的基本 UI 数据类型准确外,我们还需要做一些数据结构描述上可维护性的增强。

可维护性

通常的可维护性一般分为两点:布局结构和语义化。

布局指的是图层与图层之间结构上的排列关系,从最早时期的 div+css 布局,再到如今的 flex 布局,我们对生成代码的布局结构要求也越来越高。从设计工具里的所有图层坐标绝对定位的布局,再到我们开发中所使用到的层次结构分明的布局(相对定位、Flex 布局),这里面我们可以做许多智能布局的事情。

智能布局结构转换

语义化通常指的是指某个设计图层的样式名命名,在生成的代码里往往会使用 text-1 或者 image-2 这种来替代。在这点上我们可以尝试借助图层的上下文结构布局信息,或者图层本身的内容数据(比如文本内容含义、图像内容含义)来加强这块的语义化命名,来生成更加人性化的命名代码。

智能语义化命名

响应式

在生成的样式上,设计工具或者图像里往往都是用像素(px)来表达,而我们实际在使用中往往会需要用到一些响应式的样式代码,我们可以对里面的像素值基于设计稿宽度或者实际屏幕视宽,使用 vm 或者 rem 的响应式单位来处理,从而能够适配到不同尺寸的屏幕或者场景。

DSL 与 工程框架

在我们拥有一份结构化描述的数据来描述一个设计稿里的内容后,除了可以转成常规的 HTML 代码外,我们还能通过这份数据转成不同框架 DSL 来做渲染。甚至可以基于这套 DSL 代码的转换,我们还能够生成一个工程目录来直接编译运行这份代码查看效果。

总结

本篇主要介绍 D2C 里一些常规的事项,当然真正要能够做好 D2C 不仅仅只有这几个抓手,我们还需要面对复杂组件、面对交互逻辑代码以及业务逻辑等等,仅仅生成一份静态可维护的代码还远远不够。但如果能够将静态 UI 的代码生成做到极致便于后续二次开发,确实是能够在开发环节中提效许多,这也是我们所希望 D2C 能够达到的一个比较核心的目标之一。

另外一方面,当下的许多设计工具产品都在革自身设计的命,除了最基本的静态设计能力外,动态交互、动画展示等等在新一代的设计产品里都是可结构化描述的,未来 D2C 也可以运用这部分数据来生成这类交互逻辑和动画代码。

Reference