一、前言

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

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

本文將從新活動(dòng)平臺(tái)（以下簡稱為活動(dòng)平臺(tái)）的建設(shè)歷程展開，闡述我們?cè)谡麄€(gè)開發(fā)過程中的設(shè)計(jì)理念、建設(shè)規(guī)劃和架構(gòu)思考。不同建設(shè)階段中面臨的挑戰(zhàn)，以及活動(dòng)平臺(tái)團(tuán)隊(duì)是如何解決的。希望能對(duì)你有點(diǎn)幫助。

開始之前，先來簡單認(rèn)識(shí)一下活動(dòng)平臺(tái)：

圖片

活動(dòng)平臺(tái)最核心的頁面：制作頁

二、活動(dòng)平臺(tái)是什么

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

2.1 服務(wù)對(duì)象

活動(dòng)平臺(tái)服務(wù)對(duì)象包括運(yùn)營、用戶、研發(fā)三類，其中：

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

2.2 業(yè)務(wù)模式

活動(dòng)平臺(tái)業(yè)務(wù)模式包括 No Code、Low Code、Pro Code 三種模式，其中：

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

三類服務(wù)對(duì)象和三種業(yè)務(wù)模式的關(guān)系示意圖

三、背景和目標(biāo)

3.1 項(xiàng)目背景

為什么要建設(shè)活動(dòng)平臺(tái)，主要有兩點(diǎn)原因：

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

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

3.2 面臨挑戰(zhàn)

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

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

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

1）平臺(tái)體驗(yàn)方面：

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

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

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

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

2）架構(gòu)設(shè)計(jì)方面：

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

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

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

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

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

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

2.外部挑戰(zhàn)

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

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

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

3.3 建設(shè)目標(biāo)

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

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

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

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

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

建設(shè)理念：業(yè)務(wù)優(yōu)先，技術(shù)驅(qū)動(dòng)

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

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

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

基于這個(gè)理念和策略，活動(dòng)平臺(tái)整體建設(shè)規(guī)劃了三個(gè)階段，來逐步推進(jìn)落地。

四、建設(shè)歷程

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

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

1.活動(dòng)平臺(tái)一階段：

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

升級(jí)技術(shù)升級(jí)期，目標(biāo)是助力業(yè)務(wù)增長

2.活動(dòng)平臺(tái)二階段：

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

3.活動(dòng)平臺(tái)三階段：

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

圖片

4.1 一階段

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

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

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

1.技術(shù)架構(gòu)設(shè)計(jì)

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

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

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

圖片

2.重點(diǎn)建設(shè)案例

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

a. 畫布改造

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

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

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

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

previewWrap 工作流程示意

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

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

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

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

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

圖片

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

圖片

舉一個(gè)例子：運(yùn)營配置一個(gè)完成任務(wù)獲得抽獎(jiǎng)機(jī)會(huì)的活動(dòng)：

圖片

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

3.階段建設(shè)成果

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

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

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

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

4）組件優(yōu)化：新增平臺(tái)級(jí)的彈窗、標(biāo)簽卡組件、任務(wù)、抽獎(jiǎng)、征稿等多個(gè)數(shù)據(jù)源組件一體化改造、容器、標(biāo)簽卡等基礎(chǔ)組件優(yōu)化... 等等。

兼具體驗(yàn)和效率的新版制作頁

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

• 解決了 80% 的體驗(yàn)和效率問題，平均搭建耗時(shí) 3.56h，征稿類活動(dòng)搭建耗時(shí) 3.89h，提效 20%+；
• 新搭建流程覆蓋了 42% 選題會(huì)活動(dòng)；
• 簡化了征稿活動(dòng)流程，提效 34%。

 4.2 二階段

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

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

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

1.技術(shù)架構(gòu)設(shè)計(jì)

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

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

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

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

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

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

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

并補(bǔ)齊了一些配套能力建設(shè)：

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

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

3）上線活動(dòng)模板功能；

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

圖片

2.重點(diǎn)建設(shè)案例

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

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

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

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

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

ComponentInfo 組件信息：描述組件的基礎(chǔ)必要信息

a.BaseInfo 基礎(chǔ)信息：描述組件名、分類、版本號(hào)、支持平臺(tái)、縮略圖等信息。

b.PropInfo 表單信息：描述組件在屬性表單面板里有哪些配置項(xiàng)，對(duì)應(yīng)什么控件。

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

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

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

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

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

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

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

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

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

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

組件轉(zhuǎn)換器

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

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

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

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

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

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

渲染邏輯分層

通過對(duì)頁面渲染邏輯的分層設(shè)計(jì)和應(yīng)用，取得了以下成果：

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

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

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

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

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

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

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

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

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

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

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

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

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

新版圖層模塊完成上線后，可以說從底層重塑了活動(dòng)平臺(tái)的拖拽體驗(yàn)：

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

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

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

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

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

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

1）woodman-cli 存在無法全真預(yù)覽，無法使用新平臺(tái)的核心能力；

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

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

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

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

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

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

3.階段建設(shè)成果

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

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

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

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

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

4.3 三階段

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

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

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

3）C 端頁面加載性能較差，難以滿足司級(jí)活動(dòng)的頁面性能要求。

1.技術(shù)架構(gòu)設(shè)計(jì)

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

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

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

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

圖片

2.重點(diǎn)建設(shè)案例

a. Low Code 模式

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

該模式存在以下特點(diǎn)：

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

圖片

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

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

圖片

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

主要功能一覽：

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

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

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

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

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

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

圖片

b. Pro Code 模式

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

該模式存在以下特點(diǎn)：

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

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

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

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

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

圖片

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

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

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

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

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

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

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

預(yù)渲染技術(shù)方案簡易模型

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

圖片

3.階段建設(shè)成果

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

Low Code + Pro Code 支撐起司級(jí)活動(dòng)開發(fā)

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

2）預(yù)渲染技術(shù)方案簡易模型  Pro Code 模式，為 Q4 的用戶年報(bào)司級(jí)活動(dòng)提前鋪路。

圖片

S14 Low Code 示意 & 活動(dòng)效果

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

1） H5 頁面 FCP 周均值指標(biāo)從 1792ms 降至 1484ms，即訪問頁面的白屏?xí)r間降低了 17.2%；

2） H5 頁面停留時(shí)長周均值指標(biāo)從 7973ms 升至 8604ms，提高了 7.91%

圖片

五、建設(shè)總結(jié)

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

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

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

圖片

5.2 整體建設(shè)成果

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

快：活動(dòng)提效明顯

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

好：活動(dòng)效果可觀

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

典型活動(dòng)示例：黑神話悟空（No Code 搭建）

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

圖片

黑神話悟空活動(dòng)：任務(wù)+集卡+答題+圈子的復(fù)雜玩法

六、未來規(guī)劃

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

1） 建設(shè)活動(dòng)頁面質(zhì)量檢測(cè)面板和智能糾錯(cuò)能力，降低運(yùn)營配置錯(cuò)誤率，減少線上問題；

2）探索頁面自動(dòng)化測(cè)試方案；

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

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