在Android中使用Binder for IPC的优点

Question

在Android堆栈中使用Binder for IPC（Semaphores，Message Queue，PIPES）有什么好处？

Answer 1

旧问题（可能不受海报监控），但值得回答：

A）由于缺少一个可写入世界的目录，所有进程都可以mkfifo /创建其IPC端口的文件系统/套接字表示，因此无法使用所有基于文件系统或文件系统可表示的IPC机制（特别是管道）（ / dev / socket尽管如此，它用于系统进程，例如rile，zygote和他们的同类）。

B）所建议的机制都不具备Android所需的“服务定位”能力。 在UNIX中，有一个RPC portmapper，Android需要类似的功能。 输入：ServiceManager，可以使用binder注册为上下文管理器，即时注册/查找服务句柄

C）对序列化有广泛的需求 - 无论是意图还是其他消息。 Binder提供parcel抽象，可用于Parcel.java的数据封送。

D）SysV还有其他问题，而不是Lambada先生的答案，这些问题更为重要，特别是竞争条件和缺乏授权。

E）消息队列和管道无法传递描述符。 UNIX域套接字可能但由于（A）而无法使用（同样，除非你是root / system，如zygote，rild，installd ..）

F）Binder非常轻巧，并且内置授权机制。 它还具有漂亮的功能，如唤醒收件人进程，以及内存共享，其他机制根本没有。 （并记住，没有mmap（2），因为（A）中的命名映射存在文件问题）。

- 让我们不要忘记

G）Binder是在Palm（啊，怀旧）（qv OpenBinder）开始的。 Ex-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应用程序生命周期实现的重要组成部分。 这意味着，即使只假设非错误和非恶意代码，很可能随着时间的推移，用于实现SysV IPC的内核全局表将填满。

此时，可能会发生奇怪的故障，并阻止使用它们的程序在下次重新引导系统之前正常运行。

Answer 3

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

粘合剂通常不是直接使用，而是通过“服务”或“Messenger”类。 虽然通过完整的功能API与服务进行通信，但与Messenger的通信必须使用“消息”。 信使实施起来要简单得多。

除了使用Binders之外，您还可以使用任何VM实例中提供的任何内容，例如“LocalSocket”，Files，ContentProviders，Intents，...

由于每个对象都必须转换为包裹（并从包裹返回），因此粘合剂不适合传输大型数据流（如音频/视频）。 所有转换都需要时间。 在这种情况下，更好的是例如LocalSocket。

Answer 4

绑定器用于启用远程过程调用。 您可以使用您提到的同步工具实现RPC，但是您还需要编写大量代码才能将它组合在一起...使用Binder（通常仅在Android服务中使用），您可以编写更少的代码; 几乎不比你的实际远程功能。