干货|一款实用 iOS 云真机的技术架构是如何搭建的？

关注

发布于: 2021 年 06 月 11 日

目前，市场上有很多 App 支持 iOS9、iOS10，一旦在这些低版本的机器出现兼容性问题时，想找一台手机来 debug 就是一件非常难的事，而且 iOS 系统的分辨率也越来越多，无论是自动化还是日常的兼容性，都需要有更全面的机型去做兼容性测试。

对移动开发者来说，无论是开发、调试、测试、还是上线前后检验效果，都离不开测试机，甚至是产品、运营和客服，也时不时需要使用真机进行产品体验、产品运营。传统渠道上，开发者只能通过采购设备满足各部门测试需求。然而随着业务的发展，这种方式的缺陷越来越凸显：稀缺机型抢手、设备数量不足、费用高企、资源利用率不高等。

我们在调研了业界的诸多云真机解决方案后，发现大家尤其是对 iOS 端支持得不好，并且收费也相对较高。历经数个版本的迭代后，友盟+推出了搭载在 U-APM 应用性能监控平台上的云真机服务，为移动开发者提供了灵活地测试操作界面，支持 ADB 调试、WEB 远程调试、扫码、抓包、虚拟定位等测试功能，并提供了测试报告供开发者后续查看。尤其是在 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，从而提高整个链路的响应速度。