一、大型活動所面臨的技術(shù)挑戰(zhàn)

CNY（春節(jié)活動）是快手重要的年度專項之一。平臺在春節(jié)期間推出多種互動玩法，內(nèi)容會場作為預(yù)熱、除夕和留存階段的核心載體，先后支撐了“快手有年味”、“老鐵晚會”、“龍之頁”、“明星陪你過大年”等多項活動。這些頁面以內(nèi)容消費為主，致力于將內(nèi)容與玩法創(chuàng)新結(jié)合，以更好地實現(xiàn)業(yè)務(wù)目標(biāo)。

快手低代碼搭建平臺（簡稱“積木”）是快手核心的運營活動頁面構(gòu)建基礎(chǔ)設(shè)施，目前已承擔(dān)90%以上的活動頁面搭建工作。在2025年CNY內(nèi)容會場中，共包含18個會場和40多個頁面。作為技術(shù)支撐方，為高效、高質(zhì)量支持業(yè)務(wù)團(tuán)隊，需重點解決以下問題：

• 高效方面：盡可能通過無代碼方式滿足需求。這就要求搭建方式足夠靈活、易于組合，并對無法直接搭建的創(chuàng)新需求提供快速定制開發(fā)能力。
• 高質(zhì)量方面：保障用戶滿意度。需確保頁面性能達(dá)標(biāo)，提供流暢的視頻與直播消費體驗，并在多端實現(xiàn)一致且高還原度的視覺表現(xiàn)。

在這一背景下，積木平臺主要面臨以下四大技術(shù)挑戰(zhàn)：

挑戰(zhàn)一：復(fù)用與創(chuàng)新的天然矛盾

