本文將介紹，淘寶直播前端團隊為提升業務觸達效率而設計的零代碼彈窗動態化方案。業務背景眾所周知，產品有三寶：彈窗，紅點和引導。在淘寶直播業務裡面，每當有功能上新、活動邀約、系統消息、獎勵發放等事件發生時，我們通常采用彈窗來及時告知目標用戶。可見彈窗是一項極其重要的觸達手段，它打通瞭平臺與主播的信號傳達通路。為瞭能高效快捷地與主播傳遞信息，我們必然要犧牲彈窗的視覺效果和靈動性。因此，過去的彈窗基本上由純文本或單張圖片組成：圖1 傳統純文本或圖片彈窗當然，由純文本或單張圖片構成的彈窗往往缺乏視覺張力，使用戶不能在短時間內閱讀並理解彈窗內容，造成觸達效率下降。另外，由於無法定制業務邏輯，主播不可以在彈窗上及時做出反饋動作，造成用戶體驗和觸達效率的進一步下降。因此，為瞭能在前端開發資源有限的前提下，提供更加美觀、靈活的彈窗形式，提升業務觸達效率，淘寶直播前端團隊設計瞭一套零代碼彈窗動態化方案（No-Code Dynamic Popup）。方案探索為瞭使彈窗的視覺效果更加多樣、交互更加靈活，在不依賴客戶端發版的前提下，必然要引入前端到各個需求的開發流程中來。因此，我們站在前端視角對彈窗這一場景進行瞭技術方案調研。▐方案一：傳統開發流程我們首先能想到的是按傳統需求交付 SOP 來開發彈窗。當然，在初期階段我們確實采取過這種流程並在今年年初上線瞭最早的幾個 H5 彈窗。圖2 傳統開發流程圖如圖 2 所示，傳統產研流程需要把彈窗從其父需求中拆解出來，因為彈窗通常不是一個獨立的需求，它是作為某個功能迭代、活動/任務上新等業務的附屬需求。拆解完後經過需求評審，再由設計師出手設計彈窗的視覺稿，然後分別進入各端的開發、聯調階段。客戶端已經有瞭現成的 H5 彈層容器（WebViewLayer）故不需要投入開發；服務端也有瞭成熟的配置方案（疲勞度、優先級等）並且需要返回給前端的字段不多，因此工作量也不大。而前端由於缺少相關基礎設置，需要把彈層當作一個頁面從零開始投入，具體包括工程初始化、視覺稿還原（視圖層開發）、業務邏輯實現、Mock 數據、接口聯調、冒煙測試等。這一系列「組合拳」下來至少要花費 1.5 至 2 天的開發時間，在交付流程中位於「關鍵路徑」之上，若出一點問題就有可能影響整個需求的交付。因此我們需要尋找一個更加敏捷的方案。▐方案二：斑馬搭建眾所周知，集團內有一個神器「斑馬搭建」，它是一個頁面搭建平臺。提供瞭文本、圖片、熱區鏈接等基礎組件，可使用戶通過「搭積木」的方式快速搭建出大促、活動頁面。在淘寶直播，斑馬搭建也在素材中心的素材生產環節起瞭重要作用。然而在彈窗場景下，若使用斑馬搭建會帶來如下問題：搭建平臺功能受限，無法對標 Sketch、Photoshop 等專業制圖工具，限制設計師做出高級視覺效果；給設計師引入瞭額外學習成本和工作量；交互邏輯局限，不足以滿足直播彈層業務訴求。上述 1、2 點比較好理解，斑馬搭建不能像 Sketch、Photoshop 等制圖工具一樣實現復雜的效果，因此需要設計師通過其他制圖軟件設計好後，切圖導入到斑馬上來，這無疑增加瞭設計成本。為瞭讓用戶及時做出響應，我們需要在彈窗上實現一些復雜的業務邏輯。如點擊按鈕調用 Mtop 接口並通過 toast 反饋給用戶結果等。這種形式的業務邏輯無法通過斑馬實現，也就是問題 3 所在。▐方案三：imgcook 智能解析斑馬搭建給我們實現彈窗提效帶來瞭很好的啟發，但我們發現 imgcook 能更好地服務於直播彈層場景。據官方宣傳材料，imgcook 采用計算機視覺、深度學習等智能化技術，能夠智能解析視覺稿並生成 H5 頁面，賦能前端開發。這聽起來很誘人，但通過調研我們也找到瞭 imgcook 的痛點問題：生成的代碼可維護性差，不利於後續迭代；生成的頁面存在適配問題；若要實現自定義業務邏輯，仍依賴代碼侵入。不過彈窗業務也具有其特殊性，它們巧妙地抵消瞭上述痛點問題 1 和 2：生命周期短，一個彈窗一般不會有後續迭代；大小固定，無需考慮不同尺寸屏幕下的適配問題。因此我們可以借助 imgcook 的優勢，即視覺稿還原能力，然後實現出直播彈窗場景下的 NoCode 彈窗生成方案。圖3 imgcook 的 logo如何實現彈窗自由▐目標借助成熟的前端智能化技術，打造淘寶直播觸達彈窗領域下的無代碼解決方案，解放前端開發，賦能業務上線，提高業務觸達效率。▐生產側流程我們知道完整的前端開發流程可以簡化為視圖層和邏輯層的編碼，在彈窗場景下也是如此。通過上述方案探索，我們瞭解到 imgcook 可以很好地 cover 掉視圖層的工作量，但我們仍需要實現一套立足於直播彈窗業務的搭建平臺來處理生產環節中邏輯層部分，即直播彈窗生成器。圖4 簡化版前端開發流程下圖是動態彈窗生產鏈路：圖5 新方案流程圖第一步，上傳並解析視覺稿首先由設計師將彈窗的視覺稿上傳到 imgcook 工作臺，對於視覺還原不準確的地方可以通過工作臺的圖形界面進一步調整。在 imgcook 內部，會通過一份數據來做結構化的描述。這份數據從設計工具（如 Sketch、PhotoShop）導出開始，流經一系列的數據處理環節，最終生成一份模塊從而產出代碼。這份結構化數據信息描述叫做 schema。圖6 智能解析視覺稿第二步，配置彈窗信息解析完視覺稿後，需要移步直播彈窗生成器（目前位於小二工作臺）。生成器會首先要求配置彈窗的基本信息，比如彈窗名稱、尺寸、SPM 等。圖7 配置彈窗信息第三步，導入 schema由於彈窗具有無需迭代的特殊性，我們並不需要 imgcook 幫助我們生成最終的代碼，隻需要提供結構化描述信息即可。在生成器的第二步，我們需要導入 imgcook 生成的 schema。在右側的預覽畫面中可以看到渲染結果，當然這隻是還原瞭視覺稿中的靜態效果。圖8 導入 Schema第四步，上傳數據模型並綁定事件為瞭實現彈窗的動態化，我們需要通過接口下發的圖片或文案來替代視覺稿中的相應元素，同時增加一些簡單的可交互邏輯。我們歸納出彈窗中的動態邏輯如下：動態文本（如主播名稱、獎勵流量數）動態圖片（如頭像、等級標志）行動點（如跳轉 H5，喚起 Native 頁）發起一個 mtop 請求（如領取任務組）發起一個埋點上報通過循環生成一個簡易列表直接關閉彈窗我們對上述可枚舉的業務邏輯進行封裝，並實現瞭基於圖形界面的字段映射和事件綁定能力。如下圖所示，這個工具包含兩個模塊：靜態預覽和動態綁定模塊。我們可以在預覽模塊選中一個元素，選擇需要的動態化類型，那麼便可在右側完成字段或事件的綁定操作，讓靜態彈窗「動」起來。圖9 彈窗動態化第五步，預覽並配置動畫自從今年 5 月初動態彈窗上線以來，我們已經基於此快速上線瞭多個業務彈窗。特別的，我們在今年 618 大促期間上線瞭 618 主播任務的彈窗，目的是吸引用戶參加大促，賦能主播成長和等級躍遷。但在復盤業務數據時，我們可以明顯看到任務的領取率不高。通過投放效果分析，發現根本原因是彈窗的點擊率低，很多用戶在彈窗出現後便直接關閉瞭，原因可能是不小心碰到，或思維慣性造成的。為瞭解決彈窗停留時長短，用戶點擊率低的問題，我們打算從視覺效果上入手，通過華麗的彈窗打開動畫吸引用戶眼球，以提高用戶點擊率和業務觸達效率。動效的具體實現方式為 lottie 和 CSS 動畫，lottie 作為彈窗背景動畫，CSS 實現彈窗前景動畫。動畫效果均可拓展。圖10 動畫效果配置最終產物通過智能解析視覺稿，我們獲取到瞭描述頁面視圖層的結構化數據（Imgcook Schema） ；在彈窗生成器上，我們生產出瞭包含彈窗尺寸、SPM、動畫在內的配置信息（Configuration Data）和讓靜態元素動態化的映射數據（Mapping Data）。將上述三者合並便得到瞭最終產物：Popup DSL，這也是我們最終交付和發佈的文件。，時長01:41▐消費側流程目前在淘寶直播供給側，主播工作臺、主播 APP、PC 中控臺和小程序都有彈窗的觸達需求。為瞭統一四端的彈窗表現，我們實現瞭在消費側渲染動態彈窗的 H5 容器。上文提到生產側的最終交付物是一份 Popup DSL 描述文件，那麼彈窗容器的主要工作便是解析這份文件並渲染出來。第一步，裝載彈窗容器無論是在移動端還是 PC 端，我們會在應用啟動時查詢彈窗信息。如果有，接口會返回 Popup DSL 文件以及相應的業務數據結構。在移動端，我們通過 WebView 裝載彈窗容器，並通過 JS Bridge 講 DSL 和業務數據傳遞進去；在 Web 端我們通過 iframe 裝載彈窗容器，通過 Post Message 通信。第二步，渲染視圖層彈窗容器在收到底層傳來的 DSL 描述文件後，會首先解析出其中的視圖層描述信息，即 imgcook schema。然後通過這份描述信息生成 HTML 結構和 CSS 層疊樣式表，將相應的 DOM 節點裝載在前景層，此時彈窗的靜態部分渲染完成。第三步，綁定動態事件當靜態部分渲染完成後，容器會解析出映射數據（Mapping Data），依次為前景層上的元素綁定事件。同時會綁定背景層的點擊關閉事件。第四步，播放動畫如果彈窗有配置動畫，則會將 CSS Animation 作用於前景，在背景播放 lottie 動畫。圖11 彈窗的層級信息實踐案例從今年三月到現在，淘寶直播供給側已通過動態彈窗方案，零代碼生產上線瞭十餘個彈窗案例。雖然每生成一個彈窗隻能減少有限的開發成本，但隨著需求數量的不斷增長，從總體看上是能產生很大的收益的。同時，在上線動畫效果後，彈窗的點擊率從提升到瞭 45%，觸達效率進一步提升。下圖列舉瞭一些動態彈窗案例：圖12 動態彈窗案例心得體會作為業務前端，要避免把自己定位成「切圖仔」，無腦接需求。我們要積極歸納總結出日常工作中的重復部分，並發散思維，看看能否沉淀出一套通用的方法論把我們從機械化的重復中解放出來；需求上線後不能不管不顧，要時常 Review 業務數據並找到不好的地方，並運用我們前端的頭腦給出合適的解法，賦能業務增長；在技術選型時，我們要善於利用各種工具的優勢，並找到巧妙的方法解決掉它的痛點問題。團隊介紹我們是大淘寶內容前端團隊，核心負責淘寶的內容業務（直播、圖文、短視頻）和內容中臺建設，主要業務包括淘寶直播、逛逛、親拍、有好貨，並且也通過平臺化的方式支持著阿裡系的其他內容業務，包括餓瞭麼、盒馬、優酷、閑魚、飛豬等 24 個 BU，160 個業務場景。內容化是一個較新的戰場，整個前端團隊在多媒體、機器學習、播放器、視頻剪輯、LowCode 等技術領域都有比較多挖掘和技術應用。作者|檀鵬程（弈坤）來源:微信公眾號:大淘寶技術出處:https://mp.weixin.qq.com/s/WPJjsHa5NZF0jyZAXQtxow
本文出自快速备案，转载时请注明出处及相应链接。