Linux 进程通信内存拷贝计数图

一、进程通信中“拷贝”的概念

拷贝：

• 广义上讲就是任何数据复制，但是在Linux系统中比较特殊，这里的概念比较狭义，物理内存之间的数据复制才叫拷贝
• IO设备、Input 、DMA（Direct Memory Access）与其他设备之间的数据复制不能称为拷贝

为什么要着重强调这个概念呢？

因为很多博客中讲sendfile、mmap，多次拷贝的时候出现了描述矛盾的问题。

 

1、两次拷贝 (这张图上有3个物理内存)

• Copy From User   用户态->内核态
• Copy To User        内核态->用户态

因此传统IO上，进程间的通信经过两次拷贝，而且这只是单向传输数据，如果B进程要返回结果给A进程，只需要把这张图中的A进程和B进程角色关系调换一下。也是就是说，如果是带返回值的IPC，至少需要4次拷贝。

细品Copy这个单词：

我们发现，Copy From  User和Copy To User ? 作为主谓宾结构，到底是Who在Copy？

答案：是内核驱动程序，说明了一件事，进程通信需要内核允许

 

2、一次拷贝（这张图上有2个物理内存）

 

Binder 通信的实质，Binder 服务端和Binder用户端，进程A和B分别和内核态建立映射关系，这个映射关系依靠mmap完成，一次拷贝。

IPC通信，最多只需要2次拷贝，比传统方式少一倍。

 

3、0拷贝（这张图上1个物理内存）

A，B两用户态进程和内核态建立了同一虚拟内存地址的内存，因此，实现了内存共享，同样也是通过mmap实现

 

问题来了，共享内存这么高校为什么Android 通信不用？

实际上，Android并没有不用，只是在用户进程之间通信不推荐试用，Android使用共享内存的。Android使用共享内存的地方是SurfaceFlinger，Android App中可以使用共享内存的是工具是MemoryFile。

 

Google为什么不推荐呢？

共享内存无法实现高并发的复杂控制，可能出现用户进程A修改用户进程B数据的问题，对于一对一的通信缺陷并不大，但是多对一，多对多就是致命伤？

 

为什么SurfaceFlinger会使用共享内存？

• SurfaceFlinger数据控制使用Binder，View绘制使用GraphicBuffer 共享内存
• 共享内存传输数据非常高校，SurfaceFlinger直接和显示设备关联，需要尽可能避免图像数据延迟导致丢帧问题
• 数据类型单一，无需安全校验
• 进程之间是一对一，通过优先级合成图像