Android Binder跨进程通信原理分析

0.064字数 512阅读 137

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

Binder WorkFlow

一开始上手,陌生的东西比较多,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。
先上一张图来描述上面的那个情景:
Binder通信模型

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

Binder通信原理

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进程还是如愿的得到了自己想要。跨进程通信完毕!

这篇文章写的主要是我学习Binder时的痛点,我看过好多篇讲Binder的文章,发现好多都是不讲Binder驱动的,我很懵逼为什么那么重要的东西就略过,但还是有大神写的很好,比如:
Binder学习指南
Android Binder设计与实现
关于用户空间和内核空间,可以阅读阮一峰老师的文章:User space 与 Kernel space
全文完毕!

推荐阅读更多精彩内容