一、前言

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

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

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

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

圖片

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

二、活動平臺是什么

活動平臺本質(zhì)上是一個低代碼平臺。低代碼平臺是一種成熟的業(yè)務應用開發(fā)方案，這里不再贅述。除了低代碼的標簽外，活動平臺也是一個 CMS（Content Management System） 系統(tǒng)，除了最核心的活動業(yè)務，還能廣泛應用在其它各種頁面生產(chǎn)場景。因此從業(yè)務抽象的角度來總結(jié)的話，可以從服務對象和業(yè)務模式兩方面來概括活動平臺：

2.1 服務對象

活動平臺服務對象包括運營、用戶、研發(fā)三類，其中：

• 運營：是平臺的 B 端用戶，負責生產(chǎn)活動頁面；
• 用戶：是平臺的 C 端用戶，負責消費活動頁面；
• 研發(fā)：包括平臺研發(fā)+業(yè)務研發(fā)
• 平臺研發(fā)：平臺系統(tǒng)維護者，負責平臺迭代建設、開發(fā)通用組件、維護組件生態(tài)和數(shù)據(jù)源生態(tài)，并對外提供開發(fā)工具；
• 業(yè)務研發(fā)：負責通過平臺提供的開發(fā)工具來開發(fā)業(yè)務組件，供運營消費組件來生產(chǎn)活動頁面

2.2 業(yè)務模式

活動平臺業(yè)務模式包括 No Code、Low Code、Pro Code 三種模式，其中：

• No Code 模式：服務于全搭建的業(yè)務場景 —— 頁面搭建配置過程由運營完全負責，無需研發(fā)介入。研發(fā)在平臺上發(fā)布可復用的業(yè)務組件，運營基于業(yè)務組件生產(chǎn)各種不同的活動頁面。基于豐富的組件生態(tài)，可以覆蓋 > 99% 業(yè)務場景。
• Low Code 模式：服務于半搭建半開發(fā)的業(yè)務場景 —— 比如一個活動頁面里 90% 部分可以基于平臺搭建，剩下的 10% 沒有對應的平臺組件，同時也不具備可復用價值。那么在運營搭建好頁面框架的基礎上，研發(fā)介入生產(chǎn)一次性的定制功能代碼塊組件并發(fā)布到平臺，然后交由運營操作組裝，與頁面進行有機結(jié)合，實現(xiàn)完整的頁面功能。大概覆蓋 < 1% 業(yè)務場景。
• Pro Code 模式：服務于少數(shù)需要全定制開發(fā)的業(yè)務場景 —— 比如個別大型活動，需要使用動畫框架、定制模板能力或者定制渲染器。那么開發(fā)者可以通過平臺開發(fā)工具，定制開發(fā)頁面后，通過平臺來發(fā)布和管理頁面。同時如果頁面有部分模塊是可以復用平臺組件的，那么可以基于平臺的片段加載器能力，來直接復用運營搭建的頁面片段，提高開發(fā)效率。

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

三、背景和目標

3.1 項目背景

為什么要建設活動平臺，主要有兩點原因：

1.環(huán)境原因：在公司提效的大背景下，需要整合統(tǒng)一各部門的活動搭建能力，比如活動業(yè)務的 Flash 平臺、Native 平臺、直播業(yè)務的云雀平臺。通過橫向?qū)Ρ雀髌脚_的技術能力現(xiàn)狀及業(yè)務覆蓋情況，最終選擇基于 Flash 平臺進行迭代升級：

2.平臺原因：Flash 平臺自上線運行多年以來，一直都是通過技術自驅(qū)進行迭代，雖然功能強大且生態(tài)豐富，但由于長期缺少整體設計、架構(gòu)優(yōu)化和產(chǎn)品化的規(guī)劃打磨，因此界面和交互較為陳舊、核心功能重技術輕體驗、架構(gòu)擴展性差跟不上時代變化、整體活動搭建和開發(fā)體驗和效率都較差，急需進行改造升級。

3.2 面臨挑戰(zhàn)

活動平臺是由多套服務組成的復雜系統(tǒng)，涉及業(yè)務廣泛，想要對其進行從內(nèi)到外的整體改造升級，是一個巨大的挑戰(zhàn)。

1.內(nèi)部挑戰(zhàn)

從長期的用戶使用反饋和平臺開發(fā)視角來看，主要包括幾個方面的問題：

1）平臺體驗方面：

a.  制作頁問題：功能布局不合理、圖層拖拽體驗差，無法跨層級拖拽、組件列表管理方式不直觀... 等等；

b.  畫布問題：部分組件無法預覽、容器無法多級嵌套、搭建過程無法全真預覽體驗較差... 等等；

c.  數(shù)據(jù)源問題：數(shù)據(jù)源割裂分散、數(shù)據(jù)源配置項繁冗重復、低頻的高級功能導致使用復雜度上升... 等等；

d.  組件問題：沒有平臺級的彈窗組件、數(shù)據(jù)源組件使用成本高、組件重復且質(zhì)量參差不齊... 等等。

2）架構(gòu)設計方面：

a.  整體架構(gòu)問題：歷史包袱重，核心模塊耦合嚴重，牽一發(fā)動全身，無法進行獨立測試，功能擴展性差；

