一、概述
Android系統(tǒng)中，涉及到多進程間的通信底層都是依賴于Binder IPC機制。例如當進程A中的Activity要向進程B中的Service通信，這便需要依賴于Binder IPC。不僅于此，整個Android系統(tǒng)架構中，大量采用了Binder機制作為IPC（進程間通信）方案。
當然也存在部分其他的IPC方式，如管道、SystemV、Socket等。那么Android為什么不使用這些原有的技術，而是要使開發(fā)一種新的叫Binder的進程間通信機制呢？
為什么要使用Binder？
性能方面
在移動設備上（性能受限制的設備，比如要省電），廣泛地使用跨進程通信對通信機制的性能有嚴格的要求，Binder相對出傳統(tǒng)的Socket方式，更加高效。Binder數(shù)據(jù)拷貝只需要一次，而管道、消息隊列、Socket都需要2次，共享內存方式一次內存拷貝都不需要，但實現(xiàn)方式又比較復雜。
安全方面
傳統(tǒng)的進程通信方式對于通信雙方的身份并沒有做出嚴格的驗證，比如Socket通信ip地址是客戶端手動填入，很容易進行偽造，而Binder機制從協(xié)議本身就支持對通信雙方做身份校檢，因而大大提升了安全性。
二、 Binder
IPC原理
從進程角度來看IPC機制
每個Android的進程，只能運行在自己進程所擁有的虛擬地址空間。對應一個4GB的虛擬地址空間，其中3GB是用戶空間，1GB是內核空間，當然內核空間的大小是可以通過參數(shù)配置調整的。對于用戶空間，不同進程之間彼此是不能共享的，而內核空間卻是可共享的。Client進程向Server進程通信，恰恰是利用進程間可共享的內核內存空間來完成底層通信工作的，Client端與Server端進程往往采用ioctl等方法跟內核空間的驅動進行交互。
Binder原理
Binder通信采用C/S架構，從組件視角來說，包含Client、Server、ServiceManager以及binder驅動，其中ServiceManager用于管理系統(tǒng)中的各種服務。架構圖如下所示：
Binder通信的四個角色
Client進程：使用服務的進程。
Server進程：提供服務的進程。
ServiceManager進程：ServiceManager的作用是將字符形式的Binder名字轉化成Client中對該Binder的引用，使得Client能夠通過Binder名字獲得對Server中Binder實體的引用。
Binder驅動：驅動負責進程之間Binder通信的建立，Binder在進程之間的傳遞，Binder引用計數(shù)管理，數(shù)據(jù)包在進程之間的傳遞和交互等一系列底層支持。
Binder運行機制
圖中Client/Server/ServiceManage之間的相互通信都是基于Binder機制。既然基于Binder機制通信，那么同樣也是C/S架構，則圖中的3大步驟都有相應的Client端與Server端。
注冊服務(addService)：Server進程要先注冊Service到ServiceManager。該過程：Server是客戶端，ServiceManager是服務端。
獲取服務(getService)：Client進程使用某個Service前，須先向ServiceManager中獲取相應的Service。該過程：Client是客戶端，ServiceManager是服務端。
使用服務：Client根據(jù)得到的Service信息建立與Service所在的Server進程通信的通路，然后就可以直接與Service交互。該過程：client是客戶端，server是服務端。
圖中的Client,Server,Service Manager之間交互都是虛線表示，是由于它們彼此之間不是直接交互的，而是都通過與Binder驅動進行交互的，從而實現(xiàn)IPC通信方式。其中Binder驅動位于內核空間，Client,Server,Service Manager位于用戶空間。Binder驅動和Service Manager可以看做是Android平臺的基礎架構，而Client和Server是Android的應用層，開發(fā)人員只需自定義實現(xiàn)client、Server端，借助Android的基本平臺架構便可以直接進行IPC通信。
Binder運行的實例解釋
首先我們看看我們的程序跨進程調用系統(tǒng)服務的簡單示例，實現(xiàn)浮動窗口部分代碼：
//獲取WindowManager服務引用
WindowManager wm = (WindowManager)getSystemService(getApplication().WINDOW_SERVICE);
//布局參數(shù)layoutParams相關設置略...
View view=LayoutInflater.from(getApplication()).inflate(R.layout.float_layout, null);
//添加view
wm.addView(view, layoutParams);
注冊服務(addService)：在Android開機啟動過程中，Android會初始化系統(tǒng)的各種Service，并將這些Service向ServiceManager注冊（即讓ServiceManager管理）。這一步是系統(tǒng)自動完成的。
獲取服務(getService)：客戶端想要得到具體的Service直接向ServiceManager要即可。客戶端首先向ServiceManager查詢得到具體的Service引用，通常是Service引用的代理對象，對數(shù)據(jù)進行一些處理操作。即第2行代碼中，得到的wm是WindowManager對象的引用。
使用服務：通過這個引用向具體的服務端發(fā)送請求，服務端執(zhí)行完成后就返回。即第6行調用WindowManager的addView函數(shù)，將觸發(fā)遠程調用，調用的是運行在systemServer進程中的WindowManager的addView函數(shù)。
使用服務的具體執(zhí)行過程
- client通過獲得一個server的代理接口，對server進行調用。
- 代理接口中定義的方法與server中定義的方法時一一對應的。
- client調用某個代理接口中的方法時，代理接口的方法會將client傳遞的參數(shù)打包成Parcel對象。
- 代理接口將Parcel發(fā)送給內核中的binder driver。
- server會讀取binder driver中的請求數(shù)據(jù)，如果是發(fā)送給自己的，解包Parcel對象，處理并將結果返回。
- 整個的調用過程是一個同步過程，在server處理的時候，client會block住。因此client調用過程不應在主線程。
以上就是Binder機制原理的簡單介紹，后面會以AIDL來具體介紹Binder機制的使用，加深對其的了解。
