以下文章参考红茶一杯话Binder(初始篇)，并摘录相应的原文
参考：Binder总结篇1-Binder原理

什么是Binder

简单地说，Binder是Android平台上的一种跨进程交互技术。该技术最早并不是由Google公司提出的，它的前身是Be Inc公司开发的OpenBinder，而且在Palm中也有应用。后来OpenBinder的作者Dianne Hackborn加入了Google公司，并负责Android平台的开发工作，所以把这项技术也带进了Android。
我们知道，在Android的应用层次上，基本上已经没有过去的进程概念了。然而在实现层次，它毕竟还是要建构在一个个进程之上的。实际上，在Android内部，那些支撑应用的组件往往会身处于不同的进程，那么应用的底层必然会牵涉大量的跨进程通信。为了保证通信的高效性，Android提供了Binder机制。

传统IPC

1、共享内存
2、消息管道
3、Socket
4、信号量

Binder相对于传统IPC的优势

1、Binder是只需要一次数据copy，仅低于共享内存。
2、他基于C/S架构，职责分离又相互独立，稳定性更好。
3、在安全性方面，传统的IPC接收方无法获取对方可靠的进程PId，从而无法鉴别对方身份。但是在Android中，他会为每一个安装好的App分配一个自己的UID，从而做到可以鉴别身份。
传统IPC(除共享内存外)的数据传输方式：

image.png

Binder的数据传输方式：

image.png

Binder借助内存映射，在内核空间和接收方的用户空间的数据缓存区做了一层内存映射。也就是说，在发送方将数据拷贝到内存空间的时候，内核空间的这部分地址同时也会被映射到接收方的内存缓存中，这样子，就少了一次从内和空间拷贝到用户空间。
在Binder中，有四个概念，Binder驱动，ServerManager，Client以及Server，这四个部分组成了BinderC/S架构。

Binder驱动

Binder驱动是一种虚拟的字符设备，注册在/dev/bindr中，其中定义了一套Binder通信协议，负责建立进程间Binder通信，提供了数据包在进程之间传递的底层支持。
他的角色类似路由，他是提供进程间通信的底层支持。负责将Client端的请求转发到Server，并将Server的数据返回给Client。

ServerManager

他的作用类似DNS服务器，负责将Client请求的Server的Binder描述转化为具体的Server地址，以便Binder驱动将Client的请求转达到Server。当Server需要提供服务的时候，他必须先向ServerManager注册，这样子，ServerManager中，就存有一份类似key-value的数据，保存了一份Server的Binder字符名称和Binder引用的映射以便Client可以找到。

Client

Client的作用是发起请求，通过Binder向ServerManager发起请求获取Server的具体地址，然后交由Binder驱动转发。

Server

Server假如需要对外提供服务，他就需要先将自己注册到ServerManager中，以便被解析出来。Server在响应请求之后，就将数据通过Binder驱动再次将数据传递会Client。

ServerManager的创建

1、在Android系统启动之后，会创建一个名词为servermanager的进程，可以查看ZygoteInit文件，在里面的main方法中，调用Zygote的forkSystemServer产生。它通过一个约定的命令BINDERSERVER_MGR向Binder驱动注册，申请成为ServerManager。Binder驱动会自动为ServerManager创建一个Binder实体
2、这个Binder实体的引用在所有的Client中都是0，也就是说各个Client通过0这个引用就可以与ServerManager进行通信

Binder的代理机制

image.png

Binder机制具有两层含义：
1） 是一种跨进程通信手段（IPC，Inter-Process Communication）。
2） 是一种远程过程调用手段（RPC，Remote Procedure Call）。

从实现的角度来说，Binder核心被实现成一个Linux驱动程序，并运行于内核态。这样它才能具有强大的跨进程访问能力。

简述Binder的跨进程机制

为了理解Binder，我们可以先画一张最简单的跨进程通信示意图：

image.png

这个很容易理解，不需赘言。到了Android平台上，IPC机制就变成了Binder机制，情况类似，只不过为了便于说明问题，我们需要稍微调整一下示意图：

image.png

image

image

则表示“Binder响应方”，主要用于响应语义。需要说明的是，这种图形表示方法是我自己杜撰的，并没有正规的出处。我个人觉得这种图形非常简便，所以在分析Android架构时，会经常使用这种表示法。
在后文中，我们可以看到，Binder代理方大概对应于C++层次的BpBinder对象，而Binder响应方则对应于BBinder对象。这两个对象在后文会详细阐述，此处不必太细究。
然而，上图的Binder代理方主要只负责了“传递信息”的工作，并没有起到“远程过程调用”的作用，如果要支持远程过程调用，我们还必须提供“接口代理方”和“接口实现体”。这样，我们的示意图就需要再调整一下，如下：

image.png