b.  渲染器問題：B 端和 C 端使用兩套渲染器，無法從根本上解決畫布渲染下和頁面預覽下可能出現(xiàn)的組件表現(xiàn)不一致問題；

c.  模塊設計問題：畫布、圖層、表單等核心模塊設計不合理，使得開發(fā)需要模塊間聯(lián)動的復雜業(yè)務組件變得困難甚至不可行（比如答題、集卡組件）；

d.  拖拽能力問題：組件列表和圖層樹采用兩套拖拽實現(xiàn)方案，功能和體驗割裂，且三方庫的拖拽能力越來越難以滿足快速發(fā)展的業(yè)務需求；

      e.  開發(fā)環(huán)境問題：開發(fā)模式和搭建模式使用兩套不同的可視化方案，容易出現(xiàn)組件開發(fā)和搭建環(huán)境下渲染表現(xiàn)不一致；加上無法實時預覽、開發(fā)工具碎片化等問題，導致整體開發(fā)體驗較差

3） 存量業(yè)務方面：平臺維護組件數(shù)量多達 330+ 個，如何低成本地進行新架構(gòu)的快速適配和遷移；

2.外部挑戰(zhàn)

活動平臺目前接入垂類業(yè)務技術團隊 8 個（直播、漫畫、電商、OGV、貓耳、商業(yè)、星辰、大會員），垂類業(yè)務方開發(fā)組件 230+ 個，運營使用團隊 20+ 個，日均支持 35+ 個活動。

1） 涉及的業(yè)務范圍廣而多，如何在不影響業(yè)務正常運轉(zhuǎn)的情況下，對平臺進行漸進式的改造重構(gòu)；

2）如何最小化業(yè)務方的技術遷移成本，同時保證遷移效果接近無損，需要謹慎設計和合理規(guī)劃。

3.3 建設目標

我們基于平臺開發(fā)經(jīng)驗和業(yè)務現(xiàn)狀，結(jié)合對未來的規(guī)劃，進行全面審視和重新思考后，新活動平臺明確了幾個建設目標：

1.  解決所有用戶反饋的使用問題，打造體驗一流、更具生產(chǎn)力的一站式活動頁面可視化搭建系統(tǒng)；

2.  以體驗和效率為目標，重新設計 No Code、Low Code、Pro Code 三種業(yè)務模式，更好地服務于運營、用戶和研發(fā)；

3.  系統(tǒng)架構(gòu)設計在滿足中短期規(guī)劃的同時，保留足夠的靈活度和拓展性，為長期業(yè)務發(fā)展做一定的準備。

為了保證能順利推進完成業(yè)務和技術上的雙重目標，需要制定一套行之有效的方法論來支撐和指導。

建設理念：業(yè)務優(yōu)先，技術驅(qū)動

活動部門做為職能部門，保障業(yè)務是我們的基本生命線；同時做為技術團隊，技術驅(qū)動是第一生產(chǎn)力。技術自驅(qū)也是我們團隊一直以來的行事風格，F(xiàn)lash 平臺建設如此，新活動平臺建設也是如此。

執(zhí)行策略：短線技術優(yōu)化，保障業(yè)務開展；長線技術升級，助力業(yè)務增長

通過短期的技術優(yōu)化，來確?；顒訕I(yè)務能夠順利交付。同時，我們著眼長遠，通過技術迭代不斷提升工程能力和效率。在這個過程中，技術不僅支持業(yè)務發(fā)展，還能推動業(yè)務創(chuàng)新，優(yōu)化活動形式和效果，讓活動越辦越好，最終實現(xiàn)良性循環(huán)。

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

四、建設歷程

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

•  短線技術優(yōu)化期，目標是保障業(yè)務開展

1.活動平臺一階段：

• 關鍵詞：界面交互重構(gòu)，用戶體驗升級。
• 業(yè)務目標：重新設計 No Code 模式的搭建流程，集中解決活動頁面搭建問題，提高運營使用效率和體驗。

升級技術升級期，目標是助力業(yè)務增長

2.活動平臺二階段：

• 關鍵詞：平臺架構(gòu)升級，組件生態(tài)建設。
• 業(yè)務目標：通過長線漸進式技術升級，解決整體架構(gòu)性問題，并完成 No Code 模式底層重構(gòu)，開始賦能業(yè)務。

3.活動平臺三階段：

• 關鍵詞：開放能力補完，C端性能優(yōu)化。
• 業(yè)務目標：長線技術規(guī)劃圖譜補全，基于新架構(gòu)重新設計 Low Code 和 Pro Code 模式，助力業(yè)務跑得更好。

圖片

4.1 一階段

運營是活動平臺生產(chǎn)端的主要用戶，平均每天花費超過 4h 時間用于搭建活動頁面，由于前面提到的包括制作頁、畫布、數(shù)據(jù)源、組件在內(nèi)的各種問題，使得運營一直以來在使用活動平時都要忍受相對糟糕的的體驗和低下的效率。

因此這階段的主要目標，是在不涉及系統(tǒng)底層架構(gòu)大改的基礎上，通過局部模塊的重新設計和調(diào)優(yōu)，來重塑 No Code 模式的搭建流程，集中解決活動頁面搭建問題，在保障業(yè)務正常開展的同時，短期內(nèi)快速提高運營整體使用效率和體驗。包括：

