最近又做了一遍基于Replaykit Extension实现iOS录屏直播的需求，其中宿主App和Extension间用到了CFMessagePort进行进程间通信，记录一下，并试图封装出一个小轮子（doing）
有啥用
已经使用：
- 录屏直播场景下，主App起定时器通过port时不时ping一下ReplaykitExtension是否在运行，没有的话提示开启
- ReplaykitExtension时不时ping一下主App控制台是否在选择背景图，如果是，则推流默认图片，保护用户相册隐私
- 结合UserDefault，在需要数据同步时发送message通知另一方去更新数据
设想：
- 部分场景下让同一个AppGroup下的另一个后台App/Extension停止播放/数据更新等
- 与同一个AppGroup下的另一个App/Extension进行数据交互，（token共享、偏好共享等）
通信的前提条件
- 两个通信进程需要在同一个AppGroup中
- CFMessagePortRef的portName必须是以 AppGroupId为前缀，
例如com.clc.group.portName，其中com.clc.group是AppGroupId - 如果是一个前台一个后台两个进程，需要后台保活（Replaykit不必，没有后台状态）
结构是怎样的
先贴一下思考的时候画的图（一边想一变画的，大概意思就是两者通过MessagePort通信）
如图，左边是Extension进程，右边是App进程。
通过在Runloop上的Source1位置挂上一个Listener（即一个Port）作为接收端，在漫长的跑圈里，等待Port来访。
创建Listener
- (void)startListener
CFStringRef portName = (__bridge CFStringRef)(self.PortName);
//回调
CFMessagePortCallBack callback = onRecvMessageCallBack;
//创建端口
CFMessagePortRef port = CFMessagePortCreateLocal(kCFAllocatorDefault, portName, callback, NULL, NULL);
//端口封装成source
CFRunLoopSourceRef source = CFMessagePortCreateRunLoopSource(kCFAllocatorDefault, port, 0);
//source挂上runloop
CFRunLoopAddSource(CFRunLoopGetCurrent(), source, kCFRunLoopDefaultMode);
}
再写一下间听到信息时的回调函数
CFDataRef onRecvMessageCallBack(CFMessagePortRef local ,SInt32 msgid,CFDataRef cfData, void*info)
{
//伪代码
//处理收到的data
handler(cfData);
//准备好伴手礼数据回调给发送者
return responseData;
}
那么一个Listener就创建完成了，那么接下来让我们打开这个Listener
CLCListener *listener = [[CLCListener alloc] initWithPortName:portName];
//开启listener
NSThread *listenerThread = [[NSThread alloc] initWithBlock:^{
[listener startListener];
CFRunLoopRun();
}];
listener.runingThread = listenerThread;
[listenerThread start];
OK，那么接收端这边就准备好了，需要注意的是
发送端发送-->Listener收到信息进入回调函数-->完成回调给发送放
这一整个流程都是同步进行的，所以如果在回调函数里避免耗时操作。
如果不可避免，则应先进行回调，再想办法在处理完成后进行一次通信（比如发送方开一个Listener等待，处理方完成后主动通知发送方，发送方收到后再关闭用于等待处理的Listener）
进行一次美好的调用
让我们看看发送方是怎么向Listener发送信息的，
首先这里会用CFMessagePortCreateRemote创建一个Port。
其中的portName就是和上面创建Listener时的portName。
- (void)doRequestWithMessage:(NSString *)message
portName:(NSString *)portName
timeOut:(NSTimeInterval)timeout
callBack:(void(^)(id data))callBack
CFStringRef cPortName = (__bridge CFStringRef)(portName);
// 生成Remote port
CFMessagePortRef port = CFMessagePortCreateRemote(kCFAllocatorDefault, cPortName);
如果在创建的时候，Listener还没有被创建，那么这里返回的port就是nil。
if (nil == port) {
callBack(nil);
return;
}
如果有值，那么枪就准备好了，接下来上弹
//带过去的参数
const char *cMessage = [message UTF8String];
CFDataRef cRequestData = CFDataCreate(NULL, (UInt8 *)cMessage, strlen(cMessage));
//用来接回调的CFDataRef
CFDataRef cResponseData = nil;
//demo里随便写的，可以是任意数值，在接受方可以取到
SInt32 msgId = 32;
//do localRequest
CFMessagePortSendRequest(port, msgId, cRequestData, 1, timeout, kCFRunLoopDefaultMode, &cResponseData);
其中的1和timeout一个是发送timeout，一个是等待回调的timeout，还是上面那句话，因为这里是同步调用，所以需要小心耗时操作阻塞
如果调用成功，那么这里的cResponseData已经把值带回来了
把CF对象桥过去给NS对象，就可以进业务逻辑了
if (callBack) {
//cf to ns
NSData* response = (__bridge_transfer NSData*)cResponseData;
callBack(response);
}
通信完成，走的时候带一下垃圾，欢迎下次光临
//clean up
CFRelease(cRequestData);
CFMessagePortInvalidate(port);
CFRelease(port);
}
轮子能上路前还有啥要做的事情
- 数据封装，目前只是用来互相ping确认存活提及通知去UserDefault更新数据，数据传递能力还不够完备易用
- 启动关闭Listener的线程操作封装起来，提高安全性
- 层级结构理清，上层下层逻辑分离干净
- 晚饭还没吃，今天还要去理发