手淘雙11最新實踐：PopLayer彈層領域業務研發模式升級

背景

近年來，各大APP內的彈層需求逐漸增多，以手機淘寶爲例，平常的彈層上線頻率爲單端每個月50次左右，而在大促期間能夠達到240次以上。在手淘內，各種彈層業務都會經過PopLayer中間件的能力進行管理。但業務每每會遇到開發彈層難、慢、穩定性差的種種困難。對比於往年業務研發成本較高的現狀，PopLayer在今年提出了【低研發搭建模式】來解決這類問題，造成一套快速搭建+可視化+多端多場景通用的解決方案，在平常與大促期間獲得了普遍應用：

• 研發效率升級：彈層業務的上線成本從3天+，下降到2小時左右
• 業務覆蓋率高：雙11大促期間的業務覆蓋率達到75%
• 穩定性極佳：大促期間線上0故障

在各種APP都逐漸走向存量時代，精細化流量運營的今天，彈層做爲一個能夠隨時隨地產生內容並帶來高流量的強運營手段，已經從低頻需求，變成了面向各種人羣觸達的高頻需求。做爲業務支撐方向的中間件，如何爲業務提效，將業務的關注重點從開發轉向內容運營，助力其完成觸達矩陣，成爲了一件很是值得探索的事情。

（更多幹貨內容請搜索關注【淘系技術】公衆號）

PopLayer

彈層，是一種強觸達用戶的交互形態。PopLayer的定義，則是一個能夠在任何APP頁面上，在指定時間內，對頁面無侵入地彈出任何內容的彈層中間件。其業務定位，則爲觸達各領域用戶的重要流量場。

爲了便於理解，下面以手淘首頁近期Pop爲例，將手淘內的Pop業務分類舉例介紹（本文中Pop即指彈層）：

1. 大促氛圍打造

開售倒計時提醒

1. 加強用戶體驗

死亡恢復瀏覽飄條

1. 紅包發放&提醒

星秀貓開獎

紅包催用提醒飄條

1. 用戶指引

能夠看到，彈層業務的交互形態是靈活多變的，業務目標訴求也各有不一樣。其背後有着各自業務層面的複雜訴求和增加目標。PopLayer爲此提供了一套端側彈層管理SDK+任務管理系統的總體解決方案。

PopLayer常規任務管理流程

注：PopLayer是以端側中間件爲核心進行建設的，其中每一個環節都有比較複雜的鏈路能夠展開，本文不展開討論端側細節，主要討論研發效率方面。

在這套流程中，對業務方負擔最重的，也是研發耗時最重的，即是前端頁面的研發以及服務端接口的研發。且各個業務的曝光預判接口不斷累積，也帶來了很是大的資源浪費與QPS壓力。隨着彈層業務逐年增多，這套模式的弊端愈來愈凸顯：

• 研發效率低下。以平常期間觀察，研發一個圖文類型彈層，至少須要一個前端人員投入三天以上時間+一個後端人員投入三天以上時間+測試人員投入一天以上。
• 運營效率低下。運營策略每每受限於研發成本、資源調控、以及上線時間等等問題，而沒法靈活展開與快速迭代。尤爲在大促期間，不少快速決策的運營玩法沒法及時且穩定地落地，喪失了關鍵時刻獲取流量的機會。
• 研發質量難以保證。不一樣於整頁研發，彈層存在一些特殊須要注意的問題。而研發人員接入PopLayer的流程熟悉程度每每有限，很容易因缺少經驗而產生線上異常，好比只有背景黑色遮罩彈出而內容加載失敗（能夠想想會是什麼情況）
• 業務數據指標沒有統一標準，沒法造成客觀統一的業務指標，沒法經過數據快速定位問題，沒法造成有效的數據沉澱與對比。
• 總體方案難以沉澱複用。

這樣的研發成本，對於Pop這類每每須要快速響應的業務需求，是遠遠不能知足的。尤爲在大促期間，對時效性要求很高，一個Pop從決策到上線，可能僅僅只有1-2個小時的響應時間，一旦錯過期機對業務的流量損失是巨大的。

通過建設搭建模式，這套陳舊野生的研發流程終於獲得了改變。現在，經過新模式，一個常規的單圖Pop幾分鐘就能夠完成搭建。業務方能夠完全解放雙手，集中精力在更加優質的內容編排與製做上。

PopLayer搭建模式對研發流程的影響

-

PopLayer搭建模式

Pop業務背景分析

通過長期與業務深刻合做，咱們發現彈層的需求每每有必定的規律可循。PopLayer領域下的業務特徵大致以下：

