新活动平台建设历程与架构演进

01 前言

历时近两年的重新设计和迭代重构，用户技术中心的新活动平台建设bilibili活动中台终于落地完成！并迎来了里程碑时刻 —— 接过新老迭代的历史交接棒，从内到外、从开发到搭建实现全面升级，开启了活动生产工业化新时代：

界面交互层面：在界面和交互上推倒重来，实现了简洁美观、符合直觉、简单易用的现代化升级；
业务功能层面：在功能上去繁就简，聚焦核心业务，对活动搭建和业务开发两条主场景进行重新思考和设计，简化流程并提高了整体效率和体验；
系统架构层面：模块解耦提升扩展性的同时，围绕业务诉求进行迭代演进，通过技术驱动来赋能业务，提高业务边界和想像力，助力活动业务跑得更好更快；
开发生态层面：通过开发工具链的升级，把平台开放能力提升到了一个新的高度，为业务开发者创造了更加友好的开发环境和平台生态。

本文将从新活动平台（以下简称为活动平台）的建设历程展开，阐述我们在整个开发过程中的设计理念、建设规划和架构思考。不同建设阶段中面临的挑战，以及活动平台团队是如何解决的。希望能对你有点帮助。

开始之前，先来简单认识一下活动平台：

活动平台最核心的页面：制作页

02 活动平台是什么

活动平台本质上是一个低代码平台。低代码平台是一种成熟的业务应用开发方案，这里不再赘述。除了低代码的标签外，活动平台也是一个 CMS（Content Management System）系统，除了最核心的活动业务，还能广泛应用在其它各种页面生产场景。因此从业务抽象的角度来总结的话，可以从服务对象和业务模式两方面来概括活动平台：

2.1 服务对象

活动平台服务对象包括运营、用户、研发三类，其中：

运营：是平台的 B 端用户，负责生产活动页面；
用户：是平台的 C 端用户，负责消费活动页面；
研发：包括平台研发+业务研发

平台研发：平台系统维护者，负责平台迭代建设、开发通用组件、维护组件生态和数据源生态，并对外提供开发工具；
业务研发：负责通过平台提供的开发工具来开发业务组件，供运营消费组件来生产活动页面

2.2 业务模式

活动平台业务模式包括 No Code、Low Code、Pro Code 三种模式，其中：

No Code 模式：服务于全搭建的业务场景 —— 页面搭建配置过程由运营完全负责，无需研发介入。研发在平台上发布可复用的业务组件，运营基于业务组件生产各种不同的活动页面。基于丰富的组件生态，可以覆盖 > 99% 业务场景。
Low Code 模式：服务于半搭建半开发的业务场景 —— 比如一个活动页面里 90% 部分可以基于平台搭建，剩下的 10% 没有对应的平台组件，同时也不具备可复用价值。那么在运营搭建好页面框架的基础上，研发介入生产一次性的定制功能代码块组件并发布到平台，然后交由运营操作组装，与页面进行有机结合，实现完整的页面功能。大概覆盖 < 1% 业务场景。
Pro Code 模式：服务于少数需要全定制开发的业务场景 —— 比如个别大型活动，需要使用动画框架、定制模板能力或者定制渲染器。那么开发者可以通过平台开发工具，定制开发页面后，通过平台来发布和管理页面。同时如果页面有部分模块是可以复用平台组件的，那么可以基于平台的片段加载器能力，来直接复用运营搭建的页面片段，提高开发效率。

三类服务对象和三种业务模式的关系示意图

03.背景和目标

3.1 项目背景

为什么要建设活动平台，主要有两点原因：

1. 环境原因：在公司提效的大背景下，需要整合统一各部门的活动搭建能力，比如活动业务的 Flash 平台、Native 平台、直播业务的云雀平台。通过横向对比各平台的技术能力现状及业务覆盖情况，最终选择基于 Flash 平台进行迭代升级：

2. 平台原因：Flash 平台自上线运行多年以来，一直都是通过技术自驱进行迭代，虽然功能强大且生态丰富，但由于长期缺少整体设计、架构优化和产品化的规划打磨，因此界面和交互较为陈旧、核心功能重技术轻体验、架构扩展性差跟不上时代变化、整体活动搭建和开发体验和效率都较差，急需进行改造升级。

