背景&&現狀
現在還有很多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調試
岩鼠雲裝置平台，疫情期間，為企業免費開放，支援企業走過陰霾！
體驗位址：
岩鼠雲裝置平台