Linux IPC 机制
IPC(InterProcess Communication)进程间通讯，我们都知道Android内核其实就是Linux内核，而每个Android Application进程其实就是一个Linux进程，Linux 已经有比较好的IPC机制，为什么Android用Binder实现IPC机制呢？，分析Linux 一下的IPC 机制，方便深入理解Android Binder机制。
Linux 现有IPC机制
- 1.管道(pipe)
- 2.信号量
- 3.信号
- 4.消息队列
- 5.共享内存
- 6.socket
管道
- 数据拷贝两次(读取端 & 写入端)
- 借助内核缓存区(4K 限制)
信号量
- 资源共享，（PV操作）信号量提供互斥锁，防止多进程访问资源冲突。主要用于多进程和多线程的同步手段
信号
- 进程间通信外，进程还可以发送信号给进程本身，多用于消息传递 & 通知，不适合传递信息。
消息队列
- 数据拷贝两次，数据有最大限制。
共享内存
- 可直接加载到内存，但是不提供同步工具，需要结合类似信号量使用。
socket
- 传输效率低，C/S架构，多用于跨网络,跨设备的通信
参考
为什么选用Binder作为Android IPC机制呢
- 从性能来说，管道、消息队列、Socket对数据都会进行两次拷贝，耗费性能，而Binder只需要一次，对于移动设备来说，性能不得不考虑。
- 从架构来看，C/S架构，功能分离明确，稳定性好
- 最重要的一点，Linux IPC 无法鉴别身份，而Binder 可以鉴别用户进程Uid，给予Android身份机制。
- 从语言来说，Linux 是基于C语言面向过程，而Binder是基于Java面向对象来实现的。
贴出 Gityuan 的架构分析
最后，简单讲讲Android
* Binder架构Binder在Android系统中江湖地位非常之高。在Zygote孵化出system_server进程后，在system_server进程中出初始化支持整个Android framework的各种各样的Service，而这些Service从大的方向来划分，分为Java层Framework和Native Framework层(C++)的Service，几乎都是基于BInder IPC机制。
* Java framework：作为Server端继承(或间接继承)于Binder类，Client端继承(或间接继承)于BinderProxy类。例如 ActivityManagerService(用于控制Activity、Service、进程等) 这个服务作为Server端，间接继承Binder类，而相应的ActivityManager作为Client端，间接继承于BinderProxy类。 当然还有PackageManagerService、WindowManagerService等等很多系统服务都是采用C/S架构；
* Native Framework层：这是C++层，作为Server端继承(或间接继承)于BBinder类，Client端继承(或间接继承)于BpBinder。例如MediaPlayService(用于多媒体相关)作为Server端，继承于BBinder类，而相应的MediaPlay作为Client端，间接继承于BpBinder类。