最近用到了屏幕录制这个功能，找了一下第三方和苹果自带的ReplayKit框架，分析了几种屏幕录制的效果，最后还在选择了ReplayKit进行录屏。
ReplayKit的优势：
1.内存、CPU占用极小可以忽略不计，对于需要录制过程中有高消耗内存的情景来说是非常友好了；
2.录制清晰度和流畅度非常高；
3.不需要导入一些SDK包，对APP的负担几乎为0；
当然他的劣势也是非常的多，这在下面一点一点地说明。
使用ReplayKit一个正常的录屏流程如下：
1.检测是否支持
2.开始录屏
3.结束录屏
4.调出预览界面
5.将视频保存到相册
6.拿出这段数据进行操作
在实际操作中，开发者其实很想把步骤4、5去掉，因为这个预览界面可操作性非常低，大多数操作权限全在用户身上，使得整个流程变得不可控，而且很多情况下并不需要这个预览界面。所以下面的流程中我去掉了这个预览界面。
另一方面，从相册中拿出的录制视频默认是非常高清的，每1秒大概有1M，所以在保存后我增加了压缩的过程。
我的ReplayKit录屏过程如下：
1.检测是否支持
2.开始录屏
3.检测是否真正开始录屏
4.结束录屏
5.将视频保存到相册
6.拿出路径进行压缩
7.拿出压缩后的输出路径进行数据操作
下面是对每一步进行的分析和解释，同时也在说明Replay的一些劣势：
1.检测是否支持
此处对应Demo里方法:
- (void)REC_Available;
- (void)REC_PermissionsAlert;
第一个方法是检测系统是否是iOS9.0+,包括提示风险。这里的风险是指的ReplayKit对各个系统各个机型支持的并不是很友好，我测试了10部手机，版本从9.0 ~ 11.4，一样的代码下有些系统可能启动不了录屏，这个情况在10.2以下出现的频率比较大，所以我加入了10.2系统的判断，这点可有可无。
第二个方法是权限的提醒，当你调用录屏时会弹出是否允许录屏的权限，在弹出之前提醒用户选择第一项，这点可有可无。
2.开始录屏
这部分在Demo中对应的方法:
- (void)startREC；
这里需要区分9.0~10 和 10+的系统对应不同的方法
if (@available(iOS 10.0, *)) {
[recorder startRecordingWithHandler:^(NSError * _Nullable error) {
if (!error) {
weakSelf.REC_StartOK = YES;
if (!weakSelf.canRecord) {
[weakSelf stopREC_WithSave:NO alert:NO tryAgain:YES];
}
NSLog(@"===启动成功");
}
}];
} else {
if (@available(iOS 9.0, *)) {
[recorder startRecordingWithMicrophoneEnabled:YES handler:^(NSError * _Nullable error) {
if (!error) {
weakSelf.REC_StartOK = YES;
if (!weakSelf.canRecord) {
[weakSelf stopREC_WithSave:NO alert:NO tryAgain:YES];
}
NSLog(@"===启动成功");
}
}];
}
}
3.检测是否真正开始录屏
这里是一个关键，在Demo中对应的方法：
- (void)REC_StartResult;
这里说下为什么要加这个流程：Replay只负责了权限的弹出没有管权限的反馈，也就是说用户点了哪个权限你并不知道点击了之后也没有任何反馈。这就比较尴尬了，所以我这边加了个延迟5秒判断是否真正开启了录屏，如果5秒之后用户还没有授权或者拒绝掉就提示他重新操作，保证了后续工作是在录屏状态下进行，但这样的操作的话会把这5秒录进去，需不需要自己权衡。
4.结束录屏
在Demo里对应的方法：
- (void)stopREC_WithSave:(BOOL)save alert:(BOOL)alert tryAgain:(BOOL)tryAgain;
这里主要调用系统方法：
- (void)stopRecordingWithHandler:(nullable void(^)(RPPreviewViewController * _Nullable previewViewController, NSError * _Nullable error))handler;
三个参数作用：
save：是否保存，在处理流程异常时不保存，正常结束录屏时保存
alert：异常时是否给予错误提示
tryAgain：如果是5秒内没有允许录屏权限，之后再允许弹出提示
结束的时候有一个关键的地方，就是结束完如何不弹出预览视图就能拿到这段视频的路径，这里参考了网上的一些方法，选择了利用分类处理：创建分类，覆盖其不暴露的属性movieURL
if ([previewViewController respondsToSelector:@selector(movieURL)]) {
NSURL *videoURL = [previewViewController.movieURL copy];
}
5.将视频保存到相册
Demo中对应的方法是在第4步停止录屏里，调用系统方法：
UISaveVideoAtPathToSavedPhotosAlbum([videoURL path], self, @selector(savedPhotoImage:didFinishSavingWithError:contextInfo:), nil);
这里还是要强调一点，请先在录屏的时候获取权限，在保存的时候在进行权限操作可能会出现问题。
其实在这里已经出现了视频url，理论上已经可以对视频进行压缩操作了，我在测试的时候证明这里也是可以进行压缩操作的，不过由于我这边产品流程的原因所以还是走了保存到相册这一步，不需要的话这个步骤可以跳过直接进行视频压缩。
6.拿出路径进行压缩
Demo中对应的方法是保存到相册之后的回调：
- (void)savedPhotoImage:(UIImage*)image didFinishSavingWithError: (NSError *)error contextInfo: (void *)contextInfo;
在取相册中的这个视频时我直接取最后一个文件，因为结束的流程直接是一气呵成没有停顿什么的，只要保存成功立马拿出它的路径。
这里说下为什么要压缩，Replay录制的是非常高清的mp4格式，在设备iPhone6上1秒大约1M。这也就出现了两个问题：
1.不能过长时间录制，否则内存吃不消
2.如果进行上传之类的操作必须要经过压缩才行
压缩采用了中等质量，压缩出来在iPhone6上大概为每10秒0.8M。从这个方面我们就可以看到，Replay不太适合长时间的录制。当然，你可以使用FFMpeg进行高定制的压缩，使得压缩率更大而视频效果良好。
6.拿出这段数据进行操作
最后你可以拿着这段输出路径进行任何想要的操作。
最后贴一下Replay的缺点：
1.录制的原始视频清晰度非常高，导致整个视频文件非常大，不得不进行压缩
2.录制时权限没有回调
3.录制完成时正常条件下必须要通过预览界面拿到视频
4.有一定几率无法启动视频录制，并且无法追溯原因
5.不同的机型和版本出现特例原因，很难追溯原因，稳定性不太好
总结，如果你的工程中录屏只是个辅助工具，对整个工程影响没有那么大，那么ReplayKit适合你。但如果你的工程非常依赖录屏，那么还是建议自定义一套录屏工具。
另外可以了解一下ReplayKit2在直播推流上的应用，效果挺好。
附上Demo地址：https://github.com/QiuYunxiang/YX_ReplayKitDemo
9.4日更新一些问题：
1.iOS11.4系统苹果6P上，不保存相册直接拿路径压缩会报路径无效的错误，拿不到这个路径上的文件，建议还是保存到相册一下；
2.磁盘内存不足时会保存不上（可能没有错误提示），压缩时会报路径上没有文件的错误。基于原始视频文件很大的情况，建议在发起录屏时进行磁盘空间大小检测，原始视频大约为每秒1M；
9.6日更新一些问题：
1.结束方法可能会不走回调，处在假死状态，即使把任务放在异步主线程也会莫名其妙无法走结束的回调方法，建议像检测是否真正开始录屏时一样检测是否真正结束录屏。
11.2日更新一些问题
1.iOS12及12之后的版本，Demo中的原来不加创建时间排序的方法无效，取到的最后一个资源文件是图片类型，需要加上创建时间排序；
2.录屏完成后拿到的录屏文件路径是在整个手机的资源中，并不是在启动录屏的app的沙盒中，无法对这个原始的录屏文件进行移动、拷贝之类的操作，但是可以进行播放、保存到相册，所以这里我使用了保存相册这个方式，上面也提到如果直接对这个路径文件进行压缩会报错；
3.根据业务员的反馈记录，手机型号越新系统版本越高的手机稳定性越好（各种错误提示越少），个人觉得这个框架和手机关系也很密切；
