IPC Binder 之杂谈

Someone2023年6月19日大约 6 分钟

Abstract

进程间通信（IPC）在系统中非常重要，目前 Android 的 binder 方案已经属于行业内非常优秀的实践案例；但是作为软件从业人员，如果仅仅满足于现有架构或者技术的优势，这是远远不够的。所以本文有几个重要的目的：

第一是从对比、实践、设计的角度去看看 binder 有什么缺陷和改进点
第二是研究一下业界最新的技术是如何优化 IPC 的，或者说有没有什么新的思路借鉴？
第三是一些杂谈

Binder 优缺点

优点

对于 binder 具体的分析可以看我的另一篇博文《Research on Binder》，在此对具体的技术细节就不进行赘述，总的来看，binder 的优点包括以下几个：

第一，binder 只需要进行一次内存拷贝；

第二，binder 的使用非常简单（在上层 service 看来，只需要一个客户端、一个服务端，C/S 架构，超级简单）

第三，binder 很安全。binder 没有打破进程隔离的属性，并且在上层的 C/S 之间也有丰富的鉴权机制

最后，个人认为最重要的：Google 开发 binder 已经有很多年了，期间做了无数精妙的优化（这句话是想说，一个项目有很多优秀的从业者持续优化）

主要就是因为这几个优点，导致了 binder 在 Android 中的地位不可撼动。

缺点

但是随着对 binder 技术的稍微深入，我们发现，binder 的设计本质上是一个 trade-off: 牺牲了一部分性能，换取了安全和架构上的简洁，这也就是我们要说的 binder 的缺点：

第一，性能不是最优。虽然 binder 只需要一次拷贝，但是就是因为这次拷贝，使得 binder 的性能还存在 overhead, 具体来说：能不能避免这次拷贝？肯定能！但是为什么 Google 没做？我们上面说过，做了取舍；

第二，通信的信息大小存在限制。从 binder 的实现来看，因为使用了 mmap, 所以要在 kernel space 和 user space 之间做映射，这意味着需要在内核的地址空间占用临时映射区的空间，一个进程占一些，那进程多了，映射空间不够用怎么办？所以说 Android 严格限制了一个进程可以映射的内存大小，来规避这个问题；这也就是 Binder 的第二个缺点；

除此之外，Binder 本身比较复杂，如果需要 debug, 这会是一场灾难（当然，所有的进程间通信都是）；

还有一点，吹毛求疵一下：几乎无可扩展性；为 Android 专门设计的，想迁移到诸如微内核等上面？不存在的。

其他选择：dIPC

dIPC 是一篇论文的实现：《Direct Inter-Process Communication (dIPC): Repurposing the CODOMs Architecture to Accelerate IPC》，这篇论文的研究可以看我的另一篇文章。

简单来说，这篇文章为了解决 IPC（或者 Binder）性能问题，将需要进行进程间通信的进程分配到了一个共享页表中，然后使用自定义的隔离算法来保证安全性。

dIPC 设计理念

dIPC 的设计第一次让人看到时会有比较惊艳的感觉：我在此引用作者的 Abstract 中的一个内容：

In current architectures, page tables are the fundamental mechanism that allows contemporary OSs to isolate user processes, binding each thread to a specific page table.

作者刚开始就对现有的页表机制做了抨击！做创新、做学术就应该如此，敢于挑战权威和质疑现有的所有实现，这样才是进步之道。不管作者如何实现，这都为我们提供了一个新的思路：打破页表的限制！

那么作者是如何做的呢？作者复用了他之前的一个研究：CODOMs, 这个研究主要针对于单个进程之间的组件隔离，将多个组件按照页表，区分为多个域，每个域之间确定隔离策略。比如说可以进行通信和数据交互的域，我给配置读写权限；如果没有关系的域，就配置隔离策略。需要注意，这不是一个纯粹的软件策略，从页表上动手，意味着我们硬件也可以出手了，这就意味着：软硬件协同的机会来了！

// some image

我们截取论文中的一张图片进行简单介绍：在 dIPC 中，当两个进程要进行通信的时候，kernel 会负责创建（或者说自动生成）一个 proxy 对象，这个 proxy 对象拥有对客户端的读权限和服务端的写权限，这是在用户态可以配置的；如此一来就在不用拷贝数据到内核地址空间的情况下完成了进程间通信。