• UI結構輕量：主要爲底圖+內部圖文混合的UI結構，視覺複雜度有限
• 點擊交互可枚舉：跳轉頁面、關閉Pop、發送後端接口、切換內部子頁面等
• 組件複用性低、總體複用性高：每一個Pop內部可複用的組件幾乎不存在，更應該以一個完整的Pop做爲一個模板進行維護和複用
• Pop特有邏輯較多，好比疲勞度規則、各種數據來源變量解析等

那麼實現一套統一標準的搭建方案，從先後端等各個方面逐個擊破，來承載業務的大部分高頻需求，支持其快速、低研發迭代上線，便成了解決這類問題的首選方案。

得益於這套標準化的前端協議規則，咱們能夠將PopLayer的觸發範圍，從APP站內觸達，向其餘流量場橫向擴展，好比Android桌面、H5環境等，這部分後文將會展開討論。

搭建模式架構

搭建模式方案框架圖

咱們經過鎖定 低研發搭建+多端多領域統一觸達 的解決方案，支持運營與業務快速完成各種彈層小時級上線。其鏈路主要包括以下幾個部分：

• 搭建
• 設計一套Pop業務域內的統一業務描述DSL，來描述Pop的所有UI架構、數據提取規則、交互邏輯等等內容。以其爲核心，完成搭建與各端各領域的解耦
• 搭建IDE，提供友好的編輯界面、實時動態預覽、真機預覽等業務服務，最終產生標準DSL內容
• 解析
• 探索除APP站內以外的更多觸達領域，包括Android桌面環境、H5環境
• 研發DSL運行時解析引擎，並完成統一體驗的Pop渲染及交互
• 任務管理服務
• 提供一體化人羣曝光預判
• 提供權益、AB與模板搭建的打包配置能力，無需業務方自建實驗、自研權益對接
• 將單場景多Pop狀況下的預判QPS壓力，下降爲單場景組合預判模式，有效下降服務端壓力

搭建

搭建與DSL

DSL，即領域特定描述語言，是爲了解決特定領域問題而造成的編程語言或規範語言。在Pop業務域下，咱們無需造成編程語言，甚至追求儘量低研發，因此這裏的DSL即爲一種Pop業務域範圍內的規範描述語言。

Pop的DSL格式爲經常使用的JSON格式。其總體結構爲pages-UI動線、props-變量解析、requests-請求接口、env-環境全局配置。

下面咱們從交互動線結構、變量解析、事件結構、疲勞度幾個方面分別介紹DSL描述的主要內容。

1. 交互動線與UI結構

交互動線

對應到DSL，咱們提供了多子頁面+多版本的描述方案，即經過建立多個子頁面+每一個子頁面的多個版原本完成動線素材，並經過設置事件動做，完成動線串聯。對應到DSL的結構，即經過pages+vers以樹形結構分別描述各個子頁面版本。其總體示例以下：

佈局版型

Pop的佈局版型是多種多樣的，但基本可歸類爲以下幾種：居中、四角掛角、四邊貼邊。DSL設計中，每個子頁面均可以單獨設置其佈局版型。不一樣的版型，會以不一樣的佈局邏輯計算其大小位置。

UI組件

Pop形態下的UI組件，基於圍繞着以下幾個類型展開：圖片、文本、視頻、容器、倒計時、點擊熱區等。即經過提供大圖或視頻爲背景，並經過容器+內部組件造成內部複雜的界面佈局。咱們針對各個組件提供了統一的佈局配置+各自不一樣的素材配置。以一個倒計時組件爲例：

1. 變量數據提取與綁定

變量數據提取

Pop的內容與服務端數據作綁定時，須要提供一套提取數據的描述方案。而數據來源因Pop的總體鏈路設計，存在多個可能來源。咱們經過 指定數據來源+提供插入式Mtop接口配置+接口數據提取Function 完成數據提取的設置，造成一個變量。仍以上述Demo爲例，其中紅包金額的變量爲服務端Mtop接口返回數據。其提取流程示例：

即經過預判MTOP接口數據源，經過JSONPath，並指定其數據位置完成提取。在某些較爲複雜的狀況下，有時數據來源須要多層解析（JSONPath+URLDecode+URLParse），那麼也支持其設置串行多層解析。

變量綁定

解析結束的變量，即視爲一種全局資源，其能夠綁定到各類內容與其餘數據上，哪裏須要哪裏搬。好比圖片地址、文本內容、toast內容、跳轉地址、MTOP請求參數等等。其實現方案爲經常使用的字符串模板表達式${prop_name}，進行運行時替換。