• 提供更現(xiàn)代化的界面和交互，產(chǎn)品化打磨流程和細節(jié)；
• 解決大部分痛點體驗問題，從創(chuàng)建到搭建到管理，從數(shù)據(jù)源到組件全流程覆蓋；
• 提高整體活動頁搭建效率，提高業(yè)務產(chǎn)出。

1.技術架構(gòu)設計

先來快速了解下平臺整體系統(tǒng)架構(gòu)組成：

• eva 服務：活動平臺前臺應用。運營主要使用的服務，承載了活動頁面的全生命周期（創(chuàng)建、搭建、發(fā)布、分析、管理），包括 6 大模塊（活動列表、制作頁、活動效果、功能數(shù)據(jù)、權限控制、輔助工具）和 2 個生態(tài)（組件生態(tài)、數(shù)據(jù)源）。其中制作頁是最核心的模塊，也是運營使用最高頻的功能，主要由畫布、圖層樹、屬性表單、組件列表四部分組成。
• eva-server 服務：活動平臺 node 服務。主要負責預覽/線上頁面的 HTML 構(gòu)建、基礎 SSR 服務、頁面部署上線，以及提供平臺內(nèi)部使用的接口能力。
• page-service 服務：活動平臺頁面服務。主要負責頁面分發(fā)，配合 SLB（Server Load Balancing - 服務器負載均衡）和 BFS（bilibili file storage - B站文件存儲服務） 能力來實現(xiàn)輕量級的路由管理，以及通過內(nèi)存化緩存來提升服務穩(wěn)定性，同時還支持了服務多活和 SLB 降級。
• page 產(chǎn)物：用戶最終消費的靜態(tài)頁面。

這階段的架構(gòu)設計，我們在保持整體框架不變的基礎上，對 No Code 模式流程里涉及的功能模塊都進行了優(yōu)化（白底的模塊，15+），并對幾個重點模塊做了重新設計（黃底的模塊，5+），包括最核心的制作頁模塊改造和一體化數(shù)據(jù)源改造。

圖片

2.重點建設案例

由于涉及優(yōu)化的模塊太多太廣，篇幅原因無法一一展開，這里我挑兩個重點案例來具體闡述。

a. 畫布改造

畫布改造是為了解決一直被詬病的組件預覽問題，我們通過新的技術方案來實現(xiàn)所有組件的實時全真預覽能力。詳細對比了 component 方案和 iframe 兩種技術方案：

考慮到體驗和效果優(yōu)先，為了保證運營在頁面搭建過程中能實時便捷地預覽組件配置效果，最終選擇了 iframe 方案。但該方案存在跨頁面拖拽的交互問題，如何解決呢？

經(jīng)過探索和實踐，我們采用了在畫布上引入 previewWarp 中間層的方式來解決 iframe 的跨頁面拖拽問題。具體方案為：

• previewWarp 以透明浮層的方式覆蓋在畫布的 iframe 容器上方，默認為隱藏狀態(tài)；
• 從組件列表拖拽組件進畫布時，previewWarp 浮層顯示并且作為 Drop 的目標區(qū)域，實現(xiàn)畫布的拖拽交互；
• 拖拽完成后 previewWarp 自動隱藏，避免影響畫布本身的交互操作；
• 同時通過 Message 通信通知 iframe 頁面添加組件到圖層樹，并觸發(fā)重新渲染畫布，達到實時預覽的效果。

previewWrap 工作流程示意

b. 數(shù)據(jù)源改造

數(shù)據(jù)源改造是為了解決另一個長期被詬病的問題 —— 活動玩法組件配置太復雜、配置難、易配錯。我們通過重新設計整個配置鏈路，提供一站式的配置面板來降低運營使用數(shù)據(jù)源的心智負擔，以及減少線上問題的發(fā)生。

采用的技術方案，簡要來說是：動態(tài)維護一個表單棧 stackForm，存儲當前層的 callerId、data 等數(shù)據(jù)，層級增加時 push，層級減少時 pop，并檢查當 returnId = callerId 時，觸發(fā)上一層的回調(diào)，返回當前層的配置數(shù)據(jù)。最后攜帶數(shù)據(jù)源 ID 和數(shù)據(jù)返回到入口處，交由組件自行處理信息回填等操作。

一體化數(shù)據(jù)源使用示意

數(shù)據(jù)源配置入口與數(shù)據(jù)源組件配置表單直接綁定，讓運營在使用上一氣呵成，省去了來回跳轉(zhuǎn)的麻煩。因此與一體化數(shù)據(jù)源面板一起重新設計的，還有首批數(shù)據(jù)源組件：任務組件、抽獎組件、征稿組件。不僅在組件功能和組件表單上做了對應的升級聯(lián)動，還在數(shù)據(jù)源表單項上進行了重新思考，保留最核心的配置項，合理刪減低頻功能，下調(diào)高級功能的顯示優(yōu)先級，為運營進一步減賦提效。

圖片

流程和功能簡化后，對降低配置難度和提高配置效率有著顯著的效果：

圖片

舉一個例子：運營配置一個完成任務獲得抽獎機會的活動：

圖片

