為什么選用Binder，在討論這個問題之前，我們知道Android也是基于Linux內(nèi)核，Linux現(xiàn)有的進程通信手段有以下幾種：
- 管道：在創(chuàng)建時分配一個page大小的內(nèi)存，緩存區(qū)大小比較有限；
- 消息隊列：信息復(fù)制兩次，額外的CPU消耗；不合適頻繁或信息量大的通信；
- 共享內(nèi)存：無須復(fù)制，共享緩沖區(qū)直接附加到進程虛擬地址空間，速度快；但進程間的同步問題操作系統(tǒng)無法實現(xiàn)，必須各進程利用同步工具解決；
- 套接字：作為更通用的接口，傳輸效率低，主要用于不同機器或跨網(wǎng)絡(luò)的通信；
- 信號量：常作為一種鎖機制，防止某進程正在訪問共享資源時，其他進程也訪問該資源。因此，主要作為進程間以及同一進程內(nèi)不同線程之間的同步手段。 不適用于信息交換，更適用于進程中斷控制，比如非法內(nèi)存訪問，殺死某個進程等；
既然有現(xiàn)有的IPC方式，為什么重新設(shè)計一套Binder機制呢。主要是出于以上三個方面的考量：
-
效率：傳輸效率主要影響因素是內(nèi)存拷貝的次數(shù)，拷貝次數(shù)越少，傳輸速率越高。從Android進程架構(gòu)角度分析：對于消息隊列、Socket和管道來說，數(shù)據(jù)先從發(fā)送方的緩存區(qū)拷貝到內(nèi)核開辟的緩存區(qū)中，再從內(nèi)核緩存區(qū)拷貝到接收方的緩存區(qū)，一共兩次拷貝，如圖：
1695c427354bbec4.jpg
而對于Binder來說，數(shù)據(jù)從發(fā)送方的緩存區(qū)拷貝到內(nèi)核的緩存區(qū)，而接收方的緩存區(qū)與內(nèi)核的緩存區(qū)是映射到同一塊物理地址的，節(jié)省了一次數(shù)據(jù)拷貝的過程，如圖：
1695c428e3c4a95a.jpg
共享內(nèi)存不需要拷貝，Binder的性能僅次于共享內(nèi)存。 - 穩(wěn)定性：上面說到共享內(nèi)存的性能優(yōu)于Binder，那為什么不采用共享內(nèi)存呢，因為共享內(nèi)存需要處理并發(fā)同步問題，容易出現(xiàn)死鎖和資源競爭，穩(wěn)定性較差。Socket雖然是基于C/S架構(gòu)的，但是它主要是用于網(wǎng)絡(luò)間的通信且傳輸效率較低。Binder基于C/S架構(gòu) ，Server端與Client端相對獨立，穩(wěn)定性較好。
- 安全性：傳統(tǒng)Linux IPC的接收方無法獲得對方進程可靠的UID/PID，從而無法鑒別對方身份；而Binder機制為每個進程分配了UID/PID，且在Binder通信時會根據(jù)UID/PID進行有效性檢測。
Binder機制的作用和原理
Linux系統(tǒng)將一個進程分為用戶空間和內(nèi)核空間。對于進程之間來說，用戶空間的數(shù)據(jù)不可共享，內(nèi)核空間的數(shù)據(jù)可共享，為了保證安全性和獨立性，一個進程不能直接操作或者訪問另一個進程，即Android的進程是相互獨立、隔離的，這就需要跨進程之間的數(shù)據(jù)通信方式。普通的跨進程通信方式一般需要2次內(nèi)存拷貝，如下圖所示：
1695c1ab41198d5c.jpg
一次完整的 Binder IPC 通信過程通常是這樣：
- 首先 Binder 驅(qū)動在內(nèi)核空間創(chuàng)建一個數(shù)據(jù)接收緩存區(qū)。
- 接著在內(nèi)核空間開辟一塊內(nèi)核緩存區(qū)，建立內(nèi)核緩存區(qū)和內(nèi)核中數(shù)據(jù)接收緩存區(qū)之間的映射關(guān)系，以及內(nèi)核中數(shù)據(jù)接收緩存區(qū)和接收進程用戶空間地址的映射關(guān)系。
- 發(fā)送方進程通過系統(tǒng)調(diào)用 copyfromuser() 將數(shù)據(jù) copy 到內(nèi)核中的內(nèi)核緩存區(qū)，由于內(nèi)核緩存區(qū)和接收進程的用戶空間存在內(nèi)存映射，因此也就相當于把數(shù)據(jù)發(fā)送到了接收進程的用戶空間，這樣便完成了一次進程間的通信。
1695c1ab2efe8dc52.jpg
節(jié)選自：跨進程通信