从图中可以看到，A进程并不直接和BpBinder（Binder代理）打交道，而是通过调用BpInterface（接口代理）的成员函数来完成远程调用的。此时，BpBinder已经被聚合进BpInterface了，它在BpInterface内部完成了一切跨进程的机制。另一方面，与BpInterface相对的响应端实体就是BnInterface（接口实现）了。需要注意的是，BnInterface是继承于BBinder的，它并没有采用聚合的方式来包含一个BBinder对象，所以上图中B侧的BnInterface块和BBinder块的背景图案是相同的。

这样看来，对于远程调用的客户端而言，主要搞的就是两个东西，一个是“Binder代理”，一个是“接口代理”。而服务端主要搞的则是“接口实现体”。因为binder是一种跨进程通信机制，所以还需要一个专门的管理器来为通信两端牵线搭桥，这个管理器就是Service Manager Service。不过目前我们可以先放下Service Manager Service，以后再详细研究。

Java层次的Binder元素

Java层次中，与Binder相关的接口或类的继承关系如下：

image.png

在实际使用中，我们并不需要编写上图的XXXXNative、XXXXProxy，它们会由ADT根据我们编写的aidl脚本自动生成。用户只需继承XXXXNative编写一个具体的XXXXService即可，这个XXXXService就是远程通信的服务实体类，而XXXXProxy则是其对应的代理类。

关于Java层次的binder组件，我们就先说这么多，主要是先介绍一个大概。就研究跨进程通信而言，其实质内容基本上都在C++层次，Java层次只是一个壳而已。以后我会写专文来打通Java层次和C++层次，看看它们是如何通过JNI技术关联起来的。现在我们还是把注意力集中在C++层次吧。

C++层次的Binder元素

C++层次的继承关系图如下：

image.png

其中有以下几个很关键的类：

• BpBinder
• BpInterface
• BBinder
• BnInterface

它们扮演着很重要的角色。

BpBinder

作为代理端的核心，BpBinder最重要的职责就是实现跨进程传输的传输机制，至于具体传输的是什么语义，它并不关心。我们观察它的transact()函数的参数，可以看到所有的语义都被打包成Parcel了。其他的成员函数，我们先不深究，待我们储备了足够的基础知识后，再回过头研究它们不迟。

BpInterface

BpInterface使用了模板技术，而且因为它继承了BpRefBase，所以先天上就聚合了一个mRemote成员，这个成员记录的就是前面所说的BpBinder对象啦。以后，我们还需要继承BpInterface<>实现我们自己的代理类。
在实际的代码中，我们完全可以创建多个聚合同一BpBinder对象的代理对象，这些代理对象就本质而言，对应着同一个远端binder实体。在Android框架中，常常把指向同一binder实体的多个代理称为token，这样即便这些代理分别处于不同的进程中，它们也具有了某种内在联系。这个知识点需要大家关注。

BBinder

Binder远程通信的目标端实体必须继承于BBinder类，该类和BpBinder相对，主要关心的只是传输方面的东西，不太关心所传输的语义。

BnInterface

远程通信目标端的另一个重要类是BnInterface<>，它是与BpInterface<>相对应的模板类，比较关心传输的语义。一般情况下，服务端并不直接使用BnInterface<>，而是使用它的某个子类。为此，我们需要编写一个新的BnXXX子类，并重载它的onTransact()成员函数。
BnInterface<>继承于BBinder，但它并没有实现一个默认的onTransact()成员函数，所以在远程通信时，前文所说的BBinder::transact()调用的onTransact()应该就是BnInterface<>的某个子类的onTransact()成员函数。

ProcessState

前文我们已经提到过，在Android的上层架构中，已经大幅度地弱化了进程的概念。应用程序员能看到的主要是activity、service、content provider等概念，再也找不到以前熟悉的main()函数了。然而，底层程序（C++层次）毕竟还是得跑在一个个进程之上，现在我们就来看底层进程是如何运用Binder机制来完成跨进程通信的。

    在每个进程中，会有一个全局的ProcessState对象。这个很容易理解，ProcessState的字面意思不就是“进程状态”吗，当然应该是每个进程一个ProcessState。ProcessState的定义位于frameworks/native/include/binder/ProcessState.h中。

我们知道，Binder内核被设计成一个驱动程序，所以ProcessState里专门搞了个mDriverFD域，来记录binder驱动对应的句柄值，以便随时和binder驱动通信。ProcessState对象采用了典型的单例模式，在一个应用进程中，只会有唯一的一个ProcessState对象，它将被进程中的多个线程共用，因此每个进程里的线程其实是共用所打开的那个驱动句柄（mDriverFD）的，示意图如下：

image.png

每个进程基本上都是这样的结构，组合起来的示意图就是：

image.png

总结

image.png