作者簡(jiǎn)介

酒店無(wú)線效能研發(fā)組，負(fù)責(zé)酒店無(wú)線團(tuán)隊(duì)基礎(chǔ)能力平臺(tái)的研發(fā)，比如Cloud Touch平臺(tái)（云端手機(jī)），內(nèi)容運(yùn)營(yíng)平臺(tái)，自動(dòng)化測(cè)試流程等，通過(guò)對(duì)日常規(guī)律性事務(wù)的抽象總結(jié)提供解決方案，提高平臺(tái)所承載業(yè)務(wù)的整體效能。

一、背景

攜程內(nèi)部會(huì)有大量的部門或團(tuán)隊(duì)需要在App新版本、新站點(diǎn)完成研發(fā)階段所有功能測(cè)試后，在上架前(Post Release)階段，再進(jìn)行無(wú)拘束的從客人視角驗(yàn)收的訴求（比如競(jìng)品對(duì)比、Localization體驗(yàn)等）。對(duì)于已經(jīng)上架的版本，我們的客服人員在客人協(xié)助、新員工培訓(xùn)等場(chǎng)合，也有著使用生產(chǎn)資源來(lái)獲得與客人同一視角的環(huán)境訴求，這對(duì)我們研發(fā)流程中已經(jīng)存在的測(cè)試環(huán)境的適用性提出了巨大的挑戰(zhàn)，無(wú)論從操作體驗(yàn)、還是資源對(duì)齊等多方面，測(cè)試環(huán)境都難以滿足訴求。

• 例如為滿足Trip.com的新站點(diǎn)上線前的海外駐地驗(yàn)收訴求，需支持新站點(diǎn)的新功能提前向定向人群釋放的能力。
  
  
• 例如為滿足客服在對(duì)客協(xié)助時(shí)，能充分理解客人的進(jìn)線問(wèn)題，需支持員工和客人的視角保持一致的App操作平臺(tái)。

二、全場(chǎng)景建設(shè)

我們綜合評(píng)估了相似訴求以及平臺(tái)能力可能的輻射面后，下圖呈現(xiàn)了我們對(duì)系統(tǒng)（下文統(tǒng)一命名Cloud Touch）的適用人群的預(yù)期：

以駐地驗(yàn)收?qǐng)鼍盀槔?/span>基于Cloud Touch平臺(tái)，可統(tǒng)一收口驗(yàn)收人員的設(shè)備管理，通過(guò)云平臺(tái)提供統(tǒng)一的遠(yuǎn)程操作入口。這樣不論我們的員工在世界任何駐地，都可以方便的使用中心化維護(hù)的設(shè)備，同時(shí)新站點(diǎn)的RC包將在Cloud Touch上提前上架，完成待驗(yàn)收版本的部署。

以客服協(xié)助場(chǎng)景為例：基于客服工作臺(tái)給員工提供統(tǒng)一的進(jìn)入Cloud Touch的入口，可供員工在與客人的對(duì)話中了解客人的對(duì)應(yīng)App版本，能快捷的在設(shè)備池中選擇相關(guān)預(yù)置好的實(shí)機(jī)進(jìn)行場(chǎng)景鑒定工作。

（以上示意圖）

三、基于Cloud Touch的技術(shù)解決方案

3.1 核心平臺(tái)設(shè)計(jì)

基于以上分析，平臺(tái)需要解決的是覆蓋不同應(yīng)用場(chǎng)景的設(shè)備資源的分配管理問(wèn)題，實(shí)現(xiàn)不同地域請(qǐng)求的中心化分發(fā)問(wèn)題，提供本地設(shè)備的遠(yuǎn)程操控以及畫面的實(shí)時(shí)同步問(wèn)題，以達(dá)到類似于遠(yuǎn)程桌面的交互體驗(yàn)。并且可基于平臺(tái)化的收口能力為不同業(yè)務(wù)場(chǎng)景提供統(tǒng)一的預(yù)置參數(shù)和環(huán)境的配置，使各項(xiàng)工作的標(biāo)準(zhǔn)化能進(jìn)一步得到提升。

3.2 設(shè)備分池設(shè)計(jì)

我們有大量的客服員工座席，同時(shí)也有研發(fā)線的測(cè)試驗(yàn)收人員，設(shè)備池的足夠大是硬件條件，但是如何有效的利用這些設(shè)備，協(xié)調(diào)好不同應(yīng)用場(chǎng)景的人和設(shè)備的關(guān)系，這還需要一套滿足核心場(chǎng)景的分配策略設(shè)計(jì)，主要的核心流程如下：

