Android binder架构解析

Android系统中，多进程间的通信都是依赖于底层Binder IPC机制，Binder机制是一种RPC方案，因为binder的功能就是在本地“执行”其他进程的功能。例如：当进程A中的Activity与进程B中的Service通信时，就使用了binder机制。为了完成进程间的通信，binder使用AIDL来描述进程间的接口。

不仅于此，此外，整个Android系统架构中，采用了大量的binder机制。

1.1 binder通信机制

Android中的Binder通信采用C/S架构，从组件视角来说，包含Client、Server、Service Manager以及binder驱动，其中Service Manager用于管理系统中的各种服务。Binder整体通信架构如下图所示：

（1）注册服务（addService）：Server进程要先注册Service到Service Manager。该过程：Server是客户端，Service Manager是服务端；

（2）获取服务（getService）：Client进程使用某个Service前，须先向Service Manager中获取相应的Service。该过程：Client是客户端，Service Manager是服务端；

（3）使用服务：Client根据得到的Service信息建立与Service所在的Server进程通信的通路，然后就可以直接与Service交互。该过程：client是客户端，server是服务端。

1.2 binder架构

Android源码中，binder的核心库是在native层实现，但在Java层和native层都有接口供应用程序使用。Binder架构图如下：

(1) binder驱动层

Android因此添加了binder驱动，其设备节点为/dev/binder，主设备号为10，binder驱动程序在内核中的头文件和代码路径如下：

kernel/drivers/staging/binder.h

kernel/drivers/staging/binder.c

binder驱动层的主要作用是完成实际的binder数据传输。

(2) binder adapter层

主要是IPCThreadState.cpp和ProcessState.cpp，源码位于frameworks/native/libs/binder目录下，这两个类都采用了单例模式，主要负责和驱动直接交互。

a、ProcessState负责打开binder设备，进行一些初始化设置并做内存映射；

b、IPCThreadState负责直接和binder设备通信，使用ioctl读写binder驱动数据。

(3) Binder核心层

Binder核心层主要是IBinder及它的两个子类，即BBinder和BpBinder，分别代表了最基本的服务端及客户端。源码位于frameworks/native/libs/binder目录下。

binder service服务端实体类会继承BnInterface，而BnInterface会继承自BBinder，服务端可将BBinder对象注册到servicemananger进程。

客户端程序和驱动交互时只能得到远程对象的句柄handle，它可以调用调用ProcessState的getStrongProxyForHandle函数，利用句柄handle建立BpBinder对象，然后将它转为IBinder指针返回给调用者。这样客户端每次调用IBinder指针的transact方法，其实是执行BpBinder的transact方法。

(4) Binder框架层

a、Native Binder框架层包含以下类(frameworks/native/libs/binder)：IInterface，BnInterface，BpInterface，等。

b、Java框架层包含以下类(frameworks/base/core/java/android/os):

IBinder，Binder，IInterface，ServiceManagerNative，ServiceManager，BinderInternal，IServiceManager，ServiceManagerProxy

Java框架层的类的部分方法的实现在本地代码里(frameworks/base/core/jni)。

1.3 binder分层

Java(App) framework层的binder采用JNI技术来调用native(C/C++ framework)层的binder架构，从而为上层应用程序提供服务。

native层中，binder是C/S架构，分为Bn端(Server)和Bp端(Client)，而java层binder在命名与架构上与其非常相近，同样在也实现了一套IPC通信架构。需要注意的是Java(App) framework层的Binder是建立在Native层架构基础之上的，核心逻辑都是交予Native层方法来处理。

图中红色代表整个Java(App) framework层binder架构相关组件；Binder类代表Server端，BinderProxy类代表Client端；

图中蓝色代表Native层Binder架构相关组件；

Java(App) framework层的Service Manager类与Native层的功能并不完全对应，java层的Service Manager类的实现最终是通过BinderProxy传递给Native层来完成的。

1.4 Binder类分层

整个Binder从kernel至，native，JNI，Framework层所涉及的类如下：

来源： http://blog.csdn.net/tfygg/article/details/51626632