“前端智能化”存在的价值和意义，被不断拷问。

一部分人对“前端智能化”持拥抱态度，认为这是前端领域的一种革命性技术。

另一部分人则认为“前端智能化”可行性范围有限，大多是一些 Demo 性产品，对能否真正应用到业务生产持怀疑态度。

其最终目的还是要将产品和技术能力融入业务体系，释放技术红利，驱动业务增长。

本文将结合阿里云的业务场景，分析在中后台领域中，“前端智能化”如何降低开发成本，提升研发效能，从而创造更深远的业务价值。

01 让「前端智能化」真的运转起来

什么是前端智能化？

和垂直的“端智能”方向不同，前端智能化关注的领域更偏向于生产效率的提升。如果更准确的描述，“前端智能化”应该是“前端开发智能化”。

通过 AI 与前端业务深入结合，基于 AI 能力提供的丰富预测、推荐信息，结合研发逻辑积累，打造更加人性化、智能化的前端代码。

当然，并不是机器能生成 100%的代码去代替前端开发，出发点是让机器能自动化、智能化，为前端人员减少开发工作量，代替完成可抽象、可复用、UI 编排、国际化等低成本、较为繁琐的工作，最后产出一份可以二次开发、可维护、高质量的源码 Procode。

每一套技术方案背后，必然有完整的理论体系和运作机制。

Dumbo平台能力

阿里云在怎样的业务和技术背景下做边缘云 “前端智能化”？

从业务增长上来讲：由于云计算业务整合及调整，增加了大量的控制台、中后台管控等 B 端业务，在人力基本不变的情况下，团队如何快速支撑起这部分业务？

从业务特性上来讲：主要以 ToB 端、中后台为主, 重管控 crud、UI 编排较统一、研发逻辑相似等，云控制台产品的国际化等特性。

前端业务侧基于以上特性沉淀了前端技术框架，研发模式是基于组件化、场景化、模块化的方案。

通过这类研发方案，不仅能实现技术成本降低，组件化开发、最佳实践地积累等，还能通过统一的视觉标准规范，减少视觉沟通成本和沟通成本, 从而大大提高开发效率。

虽然，基于这种方式的研发方案能带来极大的提效，但在开发过程中也存在一些组件编排复杂、代码重复率高、大量无关核心业务逻辑开发的工作。

因此，我们思考如何基于现有研发方案，带来进一步提效？

首先，明确前端的研发成本。主要包括：UI 组件编排、业务逻辑（交互与数据）、文案国际化、工程链路、沟通成本（设计、后端、产品）等。

其次，站在巨人的肩膀上看问题。团队调研了一些现有的提效方案，主要包括：基于可视化搭建平台、基于可视化物料源码开发站、基于 AI 能力的效能提升平台等。

在此基础上，结合自身业务场景、现有研发方案、开发模式、学习成本等综合因素考虑，决定打造一个“智能化”的面向阿里云控制台、中后台源码开发平台。

02 Dumbo 的智能化：“智能识别”

Dumbo「智能化」是一个利用图像识别算法，一键生成前端代码的智能解决方案。目前已经落地于多个阿里云控制台及中后台项目。

Dumbo 的基本链路通过对标准化样本进行生成，基于样本来进行模型训练。用户只要输入图片，通过训练的模型就能识别及最终产出前端所需代码。

智能化的核心之一是“智能识别”，主要包含：目标检测算法、样本生成、模型训练及识别。

目标检测算法

即输入一张图片，输出图片中感兴趣物体的坐标信息。经典的目标检测算法有两种，one-stage 与 two-stage。one-stage 算法即只对图片处理一次，它的速度通常优于 two-stage 算法，代表算法有 yolo 系列。

而 two-stage 算法会对图片处理两次，先找到可能存在目标的区域，再对该区域做一次预测。这类算法速度较慢但准确率更好，代表算法有 Faster R-CNN。

主要使用的目标检测算法是 SSD300。SSD300 是 2016 年提出的一种目标检测算法，它是一种 one-stage 算法，同时吸收了 yolo 和 Faster R-CNN 的优点，兼具速度和准确率。虽然在最新的目标检测算法排名中，SSD 已不再具有优势。