經(jīng)過對上線后的數(shù)據(jù)分析統(tǒng)計，一體化數(shù)據(jù)源改造使得由于配置出錯導致的線上問題減少了 30%+！

3.階段建設成果

這階段完成了一系列模塊的優(yōu)化項，覆蓋了 No Code 搭建流程的方方頁面：

1）制作頁優(yōu)化：全新設計的制作頁面、升級圖層樹，優(yōu)化拖拽體驗、支持跨層級拖拽組件、重新設計表單控件、升級組件列表…... 等等；

2）畫布優(yōu)化：iframe 畫布方案、重新設計通信方案、渲染器升級，支持容器多級嵌套... 等等；

3）數(shù)據(jù)源優(yōu)化：一體化數(shù)據(jù)源面板方案、重新設計各類數(shù)據(jù)源配置項、統(tǒng)一活動概念... 等等；

4）組件優(yōu)化：新增平臺級的彈窗、標簽卡組件、任務、抽獎、征稿等多個數(shù)據(jù)源組件一體化改造、容器、標簽卡等基礎組件優(yōu)化... 等等。

兼具體驗和效率的新版制作頁

同時也在業(yè)務上取得了可觀的成果，并多次收到運營使用上的的正面反饋！

• 解決了 80% 的體驗和效率問題，平均搭建耗時 3.56h，征稿類活動搭建耗時 3.89h，提效 20%+；
• 新搭建流程覆蓋了 42% 選題會活動；
• 簡化了征稿活動流程，提效 34%。

 4.2 二階段

一階段通過技術優(yōu)化手段，解決了 No Code 模式下 80% 的體驗和效率問題，剩下的 20% 由于架構(gòu)設計問題難以根治。包括前面章節(jié)提到的：

• B 端和 C 端使用兩套渲染器，無法從根本上解決畫布渲染下和頁面預覽下可能出現(xiàn)的組件表現(xiàn)不一致問題；
• 畫布、圖層、表單等核心模塊設計不合理，使得開發(fā)需要模塊間聯(lián)動的復雜業(yè)務組件變得困難甚至不可行；
• 組件列表和圖層樹采用兩套拖拽實現(xiàn)方案，功能和體驗割裂，且三方庫的拖拽能力越來越難以滿足快速發(fā)展的業(yè)務需求；
• 開發(fā)模式和搭建模式使用兩套不同的可視化方案，容易出現(xiàn)組件開發(fā)環(huán)境下和搭建環(huán)境下渲染表現(xiàn)不一致。

同時，一階段的建設成果已經(jīng)能夠滿足短期業(yè)務需求的正常開展，給了技術喘息和規(guī)劃的機會。因此從這階段開始，正式啟動了活動平臺橫跨兩個半年周期的漸進式長線技術升級期。

1.技術架構(gòu)設計

這階段我們在架構(gòu)層面做了一次比較大的調(diào)整，基于B站的活動業(yè)務特點升級了整體技術架構(gòu)。同時我們也調(diào)研了一些業(yè)界流行低代碼系統(tǒng)的設計，比如百度的低代碼前端框架（AMIS） 和阿里的低代碼引擎（LowCodeEngine），雖然他們都有各自非常優(yōu)秀的設計理念和實踐場景，但對于B站的活動業(yè)務來說，也都存在比較明顯的水土不服問題，比如 AMIS 無法滿足個性化復雜業(yè)務組件的定制需求、LowCodeEngine 無法很好地支持除了 React 框架以外的組件，難以兼容平臺的組件生態(tài)（React、Vue、Vanilla），等等。

因此我們在整體自研的基礎上，局部模塊借鑒了他們的優(yōu)秀設計實踐，比如在頁面結(jié)構(gòu)和組件描述上采用了類似于 AMIS 的 JSON Schema 方案；在制作頁的核心模塊設計上與 LowCodeEngine 方案有異曲同工之妙，功能解耦、可獨立運行、可靈活擴展和配置。由于篇幅限制，細節(jié)這里不詳細展開。

整體設計目標致力于解決當下架構(gòu)問題，同時保留一定的靈活性和拓展能力，以滿足未來幾年的業(yè)務發(fā)展：

1） 制作頁架構(gòu)升級，重新設計數(shù)據(jù)模型，并解耦出 4 大模塊，用于組裝新的制作頁面板，各模塊可以獨立擴展或替換；

2）統(tǒng)一 B/C 兩端渲染器，保證所有組件在畫布渲染和預覽/線上渲染場景下表現(xiàn)完全一致；

3） 重新設計實現(xiàn)圖層樹、屬性表單、組件列表模塊。擺脫三方依賴，實現(xiàn)功能完全自定義；

4）重新設計新開發(fā)工具 eva-cli，滿足 No Code 模式的組件開發(fā)流程，并在未來集成 Low Code 和 Pro Code 模式；eva-cli 開發(fā)面板采用與制作頁同構(gòu)化的技術方案，保證一致的功能和體驗。

并補齊了一些配套能力建設：

1）組件轉(zhuǎn)換器，用于橋接新老架構(gòu)的數(shù)據(jù)模型，輔助業(yè)務開發(fā)遷移組件到新架構(gòu)；

2）上線新組件中心，與 eva-cli 深度集成，組件開發(fā)流程工程化；

