Binder學習指南（轉）

毫不誇張地說，Binder是Android系統中最重要的特性之一；正如其名“粘合劑”所喻，它是系統間各個組件的橋樑，Android系統的開放式設計也很大程度上得益於這種及其方便的跨進程通信機制。

理解Binder對於理解整個Android系統有着非常重要的作用，Android系統的四大組件，AMS，PMS等系統服務無一不與Binder掛鉤；如果對Binder不甚瞭解，那麼就很難了解這些系統機制，從而僅僅浮游與表面，不懂Binder你都不好意思說自己會Android開發；要深入Android，Binder是必須邁出的一步。

現在網上有不少資料介紹Binder，個人覺得最好的兩篇如下：

Binder設計與實現
 Android進程間通信（IPC）機制Binder簡要介紹和學習計劃系列

其中, 《Binder設計與實現》以一種宏觀的角度解釋了Android系統中的Binder機制，文章如行雲流水；如果對於Binder有一定的瞭解再來看着篇文章，有一種打通任督二脈的感覺；每看一次理解就深一層。老羅的系列文章則從系統源碼角度深入分析了Binder的實現細節；具有很大的參考意義；每當對於Binder細節有疑惑，看一看他的書就迎刃而解。

但是遺憾的是，Binder機制終究不是三言兩語就能解釋清楚的，一上來就扒出源碼很可能深陷細節無法自拔，老羅的文章那不是一般的長，如果看不懂強行看很容易睡着；勉強看完還是雲裏霧裏；相反如果直接大談特談Binder的設計，那麼完全就是不知所云；因此上述兩篇文章對於初學者並不友好，本文不會深入源碼細節，也不會對於Binder的設計高談闊論；重點如下：

1、一些Linux的預備知識
2、Binder到底是什麼？
3、Binder機制是如何跨進程的？
4、一次Binder通信的基本流程是什麼樣？
5、深入理解Java層的Binder

讀完本文，你應該對於Java層的AIDL瞭如指掌，對於Binder也會有一個大體上的認識；再深入學習就得靠自己了，本人推薦的Binder學習路徑如下：

1、先學會熟練使用AIDL進行跨進程通信（簡單來說就是遠程Service）
2、看完本文
3、看Android文檔，Parcel, IBinder, Binder等涉及到跨進程通信的類
4、不依賴AIDL工具，手寫遠程Service完成跨進程通信
5、看《Binder設計與實現》
6、看老羅的博客或者書（書結構更清晰）
7、再看《Binder設計與實現》
8、學習Linux系統相關知識；自己看源碼。

背景知識

爲了理解Binder我們先澄清一些概念。爲什麼需要跨進程通信（IPC），怎麼做到跨進程通信？爲什麼是Binder？

由於Android系統基於Linux內核，因此有必要了解相關知識。

進程隔離

進程隔離是爲保護操作系統中進程互不干擾而設計的一組不同硬件和軟件的技術。這個技術是爲了避免進程A寫入進程B的情況發生。進程的隔離實現，使用了虛擬地址空間。進程A的虛擬地址和進程B的虛擬地址不同，這樣就防止進程A將數據信息寫入進程B。

