Binder通信流程图

 Java层Binder框架

 

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框架

 

IPCThreadState.cpp

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

Parcel.cpp和Parcel.java

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

android_os_Binder.cpp和Binder

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

 

BpBinder.cpp

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

 

 

 

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

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

 

 

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