Open kukyxs opened 5 years ago
进程: 进程是操作系统的概念. 每当我们执行一个程序时,对于操作系统来讲就创建了一个进程. 在这个过程中,伴随着资源的分配和释放. 可以认为进程是一个程序的一次执行过程.
进程间通信: 进程用户空间是相互独立的,一般而言是不能相互访问的. 但很多情况下进程间需要互相通信,来完成系统的某项功能. 进程通过与内核及其它进程之间的互相通信来协调它们的行为.
Linux现有进程间通信: 1)管道:在创建时分配一个page大小的内存,缓存区大小比较有限. 2)消息队列:信息复制两次,额外的CPU消耗;不合适频繁或信息量大的通信. 3)共享内存:无须复制,共享缓冲区直接附加到进程虚拟地址空间,速度快;但进程间的同步问题操作系统无法实现,必须各进程利用同步工具解决. 4)套接字:作为更通用的接口,传输效率低,主要用于不同机器或跨网络的通信. 5)信号量:常作为一种锁机制,防止某进程正在访问共享资源时,其他进程也访问该资源.因此,主要作为进程间以及同一进程内不同线程之间的同步手段. 6)信号:不适用于信息交换,更适用于进程中断控制,比如非法内存访问,杀死某个进程等.
对比: 1)从性能的角度(数据拷贝次数) 0次:共享内存 1次:Binder 2次:管道 消息队列 套接字 从性能角度看,Binder性能仅次于共享内存.
2)从稳定性的角度 Binder基于C/S架构,C和S相对独立,稳定性较好. 共享内存实现方式复杂,没有客户与服务端之别,需要充分考虑到访问临界资源的并发同步问题,否则可能会出现死锁等问题. 从稳定性角度看,Binder优越于共享内存.
3)从安全的角度 传统Linux的IPC的接收方无法获得对方进程可靠的UID/PID,从而无法鉴别对方身份. 而Android作为一个开放的开源体系,拥有非常多的开发平台,App来源甚广,因此手机的安全显得额外重要. 对于普通用户,绝不希望从App商店下载偷窥隐私数据、后台造成手机耗电等等问题,传统Linux IPC无任何保护措施,完全由上层协议来确保.
Android为每个安装好的应用程序分配了自己的UID,故进程的UID是鉴别进程身份的重要标志. 前面提到C/S架构,Android系统中对外只暴露Client端,Client端将任务发送给Server端. Server端会根据权限控制策略判断UID/PID是否满足访问权限,目前权限控制很多时候是通过弹出权限询问对话框,让用户选择是否运行.
传统IPC只能由用户在数据包里填入UID/PID. 另外,可靠的身份标记只有由IPC机制本身在内核中添加. 其次传统IPC访问接入点是开放的,无法建立私有通道. 从安全角度,Binder的安全性更高.
4)从语言层面的角度 Linux基于C(面向过程),Android基于Java(面向对象). 而对于Binder恰恰也符合面向对象的思想,将进程间通信转化为通过对某个Binder对象的引用调用该对象的方法. 而其独特之处在于Binder对象是一个可以跨进程引用的对象,它的实体位于一个进程中,而它的引用却遍布于系统的各个进程之中. 可以从一个进程传给其它进程,让大家都能访问同一Server,就像将一个对象或引用赋值给另一个引用一样. Binder模糊了进程边界,淡化了进程间通信过程,整个系统仿佛运行于同一个面向对象的程序之中. 从语言层面,Binder更适合基于面向对象语言的Android系统.
5)从公司战略的角度 Linux内核是开源的系统,所开放源代码许可协议GPL保护,该协议具有“病毒式感染”的能力. Android之父Andy Rubin对于GPL显然是不能接受的.
为此,Google巧妙地将GPL协议控制在内核空间. 将用户空间的协议采用Apache-2.0协议. 同时在GPL协议与Apache-2.0之间的Lib库中采用BSD授权方法,有效隔断了GPL的传染性.
综合上述5点,可知Binder是Android系统上层进程间通信的不二选择.
参考: 1)https://www.cnblogs.com/liugh-wait/p/8533003.html 2)https://www.zhihu.com/question/39440766/answer/89210950 3)https://blog.csdn.net/universus/article/details/6211589 4)http://www.360doc.com/content/18/0414/22/11935121_745697757.shtml
进程: 进程是操作系统的概念. 每当我们执行一个程序时,对于操作系统来讲就创建了一个进程. 在这个过程中,伴随着资源的分配和释放. 可以认为进程是一个程序的一次执行过程.
进程间通信: 进程用户空间是相互独立的,一般而言是不能相互访问的. 但很多情况下进程间需要互相通信,来完成系统的某项功能. 进程通过与内核及其它进程之间的互相通信来协调它们的行为.
Linux现有进程间通信: 1)管道:在创建时分配一个page大小的内存,缓存区大小比较有限. 2)消息队列:信息复制两次,额外的CPU消耗;不合适频繁或信息量大的通信. 3)共享内存:无须复制,共享缓冲区直接附加到进程虚拟地址空间,速度快;但进程间的同步问题操作系统无法实现,必须各进程利用同步工具解决. 4)套接字:作为更通用的接口,传输效率低,主要用于不同机器或跨网络的通信. 5)信号量:常作为一种锁机制,防止某进程正在访问共享资源时,其他进程也访问该资源.因此,主要作为进程间以及同一进程内不同线程之间的同步手段. 6)信号:不适用于信息交换,更适用于进程中断控制,比如非法内存访问,杀死某个进程等.
对比: 1)从性能的角度(数据拷贝次数) 0次:共享内存 1次:Binder
2次:管道 消息队列 套接字 从性能角度看,Binder性能仅次于共享内存.
2)从稳定性的角度 Binder基于C/S架构,C和S相对独立,稳定性较好. 共享内存实现方式复杂,没有客户与服务端之别,需要充分考虑到访问临界资源的并发同步问题,否则可能会出现死锁等问题. 从稳定性角度看,Binder优越于共享内存.
3)从安全的角度 传统Linux的IPC的接收方无法获得对方进程可靠的UID/PID,从而无法鉴别对方身份. 而Android作为一个开放的开源体系,拥有非常多的开发平台,App来源甚广,因此手机的安全显得额外重要. 对于普通用户,绝不希望从App商店下载偷窥隐私数据、后台造成手机耗电等等问题,传统Linux IPC无任何保护措施,完全由上层协议来确保.
Android为每个安装好的应用程序分配了自己的UID,故进程的UID是鉴别进程身份的重要标志. 前面提到C/S架构,Android系统中对外只暴露Client端,Client端将任务发送给Server端. Server端会根据权限控制策略判断UID/PID是否满足访问权限,目前权限控制很多时候是通过弹出权限询问对话框,让用户选择是否运行.
传统IPC只能由用户在数据包里填入UID/PID. 另外,可靠的身份标记只有由IPC机制本身在内核中添加. 其次传统IPC访问接入点是开放的,无法建立私有通道. 从安全角度,Binder的安全性更高.
4)从语言层面的角度 Linux基于C(面向过程),Android基于Java(面向对象). 而对于Binder恰恰也符合面向对象的思想,将进程间通信转化为通过对某个Binder对象的引用调用该对象的方法. 而其独特之处在于Binder对象是一个可以跨进程引用的对象,它的实体位于一个进程中,而它的引用却遍布于系统的各个进程之中. 可以从一个进程传给其它进程,让大家都能访问同一Server,就像将一个对象或引用赋值给另一个引用一样. Binder模糊了进程边界,淡化了进程间通信过程,整个系统仿佛运行于同一个面向对象的程序之中. 从语言层面,Binder更适合基于面向对象语言的Android系统.
5)从公司战略的角度 Linux内核是开源的系统,所开放源代码许可协议GPL保护,该协议具有“病毒式感染”的能力. Android之父Andy Rubin对于GPL显然是不能接受的.
为此,Google巧妙地将GPL协议控制在内核空间. 将用户空间的协议采用Apache-2.0协议. 同时在GPL协议与Apache-2.0之间的Lib库中采用BSD授权方法,有效隔断了GPL的传染性.
综合上述5点,可知Binder是Android系统上层进程间通信的不二选择.
参考: 1)https://www.cnblogs.com/liugh-wait/p/8533003.html 2)https://www.zhihu.com/question/39440766/answer/89210950 3)https://blog.csdn.net/universus/article/details/6211589 4)http://www.360doc.com/content/18/0414/22/11935121_745697757.shtml