Android 源碼分析 — Binder機制

首先來看一張Android Binder系統啟動並執行時序圖:

 

(此圖來自於google搜圖)

       從時序圖上來看，整個Android Binder系統還是有些複雜的，但是仔細分析可能會發現整個Android Binder運行機制似乎與某種常見的系統架構類似，是的，那就是我們經常會見到的基於RPC機制的C/S架構了。

　　為了便於對比和解釋Android Binder的原理，我們先從一個比較熟悉的情境分析: 對於一個基於RPC（遠端程序呼叫）的C/S系統，我們將其抽象並簡化，基本上由”server”,”client”,”service_manager”,”rpc-api”,”service-info”(代表每個提供service的server的資訊)這5部分構成。

       另一方面，對於大量基於RPC的network-server，我們發現其中有相當一部分的功能和組件是獨立於具體的服務功能而保持不變的。比如”多路事件分發”，”並發控制”，”記憶體管理”，”session管理”……於是，為了避免一次又一次地”reinvent the wheel”,許多network-server framework就誕生了。比如: ACE,boost.asio,libevent……在這些架構的基礎之上，我們只需要實現特定於具體服務處理邏輯的組件，然後與架構拼裝起來即可。

       如果你熟悉network-server開發，或者對其有所瞭解，基於上面的描述，應該能瞭解整個基於RPC的網路伺服器的基本架構了。

       說了這麼多，它跟Binder有什麼關係呢？我們先來看一張圖。

 

 

       圖中的"------"表示虛線兩端的組件是等價的，看了這個圖，應該對Android-Binder這個並不太容易理解的組件有一個清晰的認識了吧:)

       Binder作為Android系統的核心基礎組件，用於簡化Android中底層服務的開發，以及服務之間的資料通訊。因為這些服務都運行在同一台Android機器上，而且這些服務之間的關係類似於一種C/S架構，所以這個時候需要的不是RPC架構，而是IPC架構。而Android系統中的Binder架構正是提供這種功能的IPC架構。

       看了這個圖，有的人可能會有想到: RPC 的client端是基於ip:port來定位到具體的server端，那麼Binder架構中，client端又是基於什麼機制來定位server端呢?答案是: “handler”。過程是這樣的:

　　1) 對於service_manager，它的handler是固定的且值為0。

　　2) 當其它的service註冊到service_manager中時，service_manager會為它分配一個唯一的handler值，並建立一個“service_name ßàhandler”的一一映射關係。

　　3)  當一個client需要訪問一個具體的service時，它會將所需要訪問的service的service_name傳遞給service_manager，然後service_manager會依據這個service_name在所管理的服務中尋找到對應的handler。

　　4)  此後，client與server之間就可以基於這個”handler”作為通訊之間的標識，基於Android的Binder設定進行通訊，這一點類似於當client擷取到了server端的ip:port之後，基於socket來與服務端進行通訊。

 

　　後續的文章中會繼續對Android Binder進行深入分析，錯漏之處敬請指正。

轉自http://www.cnblogs.com/xwroyal/archive/2012/01/15/2322733.html