智能化与低码化在兴盛优选的应用与实践

Hello，大家好，我是文子穰，来自兴盛优选体验技术部，本文主要话题是围绕低码化 & 智能化两个方向的实践与总结。

在进入正文之前，我想我们应该回溯下历史也了解下背景，任何新技术方案和平台兴起的背后都是由于某一些问题的产生从而推进得来的。前端技术发展至今，前辈们通过不断的探索，挖掘出了多种技术方向，涌现出不同的技术方案，我们作为后辈作为受益者，在平日的工作中会通过工程化，视觉化，区块化，微应用化等方案，去赋能于企业，赋能于产线。而面对日益复杂的业务场景，日益剧增的业务迭代以及频繁的重复性结果交付，这造成了团队的人力需求剧增，投入成本巨大等问题，我想这都是大家在现实工作中所面临的共同问题。因此”低代码“这一话题，就从历史的轮子当中再次被提取了出来。当前低代码的表现形式大家对其都褒贬不一，部分人认为它没有实际用处，没法给研发人员通用化提效，反而增加了大量的定制化工作，给其定性为“毒瘤”。而部分人认为它解决了业务线具体的生产需求，是一个有效的生产力工具。无论大家对其如何的评价都不可否定低代码是一个较好的解决方案，每一个人每一件事站在的角度不一样得出的结论也大不相同。在接下来的文章中我会具体的讲解，针对低代码这一话题我不同的看法及其整体布局。

关于低码化方案制定我们从两个部分展开分别是《展现形式》《方案抉择》，通过这两部分我们能够比较清晰的看待低代码以及在日常工作中如何决策平台建设工作。

如上图所示低代码的特征是极具特色和明显的，我们可以用三个维度看出与其他方案不同之处。第一部分为交互模式的改变。第二部分为组件模式的不同，低代码平台中会预先制作好常用组件，预先存留好常规场景，从而来缩短输出工期。这一部分是低代码平台的特色也是其最受争议的模块。在以往的模式内我们有视觉化所提供出来的通用组件库，有区块化提供出来的业务组件和模版物料，常规模式里组件库与区块是高度灵活和抽象的。而低代码平台组件和物料部分被固化，形成先天性的劣势，从而造成灵活性不高拓展性不强等问题，因此它最适合运用在”通用性““重复性”较高的场景。第三部分是数据模式的不同，在低代码中数据是被抽象成配置的，无论是组件的属性还是组件的事件流转，都是通过数据配置化结合配置可视化来进行处理。结合上述三个不同维度的分解，我们不难看出其在某一些方向的优势和劣势，低代码它不可被万能化它不是一个可被业务运用在任何场景之下的通用技术方案，我们应该合理把控合理规划的去建设其核心能力以及平台。

了解完低代码的核心特征后我想多数人对此都会有了一定的客观印象，接下来我们从模式和角色上进行分析。如上图所示，低码模式主要分为四种，“ProCode”“LowCode”“NoCode”“AutoCode”，每一种模式在使用方式上都有所不同，研发难易程度也是从低到高呈现，它们都被应用在不同的场景之下。第二部分我们从使用角色上进行拆解，面对平台不同的使用角色决定了我们对于平台建设上不同的技术架构，在图中我粗略的以三种角色进行概括，其分为“开发人员使用”“无编码能力人员使用”“基于环节式驱动”每一种方式我们所提供的功能及低码模式都不一样。其中开发人员更适合 Pro-Code|Low-Code 的方式，平台需要具备更高的灵活性和组件的插拔式面对多样的业务场景都有很好的承接性。运营人员、产品经理、设计师等角色他们不具备编码能力，对于页面的生产过程不具备一定的了解。所以更适合 No-Code|Auto-Code 的方式, 平台内需要内置大量的场景模块，组件和事件流转方案，在使用的过程中能够被用户更好地理解以及快速的输出产物，不必纠结于细节，能够模版配置化最好。而最难的莫过于环节驱动下的需求，每一个环节使用角色不一样，其呈现出一连一的特征，这时我们就要考虑混合的建设方式，用不同的模式来解决每一个环节的痛点，最终打通整体流程。

