一、前言

歷時近兩年的重新設計和迭代重構，用戶技術中心的新活動平臺建設bilibili活動中臺終于落地完成！并迎來了里程碑時刻 —— 接過新老迭代的歷史交接棒，從內到外、從開發到搭建實現全面升級，開啟了活動生產工業化新時代：

• 界面交互層面：在界面和交互上推倒重來，實現了簡潔美觀、符合直覺、簡單易用的現代化升級；
• 業務功能層面：在功能上去繁就簡，聚焦核心業務，對活動搭建和業務開發兩條主場景進行重新思考和設計，簡化流程并提高了整體效率和體驗；
• 系統架構層面：模塊解耦提升擴展性的同時，圍繞業務訴求進行迭代演進，通過技術驅動來賦能業務，提高業務邊界和想像力，助力活動業務跑得更好更快；
• 開發生態層面：通過開發工具鏈的升級，把平臺開放能力提升到了一個新的高度，為業務開發者創造了更加友好的開發環境和平臺生態。

本文將從新活動平臺（以下簡稱為活動平臺）的建設歷程展開，闡述我們在整個開發過程中的設計理念、建設規劃和架構思考。不同建設階段中面臨的挑戰，以及活動平臺團隊是如何解決的。希望能對你有點幫助。

開始之前，先來簡單認識一下活動平臺：

圖片

活動平臺最核心的頁面：制作頁

二、活動平臺是什么

活動平臺本質上是一個低代碼平臺。低代碼平臺是一種成熟的業務應用開發方案，這里不再贅述。除了低代碼的標簽外，活動平臺也是一個 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 模式：服務于少數需要全定制開發的業務場景 —— 比如個別大型活動，需要使用動畫框架、定制模板能力或者定制渲染器。那么開發者可以通過平臺開發工具，定制開發頁面后，通過平臺來發布和管理頁面。同時如果頁面有部分模塊是可以復用平臺組件的，那么可以基于平臺的片段加載器能力，來直接復用運營搭建的頁面片段，提高開發效率。

三類服務對象和三種業務模式的關系示意圖

三、背景和目標

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 平臺建設如此，新活動平臺建設也是如此。

執行策略：短線技術優化，保障業務開展；長線技術升級，助力業務增長

通過短期的技術優化，來確保活動業務能夠順利交付。同時，我們著眼長遠，通過技術迭代不斷提升工程能力和效率。在這個過程中，技術不僅支持業務發展，還能推動業務創新，優化活動形式和效果，讓活動越辦越好，最終實現良性循環。

基于這個理念和策略，活動平臺整體建設規劃了三個階段，來逐步推進落地。

四、建設歷程

以半年為周期，我們規劃了兩個時期三個階段的推進節奏：

•  短線技術優化期，目標是保障業務開展

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 的跨頁面拖拽問題。具體方案為：

• previewWarp 以透明浮層的方式覆蓋在畫布的 iframe 容器上方，默認為隱藏狀態；
• 從組件列表拖拽組件進畫布時，previewWarp 浮層顯示并且作為 Drop 的目標區域，實現畫布的拖拽交互；
• 拖拽完成后 previewWarp 自動隱藏，避免影響畫布本身的交互操作；
• 同時通過 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 組件信息：描述組件的基礎必要信息

a.BaseInfo 基礎信息：描述組件名、分類、版本號、支持平臺、縮略圖等信息。

b.PropInfo 表單信息：描述組件在屬性表單面板里有哪些配置項，對應什么控件。

c.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%

圖片

五、建設總結

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 人日/月；

好：活動效果可觀

• 2024 H1 活動平臺上線頁面 1977 個，頁面總 PV 月均 0.62 億+，平臺產出稿件量 3648 萬 +；
• 截至 2024 H1，平臺總頁面數 4369 個，帶來總 PV 8.42 億；
• 截至 2024.8 新活動平臺頁面覆蓋率 77.06%。

典型活動示例：黑神話悟空（No Code 搭建）

• 該活動結合了平臺多種整合營銷玩法：任務 + 集卡 + 答題 + 圈子；
• 上線一周帶來接近 1000 萬 pv，堪比司級活動；18 萬+ 稿件量，9.7 億+ 播放量，其中百萬播稿件量 100+；

圖片

黑神話悟空活動：任務+集卡+答題+圈子的復雜玩法

六、未來規劃

我們已經完成了新活動平臺的工業化 2.0 升級，未來主要方向之一，會超著智能化、數據驅動的方向探索，包括但不限于：

1） 建設活動頁面質量檢測面板和智能糾錯能力，降低運營配置錯誤率，減少線上問題；

2）探索頁面自動化測試方案；

3）探索結合 低代碼 + MLLM（Multimodal Large Language Model - 多模態大語言模型） + D2C（Design2Code - 設計稿轉代碼） 的可能性；

4） 結合大量的活動數據分析，建立活動效果評估系統，通過數據驅動發現有潛力有價值的活動玩法，為業務創新提供更多可能性。