iOS 雲真機實現原理

背景&&現狀

如今還有不少App在支持着iOS九、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調試

UC研發效能出品

巖鼠 - 雲端設備，觸手可及​

嶽鷹-讓用戶體驗提高更簡單​