3）上線活動模板功能；

4）新增集卡、答題、押注等多種數(shù)據(jù)源組件玩法。

圖片

2.重點建設案例

該階段是三個階段中最重要的一步，這里我多挑幾個實踐展開說說。

a. 數(shù)據(jù)模型重構(gòu)

制作頁四大核心模塊解耦的基礎，依賴一套全新的數(shù)據(jù)模型，用于定義模塊自身的數(shù)據(jù)結(jié)構(gòu)，以及規(guī)范和約束模塊間的通信和 API 能力。

經(jīng)過重新梳理，我們把整個制作頁的數(shù)據(jù)描述定義為三類：

• ComponentData 組件數(shù)據(jù)：定義組件的完整數(shù)據(jù)

ComponentInfo 組件信息：描述組件的基礎必要信息

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

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

c.SlotInfo 插槽信息：描述組件在圖層樹里有幾個插槽，分別是什么。

Assets 組件資源：組件打包后的 js 和 css 產(chǎn)物地址。

LayerControl 圖層控制器：組件與圖層樹模塊聯(lián)動的描述文件，用于注冊一系列圖層勾子的監(jiān)聽函數(shù)，在圖層樹發(fā)生變化時，通過調(diào)用 LayerAPI 來實現(xiàn)一些聯(lián)動邏輯。

FormControl 表單控制器：組件與屬性表單模塊聯(lián)動的描述文件，用于注冊一系列表單勾子的監(jiān)聽函數(shù)，在屬性表單內(nèi)容發(fā)生變化時，通過調(diào)用 FormAPI 來實現(xiàn)一些聯(lián)動邏輯。

• LayerData 圖層數(shù)據(jù)：定義圖層的完整數(shù)據(jù)。

ComponentProps 圖層屬性信息：圖層的表單配置數(shù)據(jù)，即組件的狀態(tài)數(shù)據(jù)。

ComponentSlotData 圖層嵌套關系：圖層子節(jié)點信息，用于描述圖層嵌套關系。

• ApiData 接口數(shù)據(jù)：組件請求服務端接口拿到的業(yè)務數(shù)據(jù)。

四大模塊分別實現(xiàn)了各自的渲染函數(shù)，圖層樹和屬性表單模塊還定義了 API 能力，用于和組件進行聯(lián)動。然后通過組件數(shù)據(jù)和圖層數(shù)據(jù)的串聯(lián)組織，建立起整個制作頁的數(shù)據(jù)模型：

三類數(shù)據(jù) + 四大模塊 = 制作頁數(shù)據(jù)模型

組件轉(zhuǎn)換器

新的數(shù)據(jù)模型必然會帶來破壞性變更，無法向下兼容舊的組件數(shù)據(jù)結(jié)構(gòu)。如何批量快速遷移組件，減少業(yè)務方不必要的理解成本，則需要借助組件轉(zhuǎn)換器來實現(xiàn)。通過詳盡的字段關系映射和兜底邏輯處理，我們提供了一個近乎無損的 woodman 組件轉(zhuǎn)換器，完成了超過 50+ 組件的轉(zhuǎn)換工作。

woodman 組件轉(zhuǎn)換器原理示意

b. 渲染器重構(gòu)

想要從根本上解決組件渲染在畫布環(huán)境和預覽/線上環(huán)境不一致的問題，辦法只有一個：統(tǒng)一 B/C 兩端的渲染器。并且畫布已經(jīng)從 component 模式改造成 iframe 模式，抹去了 B/C 兩端最大的環(huán)境差異。接下來的目標很明確，就是如何設計一個符合業(yè)務需求的、理想的統(tǒng)一渲染器。

我們基于活動業(yè)務 B 端和 C 端場景的特點，結(jié)合以往幾年平臺實踐下來的經(jīng)驗沉淀，設計了一套 5 層結(jié)構(gòu)的頁面渲染框架，具體拆解為：

• 第一層 - 核心渲染器 eva-render：支持 3 類框架（React、Vue、Vanilla）、6 類組件（頁面組件、環(huán)境組件、容器組件、業(yè)務組件、拖拽響應組件，以及未來拓展支持的代碼塊組件）渲染的基礎渲染器，負責所有組件渲染。內(nèi)部封裝成圖層渲染器 LayerRenderer，直接供 B 端場景使用；
• 第二層 - 通用運行時 runtime：基于核心渲染器的封裝，包含各種數(shù)據(jù)注入邏輯，并結(jié)合后面幾層的包裝，服務于 C 端場景；
• 第三層 - HTML 模板 template：C 端頁面模板，runtime 載體，用于配置頁面基礎能力，包括互跳、埋點上報等；
• 第四層 - Node 服務 eva-server：基于模板構(gòu)建 C 端環(huán)境 HTML 內(nèi)容，通過基礎 SSR 在 window 上掛載 runtime 需要的一切數(shù)據(jù)。后續(xù)還會支持頁面框架預渲染能力；
• 第五層 - 業(yè)務場景：包括 B 端制作頁（制作頁畫布、開發(fā)面板）和 C 端線上頁面（預覽 HTML、線上 HTML）。

渲染邏輯分層

通過對頁面渲染邏輯的分層設計和應用，取得了以下成果：

