美團點評雲真機平臺實踐

背景

隨着美團點評業務愈來愈多，研發團隊愈來愈龐大，對測試手機的需求顯著增加。這對公司來講是一筆不小的開支，但現有測試手機資源分配不均，利用率也很是有限，致使各個團隊開發、測試過程當中都很難作到多機型覆蓋。怎麼樣合理、高效利用這些測試手機資源，是擺在咱們面前的一道難題。

現有的方案

爲了解決這些問題，業內也出現了一些手機管理和在線調試使用的工具或平臺，比較常見的有:

• OpenSTF
• 百度MTC的遠程真機調試
• Testin的雲真機
• 騰訊WeTest的雲真機
• 阿里MQC的遠程真機租用

其中OpenSTF是開源項目，其餘的平臺大多也都是基於OpenSTF原理實現的。所以，咱們對OpenSTF項目進行了深刻研究。

遇到的問題

咱們首先按照OpenSTF官方的方案進行了搭建，並進行了小規模的應用，但漸漸的咱們發現了它的一些問題：

• 模塊過多並且耦合緊密，解耦難度較大，每次修改須要更新全部模塊，難以快速迭代開發。

• 部分技術選型落後。因爲OpenSTF出現的時間比較早，部分技術已經落後於目前的主流。例如OpenSTF前端選用AngularJS 1.0進行開發，在生態鏈方面已經落後於其餘流行的框架；數據庫方面選用非關係型數據庫RethinkDB，在數據計算和性能方面弱於MySQL等關係型數據庫，同時RethinkDB資料較少，不便於開發與維護。

• OpenSTF屏幕圖像傳輸採用圖片單張傳輸的方式進行，並且畫質不能由用戶來調節，實際應用中佔用帶寬很高，在網絡比較差的狀況下會有嚴重的卡頓現象，體驗不好。

咱們的方案

架構設計

根據業務場景的須要，並吸收了OpenSTF結構優勢，咱們採用Agent/Server模型的模塊化設計方案。下面分別介紹主要模塊的功能：

• Agent模塊。Agent模塊與OpenSTF的provider相似，部署在服務器上或者用戶的電腦上，Agent鏈接真實的手機，而且將手機的屏幕圖像經過Websocket動態代理到Websocket服務器上，而後經過消息中心來進行消息的傳遞。

• Server模塊。Server用來集中管理和調度手機，與OpenSTF結構不一樣的是，咱們的Server端包含Web服務器、Websocket服務器、動態代理以及消息處理服務等部分，Server將用戶的訪問動態代理到對應的Web服務器和Websocket服務器上，並經過消息處理模塊向消息中心傳遞消息，實現用戶與Agent端手機的交互。

• 數據存儲模塊。數據存儲模塊用來保存整個平臺的數據，例如手機的狀態、用戶使用記錄等。數據存儲模塊由MySQL數據庫和一個RPC服務組成，Server再也不直接讀寫數據庫，而是經過一個RPC服務來進行數據的讀寫操做。

• 消息中心。與OpenSTF的triproxy功能相似，是鏈接手機和Server的樞紐，消息中心主要處理屏幕的操做以及手機的狀態變動等消息。

經過模塊化設計，項目結構比OpenSTF更加清晰。下面是整個系統的設計圖：

架構的優點

Agent模塊咱們直接複用了OpenSTF的provider大部分功能，包括minicap、minitouch等。在此基礎上，咱們也擴展了一部分OpenSTF缺失的功能，好比：

• 在provider的基礎上進行了二次開發，使其支持畫質/幀率調節（下文會有詳細說明）。

• 加入健康檢測功能，檢測手機網絡是否正常、是否設置了網絡代理等。

• 加入Inspector功能，方便獲取UI控件樹（下文會有詳細說明）。

• 對Agent進行了版本區分，便於Web端根據不一樣的Agent版本對相應的功能展現和隱藏。

在Server模塊中，咱們引入了動態代理的機制，而且從新開發了Web部分，採用了Vue 2.0 + iView來實現，數據庫採用了MySQL。

相比OpenSTF原生架構，總結下來有如下優點：

• 模塊耦合程度低，開發和部署更方便。OpenSTF各個功能模塊不只數量多並且代碼耦合緊密，在此基礎上進行二次開發和部署很是困難。而咱們將整個項目分爲Server、Agent、消息中心、數據存儲四個模塊，四個模塊功能和代碼都是獨立的，基本上沒有耦合關係，支持快速迭代開發，部署也很方便。

• 前端框架更主流，開發和維護成本低。OpenSTF前端是使用AngularJS 1.0實現的，AngularJS 1.0已經處於廢棄階段，各類第三方組件基本已經中止支持，AngularJS 2.0的社區和生態並未成熟，而咱們採用了Vue 2.0前端框架，Vue 2.0相對已經成熟，在美團側也已經有大量應用，可以快速開發高質量的Web功能。

