binder工作在linux層面，屬於乙個驅動，只是這個驅動不需要硬體，或者說其操作的硬體是基於一小段記憶體。從執行緒的角度來講，binder驅動**執行在核心態，客戶端程式呼叫binder是通過系統呼叫完成的。
binder是一種架構，這種架構提供了服務端介面、binder驅動、客戶端介面三個模組，如圖所示。
首先來看服務端。乙個binder服務端實際上就是乙個binder類的物件，該物件一旦建立，內部就啟動乙個隱藏執行緒。該執行緒接下來會接收binder驅動傳送的訊息，收到訊息後，會執行到binder物件中的ontransact()函式，並按照該函式的引數執行不同的服務**。因此，要實現乙個binder服務，就必須過載ontransact()方法。
可以想象，過載ontransact()函式的主要內容是把ontransact()函式的引數轉換為服務函式的引數，而ontransact()函式的引數**是客戶端呼叫transact()函式時輸入的，因此，如果transact()有固定格式的輸入，那麼ontransact()就會有固定格式的輸出。
下面再看binder驅動。任意乙個服務端binder物件被建立時，同時會在binder驅動中建立乙個mremote物件，該物件的型別也是binder類。客戶端要訪問遠端服務時，都是通過mremote物件。
最後來看應用程式客戶端。客戶端要想訪問遠端服務，必須獲取遠端服務在binder物件中對應的mremote引用。獲得該mremote物件後，就可以呼叫其transact()方法，而在binder驅動中，mremote物件也過載了transact()方法，過載的內容主要包括以下幾項。
以執行緒間訊息通訊的模式，向服務端傳送客戶端傳遞過來的引數。
掛起當前執行緒，當前執行緒正是客戶端執行緒，並等待服務端執行緒執行完指定服務函式後通知(notify)。
接收到服務端執行緒的通知，然後繼續執行客戶端執行緒，並返回到客戶端**區。
從這裡可以看出，對應用程式開發員來講，客戶端似乎是直接呼叫遠端服務對應的binder，而事實上則是通過binder驅動進行了中轉。即存在兩個binder物件，乙個是服務端的binder物件，另乙個則是binder驅動中的binder物件，所不同的是binder驅動中的物件不會再額外產生乙個執行緒。
核心研究 Binder客戶端設計
要想使用服務端，首先要獲取服務端在binder驅動中對應的mremote變數的引用。獲得該變數的引用後，就可以呼叫該變數的transact 方法。該方法的函式原型如下 public final boolean transact int code,parcel data,parcel reply,in...
Binder驅動研究
好久沒寫過部落格了，也沒怎麼研究過原始碼，偶爾看到別人的部落格都是系列研究，自愧不如啊，所以也下下來android原始碼開始看了，參考網上的講解，結合原始碼。希望這樣記錄下自己的閱讀歷程，也不枉虛度時光了。先從android的binder驅動說起吧，以前也不懂linux驅動，有說錯的地方敬請諒解，歡...
核心研究 Framework框架
framework定義了客戶端元件和服務端元件功能及介面。以下闡述中，應用程式 一般是指 apk 程式。框架中包含三個主要部分，分別為服務端 客戶端和linux驅動。服務端 服務端主要包含兩個重要類，分別是windowmanagerservice wms 和activitymanagerservic...