背景

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

現有的方案

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

• 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。

更多專業前端知識，請上 【猿2048】www.mk2048.com

總結

以上是生活随笔為你收集整理的美团点评云真机平台实践的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。