3.3 遠(yuǎn)程設(shè)備操控設(shè)計(jì)與實(shí)現(xiàn)

實(shí)現(xiàn)了平臺(tái)化和設(shè)備的統(tǒng)一分發(fā)工作后，那么技術(shù)的核心在于如何選型并實(shí)現(xiàn)一套端到端的遠(yuǎn)程控制方案。

因?yàn)椴煌到y(tǒng)的對(duì)接技術(shù)不同，此處我們以iOS的實(shí)現(xiàn)為例，WebDriverAgent是Facebook 在17年的 SeleniumConf 大會(huì)上推出的一款新的iOS移動(dòng)測(cè)試框架（WDA），WebDriverAgent 在 iOS 端實(shí)現(xiàn)了一個(gè) WebDriver Server 能夠?qū)崿F(xiàn)與瀏覽器進(jìn)行交互，它的實(shí)現(xiàn)使用了經(jīng)典的Server-Client架構(gòu)（C/S），客戶端發(fā)送一個(gè)Requset，服務(wù)器端返回一個(gè)Response，借助這個(gè) Server 我們可以遠(yuǎn)程控制 iOS 設(shè)備。

WDAClient：基于WebDriverAgent實(shí)現(xiàn)的WDA的客戶端。facebook-wda 就是 WDA 的 Python 客戶端庫(kù)，通過(guò)直接構(gòu)造HTTP請(qǐng)求直接跟WebDriverAgent通信。

WDAServer：運(yùn)行WDA App的機(jī)器，實(shí)現(xiàn)了WebDriver的通訊協(xié)議。

Session：服務(wù)器端需要維護(hù)客戶端的Session，客戶端首次發(fā)送請(qǐng)求的字符串是'/session/sessionId/url′。服務(wù)器端根據(jù)url打開(kāi)對(duì)應(yīng)的url地址，同時(shí)將sessionId解析成真實(shí)的值，然后返回給客戶端。以后客戶端再向?yàn)g覽器發(fā)送請(qǐng)求時(shí)，會(huì)攜帶session值一起發(fā)送。

WebElement：WebDriverAPI中的對(duì)象，代表頁(yè)面上的一個(gè)DOM元素。

JsonWireProtocol：是通過(guò)使用webdriver與remote server進(jìn)行通信的 web service 協(xié)議 。通過(guò)http請(qǐng)求，完成和remote server的交互。

Mobile JSON Wire Protocol Specification：移動(dòng)端自動(dòng)化協(xié)議。

（此處引用了WDA官方的部分基礎(chǔ)技術(shù)說(shuō)明，如您感興趣可以再進(jìn)一步參考github上的facebook archive項(xiàng)目）

3.3.1 指令集適配

Client端可以接收多種不同類型的指令以完成不同的動(dòng)作，主要包括以下幾種：

（1）基本指令通信格式（iOS/Android格式公用，處理略有不同，以下用iOS舉例）：

{
    "serial":"00008030-000D48A40291802E", // IOS設(shè)備udid
    "type":"M_TOUCH", // 命令類型枚舉值
    "message":{
        "action":0, // 鼠標(biāo)或鍵盤 0按下 1松開(kāi)
        "keycodeType":"ascii", // 代表鍵盤事件輸入的是ascii碼
        "keyCode":60, // 鍵盤按下了哪個(gè)鍵 非ascii時(shí)響應(yīng)對(duì)應(yīng)系統(tǒng)鍵
        "position":{
            "x":687, // 鼠標(biāo)點(diǎn)擊事件x像素坐標(biāo)
            "y":1116, // 鼠標(biāo)點(diǎn)擊事件y像素坐標(biāo)
        }
    }
}

（2）基本指令：鼠標(biāo)事件(點(diǎn)擊/滑動(dòng)操作)