1）實現(xiàn)了活動平臺渲染器的統(tǒng)一，從根本上解決了 B/C 兩端渲染不一致的問題；

2）渲染器模塊完全解耦，可脫離制作頁環(huán)境獨立使用，為后面組裝 eva-cli 開發(fā)面板和實現(xiàn)頁面片段加載器打好基礎；

3）核心渲染器可供業(yè)務方獨立使用，自行構(gòu)建 HTML，滿足定制化渲染需求，比如直播的掛件場景；

4）業(yè)務方也可基于核心渲染器封裝自己的業(yè)務渲染器，搭配自閉環(huán)的業(yè)務組件，實現(xiàn)一些微前端之類的輕量級使用場景。

c. 圖層模塊重構(gòu)

現(xiàn)有的圖層模塊功能和拖拽能力是基于 antd tree 做的定制開發(fā)。雖然一階段我們通過技術優(yōu)化解決了大部分圖層體驗問題，但依然有幾個遺留問題是現(xiàn)有術選型無法解決的，包括：

• antd tree 自定義能力較弱，組件拖拽方式不夠直觀，且精準度不佳導致失誤率較高，在圖層操作這類高頻使用場景上明顯影響效率；
• antd tree 組件靈活度不夠，無法滿足圖層隱藏、多插槽圖層等高級功能，阻礙組件開發(fā)的靈活度。

同時平臺在組件列表模塊里采用了另一套拖拽解決方案：reactDnD。與 antd tree 的拖拽體驗對比下來，reactDnD 更輕量靈活，也更適合業(yè)務定制，因此我們決定重新基于此打造圖層模塊：

1）拋棄 antd tree 方案，基于 reactDnD 重新實現(xiàn)理想的圖層拖拽交互體驗：直觀易用，靈活性度，拓展性強；

2）拋棄傳統(tǒng)樹結(jié)構(gòu)，采用更輕量的扁平樹結(jié)構(gòu)，編寫更高效的 API，提高狀態(tài)數(shù)據(jù)變更效率，保證拖拽過程實時反饋的最佳體驗；

3）重新設計 30+ LayerAPI，支持多插槽、圖層勾子、圖層隱藏等核心能力；API 全部純函數(shù)設計，方便單測接入；

4）未來支持更多定制化的能力拓展，技術上不受限，為組件玩法創(chuàng)造更多可能性。

數(shù)據(jù)結(jié)構(gòu)轉(zhuǎn)換模型 & LayerAPI 全貌 & 圖層模塊能力全貌

新版圖層模塊完成上線后，可以說從底層重塑了活動平臺的拖拽體驗：

1）實現(xiàn)了平臺拖拽體驗的升級和統(tǒng)一，徹底解決運營反饋的圖層拖拽不跟手、不精準的問題；

2）圖層模塊完全解耦，依然可供業(yè)務方獨立使用，在滿足數(shù)據(jù)結(jié)構(gòu)規(guī)范的前提下滿足定制化場景；

3）為后續(xù)實現(xiàn)骨架屏、海報布局等更多拖拽場景打好基礎。

d. 開發(fā)工具重構(gòu)

新架構(gòu)下的數(shù)據(jù)模型和制作頁核心模塊準備就緒之后，接下來我們要考慮的問題自然就是：如何在新架構(gòu)下為 No Code 模式開發(fā)業(yè)務組件？

還記得前面的組件轉(zhuǎn)換器嗎，它除了用來遷移存量組件外，也是作為一種過渡方案存在，通過 「woodman-cli + 轉(zhuǎn)換器」的組合，可以用來應急滿足新組件的開發(fā)，但問題也比較明顯：

1）woodman-cli 存在無法全真預覽，無法使用新平臺的核心能力；

2）組件開發(fā)鏈路工程化程度低，人工依賴性強。

是時候打造一套全新的組件開發(fā)工具了！前期花費大量心血設計的新架構(gòu)也能在此該發(fā)揮出巨大優(yōu)勢：通過 4 大模塊組裝出新的開發(fā)工具面板，抹平和制作頁的環(huán)境差異，提供能力完整、體驗一致的開發(fā)體驗。

有了核心的開發(fā)面板，再結(jié)合一些工程化配套能力的建設，我們打造的新開發(fā)工具 eva-cli 也就呼之而出了：

1）提供 No Code 模式下的配置工程化指令，覆蓋業(yè)務組件開發(fā)全流程；

2）建設新組件中心，與工具鏈深度整合，接入審核流程，實現(xiàn)組件【開發(fā)-使用-管理】的一棧式解決方案。

eva-cli 架構(gòu)：No Code 模式 & 組件開發(fā)流程前后對比

3.階段建設成果

活動平臺新架構(gòu)一階段的落地，順利解決了 No Code 模式下剩余的 20% 系統(tǒng)性難題，為運營和業(yè)務開發(fā)帶來了體驗質(zhì)的提升：

• B/C 兩端渲染表現(xiàn)一致，保證低代碼平臺所見即所得核心體驗的可靠穩(wěn)定；
• 搭建/開發(fā)框架一致，極大提高開發(fā)體驗、減少環(huán)境差異帶來的開發(fā)問題；
• 圖層、畫布架構(gòu)升級，支持標簽卡+任務、彈窗+抽獎等復雜組合的實時預覽和交互操作；
• 新開發(fā)工具 eva-cli 完成了 No Code 模式下組件開發(fā)能力的閉環(huán)。

