前端智能化D2C效率提升50%，带你一睹为快

前言

前端近年来一直在尝试如何提高开发人员的效率，从最初的脚手架工具、组件库、持续集成体系、自动化测试、多端适配到现在的全面的低代码平台、前端智能化、在线 IDE，大家都在为未来的新的且高效率的方式做着努力。

前端行业即将要进入到下一个阶段，因为对于如何搭建组件库、脚手架已经有大量的文章/教程，已经快到了人人可以手撕一个组件库的阶段了，并且随着前端开发人员的技术的普遍提高，枯燥机械式地写代码（样式/布局）已经无法满足开发人员日益增长的追逐技术的心了，因此需要智能化布局来解放这些枯燥的工作。

落后就要挨打，我就打算趁着周末打算探索一下前端智能化。（本人也是新手，纯是感兴趣~，因此不用担心看不懂）

发展历程

其实要说从设计稿转化为 html 的项目，最早可以溯源为 PS(Photoshop) 的导出 html 功能，PS(Photoshop) 可谓是一个老牌的设计产品，从1988年首次发布新版本，到现在仍然在更新。

我们来体验一下这个功能。

首先打开 PS，导入一张网上随便下载的图片，将图片拖进 PS。然后按照以下步骤进行操作。

1.按 command/ctrl + R 打开标尺

2.拖出辅助线，拖出分割块

3.选择切片工具（裁剪工具那一个图标按右键）

4.选择顶部的基于参考线切片

5.文件 - 导出 - 储存为 web 所用格式

就能看到导出了以下几个文件。（我这里切的比较粗糙如果是精细地将一张图片进行切片，应该是非常符合web 的所用格式的，毕竟很久以前，设计师就是这么给我们切片的）

然后我们打开 html 查看里面的元素。

发现它主要以 table 的方式来布局，但是这样的形式，在日益繁多的设备上是无法使用的（可能在当时的PC上还能有不错的应用场景。）

前端当时正处于萌芽阶段，前端智能化的概念还没有被提出，没有 Vue、React，没有工程化，也没有低代码，一切都是刚刚起步，前端智能化也没有被提及。

直到2017年，一篇 pix2code: Generating Code from a Graphical User Interface Screenshot 的论文引起了业界的关注，该论文实现了从一张 UI 截图识别生成了 UI 结构，并且将 UI 结构描述转化成了 HTML 代码。

随后，基于 pix2code 开发的 Screenshot2Code 项目速度进入到 Github 排行榜第一，该工具能够将 UI 截图转成 HTML 代码，该项目作者号称 3 年后人工智能会彻底改变前端开发。

2018 年，微软 AI Lab 开源了草图转代码工具 Sketch2Code，一些人认为生成代码效果不理想不适用于生产环境，但也有人认为代码自动生成还处于初级阶段，未来发展值得想象。

工作流：

效果实现：

一直到2019年， D2 前端论坛（Designer & Developer Frontend Technology Forum, 简称D2）发布了 imgcook ，前端智能化这个词正式确立了。

随后58集团、CodeFun等都相继发布了智能化的产品，但是这个行业是年轻的，也是具有挑战的，这些产品的都还在初期，虽然没办法全方面的得到开发者的青睐，但是都已经有一些不错的落地场景了。

项目体验

设计稿：demo.sketch

代码与sketch下载地址： https://github.com/nan980914/ui2code-demo

这次将分别体验58的 Picasso、imgcook、CodeFun 3款工具的「sketch设计稿转代码」。

我们将以平常写代码中比较重视的几个部分来对这三款软件进行分析：

是否可以还原设计稿
布局识别的准确性
代码（css）可维护性（代码量，定宽定高，flex）
List自动识别，分组
列表循环识别

其中第一点是最基本的，因为如果一个D2C（Design To Code）工具，抛开一些布局之外，连基本的设计稿都无法1:1 还原的话，对我们开发的工作量来说太巨大了，这就好比某个同事已经写了一个半成品项目了，这个时候他突然有事请假了，需要我们去帮忙结尾，这个时候我们需要去看别人的代码，再去修改。每每这个时候心里都会念叨，还不如自己重新写一个项目。

对于第二点来说，布局的准确性，明明是一个左右布局，你给我识别成了上下布局，那基本上那一块的代码都都重新进行修改。相比第一点来说，稍微还好一些，至少不是去收拾一个半成品，只是去改别人写好的项目中bug一样，至少还是能用的。

第三点的话，我认为还是很重要的，CSS 代码的可维护性，我们都知道设计图上对于模块的大小都是width 和 height 的标注的，但是我们真正在写代码的时候，都是不会去定宽和定高的，都是由内部元素去将模块给撑开高度，这样的话，对于移动端的短适配性会比较好。

对于第四点和第五点，算是写代码的复用小能手，对于一个 list 我们一般不会去在 html 写死成多个块，而是会用循环舒服，减少重复代码，也是为了能够和后端进行适配。

58 Picasso(https://github.com/wuba/Picasso)

操作流程：

Picasso的Github仓库上下载其sketch插件毕加索，在sketch中选中我们的画板后生成Web代码。

然后就导出了这样一个文件，让我们打开index.html来看看效果。

1.是否还原设计稿：

怎么说呢，可以看到58Picasso这个还原效果其实除了订单的实付价格那里不知道怎么被挤下去了，和底部footer的样式错乱以外看起来还可以，那我们来看看代码到底怎么样。

2.布局识别的准确性：

我们期待的是两个左右结构的块，却被识别成了这个样子…

虽然以上采用了 flex 布局，但是并没有等分布局，并且也被定宽了，我们希望的是：

3. 代码可维护性：

index.css生成1289行。

分析了一下它会生成如此多代码的原因。

1.累赘的类名

它给每一个div元素都设置了一个英文单词，并且与当前的模块的语义化严重不符。

2.定宽定高

由于它给每个div都是定宽定高的，因此也产生了许多不必要的代码。

3.同类型无法合并

由于没有办法归类相同的元素，因此代码也变得更多了。

4. List自动识别，分组

分析这个设计稿我们可以看出来，下面三个订单的块其实是非常相似的结构，我们希望生成的代码能把相似的结构识别出来并分在同一个组内而不是平铺。

连 list 都没有识别好，那就没有第五步了，总结起来这样的代码，仿佛就是同事甩的锅一样，难以维护，有这时间看代码和修复代码，自己已经写好一个完美版本了。

5.总结

所以 Picasso 距离工业化代码还是有一定差距的，不过 Picasso 的代码是开源的，里面的布局方案是通过图层解析出DSL，然后再通过一定的算法生成的代码。