簡(jiǎn)介：從2019年雙十一的 “蓋樓 ”到今年618的 “開(kāi)列車”，在大促互動(dòng)游戲背后，是業(yè)務(wù)多變性、產(chǎn)品穩(wěn)定性和研發(fā)效率的多重博弈。本文介紹了淘系互動(dòng)前端團(tuán)隊(duì)如何應(yīng)對(duì)研發(fā)效率 & 產(chǎn)品穩(wěn)定性的挑戰(zhàn)，內(nèi)容涵蓋“互動(dòng)智能測(cè)試” & “彈窗規(guī)?；a(chǎn)”這兩個(gè)技術(shù)方案。

2020年618大促已經(jīng)過(guò)去，作為淘系每年重要的大促活動(dòng)，淘系前端在其中扮演著什么樣的角色，如何保證大促的平穩(wěn)進(jìn)行？又在其中應(yīng)用了哪些新技術(shù)？淘系技術(shù)特此推出「618 系列|淘系前端技術(shù)分享」，為大家介紹 618 中的前端身影，上篇內(nèi)容《618 大促背后的淘系前端技術(shù)體系》。

前言

本篇來(lái)自于 淘系技術(shù)部 互動(dòng)前端團(tuán)隊(duì)，今年我們帶來(lái)了名為“幸運(yùn)列車”的互動(dòng)游戲，攜全國(guó)各地的特色農(nóng)貨和美食，讓大家在這個(gè)夏天尋味中國(guó)。

從2019年雙十一的 “蓋樓 ”到今年618的 “開(kāi)列車”，在大促互動(dòng)游戲背后，是業(yè)務(wù)多變性、產(chǎn)品穩(wěn)定性和研發(fā)效率的多重博弈。**本文介紹了淘系互動(dòng)前端團(tuán)隊(duì)如何應(yīng)對(duì)研發(fā)效率 & 產(chǎn)品穩(wěn)定性的挑戰(zhàn)，內(nèi)容涵蓋“互動(dòng)智能測(cè)試” & “彈窗規(guī)模化生產(chǎn)”這兩個(gè)技術(shù)方案。
**

互動(dòng)智能測(cè)試

當(dāng)前互動(dòng)玩法愈發(fā)新穎多樣，這給業(yè)務(wù)開(kāi)發(fā)的效率帶來(lái)很大的挑戰(zhàn)，我們需要在視圖模型中維護(hù)大量的狀態(tài)。

以列車合成區(qū)域（下圖紅框）的狀態(tài)為例，共有10個(gè)合成位可以放置車廂，每個(gè)車廂有58個(gè)等級(jí)，開(kāi)發(fā)的時(shí)候需要模擬大量的數(shù)據(jù)。另外在互動(dòng)過(guò)程中還有抽中紅包等概率事件，異常狀態(tài)情況的驗(yàn)證也有很高的成本。

618互動(dòng)游戲的玩法可以簡(jiǎn)單歸納為：用戶通過(guò)各種行為獲取喵幣，消耗喵幣升級(jí)列車換取驚喜紅包，最后兌換現(xiàn)金紅包的過(guò)程。

我們通過(guò)機(jī)器學(xué)習(xí)的手段，幫助我們模擬用戶的行為，獲得真實(shí)交互環(huán)境中產(chǎn)生的數(shù)據(jù)，而不是手動(dòng)枚舉方式造測(cè)試數(shù)據(jù)。同時(shí)還結(jié)合 Puppeteer 模擬真實(shí)客戶端環(huán)境，在線上需要變更時(shí)，快速的進(jìn)行前端功能回歸驗(yàn)證，減少研發(fā)成本。

? 強(qiáng)化學(xué)習(xí)

強(qiáng)化學(xué)習(xí)是機(jī)器學(xué)習(xí)中的一個(gè)領(lǐng)域，強(qiáng)調(diào)如何基于環(huán)境行動(dòng)，以取得最大化的預(yù)期利益，也意味著能夠更快速的到達(dá)互動(dòng)玩法的最終狀態(tài)。