3.2 面临挑战

活动平台是由多套服务组成的复杂系统，涉及业务广泛，想要对其进行从内到外的整体改造升级，是一个巨大的挑战。

1）内部挑战

从长期的用户使用反馈和平台开发视角来看，主要包括几个方面的问题：

1. 平台体验方面：

a. 制作页问题：功能布局不合理、图层拖拽体验差，无法跨层级拖拽、组件列表管理方式不直观... 等等；

b. 画布问题：部分组件无法预览、容器无法多级嵌套、搭建过程无法全真预览体验较差... 等等；

c. 数据源问题：数据源割裂分散、数据源配置项繁冗重复、低频的高级功能导致使用复杂度上升... 等等；

d. 组件问题：没有平台级的弹窗组件、数据源组件使用成本高、组件重复且质量参差不齐... 等等。

2. 架构设计方面：

a. 整体架构问题：历史包袱重，核心模块耦合严重，牵一发动全身，无法进行独立测试，功能扩展性差；

b. 渲染器问题：B 端和 C 端使用两套渲染器，无法从根本上解决画布渲染下和页面预览下可能出现的组件表现不一致问题；

c. 模块设计问题：画布、图层、表单等核心模块设计不合理，使得开发需要模块间联动的复杂业务组件变得困难甚至不可行（比如答题、集卡组件）；

d. 拖拽能力问题：组件列表和图层树采用两套拖拽实现方案，功能和体验割裂，且三方库的拖拽能力越来越难以满足快速发展的业务需求；

e. 开发环境问题：开发模式和搭建模式使用两套不同的可视化方案，容易出现组件开发和搭建环境下渲染表现不一致；加上无法实时预览、开发工具碎片化等问题，导致整体开发体验较差

3. 存量业务方面：平台维护组件数量多达 330+ 个，如何低成本地进行新架构的快速适配和迁移；

2）外部挑战

活动平台目前接入垂类业务技术团队 8 个（直播、漫画、电商、OGV、猫耳、商业、星辰、大会员），垂类业务方开发组件 230+ 个，运营使用团队 20+ 个，日均支持 35+ 个活动。

1. 涉及的业务范围广而多，如何在不影响业务正常运转的情况下，对平台进行渐进式的改造重构；

2. 如何最小化业务方的技术迁移成本，同时保证迁移效果接近无损，需要谨慎设计和合理规划。

3.3 建设目标

我们基于平台开发经验和业务现状，结合对未来的规划，进行全面审视和重新思考后，新活动平台明确了几个建设目标：

1. 解决所有用户反馈的使用问题，打造体验一流、更具生产力的一站式活动页面可视化搭建系统；

2. 以体验和效率为目标，重新设计 No Code、Low Code、Pro Code 三种业务模式，更好地服务于运营、用户和研发；

3. 系统架构设计在满足中短期规划的同时，保留足够的灵活度和拓展性，为长期业务发展做一定的准备。

为了保证能顺利推进完成业务和技术上的双重目标，需要制定一套行之有效的方法论来支撑和指导。

建设理念：业务优先，技术驱动

活动部门做为职能部门，保障业务是我们的基本生命线；同时做为技术团队，技术驱动是第一生产力。技术自驱也是我们团队一直以来的行事风格，Flash 平台建设如此，新活动平台建设也是如此。

执行策略：短线技术优化，保障业务开展；长线技术升级，助力业务增长

通过短期的技术优化，来确保活动业务能够顺利交付。同时，我们着眼长远，通过技术迭代不断提升工程能力和效率。在这个过程中，技术不仅支持业务发展，还能推动业务创新，优化活动形式和效果，让活动越办越好，最终实现良性循环。

基于这个理念和策略，活动平台整体建设规划了三个阶段，来逐步推进落地。

04.建设历程

以半年为周期，我们规划了两个时期三个阶段的推进节奏：

短线技术优化期，目标是保障业务开展

1.活动平台一阶段：

关键词：界面交互重构，用户体验升级。
业务目标：重新设计 No Code 模式的搭建流程，集中解决活动页面搭建问题，提高运营使用效率和体验。

