概况
Android 系统架构中大量使用了binder机制作为IPC(进程间通讯)方案
当然也存在部分其他的IPC方式，如管道、SystemV、Socket等。那么Android为什么不使用这些原有的技术，而是要使开发一种新的叫Binder的进程间通信机制呢？
为什么使用binder
性能方面
在移动设备上，广泛的使用IPC对性能有更高的要求；binder数据拷贝需要一次，原有的socket、管道、消息队列等方式需要
（用户空间A--（copy-from-user）--内核空间缓存---（映射）--内核空间数据接收缓存区--（映射）--用户空间B）
进行两次；共享内存的方式不需要进行进行内存拷贝，但实现方式比较复杂；
安全方面
传统的进程间通讯方式并没有对通讯双方的身份做出严格的验证，比如socket通讯，ip是客户端手动填入，容易伪造，而binder机制从协议本身就支持对通讯双方做身份校验，因此安全性更高。
binder
IPC原理
每个android的进程只能运行在自己进程所在的虚拟空间，分为用户空间和内核空间，用户空间不可共享，但内核空间共享。client和service通信正是使用内核空间来完成底层通信工作的；采用ioclt等方法跟内核空间的驱动进行交互的；
binder原理
binder 通信采用C/S架构，从组件视角来看由Client，Service，SeviceManager，Binder驱动构成，其中servicemanager用于管理系统中的各种服务；架构图如下:
从不同的组件来看，
Binder的四个角色：
Client ： 使用服务的进程
Server：提供服务的进程
ServiceManager : ServiceManager的作用是将字符形式的Binder名字转化成Client中对该
Binder的引用，使得Client 能够通过Binder名字获得对Service中Binder实体的引用。
Binder驱动：驱动负责进程之间Binder通信的建立，Binder在进程之间的传递，Binder引用计数管理，数据包在进程之间的传递和交互等一系列的底层支持；
Binder 运行机制：图中Client / Server / ServiceManager 之间的的相互通信都是基于Binder机制。自然同样适用的是C/S架构，图中的三大步骤都有相应的Client,Service端
注册服务：Server 进程先要注册Service 到ServiceManager，此时Server是客户端，ServiceManager服务端
获取服务：Client进程需要使用某个Service前，需要从ServiceManager中获取相应的Service。该过程：Client是客户端，ServiceManager是服务端。
使用服务：Client根据得到的Service信息建立与Service所在的server进程通信的通路，就可以直接与Service交互，此过程，Client是客户端，server是服务端
其中Client、Server、ServiceManager之间交互都是虚线，是由于他们之间交互不是直接的，而是通过binder驱动进行交互的，从而实现IPC的通信方式。其中binder位于内核空间，Client、Server、ServiceManager位于用户空间；其中Binder和ServiceManager又可以看做是Android 平台的基础架构，而Client、Server是Android 的应用层，开发人员只需自定义实现client、Server端，借助Android的基本平台架构便可以直接进行IPC通信。
使用服务的具体过程
- client通过获得一个server的代理接口，对server进行调用。
- 代理接口中定义的方法与server中定义的方法时一一对应的。
- client调用某个代理接口中的方法时，代理接口的方法会将client传递的参数打包成Parcel对象。
- 代理接口将Parcel发送给内核中的binder driver。
- server会读取binder driver中的请求数据，如果是发送给自己的，解包Parcel对象，处理并将结果返回。
- 整个的调用过程是一个同步过程，在server处理的时候，client会block住。因此client调用过程不应在主线程。
参与文章：https://www.jianshu.com/p/4920c7781afe?from=jiantop.com
