Binder通信流程图

 Java层Binder框架

Binder通信流程图_第1张图片

 Binder通信流程图_第2张图片

Binder通信流程图_第3张图片

Binder通信流程图_第4张图片

BpBinder和JavaBBinder是一对的 ,是通信架构的一部分,应该算是身份证的持有者。

通信时,是通过IPCThreadState和binder驱动交互。例如在客户端发送请求时,是BpBinder把要通信的BBinder的handle告诉binder线程的IPCThreadState,然后IPCThreadState就把handle告诉binder驱动,然后把请求数据包交给binder驱动,binder驱动放到binder驱动内存中分配给服务端进程所属的buffer。

接着binder驱动唤醒一个binder线程,最后属于该binder线程的IPCThreadState根据handle,找到对应的BBinder,接着就可以调用业务层逻辑了。

Java构架和native构架基本上是一一对应的(服务端的业务逻辑不算),因为最终是要与binder驱动通信的,包括数据包parcel等,parcel是要给BpBinder使用的,BpBinder只接受native类型的Parcel指针,那为什么BpBinder不直接接收jni类型的jObject,而那么麻烦将jObject的Java Parcel转为native类型的Parcel。因为不只是java应用程序使用binder通信,而一些native程序也使用binder通信,如media server进程。

 

native层Binder框架

Binder通信流程图_第5张图片

Binder通信流程图_第6张图片

 

IPCThreadState.cpp

直接和Binder驱动通信的一个类,talkWithDriver()和ioctl(...)

Parcel.cpp和Parcel.java

Parcel只是数据的封装,和通信无关。

android_os_Binder.cpp和Binder

Binder和通信相关,但是只是一个中介,主要是作为服务的业务逻辑和通信逻辑的桥梁

 

BpBinder.cpp

Binder通信流程图_第7张图片

可以看到和binder驱动通信的任务是完全交给IPCThreadState

 

 

 

那么服务端的native层的BBinder是如何处理的:

Binder通信流程图_第8张图片

当有请求的时候,binder驱动将会唤醒服务所在进程的binder线程,然后调用IPCThreadState#executeCommand(cmd),其中参数为BR_TRANSACTION。接着binder线程回去binder驱动读取请求参数,读到tr中。然后再调用BBinder#transact(...),这样就会逐步去到服务端的业务层,这个业务层的实现可以使用native语言,也可以使用java。所以Java层的binder框架不是必须的。

 

 

参考自深入理解AndroidⅠ的第六章深入理解Binder和深入理解AndroidⅡ的第二章深入理解Android Java Binder和Message Queue

 

你可能感兴趣的:(android系统相关)