android深入浅出binder机制,Android Binder机制，跨进程机制深入理解精华总结-优快云博客

本文可能不适于初学者阅读。适于立志于弄懂此领域，并已经进行了相关文章或源码阅读，但未得清晰思路，想要融汇贯通的人，如看过该经典文章innost的Android深入浅出之Binder机制，却被大信息量和分析所淹没思路。~~

一业务接口IInterface 通信接口IBinder 二者要融合到一块并要能相互转化

IInterface 能力：

asBinder 转化为 Binder 实例 -----转到----> 子类 BnInterface/BpInterface onAsBinder { return this; } 二者是Binder

而IInterface 没有，跟Binder 没有关系

IBinder 的能力：

getInterfaceDescriptor 知道自己是什么样的接口借助子类转到IInterface的宏里的实现；

queryLocalInterface(传入的跟自己的比对) BBinder return this; BpBinder --> IBinder return null;

另： inerface_cast --> as_interafce --> queryLocalInterface == null ? .......

IBinder* BnInterface::onAsBinder()

{

return this;

}

inline IBinder* BpInterface::onAsBinder()

{

return remote();

}

BnInterface == Stub BpInterface == Stub.Proxy

asInterface 静态方法 static 的像java中的 stub IServiceManager.asInterface()

二继承关系

Server/Native端

RefBase

IInterface (asBinder -> onAsBinder) 业务接口

IServiceManager (static asInterface(Binder对象)) 业务接口

Bn ------ BBinder通信接口!

BnServiceManager (实现业务接口的业务方法) 此对象同java层 IXXXX.Stub

并不是 Bn接口， Bn只是为了C里多继承，共用一些逻辑而设立的

IServiceManager

BpInterface ----- BpRefBase

BpServiceManager 同 IXXXX.Stub.Proxy --- BpRefBase (IBinder* const mRemote)

C 是在 IXXX.h IXXX.cpp 里；而 java 是在 IXXX.java 里只不过不是 aidl 代码自动生成

简直有异曲同工之妙！！！！

三二者融合以及的能力(转化)实现

BnInterface 里的 query get 是 IBinder 里的方法可查：

template

class BnInterface : public INTERFACE, public BBinder

{

public:

virtual sp queryLocalInterface(const String16& _descriptor); // return this

virtual const String16& getInterfaceDescriptor() const; //调用父类 IServiceManager:getInterfaceDescriptor IMPLEMENT_META...

protected:

virtual IBinder* onAsBinder();

};

queryLocalInterface getInterfaceDescriptor 在BBinder 里返回的都是null 可以理解因为是跟业务相关的。

在BnInterface 里实现调用的是IServiceManager里的(即那段宏)

IBinder的接口借由IServicerManager 中META_INTERFACE宏实现

C的多重继承起了作用

IServicerManager ( META_INTERFACE macro: static discriptor, static asInterface, getInterfaceDiscriptor )

/|\

N (Bn)

queryLocalInterface 是BBinder(BnXxx实体对象)的接口，而 BpBinder返回null ；

interface_cast传入的是IBinder : 实际对象是BBinder 或 BpBinder

template

inline sp BnInterface::queryLocalInterface(

const String16& _descriptor)

{

if (_descriptor == INTERFACE::descriptor) return this;

return NULL;

}

IBinder :

sp IBinder::queryLocalInterface(const String16& /*descriptor*/)

{

return NULL;

}

IXxxxx接口借由 onAsBinder return this;

IServicerManager ( asBinder ---转到--- onAsBinder )

\|/

P (Bp)——— (实现onAsBinder return this 因为已经继承Binder了)

二者相互转化的能力清楚理解的关键

IInterface ----> asBinder +asInterafce(Binder) (实现也是借用了queryLocalInterface)

Binder --> getInterfaceDescriptor+queryLocalInterface(asInterface借用它)

业务接口能强转成通信接口；通信接口能知道自己是什么业务接口！！！！！！

由子类来让二者产生关系！！！

四 C Java中都有这么一套机制，二者的对应关系

另：BpBinder 相当于 java里的 BinderProxy对象

Stub.Proxy 里的 mRemote -----是---- BinderProxy android_util_Binder.cpp 里生成 javaObjectForIBinder 里的mObject 是Binder 应该就是BpBinder对象。对于 ServiceManager.java sServiceManager = ServiceManagerNative.asInterface(BinderInternal.getContextObject());

---- android_os_BinderInternal_getContextObject ()

------ sp b =ProcessState::self()->getContextObject(NULL);return javaObjectForIBinder(env, b); 跟C层获取方式是一样的！！！

BpServiceManager 里的

(BpRefBase) IBinder* const mRemote; --------- BpBinder由ProcessState::self()->getContextObject(NULL); 获得

真是完全对应的啊！！！！

BpBinder(mHandle) BinderProxy(mObject) 让一个handle或地址(是一个整数值) 装扮成 IBinder 对象

mHandler-->BpBinder-->BpServiceManager BpInterface 接口

BBinder ------ BpBinder

Binder --------- BinderProxy

IBinder/Binder 对象 Native Remote对比项

由 handle/地址 ---------> Binder.java BinderProxy------------------------> Stub(native)， Proxy 业务对象JAVA层

BBinder BpBinder -----------------------> BnXxxService BpXxxServiceC层

五流程调用

(1)Client端：

BpXxxService.业务接口() ---->BpBinder.transact() --> IPCThreadState::self() --> transact()

(writeTransactionData(写到mOut里) + waitForResponse(while 循环 talkWithDriver(ioctl)))

writeTransactionData(...., handle,.....) {

binder_transaction_data tr;

tr.target.ptr = 0; /* Don't pass uninitialized stack data to a remote process */

tr.target.handle = handle; //BpBinder里的handle

}

如果非要往下说，BpBinder 是怎么对应到 server/remote 端区分的，就是mHandle字段

(2)Servier端 MediaPlayerService

ProcessState::self()->startThreadPool(); ---> 创建线程 createThreadEtc ：_threadLoop

----> threadLoop : IPCThreadState::self()->joinThreadPool(mIsMain); mIsMain为true. (threadLoopreturn false _threadLoop只执行一次)

--------do { getAndExecuteCommand() } while()//自书己循环执行 Command

------------talkWithDriver + executeCommand //循环执行这个方法

talkWithDriver 跟ioctl打交道与 mIn 和 mOut 数据交换

把mOut parcel : 写出的数据 mIn parcel : 读取的数据赋给bwr ioctl 传入驱动中

mOut + mIn bwr binder 驱动

executeCommand

跟mIn mOut 打交道BBinder -> transact --> onTransact --> BnXxxxxx.onTransact ---> 最终实体对象.业务接口

(3)Servier端 ServiceManager

binder_become_context_manager(bs);

binder_loop(bs, svcmgr_handler);//处理BpServiceManager发过来的命令

for(;;) { res = ioctl(bs->fd, BINDER_WRITE_READ, &bwr); res = binder_parse(bs, 0, readbuf, bwr.read_consumed, func);}

也是循环

binder_loop ( for(;;) { } ) ----> binder_parse -- > svcmgr_handler ---> do_add_service 添加到链表 svclist