Binder

Binder（胶水，粘合剂 ） 是Android系统最重要的特性之一。是系统间各个组建的桥梁。Android系统的开放式很大程度上得益于这种极其方便的跨进程通信机制
理解Binder对于理解整个Android系统有着重要的作用，Android系统的四大组件，AMS，PMS等系统服务无一不与Binder挂钩。可以说无Binder不Android
Binder分为 Binder对象 和 Binder驱动。

Binder 驱动

在Android系统中，这个运行在内核空间的，负责各个用户进程通过Binder通信的内核模块叫做Binder驱动。但是Binder并不是Linux内核的一部分，它可以访问内核空间是因为Linux的动态可加载内核模块（Loadable Kernel Module，LKM）机制。模块是具有独立功能的程序，它可以被单独编译，但不能独立运行。它在运行时被链接到内核作为内核的一部分在内核空间运行。

Binder 对象

Binder对象是一个可以夸进程引用的对象，它的实现位于一个进程中，而它的引用却遍布与系统的各个进程之中。最诱人的是，这个引用和java引用一样，既可以是强类型，也可以是弱类型，而且可以从一个进程传递给其他进程，让大家都能访问同一个Server，就像将一个对象或引用赋值给另一个引用一样。分为本地对象和代理对象

1. Binder 本地对像：AIDL接口实现端的对象
2. Binder 代理对象： 它只是Binder本地对象的一个远程代理；对这个Binder代理对象的操作，会通过Binder驱动最终转发到Binder本地对象上去完成

Binder驱动是主要的内核模块，而整个Binder对象就是通讯载体。可以自由的通过Binder驱动穿梭任意进程。所以客户端或者服务器可以把数据放入Binder对象里，然后进行调用和通讯。

Binder 从不同的角度，可以有不同的解释：

• 是Android的一个类，即Binder.java，实现了IBinder接口，
• 从IPC角度说，是Android的一种跨进程通信方式，这种方式在Linux中没有
• 还可以理解为一种虚拟的物理设备，Binder驱动，设备驱动在/dev/binder,
• 从Android Framework角度来说，是ServiceManager连接各种Manager（ActivityManager，WindowManager等）和形影的ManagerService的桥梁
• 从Android应用层来说，是客户端和服务端进行通信的媒介，当bindService的时候，服务端会返回一个包含了服务端业务调用的Binder对象，通过这个Binder对象，客户端就可以获取服务器提供的服务或者数据了，这里的服务包括普通的服务和基于AIDL的服务
• 对于Server进程来说，Binder指的是Binder本地对象。
• 对于Client来说，Binder指的是Binder代理对象，对于一个拥有Binder对象的使用者而言，它无须关心这是一个Binder代理对象还是Binder本地对象；对于代理对象的操作和对本地对象的操作对它来说没有区别。
• 对于传输过程而言，Binder是可以进行跨进程传递的对象；Binder驱动会对具有跨进程传递能力的对象做特殊处理：自动完成代理对象和本地对象的转换。

Binder模糊了进程边界，淡化了进程间通信过程，整个系统仿佛运行与同一个面向对象的程序之中，形形色色的Binder对象以及星罗棋布的引用仿佛粘是结整个应用程序的胶水，这也是Binder在英文中的原意。

Binder的工作过程

Binder的框架采用C/S架构，包含四个角色： Server，Client，ServiceManager(SM)以及Binder驱动。其中Server，Client，SM 运行用户空间，而Binder驱动运行在内核空间。

例如 一个 Client进程想要调用Server进程中的object对象的一个add()方法。

1. 首先Server进程要向SM注册；告诉自己是谁，自己有什么能力；例如 它叫zhangsan，它有一个object对象，可以执行add 操作；于是SM建立了一张表：zhangsan这个名字对应进程Server;
2. 然后Client向SM查询：我需要联系一个名字叫做zhangsan的Server 进程里面的object对象；这时候关键来了：进程之间通信的数据都会经过运行在内核空间里面的Binder驱动，Binder驱动在数据流过的时候做了一点手脚，它并不会给Client进程返回一个真正的object对象，而是返回一个看起来跟object一模一样的代理对象objectProxy，这个objectProxy也有一个add方法，但是这个add方法只是一个傀儡，并没有Server进程里面object对象的add方法那个能力，它唯一做的事情就是把参数包装然后交给Binder驱动。但是Client进程并不知道Binder驱动返回给它的对象动过手脚，毕竟伪装的太像了，如假包换。Client开开心心地拿着objectProxy对象然后调用add方法；我们说过，这个add什么也不做，直接把参数做一些包装然后直接转发给Binder驱动。
3. 最后Binder驱动收到这个消息，发现是这个objectProxy；一查表就明白了：我之前用objectProxy替换了object发送给Client了，它真正应该要访问的是object对象的add方法；于是Binder驱动通知Server进程，调用你的object对象的add方法，然后把结果发给我，Sever进程收到这个消息，照做之后将结果返回Binder驱动，Binder驱动然后把结果返回给Client进程；于是整个过程就完成了。

由于Binder驱动返回的objectProxy与Server进程里面原始的object是如此相似，给人感觉好像是直接把Server进程里面的对象object传递到了Client进程；而实际上Client进程只不过是持有了Server端的代理对象而已；代理对象协助驱动完成了跨进程通信。因此，我们可以说Binder对象是可以进行跨进程传递的对象

Binder使用场景

Android开发中，Binder主要用于在Service中，包括AIDL和Messager，其中普通服务中的Binder不涉及到进程通信，另外，ContentProvider底层实现也是Binder，
所以Binder的使用场景如下：

参考链接：

Android 开发艺术探索

Android Binder之应用层总结与分析

Binder学习指南

Android面试一天一题（Day 35：神秘的Binder机制）