Binder原理系列

一直关注皇叔，他的分享干货满满，写的博客条理清晰对framework层原理分析的很是透彻，适合大家学习。下面推荐几篇皇叔的Binder原理系列文章：

刘望舒Binder系列

下面从概述->Java层Binder->Native层Binder->Binder驱动大致流程进行分析Binder原理：

1.Linux的IPC通信原理

用户空间需要访问内核空间，就需要借助系统调用来实现。系统调用是用户空间访问内核空间的唯一方式，保证了所有的资源访问都是在内核的控制下进行的，避免了用户程序对系统资源的越权访问，提升了系统安全性和稳定性。

进程A和进程B的用户空间可以通过如下系统函数和内核空间进行交互：

copy_from_user：将用户空间的数据拷贝到内核空间。

copy_to_user：将内核空间的数据拷贝到用户空间。

2.Binder的通信原理（通过内存映射减少数据拷贝次数）

1.Binder驱动在内核空间创建一个数据接收缓存区。
2.在内核空间开辟一块内核缓存区，建立内核缓存区和数据接收缓存区之间的映射关系，以及数据接收缓存区和接收进程用户空间地址的映射关系。
3.发送方进程通过copy_from_user()函数将数据拷贝 到内核中的内核缓存区，由于内核缓存区和接收进程的用户空间存在内存映射，因此也就相当于把数据发送到了接收进程的用户空间，这样便完成了一次进程间的通信。

整个过程只使用了1次拷贝，不会因为不知道数据的大小而浪费空间或者时间，效率更高。

3.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 驱动会对这个跨越进程边界的对象对一点点特殊处理，自动完成代理对象和本地对象之间的转换。

4.java层Binder

我们拿AMS举例：

一次进程通信大致过程:BinderProxy.transact()->transactNative()-----------Binder---------Binder.transact()->onTransact()

5.Native层Binder

客户端通过Java层的服务端代理最终调用到BpBinder.transact函数。

Binder原理这块大家是不是和我一样困扰多年，学习Binder我看了好多书籍和文章，从不懂到萌懂再到略懂，每每看一次都有不一样的收获。其实无论再难的知识点只要我们愿意花费时间精力去学习去研究，总有一天会豁然开朗！

感谢
https://mp.weixin.qq.com/s/NBm5lh8_ZLfodOXT8Ph5iA

https://mp.weixin.qq.com/s/8knpF_axhD_JAEF6QUp2UQ

https://mp.weixin.qq.com/s/jbZrZYdKhSF8k9OSQAuksQ