Android为什么选择binder
2016-02-24 17:37
246 查看
Binder (Android技术内幕):
在上面这些可供选择的方式中,Android使用得最多也最被认可的还是Binder机制。
为什么会选择Binder来作为进程之间的通信机制呢?因为Binder更加简洁和快速,消耗的内存资源更小吗?
不错,这些也正是Binder的优点。
当然,也还有很多其他原因,比如传统的进程间通信可能会增加进程的开销,而且有进程过载和安全漏洞等方面的风险,Binder正好能解决和避免这些问题。
Binder主要能提供以下一些功能:
用驱动程序来推进进程间的通信。
通过共享内存来提高性能。
为进程请求分配每个进程的线程池。
针对系统中的对象引入了引用计数和跨进程的对象引用映射。
进程间同步调用。
Android Binder设计与实现 – 设计篇:
目前linux支持的IPC包括传统的管道、System V IPC、即消息队列/共享内存/信号量,以及socket中只有socket支持Client-Server的通信方式。
当然也可以在这些底层机制上架设一套协议来实现Client-Server通信,但这样增加了系统的复杂性,在手机这种条件复杂,资源稀缺的环境下可靠性也难以保证。
另一方面是传输性能:
socket作为一款通用接口,其传输效率低,开销大,主要用在跨网络的进程间通信和本机上进程间的低速通信。
消息队列和管道采用存储-转发方式,即数据先从发送方缓存区拷贝到内核开辟的缓存区中,然后再从内核缓存区拷贝到接收方缓存区,
至少有两次拷贝过程。共享内存虽然无需拷贝,但控制复杂,难以使用。
表 1 各种IPC方式数据拷贝次数
还有一点是出于安全性考虑:
Android作为一个开放式,拥有众多开发者的平台,应用程序的来源广泛,确保智能终端的安全是非常重要的。
终端用户不希望从网上下载的程序在不知情的情况下偷窥隐私数据,连接无线网络,长期操作底层设备导致电池很快耗尽等等。传统IPC没有任何
安全措施,完全依赖上层协议来确保。首先传统IPC的接收方无法获得对方进程可靠的UID/PID(用户ID/进程ID),从而无法鉴别对方身份。
Android为每个安装好的应用程序分配了自己的UID,故进程的UID是鉴别进程身份的重要标志。使用传统IPC只能由用户在数据包里填入UID/PID,
但这样不可靠,容易被恶意程序利用。可靠的身份标记只有由IPC机制本身在内核中添加。其次传统IPC访问接入点是开放的,无法建立私有通道。
比如命名管道的名称、system V的键值、socket的ip地址或文件名都是开放的,只要知道这些接入点的程序都可以和对端建立连接,不管怎样都无法
阻止恶意程序通过猜测接收方地址获得连接。
基于以上原因,Android需要建立一套新的IPC机制来满足系统对通信方式,传输性能和安全性的要求,这就是Binder。
Binder基于 Client-Server通信模式,传输过程只需一次拷贝,为发送发添加UID/PID身份,既支持实名Binder也支持匿名Binder,安全性高。
面向对象的 Binder IPC:
面向对象思想的引入将进程间通信转化为通过对某个Binder对象的引用调用该对象的方法,而其独特之处在于Binder对象是一个
可以跨进程引用的对象,它的实体位于一个进程中,而它的引用却遍布于系统的各个进程之中。最诱人的是,这个引用和java里引用
一样既可以是强类型,也可以是弱类型,而且可以从一个进程传给其它进程,让大家都能访问同一Server,就像将一个对象或引用赋
值给另一个引用一样。Binder模糊了进程边界,淡化了进程间通信过程,整个系统仿佛运行于同一个面向对象的程序之中。
面向对象只是针对应用程序而言,对于Binder驱动和内核其它模块一样使用C语言实现,没有类和对象的概念。
Binder驱动为面向对象的进程间通信提供底层支持。
》关于Binder架构:
从架构的角度看,在Java中搭建了一整套框架,如IBinder接口、Binder类和BinderProxy类。但是从通信角度看,架构的编写不论采用的是Native语言还是Java语言,只要把请求传递到Binder驱动就可以了,所以通信的目的是向binder发送请求和接收回复。在这个目的之上,考虑到软件的灵活性和可扩展性,于是编写了一个架构。反过来说,也可以不使用架构(即没有使用任何接口、派生之类的东西)而直接和binder交互,例如,ServiceManager作为Binder架构的一个核心程序,就是直接读取/dev/binder设备,获取并处理请求。从这一点上看,Binder架构的目的虽是简单的(即打开binder设备,然后读请求和写回复),但是架构是复杂的(编写各种接口类和封装类等)。我们在研究源码时,一定要先搞清楚目的。实现只不过是达到该目的的一种手段和方式。脱离目的而去研究实现,如缘木求鱼,很容易偏离事物本质。
来自:http://wenku.baidu.com/view/4186490690c69ec3d5bb753a.html
在上面这些可供选择的方式中,Android使用得最多也最被认可的还是Binder机制。
为什么会选择Binder来作为进程之间的通信机制呢?因为Binder更加简洁和快速,消耗的内存资源更小吗?
不错,这些也正是Binder的优点。
当然,也还有很多其他原因,比如传统的进程间通信可能会增加进程的开销,而且有进程过载和安全漏洞等方面的风险,Binder正好能解决和避免这些问题。
Binder主要能提供以下一些功能:
用驱动程序来推进进程间的通信。
通过共享内存来提高性能。
为进程请求分配每个进程的线程池。
针对系统中的对象引入了引用计数和跨进程的对象引用映射。
进程间同步调用。
Android Binder设计与实现 – 设计篇:
目前linux支持的IPC包括传统的管道、System V IPC、即消息队列/共享内存/信号量,以及socket中只有socket支持Client-Server的通信方式。
当然也可以在这些底层机制上架设一套协议来实现Client-Server通信,但这样增加了系统的复杂性,在手机这种条件复杂,资源稀缺的环境下可靠性也难以保证。
另一方面是传输性能:
socket作为一款通用接口,其传输效率低,开销大,主要用在跨网络的进程间通信和本机上进程间的低速通信。
消息队列和管道采用存储-转发方式,即数据先从发送方缓存区拷贝到内核开辟的缓存区中,然后再从内核缓存区拷贝到接收方缓存区,
至少有两次拷贝过程。共享内存虽然无需拷贝,但控制复杂,难以使用。
表 1 各种IPC方式数据拷贝次数
IPC | 数据拷贝次数 |
共享内存 | 0 |
Binder | 1 |
Socket/管道/消息队列 | 2 |
Android作为一个开放式,拥有众多开发者的平台,应用程序的来源广泛,确保智能终端的安全是非常重要的。
终端用户不希望从网上下载的程序在不知情的情况下偷窥隐私数据,连接无线网络,长期操作底层设备导致电池很快耗尽等等。传统IPC没有任何
安全措施,完全依赖上层协议来确保。首先传统IPC的接收方无法获得对方进程可靠的UID/PID(用户ID/进程ID),从而无法鉴别对方身份。
Android为每个安装好的应用程序分配了自己的UID,故进程的UID是鉴别进程身份的重要标志。使用传统IPC只能由用户在数据包里填入UID/PID,
但这样不可靠,容易被恶意程序利用。可靠的身份标记只有由IPC机制本身在内核中添加。其次传统IPC访问接入点是开放的,无法建立私有通道。
比如命名管道的名称、system V的键值、socket的ip地址或文件名都是开放的,只要知道这些接入点的程序都可以和对端建立连接,不管怎样都无法
阻止恶意程序通过猜测接收方地址获得连接。
基于以上原因,Android需要建立一套新的IPC机制来满足系统对通信方式,传输性能和安全性的要求,这就是Binder。
Binder基于 Client-Server通信模式,传输过程只需一次拷贝,为发送发添加UID/PID身份,既支持实名Binder也支持匿名Binder,安全性高。
面向对象的 Binder IPC:
面向对象思想的引入将进程间通信转化为通过对某个Binder对象的引用调用该对象的方法,而其独特之处在于Binder对象是一个
可以跨进程引用的对象,它的实体位于一个进程中,而它的引用却遍布于系统的各个进程之中。最诱人的是,这个引用和java里引用
一样既可以是强类型,也可以是弱类型,而且可以从一个进程传给其它进程,让大家都能访问同一Server,就像将一个对象或引用赋
值给另一个引用一样。Binder模糊了进程边界,淡化了进程间通信过程,整个系统仿佛运行于同一个面向对象的程序之中。
面向对象只是针对应用程序而言,对于Binder驱动和内核其它模块一样使用C语言实现,没有类和对象的概念。
Binder驱动为面向对象的进程间通信提供底层支持。
》关于Binder架构:
从架构的角度看,在Java中搭建了一整套框架,如IBinder接口、Binder类和BinderProxy类。但是从通信角度看,架构的编写不论采用的是Native语言还是Java语言,只要把请求传递到Binder驱动就可以了,所以通信的目的是向binder发送请求和接收回复。在这个目的之上,考虑到软件的灵活性和可扩展性,于是编写了一个架构。反过来说,也可以不使用架构(即没有使用任何接口、派生之类的东西)而直接和binder交互,例如,ServiceManager作为Binder架构的一个核心程序,就是直接读取/dev/binder设备,获取并处理请求。从这一点上看,Binder架构的目的虽是简单的(即打开binder设备,然后读请求和写回复),但是架构是复杂的(编写各种接口类和封装类等)。我们在研究源码时,一定要先搞清楚目的。实现只不过是达到该目的的一种手段和方式。脱离目的而去研究实现,如缘木求鱼,很容易偏离事物本质。
来自:http://wenku.baidu.com/view/4186490690c69ec3d5bb753a.html
相关文章推荐
- Android 6.0 fork Zygote时的存储权限管理
- 用Android代码实现打开USB调试
- 隐藏APK在Launcher中的启动图标 android开发教程
- 安装Android模拟器Genymotion【Android学习入门】
- 编译android源码
- Android Binder IPC分析
- Android 获取SD卡路径和判断SD卡是否存在.
- android Mp3播放器之音频文件扫描
- Android Gradle插件用户指南(转载)
- Android开发10——Activity的跳转与传值
- Android-使用XML布局文件实现游戏的开始界面
- Android Studio 插件--Findbugs
- Android 知识点
- 引入其他项目做为module之后,在编译时候提示“Error:Dependency Android_2015:projLib:unspecified on project projAPK resol”
- Android中的进程和线程
- android中修改framework层代码后怎样操作才能看到修改后的效果?
- 使用Android Studio阅读整个Android源码
- android txt文件名listview item 点击并传值
- android扫描sd卡下的所有.txt 并获取路径
- 从技术到产品,转型的这一年我明白了很多道理