在代碼分析中，我發現Android中只是把Binder理解成進程間通訊的實現，有點狹隘，而是應該站在公共對象請求代理這個高度來理解Binder，Service的概念，這樣我們就會看到不一樣的格局，從這個高度來理解設計意圖，我們才會對Android中的一些天才想法感到驚奇。從Android的外特性概念空間中，我們看不到進程的概念，而是Activity，Service，AIDL，INTENT。一般的如果我作為設計者，在我們的根深蒂固的想法中，這些都是如下的C/S架構，客戶端和服務端直接通過Binder交互數據，打開Binder寫入數據，通過Binder讀取數據，通訊就可以完成了。
該注意到Android的概念中，Binder是一個很低層的概念，上面一層根本都看不到Binder，而是Activity跟一個Service的對象直接通過方法調用，獲取服務。
這個就是Android提供給我們的外特性：在Android中，要完成某個操作，所需要做的就是請求某個有能力的服務對象去完成動作，而無需知道這個通訊是怎樣工作的，以及服務在哪裡。所以Andoid的IPC在本質上屬於對象請求代理架構，Android的設計者用CORBA的概念將自己包裝了一下，實現了一個微型的輕量級CORBA架構，這就是Andoid的IPC設計的意圖所在，它並不是僅僅解決通訊，而是給出了一個架構，一種設計理念，這就是Android的閃光的地方。Android的Binder更多考慮了數據交換的便捷，並且只是解決本機的進程間的通訊，所以不像CORBA那樣復雜，所以叫做輕量級。
所以要理解Android的IPC架構，就需要了解CORBA的架構。而CORBA的架構在本質上可以使用下面圖來表示：
在服務端，多了一個代理器，更為抽象一點我們可以下圖來表示。
分析和CORBA的大體理論架構，我給出下面的Android的對象代理結構。
在結構圖中，我們可以較為清楚的把握Android的ＩＰＣ包含了如下的概念：
設備上下文包含關於客服端，環境或者請求中沒有作為參數傳遞個操作的上下文信息，應用程序開發者用ContextObject接口上定義的操作來創建和操作上下文。
Android的外特性空間是不需要知道服務在那裡，只要通過代理對象完成請求，但是我們要探究Android是如何實現這個架構，首先要問的是在Client端要完成雲服務端的通訊，首先應該知道服務在哪裡？我們首先來看看Service Manger管理了那些數據。Service Manager提供了add service,check service兩個重要的方法，並且維護了一個服務列表記錄登記的服務名稱和句柄。
Service manager service使用0來標識自己。並且在初始化的時候，通過binder設備使用BINDER_SET_CONTEXT_MGR ioctl將自己變成了CONTEXT_MGR。Svclist中存儲了服務的名字和Handle，這個Handle作為Client端發起請求時的目標地址。服務通過add_service方法將自己的名字和Binder標識handle登記在svclist中。而服務請求者，通過check_service方法，通過服務名字在service list中獲取到service 相關聯的Binder的標識handle,通過這個Handle作為請求包的目標地址發起請求。
我們理解了Service Manager的工作就是登記功能，現在再回到ＩＰＣ上，客服端如何建立連接的？我們首先回到通訊的本質：IPC。從一般的概念來講，Android設計者在Linux內核中設計了一個叫做Binder的設備文件，專門用來進行Android的數據交換。所有從數據流來看Java對象從Java的VM空間進入到C++空間進行了一次轉換，並利用C++空間的函數將轉換過的對象通過driver/binder設備傳遞到服務進程，從而完成進程間的IPC。這個過程可以用下圖來表示。
這裡數據流有幾層轉換過程。
（1） 從JVM空間傳到c++空間，這個是靠JNI使用ENV來完成對象的映射過程。
（2） 從c++空間傳入內核Binder設備，使用ProcessState類完成工作。
（3） Service從內核中Binder設備讀取數據。
Ａｎｄｒｏｉｄ設計者需要利用面向對象的技術設計一個框架來屏蔽掉這個過程。要讓上層概念空間中沒有這些細節。Android設計者是怎樣做的呢？我們通過c++空間代碼分析，看到有如下空間概念包裝(ProcessState@(ProcessState.cpp)
在ProcessState類中包含了通訊細節，利用open_binder打開Linux設備dev/binder,通過ioctrl建立的基本的通訊框架。利用上層傳遞下來的servicehandle來確定請求發送到那個Service。通過分析我終於明白了Bnbinder，BpBinder的命名含義，Bn-代表Native，而Bp代表Proxy。一旦理解到這個層次，ProcessState就容易弄明白了。
下面我們看JVM概念空間中對這些概念的包裝。為了通篇理解設備上下文，我們需要將Android VM概念空間中的設備上下文和C++空間總的設備上下文連接起來進行研究。
為了在上層使用統一的接口，在JVM層面有兩個東西。在Android中，為了簡化管理框架，引入了ServiceManger這個服務。所有的服務都是從ServiceManager開始的，只用通過Service Manager獲取到某個特定的服務標識構建代理IBinder。在Android的設計中利用Service Manager是默認的Handle為0，只要設置請求包的目標句柄為0，就是發給Service Manager這個Service的。在做服務請求時，Android建立一個新的Service Manager Proxy。Service Manager Proxy使用ContexObject作為Binder和Service Manager Service（服務端）進行通訊。
