AndroidBAT高级面试合集——Binder 通信原理与机制

Posted 2022-02-07 冬天的毛毛雨

先上一张 Binder 的工作流程图。
（如果不清晰，可以 复制图片链接到浏览器 或 保存到本地 查看，我经常都是这样看图的哈）

一开始上手，陌生的东西比较多，But，其实并不复杂。喔，流程图是用 ProcessOn 画的。很棒的在线画图工具。

出发前预备子弹 我们知道进程之间，虚拟地址不同，是不能直接通信的，这是 一种保护机制。打开任务管理器，查看一下 N 多的进程，试想一下如果这些进 程直接通信会带来什么后果？

而用户空间可以通过 System calls（系统回调）与内核空间通信的，如果在内核 空间中有一个模块，能够完成数据的转发，那么是不是两个进程就可以通信了 呢？如下图：

上面提到一些用户空间、内核空间的概念，用户空间也能大概猜到是什么东西， 而内核空间，就知道它是很底层的东西好了。而模块呢，可以简单的理解为实现 一个功能的程序或一个硬件电路等，比如玩单片机的时候，会有红外线模块，蓝 牙模块，wifi 模块等。这些概念的东西搜索一下百科知道就好。

Binder 驱动

Binder 驱动运行在内核空间，它就是那个内核模块了。Binder 驱动很重要，承 担了进程间通信的数据转发等。一提到驱动，也是比较熟悉，你插个 U 盘，需 要驱动吧。而 Binder 驱动也差不多，虽然名字取得很好，功能还很强大。但也 不是什么神奇的东西。

Binder 跨进程通信模型
Binder 的通信模型有 4 个角色：Binder Client、Binder Server、Binder Driver （Binder 驱动）、ServiceManager。

想象一个情景：我到北京旅行，要给高中同学寄一张明信片，明信片肯定要写上 地址吧，不然怎么寄给对方呢？那么我怎么拿到这个地址呢，很简单，翻一下毕 业相册就好了。而这个记录着同学们通信地址的毕业相册，就相当与一个通讯录。 在 Binder 的通信模型中扮演的是 ServiceManager 的角色。好，现在已经有了通 信地址了，那么就找到邮局寄出去就好了。过几天同学就高高兴兴的收到了明信 片。那么这个邮局在 Binder 通信模型中扮演的是 Binder 驱动的角色，而作为寄 信人的我就是 Binder Client，收信人同学就是 Binder Server。 先上一张图来描述上面的那个情景：

可以看到，ServiceManager、Binder Client、Binder Server 处于不同的进程，他 们三个都在用户空间，而 Binder 驱动在内核空间。（我是特意把 Binder 驱动画 的比较大的，因为 Binder 驱动的作用最大）

那先来简述一下这个通信模型： 首先是有一个 ServiceManager，刚开始这个通讯录是空白的，然后 Server 进程 向 ServiceManager 注册一个映射关系表，比如徐同学把自己的地址广东省广州 市 xx 区写进通讯录，那么就形成了一张表：

$$徐同学—>广东省广州市xx区$$

之后 Client 进程想要和 Server 进程通信，首先向 ServiceManager 查询地址， ServiceManager 收到查询的请求之后，返回查询结果给 Client。

注意到这里不管是 Server 进程注册，还是 Client 查询，都是经过 Binder 驱动的， 这也真是 Binder 驱动的作用所在，先不急，下面的原理会分析到。

这时候我就拿着地址就开始寄明信片咯。当我把明信片放扔进邮筒，之后的工作 就是由邮局去完成了，也就是 Binder 驱动去完成通信的转发。

Binder 通信原理
从寄明信片的例子中，邮递员从邮筒取出明信片，然后跨越千山万水将明信片送 达。从这点我们也能想到，其实 Binder 驱动完成的工作是很重要的。

我们来还原一个 Binder 跨进程通信的过程。 案例：Client 进程调用 Server 进程 的 computer 对象的 add 方法。

接下来的内容你可能需要知道代理模式才能更好的理解，不过没学习过代理模式 也没关系，可以先读下去，然后在去补一下代理模式，再回来看这篇文章。思路 会清晰很多。

1. Server 进程向 ServiceManager 注册，告诉 ServiceManager 我是谁，我有什么，我能做什么。就好比徐同学（Server 进程）有一台笔记本（computer 对象），这台笔记本有个 add 方法。这时 映射关系表就生成了。
2. Client 进程向 ServiceManager 查询，我要调用 Server 进程的 computer 对象的 add 方法，可以看到这个过程经过 Binder 驱动， 这时候 Binder 驱动就开始发挥他的作用了。当向 ServiceManager 查询完毕，是返回一个 computer 对象给 Client 进程吗？其实不然， Binder 驱动将 computer 对象转换成了 computerProxy 对象，并转 发给了 Client 进程，因此，Client 进程拿到的并不是真实的 computer 对象，而是一个代理对象，即 computerProxy 对象。很 容易理解这个 computerProxy 对象也是有 add 方法，（如果连 add 方法都没有，岂不是欺骗了 Client？），但是这个 add 方法只是对 参数进行一些包装而已。
3. 当 Client 进程调用 add 方法，这个消息发送给 Binder 驱动， 这时驱动发现，原来是 computerProxy，那么 Client 进程应该是需 要调用 computer 对象的 add 方法的，这时驱动通知 Server 进程， 调用你的 computer 对象的 add 方法，将结果给我。然后 Server 进程就将计算结果发送给驱动，驱动再转发给 Client 进程，这时 Client 进程还蒙在了鼓里，他以为自己调用的是真实的 computer 对象的 add 方法，其实他只是调用了代理而已。不过 Client 最终 还是拿到了计算结果。

好了，一个通信过程就完成了。我们发现，其实 Binder 驱动就是一个中转。

总结

再来梳理总结一下：当 Client 进程向 ServiceManager 查询 Server 进程（我要调 用你的某个对象的某个方法了），这个过程也是一个跨进程通信的过程，也经过 了 Binder 驱动，这时 Binder 驱动发挥它的作用，来了个狸猫换太子，将 Server 进程中的真实对象转换成代理对象，返回这个代理对象给 Client 进程。 Client 进程拿到了这个代理对象，然后调用这个代理对象的方法，Binder 驱动继续发挥 他的使命，它会通知 Server 进程执行计算工作，将 Server 进程中的真实对象执 行的结果返回给了 Client 进程，这样 Client 进程还是如愿的得到了自己想要。跨进程通信完毕。

由于文章篇幅长度原因，暂且写到这了，后面还有更多丰富的干货更新，我已将后续更新内容整理成文档形式了，大家如果想要参考学习可以私信回复我【666】或点击【Github地址】进行查看获取！

文档完整版如下