升级技术升级期，目标是助力业务增长

2.活动平台二阶段：

关键词：平台架构升级，组件生态建设。
业务目标：通过长线渐进式技术升级，解决整体架构性问题，并完成 No Code 模式底层重构，开始赋能业务。

3.活动平台三阶段：

关键词：开放能力补完，C端性能优化。
业务目标：长线技术规划图谱补全，基于新架构重新设计 Low Code 和 Pro Code 模式，助力业务跑得更好。

4.1 一阶段

运营是活动平台生产端的主要用户，平均每天花费超过 4h 时间用于搭建活动页面，由于前面提到的包括制作页、画布、数据源、组件在内的各种问题，使得运营一直以来在使用活动平时都要忍受相对糟糕的的体验和低下的效率。

因此这阶段的主要目标，是在不涉及系统底层架构大改的基础上，通过局部模块的重新设计和调优，来重塑 No Code 模式的搭建流程，集中解决活动页面搭建问题，在保障业务正常开展的同时，短期内快速提高运营整体使用效率和体验。包括：

提供更现代化的界面和交互，产品化打磨流程和细节；
解决大部分痛点体验问题，从创建到搭建到管理，从数据源到组件全流程覆盖；
提高整体活动页搭建效率，提高业务产出。

1）技术架构设计

先来快速了解下平台整体系统架构组成：

eva 服务：活动平台前台应用。运营主要使用的服务，承载了活动页面的全生命周期（创建、搭建、发布、分析、管理），包括 6 大模块（活动列表、制作页、活动效果、功能数据、权限控制、辅助工具）和 2 个生态（组件生态、数据源）。其中制作页是最核心的模块，也是运营使用最高频的功能，主要由画布、图层树、属性表单、组件列表四部分组成。
eva-server 服务：活动平台 node 服务。主要负责预览/线上页面的 HTML 构建、基础 SSR 服务、页面部署上线，以及提供平台内部使用的接口能力。
page-service 服务：活动平台页面服务。主要负责页面分发，配合 SLB（Server Load Balancing - 服务器负载均衡）和 BFS（bilibili file storage - B站文件存储服务）能力来实现轻量级的路由管理，以及通过内存化缓存来提升服务稳定性，同时还支持了服务多活和 SLB 降级。
page 产物：用户最终消费的静态页面。

这阶段的架构设计，我们在保持整体框架不变的基础上，对 No Code 模式流程里涉及的功能模块都进行了优化（白底的模块，15+），并对几个重点模块做了重新设计（黄底的模块，5+），包括最核心的制作页模块改造和一体化数据源改造。

2）重点建设案例

由于涉及优化的模块太多太广，篇幅原因无法一一展开，这里我挑两个重点案例来具体阐述。

a. 画布改造

画布改造是为了解决一直被诟病的组件预览问题，我们通过新的技术方案来实现所有组件的实时全真预览能力。详细对比了 component 方案和 iframe 两种技术方案：

考虑到体验和效果优先，为了保证运营在页面搭建过程中能实时便捷地预览组件配置效果，最终选择了 iframe 方案。但该方案存在跨页面拖拽的交互问题，如何解决呢？

经过探索和实践，我们采用了在画布上引入 previewWarp 中间层的方式来解决 iframe 的跨页面拖拽问题。具体方案为：

1. previewWarp 以透明浮层的方式覆盖在画布的 iframe 容器上方，默认为隐藏状态；

2. 从组件列表拖拽组件进画布时，previewWarp 浮层显示并且作为 Drop 的目标区域，实现画布的拖拽交互；

3. 拖拽完成后 previewWarp 自动隐藏，避免影响画布本身的交互操作；

4. 同时通过 Message 通信通知 iframe 页面添加组件到图层树，并触发重新渲染画布，达到实时预览的效果。

previewWrap 工作流程示意

b. 数据源改造

数据源改造是为了解决另一个长期被诟病的问题 —— 活动玩法组件配置太复杂、配置难、易配错。我们通过重新设计整个配置链路，提供一站式的配置面板来降低运营使用数据源的心智负担，以及减少线上问题的发生。

