在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服務中使用），您可以編寫更少的代碼; 幾乎不比你的實際遠程功能。