云测服务 iOS 云真机实现原理

UC研发效能 · 2019年10月16日 · 最后由 qchuang 回复于 2020年03月04日 · 6669 次阅读

背景&&现状

现在还有很多 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，从而提高整个链路的响应速度。