以上來自維基百科；操作系統的不同進程之間，數據不共享；對於每個進程來說，它都天真地以爲自己獨享了整個系統，完全不知道其他進程的存在；(有關虛擬地址，請自行查閱）因此一個進程需要與另外一個進程通信，需要某種系統機制才能完成。

用戶空間/內核空間

詳細解釋可以參考Kernel Space Definition；簡單理解如下：

Linux Kernel是操作系統的核心，獨立於普通的應用程序，可以訪問受保護的內存空間，也有訪問底層硬件設備的所有權限。

對於Kernel這麼一個高安全級別的東西，顯然是不容許其它的應用程序隨便調用或訪問的，所以需要對Kernel提供一定的保護機制，這個保護機制用來告訴那些應用程序，你只可以訪問某些許可的資源，不許可的資源是拒絕被訪問的，於是就把Kernel和上層的應用程序抽像的隔離開，分別稱之爲Kernel Space和User Space。

系統調用/內核態/用戶態

雖然從邏輯上抽離出用戶空間和內核空間；但是不可避免的的是，總有那麼一些用戶空間需要訪問內核的資源；比如應用程序訪問文件，網絡是很常見的事情，怎麼辦呢？

Kernel space can be accessed by user processes only through the use of system calls.

用戶空間訪問內核空間的唯一方式就是系統調用；通過這個統一入口接口，所有的資源訪問都是在內核的控制下執行，以免導致對用戶程序對系統資源的越權訪問，從而保障了系統的安全和穩定。用戶軟件良莠不齊，要是它們亂搞把系統玩壞了怎麼辦？因此對於某些特權操作必須交給安全可靠的內核來執行。

當一個任務（進程）執行系統調用而陷入內核代碼中執行時，我們就稱進程處於內核運行態（或簡稱爲內核態）此時處理器處於特權級最高的（0級）內核代碼中執行。當進程在執行用戶自己的代碼時，則稱其處於用戶運行態（用戶態）。即此時處理器在特權級最低的（3級）用戶代碼中運行。處理器在特權等級高的時候才能執行那些特權CPU指令。

內核模塊/驅動

通過系統調用，用戶空間可以訪問內核空間，那麼如果一個用戶空間想與另外一個用戶空間進行通信怎麼辦呢？很自然想到的是讓操作系統內核添加支持；傳統的Linux通信機制，比如Socket，管道等都是內核支持的；但是Binder並不是Linux內核的一部分，它是怎麼做到訪問內核空間的呢？Linux的動態可加載內核模塊（Loadable Kernel Module，LKM）機制解決了這個問題；模塊是具有獨立功能的程序，它可以被單獨編譯，但不能獨立運行。它在運行時被鏈接到內核作爲內核的一部分在內核空間運行。這樣，Android系統可以通過添加一個內核模塊運行在內核空間，用戶進程之間的通過這個模塊作爲橋樑，就可以完成通信了。

在Android系統中，這個運行在內核空間的，負責各個用戶進程通過Binder通信的內核模塊叫做Binder驅動;

驅動程序一般指的是設備驅動程序（Device Driver），是一種可以使計算機和設備通信的特殊程序。相當於硬件的接口，操作系統只有通過這個接口，才能控制硬件設備的工作；

驅動就是操作硬件的接口，爲了支持Binder通信過程，Binder使用了一種“硬件”，因此這個模塊被稱之爲驅動。

爲什麼使用Binder？

Android使用的Linux內核擁有着非常多的跨進程通信機制，比如管道，System V，Socket等；爲什麼還需要單獨搞一個Binder出來呢？主要有兩點，性能和安全。在移動設備上，廣泛地使用跨進程通信肯定對通信機制本身提出了嚴格的要求；Binder相對出傳統的Socket方式，更加高效；另外，傳統的進程通信方式對於通信雙方的身份並沒有做出嚴格的驗證，只有在上層協議上進行架設；比如Socket通信ip地址是客戶端手動填入的，都可以進行僞造；而Binder機制從協議本身就支持對通信雙方做身份校檢，因而大大提升了安全性。這個也是Android權限模型的基礎。

Binder通信模型

對於跨進程通信的雙方，我們姑且叫做Server進程（簡稱Server），Client進程（簡稱Client）；由於進程隔離的存在，它們之間沒辦法通過簡單的方式進行通信，那麼Binder機制是如何進行的呢？

回想一下日常生活中我們通信的過程：假設A和B要進行通信，通信的媒介是打電話（A是Client，B是Server）；A要給B打電話，必須知道B的號碼，這個號碼怎麼獲取呢？通信錄.

這個通信錄就是一張表；內容大致是：

B -> 12345676
C -> 12334354

先查閱通信錄，拿到B的號碼；才能進行通信；否則，怎麼知道應該撥什麼號碼？回想一下古老的電話機，如果A要給B打電話，必須先連接通話中心，說明給我接通B的電話；這時候通話中心幫他呼叫B；連接建立，就完成了通信。

另外，光有電話和通信錄是不可能完成通信的，沒有基站支持；信息根本無法傳達。

我們看到，一次電話通信的過程除了通信的雙方還有兩個隱藏角色：通信錄和基站。Binder通信機制也是一樣：兩個運行在用戶空間的進程要完成通信，必須藉助內核的幫助，這個運行在內核裏面的程序叫做Binder驅動，它的功能類似於基站；通信錄呢，就是一個叫做ServiceManager的東西（簡稱SM）

OK，Binder的通信模型就是這麼簡單，如下圖：

整個通信步驟如下：

SM建立(建立通信錄)；首先有一個進程向驅動提出申請爲SM；驅動同意之後，SM進程負責管理Service（注意這裏是Service而不是Server，因爲如果通信過程反過來的話，那麼原來的客戶端Client也會成爲服務端Server）不過這時候通信錄還是空的，一個號碼都沒有。
各個Server向SM註冊(完善通信錄)；每個Server端進程啓動之後，向SM報告，我是zhangsan,
要找我請返回0x1234(這個地址沒有實際意義，類比)；其他Server進程依次如此；這樣SM就建立了一張表，對應着各個Server的名字和地址；就好比B與A見面了，說存個我的號碼吧，以後找我撥打10086；
Client想要與Server通信，首先詢問SM；請告訴我如何聯繫zhangsan，SM收到後給他一個號碼0x1234；Client收到之後，開心滴用這個號碼撥通了Server的電話，於是就開始通信了。

那麼Binder驅動幹什麼去了呢？這裏Client與SM的通信，以及Client與Server的通信，都會經過驅動，驅動在背後默默無聞，但是做着最重要的工作。驅動是整個通信過程的核心，因此完成跨進程通信的祕密全部隱藏在驅動裏面；這個我們稍後討論。

OK，上面就是整個Binder通信的基本模型；做了一個簡單的類比，當然也有一些不恰當的地方，(比如通信錄現實中每個人都有一個，但是SM整個系統只有一個；基站也有很多個，但是驅動只有一個）；但是整體上就是這樣的；我們看到其實整個通信模型非常簡單。

Binder機制跨進程原理

上文給出了Binder的通信模型，指出了通信過程的四個角色: Client, Server, SM, driver; 但是我們仍然不清楚Client到底是如何與Server完成通信的。

兩個運行在用戶空間的進程A和進程B如何完成通信呢？內核可以訪問A和B的所有數據；所以，最簡單的方式是通過內核做中轉；假設進程A要給進程B發送數據，那麼就先把A的數據copy到內核空間，然後把內核空間對應的數據copy到B就完成了；用戶空間要操作內核空間，需要通過系統調用；剛好，這裏就有兩個系統調用：copy_from_user, copy_to_user。

但是，Binder機制並不是這麼幹的。講這麼一段，是說明進程間通信並不是什麼神祕的東西。那麼，Binder機制是如何實現跨進程通信的呢？

Binder驅動爲我們做了一切。

假設Client進程想要調用Server進程的object對象的一個方法add;對於這個跨進程通信過程，我們來看看Binder機制是如何做的。（通信是一個廣泛的概念，只要一個進程能調用另外一個進程裏面某對象的方法，那麼具體要完成什麼通信內容就很容易了。）

首先，Server進程要向SM註冊；告訴自己是誰，自己有什麼能力；在這個場景就是Server告訴SM，它叫zhangsan，它有一個object對象，可以執行add 操作；於是SM建立了一張表：zhangsan這個名字對應進程Server;

然後Client向SM查詢：我需要聯繫一個名字叫做zhangsan的進程裏面的object對象；這時候關鍵來了：進程之間通信的數據都會經過運行在內核空間裏面的驅動，驅動在數據流過的時候做了一點手腳，它並不會給Client進程返回一個真正的object對象，而是返回一個看起來跟object一模一樣的代理對象objectProxy，這個objectProxy也有一個add方法，但是這個add方法沒有Server進程裏面object對象的add方法那個能力；objectProxy的add只是一個傀儡，它唯一做的事情就是把參數包裝然後交給驅動。(這裏我們簡化了SM的流程，見下文)

但是Client進程並不知道驅動返回給它的對象動過手腳，畢竟僞裝的太像了，如假包換。Client開開心心地拿着objectProxy對象然後調用add方法；我們說過，這個add什麼也不做，直接把參數做一些包裝然後直接轉發給Binder驅動。

驅動收到這個消息，發現是這個objectProxy；一查表就明白了：我之前用objectProxy替換了object發送給Client了，它真正應該要訪問的是object對象的add方法；於是Binder驅動通知Server進程，調用你的object對象的add方法，然後把結果發給我，Sever進程收到這個消息，照做之後將結果返回驅動，驅動然後把結果返回給Client進程；於是整個過程就完成了。

由於驅動返回的objectProxy與Server進程裏面原始的object是如此相似，給人感覺好像是直接把Server進程裏面的對象object傳遞到了Client進程；因此，我們可以說Binder對象是可以進行跨進程傳遞的對象

但事實上我們知道，Binder跨進程傳輸並不是真的把一個對象傳輸到了另外一個進程；傳輸過程好像是Binder跨進程穿越的時候，它在一個進程留下了一個真身，在另外一個進程幻化出一個影子（這個影子可以很多個）；Client進程的操作其實是對於影子的操作，影子利用Binder驅動最終讓真身完成操作。

理解這一點非常重要；務必仔細體會。另外，Android系統實現這種機制使用的是代理模式, 對於Binder的訪問，如果是在同一個進程（不需要跨進程），那麼直接返回原始的Binder實體；如果在不同進程，那麼就給他一個代理對象（影子）；我們在系統源碼以及AIDL的生成代碼裏面可以看到很多這種實現。

另外我們爲了簡化整個流程，隱藏了SM這一部分驅動進行的操作；實際上，由於SM與Server通常不在一個進程，Server進程向SM註冊的過程也是跨進程通信，驅動也會對這個過程進行暗箱操作：SM中存在的Server端的對象實際上也是代理對象，後面Client向SM查詢的時候，驅動會給Client返回另外一個代理對象。Sever進程的本地對象僅有一個，其他進程所擁有的全部都是它的代理。

一句話總結就是：Client進程只不過是持有了Server端的代理；代理對象協助驅動完成了跨進程通信。

Binder到底是什麼？

我們經常提到Binder，那麼Binder到底是什麼呢？

Binder的設計採用了面向對象的思想，在Binder通信模型的四個角色裏面；他們的代表都是“Binder”，這樣，對於Binder通信的使用者而言，Server裏面的Binder和Client裏面的Binder沒有什麼不同，一個Binder對象就代表了所有，它不用關心實現的細節，甚至不用關心驅動以及SM的存在；這就是抽象。

通常意義下，Binder指的是一種通信機制；我們說AIDL使用Binder進行通信，指的就是Binder這種IPC機制。
對於Server進程來說，Binder指的是Binder本地對象
對於Client來說，Binder指的是Binder代理對象，它只是Binder本地對象的一個遠程代理；對這個Binder代理對象的操作，會通過驅動最終轉發到Binder本地對象上去完成；對於一個擁有Binder對象的使用者而言，它無須關心這是一個Binder代理對象還是Binder本地對象；對於代理對象的操作和對本地對象的操作對它來說沒有區別。
對於傳輸過程而言，Binder是可以進行跨進程傳遞的對象；Binder驅動會對具有跨進程傳遞能力的對象做特殊處理：自動完成代理對象和本地對象的轉換。

面向對象思想的引入將進程間通信轉化爲通過對某個Binder對象的引用調用該對象的方法，而其獨特之處在於Binder對象是一個可以跨進程引用的對象，它的實體（本地對象）位於一個進程中，而它的引用（代理對象）卻遍佈於系統的各個進程之中。最誘人的是，這個引用和java裏引用一樣既可以是強類型，也可以是弱類型，而且可以從一個進程傳給其它進程，讓大家都能訪問同一Server，就象將一個對象或引用賦值給另一個引用一樣。Binder模糊了進程邊界，淡化了進程間通信過程，整個系統彷彿運行於同一個面向對象的程序之中。形形色色的Binder對象以及星羅棋佈的引用彷彿粘接各個應用程序的膠水，這也是Binder在英文裏的原意。

驅動裏面的Binder

我們現在知道，Server進程裏面的Binder對象指的是Binder本地對象，Client裏面的對象值得是Binder代理對象；在Binder對象進行跨進程傳遞的時候，Binder驅動會自動完成這兩種類型的轉換；因此Binder驅動必然保存了每一個跨越進程的Binder對象的相關信息；在驅動中，Binder本地對象的代表是一個叫做binder_node的數據結構，Binder代理對象是用binder_ref代表的；有的地方把Binder本地對象直接稱作Binder實體，把Binder代理對象直接稱作Binder引用（句柄），其實指的是Binder對象在驅動裏面的表現形式；讀者明白意思即可。

OK，現在大致瞭解Binder的通信模型，也瞭解了Binder這個對象在通信過程中各個組件裏面到底表示的是什麼。

深入理解Java層的Binder

IBinder/IInterface/Binder/BinderProxy/Stub

我們使用AIDL接口的時候，經常會接觸到這些類，那麼這每個類代表的是什麼呢？

IBinder是一個接口，它代表了一種跨進程傳輸的能力；只要實現了這個接口，就能將這個對象進行跨進程傳遞；這是驅動底層支持的；在跨進程數據流經驅動的時候，驅動會識別IBinder類型的數據，從而自動完成不同進程Binder本地對象以及Binder代理對象的轉換。
IBinder負責數據傳輸，那麼client與server端的調用契約（這裏不用接口避免混淆）呢？這裏的IInterface代表的就是遠程server對象具有什麼能力。具體來說，就是aidl裏面的接口。
Java層的Binder類，代表的其實就是Binder本地對象。BinderProxy類是Binder類的一個內部類，它代表遠程進程的Binder對象的本地代理；這兩個類都繼承自IBinder,
因而都具有跨進程傳輸的能力；實際上，在跨越進程的時候，Binder驅動會自動完成這兩個對象的轉換。
在使用AIDL的時候，編譯工具會給我們生成一個Stub的靜態內部類；這個類繼承了Binder,
說明它是一個Binder本地對象，它實現了IInterface接口，表明它具有遠程Server承諾給Client的能力；Stub是一個抽象類，具體的IInterface的相關實現需要我們手動完成，這裏使用了策略模式。

AIDL過程分析

現在我們通過一個AIDL的使用，分析一下整個通信過程中，各個角色到底做了什麼，AIDL到底是如何完成通信的。（如果你連AIDL都不熟悉，請先查閱官方文檔）

首先定一個一個簡單的aidl接口：

// ICompute.aidl
package com.example.test.app;
interface ICompute {
     int add(int a, int b);
}

然後用編譯工具編譯之後，可以得到對應的ICompute.java類，看看系統給我們生成的代碼：

package com.example.test.app;

public interface ICompute extends android.os.IInterface {
    /**
     * Local-side IPC implementation stub class.
     */
    public static abstract class Stub extends android.os.Binder implements com.example.test.app.ICompute {
        private static final java.lang.String DESCRIPTOR = "com.example.test.app.ICompute";

        /**
         * Construct the stub at attach it to the interface.
         */
        public Stub() {
            this.attachInterface(this, DESCRIPTOR);
        }

        /**
         * Cast an IBinder object into an com.example.test.app.ICompute interface,
         * generating a proxy if needed.
         */
        public static com.example.test.app.ICompute asInterface(android.os.IBinder obj) {
            if ((obj == null)) {
                return null;
            }
            android.os.IInterface iin = obj.queryLocalInterface(DESCRIPTOR);
            if (((iin != null) && (iin instanceof com.example.test.app.ICompute))) {
                return ((com.example.test.app.ICompute) iin);
            }
            return new com.example.test.app.ICompute.Stub.Proxy(obj);
        }

        @Override
        public android.os.IBinder asBinder() {
            return this;
        }

        @Override
        public boolean onTransact(int code, android.os.Parcel data, android.os.Parcel reply, int flags) throws android.os.RemoteException {
            switch (code) {
                case INTERFACE_TRANSACTION: {
                    reply.writeString(DESCRIPTOR);
                    return true;
                }
                case TRANSACTION_add: {
                    data.enforceInterface(DESCRIPTOR);
                    int _arg0;
                    _arg0 = data.readInt();
                    int _arg1;
                    _arg1 = data.readInt();
                    int _result = this.add(_arg0, _arg1);
                    reply.writeNoException();
                    reply.writeInt(_result);
                    return true;
                }
            }
            return super.onTransact(code, data, reply, flags);
        }

        private static class Proxy implements com.example.test.app.ICompute {
            private android.os.IBinder mRemote;

            Proxy(android.os.IBinder remote) {
                mRemote = remote;
            }

            @Override
            public android.os.IBinder asBinder() {
                return mRemote;
            }

            public java.lang.String getInterfaceDescriptor() {
                return DESCRIPTOR;
            }

            /**
             * Demonstrates some basic types that you can use as parameters
             * and return values in AIDL.
             */
            @Override
            public int add(int a, int b) throws android.os.RemoteException {
                android.os.Parcel _data = android.os.Parcel.obtain();
                android.os.Parcel _reply = android.os.Parcel.obtain();
                int _result;
                try {
                    _data.writeInterfaceToken(DESCRIPTOR);
                    _data.writeInt(a);
                    _data.writeInt(b);
                    mRemote.transact(Stub.TRANSACTION_add, _data, _reply, 0);
                    _reply.readException();
                    _result = _reply.readInt();
                } finally {
                    _reply.recycle();
                    _data.recycle();
                }
                return _result;
            }
        }

        static final int TRANSACTION_add = (android.os.IBinder.FIRST_CALL_TRANSACTION + 0);
    }

    /**
     * Demonstrates some basic types that you can use as parameters
     * and return values in AIDL.
     */
    public int add(int a, int b) throws android.os.RemoteException;
}

系統幫我們生成了這個文件之後，我們只需要繼承ICompute.Stub這個抽象類，實現它的方法，然後在Service 的onBind方法裏面返回就實現了AIDL。這個Stub類非常重要，具體看看它做了什麼。

Stub類繼承自Binder，意味着這個Stub其實自己是一個Binder本地對象，然後實現了ICompute接口，ICompute本身是一個IInterface，因此他攜帶某種客戶端需要的能力（這裏是方法add)。此類有一個內部類Proxy，也就是Binder代理對象；

然後看看asInterface方法，我們在bind一個Service之後，在onServiceConnecttion的回調裏面，就是通過這個方法拿到一個遠程的service的，這個方法做了什麼呢？

/**
 * Cast an IBinder object into an com.example.test.app.ICompute interface,
 * generating a proxy if needed.
 */
public static com.example.test.app.ICompute asInterface(android.os.IBinder obj) {
    if ((obj == null)) {
        return null;
    }
    android.os.IInterface iin = obj.queryLocalInterface(DESCRIPTOR);
    if (((iin != null) && (iin instanceof com.example.test.app.ICompute))) {
        return ((com.example.test.app.ICompute) iin);
    }
    return new com.example.test.app.ICompute.Stub.Proxy(obj);
}

首先看函數的參數IBinder類型的obj，這個對象是驅動給我們的，如果是Binder本地對象，那麼它就是Binder類型，如果是Binder代理對象，那就是BinderProxy類型；然後，正如上面自動生成的文檔所說，它會試着查找Binder本地對象，如果找到，說明Client和Server都在同一個進程，這個參數直接就是本地對象，直接強制類型轉換然後返回，如果找不到，說明是遠程對象（處於另外一個進程）那麼就需要創建一個Binde代理對象，讓這個Binder代理實現對於遠程對象的訪問。一般來說，如果是與一個遠程Service對象進行通信，那麼這裏返回的一定是一個Binder代理對象，這個IBinder參數的實際上是BinderProxy;

再看看我們對於aidl的add 方法的實現；在Stub類裏面，add是一個抽象方法，我們需要繼承這個類並實現它；如果Client和Server在同一個進程，那麼直接就是調用這個方法；那麼，如果是遠程調用，這中間發生了什麼呢？Client是如何調用到Server的方法的？

我們知道，對於遠程方法的調用，是通過Binder代理完成的，在這個例子裏面就是Proxy類；Proxy對於add方法的實現如下：

Override
public int add(int a, int b) throws android.os.RemoteException {
    android.os.Parcel _data = android.os.Parcel.obtain();
    android.os.Parcel _reply = android.os.Parcel.obtain();
    int _result;
    try {
        _data.writeInterfaceToken(DESCRIPTOR);
        _data.writeInt(a);
        _data.writeInt(b);
        mRemote.transact(Stub.TRANSACTION_add, _data, _reply, 0);
        _reply.readException();
        _result = _reply.readInt();
    } finally {
        _reply.recycle();
        _data.recycle();
    }
    return _result;
}

它首先用Parcel把數據序列化了，然後調用了transact方法；這個transact到底做了什麼呢？這個Proxy類在asInterface方法裏面被創建，前面提到過，如果是Binder代理那麼說明驅動返回的IBinder實際是BinderProxy, 因此我們的Proxy類裏面的mRemote實際類型應該是BinderProxy；我們看看BinderProxy的transact方法：(Binder.java的內部類)

public native boolean transact(int code, Parcel data, Parcel reply,
            int flags) throws RemoteException;

這是一個本地方法；它的實現在native層，具體來說在frameworks/base/core/jni/android_util_Binder.cpp文件，裏面進行了一系列的函數調用，調用鏈實在太長這裏就不給出了；要知道的是它最終調用到了talkWithDriver函數；看這個函數的名字就知道，通信過程要交給驅動完成了；這個函數最後通過ioctl系統調用，Client進程陷入內核態，Client調用add方法的線程掛起等待返回；驅動完成一系列的操作之後喚醒Server進程，調用了Server進程本地對象的onTransact函數（實際上由Server端線程池完成）。我們再看Binder本地對象的onTransact方法（這裏就是Stub類裏面的此方法）：

@Override
public boolean onTransact(int code, android.os.Parcel data, android.os.Parcel reply, int flags) throws android.os.RemoteException {
    switch (code) {
        case INTERFACE_TRANSACTION: {
            reply.writeString(DESCRIPTOR);
            return true;
        }
        case TRANSACTION_add: {
            data.enforceInterface(DESCRIPTOR);
            int _arg0;
            _arg0 = data.readInt();
            int _arg1;
            _arg1 = data.readInt();
            int _result = this.add(_arg0, _arg1);
            reply.writeNoException();
            reply.writeInt(_result);
            return true;
        }
    }
    return super.onTransact(code, data, reply, flags);
}

在Server進程裏面，onTransact根據調用號（每個AIDL函數都有一個編號，在跨進程的時候，不會傳遞函數，而是傳遞編號指明調用哪個函數）調用相關函數；在這個例子裏面，調用了Binder本地對象的add方法；這個方法將結果返回給驅動，驅動喚醒掛起的Client進程裏面的線程並將結果返回。於是一次跨進程調用就完成了。

至此，你應該對AIDL這種通信方式裏面的各個類以及各個角色有了一定的瞭解；它總是那麼一種固定的模式：一個需要跨進程傳遞的對象一定繼承自IBinder，如果是Binder本地對象，那麼一定繼承Binder實現IInterface，如果是代理對象，那麼就實現了IInterface並持有了IBinder引用；

Proxy與Stub不一樣，雖然他們都既是Binder又是IInterface，不同的是Stub採用的是繼承（is 關係），Proxy採用的是組合（has 關係）。他們均實現了所有的IInterface函數，不同的是，Stub又使用策略模式調用的是虛函數（待子類實現），而Proxy則使用組合模式。爲什麼Stub採用繼承而Proxy採用組合？事實上，Stub本身is一個IBinder（Binder），它本身就是一個能跨越進程邊界傳輸的對象，所以它得繼承IBinder實現transact這個函數從而得到跨越進程的能力（這個能力由驅動賦予）。Proxy類使用組合，是因爲他不關心自己是什麼，它也不需要跨越進程傳輸，它只需要擁有這個能力即可，要擁有這個能力，只需要保留一個對IBinder的引用。如果把這個過程做一個類比，在封建社會，Stub好比皇帝，可以號令天下，他生而具有這個權利（不要說宣揚封建迷信。。）如果一個人也想號令天下，可以，“挾天子以令諸侯”。爲什麼不自己去當皇帝，其一，一般情況沒必要，當了皇帝其實限制也蠻多的是不是？我現在既能掌管天下，又能不受約束（Java單繼承）；其二，名不正言不順啊，我本來特麼就不是（Binder），你非要我是說不過去，搞不好還會造反。最後呢，如果想當皇帝也可以，那就是asBinder了。在Stub類裏面，asBinder返回this，在Proxy裏面返回的是持有的組合類IBinder的引用。

再去翻閱系統的ActivityManagerServer的源碼，就知道哪一個類是什麼角色了：IActivityManager是一個IInterface，它代表遠程Service具有什麼能力，ActivityManagerNative指的是Binder本地對象（類似AIDL工具生成的Stub類），這個類是抽象類，它的實現是ActivityManagerService；因此對於AMS的最終操作都會進入ActivityManagerService這個真正實現；同時如果仔細觀察，ActivityManagerNative.java裏面有一個非公開類ActivityManagerProxy, 它代表的就是Binder代理對象；是不是跟AIDL模型一模一樣呢？那麼ActivityManager是什麼？他不過是一個管理類而已，可以看到真正的操作都是轉發給ActivityManagerNative進而交給他的實現ActivityManagerService 完成的。

OK，本文就講到這裏了，要深入理解Binder，需要自己下功夫；那些native層以及驅動裏面的調用過程，用文章寫出來根本沒有意義，需要自己去跟蹤；接下來你可以：

看Android文檔，Parcel, IBinder, Binder等涉及到跨進程通信的類；
不依賴AIDL工具，手寫遠程Service完成跨進程通信
看《Binder設計與實現》
看老羅的博客或者書（書結構更清晰）
再看《Binder設計與實現》
學習Linux系統相關知識；自己看源碼。

Binder學習指南（轉）

背景知識

進程隔離

用戶空間/內核空間

系統調用/內核態/用戶態

內核模塊/驅動

爲什麼使用Binder？

Binder通信模型

Binder機制跨進程原理

Binder到底是什麼？

驅動裏面的Binder

深入理解Java層的Binder

AIDL過程分析

Android全面檢測設備是否模擬器

安卓設計模式の裝飾者模式

安卓設計模式の模板方法模式

安卓設計模式の外觀模式

安卓設計模式のAdapter模式

Mac下配置sublime實現LaTeX

https://yachay.unat.edu.pe/blog/index.php?comment_area=format_blog&comment_component=blog&comment_co

linux以太網驅動總結