同時也在業(yè)務上取得了新的突破，幫助業(yè)務取得了一定的增長：

• 友好的開放能力快速建立起組件生態(tài)和業(yè)務多樣性：
• 截至目前已接入 10 條垂類業(yè)務線：直播、大會員、賽事、貓耳、創(chuàng)平、商業(yè)、OGV、漫畫、版權音樂、課堂；
• 平臺組件生態(tài)：57 個 H5 組件、48 個 PC 組件；
• 垂類組件生態(tài)：153 個 H5 組件、90 個 PC 組件；
• 平臺整體技術升級，使得像集卡組件、答題圈子這類交互和配置復雜度很高的整合營銷玩法組件化落地成為可能；

復雜整合營銷玩法組件 & 工程化開發(fā)依賴的平臺能力

4.3 三階段

活動平臺經(jīng)過前面兩個階段建設下來，已經(jīng)完全重構(gòu)了整個 No Code 模式，包括運營搭建頁面流程和業(yè)務開發(fā)生產(chǎn)組件流程。我們長線規(guī)劃的最后一步，技術圖譜里還差這么幾塊拼圖：

1）缺少 Low Code 工程化能力，無法滿足大型活動的定制模塊開發(fā)需求；

2）缺少 Pro Code 工程化能力，無法滿足個別活動的完全定制開發(fā)需求；

3）C 端頁面加載性能較差，難以滿足司級活動的頁面性能要求。

1.技術架構(gòu)設計

因此，這階段的架構(gòu)變化，即在新的框架基礎上，拓展 Low Code & Pro Code 模式，補全平臺開放能力：

1）eva-cli 增加 Low Code 工程化能力，打通代碼塊組件開發(fā)流程；

2）eva-cli 增加 Pro Code 工程化能力，結(jié)合制作頁開發(fā)模式和片段加載器，打通定制活動開發(fā)流程；

5）eva-server 增加框架預渲染能力，提升 C 端頁面加載性能。

圖片

2.重點建設案例

a. Low Code 模式

代碼塊開發(fā)模式服務于半搭建半開發(fā)的活動場景。業(yè)務開發(fā)者在運營搭建好頁面框架的基礎上，通過 eva-cli 生產(chǎn)一次性的定制功能代碼塊組件，并上傳到制作頁供運營當普通組件使用，來完成頁面的定制功能開發(fā)。

該模式存在以下特點：

• 配套有開發(fā)環(huán)境下的工程化解決方案：eva-cli 代碼塊組件開發(fā)指令；
• 遵循平臺「組件化」原則，代碼塊本質(zhì)上是一次性組件，符合平臺組件規(guī)范，可以完全復用平臺現(xiàn)有能力，包括畫布預覽、圖層拖拽嵌套、表單配置等等；
• 與頁面深度結(jié)合，支持在開發(fā)環(huán)境下拉取活動頁面數(shù)據(jù)，在開發(fā)環(huán)境與頁面直接交互，操作頁面數(shù)據(jù)，并實時預覽效果；
• 無需走組件中心審批流程，與頁面直接綁定，支持直接發(fā)布供運營線上使用，同時也支持本地配置好代碼塊后一鍵同步到線上頁面。

圖片

eva-cli 增加 Low Code 模式 & 代碼塊組件開發(fā)流程復用度對比

來直觀感受下本地開發(fā)代碼塊的體驗：

圖片

示例：S14 征稿活動代碼塊本地開發(fā)環(huán)境

主要功能一覽：

1）【數(shù)據(jù)展示模塊】：顯示關聯(lián)的活動及制作頁，用于拉取線上頁面數(shù)據(jù)；

2） 【數(shù)據(jù)管理】：擁有管理本地數(shù)據(jù)的能力，可以新建本地頁面，切換頁面，頁面?zhèn)浞荩?/p>

3）【保存】：保存本地數(shù)據(jù)到【數(shù)據(jù)管理】中，方便備份本地數(shù)據(jù)；

4）【僅發(fā)布代碼塊】：僅將代碼塊發(fā)布到活動上，本地頁面數(shù)據(jù)不會同步到制作頁，需要到活動頁上進行手動拖拽添加；

5）【同步到制作頁】：代碼塊發(fā)布 & 頁面同步 一站式操作，同時有沖突檢測保護機制。

總結(jié)下 Low Code 模式的工程化成果：

圖片

b. Pro Code 模式

Pro Code 模式服務于少數(shù)需要全定制開發(fā)的業(yè)務場景。比如個別大型活動，需要使用動畫框架、定制模板能力或者定制渲染器。那么業(yè)務開發(fā)者可以使用 eva-cli 定制開發(fā)頁面后，通過平臺來發(fā)布和管理頁面。同時如果頁面有部分模塊是可以復用平臺組件的，那么可以基于平臺的片段加載器能力，來直接復用運營搭建的頁面片段，提高開發(fā)效率。

該模式存在以下特點：

1）配套有開發(fā)環(huán)境下的工程化解決方案：eva-cli 代碼模式開發(fā)指令；