对于我们在业务产线中，想要基于低代码方案来布局平台解决问题时，我们最重要的不是关注平台功能本身而是需要决策平台的落地方式。前文中我有分析过目前低代码的整体情况及其展现形式，跟大家说这些也并不是我写这篇文章的初心，而是想通过一步一步的演进从而推导出决策的方法。如上图所陈列的一样“应对不同的场景与角色，使用不同的方案以及方案的下沉深度”。确定使用人群，聚焦业务形态，寻找平台闭环。当我们确立了平台准确目标后，平台建设基本上就有了初步的形态，反之低代码的展现形式及相关布局方式不符合当前业务场景使用时，请勿生搬硬套，反而容易吃力不讨好。有了基本的形态那么接下来我们才需要考虑具体的技术方案，目前市面上有较多的方案可供选择。例如：阿里系的 LowCodeEngine，腾讯系的 TmagicEditor，百度系 Amis 等。这些不乏都是行业里比较成熟的案例，它们经过了企业内部的推敲验证，我们可大胆尝试使用。而面对一些中大型厂商，会有一些独特的场景需求及定制化工作，在拥有合适技术人选以及人力资源投入时，我们可以不使用开源方案，自己制定出符合企业内部特色的低代码技术解决方案。

在我加入兴盛优选体验技术部前，我们团队内已经存在一部分低代码的产品，他们都被运用在不同的业务领域，有大屏可视化的，有中后台搭建的，有营销侧的，有表单类的。无一例外它们都具备一定的业务价值，解决着一定的业务问题。但是每一个平台都有各自的方法论和实现原理。每一个平台有各自不同的视觉呈现以及其不同的交互方式。它们都划分在不同的团队中由不同的人员维护管理。不可否认这确实挺锻炼人的，毕竟会输送出一批了解低代码平台建设的人才。但在同一个企业之中各平台所面对的大多数使用者或许是同一批人，这极大的增加了用户使用的成本以及用户切换平台的连贯性。其次多个平台的底层实现原理都由不同的人维护，每一个平台的底层迭代更新在功能层面也没法更好的进行共享。新来一个搭建需求又是另起炉灶，重复迭代。说白了”轮子不怕多，越多越好“的事实在大多数企业内部也同样存在，甚至整个圈子里也在不断重复建设。

结合上面所阐述的问题以及对整个团队低码产品有了充分了解后，我们开始了相关能力的研发工作，最终形成了一套可多端（移动端 + 中后台 + 大屏）支撑通用性强的低代码引擎，它由四个模块组合而成分别是 《低代码视觉体系的建设》《低代码底层原理库的建设》《通用化低代码开箱即用的建设》《低代码物料协议与物料模版的建设》我为其取名《惊奇引擎 -Marvel》，上图为惊奇引擎整体的架构图，接下来我会依次介绍每一个组成部分。

Dlibrary 为惊奇引擎提供底层能力支撑，它包含八个高度解耦的服务模块，我们将常规低代码平台中需被通用化的功能在此统一封装且每一个模块都具备独立插拔的能力，具体模块如下：

• component-loader：物料加载器，提供物料的接入识别以及转换能力，为低码平台提供源源不断的资产支撑。

• canvas-loader ：画布加载器，其中包含多画布，卡尺，容器自适应，沙箱隔离等功能，为低代码平台提供作业区域的的核心能力支撑。

• draggable-lib：拖拽库，拖拽库中包含了拖拽容器及拖拽元素的组件级封装，并提供自由拖拽模式，排序拖拽模式供不同交互形态使用，还包含元素距离检测，覆盖检测，边界检测，合并成组等常见功能。

• render：渲染器，渲染器是组件 & 自定义设置器 & 页面的核心渲染能力的包装。

• animation-timeline：动画设置器，其基于时间轴的方式配置的动画细节，内置了整个动画编排规则及常规动画库。

• factorys：数据工厂，其内部包含数据源，接口，变量等不同模块的工厂服务，提供各模块的数据创建，存储，提取，更新，监听等操作。

• hotkeys：热键库，我们针对键盘操作提供了一套高度封装的方法，通过简单的参数配置即可对接到低码平台，使其快速拥有快捷操作等功能。

• tools：工具库，其内部封装了在低代码平台建设中常见的工具函数

区域展示-01

