设计稿生成代码与 Serverless 的前世今生与未来!

本文涉及的产品
可观测监控 Prometheus 版,每月50GB免费额度
云原生网关 MSE Higress,422元/月
注册配置 MSE Nacos/ZooKeeper,182元/月
简介: 云栖大会云上 Hello World 活动火热进行中!每位参与者都可收获一份阿里云出品的全球唯一序列号纪念证书!

1.png

一场脑洞实验

云栖大会云上 Hello World 活动火热进行中!每位参与者都可收获一份阿里云出品的全球唯一序列号纪念证书!

作为阿里经济体前端委员会的四大技术方向之一,前端智能化方向一被提及,就不免有人好奇:前端结合机器学习能做些什么,怎么做,未来会不会对前端产生很大的冲击等等。本文以「设计稿自动生成代码」场景为例,细述我们的思考及过程实践。

前端智能化与云 IDE 的结合,通过后者打通的各种服务与接口,再加上设计稿生成代码的能力,可以进一步地提升前端开发者的开发体验,由原来的设计稿生成代码,转变为生成可随时可部署的应用/页面,因此本文最后会介绍如何在阿里云云开发平台使用 imgcook 插件,一键完成设计稿稿生成应用,开启您的智能开发之旅。

前端智能化背景

业界机器学习之势如火如荼,「AI 是未来的共识」频频出现在各大媒体上。李开复老师也在《AI · 未来》指出,将近 50% 的人类工作将在 15 年内被人工智能所取代,尤其是简单的、重复性的工作。并且,白领比蓝领的工作更容易被取代;因为蓝领的工作可能还需要机器人和软硬件相关技术都突破才能被取代,而白领工作一般只需要软件技术突破就可以被取代,那我们前端这个“白领”工作会不会被取代,什么时候能被取代多少?

回看 2010 年,软件几乎吞噬了所有行业,带来近几年软件行业的繁荣;而到了 2019 年,软件开发行业本身却又在被 AI 所吞噬。你看:DBA 领域出现了 Question-to-SQL,针对某个领域只要问问题就可以生成 SQL 语句;基于机器学习的源码分析工具 TabNine 可以辅助代码生成;设计师行业也出了 P5 Banner 智能设计师“鹿班”,测试领域的智能化结合也精彩纷呈。那前端领域呢?

那就不得不提一个我们再熟悉不过的场景了,它就是设计稿自动生成代码(Design2Code,以下简称 D2C),阿里经济体前端委员会 - 前端智能化方向当前阶段,就是聚焦在如何让 AI 助力前端这个职能角色提效升级,杜绝简单重复性工作,让前端工程师专注更有挑战性的工作内容!

imgcook 是什么?

imgcook 使用 Sketch、PSD、静态图片等形式作为输入,通过智能化技术一键生成可维护的前端代码,包含视图代码、数据字段绑定、组件代码、部分业务逻辑代码等。

2.png

它期望能够利用智能化手段,让自己成为一位前端工程师,在对设计稿轻约束的前提下实现高度还原,释放前端生产力,助力前端与设计师高效协作,让工程师们专注于更具挑战性的工作!

设计稿生成代码的目标是让 AI 助力前端这个职能角色提效升级,杜绝简单重复性工作内容。那我们先来分析下,“常规”前端尤其是面向 C 端业务的同学,一般的工作流程日常工作内容大致如下:

3.png

“常规”前端一般的开发工作量,主要集中在视图代码逻辑代码数据联调这几大块,接下来,我们逐块拆解分析。

1. 问题定义

视图代码研发,一般是根据视觉稿编写 HTML 和 CSS 代码。如何提效?当面对 UI 视图开发重复性的工作时,自然想到组件化、模块化等封装复用物料的解决方案,基于此解决方案会有各种 UI 库的沉淀,甚至是可视化拼装搭建的更高阶的产品化封装,但复用的物料不能解决所有场景问题。个性化业务、个性化视图遍地开花,直面问题本身,直接生成可用的 HTML 和 CSS 代码是否可行?

4.png

这是业界一直在不断尝试的命题,通过设计工具的开发插件可以导出图层的基本信息,但这里的主要难点还是对设计稿的要求高、生成代码可维护性差,这是核心问题,我们来继续拆解。

1)设计稿要求高

对设计稿的要求高,会导致设计师的成本加大,相当于前端的工作量转嫁给了设计师,导致推广难度会非常大。