采用的技术方案，简要来说是：动态维护一个表单栈 stackForm，存储当前层的 callerId、data 等数据，层级增加时 push，层级减少时 pop，并检查当 returnId = callerId 时，触发上一层的回调，返回当前层的配置数据。最后携带数据源 ID 和数据返回到入口处，交由组件自行处理信息回填等操作。

一体化数据源使用示意

数据源配置入口与数据源组件配置表单直接绑定，让运营在使用上一气呵成，省去了来回跳转的麻烦。因此与一体化数据源面板一起重新设计的，还有首批数据源组件：任务组件、抽奖组件、征稿组件。不仅在组件功能和组件表单上做了对应的升级联动，还在数据源表单项上进行了重新思考，保留最核心的配置项，合理删减低频功能，下调高级功能的显示优先级，为运营进一步减赋提效。

流程和功能简化后，对降低配置难度和提高配置效率有着显著的效果：

举一个例子：运营配置一个完成任务获得抽奖机会的活动：

经过对上线后的数据分析统计，一体化数据源改造使得由于配置出错导致的线上问题减少了 30%+！

3）阶段建设成果

这阶段完成了一系列模块的优化项，覆盖了 No Code 搭建流程的方方页面：

1. 制作页优化：全新设计的制作页面、升级图层树，优化拖拽体验、支持跨层级拖拽组件、重新设计表单控件、升级组件列表…... 等等；

2. 画布优化：iframe 画布方案、重新设计通信方案、渲染器升级，支持容器多级嵌套... 等等；

3. 数据源优化：一体化数据源面板方案、重新设计各类数据源配置项、统一活动概念... 等等；

4. 组件优化：新增平台级的弹窗、标签卡组件、任务、抽奖、征稿等多个数据源组件一体化改造、容器、标签卡等基础组件优化... 等等。

兼具体验和效率的新版制作页

同时也在业务上取得了可观的成果，并多次收到运营使用上的的正面反馈！

解决了 80% 的体验和效率问题，平均搭建耗时 3.56h，征稿类活动搭建耗时 3.89h，提效 20%+；
新搭建流程覆盖了 42% 选题会活动；
简化了征稿活动流程，提效 34%。

4.2 二阶段

一阶段通过技术优化手段，解决了 No Code 模式下 80% 的体验和效率问题，剩下的 20% 由于架构设计问题难以根治。包括前面章节提到的：

B 端和 C 端使用两套渲染器，无法从根本上解决画布渲染下和页面预览下可能出现的组件表现不一致问题；
画布、图层、表单等核心模块设计不合理，使得开发需要模块间联动的复杂业务组件变得困难甚至不可行；
组件列表和图层树采用两套拖拽实现方案，功能和体验割裂，且三方库的拖拽能力越来越难以满足快速发展的业务需求；
开发模式和搭建模式使用两套不同的可视化方案，容易出现组件开发环境下和搭建环境下渲染表现不一致。

同时，一阶段的建设成果已经能够满足短期业务需求的正常开展，给了技术喘息和规划的机会。因此从这阶段开始，正式启动了活动平台横跨两个半年周期的渐进式长线技术升级期。

1）技术架构设计

这阶段我们在架构层面做了一次比较大的调整，基于B站的活动业务特点升级了整体技术架构。同时我们也调研了一些业界流行低代码系统的设计，比如百度的低代码前端框架（AMIS）和阿里的低代码引擎（LowCodeEngine），虽然他们都有各自非常优秀的设计理念和实践场景，但对于B站的活动业务来说，也都存在比较明显的水土不服问题，比如 AMIS 无法满足个性化复杂业务组件的定制需求、LowCodeEngine 无法很好地支持除了 React 框架以外的组件，难以兼容平台的组件生态（React、Vue、Vanilla），等等。

因此我们在整体自研的基础上，局部模块借鉴了他们的优秀设计实践，比如在页面结构和组件描述上采用了类似于 AMIS 的 JSON Schema 方案；在制作页的核心模块设计上与 LowCodeEngine 方案有异曲同工之妙，功能解耦、可独立运行、可灵活扩展和配置。由于篇幅限制，细节这里不详细展开。

