作为阿里经济体前端委员会四大技术方向之一，前端智能化项目经历了2019双十一的阶段性考验，交出了不错的答卷，天猫淘宝双十一会场新增模块79.34%的线上代码由前端智能化项目自动生成。在此期间研发小组经历了许多困难与思考，本次《前端代码是怎样智能生成的》系列分享，将与大家分享前端智能化项目中技术与思考的点点滴滴。
概述
imgcook 是以各种设计稿图像（Sketch/PSD/ 静态图片）为原材料烹饪的匠心大厨，通过智能化手段将各种原始设计稿一键生成可维护的 UI 试图代码和逻辑代码。
语义化是什么？
语义主要研究符号标记，以及他们所代表的事物之间的关系，语言学中主要研究符号所表达的意思，而在web前端开发领域中，语义化指编写HTML的过程中“用最恰当语义的html标签和class类名等内容，让页面具有良好的结构与含义，从而让人和机器都能快速理解网页内容”。语义化的web页面一方面可以让机器（搜索引擎、爬虫、屏幕阅读器）在更少的人类干预下收集并研究网页的信息，从而可以读懂网页内容，收集汇总信息进行分析；另一方面它可以让开发人员读懂结构，快速理解页面各区块功能，便于二次维护。简单来说就是利于SEO，便于阅读维护理解。
传统语义化包含了 html 标签的语义和 class 类名的语义。
先说 html 标签语义，在 HTML5 出现之前，我们只能用没有语义的 div 来表示页 面章 节。 现 在， 通 过 使用 HTML5 语 义 元 素 标 签， 如 body、article、nav、aside、section、header、footer、hgroup 等，我们可以通过读取 html 结构就了解页面的布局结构。在 react-native、rax 等跨端 UI 体系下，标签通常被各种组件替代，标签语义化也就转换成了“组件语义化”，在合适的场景下使用合适的组件名即可实现结构可读。
class 类名语义化指用易于理解的名称对 html 标签附加的 class 或 id 命名。class属性本意用来描述元素样式内容的，经过前端领域多年的演变，已经不仅局限于做HTML 和 CSS 的衔接，而是一个集样式定义、函数钩子、组件类型等多层意义的复杂属性。本文将专注于 class 类名语义化这个问题，尝试运用 D2C 的能力彻底解决。
所在分层
在整体架构中，语义化层负责对布局算法生成的视图进行语义推测，用较为人性化的类名替换初始值，从而达到接近前端自己命名的效果。
(D2C 技术能力分层 )
制定 class 类名命名原则
业界规范
BEM（Block，Element，Modifier）
BEM 是块（block）、元素（element）、修饰符（modifier）的简写，由 Yandex团队提出的一种前端 CSS 命名方法论。用中划线、双下划线、单下划线来做单词间的链接记号，通过将页面分解为一个个小小的可重复使用组件来解决复杂项目的命名问题。 比如：.block{}、.block__element{}、.block--modifier{}， 都是典型的BEM 命名模式，他们的命名规范、可读性高，通过组件的修饰符就可以了解组件的形态。
NEC（niceeasycss）
国内的网易团队指定的前端样式规范。通过指定的单字母前端来做功能划分，大体 上 有 以 下 功 能： 重 置 和 默 认（reset+base）、 布 局（g-）、 模 块（m-）、 元 件（u-）、功能（f-）、皮肤（s-）、状态（z-）、js 钩子（j-）等。基于上述单字母命名，再使用简约而不失语义的后代选择器名称追加其后。典型的 NEC 命名如 m-list、u-btn-hover 等。
AliceUi
用扁平化的方式划分为不同层级。基于 - 符号做命名空间隔离，第一个前缀通常是通用业务标识，各业务线选取自己的前缀，后面依次用组件名、组件状态等填充。组件名必选，且要求表意，模块内部类名需继承上层名称。ui-name-status、uipage-item-info 都是典型的 AliceUi 命名方式。
业界的 class 类名规范的目的都是解决大规模项目下的样式命名问题，且因为遵循了各种层级结构关系和私有约定，编写出的类名普遍较长、在不了解规范的人眼中需要有一定的适应过程。不是特别适合 D2C 主打的移动端轻量级的模块开发场景。
从实际场景推导
为了寻求适合的场景，我们分析了内部的前端工程师在导购开发业务下真实代码的样式命名。下图是我们对淘系导购页面的真实词频统计结果，左图是样式全名词频，右图是拆分之后的原子结果：
( 前端样式词频分析 )
图中样式命名有如下特点：
- 和 BEM、NEC 等规范的风格不同，实际开发场景中的命名相对简洁
- 准确表达语义，且和节点业务特征强关联
- 单词为主，复合词采用驼峰命名，长度通常不超过 3
- 辅助性的修饰词如：wrap、ctn、empty、desc 等高频出现
- 可使用通俗易懂的简写单词
制定命名原则
D2C 希望优先解决淘系移动业务的问题，总体上以实际场景为主，业界规范为辅，最终确定了以表意为主要原则的样式命名策略：
- 表意：样式名需准确表达节点意义，选择上优先从移动端业务真实类名中获取
- 简洁：以单个词为主，所有词都使用不超过三个原子词组合
- 规范：以驼峰为主，同时在代码转化层面保留了转化为连字符的能力
- 工整：从模块根节点开始，采用布局信息 + 区块语义 + 语义辅助的整体命名策略
类名策略树
命名原则确定后，我们相当于定义了一个树的最终叶子节点形态，接下来需要构建从枝干一点点按图索骥到这些最终节点的过程，最终构建出我们的类名策略树。
判别维度
在实际对节点类名命名的过程中，我们要考虑的规则往往是多个维度的：
( 样式判别维度 )
imgcook 对淘系多达几百的模块进行规则提取，根据真实书写习惯，将上述规则做了权重，一般来说我们希望功能类别优先于样式特征，即一个按钮播放器按钮命名为 playBtn 而不是 circleIcon。其他的规则作为辅助决策，在整个树中左右走向。
基于节点样式、内容、层级、特征、权重、布局、全局计数对组件节点做了多方位多种类型的鉴别。同时借助阿里内部 sqi 平台和 D2C 自身的智能化能力，实现对一些经验规则解决不了的节点类名的鉴别。
(D2C 样式命名选型 )
策略定型
在建设完成阿里内部业务专属的类名专家系统后，结合智能化算法，我们升级了策略判别的流程，并整合出了下面这个最终的策略树。从根节点出发，大部分节点都可以通过此策略树归纳到一个具体语义结果上。
(D2C 样式策略树 )
类名识别服务
核心实现
在实现上述样式命名策略树的过程中，我们产出了一个专用于推测 imgcook 模块布局类名的服务：
( 语义化 SemanticService 结构图 )
semantic-core 提供整体的节点树遍历流程控制，分为前置和后置两个处理过程。
预处理过程会向组件节点追加检索索引，同时会检索组件树中符合条件、需要调用 iconFont 识别服务的图片统一聚合发送请求。后置处理中会对各个语义项处理的结果标记进行排序、应用前缀类名、执行组件索引清理等。
semnatic-text、semantic-pic、semantic-view、semantic-layout 是imgcook 内置的语义算法。分别分析文字、图片、容器和布局相关的信息。
每个语义项执行过程如下：
- 判断是否命中语义策略，未命中则结束此语义执行（语义策略下面会有详解）
- 判断是否会影响父元素，是则检索父元素，追加当前语义项的标记
- 判断是否会影响兄弟元素，是则检索兄弟元素，追加当前语义项的标记
- 判断当前命中的语义策略置信度是否可靠，是则为当前节点追加数据推荐标记
- 最终，一个节点会得到很多不同置信度的语义项标记结果。通过统一筛选，得到此节点最后生效的类名
( 语义项执行流程 )
细节实现
在向各个策略叶子节点的推导过程中，我们会使用最适合的能力实现需求，比如为了解决“鉴别小图标”这个语义判别过程中我们部署了 IconFont 服务来实现，具体流程如下：
- 从 iconfont 网站上获取 iconfont 的图标文件，并转成 png 格式，如下图
- 使用一个自编码器把图片编码到特征空间
- 使用 t-SNE 映射到二维平面上看看效果
- 在特征空间上使用聚类算法将类似的 icon 聚到一起
- 手工剔除质量较差的版本，然后将一个类簇中的命名根据已有名称进行选举
(IconFont 识别服务执行流程 )
iconFont 服务用于解决小图标命名问题，至今仍然在持续优化中。
展望未来
典型应用
imgcook 语义化能力自从方案上线以来已支持了一年多的线上业务。以下是2019 年双 11 的模块仓库中找到的，可验收语义化成果的一个模块：
( 语义识别结果 )
从该模块的还原效果中可见，依次命中了布局逻辑、图片分类、IconFont 分类、翻译、店铺名、样式特征、价格判断等内置策略。大部分节点都有语义项命中，其中识别较为准确且贴近语义的节点占比 60%+。
衍生方向
语义化本质是推测节点特征的过程，在识别准确度没有要求时可以作为 class名使用。对于识别准确度极高的预测结果，我们认为节点和数据也有映射成功的可能性。
因为我们希望 D2C 能推测出节点绑定字段并实现在业务中落地，所以基于语义化的思路，D2C 孵化出了目的性更强、对准确度要求更高的节点数据字段推测服务。
感兴趣的同学可以移步本系列的“字段绑定”文章继续深入了解。
