背景&&現狀
現在還有很多App在支持著iOS9、iOS10，一旦在這些低版本的機器出現兼容性問題的時，想找一臺手機來debug，是一件非常難的事，而且iOS系統的分辨率也越來越多，無論是自動化還是日常的兼容性都需要有更全面的機型去做兼容性測試
在公司內部，很多時候，一些稀缺的測試設備我們是有，但無法高效地利用起來，對於其他辦公區的同事用起來想快速用起來就更難了。當然，有了統一的平臺去管理設備後，我們也有一個統一的資源池，在機器空閒的時候，能提供給自動化服務使用。
我們調研了業界的解決方案後，發現大家對iOS端都支持得不是那麼好，並且收費也相對較高，所以我們決定去嘗試自研。歷經數個版本的迭代後，我們終於完成了一版比較好用的iOS雲真機產品了，可以先感受一下效果。
亮點
在屏幕畫面方面，我們做到了高端機能有15幀左右的比較流暢的高畫質屏幕傳輸，並且是秒開、超級省流量。
在操作方面，極低延遲
在用戶體驗方面，我們也做了更多比較方便的小功能，快捷安裝ipa、鍵盤輸入、從電腦直接粘貼內容到手機、一鍵web調試。。。。。
在Mac主機方面，現階段，我們是能做到一臺i5 的mac mini能支持同時接入20臺手機
解決方案
我們的架構
基本和openSTF類似，mini作為provider，provider去管理手機和處理與雲端服務器之間的消息，連接到雲端服務器，雲端服務器能夠支持N個provider接入，並且自身能很容易地去做擴展，而云端服務器則負責分發消息，與做一些websocket服務的代理轉發，前端則直接對接雲端服務器。
雲真機核心驅動部分
這部分我們是完全自研，不基於WDA，也不基於開源產品，現在市面上很多iOS雲真機都會基於WDA或者其他的開源自動化測試框架去做的，可是這些框架的設計初衷並不是做雲真機，會引入了很多我們不需要的功能模塊。我們希望雲真機核心驅動部分，能儘量輕量，而且穩定。
整個核心驅動部分，最主要分為屏幕捕獲、模擬控制、輔助功能接口。
屏幕捕獲
苦於蘋果的限制，這一點是最難突破，我們也有嘗試過很多方案。例如:
idevicescreenshot，幀率太低了，而且通過逆向發現iOS系統中的ScreenShorter 不接受任何寬高、圖片質量、圖片格式的參數，這個方法在iPhoneX之類的高分辨率的機器，截圖會更慢，只有1-2幀。
而比較流行的iOS-minicap方案，這個方案雖然能非常非常高效地實時獲取到屏幕內容，但這個方案最大的缺點就是1個mac只能提供到1臺iPhone的實時屏幕流，成本實在太高，我們也有嘗試過破解Mac中CoreMediaIO。framework的iOSScreenCapture協議 (iOS-minicap就是調用了系統提供的iPhone錄屏接口，由AVFoundation與CoreMediaIO提供的)，我們還有嘗試過把整個Mac虛擬化去做隔離，讓同一個物理機使用多個iOS-minicap，但這些種種方案，最終都以失敗告終。
我們的最終方案是，在XCUITest中是使用私有API去截圖，這個私有API能最高能達到15幀左右，基本能滿足我們的需求了，再把每一幀編碼成視頻流，從而節省流量。可以感受一下jpg截圖與視頻流的流量大小對比:
以XS Max為例，每一幀都平均在90K左右，每一幀的數據傳輸截圖:
與圖片對比，肉眼可見的同等畫質下的，當編碼成視頻流後，一樣的機型，用相同的操作和相同的畫面去對比，視頻流所需的帶寬非常小
最重要的是，視頻流能節省的不僅僅是服務器出口的流量，還能減輕usbmuxd的cpu資源佔用。usbmuxd 當前是單進程的，只能使用單個cpu的核心，很容易到達瓶頸，對此我們還有一個改造就是把usbmuxd改成能充分使用cpu的每一個核心，提高整個mac的硬件使用率，這部分，我們以後在單獨寫文章介紹
模擬控制
相對於屏幕獲取，點擊事件倒是簡單很多，可以參考WDA，直接使用XCUITest的私有API觸發就可以。而消息格式則是沿用回openSTF的格式，provider收到之後直接轉發給XCUITest。這裡的重點是使用長連接去與provider做數據交互，而不是HTTP，從而提高整個鏈路的響應速度。
其他
除此屏幕控制和模擬控制這2塊核心的模塊外，我們還有很多小模塊去幫助用戶提升效率。
- 手勢支持
- 鍵盤輸入
- 粘貼內容到手機
- 快捷安裝
- 截屏
- 日誌
- 上傳圖片到相冊
- 前端同學最愛的Web調試
巖鼠雲設備平臺，疫情期間，為企業免費開放，支持企業走過陰霾！
體驗地址：巖鼠雲設備平臺