Android Binder 简单认识
虽然Linux提供了上述(还有其它的如信号量等)的IPC方式，但是由于每种方式都有其缺点，因此，Android另起炉灶弄了另一种方式：Binder。 在此之前，先来了解一下内存映射(mmap)。
内存映射
image.png
上面提到过，"存储-转发"过程需要在用户空间和内核空间之间拷贝数据，还有一种不需要拷贝的方式：内存映射。 如上图，进程空间与内核空间共享磁盘上的一个映射文件，当进程空间往映射文件写入数据后（此处不是真正的I/O，而是内存读写），相当与写入了内核空间，反之亦然。
Binder 通信方式
image.png
进程A给进程B发送一段信息，流程如下：
-
进程A通过系统调用拷贝内容到内核空间。
-
由于内核空间与进程B做了内存映射，因此进程B能够知道内核空间的信息。
从上可知，通过Binder，进程A给进程B发送信息只进行了一次数据拷贝。 对比其它IPC方式可知：
image.png
另外，传统的IPC方式只能由使用者填入UID/PID，容易被外界仿造、篡改。而Binder内置为发送者添加UID/PID，更安全。
Android Binder 使用场合
似乎平时很少使用Binder呢？其实不然，我们不知不觉中已经用了它。 上图展示了Binder使用C/S模式，也就是
S(Server)端提供服务入口，C(Client)调用服务提供的接口，进而两者可以进行通信。 先来看看一段手机马达震动的代码：
Vibrator vibrator = (Vibrator)getSystemService(Context.VIBRATOR_SERVICE);
vibrator.vibrate(1000);
调用了Context里的方法：getSystemService，指定获取名为：VIBRATOR_SERVICE 的服务，拿到服务后调用vibrate(xx)即可实现手机震动。
每个App都能通过访问这段代码来实现手机震动，可想而知拿到的"震动服务"一定是某个地方统一提供的。 我们知道，Android系统启动后会开启名为：system_server的进程，顾名思义：系统服务，提供给所有App使用的公共服务进程。 "震动服务"就是跑在该进程里的。
当调用getSystemService(xx)获取"震动服务时"，相当于调用者(App进程)与system_server(服务提供进程）进行了一次IPC过程(实际比较复杂，简单说是：
通过ServiceManager获取Binder，该Binder连接system_server，ServiceManager跑在另外的进里)。
App进程--->Client system_server--->Server 类似的调用了getSystemService(xx)都是进程间通信。
你也许会说，我不调用上面的方法就不进行进程间通信了？
非也，请看。
举个例子：
客户端进程里有行为:Activity A跳转到ActivityB，这个过程是：
客户端进程先请求ActivityManagerService(AMS)[AMS运行在system_server进程]，此时已经通过Binder进 行了一次IPC操作。 AMS准备好之后告诉客户端进程创建Activity B对象，又是一次IPC操作。
注：中途还有其它 IPC过程
同理四大组件Service、ContentProvider、BroadcastReceiver都离不开Binder。 Binder一直存在，默默地充当着
进程间通信的桥梁，只是系统封装好了上层很少去主动调用它。
网友评论