背景&&现状
如今还有不少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块核心的模块外,咱们还有不少小模块去帮助用户提高效率。
UC研发效能出品