其中環(huán)境通常被規(guī)范視為馬爾可夫決策過(guò)程（MDPs）。首先介紹幾個(gè)概念：

• Agent：學(xué)習(xí)和做決策的主體
• Environment：Agent 交互的對(duì)象
• State：Agent 的狀態(tài)
• Action：行動(dòng)，Agent 會(huì)根據(jù)當(dāng)前的狀態(tài)選擇 Action
• Reward：獎(jiǎng)勵(lì)

MDPs 簡(jiǎn)單說(shuō)就是一個(gè)智能體（Agent）采取行動(dòng)（Action）從而改變自己的狀態(tài)（State）獲得獎(jiǎng)勵(lì)（Reward）與環(huán)境（Environment）發(fā)生交互的循環(huán)過(guò)程。Agent 會(huì)持續(xù)的和環(huán)境交互，根據(jù)當(dāng)前的狀態(tài)選擇 Action，而環(huán)境會(huì)給 Agent 新的狀態(tài)和 Reward。

為了在項(xiàng)目中生成數(shù)據(jù)，我們定義了如下 Action：收金幣、購(gòu)買車廂、合成車廂等。Agent 不斷與賽車玩法交互，Agent 從初始化狀態(tài)開(kāi)始，進(jìn)行“發(fā)送 Action -> 更新?tīng)顟B(tài)”的循環(huán)，直到最終達(dá)到目標(biāo)“抽大獎(jiǎng)”，學(xué)習(xí)過(guò)程到此結(jié)束。

學(xué)習(xí)流程圖

我們將學(xué)習(xí)過(guò)程中的狀態(tài)快照記錄了下來(lái)，作為服務(wù)接口的測(cè)試數(shù)據(jù)，幫助前端側(cè)開(kāi)發(fā)和調(diào)試。

? 自動(dòng)回歸測(cè)試

互動(dòng)場(chǎng)景下的前端交互非常復(fù)雜，然而前端功能回歸一直以人工方式為主。我們?cè)陧?xiàng)目中嘗試自動(dòng)生成測(cè)試用例，用于回歸測(cè)試。

從用戶交互的視角出發(fā)，收金幣、購(gòu)買車廂、合成車廂都對(duì)應(yīng)用戶的一次交互行為。我們?cè)?Puppeteer 環(huán)境中運(yùn)行頁(yè)面，根據(jù)沉淀下來(lái)的數(shù)據(jù)，回溯到特定的狀態(tài)。并結(jié)合強(qiáng)化學(xué)習(xí)，擇優(yōu)觸發(fā)前端Action事件，模擬真實(shí)的用戶操作，最終形成用戶的前端交互行為樹(shù)。

用戶交互行為樹(shù)

得到用戶交互行為樹(shù)之后，我們會(huì)對(duì)行為路徑再進(jìn)行優(yōu)化，排除無(wú)價(jià)值的鏈路，合并重復(fù)鏈路，并最終拆分成簡(jiǎn)短的片段便于測(cè)試。如合成車廂 N 次，會(huì)處理成為 N 個(gè)測(cè)試用例，盡量以同種狀態(tài)下的最短路徑作為最終的測(cè)試用例。

前端測(cè)試用例圖

在需要回歸測(cè)試時(shí)，我們可以在 Puppeteer 環(huán)境中回放測(cè)試用例，做到了前端功能的自動(dòng)回歸。這個(gè)過(guò)程中，我們把各個(gè)測(cè)試用例的UI快照保存了下來(lái)，利用圖像識(shí)別技術(shù)進(jìn)行最后的校驗(yàn)。

以倒計(jì)時(shí)瀏覽任務(wù)為例，我們需要驗(yàn)證在跳轉(zhuǎn)后的頁(yè)面上，是否正確的展示了某個(gè)組件，通過(guò)圖像元素的對(duì)比，可以判斷該功能點(diǎn)是否正常。

檢測(cè)到組件，測(cè)試用例通過(guò)

