IOS远程控制技术当中，最重要的环节是视频的输出，本文就目前出现的几种IOS视频流技术做一个实践和对比，重点会放在比较这几个方案在性能上的优缺点。
方案分析
IOS视频流方案，目前可以想到的有以下三种：
-
通过截屏获取图片，转换成视频流的形式，这种方法可见于facebook研发的WebDriverAgent（WDA)[1]技术，后由Appium进行维护，通过WDA的MJPEG服务接口获取屏幕截图，再用web-socket发送到浏览器端，就可以视觉上形成视频的效果。
-
Apple自带的开发组件，获取视频流，比如屏幕音视频录制可以使用Apple开发组件：AirPlay、ReplayKit框架等。
-
使用MAC本身的QUICKTIME对IOS设备进行录制，这种方式需要通过程序来启用QUICKTIME。
实践和对比
这里根据几个开源项目，做一个不同技术方案的视频流效果对比。
为方便比较，展示视频流的应用架构基本一致，不同之处在于使用哪种方式去获取视频流，程序架构图如下：
流程图
1. WebDriverAgent MJPEG 图片服务器
这里我们用开源项目STF[2] 来观察WDA图片服务视频流的效果。我们部署了一套STF在机器上，通过手机的秒表来记录视频流的延迟，结果是大概延迟200毫秒左右，点击有肉眼可见的卡顿。缺点是WDA服务启动过程略长，同时功能上不支持音频服务。
结果示意图如下：
2. Replay kit 视频流
Apple开发组件replay kit[3] 经常用于直播当中，可以实时的获取视频流，它是通过IOS内置的录制视频组件，在苹果手机上启动一个视频输出的服务，再从此端口获取视频流。优点是传输快，缺点是由于使用了本身的录屏功能，因此对苹果硬件损耗大，手机容易发热，使用它做IOS视频流输出时，无法再使用直播APP。我们使用将replay kit录屏方式，服务端使用python的socket方法接收视频流，展示在前端，做了个简单的程序，验证了下效果，延迟大概100-200ms之间。
- (void)processSampleBuffer:(CMSampleBufferRef)sampleBuffer withType:(RPSampleBufferType)sampleBufferType {
@synchronized(self) {
switch (sampleBufferType) {
case RPSampleBufferTypeVideo:
// Handle video sample buffer
if (!CMSampleBufferIsValid(sampleBuffer))
{
return;
}
if (tempVideoTimeStamp && (CFAbsoluteTimeGetCurrent() - tempVideoTimeStamp < 0.01))
{
NSLog(@"load frame...");
}
else{
[imageHandler pushOneFrame:sampleBuffer];
tempVideoTimeStamp = CFAbsoluteTimeGetCurrent();
}
break;
case RPSampleBufferTypeAudioApp:
// Handle audio sample buffer for app audio
break;
case RPSampleBufferTypeAudioMic:
// Handle audio sample buffer for mic audio
break;
default:
break;
}
}
结果示意图如下：
3. Qvh视频流
QVH[4]通过使用MAC QUICKTIME组件，进行屏幕录制视频，是目前github上的开源项目，这款技术理论上可以用在MAC，LINUX上，可以独立实现录制屏幕。该技术可以继续加入音频。我们使用web-socket技术，把qvh输出的视频流展示出来，得到的结果是延迟略高，我们再来看下qvh本身的延迟，大概有200毫秒，如下图：
通过web-socket转到前端后，延迟在200-700ms之间，假如用于IOS真机远程控制，用户体验上面可能会遇到一些瓶颈。
结果示意图如下：
结论
参考文献
WebDriverAgent服务：
https://github.com/facebookarchive/WebDriverAgent
STF开源项目：
https://github.com/DeviceFarmer/stf
replay kit 接口：
qvh开源项目：