整体设计目标致力于解决当下架构问题，同时保留一定的灵活性和拓展能力，以满足未来几年的业务发展：

1. 制作页架构升级，重新设计数据模型，并解耦出 4 大模块，用于组装新的制作页面板，各模块可以独立扩展或替换；

2. 统一 B/C 两端渲染器，保证所有组件在画布渲染和预览/线上渲染场景下表现完全一致；

3. 重新设计实现图层树、属性表单、组件列表模块。摆脱三方依赖，实现功能完全自定义；

4. 重新设计新开发工具 eva-cli，满足 No Code 模式的组件开发流程，并在未来集成 Low Code 和 Pro Code 模式；eva-cli 开发面板采用与制作页同构化的技术方案，保证一致的功能和体验。

并补齐了一些配套能力建设：

1. 组件转换器，用于桥接新老架构的数据模型，辅助业务开发迁移组件到新架构；

2. 上线新组件中心，与 eva-cli 深度集成，组件开发流程工程化；

3. 上线活动模板功能；

4. 新增集卡、答题、押注等多种数据源组件玩法。

2）重点建设案例

该阶段是三个阶段中最重要的一步，这里我多挑几个实践展开说说。

a. 数据模型重构

制作页四大核心模块解耦的基础，依赖一套全新的数据模型，用于定义模块自身的数据结构，以及规范和约束模块间的通信和 API 能力。

经过重新梳理，我们把整个制作页的数据描述定义为三类：

ComponentData 组件数据：定义组件的完整数据
ComponentInfo 组件信息：描述组件的基础必要信息

BaseInfo 基础信息：描述组件名、分类、版本号、支持平台、缩略图等信息。
PropInfo 表单信息：描述组件在属性表单面板里有哪些配置项，对应什么控件。
SlotInfo 插槽信息：描述组件在图层树里有几个插槽，分别是什么。

Assets 组件资源：组件打包后的 js 和 css 产物地址。
LayerControl 图层控制器：组件与图层树模块联动的描述文件，用于注册一系列图层勾子的监听函数，在图层树发生变化时，通过调用 LayerAPI 来实现一些联动逻辑。
FormControl 表单控制器：组件与属性表单模块联动的描述文件，用于注册一系列表单勾子的监听函数，在属性表单内容发生变化时，通过调用 FormAPI 来实现一些联动逻辑。

LayerData 图层数据：定义图层的完整数据。

ComponentProps 图层属性信息：图层的表单配置数据，即组件的状态数据。
ComponentSlotData 图层嵌套关系：图层子节点信息，用于描述图层嵌套关系。

ApiData 接口数据：组件请求服务端接口拿到的业务数据。

四大模块分别实现了各自的渲染函数，图层树和属性表单模块还定义了 API 能力，用于和组件进行联动。然后通过组件数据和图层数据的串联组织，建立起整个制作页的数据模型：

三类数据 + 四大模块 = 制作页数据模型

组件转换器

新的数据模型必然会带来破坏性变更，无法向下兼容旧的组件数据结构。如何批量快速迁移组件，减少业务方不必要的理解成本，则需要借助组件转换器来实现。通过详尽的字段关系映射和兜底逻辑处理，我们提供了一个近乎无损的 woodman 组件转换器，完成了超过 50+ 组件的转换工作。

woodman 组件转换器原理示意

b. 渲染器重构

想要从根本上解决组件渲染在画布环境和预览/线上环境不一致的问题，办法只有一个：统一 B/C 两端的渲染器。并且画布已经从 component 模式改造成 iframe 模式，抹去了 B/C 两端最大的环境差异。接下来的目标很明确，就是如何设计一个符合业务需求的、理想的统一渲染器。

我们基于活动业务 B 端和 C 端场景的特点，结合以往几年平台实践下来的经验沉淀，设计了一套 5 层结构的页面渲染框架，具体拆解为：