• 數據庫性能強，設計靈活、維護方便。OpenSTF使用RethikDB做爲數據庫，RethikDB是一個NoSQL型數據庫，它有很是多的缺點，好比處理大量數據時的性能不好，資料很是匱乏，排查問題和數據庫維護都很是困難。而咱們採用了MySQL數據庫，很好的解決了這些問題，而且實現了Server模塊與數據讀寫的分離，這樣在更新數據庫表結構的時候無須同時修改Server端的代碼，只要保證RPC服務的接口格式一致便可，開發和維護更加方便。

除了這些基礎的功能以外，咱們還開發了一些特點的功能，下面咱們來詳細介紹。

特點功能

與客戶端自動化相結合

爲了合理、高效利用測試手機資源，咱們與客戶端自動化進行告終合，主要有兩個方面：

• 與集團內部的雲測平臺深度融合。在雲測平臺的服務器節點上部署Agent代碼，爲雲測平臺自動化任務建立者提供自動化過程展現和遠程調試功能，同時將雲測平臺空閒的手機開放給更多人使用。

• 開放API。咱們開放了一些API給普通用戶，供用戶查詢手機狀態、佔用手機、鏈接adb調試等，用戶可使用腳本調用API，而後直接在平臺的手機上進行自動化測試。

預定功能

當一臺手機處於繁忙狀態時，用戶必需要等待手機空閒後才能使用，因爲手機空閒時間不肯定，就會給用戶帶來很大的不便。爲了解決這個問題，咱們開發了手機預定的功能，用戶能夠預定處於繁忙狀態的手機，當手機空閒時，自動幫預定用戶佔用15分鐘，並經過即時通信工具通知預定人。

畫質調節

遠程調試平臺的核心是實時獲取屏幕圖像，因爲屏幕傳輸須要比較大的網絡帶寬，在網絡不佳的狀況下就會出現卡頓現象。所以，咱們針對不一樣的網絡作了一些流暢度的優化，下面來介紹一下其中的細節。

屏幕獲取的原理是經過minicap來高速截圖，每秒最高可達60張，而後將這些截圖顯示在Web上。所以，咱們考慮從兩個方面來優化網絡帶寬的佔用，第一個是調節截圖的質量，minicap自己支持調節畫質（OpenSTF固定設置了80%的壓縮比），關鍵代碼以下：

var rate =  Number(match[6])
    if (rate > 2 && rate < 100) {
      log.info(rate)
      if (rate > 30) {
        options.screenJpegQuality = 80
      }else if (rate > 15) {
        options.screenJpegQuality = 50
      }else {
        options.screenJpegQuality = 20
      }

      frameProducer.restart()
      framerate = rate
    }
複製代碼

第二個是調節每秒發送的圖片張數，也就是幀率，咱們能夠在Agent端控制發送圖片的數量，關鍵代碼以下：

# 首先修改幀率發送部分：
function wsFrameNotifier(frame) {  
  if (latesenttime == 0 || Date.now()-latesenttime > 1000/framerate) {  
    latesenttime = Date.now()  
    return send(frame, {  
      binary: true  
    })  
  }  
}
# 再加入調整幀率的代碼：
case 'rate':  
  var rate =  Number(match[6])  
  if (rate > 2 && rate < 100) {  
    framerate = rate  
  }  
  break
複製代碼

那麼，幀率和圖片壓縮比調節到多少才能知足不一樣網絡環境的須要呢？咱們先來看一組數據：

圖片壓縮比	圖片尺寸
100%	69.82KB
80%	46.78KB
50%	41.87KB
20%	37.84KB
10%	35.84KB

表中是使用minicap作的圖片壓縮實驗，從數據中咱們能夠看到當圖片質量下降到80%時圖片大小下降比較明顯，而圖片質量並無明顯的降低。繼續下降圖片質量，圖片大小下降有限。咱們再來看另一組數據：

幀率	圖片壓縮比	實際流量
60	100%	4.02M/S
60	80%	2.74M/S
60	50%	2.41M/S
30	80%	1.43M/S
30	50%	1.22M/S
30	20%	1.10M/S
15	50%	0.63M/S
15	20%	0.55M/S
15	10%	0.52M/S

表中是各類幀率和壓縮比組合產生的實際流量數據。

從數據中咱們能夠看到最高幀率和壓縮比的組合下，流量達到了4M/S，而80%壓縮比時流量減少到了2.7M/S，下降很是明顯。考慮到實際網絡狀況，咱們將60幀、80%壓縮做爲了高畫質選項。