1. 事件結構

大多狀況下，Pop內的事件，即爲用戶點擊事件，但隨着業務複雜度的提高，例如視頻播放結束、視頻加載失敗、倒計時結束等時機也須要響應事件，咱們便提供了統一的事件描述，方便掛載到各個組件事件配置上。而事件的類型。即爲跳轉場景、切換子頁面、發送MTOP接口、關閉Pop等，咱們分別對這些事件提供了對應的封裝描述。此處細節較多暫不展開。

1. 疲勞度

疲勞度是Pop的重要組成部分之一。疲勞度的設計分爲疲勞度規則+疲勞度消耗規則。例如Pop須要用戶天天曝光不設限，但點擊後當天再也不彈出。那麼其疲勞度規則爲一天一次，而消耗規則即爲點擊時消耗。經過這樣的實現方式，則能夠很是靈活的實現各種疲勞度需求，作到想怎麼彈就怎麼彈。

在DSL的曝光、關閉、以及每一個事件結構中，均有疲勞度消耗規則，而疲勞度總體規則，則經過不一樣的疲勞度表達式完成配置。

搭建IDE

IDE的核心功能，即爲業務用戶提供一個實時可視化、隨時可真機預覽的一站式搭建編輯器。其產出，則是產生一份描述業務完整需求的DSL內容。目前已爲業務提供包括頁面搭建、數據管理、曝光斷定、疲勞度規則、降級策略、埋點配置等方面的搭建功能。

搭建IDE

解析

如方案框架圖所示，搭建模式的目標不只僅是在APP站內完成Pop觸達，還須要在Android桌面、站外H5這樣的環境裏完成一站式多端觸達。咱們能夠把目前涉及的幾個流量域，稱爲觸達領域。

APP站內的觸發流程，即PopLayer端側中間件，功能上有很是豐富的積累，可支撐幾乎全部Pop業務的各方面訴求，此處不進行展開，本文將從彈出Pop後的解析引擎、Android桌面的觸達領域支持方面進行介紹。

運行時解析引擎

針對不一樣的觸達環境，須要造成各自的運行時解析引擎，目前咱們完成了APP站內引擎：負責站內+Android桌面的解析渲染，以及H5站外引擎：負責H5環境下的解析渲染。這裏咱們主要針對站內引擎進行介紹。

PreDisplay + Running

解析引擎的主體工做流程，分爲PreDisplay階段：獲取DSL、獲取各環境數據、解析變量、完成UI渲染並曝光，以及Running階段：在曝光後的事件交互處理。

解析引擎工做流

在執行display以前，Pop爲隱形狀態，用戶無感知。通過如上圖的DSL解析、同步各種環境數據、變量解析、曝光斷定、素材加載等流程後，經過display接口，完成最終曝光。

爲了達到雙端統一的渲染效果、高適配性、以及高性能渲染的要求，站內引擎的底層載體目前爲Rax方案。基於Rax完善的工程化支持，咱們得以完成一系列上層方案，無需過分關注動態性、適配性等問題。

Android桌面彈層

對於手淘這樣日活流量足夠大的APP，其Android桌面的觸達流量價值一樣是巨大的。相比APP站內的Pop觸達，其更加擁有包括增強喚端、二方流量交換這樣的獨特價值。在有規則規範的前提下，咱們能夠經過端側中間件建設，把Pop搭建的能力無差異的輸出到桌面環境，使其成爲Pop觸達生態的一環。其具體的觸達形態，則能夠是頂部消息、掛角提醒等。其底層實現方案爲Android懸浮窗。

桌面Pop的效果Demo以下：

桌面Pop方案框架

首先，咱們將桌面與站內進行了搭建能力對齊，使一個搭建產生的頁面，便可以在手淘裏彈出，也能夠在桌面上彈出。爲此咱們抹平了底層方案不一樣帶來的差別，包括：

• 搭建模式與站內一致，一樣採用標準DSL+解析引擎完成渲染
• 經過控制Window添加次序來對齊層級管理
• 經過控制視窗大小位置，控制其可繪圖區域；經過搭建輸出可視區域位移量，對視窗內容進行位移還原窗口內容

另外，咱們提供了桌面環境的特殊處理：

• 增長了切換桌面觸發時機（計劃觸發，適合計劃常駐），並打通了ACCS消息觸發時機（即時觸發，適合消息類型）
• 增長了自由拖拽、邊側自動吸附功能

