网站首页 > 技术文章 正文
文/阿里淘系 F(x) Team - 缺月、画北
背景介绍
Imgcook 是以各种设计稿图像 (Sketch/PSD/静态图片)为原材料烹饪的匠心大厨,通过智能化手段将各种原始设计稿一键生成可维护的 UI 视图代码和逻辑代码。
在这样一个智能生成代码的流程中,设计稿作为原材料,是非常重要的一环。原始设计稿的质量,直接决定了最终生成代码的好坏。恰巧,在很多实际的场景中,往往设计稿是不符合规范的,或者是达不到交付标准的。这其中主要有两点原因:
- 设计师在交付设计稿时,达不到设计标准,例如整体设计没有达到业务目标要求,设计布局不和谐,物料不美观等等,这些因素直接决定了最终生成的代码也是不标准的,达不到要求的
- 设计师在实际设计过程中,往往以达到视觉效果为目标,即使像是 Sketch 或者 PS 等设计软件提供了图层和图层组以及嵌套关系等概念,设计师往往并不会合理使用这些能力。在这样一个模式下,设计稿会包含一些无用图层,不合理图层。同时会出现使用多个零碎图层去组成一个图案的情况。上述这些问题会对生成代码的模型造成干扰,从而影响最终生成代码的质量
智能规范检查使用智能化的技术对设计稿进行前置检查,检查结果代表着设计稿的质量,也代表着是否可以使用此设计稿作为原材料最终生成高质量的,可维护的前端代码。本文将介绍我们对智能规范检查的探索,思路和技术方案以及实际应用,同时,我们还会由此引出我们对未来整个行业智能设计生产的一些思考,从而完善整个代码生成体系中偏向设计侧的这一环。
问题分析
为了解决不规范的设计稿导致生成了质量低下的代码的问题,我们首先会思考一个问题,今天的代码生成模型,究竟需要一个怎样的设计稿?今天的布局算法,在接受一个怎样的图层信息之后,可以给出较为理想的布局分析呢?我们认为:
- 我们不需要设计中有最终没有对视觉产生影响的图层,这一点比较好理解,就像我们不会在前端代码里写一个对功能,UI 都没有任何影响的 DOM 一样, 如下图所示,我们选中的是一个透明图层,盖到了有用图层之上。
- 我们需要图层的位置信息尽量准确。这一条主要是为了布局分析可以尽可能的理解设计者的意图。举个例子,假如我们有一个文本图层,这个图层距离它的父元素的左右边界距离都是相等的,那我们就几乎可以认为这个文本图层是相对于父元素居中的,然而,如果左右距离偏差了几个像素,那可能我们就不会给这个图层设置上居中属性,即使视觉上它看起来依然在中间。如下图所示,立即兑换距离按钮的左右距离相等,机器就会推测文字居中显示的意图
- 属于同一个组别下面的元素应该在同一个图层组里面,如果是多个图层共同组成一个元素 (比如图标, 艺术字等),那这些图层也应该保证在一个图层组里面。试想,如果今天设计师使用了 10 个图层共同组成一个图标,前端一般会怎么做?前端工程师往往会把这些图层作为一个整体导出一张图片,然后在代码里面引入这个图片。然而,如果这些图层是分散的出现在设计稿图层结构里面,机器往往会把他们当成单独的图层对待,从而导致生成的代码可维护性变差
- 往往在一个团队或者一个公司当中,设计师是需要遵循一些特定的设计规范的,例如字体,字号,字重和颜色的范围限定,布局方式的限定,素材的大小限定等等。如果不在设计阶段就保证这些设计已经符合规范,那么等代码生成完毕之后再回过头对设计稿进行更改,将会极大降低整个智能生成链路的效率。
通过以上描述的这些问题,我们可以进一步把它们归类为两类问题: 1. 保证智能生成代码质量所需要对设计稿进行的约束 2. 保证设计符合设计交付标准和设计规范所需要对设计稿进行的约束。 如果保证好了这两点,整个设计搞转代码的能力将会极大得到保证。接下来,我们将去探讨我们可以通过什么技术,来解决好这些问题
解决方案
本章我们会分析我们可以通过怎样的技术方案来解决问题。同时,我们会介绍我们的思考过程,例如我们是怎样从初始的,简单地,基于规则的方案去升级到更具有普适性的,基于智能化技术的解决方案。
上面提到,在一个团队,甚至在一个团队所负责的每一次活动中,每一次活动下面的不同类型的模块中,都会有不同的设计规范。那么下面我们面临的问题就是,我们怎么结构化地给系统输入这些从设计团队自顶向下制定的这些设计规范,怎么把这种设计规范信息和相对应的设计稿映射起来,怎么在完成这种匹配之后能真正做出正确的检查,在这几个问题的探索中,我们主要经历了三个阶段
强规则人工匹配检查
在第一个阶段,我们首先想到的是让设计师针对每一种类型的模块录入设计规范,这种设计规范是用 sketch 稿表达的。如下图所示,右边的示例就是一个设计规范表达,这个表达详细的阐明了模块里面每一个元素它的位置,上下间距,字体字号等规范,同时,通过协议,我们还可以指定每一个属性的取值范围。为了将右边的规范和左边的模块匹配出来,我们还需要给右边的每一个元素的命名和左边每一个元素的协议命名相同,这样,我们才可以将相应的图层进行比较
这种工作模式的问题是显而易见的,那就是整体运作的人工成本非常高,而且非常不灵活。设计师需要逐一的开发设计规范,更令人头疼的是,每一个开发模块的设计师还需要给图层添加协议,去匹配相应的设计规范,可以说,整个系统是非常笨拙的, 由此,我们希望可以由机器去自动的替代一部分这样的工作
半智能化检查
为了解决上面的问题,我们想到,人工指定规范协议的部分能不能让机器自动化的代替。在假设已经有了模块设计规范的情况下,我们能不能在设计师完成模块设计之后,自动找到这个模块所对应的设计规范。实际上,去判断模块和设计规范是否匹配,只需要看这两个是否是统一模块的不同变种,进一步说,就是这两个模块的骨架是否相似。由于设计稿是有结构化信息的,我们可以直接提取模块骨架,简而言之就是把所有有差异的图片和文本磨平,然后通过 cv 像素比较,判断两个个体的相似度,从而自动找到当前模块应该对应的规范,从而进行检查
人机交互方式检查
如果我们像上述描述的那样把每一个模块的规范看做是一个独立的信息,看成不同活动,不同页面和不同模块之间是独立的,那么就会陷入无止境的繁琐的人工制定规范中区,完全利用不到这个领域沉淀下来的规律和经验。但是实际上,设计是一个成熟的,有着理论支撑的领域,是一个遵循着一致性,适用性,美而简单的领域。同时,前面提到的,对于通用的可以使代码生成更加高质量的规范来说,也是可以沉淀出一套统一的对设计的要求。
然而,这里面规则非常复杂,也有一些目前抽象的部分,人工总结出所有的规律并不现实。同时,人工总结的规则往往在新增一些新的输入的时候出现问题,导致需要部分推翻之前的结论。由此,我们想要设计一套系统,可以自动基于过往所有的标准可交付并且符合代码生成规范的设计稿自动学习出设计经验,并将这种经验用于下一次设计的检查。
当然,在这种模式下学习到的经验是宽泛的,普适性的,我们需要把这种学习到的经验和当前特定的场景和活动规则结合起来。在这种情况下,我们需要模型可以接受特定场景的输入,并将这种输入考虑进去来进行当前的规范检查,这种输入可以结合人工对当前场景的定义,人在这种场景下的角色从手工指定规则设计规范变成了告诉机器需要做什么,从而大幅度降低人工的成本。
落地成果
目前这种规范检查的能力已经集成到内测版本的 imgcook 插件内部,并且在双十一期间广泛推广到大促营销的设计团队中使用,最高日检查次数和使用人数超过50,检测错误数超过百余次。同时,我们也在完善整体设计规范检测和关于主观和美观方面的量化标准,也希望可以使用人机交互的方式不断完善规范检测的能力
未来展望
从设计规范出发,我们希望未来我们可以将这种人机交互的体系扩展到整个设计阶段,通过智能生产设计,一方面大幅度降低设计成本,把设计师从重复性繁琐的设计中解放出来,同时,也可以辅助智能生成代码生成更高质量的产物,也可以真正的根据用户喜好意图和场景生成个性化的设计。
智能 UI 已经验证了,在当前流量增量放缓的环境下,场(UI)的个性化是一个非常重要的增长动力,然而,UI 的量级很大,UI 的设计和研发成本非常高,如何快速智能设计 UI 是需要解决的问题。
在这个问题下,我们可以大致拆解为布局的生成和物料的生成。我们可以利用生成网络,根据用户的意图心智,产品需求,场的心智等元素,自动的去生成不同的布局和物料,再使用模型将这些组装起来,形成一个新的设计。我们希望由此出发,真正的在未来让整个平台的协作者,由手动去设计,去开发,变成一个人机交互师,真正使用机器和机器智能化的能力,为自己服务,从而大幅度解放自身生产力,投入到更有创造性和更具价值的活动中去!
F(X)Team 开通 微博 啦!
除文章外还有更多的团队内容等你解锁
猜你喜欢
- 2024-12-09 阿里技术官手写React进阶手册,让你轻松精通React
- 2024-12-09 操作JavaScript的AST
- 2024-12-09 阿里巴巴Java开发手册中的DO、DTO、BO、AO、VO、POJO定义
你 发表评论:
欢迎- 07-07使用AI开发招聘网站(100天AI编程实验)
- 07-07Tailwindcss 入门(tailwindcss中文文档)
- 07-07CSS 单位指南(css计量单位)
- 07-07CSS 定位详解(css定位属性的运用)
- 07-07程序员可以作为终身职业吗?什么情况下程序员会开始考虑转行?
- 07-07云和学员有话说:国企转行前端开发,斩获13K高薪!
- 07-0791年转行前端开发,是不是不该转,有啥风险?
- 07-07计算机图形学:变换矩阵(图形学 矩阵变换)
- 595℃几个Oracle空值处理函数 oracle处理null值的函数
- 587℃Oracle分析函数之Lag和Lead()使用
- 575℃0497-如何将Kerberos的CDH6.1从Oracle JDK 1.8迁移至OpenJDK 1.8
- 572℃Oracle数据库的单、多行函数 oracle执行多个sql语句
- 568℃Oracle 12c PDB迁移(一) oracle迁移到oceanbase
- 561℃【数据统计分析】详解Oracle分组函数之CUBE
- 548℃最佳实践 | 提效 47 倍,制造业生产 Oracle 迁移替换
- 541℃Oracle有哪些常见的函数? oracle中常用的函数
- 最近发表
- 标签列表
-
- 前端设计模式 (75)
- 前端性能优化 (51)
- 前端模板 (66)
- 前端跨域 (52)
- 前端缓存 (63)
- 前端react (48)
- 前端aes加密 (58)
- 前端脚手架 (56)
- 前端md5加密 (54)
- 前端路由 (61)
- 前端数组 (73)
- 前端js面试题 (50)
- 前端定时器 (59)
- 前端懒加载 (49)
- 前端获取当前时间 (50)
- Oracle RAC (73)
- oracle恢复 (76)
- oracle 删除表 (48)
- oracle 用户名 (74)
- oracle 工具 (55)
- oracle 内存 (50)
- oracle 导出表 (57)
- oracle 中文 (51)
- oracle的函数 (57)
- 前端调试 (52)
本文暂时没有评论,来添加一个吧(●'◡'●)