编者按：本文是蚂蚁集团前端工程师念响在 SEE Conf 2022 的演讲内容，包括演讲视频及文字内容，欢迎享用。

大家下午好，我是来自蚂蚁集团 RichLab 技术团队的前端工程师 - 徐奇昊，花名念响，在互联网上你也可以通过 Maqic 这个 id 找到我。今天我想和大家一起聊聊 Bakery 产品演示平台在蚂蚁内部的探索与实践。

分享大纲今天的分享主要包含以下三个部分——

产品演示平台是什么，为我们解决了什么问题？
怎样做一款产品演示平台，都有哪些通用的设计和实现思路？
最后同大家分享下后续我们的一些计划。

为什么要做产品演示平台

在介绍什么是产品产品平台前，让我来大家了解下支付宝内部一个 H5 产品研发的整个流程——

支付宝 H5 产品研发流存在的问题

相信类似的研发流直播间里很多小伙伴都经历过，容器、环境、页面复杂度本身等各种因素带来的开发调试难、视觉验收成本高、兼容测试难、埋点数据分析不直观的问题相信大家或多或少都有感触。这些问题最终会带来导致产品交付不顺畅、出现偏差，从而影响用户体验和转化率。所以我们就在想，在周而复始的产品迭代演进过程中，如何让不同岗位的参与者实时快速低成本的对焦产品交付的中间产物，提升产品交付质量？

我们的解法

为了解决上述问题，我们自研了「Bakery 一站式产品演示平台」来助力我们在各类前端应用迭代演进，提升产品交付质量。平台核心模块由 Bakery UI - 本地研发套件和 Bakery Web - 中心化演示平台两部分构成，在整个研发协作流中为各个岗位参与者提供了服务。下面，我们一起来看下，如何设计并实现这样一款产品演示平台的，而平台本身又给我们带来了怎样的能力——

怎样做一款产品演示平台

我们先从前端的视角来对「产品演示」进行一个拆解——

产品演示的构成

可以看到，产品演示主要由这三个部分构成——

接口数据：如何管理接口、jsapi 调用的数据，使其能够贯穿整个研发流，从而让产品演示的创建者低成本的创建演示实例；
容器能力：如何在浏览器中模拟 hybrid、小程序容器，使得使用者低成本的查看产品演示实例；
静态资源：演示依赖的页面、css、js 等静态资源；

因为静态资源这块和每个公司的研发部署平台强相关，我今天就不展开介绍了，我们主要来看下「接口数据管理」和「容器能力的模拟」这两块分别怎么解决？

使用 Bakery UI 管理 MOCK 数据

首先来看，mock 数据的管理我们使用了自研了 Bakery UI 这样一款本地研发工具，相较于业界其他 mock 工具，它具备以下几个优势——

提供了可视化的数据录入、场景切换的能力
支持不同的接口以业务语义进行场景组聚合，让使用者轻松完成多种业务 case 的切换和调试
轻量、去中心化的实现，mock 资产与项目绑定，git 的版本控制能力使其天然支持多人协作，沉淀的标准化 mock 数据资产可以在多种研发场景下使用，例如：组件的可视化搭投预览

这个套件是怎么实现的，我们一起来看下——

技术实现

可以看到，我们用文件树的方式去存储了 mock 资产，使用 node - fs 模块对外暴露 sdk 用于接口和场景和增删改查，利用开源框架 egg 和 umi 来实现了一个轻量的 mock server，结合 mock 代理脚本（mock-script）提供的容器模拟能力，可以为各类前端框架提供 mock 资产管理、rpc 接口调试等能力。解决了接口数据的问题，接下来我们一起来看看容器模拟是怎么做的——容器模拟
以 Hybrid 容器模拟为例，我们一起来看看 bakery 代理脚本（bakery-mock.js）是如何将你的业务逻辑进行重写的。可以看到 H5 业务逻辑执行触发后，其实是通 JSBridge 来唤起容器能力的，我们只需要模拟、拦截 JSBridge 的能力即可完成容器能力的模拟，在完成环境监测、UA 替换、沙盒初始化后，我们可以将拦截到的数据类调用重定向到 mock 数据源，交互类的调用降级到类似 antd-mobile 这种 UI 库，从而完成整个容器能力的拦截与代理。ok，在完成接口数据管理和容器模拟之后，其实我们已经具备创建产品演示的能力了，那么基于产品演示我们又可以做哪些事情呢？

基于产品演示能做哪些事

我将主要介绍三个我们基于产品演示做的提效点，这些点都与我们日常研发息息相关。

