android 是壹種基於linux 的系統，linux 系統已經提供了 諸如管道、消息隊列、***享內存和socket 等IPC 方式。既然已經存在了如此之多的IPC 機制，為什麽binder還會出現？主要是因為上述IPC機制無法對android 而言存在著諸多的不便，主要體現在性能，穩定性和安全性三個方面。
綜上，android中使用Binder作為其IPC 機制。
binder 主要是通過內存映射來實現的，壹次完整的ipc通訊的過程如下：
1.binder 驅動在內核中創建壹塊數據接收緩沖區
2.建立壹塊內核緩沖區
3.建立內核緩沖區和數據接收緩沖區的映射
4.建立內核數據緩沖區和接收進城用戶空間的映射
5.發送方將數據發送到內核緩沖區
6.由於映射的存在，就相當於直接將數據發送到了 接收進城中
binder 主要有四部分組成
其中binder client 、 binder service 和 servicemanager 運行在用戶空間，而binder 驅動則是運行在內核空間（binder驅動是通過模塊掛載的方式，運行在內核空間中的）。
binder 的工作流程其實可以類比為 上網的過程。客戶端（binder client） 服務器（binder service） dns（servicemanager） 和 路由器（binder 驅動）
客戶端輸入網址請求服務器會在路由器的幫助下請求 dns 服務器獲取服務器的ip地址，然後利用ip地址和服務器進行通訊。
binder基本的運行如下：
1.首先壹個進城通過binder驅動將自己註冊為servicemanager
2.service 通過binder 驅動將自己的binder 註冊到servicemanager中，以對外使用。在這個過程中，binder驅動會生成該binder 的內核節點，以及該節點的引用，並將這些內容發送給servicemanager，servicemanager會把引用存入表中
3.client 通過binder名稱，在binder驅動的幫助下在servicemanager中獲取到service 中binder 的引用，從而跨進程通信
1.通過上述的工作流程可知，servicemanager 其實是壹個特殊的進程，service 和 client 和 servicemanager 之間的通訊其實也是進程間的通訊，而這裏的進程間通信其實也是使用的binder通信。這裏的設計十分巧妙，servicemanager 是service 端，其他所有進程都是它的client 端，servicemanager提供了壹個非常特殊的binder，他不需要註冊也沒有名字，其他進程可以直接獲取到該binder 和servicemanager 進行通訊。
2.binder中還使用了代理模式，client 端所獲取的service 的binder引用並不是壹個真的binder對象，而是壹個service端binder 的代理，調用binder中方法的時候通過對service進行請求然後獲取返回結果。
android binder通信機制其實可以看作是壹次簡單的上網過程
1.客戶端輸入網址（發送端請求跨進程通信）
2.通過路由器查詢dns 服務器 根據域名獲取ip地址（通過binder驅動，獲取servicemanager 中實名binder的引用）
3.根據返回的ip地址，通過路由器連接服務器（根據獲取到service端的binder 代理 client端和service端進行通信 ）