画布是低代码平台重交互区域，其作用就不言而喻了，很多人对画布的概念不清晰，甚至很多平台没有画布的概念，从“区域展示 -01”图中可见画布为低代码平台中呈现在那一部分。我们将卡尺、参考线、沙箱隔离等功能融合在了画布组件之中，通过属性进行功能的控制。而整个画布的核心实现原理主要通过控制画布容器的 TransformMatrix 数值从而控制整个区域的移动、缩放、旋转、倾斜。具体如上图所示

拖拽是低代码平台最常见的交互形态，而常见平台内多为单一模式，也就是非自由模式及排序模式。从“区域展示 -01”图中可见拖拽为低代码平台中呈现在那一部分。作为底层引擎我们当然需要符合不同场景的需求，例如大屏可视化搭建、海报搭建依赖于自由拖拽模式，营销活动 h5 搭建、中后台搭建依赖于排序拖拽模式。拖拽核心也主要划分为两个部分拖拽元素主体，拖拽容器主体。具体实现原理如上图所示。

渲染这一话题在低代码平台内分为两种分别是组件的渲染、页面的渲染。上图有分离拆解图供大家可视理解。而惊奇的核心渲染逻辑分为四个步骤

《整合数据》我们基于页面 Schema 来进行组件渲染映射表的生成，形成组件与远程渲染地址的一一映射的数据源，接着在进行数据的清洗，页面中可能会存在重复组件的现象而面对这种情况我们采取由高为先的模式进行存留，避免组件渲染时组件脚本未被按照顺序加载。

《创建渲染层级顺序》首先我们会获取当前承接渲染页面的设备视宽视高，在根据组件的渲染顺序获取组件真实渲染的宽高值，在按照设备视高进行计算按照一个可视版面进行分组，分组数据会默认往后多增加一位。在通过分组数据进行脚本地址字符混合为后期 CDNCombo 方案做准备。

《预加载脚本》从前两个步骤获取到的最终映射表数据我们将会进行脚本的加载和组件实例追加的操作，一个可视版面进行两次操作预先 loader 下一个可视版面资源。

《渲染核心》基于高阶组件的方式通过 schema 中对于组件属性配置的数据进行 props 的获取与绑定，事件的获取与绑定。从而完成整体页面以及组件的渲染。整个过程可能无法通过几段话来概括，但流程和原理大致如此。

关于物料这一层级是很多低代码平台乃至低代码引擎都为之头疼的部分，因为物料资产不够或物料的研发流程复杂而限制低码平台的拓展面的情况数不胜数。为解决这一问题目前市面上最为常见的做法是根据平台性质而内置化丰富的组件物料。好一点的平台或引擎会提供一些物料接入的规则，按照规定的模式进行研发，平台侧提供物料注册函数。而惊奇的做法相对于这些方式而言会更为轻便，接下来我简单阐述下惊奇的原理和过程。如上图所示，惊奇提供了物料接入的可视化操作，使得惊奇引擎搭建出来的低代码平台可以在不变更平台代码的基础上无需平台发版的基础上，即可快速接入单一物料或物料组。

我们可以通过两种方式进行物料输入，第一种是 npm 的对接，你只需提供包名包版本，component-loader 的 node 服务会自动解析这一个 npm 包并分析出此包为单或多的形态从而进行单组件接入流程或组件集接入流程，在服务中我们会创建一个类似真实渲染的环境沙箱从而来获取组件的相关信息例如组件的名称、属性、事件等信息，最终自动生成一份符合惊奇可被接受的物料描述数据集，第二种是 cnd 资源的对接，核心逻辑与 npm 类似。具体每一个核心流程在上图有详细的诺列。除此之外针对物料的生产我们也提供了一套物料脚手架，脚手架中提供了项目的创建打包部署等功能。除此之外惊奇为每一个物料都提供可视化的管理版本能力，每一个组件的渲染都与物料版本，物料配置版本强关联从而避免造成组件更新影响老项目使用等核心问题。

DPro 为惊奇引擎提供上层的能力支撑，目前 DPro 主要分为两个主要部分，分别是一整套低代码的视觉体系规范其中包含低代码平台的视觉规范以及视觉组件。除此之外还提供通过视觉规范所衍生出来的低码细粒度模块化组件，具体情况下面如下。