• 前端頁(yè)面根據(jù)設(shè)備上報(bào)的分辨率和用戶在畫面上操作的位置，計(jì)算鼠標(biāo)的像素位置x,y并組裝鼠標(biāo)事件命令
• Client收到actinotallow=0命令時(shí)（即按下鼠標(biāo)時(shí)），記錄鼠標(biāo)按下的坐標(biāo)和命令的時(shí)間
• Client收到actinotallow=1命令時(shí)（即松開(kāi)鼠標(biāo)時(shí)），記錄鼠標(biāo)松開(kāi)的坐標(biāo)和命令的時(shí)間。
• Client根據(jù)設(shè)備的scale(IOS設(shè)備像素和uiKit的縮放比)將命令下發(fā)的像素坐標(biāo)轉(zhuǎn)換為ui操作坐標(biāo)，獲得命令的起點(diǎn)和終點(diǎn)。將按下和松手的時(shí)間差值作為命令的執(zhí)行時(shí)間，組裝WDA命令。
• 請(qǐng)求WDA的url為：/wda/swipe，根據(jù)起點(diǎn)、終點(diǎn)、命令執(zhí)行時(shí)間、命令觸發(fā)頻率的不同可產(chǎn)生點(diǎn)擊、長(zhǎng)按、雙擊、滑動(dòng)的效果

（3）基本指令：按鍵事件

• 前端記錄用戶按下的按鍵并轉(zhuǎn)換為ascii碼，組裝鍵盤輸入事件，長(zhǎng)時(shí)間按壓會(huì)連續(xù)產(chǎn)生的命令；用戶在頁(yè)面上點(diǎn)擊的系統(tǒng)按鍵(電源、主頁(yè)、菜單鍵)也會(huì)被轉(zhuǎn)換為鍵盤輸入事件
• Client收到actinotallow=0時(shí)，若收到ascii碼的字符，則觸發(fā)字符輸入事件；若收到系統(tǒng)按鍵，則組裝對(duì)應(yīng)的命令完成操作
• 字符輸入事件: /wda/keys接口默認(rèn)有同步快照機(jī)制，會(huì)消耗大量時(shí)間確保輸入按照順序進(jìn)行，平均響應(yīng)時(shí)間1字符/秒。云手機(jī)對(duì)時(shí)效的要求更高，所以將WDA快照機(jī)制刪除，并在Client中使用隊(duì)列，將短時(shí)間內(nèi)的多個(gè)字符合并成1個(gè)字符串，調(diào)用1次/wda/keys即可完成多個(gè)字符的輸入，做到輸入實(shí)時(shí)響應(yīng)
• 電源鍵：請(qǐng)求/wda/locked獲取當(dāng)前鎖屏狀態(tài)后，調(diào)用/wda/lock或者/wda/unlock進(jìn)行鎖屏與解鎖
• 主頁(yè)鍵：請(qǐng)求/wda/home回到主頁(yè)
• 菜單鍵（APP選擇頁(yè)）：WDA未提供對(duì)應(yīng)接口，通過(guò)組裝上劃命令請(qǐng)求/wda/dragfromtoforduration，模擬上劃進(jìn)入菜單頁(yè)。注：這里不能使用/wda/swipe，沒(méi)有效果
• Client收到actinotallow=1時(shí)，代表用戶已經(jīng)松手，不做響應(yīng)

（4）復(fù)雜腳本指令

• 在上方提到的基本的操作之外，Client還可以接受更多命令入?yún)⒉⒅С謫酒餟I自動(dòng)化腳本，自動(dòng)化腳本將會(huì)完成更加復(fù)雜的指令，從而實(shí)現(xiàn)智能化控制與使用
• 接收啟動(dòng)app類型、用戶賬號(hào)密碼，頁(yè)面deeplink等，喚起app完成用戶登錄后直接跳轉(zhuǎn)進(jìn)入對(duì)應(yīng)頁(yè)面
• 接收app下載地址、版本號(hào)等，實(shí)現(xiàn)app的卸載與安裝并處理彈窗等信息

3.4 遠(yuǎn)程畫面同步的設(shè)計(jì)與實(shí)現(xiàn)

關(guān)于畫面的同步，先拋一下大家熟知的ffmpeg，這是一個(gè)開(kāi)源的跨平臺(tái)音視頻處理工具，它可以用于錄制、轉(zhuǎn)換和流媒體處理等多種音視頻操作。我們通過(guò)抓幀操作，數(shù)據(jù)通過(guò)ffmpeg進(jìn)行處理后依次進(jìn)行h.264轉(zhuǎn)碼，并將編碼信息推給到web端直播服務(wù)，當(dāng)前30s的視頻約 30M，h.264轉(zhuǎn)碼后只有 3MB，畫面流目前設(shè)置為1秒20幀。

