Android——Binder

標籤：src   多個   nsa   來講   cat   roi   fifo   維護   es2017   

該文章的知識點基本上來自於這個串連，然後融入了自己的一些理解：http://gityuan.com/2015/10/31/binder-prepare/

1. 背景知識

Android的四層結構中，最底層是linux的kenel層，也就是說Android實際上還是基於linux來進行實現的，基本的實現代碼是C語言，而C語言是一個面向結構的語言，而非是物件導向的語言

那麼，linux中有很多的IPC通訊機制，來進行進程間的通訊，為何android還要建立自己的處理序間通訊機制Binder哪？ 接下來，先看下linux下不同的通訊機制

linux下的進程通訊手段基本上都是從Unix平台上繼承而來的，最初的Unix IPC有

管道及有名管道：管道在建立的時候會分配一個page大小的記憶體，其緩衝區大小比較有限，而且管道在資料拷貝時需要進行兩次拷貝

訊息佇列：一個FIFO的訊息佇列，同樣需要進行兩次資料拷貝，而且由於需要維護這個訊息佇列，因此是需要額外的CPU消耗的，並不適合與資訊量很大的通訊

訊號：訊號本質上是通知某個進程某個事情發生了，從而某個進程知道自己下一步需要幹些什麼，進程也可以自己給自己發訊號進行控制。所以訊號更加適合與進程的中斷控制等等，而不是用來進行資訊的交換

訊號量：更多地是作為一種鎖的機制，保證了進程之間以及線程之間的資料同步問題。

套介面：更為一般的處理序間通訊機制，主要是用於不同的作業系統，不同的裝置，不同的網路之間的處理序間通訊。最初由Unix系統的BSD分支開發，後來被廣泛應用與其他系統之上。但是由於其更加通用，因此傳輸效率是比較低的，而且同樣需要拷貝兩次資料

共用記憶體：多個進程可以訪問同一個記憶體空間，是所有IPC中效率最高的處理序間通訊，而且根本不需要任何的資料拷貝，是直接共用的。

 

2. Binder的出現

綜上，訊號和訊號量基本上被排除了，不適合與用來進行Android四大組件之間的資訊傳遞，接下來就剩其他三個了

（1） 語言上，linux的IPC都是使用C語言來實現的，而整個Android的framework層以及application層都是使用java來實現的。

（2） 從協議上來講，Android的創造者並不像開源他的代碼，這也是自身的商業性質決定的。而linux的主線是開源的。

上面這兩個可能是Binder出現的最本質原因，而下面是從開發人員角度來看

（3） 效能上，binder只需要一次資料拷貝，而管道 ，套介面，訊息佇列都需要兩次資料拷貝。

（4） 共用記憶體雖然不需要進行資料拷貝。但從穩定性上來講，採用C/S的bander比共用記憶體更加穩定。

（5） 安全上，linux的IPC無法擷取對方進程可靠的UID/PID，而Android給應用程式指派了自己的UID，而且C/S模式保證了Android系統對外只暴露client，而保護了server端。

 

3. BBinder，BpBinder，IBinder

BBinder：對於serveice來說，都是繼承了BBinder（BnInterface）。BBinder.onTransact()接收相應的事務請求

BpBinder：對與client來說，都是繼承了BpBinder（BpInterface）。BpBinder.transact()分發事務請求

IBinder：相當於一個指標，就像socket的ID一樣，IBinder是一個進程的唯一標識，是重構上述兩個Binder時作為參數傳入的。BBinder和BpBinder都是繼承於IBinder的

 

4. Binder的架構

圖片同樣來自於：http://gityuan.com/2015/10/31/binder-prepare/

（1） Service Manager相當於一個管理者，指的是Native曾的ServiceManager（C++），是Binder的守護進程

（2） Client和Server的通訊需要先擷取Service Manager介面，然後才能開始進行通訊

 

 

源碼分析之後會慢慢補上。。。

 

           

 

Android——Binder