因爲桌面環境的特殊性，應避免對用戶造成嚴重的干擾。那麼桌面觸達的規則管理則十分重要。目前咱們設計了以下避免過分干擾的規則：

• 桌面環境的Pop必須有明確明顯的關閉按鈕
• 切換其餘APP時，須要將Pop內容進行隱藏，對於Android高版本則進行倒計時後自動關閉設置
• 桌面的彈出管理底層與站內一致，採用分層分優先級管理，並對一次桌面切換的曝光次數進行上限設置

任務管理服務

從上述任務管理流程圖能夠看到，業務對於曝光預判、業務數據方面都是須要服務端的人力投入的。即除前端的研發成本問題，服務端一樣面臨相似的問題。咱們梳理業務目前痛點以下：

• 人力消耗大，大促時效性差
• 機器資源消耗大
• 全量配置下發+全量接口預判的模式，致使單活動機器資源消耗大；
• 單場景（好比手淘首頁）下的Pop每每存在多個，活動之間篩選獨立進行，致使機器消耗總量增加快（QPS總量隨活動數線性增長且無上限）
• 穩定性風險高
• 臨時開發的模式，加上人員開發質量層次不齊，穩定性很難保障。
• 業務須要本身投入精力維護穩定性，特別是每次大促的時候應對突發流量

爲此咱們實現了對業務進行一站式託管。核心目標爲：

• 實現權益、導流這兩個業務領域的低研發極速上線
• 下降機器資源消耗，在線活動數量再也不受機器資源限制
• 託管業務整年0故障

經過拆解上文的任務管理流程圖，能夠看到服務端的工做主要包括曝光預判接口，以及頁面內的業務數據接口。咱們針對兩部分分別進行部分託管建設，架構圖設計以下：

任務管理服務架構

• 針對曝光預判接口，咱們提供了單場景多活動的人羣預判複用能力，即將人羣圈選的預判模式統一集中管理，底層與奧格人羣平臺二方包打通，上層單場景僅透出一個整合接口。從過去每次切換頁面觸發N次預判接口，變爲僅觸發一次。業務也無需自研人羣接口，僅需把人羣包ID進行配置便可。
• 針對內容數據接口，咱們仍在建設中。計劃經過底層打通了拉菲權益平臺二方包，將權益類型（紅包、優惠券等）直接整合進搭建體系中，業務無需進行復雜的權益能力對接，僅需提供權益ID配置便可。

總體效果

除文章開頭提到雙十一期間的業務覆蓋率已經達到75%以外，得益於搭建模式對研發效率的提高，今年雙十一期間，手淘內Pop的業務量和總體流量也有了大幅度飛躍：

除此以外，今年咱們快速穩定地響應了大促期間的所有緊急需求，避免出現過去幾年因封網、研發效率等問題帶來的沒法上線Pop的狀況。

寫在最後

PopLayer目前除手淘外，已經服務了集團衆多APP，包括天貓、淘寶特價版、閒魚、淘寶直播、餓了麼、Lazada、零售通、AE等等。後續也將繼續以手淘爲核心，服務更多的集團業務。

經過雙十一大促期間以及平常的業務覆蓋率，咱們印證了搭建模式對業務的價值。站在業務的角度思考，Pop這類「既輕量又複雜」的業務域，通過一番深挖的底層支持，能夠大幅度破除業務的桎梏，讓其解放雙手，去快速經過「提出idea-搭建-AB-看數據-再次迭代」的模式獲得最佳的業務結果。這套業務研發模式的優化，從思考如何研發變爲如何儘量封裝研發，對於相對輕量級的業務域來講也是有輸出價值的。

後續，咱們一方面將會繼續完善相關建設，將AB、標籤+推薦系統、引擎加載頁面性能優化等等進行深度挖掘，從研發效率提高，升級到業務價值提高；另外一方面也會將Pop的建設經驗沉澱成流量域方法論的一部分，輸出到其餘流量域中，爲業務探索與構建更有價值的流量增加矩陣。

手淘平臺技術

咱們背靠淘系基礎架構和廠商，既有立足5G適配、網絡加速、圖片體驗、網關調用、大內容上傳下載等核心技術支撐業務體驗升級和改造，

又爲用戶增加提供消息推送、浮層搭建、廠商觸達、外鏈拉端等流量端能力，並沉澱一系列如最小核、全鏈路數據等架構能力，爲手淘及產品升級提供平臺支撐，併成爲集團移動端基礎設施。

職位：Android研發工程師、iOS研發工程師

感興趣的同窗可將簡歷發送到：yangqing.yq@alibaba-inc.com，獲取優先內推資格！