视觉验收提效

首先，我们来看视觉验收这个事情——

传统的视觉验收流程

可以看到，传统的视觉验收需要前端工程师阿强和设计师阿珍之间来来回回、反反复复的同步沟通，更有可能因为页面本身的复杂度、容器限制、环境账号限制导致很多产品细节无法通过截图和录屏完整的表现出来，最终带来验收效率低，沟通成本高、验收结果不准确的问题。

基于产品演示的视觉验收流程

那么基于产品演示的能力，我们可以改善这个重复、机械的验收流程么？答案是肯定的。在这个工作流中，阿强只需要在配置各个业务 case 的演示场景后，上传 sketch 视觉稿，发起验收任务，借助蒙娜丽莎的能力，Bakery 平台会自动完成视觉稿的解析和验收匹配度的计算，而且在匹配度不满足要求时，还会在返回的验收报告中标注样式改善意见，开发者只需要按照验收报告不断调整样式直到满足匹配度即可。在与设计师愉快的完成视觉验收后，我们继续来看下个 case，可视化的埋点资产服务——

埋点资产服务

在这里个例子中，当 BI（数据分析师）在准备分析页面中按钮的点击转化率时，他需要先根据点位的描述找到点位值（a1.b2.c3.d4），然后在埋点数据表找到这个点位，结合多份数据在数据报表中给出转化率。细心的同学应该已经发现这个流程中暴露了不少问题，例如：

根据文字描述去找点位值，可能会找错或者压根找不到
最终输出的转化率数据不直观，多了一次文字描述等于多了一层理解成本

那么 Bakery 在埋点资产服务中，可以做哪些事来改善这些问题？Bakery 的埋点资产服务在埋点创建阶段提供了可视化新建埋点的能力，用户在埋点创建阶段就完成了点位与界面元素的关系绑定，而在埋点上报过程中，我们又利用「容器模拟」章节提到的 jsapi 拦截能力拦截了点击、曝光事件的拦截，这样即使对于一些已存在的埋点（不是通过可视化创建的埋点）也能建立与界面元素的关系。最后，通过对接埋点数据服务，我们就完整的建立了界面元素与点位、界面元素与埋点数据的映射关系，省去不必要的埋点文字描述，让我们的埋点数据更加直观，展示也更加生动。那么当我们在一次次应用-迭代过程中，累计了一定数量的演示资产后，我们自然会想，能不能用这些演示资产做一些文章？

产品大图能力

当然可以，下面来看产品大图。利用众多可交互的产品演示实例，我们可以完整的展示页面不同的状态；在配套页面编排编辑器，就可以串联得到完整业务流程；再加上迭代的回溯，我们甚至能表现一个产品、页面是如何随着时间的推移一步步演化的，看到这个产品的前世今生。产品大图的能力，无论是对于新人了解一款产品的功能，还是老人思考产品后续的演进方向，都提供了非常重要的参考价值。

整体回顾

介绍完了我们基于产品演示做的一些业务场景上的实践，我们来一起回顾下 19 年至今 Bakery 平台的演化过程—— 首先，我们尝试解决的是开发者的问题，自研的 Bakery UI 本地研发套件为我们解决了容器调试难、环境不稳定的同时，也给出了产品演示两个必备要素——数据管理和容器模拟的解决方案；我们就在思考，能否把产品演示能力赋能给非研发协作者，让他们在协作的过程中也能够快速看到产品的交付产物。于是乎，中心化的 Bakery Web 产品演示平台就诞生了，他围绕了提升产品研发协作的效能做了一些工作，比如视觉验收、兼容测试、埋点资产，并将这些能力以 sdk 和接口的方式开放给蚂蚁内部的其他中台使用，提升整个内部中台的产品体验。

未来计划做的一些事

最后，和大家简单分享下我们后面的一些计划—— 未来一年我们主要会做三个事情——

第一，适配更多应用类型，包括但不限于友商的小程序、普通的 H5 应用，增强演示能力
第二，探索更多使用场景，提升产品演示价值，比如说，基于演示的产品手册可以在支付宝产品上线前就给用户一个直观生动的产品使用说明；舆情回放则可以让产品演示在用户数据的驱动下，第一时间回放舆情问题现场，帮助开发测试定位问题；
最后一点，回馈开源社区，从前面的介绍大家也可以看到 Bakery 的实现上其实使用了不少的开源工具和类库，我们也计划将 mock 数据管理的方案和产品演示能力通过开源的方式回馈给社区，同时也借助社区的力量让产品演示走的更远！