一种可行的办法是采用 CV(ComputerVision, 计算机视觉) 结合导出图层信息的方式,以去除设计稿的约束,当然对设计稿的要求最好是直接导出一张图片,那样对设计师没有任何要求,也是我们梦寐以求的方案,我们也一直在尝试从静态图片中分离出各个适合的图层,但目前在生产环境可用度不够(小目标识别精准度问题、复杂背景提取问题仍待解决),毕竟设计稿自带的元信息,比一张图片提取处理的元信息要更多更精准。

2)代码可维护性

生成的代码结构一般都会面临可维护性方面的挑战:

  • 合理布局嵌套:包括绝对定位转相对定位、冗余节点删除、合理分组、循环判断等方面;
  • 元素自适应:元素本身扩展性、元素间对齐关系、元素最大宽高容错性;
  • 语义化:类名的多级语义化;
  • 样式 CSS 表达:背景色、圆角、线条等能用 CV 等方式分析提取样式,尽可能用 CSS 表达样式代替使用图片。

将这些问题拆解后,分门别类专项解决,解决起来看似没完没了,但好在目前发现的大类问题基本解决。

很多人质疑道:这部分能力的实现看起来和智能化一点关系都没有,顶多算个布局算法相关的专家规则系统。没错,现阶段这部分比较适合规则系统,对用户而言布局算法需要接近 100% 的可用度,另外这里涉及的大部分是无数属性值组合问题,当前用规则更可控。如果非要使用模型,那这个可被定义为多分类问题。同时,任何深度学习模型的应用都是需要先有清晰的问题定义过程,把问题规则定义清楚本就是必备过程。

但在规则解决起来麻烦的情况下,可以使用模型来辅助解决。比如 合理分组(如下图) 和 循环项 的判断,实践中我们发现,在各种情况下还是误判不断,算法规则难以枚举,这里需要跨元素间的上下文语义识别,这也是接下来正在用模型解决的重点问题。

5.png

2. 技术方案

基于上述的概述和问题分解后,我们对现有的 D2C 智能化技术体系做了能力概述分层,主要分为以下三部分:

  • 识别能力:即对设计稿的识别能力,智能从设计稿分析出包含的图层、基础组件、业务组件、布局、语义化、数据字段、业务逻辑等多维度的信息;如果智能识别不准,就可视化人工干预补充纠正,一方面是为了可视化低成本干预生成高可用代码,另一方面这些干预后的数据就是标注样本,反哺提升智能识别的准确率;
  • 表达能力:主要做数据输出以及对工程部分接入:a)通过 DSL 适配将标准的结构化描述做 Schema2Code;b)通过 IDE 插件能力做工程接入;
  • 算法工程:为了更好的支撑 D2C 需要的智能化能力,将高频能力服务化,主要包含数据生成处理、模型服务部分:

    • 样本生成:主要处理各渠道来源样本数据并生成样本;
    • 模型服务:主要提供模型 API 封装服务以及数据回流。

6.png
(前端智能化 D2C 能力概要分层)

在整个方案里,我们用同一套数据协议规范(D2C Schema)来连接各层的能力,确保其中的识别能够映射到具体对应的字段上,在表达阶段也能正确地通过出码引擎等方案生成代码。

1)智能识别技术分层

在整个 D2C 项目中,最核心的是上述识别能力部分的机器智能识别部分,这层的具体再分解如下:

  • 物料识别层:主要通过图像识别能力识别图像中的物料(模块识别、原子模块识别、基础组件识别、业务组件识别);
  • 图层处理层:主要将设计稿或者图像中图层进行分离处理,并结合上一层的识别结果,整理好图层元信息;
  • 图层再加工层:对图层处理层的图层数据做进一步的规范化处理;
  • 布局算法层:转换二维中的绝对定位图层布局为相对定位和 Flex 布局;
  • 语义化层:通过图层的多维特征对图层在生成代码端做语义化表达;
  • 字段绑定层:对图层里的静态数据结合数据接口做接口动态数据字段绑定映射;
  • 业务逻辑层:对已配置的业务逻辑通过业务逻辑识别和表达器来生成业务逻辑代码协议;
  • 出码引擎层:最后输出经过各层智能化处理好的代码协议,经过表达能力(协议转代码的引擎)输出各种 DSL 代码。

7.png
(D2C 识别能力技术分层)

2)技术痛点

