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架构，多用于跨网络,跨设备的通信

参考

参考Gityuan 分析的Binder的结果

为什么选用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类。