2）打通了制作頁的代碼模式，無縫使用平臺提供的頁面部署、管理、數(shù)據(jù)回收分析等能力；

3） 支持使用片段加載器來提效：從核心渲染器（EvaRender）封裝出片段加載器 runtime，并打包成適配不同框架的 npm 包供代碼開發(fā)場景引入使用，通過傳入活動 ID 來渲染出對應的平臺搭建頁面。主要使用場景是在代碼開發(fā)中復用平臺搭建的頁面片段，最大化利用平臺組件生態(tài)來降低開發(fā)成本。

eva-cli 架構(gòu)：新增 Pro Code 模式 & Pro Code 模式開發(fā)流程

同樣總結(jié)下 Pro Code 模式的工程化成果：

圖片

c. 頁面性能優(yōu)化

活動平臺搭建出來的活動頁面是 SPA，除了一些常規(guī)優(yōu)化外，沒有針對首屏加載場景做額外優(yōu)化，導致頁面加載白屏時間較長，影響用戶體驗。另外一些大型活動對頁面性能和用戶體驗要求更高，因此需要針對首屏場景做一輪性能優(yōu)化，來減少頁面白屏時間，提高用戶體驗。

技術選型上需要優(yōu)先考慮保持 B/C 兩端的渲染一致性，以及不對現(xiàn)有組件生態(tài)帶來額外適配成本，因此：

1）我們選擇了對 runtime 侵入性最小的方案：只改造框架類組件（頁面組件、基礎容器組件、圖片組件、視頻組件）；

2） 框架類組件改造成支持打包 server bundle，供 eva-server 構(gòu)建頁面時預渲染環(huán)節(jié)使用；

3） eva-server 服務增加預渲染環(huán)節(jié)，C 端 runtime 增加預渲染能力；

4） 同時我們建設了完整的數(shù)據(jù)埋點上報分析鏈路，來監(jiān)控對比頁面性能提升情況。

預渲染技術方案簡易模型

頁面性能優(yōu)化上線后，以《黑神話：悟空》活動為例，單頁面 FCP 性能指標下降了 35%

圖片

3.階段建設成果

至此，活動平臺長線技術規(guī)劃圖譜建設完畢，補全了欠缺的兩塊開放能力拼圖，以及頁面性能大幅提升，能滿足各種不同的業(yè)務開發(fā)場景。并在業(yè)務實踐中取得了出彩的成績：

Low Code + Pro Code 支撐起司級活動開發(fā)

1） Low Code 模式 + 頁面性能優(yōu)化建設，保障活動平臺順利承接了 S14 司級活動的開發(fā)！

2）預渲染技術方案簡易模型  Pro Code 模式，為 Q4 的用戶年報司級活動提前鋪路。

圖片

S14 Low Code 示意 & 活動效果

性能優(yōu)化帶來可觀的收益

1） H5 頁面 FCP 周均值指標從 1792ms 降至 1484ms，即訪問頁面的白屏時間降低了 17.2%；

2） H5 頁面停留時長周均值指標從 7973ms 升至 8604ms，提高了 7.91%

圖片

五、建設總結(jié)

5.1 整體技術架構(gòu)

經(jīng)過三個階段的迭代演進，活動平臺整體架構(gòu)可以概括成：5 + 4 + 3 + 2。即：

• 5 塊服務：eva + eva-server + page-service + eva-cli + core-modules
• 4 大模塊：渲染器 + 圖層樹 + 屬性表單 + 組件列表
• 3 種模式：No Code + Low Code + Pro Code
• 2 個生態(tài)：組件生態(tài) + 數(shù)據(jù)源生態(tài)

圖片

5.2 整體建設成果

我們基于短線長線兩條腿走路的策略，經(jīng)過三個階段建設下來，既保障了業(yè)務無阻塞地正常開展，又通過漸進式迭代實現(xiàn)了技術架構(gòu)的長線升級。雖然歷時較久，但勝在穩(wěn)健有序?？偨Y(jié)來說就是，新活動平臺建設助力活動業(yè)務又快又好！

快：活動提效明顯

• 新平臺已實現(xiàn)原活動制作平均 3 人日/單活動（頁面搭建 1 人日 + 數(shù)據(jù)源配置 1.5 人日 + 功能調(diào)試 0.5 人日），人效提升至 0.48 人日/單活動（3.85h），主站運營平均 208 個/月活動，總計節(jié)省人力約 524 人日/月，主站運營上半年節(jié)省人力約 3144 人日；
• 截止 H1 的平臺覆蓋效果，全司活動可節(jié)省運營人效 578 人日/月；

好：活動效果可觀

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

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

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

圖片

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

六、未來規(guī)劃

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

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

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

3）探索結(jié)合 低代碼 + MLLM（Multimodal Large Language Model - 多模態(tài)大語言模型） + D2C（Design2Code - 設計稿轉(zhuǎn)代碼） 的可能性；

4） 結(jié)合大量的活動數(shù)據(jù)分析，建立活動效果評估系統(tǒng)，通過數(shù)據(jù)驅(qū)動發(fā)現(xiàn)有潛力有價值的活動玩法，為業(yè)務創(chuàng)新提供更多可能性。