当然,这其中的识别不全面、识别准确度不高一直是 D2C 老生常谈的话题,也是 imgcook 的核心技术痛点。我们尝试从这几个角度来分析引起这个问题的因素:

  • 识别问题定义不准确:问题定义不准确是影响模型识别不准的首要因素,很多人认为样本和模型是主要因素,但在这之前,可能一开始对问题的定义就出现了问题,我们需要判断我们的识别诉求模型是否合适做,如果合适那该怎么定义清楚这里面的规则等;
  • 高质量的数据集样本缺乏:我们在识别层的各个机器智能识别能力需要依赖不同的样本,那我们的样本能覆盖多少前端开发场景,各个场景的样本数据质量怎么样,数据标准是否统一,特征工程处理是否统一,样本是否存在二义性,互通性如何,这是我们当下所面临的问题;
  • 模型召回低、存在误判:我们往往会在样本里堆积许多不同场景下不同种类的样本作为训练,期望通过一个模型来解决所有的识别问题,但这却往往会让模型的部分分类召回率低,对于一些有二义性的分类也会存在误判。

【问题定义】

深度学习里的计算机视觉类模型目前比较适合解决的是分类问题和目标检测问题,我们判断一个识别问题是否该使用深度模型的前提是——我们自己是否能够判断和理解,这类问题是否有二义性等,如果人也无法准确地判断,那么这个识别问题可能就不太合适。

假如判断适合用深度学习的分类来做,那就需要继续定义清楚所有的分类,这些分类之间需要严谨、有排他性、可完整枚举。比如在做图片的语义化这个命题的时候,一般图片的 ClassName 通用常规命名有哪些,举个例子,其分析过程如下:

8.png

  • 第一步:尽可能多地找出相关的设计稿,一个个枚举里面的图片类型;
  • 第二步:对图片类型进行合理归纳归类,这是最容易有争论的地方,定义不好有二义性会导致最有模型准确度问题;
  • 第三步:分析每类图片的特征,这些特征是否典型,是否是最核心的特征点,因为关系到后续模型的推理泛化能力;
  • 第四步:每类图片的数据样本来源是否有,没有的话能否自动造;如果数据样本无法有,那就不适合用模型,可以改用算法规则等方式替代先看效果。

D2C 项目中很多这样的问题,问题本身的定义需要非常精准,并且需要有科学的参考依据,这一点本身就比较难,因为没有可借鉴的先例,只能先用已知的经验先试用,用户测试有问题后再修正,这是一个需要持续迭代持续完善的痛点。

【样本质量】

针对样本问题,我们需要对这部分数据集建立标准规范,分场景构建多维度的数据集,将收集的数据做统一的处理和提供,并以此期望能建立一套规范的数据体系。

在这套体系中,我们使用统一的样本数据存储格式,提供统一的针对不同问题(分类、目标检测)的样本评估工具来评估各项数据集的质量,针对部分特定模型可采取效果较好的特征工程(归一化、边缘放大等)来处理,同类问题的样本也期望能在后续不同的模型里能够流通作比较,来评估不同模型的准确度和效率。

9.png
(数据样本工程体系)

【模型】

针对模型的召回和误判问题,我们尝试收敛场景来提高准确度。往往不同场景下的样本会存在一些特征上的相似点或者影响部分分类局部关键特征点,导致产生误判、召回低,我们期望能够通过收敛场景来做模式化的识别,提高模型准确度。

我们把场景收敛到如下三个场景:无线 C 端营销频道场景、小程序场景以及 PC 中后台场景。这里面几个场景的设计模式都有自己的特色,针对各个场景来设计垂直的识别模型可以高效地提高单一场景的识别准确度。

10.png
(D2C 场景)

3)思考与解法

总的来说,既然使用了深度模型,有一个比较现实的问题是,模型的泛化能力不够,识别的准确率必然不能 100% 让用户满意,除了能够在后续不断地补充这批识别不到的样本数据外,在这之前我们能做什么?

在 D2C 的整个还原链路里,对于识别模型,我们还遵守一个方法论,即设计一套协议或者规则能通过其他方式来兜底深度模型的识别效果,保障在模型识别不准确的情况下用户仍可完成诉求:手动约定 > 规则策略 > 机器学习 > 深度模型。举个例子比如需要识别设计稿里的一个循环体:

  • 初期,我们可以在设计稿里手动约定循环体的协议来达成;
  • 根据图层的上下文信息可做一些规则的判断,来判断是否是循环体;
  • 利用机器学习的图层特征,可尝试做规则策略的更上游的策略优化;
  • 生成循环体的一些正负样本来通过深度模型进行学习。

其中手动约定的设计稿协议解析优先级最高,这样也能确保后续的流程不受阻塞和错误识别的干扰。

imgcook x 云开发平台

