Android中使用Binder for IPC的优势

Question

在Android堆栈中使用Binder for IPC over (信号量、消息队列、管道)的优势是什么？

Answer 1

老问题(可能没有被发帖者监控)，但值得回答：

A)所有基于文件系统或文件系统可表示的IPC机制(特别是管道)不能使用，因为缺少一个全局可写的目录，所有进程都可以mkfifo/创建其IPC端口的文件系统/套接字表示(尽管/dev/socket用于系统进程，例如rile、zygote和它们的同类)。

B)建议的机制都不具备Android所需的“服务定位”能力。在UNIX中，有一个RPC端口映射器，Android需要类似的功能。进入: ServiceManager，它可以使用绑定器注册为上下文管理器，以动态注册/查找服务句柄

C)有广泛的序列化需求--无论是意图，还是其他消息。绑定器提供了包抽象，Parcel.java可以将其用于数据编组。

D)除了兰巴达先生的回答之外，SysV还有其他更重要的问题，特别是竞争条件和缺乏授权。

E)消息队列和管道不能传递描述符。UNIX域套接字可以使用，但不能使用，因为(A) (同样，除非您是root/system，如zygote、rild、installd..)

F) Binder是非常轻量级的，并且有内置的授权机制。它还具有一些很好的功能，比如唤醒接收方进程，以及内存共享，这是其他机制所不具备的。(请记住，没有mmap(2)，因为命名映射的(A)中存在文件问题)。

还有-别忘了

G) Binder开始于Palm (啊，怀旧) (q.v。OpenBinder)。前palmers访问了Android，并带来了他们的代码。

Answer 2

从ndk的docs/system/libc/SYSV-IPC.html文件中：

Android不支持System V IPC，即由以下标准Posix报头提供的功能：

<sys/sem.h>   /* SysV semaphores */
<sys/shm.h>   /* SysV shared memory segments */
<sys/msg.h>   /* SysV message queues */
<sys/ipc.h>   /* General IPC definitions */

这是因为，在设计上，它们会导致全局内核资源泄漏。

例如，在以下情况下，无法自动释放内核中分配的SysV信号量：

• 有错误或恶意的进程退出
• 无错误且非恶意的进程崩溃或被显式终止。

自动终止进程为新进程腾出空间是Android应用程序生命周期实现的重要组成部分。这意味着，即使假设只有无buggy和非恶意代码，随着时间的推移，用于实现SysV IPC的内核全局表也很可能会被填满。

在这一点上，奇怪的故障很可能会发生，并阻止使用它们的程序正常运行，直到系统下一次重新启动。

Answer 3

绑定器用于跨进程边界进行通信，因为不同的进程不共享公共的VM上下文=>，不再直接访问彼此的对象(内存)。在同一进程中的双方(通常是在同一个应用程序中的东西)意味着(imho)你不应该使用绑定器，因为它们会减慢/复杂化不必要的事情。

绑定器通常不直接使用，而是通过"Service“或"Messenger”类使用。虽然与Service的通信是通过完整的api函数完成的，但与Messenger的通信必须使用“Message”。Messenger的实现要简单得多。

除了使用绑定器之外，您还可以使用任何VM实例中提供的任何内容，如"LocalSocket"s、文件、ContentProviders、Intents等。

绑定器不适合传输大型数据流(如音频/视频)，因为每个对象都必须转换为Parcel (或从Parcel返回)。所有的转换都需要时间。例如，在这种情况下，使用LocalSocket要好得多。