背景&&现状
现在还有很多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调试
岩鼠云设备平台，疫情期间，为企业免费开放，支持企业走过阴霾！
体验地址：岩鼠云设备平台