了解前端智能化和 imgcook 大致思路之后,那么为什么会选择在云开发平台上集成 imgcook 呢?那就是 imgcook 和云开发平台通过彼此的打通,将能够为双方解决彼此的痛点,无论是为云上开发者,还是 imgcook 开发者都提供了全新的用户体验。

对于 imgcook 开发者来说,其中一个痛点就来自于对于设计稿的管理,以及前后端交互的逻辑,然而通过云开发平台,开发者不再需要在本地安装 Sketch,通过云开发平台直接上传设计稿即可开始生成代码,真正做到了0成本一键生成。

另外云开发平台上直接提供了Midway Serverless 框架,我们通过云开发平台的插件定制化,可以让开发者直接选择某个页面所使用的函数(Function),这样就节省掉编写一些前后端交互的基础逻辑或请求代码。

对于云开发平台的开发者来说,最想得到的便是极速的上线体验和更加便捷的开发体验,imgcook 可以降低云开发平台的使用门槛,比如一位 FaaS 应用工程师不再需要学习如何切图,如何写 CSS,而只需要编写 FaaS 函数的逻辑即可,剩下的前端逻辑代码都可以通过 imgcook 插件在开发平台内即可完成,这是多么棒的体验啊!

那么,接下来就看看如何快速地从0到1生成代码吧。

首先需要先打开云开发平台创建应用,选择 imgcook 创建应用:

11.png

然后在应用的 WebIDE 中通过右键打开 imgcook 云插件,就可以正式开始使用了。

12.png

第一步,在插件中选择“导入”,打开上传设计稿界面:

13.png

第二步,imgcook 可视化编辑器:

14.png

第三步,生成代码:

15.png

第四步,导出代码到应用:

16.png

第五步,上线应用:

$ npm install
$ npm run dev
正在启动,请稍后...
---------------------------------------
开发服务器已成功启动
请打开 >>> http://*****-3000.xide.aliyun.com/
---------------------------------------
感谢使用 Midway Serverless,欢迎 Star!
https://github.com/midwayjs/midway
---------------------------------------

启动成功后通过命令行的地址打开页面效果如下,是不是很简单呢?

17.png

总结

本文通过介绍前端智能化的背景,imgcook 的问题定义以及技术方案,以及如何在云开发平台上使用 imgcook 开始智能开发,总的来说,还是希望让业内的前端工程师们从使用 imgcook 开始,将日常工作中的一些繁琐、耗时的工作交给 AI 来完成,这样能关注工程师本身更感兴趣,也更有价值的事情,也相信不久的将来,前端工程师将借助于 AI 能更加快乐与从容地工作!

点击链接立即体验:https://yunqi.aliyun.com/2020/hol

阿里巴巴云原生关注微服务、Serverless、容器、Service Mesh 等技术领域、聚焦云原生流行技术趋势、云原生大规模的落地实践,做最懂云原生开发者的公众号。”