“ 在前端场景的目标检测中，组件并没有复杂的特征形态，算法不是最重要的因素，样本集和超参数的设置往往比算法本身更重要。”

SSD 算法在准确率和速度上都较 YOLO 有较大提升，SSD 算法在经过一次 VGG-16 转换后，得到一个 38 38 512 的特征图，之后的每一次卷积运算的同时都会输出一次预测结果。

这么做可以兼顾大目标和小目标的检测，感受野小的 feature map 检测小目标，感受野大的 feature map 检测大目标。SSD 同时引入了 Faster RCNN 中的 Anchor，提出了相似的 Prior box 概念，在对样本做标记时，也是基于 Prior box 的偏移来做的。

在每一个不同尺寸的 feature map 中，都预先设置好了多个 Prior box，这些先验框可通过人为规定或统计学方法计算得到。

在对目标做标记时，SSD 要求找到与待检测目标真实框交并比最大的先验框，由它负责预测该目标，标记的数据为两个框之间差值。预测的时候也是同理，因此，在 SSD 中，会多出一步转换的过程，用来还原真实框的位置信息。

Dumbo 把该套目标检测算法通过 PAI 深度学习训练来训练模型，并部署在 PAI 上的在线模型服务（ESA）,通过函数计算来实现服务调用，实现了一套模型训练服务。

样本生成

目标检测的模型训练，样本集尤为重要。对于现有场景而言，样本集就是各种各样的控制台页面截图。

想要识别的组件，需要在图片中标注出来，标注格式有多种，常见的格式有 xml、json、csv 等。根据 SSD 算法需要的标准细节，采用了 xml 格式对组件进行标注。以 Button 为例，标注信息包括组件的左上角顶点坐标、组件的长度和宽度。

不同的目标检测算法需要的数据可能不同，有的需要组件中心点的坐标数据，有的则需要组件占图片的比例数据。这些数据都可以通过计算相互转换，本质并没有发生变化。

将图片中所有组件都标注完成后，得到了一对样本图片与标注文件的集合，大量这样的集合便构成了样本集。

仅使用真实控制台页面截图是远远不够的，并且手动标注费时又容易出错。对此分别使用了 fusion 构建了动态样本数据集。fusion 风格样本主要以阿里云控制台标准为主，用于训练阿里云控制台场景模型。

下图是使用 fusion 构建的一个随机控制台页面，目前，各类型的组件分布算法采用的是围绕视觉规范为均值的正态分布，这么做可以在少量样本条件下训练出表现更好的模型。后续将使用更加均匀的分布算法改造样本集，因为在前端领域的目标检测中，并不适合完全均匀分布的布局算法。

举个例子，PageHeader 组件，位置信息是其自身的一项特征，如果在页面底部出现了一个和 PageHeader 一模一样的组件，也不应该将其标注为 PageHeader。

组件内部属性的随机化，也要遵循一些约束，比如 Select 组件，边框、右侧的 arrow-down Icon 是其主要特征，在使用代码生成时，最好不要忽略它们。圆角、边框颜色等则不是主要特征，可以尽量随机化，让训练出的模型更具鲁棒性。

一个值得思考的特征是 placeholder，“请选择 xxx”，这里的“请选择”实际上也是一项重要的特征，思考一下，如果一个组件，除了右侧没有 arrow-down 图标，其他特征和 Select 组件一致，那么，应该将其判断为 Select 还是 Input？

总结起来，训练模型的过程，其实是让模型挖掘到组件的完整特征信息，并根据各项特征的重要程度做权重优化的过程。有了样本图片，还需要标注信息。在 Dumbo 中，使用 js 方法获取了每个组件的位置和长宽数据，在通过 puppeteer 截图的过程中，自动导出标注文件。

基于以上说明，产出样本生成服务如下：

模型训练及识别

Dumbo 提供了整套的模型训练服务，可以方便的将已经生成好的样本文件进行模型训练，这块基于 PAI 的能力，把整个模型训练链路集成到项目中，下图为模型训练的整体链路。

通过 OSS 作为中间集，进行数据和模型部署，实现了整体的模型训练链路。

基于以上模型训练链路，在 Dumbo 的 fusion 场景中训练多种模型，包括整页模型、表单模型、图表模型、详情页模型、Icon 模型等多个模型用于识别服务。