第一层 - 核心渲染器 eva-render：支持 3 类框架（React、Vue、Vanilla）、6 类组件（页面组件、环境组件、容器组件、业务组件、拖拽响应组件，以及未来拓展支持的代码块组件）渲染的基础渲染器，负责所有组件渲染。内部封装成图层渲染器 LayerRenderer，直接供 B 端场景使用；
第二层 - 通用运行时 runtime：基于核心渲染器的封装，包含各种数据注入逻辑，并结合后面几层的包装，服务于 C 端场景；
第三层 - HTML 模板 template：C 端页面模板，runtime 载体，用于配置页面基础能力，包括互跳、埋点上报等；
第四层 - Node 服务 eva-server：基于模板构建 C 端环境 HTML 内容，通过基础 SSR 在 window 上挂载 runtime 需要的一切数据。后续还会支持页面框架预渲染能力；
第五层 - 业务场景：包括 B 端制作页（制作页画布、开发面板）和 C 端线上页面（预览 HTML、线上 HTML）。

渲染逻辑分层

通过对页面渲染逻辑的分层设计和应用，取得了以下成果：

1. 实现了活动平台渲染器的统一，从根本上解决了 B/C 两端渲染不一致的问题；

2. 渲染器模块完全解耦，可脱离制作页环境独立使用，为后面组装 eva-cli 开发面板和实现页面片段加载器打好基础；

3. 核心渲染器可供业务方独立使用，自行构建 HTML，满足定制化渲染需求，比如直播的挂件场景；

4. 业务方也可基于核心渲染器封装自己的业务渲染器，搭配自闭环的业务组件，实现一些微前端之类的轻量级使用场景。

c. 图层模块重构

现有的图层模块功能和拖拽能力是基于 antd tree 做的定制开发。虽然一阶段我们通过技术优化解决了大部分图层体验问题，但依然有几个遗留问题是现有术选型无法解决的，包括：

antd tree 自定义能力较弱，组件拖拽方式不够直观，且精准度不佳导致失误率较高，在图层操作这类高频使用场景上明显影响效率；
antd tree 组件灵活度不够，无法满足图层隐藏、多插槽图层等高级功能，阻碍组件开发的灵活度。

同时平台在组件列表模块里采用了另一套拖拽解决方案：reactDnD。与 antd tree 的拖拽体验对比下来，reactDnD 更轻量灵活，也更适合业务定制，因此我们决定重新基于此打造图层模块：

1. 抛弃 antd tree 方案，基于 reactDnD 重新实现理想的图层拖拽交互体验：直观易用，灵活性度，拓展性强；

2. 抛弃传统树结构，采用更轻量的扁平树结构，编写更高效的 API，提高状态数据变更效率，保证拖拽过程实时反馈的最佳体验；

3. 重新设计 30+ LayerAPI，支持多插槽、图层勾子、图层隐藏等核心能力；API 全部纯函数设计，方便单测接入；

4. 未来支持更多定制化的能力拓展，技术上不受限，为组件玩法创造更多可能性。

数据结构转换模型 & LayerAPI 全貌 & 图层模块能力全貌

新版图层模块完成上线后，可以说从底层重塑了活动平台的拖拽体验：

1. 实现了平台拖拽体验的升级和统一，彻底解决运营反馈的图层拖拽不跟手、不精准的问题；

2. 图层模块完全解耦，依然可供业务方独立使用，在满足数据结构规范的前提下满足定制化场景；

3. 为后续实现骨架屏、海报布局等更多拖拽场景打好基础。

d. 开发工具重构

新架构下的数据模型和制作页核心模块准备就绪之后，接下来我们要考虑的问题自然就是：如何在新架构下为 No Code 模式开发业务组件？

还记得前面的组件转换器吗，它除了用来迁移存量组件外，也是作为一种过渡方案存在，通过「woodman-cli + 转换器」的组合，可以用来应急满足新组件的开发，但问题也比较明显：

1. woodman-cli 存在无法全真预览，无法使用新平台的核心能力；

2. 组件开发链路工程化程度低，人工依赖性强。

是时候打造一套全新的组件开发工具了！前期花费大量心血设计的新架构也能在此该发挥出巨大优势：通过 4 大模块组装出新的开发工具面板，抹平和制作页的环境差异，提供能力完整、体验一致的开发体验。

有了核心的开发面板，再结合一些工程化配套能力的建设，我们打造的新开发工具 eva-cli 也就呼之而出了：

1. 提供 No Code 模式下的配置工程化指令，覆盖业务组件开发全流程；

