od 无法附加

以便管道可以被循环利用。当管道中没有信息的话从管道中读取的进程会等待直到另一端的进程放入信息。当管道被放满信息的时候尝试放入信息的进程会等待直到另一端的进程取出信息。当两个进程都终结的时候管道也自动消失。

缺点

:在创建时分配一个管道时缓存区大小比较有限并不适合大量的进程通信

2.消息队列

​消息队列提供了一种从一个进程向另一个进程发送一个数据块的方法。每个数据块都被认为含有一个类型接收进程可以独立地接收含有不同类型的数据结构。我们可以通过发送消息来避免命名管道的同步和阻塞问题。但是消息队列与命名管道一样每个数据块都有一个最大长度的限制。

缺点

:信息复制两次额外的CPU消耗不合适频繁或信息量大的通信

3.共享内存

​什么是共享内存:

​顾名思义共享内存就是允许两个不相关的进程访问同一个逻辑内存。共享内存是在两个正在运行的进程之间共享和传递数据的一种非常有效的方式。不同进程之间共享的内存通常安排为同一段物理内存。进程可以将同一段共享内存连接到它们自己的地址空间中所有进程都可以访问共享内存中的地址

无须复制共享缓冲区直接付附加到进程虚拟地址空间速度快

缺点

:通信需要设计复杂的机制保证各个进程通讯有效性。进程间的同步问题操作系统无法实现必须各进程利用同步工具解决安全问题比较突出如果采用无异于将每个App放在一个内存中这样是非常不安全的

4.套接字

作为更通用的接口传输效率低主要用于不通机器或跨网络的通信

5.信号量

常作为一种锁机制防止某进程正在访问共享资源时其他进程也访问该资源。因此主要作为进程间以及同一进程内不同线程之间的同步手段。

6.信号

不适用于信息交换更适用于进程中断控制比如非法内存访问杀死某个进程等

接下来正面回答这个问题从5个角度来展开对的分析

(1)从性能的角度数据拷贝次数

数据拷贝只需要一次而管道、消息队列、都需要2次但共享内存方式一次内存拷贝都不需要从性能角度看性能仅次于共享内存。

(2)从稳定性的角度

是基于C/S架构的简单解释下C/S架构是指客户端()和服务端(Server)组成的架构Client端有什么需求直接发送给Server端去完成架构清晰明朗Server端与Client端相对独立稳定性较好而共享内存实现方式复杂没有客户与服务端之别需要充分考虑到访问临界资源的并发同步问题否则可能会出现死锁等问题从这稳定性角度看Binder架构优越于共享内存。

仅仅从以上两点各有优劣还不足以支撑google去采用binder的IPC机制那么更重要的原因是

(3)从安全的角度

传统LinuxIPC的接收方无法获得对方进程可靠的UID/PID从而无法鉴别对方身份而Android作为一个开放的开源体系拥有非常多的开发平台App来源甚广因此手机的安全显得额外重要对于普通用户绝不希望从App商店下载偷窥隐射数据、后台造成手机耗电等等问题传统LinuxIPC无任何保护措施完全由上层协议来确保。

Android为每个安装好的应用程序分配了自己的UID故进程的UID是鉴别进程身份的重要标志前面提到C/S架构Android系统中对外只暴露Client端Client端将任务发送给Server端Server端会根据权限控制策略判断UID/PID是否满足访问权限目前权限控制很多时候是通过弹出权限询问对话框让用户选择是否运行。Android6.0也称为AndroidM在6.0之前的系统是在App第一次安装时会将整个App所涉及的所有权限一次询问只要留意看会发现很多App根本用不上通信录和短信但在这一次性权限权限时会包含进去让用户拒绝不得因为拒绝后App无法正常使用而一旦授权后应用便可以胡作非为。

针对这个问题google在AndroidM做了调整不再是安装时一并询问所有权限而是在App运行过程中需要哪个权限再弹框询问用户是否给相应的权限对权限做了更细地控制让用户有了更多的可控性但同时也带来了另一个用户诟病的地方那也就是权限询问的弹框的次数大幅度增多。对于AndroidM平台上有些App开发者可能会写出让手机异常频繁弹框的App企图直到用户授权为止这对用户来说是不能忍的用户最后吐槽的可不光是App还有Android系统以及手机厂商有些用户可能就跳果粉了这还需要广大Android开发者以及手机厂商共同努力共同打造安全与体验俱佳的Android手机。

