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.

        */

        publicStub(){

            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 as Interface(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 as Binder(){

            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 as Binder(){

                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 as Interface(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系統相關知識；自己看源碼。