2. 建设新组件中心，与工具链深度整合，接入审核流程，实现组件【开发-使用-管理】的一栈式解决方案。

eva-cli 架构：No Code 模式 & 组件开发流程前后对比

3）阶段建设成果

活动平台新架构一阶段的落地，顺利解决了 No Code 模式下剩余的 20% 系统性难题，为运营和业务开发带来了体验质的提升：

B/C 两端渲染表现一致，保证低代码平台所见即所得核心体验的可靠稳定；
搭建/开发框架一致，极大提高开发体验、减少环境差异带来的开发问题；
图层、画布架构升级，支持标签卡+任务、弹窗+抽奖等复杂组合的实时预览和交互操作；
新开发工具 eva-cli 完成了 No Code 模式下组件开发能力的闭环。

同时也在业务上取得了新的突破，帮助业务取得了一定的增长：

友好的开放能力快速建立起组件生态和业务多样性：

截至目前已接入 10 条垂类业务线：直播、大会员、赛事、猫耳、创平、商业、OGV、漫画、版权音乐、课堂；
平台组件生态：57 个 H5 组件、48 个 PC 组件；
垂类组件生态：153 个 H5 组件、90 个 PC 组件；

平台整体技术升级，使得像集卡组件、答题圈子这类交互和配置复杂度很高的整合营销玩法组件化落地成为可能；

复杂整合营销玩法组件 & 工程化开发依赖的平台能力

4.3 三阶段

活动平台经过前面两个阶段建设下来，已经完全重构了整个 No Code 模式，包括运营搭建页面流程和业务开发生产组件流程。我们长线规划的最后一步，技术图谱里还差这么几块拼图：

1. 缺少 Low Code 工程化能力，无法满足大型活动的定制模块开发需求；

2. 缺少 Pro Code 工程化能力，无法满足个别活动的完全定制开发需求；

3. C 端页面加载性能较差，难以满足司级活动的页面性能要求。

1）技术架构设计

因此，这阶段的架构变化，即在新的框架基础上，拓展 Low Code & Pro Code 模式，补全平台开放能力：

1. eva-cli 增加 Low Code 工程化能力，打通代码块组件开发流程；

2. eva-cli 增加 Pro Code 工程化能力，结合制作页开发模式和片段加载器，打通定制活动开发流程；

5. eva-server 增加框架预渲染能力，提升 C 端页面加载性能。

2）重点建设案例

a. Low Code 模式

代码块开发模式服务于半搭建半开发的活动场景。业务开发者在运营搭建好页面框架的基础上，通过 eva-cli 生产一次性的定制功能代码块组件，并上传到制作页供运营当普通组件使用，来完成页面的定制功能开发。

该模式存在以下特点：

配套有开发环境下的工程化解决方案：eva-cli 代码块组件开发指令；
遵循平台「组件化」原则，代码块本质上是一次性组件，符合平台组件规范，可以完全复用平台现有能力，包括画布预览、图层拖拽嵌套、表单配置等等；
与页面深度结合，支持在开发环境下拉取活动页面数据，在开发环境与页面直接交互，操作页面数据，并实时预览效果；
无需走组件中心审批流程，与页面直接绑定，支持直接发布供运营线上使用，同时也支持本地配置好代码块后一键同步到线上页面。

eva-cli 增加 Low Code 模式 & 代码块组件开发流程复用度对比

来直观感受下本地开发代码块的体验：

示例：S14 征稿活动代码块本地开发环境

主要功能一览：

1. 【数据展示模块】：显示关联的活动及制作页，用于拉取线上页面数据；

2. 【数据管理】：拥有管理本地数据的能力，可以新建本地页面，切换页面，页面备份；

3. 【保存】：保存本地数据到【数据管理】中，方便备份本地数据；

4. 【仅发布代码块】：仅将代码块发布到活动上，本地页面数据不会同步到制作页，需要到活动页上进行手动拖拽添加；

5. 【同步到制作页】：代码块发布 & 页面同步一站式操作，同时有冲突检测保护机制。

总结下 Low Code 模式的工程化成果：

b. Pro Code 模式

