为什么Android要设计Binder呢？直接用Linux的IPC通信机制不行吗？
- 一是因为Android系统相比于Linux，对安全性有更高的要求，Android中的每个应用都是一个沙盒模型，不能访问其他应用的数据，每个进程之间也不能直接访问其他进程的数据，相比于Android，Linux的限制就松了很多，所以PC的系统的病毒也比手机系统的病毒多很多，因为PC系统中一个进程的访问权限会大很多。
- 二是因为Android的IPC场景也会比Linux多很多，一个程序可能需要频繁的获取系统中其他进程的信息，比如电量，通讯录等等，并且前面提到的安全性的限制，也会使Android的IPC场景比Linux中的IPC场景更加频繁。
那么需要怎么设计呢？
- 性能
- 安全
- 可扩展性和低耦合性
性能
在Linux系统中，进程间传输数据性能最好的方式就是共享内存，或是以共享内存为原理衍生出来的技术，如mmap内存映射。
- 共享内存或者mmap都只需要进行一次数据拷贝，即把想要传输的数据拷贝到共享或者映射的内存区域中，另一个共享或者映射了这段内存的进程就可以直接使用内存中的数据了.
- 其他的IPC传输都需要两次拷贝，即将传输的数据拷贝的指定的内存区域（一般是内核空间），然后又将指定的内存区域的数据拷贝到需要通信的进程的内存中去。
所以为了性能考虑，Binder在设计时，采用了mmap内存映射这种方式来进行数据的传输
安全性
Binder设计中为了安全性的考虑， 天然支持携带进程ID，这样在进程间通信时，可以通过进程ID进程相应的权限控制。
并且Binder是CS架构，Servcer更容易对Client的访问权限进行控制。
可扩展和低耦合
Binder的可扩展和低耦合体现在两个方面的架构上
- 一是它的C/S架构s合计，在CS架构上，Clinet和Server都容易扩展，想要扩展通信，只需要增加Client或者Server就可以了，而不用去管中间的通信流程。
- 二是基于驱动的架构设计，在Android8.0之前，Binder只在Frameworkd之间使用，Binder挂载在dev/binder目录下，8.0开始硬件供应商部分，如相机，手电筒等硬件进程通信也开始使用binder，硬件部分的Binder挂载在/dev/vnbinder或/dev/hwbinder，可以看到，基于驱动的设计下，只需要新增一个虚拟设备，就可以很容易的实现扩展Binder通信的范围。
