1. Binder是什么
在Android中Binder是跨进程通信方式。不过从不同角度来看，binder也可以有如下理解：
- 1，从进程间通信的角度看，Binder 是一种进程间通信的机制；
- 2，从 Server 进程的角度看，Binder 指的是 Server 中的 Binder 实体对象；
- 3，从 Client 进程的角度看，Binder 指的是对 Binder 代理对象，是 Binder 实体对象的一个远程代理
- 4，从传输过程的角度看，Binder 是一个可以跨进程传输的对象；传输过程中，Binder 驱动会对这个跨越进程的对象，自动完成代理对象和本地对象之间的转换。
2. Binder优势
Linux提供了管道、消息队列、共享内存和 Socket 等 IPC 机制。
-
管道/消息队列：信息复制两次，额外的CPU消耗；不合适频繁或信息量大的通信；
-
共享内存：无须复制，共享缓冲区直接附加到进程虚拟地址空间，速度快；但进程间的同步问题操作系统无法实现，必须各进程利用同步工具解决；
-
Socket：作为更通用的接口，传输效率低（涉及io读写），主要用于不通机器或跨网络的通信；
-
信号量：常作为一种锁机制，防止某进程正在访问共享资源时，其他进程也访问该资源。因此，主要作为进程间以及同一进程内不同线程之间的同步手段。
-
信号: 不适用于信息交换，更适用于进程中断控制，比如非法内存访问，杀死某个进程等；
2.1 性能：
Binder数据拷贝只需要一次，而管道、消息队列、Socket都需要2次，共享不需要内存拷贝；从性能角度看，Binder性能仅次于共享内存。
2.2 稳定性：
Binder是基于C/S架构的，Client端有什么需求，直接发送给Server端去完成，架构清晰，Server端与Client端相对独立，稳定性较好；
而共享内存实现方式复杂，没有客户与服务端之别，需要充分考虑到访问临界资源的并发同步问题，否则可能会出现死锁等问题；从这稳定性角度看，Binder架构优越于共享内存。
2.3 性能：
传统Linux IPC的接收方无法获得对方进程可靠的UID/PID，从而无法鉴别对方身份；（比如socket 只能由用户在数据包中填入 UID/PID））。
Android系统中对外只暴露Client端，Client端将任务发送给Server端，Server端会根据权限控制策略，判断UID/PID是否满足访问权限，目前权限控制很多时候是通过弹出权限询问对话框，让用户选择是否运行。
注意：Binder是为Android这类系统而生（主要从安全行考虑），并非Linux现有的IPC机制不好，只是根据不通的场景会选择不不同的IPC机制，例如：
1，Android OS中的Zygote进程的IPC采用的是Socket（套接字）机制；
2，Android中的Kill Process采用的signal（信号）机制；
3，而Binder更多则用在system_server进程与上层App层的IPC交互（主要从安全行考虑）。
3. Binder 通信原理
3.1 进程空间划分
进程间，用户空间的数据不可共享，所以用户空间 = 不可共享空间
进程间，内核空间的数据可共享，所以内核空间 = 可共享空间
所有进程共用1个内核空间
进程内 用户空间 & 内核空间 进行交互 需通过 系统调用，主要通过函数：
1，copy_from_user（）：将用户空间的数据拷贝到内核空间
2，copy_to_user（）：将内核空间的数据拷贝到用户空间
3.2 Binder驱动
3.3 内存映射
首先在内核虚拟地址空间，申请一块与用户虚拟内存相同大小的内存；然后再申请1个page大小的物理内存，再将同一块物理内存分别映射到内核虚拟地址空间和用户虚拟内存空间，从而实现了用户空间的Buffer和内核空间的Buffer同步操作的功能。
3.4 Binder通信原理
1，Binder驱动在内核空间创建一个数据接收缓存区；
2，实现地址映射关系，将内核缓存区和接收进程地址空间映射到Binde创建一个数据接收缓存区；
3，发送方进程通过系统调用 copy_from_user() 将数据 copy 到内核缓存区，由于内核缓存区和接收进程的地址空间存在内存映射，因此也就相当于把数据发送到了接收进程的用户空间，这样便完成了一次进程间的通信。
问题：为啥不能直接将内核缓存区映射到接收进程地址空间，而需要再开辟一个数据接收缓存区？？？
我的理解是：binder开辟的数据接受缓存区就是就是开辟一块物理内存，然后将内核缓存区和接收进程地址空间映射。
❓ 内核是不是会把 Client 的数据直接拷贝到 Server 和内核共享的那块物理内存（binder buffer）？
✅ 简明回答：
是的，内核会将客户端提交的数据通过
copy_from_user()拷贝进内核控制的 binder buffer，而这个 binder buffer 最终映射给了服务端进程使用。
🔁 为什么不能用 mmap 的区域让 Client 自己写？
以下是几个核心原因：
☑️ 1. 安全性：
如果允许客户端直接写内核数据区域（比如 mmap 后共享可写），那就是 “不受信任用户进程可以写内核空间” —— 完全违反内核安全模型。
🔥 这会导致严重安全漏洞（任意代码注入、劫持系统服务、提权等）
☑️ 2. 控制权在内核：
只有 Binder 驱动有权管理：
- 哪块 buffer 是谁用的；
- 多大空间分配给每个事务；
- 什么时候 buffer 可以复用或释放；
如果客户端直接写 buffer，那就绕过了内核的 buffer 管理机制，会导致同步错乱或内存泄漏。
既然
copy_from_user()也是从用户态把数据“写”到内核态，为什么直接让用户进程mmap后写入内核共享区就不行？
这不是矛盾，而是涉及操作权限和控制方式的本质不同。
✅ 关键区别：谁控制写入、写到哪里、写多少
| 操作方式 | 数据从哪里来 | 写到内核哪里 | 谁控制写入行为 | 是否可控 | 安全性 |
|---|---|---|---|---|---|
copy_from_user() | 用户空间 | 指定内核缓冲区 | 内核主动发起 | ✅ 严格受控 | ✅ 高 |
mmap + 用户写入 | 用户空间 | 内核映射缓冲区 | 用户主动写入 | ❌ 无法限制 | ❌ 极差 |
🧠 更具体地解释：
✅ copy_from_user() 是“受控的写”：
- 是 内核代码主动发起 的写操作，客户端是向内存发起写申请；
- 内核知道要从用户哪里读（源地址）、写到哪里（目标地址）、写多少（长度）；
- 内核有权限检查（是否越界、是否有效地址等）；
- 可以拦截、验证、拒绝错误数据（如非法指针、越界数据）；
❌ 直接 mmap 给用户写，是“用户随便写”：
- 用户进程获得 mmap 映射地址（指向内核 buffer）；
- 可以 随时 往这块内存写入任何内容；
- 可以篡改其他进程或内核的数据（如果不做隔离）；
- 内核 无法知道何时写、写了什么、写了多少、是否合法；
问题本质是：
❓既然“用户进程 mmap 写内核区是危险的”，那为什么 服务端进程也能 mmap 内核区的 binder buffer，这又不会有安全问题呢？
✅ 核心回答：
因为服务端进程 mmap 到的内核缓冲区，是：
- 只读的（通常是
PROT_READ）- 由内核分配、内核写入的
- 由内核严格管理访问权限和生命周期的
✅ 所以服务端只是 “读取” 它收到的 binder 消息，不能改写内核内容，不会有安全风险。
服务端调用 mmap() 后，并不是服务端和内核各有一块 buffer，而是 内核分配 buffer 并映射到服务端用户空间中。这是一块共享的物理内存，不同虚拟地址映射到同一内存区域，做到了高效的数据传输和内存复用。
✔️ 物理页是 一块内存，在内核空间和服务端用户空间有两个虚拟映射地址。只有一块底层物理内存。然后将这块内核页 映射到服务端用户空间的虚拟地址空间中
❓ 内核是不是会把 Client 的数据直接拷贝到 Server 和内核共享的那块物理内存（binder buffer）？
✅ 简明回答：
是的，内核会将客户端提交的数据通过
copy_from_user()拷贝进内核控制的 binder buffer，而这个 binder buffer 最终映射给了服务端进程使用。
✅ Server 进程如何读取事务数据：
- Server 启动时，先打开
/dev/binder并使用mmap()初始化映射内存区域（但是还没有实际数据）。
✅ Server 调用 mmap() 是建立用户空间到 binder 驱动的“映射通道”，但并不实际映射任何有效数据 buffer；实际的 buffer 映射是内核驱动发起并控制的行为。
- Server 使用
ioctl(fd, BINDER_WRITE_READ, &bwr)主动进入“读取”阶段，告诉内核“我准备好接收事务”。
那服务端是怎么“阻塞等待”的？
如果你担心这样会浪费 CPU，其实：
ioctl(BINDER_WRITE_READ)是一个 阻塞调用；- 如果事务队列为空，内核会让这个线程进入
wait_event_interruptible()； - 一旦 Client 发来事务，内核就唤醒服务端线程；服务端轮训读取数据
所以它本质上是**“阻塞轮询”，但不是 busy loop**，是高效的事件等待机制。
服务端在初始化时就会调用 mmap() 来建立映射通道，也就是在 服务进程启动时就完成了内存映射，并不是等客户端发数据时才映射的。
是不是每个进程在创建的时候都会调用
mmap()来映射 binder buffer？
✅ 简明回答：
不是每个进程创建时都
mmap()binder buffer，只有那些
需要通过 Binder 通信，并且注册为 Binder 服务端或接收数据的进程才会调用mmap()。
4. Binder通信模型
4.1 通信模型
1，一个进程使用 BINDER_SET_CONTEXT_MGR 命令通过 Binder 驱动将自己注册成为 ServiceManager；
2，Server 通过驱动向 ServiceManager 中注册 Binder（Server 中的 Binder 实体），即注册（可对外提供的）服务。驱动为这个 Binder 创建位于内核中的实体节点以及 ServiceManager 对实体的引用，将名字以及新建的引用打包传给 ServiceManager，ServiceManger 将其填入查找表。
3，Client 通过名字，在 Binder 驱动的帮助下从 ServiceManager 中获取到对 Binder 实体的引用，通过这个引用就能实现和 Server 进程的通信。
注意：
1，ServiceManager进程是使用BINDER_SET_CONTEXT_MGR将自己注册成ServiceManager，并会创建一个Binder 实体
2，这个 Binder 实体的引用在所有 Client 中都固定为 0 ，无需通过其它手段获得。也就是说，一个 Server 想要向 ServiceManager 注册自己的 Binder 就必须通过这个 0 号引用和 ServiceManager 的 Binder 通信。
4.2 系统服务和自定义服务
1，系统服务会往ServiceManager注册，ServiceManager运行在单独的进程里，客户端进程需要先向ServiceManager里请求IBinder，再使用IBinder获取关联接口进而使用系统服务。
2，自定义服务所在进程开启后，暴露出IBinder。客户端通过绑定服务端进程里的Service，将IBinder跨进程传递至客户端，客户端再使用IBinder获取关联接口进而使用自定义服务。此过程没有借助于ServiceManager。
参考：www.jianshu.com/p/b39ffcbcb…
5. Android Binder 通信代码理解
5.1 Binder相关类
1，IBinder : IBinder 是一个接口，代表了一种跨进程通信的能力。只要实现了这个借口，这个对象就能跨进程传输。
2，IInterface : IInterface 代表 Server 进程对象具备什么样的能力（能提供哪些方法，其实对应的就是 AIDL 文件中定义的接口）
3，Binder : Java 层的 Binder 类，代表 Binder 本地对象。
4，BinderProxy :表clientd端，远程 Binder 对象的本地代理；
这两个类都继承自 IBinder, 因而都具有跨进程传输的能力；实际上，在跨越进程的时候，Binder 驱动会自动完成这两个对象的转换。
5，Stub : AIDL 的时候，编译工具会给我们生成一个名为 Stub 的静态内部类；这个类继承了 Binder, 说明它是一个 Binder 本地对象，它实现了 IInterface 接口，表明它具有 Server 提供给 Client 的能力；Stub 是一个抽象类，具体的 IInterface 的相关实现需要开发者自己实现。
