痛点：在一些音视频通信或者直播类app中，app的bundle中不可避免需要音视频处理的代码，解决音视频、采集、编码、推流、拉流等，导致app的体积很大。如果我们使用apple官方提供的extension，集成replaykit的形式来实现屏幕录制推流的话，必须在extension中集成同一份音视频处理的代码，而extension将集成在app中，导致这个app中包含两份同样的代码，体积进一步增大。
需求：app和extension中只有一份音视频处理代码
适用：app本身业务功能包含视频通话、视频直播相关音视频功能）具备使用相关功能时后台运行的能力）
论证：
- extension进程采集到音视频原始数据之后，可以通过进程通信的方式将数据传送给app的工作进程；
- 如果app此时正处于音视频通话或者视频直播，此时系统允许app在后台运行，那么app的进程处于活跃状态，可以接收到extension进程发来的数据；
- app具备音视频处理能力，可对音视频原始数据进行编码；
- app具备上传或者推流给服务器的能力，可对编码后的音视频数据进行分发；
从上面的论证中，我们可以看出这种使用replaykit的方式，需要保证：
- extension进程与app进程可以进行数据传输
- app进程对接收到的数据可以加工处理
对于进程间通信，我们可以有多种方案供考虑，例如共享内存，darwin通知，文件共享等多种方式，但这些方式都被依次pass，大概论述下过程：
共享内存：iOS来说，独特的沙盒设计目的正是隔离开不同的进程，不存在进程之间的共享内存空间
darwin通知：虽然darwin通知可以实现进程间通信
mach port：提供一组底层api用于消息的传递，可实现数据的通信，但是接口是底层的，编程比较麻烦，相关信息少，不好维护
socket：