互動(dòng)項(xiàng)目的業(yè)務(wù)邏輯，是一系列用戶行為帶來(lái)的反饋的組合體，智能測(cè)試方案在本次 618 互動(dòng)項(xiàng)目中，成為了前端開(kāi)發(fā)測(cè)試階段的提效利器。在線上階段發(fā)生變更時(shí)，可以快速完成線上功能的全量回歸和新功能的驗(yàn)證，保障線上業(yè)務(wù)的穩(wěn)定。

彈窗規(guī)?；a(chǎn)

今年的618的彈窗場(chǎng)景數(shù)量是去年618的2.5倍，彈窗由于可以避免觸及到游戲區(qū)域的復(fù)雜變動(dòng)，常常被用來(lái)滿足各類支線乃至主線需求，幫業(yè)務(wù)完成各個(gè)細(xì)分領(lǐng)域的玩法覆蓋，在無(wú)線營(yíng)銷互動(dòng)領(lǐng)域中，彈窗需求一直處于持續(xù)增量的狀態(tài)。

彈窗看似簡(jiǎn)單，但每個(gè)彈窗都有自己的意義以及屬性，可復(fù)用范圍非常受限，傳統(tǒng)方式研發(fā)彈窗的成本較高，在業(yè)務(wù)快速發(fā)展的背景下，我們需要有更快更好的研發(fā)交付能力。

? 表達(dá)層與邏輯層的解耦

一般情況我們可能會(huì)將彈窗沉淀成包含UI的彈窗組件庫(kù)，也會(huì)進(jìn)一步會(huì)將彈窗細(xì)節(jié)抽象出header、body、button、footer 等配置項(xiàng)。但這樣會(huì)有一些問(wèn)題，在互動(dòng)領(lǐng)域下的一個(gè)按鈕布局、一個(gè)圖標(biāo)形式都會(huì)讓這個(gè)“組件”越來(lái)越臃腫，所以不要天真的試圖用前端的設(shè)計(jì)思路，去預(yù)判設(shè)計(jì)師天馬行空的設(shè)計(jì)理念。畢竟不同的玩法和品牌形象下，對(duì)UI的定制往往有較強(qiáng)的訴求，因此在營(yíng)銷互動(dòng)中很難達(dá)到真正的UI可復(fù)用，因此我們要將表達(dá)層完全抽離出來(lái)，彈窗方案的邏輯層只負(fù)責(zé)模型的處理，表達(dá)層通過(guò)接受數(shù)據(jù)變化帶來(lái)的“表達(dá)”變化。

例如實(shí)現(xiàn)了一個(gè)抽獎(jiǎng)玩法，邏輯層包含了數(shù)據(jù)模型、登錄初始化請(qǐng)求數(shù)據(jù)以及抽獎(jiǎng)事件的后續(xù)邏輯行為，那么該數(shù)據(jù)模型下最終表達(dá)層選用的是老虎機(jī)、大轉(zhuǎn)盤還是直接點(diǎn)擊抽獎(jiǎng)按鈕其實(shí)都是兼容的。

? 解耦下的彈窗邏輯層

參照上述的解耦方法，我們將彈窗的能力分為UI層跟邏輯層，大致結(jié)構(gòu)是邏輯通過(guò)事件喚起彈窗，先拋開(kāi)UI層那么先對(duì)邏輯進(jìn)一步結(jié)構(gòu)化，最終邏輯層的結(jié)構(gòu)以及邏輯層跟UI層的關(guān)系如下圖所示：

邏輯層通過(guò)監(jiān)聽(tīng)業(yè)務(wù)數(shù)據(jù)層變換，初始化后Trigger管理器負(fù)責(zé)從配置隊(duì)列中檢索到匹配條件的行為，開(kāi)發(fā)者幾乎可將所有訴求類的彈窗根據(jù)Conditions（觸發(fā)條件）、 Times（展示次數(shù)）、Level（層級(jí)面）等能力描述出來(lái)，并通過(guò)配套的runtime快速生成業(yè)務(wù)所需的邏輯，例如一個(gè)初始化進(jìn)來(lái)后的彈窗只需要描述這樣一個(gè)DSL：