识别过程同时采用了递归识别和组合识别。这是为了提高小组件的识别准确率。同时将识别任务拆分到多个模型中，可降低各个模型的训练难度。

03 “智能出码”：一键生成前端代码

通过上述的智能识别，可以了解到 Dumbo 的全部训练和识别过程，识别产物非前端代码，需要根据边缘云前端框架及阿里云规范，对识别数据进行处理，最终生成前端同学可复用的布局和逻辑代码代码，从而提高研发效率。

下图是具体出码实现步骤：

图像分析

“目标检测 + 分类”看似能基本 cover 控制台视觉稿的识别，然而理想很美好, 现实不够理想。

在大量验证过程中，发现仅通过模型预测的结果精确度偏低，一些情况下预测结果位置信息存在一些偏差。同时为了模型收敛，也存在主体分类粒度不够，导致无法更好的完成后续的还原工作。

为了提高识别的准确率及视觉还原度，所以采用深度学习结合传统图像分析的方式，优化 AI 识别内容，丰富组件识别特征度，提供给上游链路更丰富有效的数据信息。

➢ 预处理：通过边界判断页面 padding 情况，是否需要切割和补充 padding 来规范预测图片内容、优化识别效果。

➢ 数据处理：在数据处理阶段做一个初步的去重操作，该操作主要判断：当两个组件没有父子关系且重叠阈值（交并比）大于某个值（这里根据经验取的 0.8）， 删除置信度较低的组件。本步骤主要为了解决 AI 对同一个物体识别为多个不同标签的情况。

➢ 位置优化：主要通过 OpenCV 进行图像分析轮廓识别，在比对轮廓的重叠阀指，收敛轮廓大小使轮廓区域和实际图像更加贴合。处理结果前后对比如下：

➢ 属性检测：主要通过 OpenCV 的颜色判断，来区分组件的属性类型，类似分析 Message 组件背景色，判断 Type 值为 Success、Error、 Notice、Warning 等。通过简单的 CV 分析，可以不断丰富组件识别特征度，不断提升还原度。

➢ 关系矫正：对于有父子嵌套关系的组件，识别优化无法处理嵌套关系异常的情况，需要加入逻辑判断。例如 radioGroup/radio 则为父子关系组件，当有父子关系嵌套不完整时，需要进一步处理判断 radio 的 siblings 节点，并纠正父组件的位置，将其 siblings 包裹完整。

布局分析

视觉稿还原的主要目标是：布局还原准确、减少冗余重复代码，最大程度的贴合人工还原代码，所以需要对图像分析处理后的数据进行数据分析，增加部分节点数据，方便后续 DSL 转换和出码。

➢ 关系矩阵：分析其位置信息（x, y, width, height），将其生成一个 N 维关系矩阵。判断关系矩阵时，对行列位置进行了的阈值设置，规定在水平垂直等方向 xOverlap、yOverlap 重叠阈值小于某个值可忽略重叠部分。具体示意图如下：

➢ 行列生成：主要目的是将关系矩阵结构转换成节点树，同时使用栅格化的方式处理行列结构布局。用 Row 节点表示一行， Col 节点表示一列，递归调用 transfer2Grid 方法，生成节点树。注意：此过程需要考虑到基于组件化布局方式特点。从而定义 componentsInline 数组，包括'Button', 'Radio', 'Checkbox' 等。

➢ 组件设置：在此步骤中，以插件化的方式判断不同的类库包括 Fusion 样式属性，转换样式，设置组件属性及通用样式类。维护一个 config 属性名称映射，对节点进行样式相关属性检测及设置，同时根据位置信息判断一些浮动、边距样式等，设置通用 className。这种方式有利于布局还原代码可读性，可维护性。

DSL 转换

智能识别的数据是一份平面化数据，需要还原为立体、有结构的 DSL 数据。转换 DSL 主要通过识别文字的预处理工作，依赖分析、和各个组件的 Adapter 组成，最终产出一份结构化的 schema 数据。