Pro Code 模式服务于少数需要全定制开发的业务场景。比如个别大型活动，需要使用动画框架、定制模板能力或者定制渲染器。那么业务开发者可以使用 eva-cli 定制开发页面后，通过平台来发布和管理页面。同时如果页面有部分模块是可以复用平台组件的，那么可以基于平台的片段加载器能力，来直接复用运营搭建的页面片段，提高开发效率。

该模式存在以下特点：

1. 配套有开发环境下的工程化解决方案：eva-cli 代码模式开发指令；

2. 打通了制作页的代码模式，无缝使用平台提供的页面部署、管理、数据回收分析等能力；

3. 支持使用片段加载器来提效：从核心渲染器（EvaRender）封装出片段加载器 runtime，并打包成适配不同框架的 npm 包供代码开发场景引入使用，通过传入活动 ID 来渲染出对应的平台搭建页面。主要使用场景是在代码开发中复用平台搭建的页面片段，最大化利用平台组件生态来降低开发成本。

eva-cli 架构：新增 Pro Code 模式 & Pro Code 模式开发流程

同样总结下 Pro Code 模式的工程化成果：

c. 页面性能优化

活动平台搭建出来的活动页面是 SPA，除了一些常规优化外，没有针对首屏加载场景做额外优化，导致页面加载白屏时间较长，影响用户体验。另外一些大型活动对页面性能和用户体验要求更高，因此需要针对首屏场景做一轮性能优化，来减少页面白屏时间，提高用户体验。

技术选型上需要优先考虑保持 B/C 两端的渲染一致性，以及不对现有组件生态带来额外适配成本，因此：

1. 我们选择了对 runtime 侵入性最小的方案：只改造框架类组件（页面组件、基础容器组件、图片组件、视频组件）；

2. 框架类组件改造成支持打包 server bundle，供 eva-server 构建页面时预渲染环节使用；

3. eva-server 服务增加预渲染环节，C 端 runtime 增加预渲染能力；

4. 同时我们建设了完整的数据埋点上报分析链路，来监控对比页面性能提升情况。

预渲染技术方案简易模型

页面性能优化上线后，以《黑神话：悟空》活动为例，单页面 FCP 性能指标下降了 35%

3）阶段建设成果

至此，活动平台长线技术规划图谱建设完毕，补全了欠缺的两块开放能力拼图，以及页面性能大幅提升，能满足各种不同的业务开发场景。并在业务实践中取得了出彩的成绩：

Low Code + Pro Code 支撑起司级活动开发

1. Low Code 模式 + 页面性能优化建设，保障活动平台顺利承接了 S14 司级活动的开发！

2. Pro Code 模式，为 Q4 的用户年报司级活动提前铺路。

S14 Low Code 示意 & 活动效果

性能优化带来可观的收益

1. H5 页面 FCP 周均值指标从 1792ms 降至 1484ms，即访问页面的白屏时间降低了 17.2%；

2. H5 页面停留时长周均值指标从 7973ms 升至 8604ms，提高了 7.91%

05.建设总结

5.1 整体技术架构

经过三个阶段的迭代演进，活动平台整体架构可以概括成：5 + 4 + 3 + 2。即：

5 块服务：eva + eva-server + page-service + eva-cli + core-modules
4 大模块：渲染器 + 图层树 + 属性表单 + 组件列表
3 种模式：No Code + Low Code + Pro Code
2 个生态：组件生态 + 数据源生态

5.2 整体建设成果

我们基于短线长线两条腿走路的策略，经过三个阶段建设下来，既保障了业务无阻塞地正常开展，又通过渐进式迭代实现了技术架构的长线升级。虽然历时较久，但胜在稳健有序。总结来说就是，新活动平台建设助力活动业务又快又好！

快：活动提效明显

新平台已实现原活动制作平均 3 人日/单活动（页面搭建 1 人日 + 数据源配置 1.5 人日 + 功能调试 0.5 人日），人效提升至 0.48 人日/单活动（3.85h），主站运营平均 208 个/月活动，总计节省人力约 524 人日/月，主站运营上半年节省人力约 3144 人日；
截止 H1 的平台覆盖效果，全司活动可节省运营人效 578 人日/月；

好：活动效果可观