? 解耦下的彈窗視圖層

為了給予設(shè)計(jì)師更多的發(fā)揮空間，我們對(duì)UI進(jìn)一步結(jié)構(gòu)化拆解，直到要達(dá)到可以快速編排出UI，以及支持動(dòng)態(tài)下發(fā)。

一個(gè)項(xiàng)目中往往會(huì)有多個(gè)彈窗，每個(gè)彈窗有許多圖層組合，假設(shè)類型比較簡(jiǎn)單只會(huì)有組、圖片、文案等類型的圖層，圖層上會(huì)有靜態(tài)&動(dòng)態(tài)的屬性描述。

我們可以通過(guò)經(jīng)驗(yàn)所得來(lái)的項(xiàng)目 > 場(chǎng)景 > 圖層各個(gè)維度的拆解，把靜態(tài)配置+動(dòng)態(tài)綁定等能力對(duì)彈窗的UI進(jìn)行結(jié)構(gòu)化描述，如下圖：

首先UI部分是純函數(shù)式的，所以只需要支持UI描述以及動(dòng)態(tài)參數(shù)，就可以展示實(shí)際的彈窗UI，讓業(yè)務(wù)開(kāi)發(fā)專注在彈窗的邏輯描述上。

配合提供相應(yīng)的UI設(shè)計(jì)器，開(kāi)發(fā)者就可以根據(jù)需求繪制出所有彈窗，把彈窗的UI開(kāi)發(fā)成本降到最低：

618彈窗部分截圖

UI設(shè)計(jì)器

通過(guò)結(jié)構(gòu)化UI層我們就很方便的做很多事情，首先彈窗UI跟邏輯方案都是DSL+Runtime的相同機(jī)制，所以只需要配合搭建平臺(tái)或者異步接口，就能快速支持動(dòng)態(tài)下發(fā)的能力。

以及面向開(kāi)發(fā)者協(xié)同以及視覺(jué)還原的真實(shí)預(yù)覽能力，在發(fā)布時(shí)，平臺(tái)上的彈窗預(yù)覽功能將原來(lái)可能需要近半小時(shí)的彈窗配置review環(huán)節(jié)，縮短到幾分鐘，且準(zhǔn)確度更高。

釘釘掃碼加入「淘系互動(dòng)交流群」
▼

關(guān)注「淘系技術(shù)」微信公眾號(hào)，一個(gè)有溫度有內(nèi)容的技術(shù)社區(qū)~

原文鏈接：https://developer.aliyun.com/article/766550?

版權(quán)聲明：本文中所有內(nèi)容均屬于阿里云開(kāi)發(fā)者社區(qū)所有，任何媒體、網(wǎng)站或個(gè)人未經(jīng)阿里云開(kāi)發(fā)者社區(qū)協(xié)議授權(quán)不得轉(zhuǎn)載、鏈接、轉(zhuǎn)貼或以其他方式復(fù)制發(fā)布/發(fā)表。申請(qǐng)授權(quán)請(qǐng)郵件developerteam@list.alibaba-inc.com，已獲得阿里云開(kāi)發(fā)者社區(qū)協(xié)議授權(quán)的媒體、網(wǎng)站，在轉(zhuǎn)載使用時(shí)必須注明"稿件來(lái)源：阿里云開(kāi)發(fā)者社區(qū)，原文作者姓名"，違者本社區(qū)將依法追究責(zé)任。 如果您發(fā)現(xiàn)本社區(qū)中有涉嫌抄襲的內(nèi)容，歡迎發(fā)送郵件至：developer2020@service.aliyun.com 進(jìn)行舉報(bào)，并提供相關(guān)證據(jù)，一經(jīng)查實(shí)，本社區(qū)將立刻刪除涉嫌侵權(quán)內(nèi)容。

總結(jié)

以上是生活随笔為你收集整理的生产力再提速，618 互动项目进化之路的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。