而圖片質量從80%下降到50%時圖片大小降低並不明顯，此時下降幀率就成了很好的選擇。當幀率下降到30幀時流量下降了一半，1.2M/S的流量可以知足大部分網絡情況使用，30幀也能保證操做的流暢度，因而30幀、50%壓縮比成爲了中畫質的選項。

低畫質主要是爲了保證在較差的網絡環境可以正常使用，500K/S的流量是紅線。咱們將15幀、20%壓縮比做爲低畫質選項，此時圖片質量和幀率較低，但可以保證基本的使用體驗。

除了經過下降圖片質量和幀率來減少手機屏幕圖像傳輸的流量外，將圖像使用H264等編碼壓縮成視頻傳輸也是一種有效下降流量的辦法，相對於圖片，圖像的壓縮率將會更高，用戶的操做體驗也會更好。可是圖像壓縮編碼原理比較複雜，相關技術咱們還在研究當中。

App Mock

在作App測試過程當中常常須要抓包，通常狀況下，咱們經過修改WiFi的代理而後用抓包工具就能夠實現。可是這樣作的效率比較低，多個工具切換也很是不便。藉助集團的Mock平臺，咱們開發了一鍵Mock功能，可以快速完成相應App的Mock操做。帶來的好處是咱們能夠一邊操做App，一邊查看App發出的請求，大大提升了測試的效率。

App Inspector

App Inspector功能可讓用戶在平臺上使用真機的同時查看頁面控件樹及頁面元素，而且支持Xpath，更加方便高效的查找頁面元素，給UI自動化測試提供了很大便利。

這個功能咱們是藉助Uiautomator實現的。基本原理是寫一個Uiautomator用例，用來獲取當前頁面的Hierarchy，而後將用例打包成一個JAR放到Agent端。當在Web端觸發獲取控件樹時，Agent將JAR包推送到手機上並運行，此時會在手機端生成一個XML文件。而後再使用cat命令獲取XML內容並在前端解析。用例核心代碼以下：

public class launch extends UiAutomatorTestCase {

    public void testDumpHierarchy() throws UiObjectNotFoundException {
        File file = new File("/data/local/tmp/local/tmp/uidump.xml");
        UiDevice uiDevice = getUiDevice();
        String filename = "uidump.xml";
        uiDevice.dumpWindowHierarchy(filename);
    } }
複製代碼

固然，你也能夠用adb命令來獲取Hierarchy：

adb shell uiautomator dump /data/local/tmp/uidump.xml
複製代碼

但這種方式不能獲取動態頁面，好比視頻播放頁面。

數據報表

爲了更好的瞭解平臺的運營狀況，咱們作了詳細的數據統計，主要從使用次數、使用時間、設備數量、使用分佈等方面進行統計。目前咱們管理的手機近300臺，平均每月有超過500名研發人員在使用咱們的平臺，天天的使用次數達到280次，天天總使用時長超過60小時。

其餘小功能

除了以上幾個比較大的功能點，咱們也作了一些貼心的小功能，好比：檢測手機網絡是否設置代理、檢測手機已安裝的應用版本及安裝時間、快速安裝最新版本的測試包、支持App內的Schema跳轉等等。這些小功能爲研發人員節省了不少時間，提高了他們的工做效率。

將來規劃

iOS手機支持

目前，雲真機平臺只支持Android手機，對iOS手機的支持正在進行中。咱們已經初步完成了主要功能的開發，預計很快將與你們見面。

產品優化

咱們計劃繼續擴展產品功能，好比支持Log日誌展現和性能數據採集等。目前雲真機平臺已經在美團點評內部平穩運行超過兩年，咱們會繼續不斷迭代版本、打磨產品，提供更好的使用體驗。

做者簡介

東初，大衆點評平臺質量工具組負責人。7年互聯網行業測試、開發經驗，2015年加入原大衆點評。前後主導了雲真機平臺、單元測試平臺、web安全實驗平臺等項目的開發，致力於用工具來提高研發團隊的工做效率。

李帥，大衆點評高級測試開發工程師。2015年加入原大衆點評，主要負責雲真機平臺的開發以及客戶端底層組件的測試。熱衷於鑽研測試領域的前沿技術，並推進了多項新技術落地。

招聘信息

點評平臺－平臺質量中心，Base上海，主要負責大衆點評平臺入口和基礎功能的質量保障。平臺包括大衆點評App、大衆點評微信小程序、PC站：www.dianping.com、 M站：m.dianping.com；主要業務涵蓋：帳號、POI、評價、視頻、文章、會員社區、問答、運營活動、搜索推薦、通訊鏈路、運營活動等基礎業務。熱忱期待各位QA、開發、算法人才加入點評平臺技術部。聯繫郵箱：wenjie.pan#dianping.com。