如上图所示，目前视觉规范中包含了 1000+ 的低码平台常规图标资源、40 多个缺省图、八大模块（接口管理、数据源管理、变量管理、代码编辑器、事件流管理、动作管理、组件物料管理、模版管理）30+ 的常规模块（通用属性设置器，样式设置器，菜单组件等）

我们在脚手架中也提供了初始化低码平台的功能，而 marvel-pro 的包提供了如下图所诺列的相关组件。开发者无需考虑 Dlibrary 的核心实现只需要通过 DPro 提供的模块化组件，像搭积木一样搭建出你所需要的低代码平台，目前惊奇引擎在兴盛内部支撑着会场搭建、中台搭建等场景，我们也在着手基于惊奇引擎提供服务一体化平台，为企业提供更强有力的支撑。

近两年前端智能化方向非常火热各大厂都纷纷投入其中，在接触这一方向之前我们其实也思考过智能化相关落地的场景，它所能带来的实际价值，研究过目前市面上相关的产品其中就有《imgcook》《codefun》《deco》这些平台。现阶段市面上智能化相关的产品大多数都是基于 D2C 这一个场景下衍生出来的。而对于我们团队内部而言 D2C 并不是我们第一层级所需要的能力，如何找到一个恰到合适的落地点，如何用智能化方案赋能前端领域，增强前端建设的多样性，也成了我们探究很久的话题。通过不懈的努力我们最终在团队内部孵化出了第一款相关平台 MarvelDesign。

MarvelDesign 是一款打通设计稿交付，页面自动走查的集成平台，我们通过智能化的手段，帮助前端开发工程师，视觉设计师在工作中简化协作步骤，简化思考，提高输出质量，在前端页面还原阶段，设计验收阶段提供不同的智能辅助能力从而起到降本增效的目的。整个平台由 figma 端的数据接收服务，设计稿解析服务，标注生成服务，自动走查服务组合而成。在整个平台中除了通用的画板标注能力，智能走查能力之外，我们还基于深度学习的方式研发了组件识别模型，图标识别模型等，我们会将这些模型运用在设计稿标注生成阶段，将设计稿中的图层进行识别，来反馈出这一图层的类别，在与常规资产进行一一匹配。下面都是平台的相关截图。

figma端插件

平台侧相关模块

设计稿标注模块图标图像管理模块及项目生成模块

智能走查模块

MD-01

MD-02

如何解析设计稿并生成我们想要的产物呢 ？我们拿 figma 举例，figma 平台本身有第三方插件研发生态提供了丰富的 openapi 供开发者使用。如上图 -MD-01 所示，调用 OpenApi 我们能够获取到整个设计稿画板的原始数据结构其中包含了画板中每一个元素的细节数据。拿到数据就可以进行一些骚操作了，比如说你想基于这些数据的关联关系生成代码或者基于这些数据做标注生成等功能，这就看每一个团队的核心需求了。那么 MD 是如何基于这份数据来进行标注生成的呢？如上图 -MD-02 所示其基本步骤有五个《数据的清洗》《图层的处理》《新结构的生成》《样式的转换》《数据的混淆》我们将 figma 拿到的数据进行一次清洗后得到一个更清晰的结构其中就包含了画板的基础信息，图层的基本信息与图层的属性信息等，接下来进行图层的处理，我们将不可见图层无含义图层数据进行删除（隐藏的图层或没有任何展示效果的图层）在进行叠加图层的处理为叠加图层增加一个父容器图层。处理好数据与关系后，我们就会针对每一个图层进行分析，分析过程大致会经过三个步骤“图标识别”“组件识别”“循环节点识别”，处理好每一个图层的的信息后得到一份 MD 的新数据结构。最后我们可以根据这份新的数据来进行下一阶段的处理如样式转换，代码生成等。

在上部分有讲到关于组件与图标的识别，那么我们是如何处理这块的呢？我们基于深度学习的方式进行组件识别模型与图标识别模型的训练最终得到相对应的权重文件，将其部署到云服务器后在通过接口服务提供相关识别能力支撑。

SD-01

SD-02