预处理：Dumbo 的文字识别之后产生的是一个 Text 节点数据，包含中英文属性，但是文案中可能会存在一些影响最终展示的特殊符号，比如●、丫等，这些符号的误识别会导致最终展示上出现不理想的情况，也有可能会出现长文字被截断成为多个文字节点的情况，需要把这些文字节点进行合并处理等。然后对生成的组件进行国际化处理。

Adapter（以 Form 组件为例子）

首先，进行节点分割，分割为文字节点和组件节点；

其次，根据 Form 特性，一般以组件作为 FormItem 的 children，Text 作为 label 属性，优先进行组件节点判断，通过遍历组件节点，并通过相邻节点函数判断，获取到该节点的相邻的 Text, 并根据交互稿规范的相邻阀值，进行 label 判断，由于不确定 FormItem 的布局情况，可能存在上下/左右 2 种布局形式，所以会同时判断 TopText 和 LeftText，并分别放入对应的数组中，之后进行比较。

根据 Form 表单的特性，一般 Form 的排列形式比较一致，不是上下/左右，很少存在既有上下，又有左右的形式，所以这块直接判断 TopText 和 LeftText 的个数来进行布局确认。

在了解布局之后，可以再次遍历没有被命中的文字节点和组件节点，因为已经确定布局类型，所以可以直接根据阀值，来判断是否存在只有文字的 FormItem 组件，进一步完善组件内容及属性，并且可以把一部分识别不是很准确的 RadioGroup 等进行合并处理。

最后，进行组件的 FormItem 组装，输出给一个完成的结构化数据。

依赖分析：识别数据通过 Adapter 转换之后，获取到的 Schema 并不包含依赖关系，和集团的规范存在出入，依赖提取的后处理部分，就是通过对 Schema 的遍历，提取使用到的组件信息，通过对应的模版依赖库，加载对应的依赖关系。

在可视化微调上，基于集团的 Low-Code 引擎，建立了一套 Fusion 物料组件，支持识别数据的可视化微调，进一步提升出码准确率。

代码生成

对于代码生成，则主要围绕着集团最新的搭建协议，通过场景的一系列编排，最终完成一个组件的生成。其结构大体可描述为：

在出码处主要处理的内容，是将机器递归遍历给出的字符串，重进编排整合，使其具有维护的能力。主要解决的问题为：代码拆分/整合、状态管理、国际化、样式。

首先，对于代码的拆分和整合。目前主要根据 DSL 中的节点类型进行拆分。对于 BLOCK 、 Component 节点，直接划分为通用的场景，以供其他页面或者模块使用。

其次，是状态管理。目前开发中，dva 已经成为团队统一的状态管理工具，在遍历过程中会对页面的 state 、 effects 进行提取，通过映射，完成组装。

然后，是国际化相关的内容。在集团的搭建协议中，可以看到最新版本的国际化内容已经被替换成如下形式。

整合后的 DSL 中 i18n 的内容会被单独提取出来，对于调用处是一个表达式。而目前团队的国际化方案更多的是自有风格，所以在处理国际化节点时需要做响应的替换。

最后，是样式相关。通过之前的布局分析，通过一系列的计算，最终每个组件节点都被赋予了栅格化的 ClassName 。所以此处只要把布局所需要的基础 css 文件作为依赖引入到页面文件中即可。

目前来说，“前端智能化” Dumbo 平台已接入众多公有云控制台应用 ，其中新控制台接入页面覆盖率大于 50%，研发效率感官提效约 30%，在整体识别率、准确率上满足了业务的基本要求，而在场景覆盖、智能化程度、智能交互等方面，也在探索更多的提升空间。

后续，计划进一步收敛场景规范、扩大使用场景覆盖面的同时，不断丰富数据模型能力，从灵活性、识别特征度、模型准确率等多维度考虑，提高“智能化”能力。同时，继续让“智能化”和“低代码”进行结合，让使用者可以通过简单的接口配置，实现页面在线运行。

未来的智能化不止于代码，还在向端云协同方向做更多渗透。

「视频云技术」你最值得关注的音视频技术公众号，每周推送来自阿里云一线的实践技术文章，在这里与音视频领域一流工程师交流切磋。公众号后台回复【技术】可加入阿里云视频云产品技术交流群，和业内大咖一起探讨音视频技术，获取更多行业最新信息。