Binder到底是什么？
- 中文即 粘合剂，意思为粘合了两个不同的进程
- 网上有很多对Binder的定义，但都说不清楚：Binder是跨进程通信方式、它实现了IBinder接口，是连接 ServiceManager的桥梁blabla，估计大家都看晕了，没法很好的理解
- 我认为：对于Binder的定义，在不同场景下其定义不同
知识储备
在讲解Binder前，我们先了解一些Linux的基础知识
进程空间划分
- 一个进程空间分为 用户空间 & 内核空间（Kernel），即把进程内 用户 & 内核 隔离开来。
- 进程间，用户空间的数据不可共享，所以用户空间 = 不可共享空间
- 进程间，内核空间的数据可共享，所以内核空间 = 可共享空间
所有进程共用1个内核空间
-
进程内 用户空间 & 内核空间 进行交互 需通过 系统调用，主要通过函数：
copy_from_user（）：将用户空间的数据拷贝到内核空间 copy_to_user（）：将内核空间的数据拷贝到用户空间
进程隔离 & 跨进程通信（ IPC ）
进程隔离
为了保证 安全性 & 独立性，一个进程 不能直接操作或者访问另一个进程，即Android的进程是相互独立、隔离的
简单的说就是操作系统中，进程与进程间内存是不共享的。两个进程就像两个平行的世界，A 进程没法直接访问 B 进程的数据，这就是进程隔离的通俗解释。A 进程和 B 进程之间要进行数据交互就得采用特殊的通信机制：进程间通信（IPC）。
-
跨进程通信（ IPC ）
即进程间需进行数据交互、通信 -
跨进程通信的基本原理
a. 而Binder的作用则是：连接 两个进程，实现了mmap()系统调用，主要负责 创建数据接收的缓存空间 & 管理数据接收缓存
b. 注：传统的跨进程通信需拷贝数据2次，但Binder机制只需1次，主要是使用到了内存映射，具体下面会详细说明
Linux 下的传统 IPC 通信原理
通常的做法是消息发送方将要发送的数据存放在内存缓存区中，通过系统调用进入内核态。然后内核程序在内核空间分配内存，开辟一块内核缓存区，调用 copyfromuser() 函数将数据从用户空间的内存缓存区拷贝到内核空间的内核缓存区中。同样的，接收方进程在接收数据时在自己的用户空间开辟一块内存缓存区，然后内核程序调用 copytouser() 函数将数据从内核缓存区拷贝到接收进程的内存缓存区。这样数据发送方进程和数据接收方进程就完成了一次数据传输，我们称完成了一次进程间通信。
这种传统的 IPC 通信方式有两个问题：
性能低下，一次数据传递需要经历：内存缓存区 --> 内核缓存区 --> 内存缓存区，需要 2 次数据拷贝；接收数据的缓存区由数据接收进程提供，但是接收进程并不知道需要多大的空间来存放将要传递过来的数据，因此只能开辟尽可能大的内存空间或者先调用 API 接收消息头来获取消息体的大小，这两种做法不是浪费空间就是浪费时间。
内存映射
https://www.jianshu.com/p/719fc4758813
Binder 跨进程通信机制 模型
模型原理图
Binder 跨进程通信机制 模型 基于 Client - Server 模式
模型组成角色说明
模型原理步骤说明
额外说明
说明1：Client进程、Server进程 & Service Manager 进程之间的交互 都必须通过Binder驱动（使用 open 和 ioctl文件操作函数），而非直接交互
原因：
Client进程、Server进程 & Service Manager进程属于进程空间的用户空间，不可进行进程间交互
Binder驱动 属于 进程空间的 内核空间，可进行进程间 & 进程内交互
所以，原理图可表示为以下：
虚线表示并非直接交互
说明2： Binder驱动 & Service Manager进程 属于 Android基础架构（即系统已经实现好了）；而Client 进程 和 Server 进程 属于Android应用层（需要开发者自己实现）
所以，在进行跨进程通信时，开发者只需自定义Client & Server 进程 并 显式使用上述3个步骤，最终借助 Android的基本架构功能就可完成进程间通信
说明3：Binder请求的线程管理
- Server进程会创建很多线程来处理Binder请求
- Binder模型的线程管理 采用Binder驱动的线程池，并由Binder驱动自身进行管理 而不是由Server进程来管理的
- 一个进程的Binder线程数默认最大是16，超过的请求会被阻塞等待空闲的Binder线程。
- 所以，在进程间通信时处理并发问题时，如使用ContentProvider时，它的CRUD（创建、检索、更新和删除）方法只能同时有16个线程同时工作
- 至此，我相信大家对Binder 跨进程通信机制 模型 已经有了一个非常清晰的定性认识
- 下面，我将通过一个实例，分析Binder跨进程通信机制 模型在 Android中的具体代码实现方式
Client/Server/ServiceManager/驱动
前面我们介绍过，Binder 是基于 C/S 架构的。由一系列的组件组成，包括 Client、Server、ServiceManager、Binder 驱动。其中 Client、Server、Service Manager 运行在用户空间，Binder 驱动运行在内核空间。其中 Service Manager 和 Binder 驱动由系统提供，而 Client、Server 由应用程序来实现。Client、Server 和 ServiceManager 均是通过系统调用 open、mmap 和 ioctl 来访问设备文件 /dev/binder，从而实现与 Binder 驱动的交互来间接的实现跨进程通信。
Client、Server、ServiceManager、Binder 驱动这几个组件在通信过程中扮演的角色就如同互联网中服务器（Server）、客户端（Client）、DNS域名服务器（ServiceManager）以及路由器（Binder 驱动）之前的关系。
通常我们访问一个网页的步骤是这样的：首先在浏览器输入一个地址，如 http://www.google.com 然后按下回车键。但是并没有办法通过域名地址直接找到我们要访问的服务器，因此需要首先访问 DNS 域名服务器，域名服务器中保存了 http://www.google.com 对应的 ip 地址 10.249.23.13，然后通过这个 ip 地址才能放到到 http://www.google.com 对应的服务器。
Binder 通信过程
- 首先，一个进程使用 BINDERSETCONTEXT_MGR 命令通过 Binder 驱动将自己注册成为 ServiceManager；
- Server 通过驱动向 ServiceManager 中注册 Binder（Server 中的 Binder 实体），表明可以对外提供服务。驱动为这个 Binder 创建位于内核中的实体节点以及 ServiceManager 对实体的引用，将名字以及新建的引用打包传给 ServiceManager，ServiceManger 将其填入查找表。
- Client 通过名字，在 Binder 驱动的帮助下从 ServiceManager 中获取到对 Binder 实体的引用，通过这个引用就能实现和 Server 进程的通信。
我们看到整个通信过程都需要 Binder 驱动的接入。下图能更加直观的展现整个通信过程(为了进一步抽象通信过程以及呈现上的方便，下图我们忽略了 Binder 实体及其引用的概念)：
Binder 通信中的代理模式
我们已经解释清楚 Client、Server 借助 Binder 驱动完成跨进程通信的实现机制了，但是还有个问题会让我们困惑。A 进程想要 B 进程中某个对象（object）是如何实现的呢？毕竟它们分属不同的进程，A 进程 没法直接使用 B 进程中的 object。
前面我们介绍过跨进程通信的过程都有 Binder 驱动的参与，因此在数据流经 Binder 驱动的时候驱动会对数据做一层转换。当 A 进程想要获取 B 进程中的 object 时，驱动并不会真的把 object 返回给 A，而是返回了一个跟 object 看起来一模一样的代理对象 objectProxy，这个 objectProxy 具有和 object 一摸一样的方法，但是这些方法并没有 B 进程中 object 对象那些方法的能力，这些方法只需要把把请求参数交给驱动即可。对于 A 进程来说和直接调用 object 中的方法是一样的。
当 Binder 驱动接收到 A 进程的消息后，发现这是个 objectProxy 就去查询自己维护的表单，一查发现这是 B 进程 object 的代理对象。于是就会去通知 B 进程调用 object 的方法，并要求 B 进程把返回结果发给自己。当驱动拿到 B 进程的返回结果后就会转发给 A 进程，一次通信就完成了。
Binder 的完整定义
- 从进程间通信的角度看，Binder 是一种进程间通信的机制；
- 从 Server 进程的角度看，Binder 指的是 Server 中的 Binder 实体对象；
- 从 Client 进程的角度看，Binder 指的是对 Binder 代理对象，是 Binder 实体对象的一个远程代理
- 从传输过程的角度看，Binder 是一个可以跨进程传输的对象；Binder 驱动会对这个跨越进程边界的对象对一点点特殊处理，自动完成代理对象和本地对象之间的转换。
Binder-函数调用
- 服务端方法本身就运行在服务端的Binder 线程池中，故服务端的方法本身就可以进行大量的耗时操作
- 客户端在调用服务端函数的时候需要注意 在哪个线程
- 因为客户端的回调方法运行在客户端的Binder线程池中，即子线程，所以无法直接更新UI，但是onServiceConnected和onServiceDisconnected是运行在UI线程的。
- 客户端调用服务端的方法也是运行在Binder线程池中的，只是是运行在服务端的Binder线程池中，所以这里面的方法是非UI线程中。
- 由于Binder中的方法是在Binder线程池中，所以是可以执行耗时操作的，但是如果客户端是在UI线程中调用的这些方法，会导致客户端长时间收不到回调而卡死，出现ANR。同理，如果服务端如果在主线程中调用客户端的回调方法时，如果是客户端回调是耗时操作，服务端也会出现ANR。
Binder机制 在Android中的具体实现原理
上面的内容作为学习笔记
参考资料如下：
https://zhuanlan.zhihu.com/p/35519585
https://blog.csdn.net/carson_ho/article/details/73560642
https://www.jianshu.com/p/2cfa14d0d75b
网友评论