传统IPC

只能由用户在数据包里填入UID/PID另外可靠的身份标记只有由IPC机制本身在内核中添加。其次传统IPC访问接入点是开放的无法建立私有通道。从安全角度Binder的安全性更高。

说到这可能有人要反驳

Android就算用了Binder架构而现如今Android手机的各种流氓软件不就是干着这种偷窥隐射后台偷偷跑流量的事吗没错确实存在但这不能说Binder的安全性不好因为Android系统仍然是掌握主控权可以控制这类App的流氓行为只是对于该采用何种策略来控制在这方面android的确存在很多有待进步的空间这也是google以及各大手机厂商一直努力改善的地方之一。在Android6.0google对于app的权限问题作为较多的努力大大收紧的应用权限另外在Google举办的AndroidBootcamp2016大会中google也表示在Android7.0(也叫AndroidN)的权限隐私方面会进一步加强加固比如SELinuxMemorysafelanguage(还在research中)等等在今年的5月18日至5月20日google将推出AndroidN。

话题扯远了继续说Binder。

(4)从语言层面的角度

大家多知道Linux是基于C语言(面向过程的语言)而Android是基于Java语言(面向对象的语句)而对于Binder恰恰也符合面向对象的思想将进程间通信转化为通过对某个Binder对象的引用调用该对象的方法而其独特之处在于Binder对象是一个可以跨进程引用的对象它的实体位于一个进程中而它的引用却遍布于系统的各个进程之中。可以从一个进程传给其它进程让大家都能访问同一Server就像将一个对象或引用赋值给另一个引用一样。Binder模糊了进程边界淡化了进程间通信过程整个系统仿佛运行于同一个面向对象的程序之中。从语言层面Binder更适合基于面向对象语言的Android系统对于Linux系统可能会有点“水土不服”。

另外Binder是为Android这类系统而生而并非Linux社区没有想到BinderIPC机制的存在对于Linux社区的广大开发人员我还是表示深深佩服让世界有了如此精湛而美妙的开源系统。也并非Linux现有的IPC机制不够好相反地经过这么多优秀工程师的不断打磨依然非常优秀每种Linux的IPC机制都有存在的价值同时在Android系统中也依然采用了大量Linux现有的IPC机制根据每类IPC的原理特性因时制宜不同场景特性往往会采用其下最适宜的。比如在AndroidOS中的Zygote进程的IPC采用的是Socket(套接字)机制Android中的KillProcess采用的signal(信号)机制等等。而Binder更多则用在system_server进程与上层App层的IPC交互

。

(5)从公司战略的角度

总所周知Linux内核是开源的系统所开放源代码许可协议GPL保护该协议具有“病毒式感染”的能力怎么理解这句话呢受GPL保护的LinuxKernel是运行在内核空间对于上层的任何类库、服务、应用等运行在用户空间一旦进行SysCall(系统调用)调用到底层Kernel那么也必须遵循GPL协议。

而Android之父AndyRubin对于GPL显然是不能接受的为此Google巧妙地将GPL协议控制在内核空间将用户空间的协议采用Apache-2.0协议(允许基于Android的开发商不向社区反馈源码)同时在GPL协议与Apache-2.0之间的Lib库中采用BSD证授权方法有效隔断了GPL的传染性仍有较大争议但至少目前缓解Android让GPL止步于内核空间这是Google在GPLLinux下开源与商业化共存的一个成功典范。

有了这些铺垫我们再说说Binder的今世前缘

Binder是基于开源的OpenBinder实现的OpenBinder是一个开源的系统IPC机制,最初是由BeInc.开发接着由Palm,Inc.公司负责开发现在OpenBinder的作者在Google工作既然作者在Google公司在用户空间采用Binder作为核心的IPC机制再用Apache-2.0协议保护自然而然是没什么问题减少法律风险以及对开发成本也大有裨益的那么从公司战略角度Binder也是不错的选择。

另外再说一点关于OpenBinder在2015年OpenBinder以及合入到LinuxKernel主线3.19版本这也算是Google对Linux的一点回馈吧。

综合上述5点可知Binder是Android系统上层进程间通信的不二选择

需要文章开头的整理的面试目录中的资料如下视频教程的话

关注我并私信【资料】