低代碼平臺普遍面臨復(fù)用與創(chuàng)新之間的內(nèi)在矛盾，主要體現(xiàn)是平臺設(shè)計層面和業(yè)務(wù)創(chuàng)新層面的沖突。
![截屏20250929 11.47.20.png]）。
(https://static-ai.51cto.com/images/202509/b21621c696073c22d0b937eb32adccde652265.png?x-oss-process=image/resize,w_820,h_428)

盡管積木平臺已積累300多個組件，覆蓋多數(shù)常規(guī)業(yè)務(wù)場景，但在支持大型“創(chuàng)新型”活動方面仍可能存在不足。增加組件數(shù)量是否能徹底解決該問題？理論上是可行的，但是需求是無止境的，而組件開發(fā)人力資源有限。持續(xù)擴(kuò)充組件數(shù)量帶來的邊際收益已明顯遞減——功能覆蓋率與組件復(fù)用率逐漸趨于平穩(wěn)。盲目增加組件并非可持續(xù)方案，需探索新路徑以支持“長尾”創(chuàng)新需求。

接下來將逐一介紹我們是應(yīng)對上述挑戰(zhàn)的解決方案。

挑戰(zhàn)二： 頁面復(fù)雜度導(dǎo)致的性能瓶頸

首先，低代碼平臺搭建的頁面在性能上本身就有一定的天然劣勢，主要原因有以下兩點。其一：組件復(fù)用和通用性設(shè)計導(dǎo)致邏輯冗余，增加了運行時開銷。其二：動態(tài)組件組合使得針對單頁面的性能優(yōu)化變得復(fù)雜。以內(nèi)容會場活動頁面為例，其組件數(shù)量常超過300個，涉及40余種組件類型，進(jìn)一步引發(fā)以下性能問題：

• 組件JavaScript文件加載集中，網(wǎng)絡(luò)請求頻繁，影響首屏加載性能；
• 多組件狀態(tài)管理和JS執(zhí)行產(chǎn)生Long Task，阻塞主線程渲染，導(dǎo)致頁面卡頓。
  
  挑戰(zhàn)三：多播放器并發(fā)渲染的性能挑戰(zhàn)

內(nèi)容會場通常包含大量視頻播放器，某些頁面中甚至同時存在數(shù)十個。播放器數(shù)量與GPU及內(nèi)存消耗呈正相關(guān)，過多播放器可能導(dǎo)致瀏覽器內(nèi)存耗盡，甚至引發(fā)應(yīng)用崩潰。因此，解決多播放器環(huán)境下的性能問題至關(guān)重要。

挑戰(zhàn)四：多端響應(yīng)式布局適配技術(shù)挑戰(zhàn)

原有布局方案采用基于 vw 的等比縮放布局策略，在常規(guī)屏幕上表現(xiàn)良好，但在 Pad 和折疊屏等大屏設(shè)備上，因活動規(guī)范要求需限定最大展示區(qū)域，等比縮放會導(dǎo)致內(nèi)容過寬，影響視覺效果。相比于 rem 單位可以通過設(shè)置根元素寬度來控制最大布局寬度，vw 是基于視口寬度計算的，難以有效約束內(nèi)容區(qū)域，因此成為響應(yīng)式適配中的技術(shù)瓶頸。

接下來將逐一介紹我們是應(yīng)對上述挑戰(zhàn)的解決方案。

二、如何兼顧復(fù)用和創(chuàng)新？

2.1 技術(shù)策略

面對代碼邏輯與業(yè)務(wù)需求的無限性，我們采用低代碼能力對無碼搭建進(jìn)行有效補充。通過“部分搭建+部分定制”的混合開發(fā)模式，最大限度地復(fù)用平臺現(xiàn)有能力，從而顯著提升活動產(chǎn)出的整體效率。具體而言，我們推行“90% 搭建 + 10% 定制”的開發(fā)策略，實現(xiàn)標(biāo)準(zhǔn)化與定制化的深度融合，真正做到“你中有我，我中有你”。

對低代碼平臺而言，復(fù)用與創(chuàng)新之間存在一定程度的天然矛盾，但這一矛盾并非不可調(diào)和，關(guān)鍵在于實現(xiàn)動態(tài)平衡。其本質(zhì)是標(biāo)準(zhǔn)化與靈活性、效率與差異化之間的動態(tài)博弈。我們的目標(biāo)并非消除矛盾，而是構(gòu)建一個“以復(fù)用支撐創(chuàng)新，以創(chuàng)新反哺復(fù)用”的健康生態(tài)，從而服務(wù)更多樣的活動需求。通過建立“創(chuàng)新 → 沉淀 → 復(fù)用 → 再創(chuàng)新”的閉環(huán)機制，我們力求在短期應(yīng)對矛盾，在長期實現(xiàn)共生。

• 短期應(yīng)對：復(fù)用保障基礎(chǔ)效率，局部創(chuàng)新突破場景邊界。
• 長期共生：創(chuàng)新成果反向沉淀為可復(fù)用資產(chǎn)，推動平臺能力進(jìn)化。

2.2 積木平臺：構(gòu)建靈活高效的技術(shù)基座

2.2.1 組件原子化與容器化架構(gòu)設(shè)計

隨著業(yè)務(wù)復(fù)雜度的提升，傳統(tǒng)粗粒度組件架構(gòu)已無法滿足多樣化需求。積木平臺采用組件原子化與容器化的架構(gòu)設(shè)計，將復(fù)雜組件拆解為最小功能單元，通過組合模式實現(xiàn)靈活搭建。

組件：具備獨立功能的最小單元，可直接實現(xiàn)某種業(yè)務(wù)邏輯或交互功能，如按鈕、視頻、圖片等。容器：用于組織和布局其他組件（或子容器）的特殊組件，本身不直接提供業(yè)務(wù)功能，而是通過結(jié)構(gòu)化嵌套實現(xiàn)頁面或模塊的層次化管理。比如聚光燈容器，含有滑動 + 縮放的能力，里邊可以放置任意的非容器組件。

通過組件原子化 + 容器化的組合方式，使得搭建更靈活。例如：一個支持左右滑動并帶有縮放效果的組件，可以將其拆分為“圖片組件” 和 "聚光燈容器"這兩個基本單位。基于這兩類穩(wěn)定單元的不同組合，能夠衍生出豐富的功能玩法，真正實現(xiàn)“以不變應(yīng)萬變”。

2.2.2 母版同步提升搭建效率

需指出的是，組件原子化這類細(xì)粒度拆分方式，在某些場景下可能降低搭建效率，反而不如粗粒度組件配置便捷。例如，當(dāng)用戶需要配置一個包含頭像和關(guān)注按鈕的列表時，若每個卡片都需逐一拖拽配置，尤其當(dāng)數(shù)量達(dá)到數(shù)百個時，重復(fù)勞動將極其繁瑣。

為此，我們引入“母版”機制，通過對原子組件進(jìn)行再組合，有效緩解細(xì)粒度拆分帶來的操作負(fù)擔(dān)。母版可生成子版，用戶通過調(diào)整母版即可統(tǒng)一控制所有子版的UI樣式與布局，實現(xiàn)一鍵同步。具體機制包括：母版中的配置屬性可同步至子版（包括多級子版）；母版中定義的事件也會同步至子版，事件“作用域”仍限于對應(yīng)子版；若某子版已修改自身屬性，則該屬性不再隨母版更新而同步。

2.2.3 邏輯編排串聯(lián)組件

我們通過邏輯編排功能，以可視化方式靈活串聯(lián)組件間的業(yè)務(wù)邏輯，顯著提升復(fù)雜交互的搭建效率。例如，在“用戶點擊直播間預(yù)約按鈕成功預(yù)約后自動觸發(fā)抽獎”這一場景中，邏輯編排可以清晰、高效地定義該流程。

2.2.4 定制開發(fā)

針對個性化需求，平臺提供三大核心能力：

1. 定制化擴(kuò)展能力：為增強組件的適應(yīng)性，支持通過代碼注入方式對組件進(jìn)行擴(kuò)展，使其在保持核心能力的基礎(chǔ)上，能夠靈活響應(yīng)個性化需求。
   

2. 組件白盒化Fork能力：開發(fā)者可直接基于現(xiàn)有組件進(jìn)行修改，通過遠(yuǎn)程編譯打包并上線，還可將調(diào)整后的組件發(fā)布至組件市場，供他人二次編輯或復(fù)用。這樣不僅提升開發(fā)效率，也促進(jìn)了組件生態(tài)的持續(xù)完善。
   

3. 對外開放能力：提供輕量、臨時性的開發(fā)方案，幫助業(yè)務(wù)快速上線并驗證效果。技術(shù)實現(xiàn)上，開發(fā)者可在瀏覽器中直接編寫代碼，無需配置本地環(huán)境，實現(xiàn)“開箱即用”。代碼提交后經(jīng)由遠(yuǎn)程編譯服務(wù)打包，最終發(fā)布至CDN。C端渲染時，將動態(tài)加載該定制組件，并融合平臺的基礎(chǔ)能力——如 Context、Bridge 與數(shù)據(jù)埋點等——使開發(fā)者既能快速實現(xiàn)定制，又能復(fù)用平臺的通用底層能力。Context：用于識別并兼容不同的運行環(huán)境（如快手APP、快影APP、回森等）。Bridge：為 H5 提供與客戶端交互的統(tǒng)一通道。
   

此外，平臺引入AI能力進(jìn)一步降低定制開發(fā)門檻，提升代碼復(fù)用與功能實現(xiàn)效率。例如，開發(fā)者可通過自然語言指令，要求AI在按鈕點擊時前置調(diào)用某個接口，并在成功后再執(zhí)行后續(xù)邏輯。此外，AI還可輔助完成組件的Fork與代碼改寫，顯著提升定制開發(fā)的效率與質(zhì)量。與此同時，我們也提供了VS Code的插件，開發(fā)者可以在自己的IDE 中進(jìn)行定制開發(fā)。

三、高性能渲染架構(gòu)與優(yōu)化策略

上文提到在大型運營活動場景中，頁面組件數(shù)量往往達(dá)到約300個，涉及約40種組件類型。此類多組件頁面在默認(rèn)按序加載和執(zhí)行JS文件的情況下，容易導(dǎo)致整體渲染性能下降。其背后主要原因是組件加載頻繁觸發(fā)Reflow、Repaint和組件同步渲染，JS 執(zhí)行存在Long Task，導(dǎo)致卡頓。針對此問題，我們采用SSG 靜態(tài)生成方案以及組件渲染優(yōu)化策略，下文將詳細(xì)介紹細(xì)節(jié)。

3.1 SSG 靜態(tài)生成方案

相較于客戶端渲染（CSR）和服務(wù)端渲染（SSR），靜態(tài)站點生成（SSG）更適用于低代碼搭建類頁面。這類頁面結(jié)構(gòu)通常基于現(xiàn)有組件組合而成，在構(gòu)建階段即可確定，無需復(fù)雜運行時邏輯，因此非常適合在編譯時生成靜態(tài)內(nèi)容。

采用SSG的核心目標(biāo)是“揚長避短”：

• 將盡可能多的運行時計算提前至發(fā)布階段完成；
• 基于頁面結(jié)構(gòu)相對固定、首屏動態(tài)內(nèi)容較少的特點，充分發(fā)揮SSG在性能上的優(yōu)勢。

SSG 實現(xiàn)過程如下：

上面是對整個頁面做的SSG，但是在實際渲染過程中，用戶優(yōu)先看到的是首屏的內(nèi)容，可以進(jìn)一步優(yōu)化首屏的性能。優(yōu)先只渲染首屏的組件，當(dāng)首屏組件渲染完畢之后，再渲染非首屏組件。

那么，具體怎么確定首屏組件呢，我們這里采用的方案主要有以下幾個方面。需要考慮以下三點：

• 根據(jù)配置的高度基準(zhǔn)值做參考，小于基準(zhǔn)值的會被標(biāo)記為首屏元素。但是會排除掉像彈窗、抽屜、非默認(rèn)激活的Tab等容器中的元素。
• 相對屏幕定位的元素。
• 和首屏元素有綁定關(guān)聯(lián)關(guān)系的元素。比如首屏的預(yù)約人數(shù)的組件，依賴非首屏的預(yù)約組件，那么非首屏的預(yù)約組件也需要提前渲染。
  
  以下圖節(jié)點為例，受引用關(guān)系和定位影響，部分非首屏元素也需在首屏進(jìn)行渲染：
  
  首屏SSG流程如下：
  

3.2 組件渲染優(yōu)化策略

編輯器設(shè)計：

引擎設(shè)計：

3.2.1?組件分級

渲染為了進(jìn)一步提升?fmp（首次有效繪制），我們對組件做了分級渲染，在編輯器中保存時，提前計算好哪些組件可能在首屏，需要對組件配置做標(biāo)記，將組件主要分了以下三個級別：

• 首屏組件：組件JS采用同步加載方式、組件樣式內(nèi)聯(lián)。
• 次屏組件：組件JS采用異步加載方案、樣式在組件加載完畢后動態(tài)注入。
• 按需組件：比如嵌套在未激活Tab中的組件、彈窗、抽屜等組件。

3.2.2?組件異步渲染

我們采用多項策略優(yōu)化加載性能：

• 預(yù)加載：首屏組件js文件采用?preload?預(yù)加載。非首屏組件采用?prefetch?預(yù)加載，讓其他必要資源提前加載。
• Defer與Async結(jié)合方案：使用 defer 實現(xiàn)JS異步下載，但仍可能因順序執(zhí)行造成阻塞；單純使用 async 可能導(dǎo)致依賴未加載完成而報錯；最終方案：公共依賴文件采用 defer，組件的代碼文件采用 async。具體做法是公共依賴文件SSG時直接輸出到HTML文件中，組件文件在Engine中采用動態(tài)創(chuàng)建的方式。
• JS文件動態(tài)激活：為避免某些瀏覽器中 preload/prefetch 失效導(dǎo)致重復(fù)請求，SSG 階段將 script 輸出為 type=“text/plain”，在適當(dāng)時機再切換為 type=“text/javascript” 執(zhí)行，例如：

<script src="engine.js"?defer></script>
<script src="context.js"?defer></script>
<script class="reload-script"?type="text/plain"?src="A.js"?async></script>
<script class="reload-script"?type="text/plain"?src="B.js"?async></script>

3.2.3 首屏樣式合并

針對多組件場景，動態(tài)插入style導(dǎo)致頻繁Reflow、Repaint?的問題，在SSG階段，會將首屏的組件css直接輸出到HTML文件中，生成后的樣式如下。

<style id="jimu-pre-style">
?// SSG 樣式
</style>
<style>
?// 對首屏的組件樣式進(jìn)行合并，直接輸出在HTML中
</sytle>

3.2.4 組件體積優(yōu)化

一方面，我們將工具鏈從?webpack?平滑遷移到?rspack，rspack?在構(gòu)建速度，體積壓縮方面都有了比較大的提升。另一方面，采用?autopolyfill?的方案按需引入?polyfill?產(chǎn)物，使得組件體積大幅減小。綜合來看，平均產(chǎn)物大小減少 65.91%，平均產(chǎn)物 Gzip壓縮 后大小減少百分比 68.37%。

四、多播放器調(diào)度引擎設(shè)計

內(nèi)容會場通常包含大量視頻和直播組件，多播放器并發(fā)渲染對頁面性能構(gòu)成嚴(yán)峻挑戰(zhàn)。為此，我們設(shè)計了一套智能播放器調(diào)度引擎，以系統(tǒng)化地應(yīng)對播放沖突、性能開銷與用戶體驗等問題。

針對這個問題，解法也比較明確，就是采用單實例。在單實例播放模式下，播放器切換時需銷毀原有實例，因此必須保存其播放狀態(tài)，確保再次激活時能夠?qū)崿F(xiàn)無縫續(xù)播。播放器實例銷毀后畫面會消失，若不做處理將嚴(yán)重影響用戶體驗。我們考慮了兩種方案：

