背景
近年來，各大APP內的彈層需求逐漸增多，以手機淘寶為例，日常的彈層上線頻率為單端每月50次左右，而在大促期間可以達到240次以上。在手淘內，各類彈層業務都會通過PopLayer中介軟體的能力進行管理。但業務往往會遇到開發彈層難、慢、穩定性差的種種困難。對比於往年業務研發成本較高的現狀，PopLayer在今年提出了【低研發搭建模式】來解決這類問題，形成一套快速搭建+視覺化+多端多場景通用的解決方案，在日常與大促期間得到了廣泛應用：
- 研發效率升級：彈層業務的上線成本從3天+，降低到2小時左右
- 業務覆蓋率高：雙11大促期間的業務覆蓋率達到75%
- 穩定性極佳：大促期間線上0故障
在各類APP都逐漸走向存量時代，精細化流量運營的今天，彈層作為一個可以隨時隨地產生內容並帶來高流量的強運營手段，已經從低頻需求，變成了面向各類人群觸達的高頻需求。作為業務支撐方向的中介軟體，如何為業務提效，將業務的關注重點從開發轉向內容運營，助力其完成觸達矩陣，成為了一件非常值得探索的事情。
（更多幹貨內容請搜尋關注【淘系技術】公眾號）
PopLayer
彈層，是一種強觸達使用者的互動形態。PopLayer的定義，則是一個可以在任何APP頁面上，在指定時間內，對頁面無侵入地彈出任何內容的彈層中介軟體。其業務定位，則為觸達各領域使用者的重要流量場。
為了便於理解，下面以手淘首頁近期Pop為例，將手淘內的Pop業務分類舉例介紹（本文中Pop即指彈層）：
- 大促氛圍打造
開售倒數計時提醒
- 增強使用者體驗
死亡恢復瀏覽飄條
- 紅包發放&提醒
星秀貓開獎
紅包催用提醒飄條
- 使用者指引
可以看到，彈層業務的互動形態是靈活多變的，業務目標訴求也各有不同。其背後有著各自業務層面的複雜訴求和增長目標。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描述的主要內容。
- 互動動線與UI結構
互動動線
對應到DSL，我們提供了多子頁面+多版本的描述方案，即通過建立多個子頁面+每個子頁面的多個版本來完成動線素材，並通過設定事件動作，完成動線串聯。對應到DSL的結構，即通過pages+vers以樹形結構分別描述各個子頁面版本。其整體示例如下：
佈局版型
Pop的佈局版型是多種多樣的，但基本可歸類為如下幾種：居中、四角掛角、四邊貼邊。DSL設計中，每一個子頁面都可以單獨設定其佈局版型。不同的版型，會以不同的佈局邏輯計算其大小位置。
UI元件
Pop形態下的UI元件，基於圍繞著如下幾個型別展開：圖片、文字、視訊、容器、倒數計時、點選熱區等。即通過提供大圖或視訊為背景，並通過容器+內部元件形成內部複雜的介面佈局。我們針對各個元件提供了統一的佈局配置+各自不同的素材配置。以一個倒數計時元件為例：
- 變數資料提取與繫結
變數資料提取
Pop的內容與服務端資料做繫結時，需要提供一套提取資料的描述方案。而資料來源因Pop的整體鏈路設計，存在多個可能來源。我們通過 指定資料來源+提供插入式Mtop介面配置+介面資料提取Function 完成資料提取的設定，形成一個變數。仍以上述Demo為例，其中紅包金額的變數為服務端Mtop介面返回資料。其提取流程示例：
即通過預判MTOP介面資料來源，通過JSONPath，並指定其資料位置完成提取。在某些較為複雜的情況下，有時資料來源需要多層解析（JSONPath+URLDecode+URLParse），那麼也支援其設定序列多層解析。
變數繫結
解析結束的變數，即視為一種全域性資源，其可以繫結到各種內容與其他資料上，哪裡需要哪裡搬。比如圖片地址、文字內容、toast內容、跳轉地址、MTOP請求引數等等。其實現方案為常用的字串模板表示式${prop_name}，進行執行時替換。
- 事件結構
大多情況下，Pop內的事件，即為使用者點選事件，但隨著業務複雜度的提升，例如視訊播放結束、視訊載入失敗、倒數計時結束等時機也需要響應事件，我們便提供了統一的事件描述，方便掛載到各個元件事件配置上。而事件的型別。即為跳轉場景、切換子頁面、傳送MTOP介面、關閉Pop等，我們分別對這些事件提供了對應的封裝描述。此處細節較多暫不展開。
- 疲勞度
疲勞度是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，獲取優先內推資格！