iOS进程间通信体验

最近又做了一遍基于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通信）

image.png

如图，左边是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的线程操作封装起来，提高安全性
层级结构理清，上层下层逻辑分离干净
晚饭还没吃，今天还要去理发