• 使用封面圖：可能因頻繁切換導(dǎo)致視覺閃爍，體驗較差；
• 將當(dāng)前畫面保存為靜態(tài)圖像：優(yōu)先選用該方案，在播放器銷毀前將當(dāng)前視頻幀導(dǎo)出為圖片并展示。
  

此外，我們建立了如下機制實現(xiàn)播放器的智能調(diào)度：

1. 播放器收集與排序：將所有播放器實例收集到統(tǒng)一隊列中，按其在頁面中的位置（如 top 值）排序，確立播放優(yōu)先級；
2. 播放候選選擇：優(yōu)先選擇“漏出比例”為1（即完全進(jìn)入視口）的播放器；
3. 播放狀態(tài)保持：若已有播放中的實例，則不中斷當(dāng)前播放；
4. 用戶行為優(yōu)先：用戶主動點擊某播放器時，立即播放該元素，不受漏出比例限制（需記錄該操作時的漏出比例，后續(xù)根據(jù)比例變化動態(tài)調(diào)整是否切換播放）。

然而，在引入聚光燈、彈窗、抽屜等動態(tài)容器后，播放決策變得更為復(fù)雜。盡管可通過事件配置（如“聚光燈激活時播放指定視頻”或“彈窗打開時播放視頻”）實現(xiàn)精準(zhǔn)控制，但也帶來了配置復(fù)雜度上升的問題。