3.4.1 畫面抓取

iOS設(shè)備畫面抓取流程：

（1）WDA mjpegServer

WDA自帶mjpegServer，mjpegServer會(huì)不斷地調(diào)用截屏API，并將截屏數(shù)據(jù)壓縮后組裝成mjpeg的數(shù)據(jù)流格式發(fā)送到畫面流的端口。

（2）截屏速度/壓縮質(zhì)量參數(shù)

WDA mjpegServer可以通過(guò)參數(shù)對(duì)截圖的速度，截圖后的壓縮質(zhì)量進(jìn)行設(shè)置。根據(jù)服務(wù)器性能和使用場(chǎng)景對(duì)FBMjpegServerScreenshotQuality和FBMjpegServerFramerate進(jìn)行調(diào)整以得到最好效果。

人眼對(duì)幀數(shù)的感知在24幀左右，所以我們將FBMjpegServerFramerate設(shè)置為24，用戶在使用時(shí)就不會(huì)感受到卡頓（幀率的選擇在3.4.2第四小節(jié)講述）

static NSUInteger FBMjpegScalingFactor = 100;  // 截圖縮放比，默認(rèn)100，一般不做修改
static NSUInteger FBMjpegServerScreenshotQuality = 25; // 截圖壓縮質(zhì)量，范圍1-100，默認(rèn)25。值越大圖片質(zhì)量越好。
static NSUInteger FBMjpegServerFramerate = 24; // 截圖輸出速度，即幀率，默認(rèn)10

（3）Client畫面獲取

用戶開(kāi)始使用時(shí)，會(huì)產(chǎn)生畫面初始化命令發(fā)送給Client。

Client通過(guò)GET請(qǐng)求畫面流的端口，便可以得到連續(xù)的mjpeg畫面流。

得到的畫面流數(shù)據(jù)格式是以--BoundaryString分隔開(kāi)的一張張mjpeg圖片，每一張圖片都可以單獨(dú)作為jpeg圖片保存下來(lái)。

3.4.2 流媒體處理

iOS畫面流轉(zhuǎn)視頻流流程：

上文提到的Client端可以通過(guò)GET請(qǐng)求畫面流端口得到一張張的jpeg圖片，mjpeg是幀內(nèi)編碼，數(shù)據(jù)非常大。如果直接將該畫面流數(shù)據(jù)推送給服務(wù)器，對(duì)使用方的帶寬要求會(huì)非常高，所以要轉(zhuǎn)成h.264的幀間編碼方式。

（1）Client請(qǐng)求畫面流端口并逐幀抓取圖片

通過(guò)ffmpeg請(qǐng)求畫面流端口，通過(guò)解碼器抓取每一張jpeg圖片。

（2）h.264編碼

將抓取到的每一張jpeg圖片都交給ffmpeg的編碼器，設(shè)置參數(shù)并進(jìn)行h.264編碼并輸出到標(biāo)準(zhǔn)輸出。

補(bǔ)充：解碼器和編碼器的幀率設(shè)置需要略大于WDA設(shè)置的截屏速度，這樣才能保證畫面的響應(yīng)一直是實(shí)時(shí)的。

（3）推流至流服務(wù)器

我們使用了平臺(tái)研發(fā)中心框架架構(gòu)研發(fā)部多媒體組提供的流服務(wù)器。通過(guò)引入框架團(tuán)隊(duì)提供的JAR包，便可方便將數(shù)據(jù)推流至服務(wù)器上。

ffmpeg編碼器標(biāo)準(zhǔn)輸出的每一幀，都會(huì)用設(shè)備在平臺(tái)上的主鍵作為唯一標(biāo)識(shí)標(biāo)記發(fā)送給流服務(wù)器。

公司的流服務(wù)器在接收到數(shù)據(jù)后，會(huì)根據(jù)唯一標(biāo)識(shí)生成類似于直播間的播放地址。前端訪問(wèn)該地址便可以看到手機(jī)的畫面。

（4）推流碼率

我們需要選取合適的幀率和碼率，以達(dá)到視頻流暢度和清晰度上的平衡：

以碼率上限設(shè)定為4.5mbps為例，用戶端所需要的網(wǎng)絡(luò)速度峰值550KB/s左右。

所需帶寬(KB/s) ≈ 推流碼率最大值(bps)/8/1024。

