Android源码(7) --- Binder(1) Linux IPC 机制

时间:2022-09-02 16:15:50

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类。