若不配置事件，可能出現(xiàn)以下問題：

在聚光燈輪播過程中，因中間元素漏出比例暫時小于1，引擎可能錯誤地播放下方視頻，而非用戶預(yù)期中的聚光燈內(nèi)容。

動效（如變換、位移、縮放、透明度變化等）會影響元素位置與可見性，進(jìn)而干擾播放決策。為解決該問題，我們監(jiān)聽動畫結(jié)束事件。為確保動效結(jié)束后正確選中聚光燈內(nèi)的元素，我們優(yōu)先選擇與當(dāng)前播放元素距離最近的候選元素，這更符合用戶視覺動線，也避免因 IntersectionObserver 返回順序混亂而誤判。

const animation = element.getAnimations();
animation.addEventListener('finish', handleAnimationEnd);
animation.addEventListener('cancel', handleAnimationEnd);

用戶滑動頁面時，若實時切換播放器，在聚光燈等動效場景中可能因中間狀態(tài)頻繁觸發(fā)銷毀與重建。因此，我們引入延遲處理機制（pending），避免中間過程被感知，既提升切換效率，也減少不必要的性能開銷。

理想的浮層播放策略是允許新出現(xiàn)的上層元素?fù)屨疾シ艡?quán)，但這會與既定統(tǒng)一策略沖突，并可能違背用戶預(yù)期。傳統(tǒng)做法是通過事件或容器感知實現(xiàn)播放中斷，但會引入組件間耦合。我們采用的解耦方案是：當(dāng)檢測到當(dāng)前播放元素被遮擋時，自動切換到位于遮擋物上層的播放器。通過如下方式判斷元素層級：

