2024年Android最新AndroidBAT高级面试合集——Binder 通信原理与机制，2024年最新面试必问10大问题回答-CSDN博客

本文链接：https://blog.csdn.net/2401_84557161/article/details/138844789

最后

下面是辛苦给大家整理的学习路线

网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。

一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！

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 区写进通讯录，那么就形成了一张表：

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

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

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

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

Binder 通信原理

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

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

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

Server 进程向 ServiceManager 注册，告诉 ServiceManager 我是谁，我有什么，我能做什么。就好比徐同学（Server 进程）有一台笔记本（computer 对象），这台笔记本有个 add 方法。这时映射关系表就生成了。
Client 进程向 ServiceManager 查询，我要调用 Server 进程的 computer 对象的 add 方法，可以看到这个过程经过 Binder 驱动，这时候 Binder 驱动就开始发挥他的作用了。当向 ServiceManager 查询完毕，是返回一个 computer 对象给 Client 进程吗？其实不然， Binder 驱动将 computer 对象转换成了 computerProxy 对象，并转发给了 Client 进程，因此，Client 进程拿到的并不是真实的 computer 对象，而是一个代理对象，即 computerProxy 对象。很容易理解这个 computerProxy 对象也是有 add 方法，（如果连 add 方法都没有，岂不是欺骗了 Client？），但是这个 add 方法只是对参数进行一些包装而已。
当 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 进程还是如愿的得到了自己想要。跨进程通信完毕。