Binder到底是什么泊脐？
我們經常提到Binder，那么Binder到底是什么呢？
Binder的設計采用了面向對象的思想壶熏，在Binder通信模型的四個角色里面；他們的代表都是“Binder”浦译，這樣棒假，對于Binder通信的使用者而言，Server里面的Binder和Client里面的Binder沒有什么不同精盅，一個Binder對象就代表了所有帽哑，它不用關心實現(xiàn)的細節(jié)，甚至不用關心驅動以及SM的存在渤弛；這就是抽象祝拯。
通常意義下，Binder指的是一種通信機制；我們說AIDL使用Binder進行通信佳头，指的就是Binder這種IPC機制鹰贵。
對于Server進程來說，Binder指的是Binder本地對象
對于Client來說康嘉，Binder指的是Binder代理對象碉输，它只是Binder本地對象的一個遠程代理；對這個Binder代理對象的操作亭珍，會通過驅動最終轉發(fā)到Binder本地對象上去完成敷钾；對于一個擁有Binder對象的使用者而言，它無須關心這是一個Binder代理對象還是Binder本地對象肄梨；對于代理對象的操作和對本地對象的操作對它來說沒有區(qū)別阻荒。
對于傳輸過程而言琉用，Binder是可以進行跨進程傳遞的對象邢享；Binder驅動會對具有跨進程傳遞能力的對象做特殊處理：自動完成代理對象和本地對象的轉換。
面向對象思想的引入將進程間通信轉化為通過對某個Binder對象的引用調用該對象的方法勋锤，而其獨特之處在于Binder對象是一個可以跨進程引用的對象粱侣，它的實體（本地對象）位于一個進程中羊壹，而它的引用（代理對象）卻遍布于系統(tǒng)的各個進程之中。最誘人的是齐婴，這個引用和java里引用一樣既可以是強類型油猫，也可以是弱類型，而且可以從一個進程傳給其它進程柠偶，讓大家都能訪問同一Server情妖，就象將一個對象或引用賦值給另一個引用一樣。Binder模糊了進程邊界嚣州，淡化了進程間通信過程鲫售，整個系統(tǒng)仿佛運行于同一個面向對象的程序之中。形形色色的Binder對象以及星羅棋布的引用仿佛粘接各個應用程序的膠水该肴，這也是Binder在英文里的原意情竹。
驅動里面的Binder
我們現(xiàn)在知道，Server進程里面的Binder對象指的是Binder本地對象匀哄，Client里面的對象值得是Binder代理對象秦效；在Binder對象進行跨進程傳遞的時候，Binder驅動會自動完成這兩種類型的轉換涎嚼；因此Binder驅動必然保存了每一個跨越進程的Binder對象的相關信息阱州；在驅動中，Binder本地對象的代表是一個叫做binder_node的數據結構法梯，Binder代理對象是用binder_ref代表的苔货；有的地方把Binder本地對象直接稱作Binder實體犀概，把Binder代理對象直接稱作Binder引用（句柄），其實指的是Binder對象在驅動里面的表現(xiàn)形式夜惭；讀者明白意思即可姻灶。
OK，現(xiàn)在大致了解Binder的通信模型诈茧，也了解了Binder這個對象在通信過程中各個組件里面到底表示的是什么产喉。
深入理解Java層的Binder
IBinder/IInterface/Binder/BinderProxy/Stub
我們使用AIDL接口的時候，經常會接觸到這些類敢会，那么這每個類代表的是什么呢曾沈？
IBinder是一個接口，它代表了一種跨進程傳輸的能力鸥昏；只要實現(xiàn)了這個接口塞俱，就能將這個對象進行跨進程傳遞；這是驅動底層支持的吏垮；在跨進程數據流經驅動的時候敛腌，驅動會識別IBinder類型的數據，從而自動完成不同進程Binder本地對象以及Binder代理對象的轉換惫皱。
IBinder負責數據傳輸，那么client與server端的調用契約（這里不用接口避免混淆）呢尤莺？這里的IInterface代表的就是遠程server對象具有什么能力旅敷。具體來說，就是aidl里面的接口颤霎。
Java層的Binder類媳谁，代表的其實就是Binder本地對象。BinderProxy類是Binder類的一個內部類友酱，它代表遠程進程的Binder對象的本地代理晴音；這兩個類都繼承自IBinder, 因而都具有跨進程傳輸的能力；實際上缔杉，在跨越進程的時候锤躁，Binder驅動會自動完成這兩個對象的轉換。
在使用AIDL的時候或详，編譯工具會給我們生成一個Stub的靜態(tài)內部類系羞；這個類繼承了Binder, 說明它是一個Binder本地對象，它實現(xiàn)了IInterface接口霸琴，表明它具有遠程Server承諾給Client的能力椒振；Stub是一個抽象類，具體的IInterface的相關實現(xiàn)需要我們手動完成梧乘，這里使用了策略模式澎迎。
AIDL過程分析
現(xiàn)在我們通過一個AIDL的使用，分析一下整個通信過程中，各個角色到底做了什么夹供，AIDL到底是如何完成通信的灵份。（如果你連AIDL都不熟悉，請先查閱官方文檔）
首先定一個一個簡單的aidl接口：
// ICompute.aidl
package com.example.test.app;
interface ICompute{
int add(int a , int b);
}
然后用編譯工具編譯之后罩引，可以得到對應的ICompute.java類各吨，看看系統(tǒng)給我們生成的代碼：
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;
}
系統(tǒng)幫我們生成了這個文件之后，我們只需要繼承ICompute.Stub這個抽象類袁铐，實現(xiàn)它的方法揭蜒，然后在Service 的onBind方法里面返回就實現(xiàn)了AIDL。這個Stub類非常重要剔桨，具體看看它做了什么屉更。
Stub類繼承自Binder，意味著這個Stub其實自己是一個Binder本地對象洒缀，然后實現(xiàn)了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都在同一個進程嘲更，這個參數直接就是本地對象筐钟，直接強制類型轉換然后返回，如果找不到赋朦，說明是遠程對象（處于另外一個進程）那么就需要創(chuàng)建一個Binde代理對象篓冲，讓這個Binder代理實現(xiàn)對于遠程對象的訪問李破。一般來說，如果是與一個遠程Service對象進行通信壹将，那么這里返回的一定是一個Binder代理對象嗤攻，這個IBinder參數的實際上是BinderProxy;
再看看我們對于aidl的add 方法的實現(xiàn)；在Stub類里面诽俯，add是一個抽象方法妇菱，我們需要繼承這個類并實現(xiàn)它；如果Client和Server在同一個進程暴区，那么直接就是調用這個方法闯团；那么，如果是遠程調用仙粱，這中間發(fā)生了什么呢房交？Client是如何調用到Server的方法的？
我們知道伐割，對于遠程方法的調用候味，是通過Binder代理完成的，在這個例子里面就是Proxy類隔心；Proxy對于add方法的實現(xiàn)如下：
@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方法里面被創(chuàng)建川抡，前面提到過，如果是Binder代理那么說明驅動返回的IBinder實際是BinderProxy, 因此我們的Proxy類里面的mRemote實際類型應該是BinderProxy须尚；我們看看BinderProxy的transact方法：(Binder.java的內部類)
public native boolean transact (int code, Parcel data, Parcel reply, int flags ) throws RemoteException ;
這是一個本地方法；它的實現(xiàn)在native層侍咱，具體來說在frameworks/base/core/jni/android_util_Binder.cpp文件耐床，里面進行了一系列的函數調用，調用鏈實在太長這里就不給出了楔脯；要知道的是它最終調用到了talkWithDriver函數撩轰；看這個函數的名字就知道，通信過程要交給驅動完成了昧廷；這個函數最后通過ioctl系統(tǒng)調用堪嫂，Client進程陷入內核態(tài)，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實現(xiàn)IInterface漱凝，如果是代理對象，那么就實現(xiàn)了IInterface并持有了IBinder引用诸迟；
Proxy與Stub不一樣茸炒，雖然他們都既是Binder又是IInterface，不同的是Stub采用的是繼承（is 關系）阵苇，Proxy采用的是組合（has 關系）壁公。他們均實現(xiàn)了所有的IInterface函數，不同的是绅项，Stub又使用策略模式調用的是虛函數（待子類實現(xiàn)）紊册，而Proxy則使用組合模式。為什么Stub采用繼承而Proxy采用組合快耿？事實上囊陡，Stub本身is一個IBinder（Binder），它本身就是一個能跨越進程邊界傳輸的對象掀亥，所以它得繼承IBinder實現(xiàn)transact這個函數從而得到跨越進程的能力（這個能力由驅動賦予）撞反。Proxy類使用組合，是因為他不關心自己是什么搪花，它也不需要跨越進程傳輸遏片，它只需要擁有這個能力即可，要擁有這個能力撮竿，只需要保留一個對IBinder的引用吮便。如果把這個過程做一個類比，在封建社會幢踏，Stub好比皇帝髓需，可以號令天下，他生而具有這個權利（不要說宣揚封建迷信房蝉。授账。）如果一個人也想號令天下枯跑，可以，“挾天子以令諸侯”白热。為什么不自己去當皇帝敛助，其一，一般情況沒必要屋确，當了皇帝其實限制也蠻多的是不是纳击？我現(xiàn)在既能掌管天下，又能不受約束（Java單繼承）攻臀；其二焕数，名不正言不順啊，我本來特么就不是（Binder）刨啸，你非要我是說不過去堡赔，搞不好還會造反。最后呢设联，如果想當皇帝也可以善已，那就是asBinder了。在Stub類里面离例，asBinder返回this换团，在Proxy里面返回的是持有的組合類IBinder的引用。
再去翻閱系統(tǒng)的ActivityManagerServer的源碼宫蛆，就知道哪一個類是什么角色了：IActivityManager是一個IInterface艘包，它代表遠程Service具有什么能力，ActivityManagerNative指的是Binder本地對象（類似AIDL工具生成的Stub類）耀盗，這個類是抽象類想虎，它的實現(xiàn)是ActivityManagerService；因此對于AMS的最終操作都會進入ActivityManagerService這個真正實現(xiàn)叛拷；同時如果仔細觀察磷醋，ActivityManagerNative.java里面有一個非公開類ActivityManagerProxy, 它代表的就是Binder代理對象；是不是跟AIDL模型一模一樣呢胡诗？那么ActivityManager是什么？他不過是一個管理類而已淌友，可以看到真正的操作都是轉發(fā)給ActivityManagerNative進而交給他的實現(xiàn)ActivityManagerService 完成的煌恢。
OK，本文就講到這里了震庭，要深入理解Binder瑰抵，需要自己下功夫；那些native層以及驅動里面的調用過程器联，用文章寫出來根本沒有意義二汛，需要自己去跟蹤婿崭；接下來你可以：
看Android文檔，Parcel, IBinder, Binder等涉及到跨進程通信的類肴颊；
不依賴AIDL工具氓栈，手寫遠程Service完成跨進程通信
看老羅的博客或者書（書結構更清晰）
學習Linux系統(tǒng)相關知識；自己看源碼婿着。