const { x, y } = target.getBoundingClientRect();
const elements = document
? ? ? ? .elementsFromPoint(Math.max(x + 1, 0), Math.max(y + 1, 0));

未來隨著標(biāo)準(zhǔn)發(fā)展，也可借助 trackVisibility 等新特性進(jìn)一步優(yōu)化可見性追蹤。低代碼平臺中的視頻播放調(diào)度遠(yuǎn)比通常情況復(fù)雜，本文僅勾勒了核心思路與實現(xiàn)路徑。

五、多端布局適配

在大型活動中，設(shè)計規(guī)范通常要求頁面在 Pad、折疊屏等寬屏設(shè)備中限制最大寬度，實現(xiàn)兩側(cè)留空的視覺效果。然而，平臺原有布局方案采用 vw 單位，其計算依賴于視口寬度，無法像 rem 一樣通過根元素字體大小限制整體布局寬度，因此需引入新的適配機制。我們調(diào)研了行業(yè)內(nèi)多種適配方案，結(jié)合其優(yōu)缺點及業(yè)務(wù)需求后認(rèn)為：CSS calc 兼容現(xiàn)有布局，維護(hù)成本低，但性能仍需進(jìn)一步驗證。為驗證性能表現(xiàn)，我們針對兩類典型頁面進(jìn)行了多機型測試，實驗結(jié)果表明，在超復(fù)雜頁面（包含組件385個，節(jié)點1310個），Android 性能無明顯差異，iOS 內(nèi)存占用增加約 80MB。在復(fù)雜頁面，選取歷史中組件較多的頁面，含組件 335 個，節(jié)點 1240 個的情況下，Android 和 iOS 性能表現(xiàn)均無顯著差異。