相关实践学习
【AI破次元壁合照】少年白马醉春风,函数计算一键部署AI绘画平台
本次实验基于阿里云函数计算产品能力开发AI绘画平台,可让您实现“破次元壁”与角色合照,为角色换背景效果,用AI绘图技术绘出属于自己的少年江湖。
从 0 入门函数计算
在函数计算的架构中,开发者只需要编写业务代码,并监控业务运行情况就可以了。这将开发者从繁重的运维工作中解放出来,将精力投入到更有意义的开发任务上。
相关文章
|
消息中间件 JavaScript 中间件
函数计算产品使用问题之WebIDE编写的Node.js代码是否会自动进行打包部署
函数计算产品作为一种事件驱动的全托管计算服务,让用户能够专注于业务逻辑的编写,而无需关心底层服务器的管理与运维。你可以有效地利用函数计算产品来支撑各类应用场景,从简单的数据处理到复杂的业务逻辑,实现快速、高效、低成本的云上部署与运维。以下是一些关于使用函数计算产品的合集和要点,帮助你更好地理解和应用这一服务。
|
存储 运维 Serverless
函数计算产品使用问题之如何解决代码需要多个gpu的问题
函数计算产品作为一种事件驱动的全托管计算服务,让用户能够专注于业务逻辑的编写,而无需关心底层服务器的管理与运维。你可以有效地利用函数计算产品来支撑各类应用场景,从简单的数据处理到复杂的业务逻辑,实现快速、高效、低成本的云上部署与运维。以下是一些关于使用函数计算产品的合集和要点,帮助你更好地理解和应用这一服务。
|
11月前
|
Serverless 数据安全/隐私保护 前端开发
大模型代码能力体验报告之贪吃蛇小游戏《一》:Claude.ai篇 - 生成、预览和快速部署的serverless一条龙
本文介绍了通过Claude.ai生成并优化Web版贪吃蛇游戏的过程,展示了其强大的代码生成功能及用户友好的界面设计。从初始版本的快速生成到根据用户反馈调整游戏速度,再到提供多种实用工具如文件管理、版本控制和一键部署,Claude.ai不仅是一个代码助手,更像是一个全面的serverless开发平台。文中还呼吁国内厂商关注此类技术的发展。
470 2
|
存储 运维 Serverless
函数计算产品使用问题之代码上传记录如何查看
函数计算产品作为一种事件驱动的全托管计算服务,让用户能够专注于业务逻辑的编写,而无需关心底层服务器的管理与运维。你可以有效地利用函数计算产品来支撑各类应用场景,从简单的数据处理到复杂的业务逻辑,实现快速、高效、低成本的云上部署与运维。以下是一些关于使用函数计算产品的合集和要点,帮助你更好地理解和应用这一服务。
|
缓存 运维 Java
函数计算产品使用问题之如何在函数代码的根目录中执行命令
阿里云Serverless 应用引擎(SAE)提供了完整的微服务应用生命周期管理能力,包括应用部署、服务治理、开发运维、资源管理等功能,并通过扩展功能支持多环境管理、API Gateway、事件驱动等高级应用场景,帮助企业快速构建、部署、运维和扩展微服务架构,实现Serverless化的应用部署与运维模式。以下是对SAE产品使用合集的概述,包括应用管理、服务治理、开发运维、资源管理等方面。
135 7
|
存储 固态存储 Serverless
函数计算操作报错合集之创建云函数并设置代码从Bucket获取时,返回403错误,该如何解决
Serverless 应用引擎(SAE)是阿里云提供的Serverless PaaS平台,支持Spring Cloud、Dubbo、HSF等主流微服务框架,简化应用的部署、运维和弹性伸缩。在使用SAE过程中,可能会遇到各种操作报错。以下是一些常见的报错情况及其可能的原因和解决方法。
164 3
|
缓存 Serverless API
函数计算产品使用问题之没有s.yaml文件,修改代码如何重新部署
实时计算Flink版作为一种强大的流处理和批处理统一的计算框架,广泛应用于各种需要实时数据处理和分析的场景。实时计算Flink版通常结合SQL接口、DataStream API、以及与上下游数据源和存储系统的丰富连接器,提供了一套全面的解决方案,以应对各种实时计算需求。其低延迟、高吞吐、容错性强的特点,使其成为众多企业和组织实时数据处理首选的技术平台。以下是实时计算Flink版的一些典型使用合集。
141 2
|
5月前
|
SQL 分布式计算 Serverless
鹰角网络:EMR Serverless Spark 在《明日方舟》游戏业务的应用
鹰角网络为应对游戏业务高频活动带来的数据潮汐、资源弹性及稳定性需求,采用阿里云 EMR Serverless Spark 替代原有架构。迁移后实现研发效率提升,支持业务快速发展、计算效率提升,增强SLA保障,稳定性提升,降低运维成本,并支撑全球化数据架构部署。
467 56
鹰角网络:EMR Serverless Spark 在《明日方舟》游戏业务的应用
|
3月前
|
存储 编解码 Serverless
Serverless架构下的OSS应用:函数计算FC自动处理图片/视频转码(演示水印添加+缩略图生成流水线)
本文介绍基于阿里云函数计算(FC)和对象存储(OSS)构建Serverless媒体处理流水线,解决传统方案资源利用率低、运维复杂、成本高等问题。通过事件驱动机制实现图片水印添加、多规格缩略图生成及视频转码优化,支持毫秒级弹性伸缩与精确计费,提升处理效率并降低成本,适用于高并发媒体处理场景。
169 0
|
5月前
|
人工智能 开发框架 安全
Serverless MCP 运行时业界首发,函数计算让 AI 应用最后一公里提速
作为云上托管 MCP 服务的最佳运行时,函数计算 FC 为阿里云百炼 MCP 提供弹性调用能力,用户只需提交 npx 命令即可“零改造”将开源 MCP Server 部署到云上,函数计算 FC 会准备好计算资源,并以弹性、可靠的方式运行 MCP 服务,按实际调用时长和次数计费,欢迎你在阿里云百炼和函数计算 FC 上体验 MCP 服务。
467 30

相关产品

  • 函数计算