因?yàn)閷?shí)際上用戶的操作速度，并不會(huì)非?？?，對(duì)于帶寬的占用會(huì)更少，一般操作引起的畫面變動(dòng)所需帶寬在150-200KB/s左右，而靜止?fàn)顟B(tài)下所需帶寬僅在5-40KB/s

綜合各個(gè)方面，我們是以WDA截屏速度為24的基礎(chǔ)上適當(dāng)加入了關(guān)鍵幀，將Client推流幀率定在30幀/s，碼率上限設(shè)定為4.5mbps，實(shí)測(cè)占用帶寬350KB/s左右，畫面顯示流暢、清晰、無(wú)花屏。

而我們使用的WIFI下載速度最高值在7.5MB/s左右，因此推流碼率和帶寬不是瓶頸。瓶頸主要在于ffmpeg將圖片流轉(zhuǎn)換為視頻流的效率。通過(guò)計(jì)算，Client端java單線程ffmpeg的轉(zhuǎn)碼效率在每秒40幀左右，這可以通過(guò)技術(shù)優(yōu)化得到提高。

四、數(shù)據(jù)采集

作為一套相關(guān)工種的員工將賴以推進(jìn)日常工作的基礎(chǔ)平臺(tái)來(lái)講，其穩(wěn)定性必須是全維度可檢測(cè)的，不僅需要支持對(duì)系統(tǒng)日常運(yùn)行的健康進(jìn)行監(jiān)控，同時(shí)也要支持采集足夠的運(yùn)行數(shù)據(jù)，提供給平臺(tái)研發(fā)人員分析并推進(jìn)后續(xù)的迭代工作。

平臺(tái)穩(wěn)定性：通過(guò)各種監(jiān)測(cè)維度數(shù)據(jù)及日志，提升用戶感知穩(wěn)定性；

使用檢測(cè)量：用于評(píng)估用戶依賴平臺(tái)工作的量，后期平臺(tái)迭代對(duì)用戶影響度；

五、實(shí)踐總結(jié)

在面向自動(dòng)化測(cè)試領(lǐng)域，包括攜程在內(nèi)，其實(shí)有很多的UI自動(dòng)化測(cè)試方案所采用的技術(shù)與此相似，甚至使用的技術(shù)底座都是相同的，比如WDA框架就是Facebook 推出的一項(xiàng)新的iOS移動(dòng)測(cè)試框架。

無(wú)獨(dú)有偶，我們團(tuán)隊(duì)在最初實(shí)現(xiàn)一些技術(shù)功能后，也是首先重點(diǎn)推廣于測(cè)試場(chǎng)景。但是攜程的業(yè)務(wù)面非常寬廣，我們不僅有開(kāi)發(fā)測(cè)試場(chǎng)景，還有內(nèi)容核驗(yàn)場(chǎng)景，尤其是我們的國(guó)際化走在前列，有大量的海外員工也要一起參與到非常多的驗(yàn)收環(huán)節(jié)。

那么像應(yīng)用版本，參數(shù)配置，環(huán)境初始化，資源準(zhǔn)備這些環(huán)節(jié)在不同國(guó)別的同事間同步或培訓(xùn)，是相當(dāng)耗費(fèi)人力和成本的，且效果并不佳?；谖覀儗?duì)技術(shù)和平臺(tái)的深度分析和演進(jìn)后才發(fā)現(xiàn)，其實(shí)技術(shù)的應(yīng)用空間很廣，使一項(xiàng)基礎(chǔ)的技術(shù)平臺(tái)化起來(lái)后，很容易將場(chǎng)景、人員、設(shè)備、配置都統(tǒng)合在一起，很多交流成本可以直接降低，驗(yàn)收設(shè)備的不充分利用問(wèn)題也得到很好的解決，尤其是共性問(wèn)題的發(fā)現(xiàn)和解決變得高效。

在我們后續(xù)的工作中，還將基于當(dāng)前的一些體驗(yàn)進(jìn)行以下幾個(gè)方面的持續(xù)優(yōu)化：

• 模擬器場(chǎng)景支持并發(fā)安裝包
• 單設(shè)備的多場(chǎng)景復(fù)用

最終使平臺(tái)的體驗(yàn)完全可替代實(shí)機(jī)操作，讓我們的潛在用戶切身感受到上平臺(tái)比自己在手機(jī)上做各項(xiàng)工作更加便利與高效。