綜合多方數(shù)據(jù)，最終評估后，選擇基于 CSS calc 的實現(xiàn)方案。

在技術(shù)實現(xiàn)層面，我們引入一個 CSS 自定義變量 --jimu-responsive-ratio，默認(rèn)值為 1，并根據(jù)預(yù)設(shè)最大寬度動態(tài)計算縮放比例：

const WIDTH_MAX = 500;
const scale = WIDTH_MAX / window.screen.width;
const rootNode = document.documentElement || document.querySelector(':root');
rootNode.style.setProperty(CSSRootVar.RESPONSIVE_RATIO, `${scale}`);

同時調(diào)整渲染邏輯，將原有的 vw 單位替換為 calc 表達(dá)式，例如：

left: `calc(${num}vw*var(${CSSRootVar.RESPONSIVE_RATIO}, 1)${offset})`;

由于 fixed 定位基于視口，內(nèi)容區(qū)域限制最大寬度后可能出現(xiàn)元素偏移。為此我們引入偏移量變量進(jìn)行補償：

const offset = (clientWidth - MAX_WIDTH) / 2;
rootNode.style.setProperty('--jimu-responsive-offset', `${offset}px`);

在樣式生成過程中，對使用 fixed 定位的元素額外添加該偏移量：

六、總結(jié)與展望

本文以CNY內(nèi)容會場為例，系統(tǒng)闡述了積木平臺在架構(gòu)設(shè)計、性能優(yōu)化與系統(tǒng)集成等方面的技術(shù)實踐與落地成果。通過體系化的技術(shù)架構(gòu)，積木平臺有效平衡了高效搭建與業(yè)務(wù)創(chuàng)新之間的關(guān)系，通過SSG靜態(tài)生成、組件分級渲染與異步渲染等關(guān)鍵技術(shù)，解決了300+組件加載的頁面性能瓶頸，實現(xiàn)了大規(guī)模組件場景下的流暢體驗。

單一技術(shù)問題的解決方案往往并不復(fù)雜，但當(dāng)其置于低代碼平臺這一復(fù)雜架構(gòu)背景下時，技術(shù)挑戰(zhàn)呈指數(shù)級上升。期望本文所分享的經(jīng)驗與思路，能為面臨類似問題的技術(shù)團(tuán)隊提供有益的參考。展望未來，我們將持續(xù)探索積木平臺與AI技術(shù)的深度融合，進(jìn)一步拓展低代碼平臺的能力邊界，為更廣泛的業(yè)務(wù)場景賦能。

【END】