关于 AI- 人工智能大家可能都有耳闻，AI 其实包含的东西有很多例如机器学习，深度学习等，它们之间有什么区别呢？如上图 -SD-02 所示它们之间是一种包裹关系 AI > 机器学习 > 深度学习。用通俗易懂一点的方式来介绍一下，机器学习是人提前设定好标签和特征，然后由计算机按照设定好的标签特征去工作。深度学习无需人工设定特征。基于提供的样本数据集自动训练模型计算权重偏量，找到各种数据的特征然后进行工作。那么如果我们想基于深度学习来训练一个自己的组件识别模型那么需要怎么做呢？如上图 SD-01 所示，其整个过程分为 8 个步骤，我们挑一些重要的步骤讲解一下。首先第一步是样本的准备，样本就是我们要提供给算法的训练数据，我们可以通无头浏览器去跑一些站点收集一些组件不同形态的图像，例如文本框的展现形式按钮的展现形式，有了样本后我们就会进行样本打标操作，最后我们要按照比例整理好结构其中包含训练数据集、验证数据集、测试数据集。

有了样本数据我们就需要进入到算法决策以及模型训练等环节，想要完成组件识别这一功能，有两种方式可供选择分别是图像分类，目标检测。如上图所示图像分类又分为强监督细粒度图像分类和弱监督细粒度图像分类。目标检测也分为 One Stage 检测算法和 Two stage 检测算法。MD 采取的是图像分类算法，我们不需要在一张图中检测出该图有哪一些命中目标，只需要一对一的图像识别即可。那么如果你是直接进行设计稿图像的识别那么就需要使用目标检测的方式来进行组件识别，这样可以在设计稿图像中识别出多个命中目标。目前市面上有两个主流框架来进行深度学习和机器学习的研发分别是 TesorFlow&Pytorch，使用这些框架多多少少需要具备一定 python 的研发能力，作为前端来说这会有一定的学习成本，在这里我推荐大家可以了解下阿里开源的《Pipcook》它是一款能让前端工程师更容易上手的框架，处理一些组件识别图标识别等功能还是绰绰有余。

智能走查的应用场景在那里？我想大多数设计师朋友都能体会到，由于每一个前端工程师的能力都有区别那么基于设计稿还原出来的页面质量都有所不同，每一次项目上线之前设计师都会进行页面的设计还原度测试，检测页面还原是否有问题比如说颜色的检查，字体大小字重的检查，间距的检查，宽高的检查等。这是一个没有什么技术含量却非常花费时间精力的一项工作。那么我们基于智能走查的方案能够在页面还原度验收环节降低非常多的人力成本。那么具体实现原理如下图所示，整个自动走查的原理是基于图像对比进行元素匹配，在基于真实 dom 元素样式表和与之匹配的设计稿元素标注样式表进行数据层面上的对比最终形成一份差异映射表。其中分为五个步骤《获取页面可视节点》《生成节点快照》《节点与图层匹配》《计算匹配数据的样式表差异》这一整个步骤中最为重要和有难度的的就是“节点匹配”这一个环节。

针对”节点匹配“我们可以通过图像相似度对比的方式来进行处理其分为两个步骤《图像的指纹提取》《图像指纹的比对》如上图所示方案有很多不做一一讲解，以均值哈希算法作为例子。一张图片就是一个二维信息，它包含了不同频率的成分亮度小的为低频它描述大范围信息，亮度变化大的就是高频区域他描述具体细节。高频可以提供图像的详细信息，低频提供整体图像框架，均值哈希算法就是利用图像的低频信息进行处理。我们基于下图 ZC-0 的步骤可以获取到两张图像的指纹，在基于下图 ZC-1 中的方式的得到两个指纹的相似度值，最终可以得出可视节点与设计稿节点的匹配度。在 MD 中我们采取的是混合提取与混合比对的模式来提高比对的准确度。整个过程包含了初筛，排序，复筛这三个过程具体如下图 ZC-2，最终我们可以通过上述手段输出设计稿自动走查的完成能力。

ZC-0

ZC-1

ZC-2

目前智能化与低码化在我们团队内部都有很好的落地场景以及产品输出，虽然每一个产品都会存在相关问题，但产品的完善是一步一步来的。未来我们也会在这两个方向不断输出更多有价值的功能赋能于企业。如果你也面临着一些相同问题或正在这两个方向做相关产品布局，希望这一篇文章讲述的过程和思路能给你带来一些启发。