作为今年阿里经济体前端委员会的四大技术方向之一,前端智能化方向一被提及,就不免有人好奇:前端结合 AI 能做些什么,怎么做,未来会不会对前端产生很大的冲击等等。本篇文章将围绕这些问题,以「设计稿自动生成代码」场景为例,从背景分析、竞品分析、问题拆解、技术方案等几个角度切入,细述相关思考及过程实践。
背景分析
业界机器学习之势如火如荼,「AI 是未来的共识」频频出现在各大媒体上。简单的、重复性的工作有较大的可能性会受到AI的冲击。并且,白领比蓝领的工作更容易被影响;因为蓝领的工作可能还需要机器人和软硬件相关技术都突破才能被实现,而白领工作一般只需要软件技术突破就可以实现。那AI会对前端这个“白领”工作产生什么样的影响?
回看 2010 年,软件几乎“吞噬”了所有行业,带来近几年软件行业的繁荣;而到了 2019 年,软件开发行业本身却又在被 AI 所“吞噬”。你看:DBA 领域出现了 Question-to-SQL,针对某个领域只要问问题就可以生成 SQL 语句;基于机器学习的源码分析工具 TabNine 可以辅助代码生成;设计师行业也出了 P5 Banner 智能设计师“鹿班”,测试领域的智能化结合也精彩纷呈。那前端领域呢?
那就不得不提一个我们再熟悉不过的场景了,它就是设计稿自动生成代码(Design2Code,以下简称 D2C),阿里经济体前端委员会-前端智能化方向当前阶段就是聚焦在如何让 AI 助力前端这个职能角色提效升级,杜绝简单重复性工作,让前端工程师专注更有挑战性的工作内容!
相关产品分析
2017 年,一篇关于图像转代码的 Pix2Code 论文掀起了业内激烈讨论的波澜,讲述如何从设计原型直接生成源代码。随后社区也不断涌现出基于此思想的类似 Screenshot2Code 的作品,2018 年微软 AI Lab 开源了草图转代码 工具 Sketch2Code,同年年底,设计稿智能生成前端代码的新秀 Yotako 也初露锋芒, 机器学习首次以不可小觑的姿态正式进入了前端开发者的视野。
基于上述分析,我们能够得到以下几点启发:
- 深度学习目前在图片方面的目标检测能力适合较大颗粒度的可复用的物料识别(模块识别、基础组件识别、业务组件识别)。
- 完整的直接由图片生成代码的端到端模型复杂度高,生成的代码可用度不高,要达到所生成代码工业级可用,需要更细的分层拆解和多级子网络模型协同,短期可通过设计稿生成代码来做 D2C 体系建设。
- 当模型的识别能力无法达到预期准确度时,可以借助设计稿人工的打底规则协议;一方面人工规则协议可以帮助用户强干预得到想要的结果,另一方面这些人工规则协议其实也是高质量的样本标注,可以当成训练样本优化模型识别准确度。
问题分解
设计稿生成代码的目标是让 AI 助力前端这个职能角色提效升级,杜绝简单重复性工作内容。那我们先来分析下,“常规”前端尤其是面向 C 端业务的同学,一般的工作流程日常工作内容大致如下:
“常规”前端一般的开发工作量,主要集中在视图代码、逻辑代码和数据联调(甚至是数据接口开发,研发 Serveless 产品化时可期)这几大块,接下来,我们逐块拆解分析。
视图代码
视图代码研发,一般是根据视觉稿编写 HTML 和 CSS 代码。如何提效,当面对 UI 视图开发重复性的工作时,自然想到组件化、模块化等封装复用物料的解决方案,基于此解决方案会有各种 UI 库的沉淀,甚至是可视化拼装搭建的更 High Level 的产品化封装,但复用的物料不能解决所有场景问题。个性化业务、个性化视图遍地开花,直面问题本身,直接生成可用的 HTML 和 CSS 代码是否可行?
这是业界一直在不断尝试的命题,通过设计工具的开发插件可以导出图层的基本信息,但这里的主要难点还是对设计稿的要求高、生成代码可维护性差,这是核心问题,我们来继续拆解。
★ 设计稿要求高问题
对设计稿的要求高,会导致设计师的成本加大,相当于前端的工作量转嫁给了设计师,导致推广难度会非常大。一种可行的办法是采用 CV(ComputerVision, 计算机视觉) 结合导出图层信息的方式,以去除设计稿的约束,当然对设计稿的要求最好是直接导出一张图片,那样对设计师没有任何要求,也是我们梦寐以求的方案,我们也一直在尝试从静态图片中分离出各个适合的图层,但目前在生产环境可用度不是非常高(小目标识别精准度问题、复杂背景提取等问题正在解决),因为毕竟设计稿自带的元信息,比一张图片提取处理的元信息要更多更精准
★ 可维护性问题
生成的代码结构一般都会面临可维护性方面的挑战:
- 合理布局嵌套:包括绝对定位转相对定位、冗余节点删除、合理分组、循环判断等方面;
- 元素自适应:元素本身扩展性、元素间对齐关系、元素最大宽高容错性;
- 语义化:Classname 的多级语义化;
- 样式 CSS 表达:背景色、圆角、线条等能用 CV 等方式分析提取样式,尽可能用 CSS 表达样式代替使用图片;
- ……
将这些问题拆解后,分门别类专项解决,解决起来看似没完没了,但好在目前发现的大类问题基本已解决。很多人质疑道,这部分的能力的实现看起来和智能化没有什么关系,顶多算个布局算法相关的专家规则测量系统。没错,现阶段这部分比较适合规则系统,对用户而言布局算法需要接近 100% 的可用度,另外这里涉及的大部分是无数属性值组合问题,当前用规则更可控。如果非要使用模型,那这个可被定义为多分类问题。同时,任何深度学习模型的应用都是需要先有清晰的问题定义过程,把问题规则定义清楚本就是必备过程。
但在规则解决起来麻烦的情况下,可以使用模型来辅助解决。比如 合理分组(如下图) 和 循环项 的判断,实践中我们发现,在各种情况下还是误判不断,算法规则难以枚举,这里需要跨元素间的上下文语义识别,这也是接下来正在用模型解决的重点问题。