在Android中使用Binder for IPC的優勢

Question

在Android堆棧中使用Binder for IPC比信號（消息隊列，PIPES）有什麼優勢？

Answer 1

綁定器用於啓用遠程過程調用。你可以使用你提到的同步工具來實現RPC，但是你也需要編寫很多代碼來使它們一起來... ...一個Binder（通常只用在Android服務中）你的代碼要少得多;幾乎不超過您的實際遠程功能。

Answer 2

由於不同的進程不共享通用的VM上下文，所以綁定器用於在進程邊界上進行通信=>不再直接訪問其他對象（內存）。同一過程中的雙方（通常是同一個應用程序中的事物）意味着（恕我直言）你不應該使用粘合劑，因爲它們減慢/複雜化事物是不必要的。

粘合劑通常不是直接使用，而是通過「服務」或「信使」類來使用。雖然通過一整套功能完成與服務的通信，但與Messenger的通信必須使用「消息」。信使更容易實施。

除了使用粘合劑就可以使用任何可從像「LocalSocket」 S，文件，ContentProviders，意圖，任何虛擬機實例...

粘合劑是不理想的傳輸大數據流（如音頻/視頻），因爲每個對象都必須轉換爲（並從）parcel。所有的轉換都需要時間。例如，在這種情況下更好的是LocalSocket。

Answer 3

距離NDK的docs/system/libc/SYSV-IPC.html文件：

Android不支持系統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 4

老問題（和海報可能不受監督），但值得回答：

A）的所有文件系統或基於文件系統的可表示IPC機制（尤其是管道），不能因爲缺乏的使用一個世界可寫的目錄，其中所有進程可以mkfifo /創建IPC端口的文件系統/套接字表示（儘管如此，/ dev/socket用於系統進程，例如rile，zygote等）。B）所建議的機制都不具備Android所需的「服務位置」的能力。在UNIX中，有一個RPC portmapper，Android需要類似的功能。輸入：可以使用綁定程序註冊爲上下文管理器的ServiceManager，用於動態註冊/查找服務句柄

C）需要序列化 ​​- 無論是意圖還是其他消息。 Binder提供了parcel.java可用於數據封送的宗地抽象。 D）SysV除了Lambada先生的回答之外還有其他問題，這些問題更爲重要，特別是競爭條件和缺乏授權。 E）消息隊列和管道不能傳遞描述符。 （A）（除非你是root/system，比如zygote，rild，installd ..），UNIX域套接字可能但不能使用。在授權機制。它還具有喚醒收件人進程的漂亮功能，以及其他機制根本沒有的內存共享功能。 （並且請記住，由於（A）中存在命名映射的文件問題，因此沒有mmap（2））。

和 - 讓我們不要忘記

G）活頁夾在棕櫚（啊，懷舊）（劑適量OpenBinder）開始。前掌上人到了Android，並帶着他們的代碼。