简单理解Binder机制的原理
一、概述
Android系统中涉及到多进程通信底层都是依赖Binder IPC机制。例如当进程A中的Activity想要向进程B的Service通信,这就需要用到IPC。不仅如此,整个Android系统架构中,大量采用了Binder机制作为IPC(进程间通信)方案。
当然也存在其他的通信方式,如管道、消息队列、socket、内存共享、SystemV等。那为什么Android不使用这些原有的技术,而要开发一种新的Binder的进程间通信机制呢?
为什么要使用Binder?
性能方面
在移动设备上(性能受限制设备上,如省电),广泛的使用跨进程通信对通信机制的性能有严格的要求,Binder相比于传统的Socket方式,更高效。Binder数据拷贝只需要一次,而管道、消息队列、Socket都需要两次,共享内存一次都不需要拷贝,但实现方式又比较复杂。
安全方面
传统的进程通信方式对于通信双方身份并没有做出严格的验证,比如Socket通信的ip地址就是用户手动的填入的,很容易进行伪造,而Binder通信机制从协议本身就支持对通信双方做身份验证,大大提高了安全性。
二、Binder
要想了解Binder,首先先了解下Linux内核的基础知识:
(1)用户空间/内核空间:
用户空间指的是用户程序运行的空间,内核空间是Linux内核的运行空间,为了安全,它们是隔离的,即使用户的程序崩溃了,内核也是不受影响的。
(2)系统调用:
Linux将用户空间和内核空间隔离是有原因的,用户软件良莠不齐,要是它们乱搞,把系统搞坏了怎么办?因此对于某些特权操作必须放到内核中进行。
用户空间访问内核空间的唯一方式就是系统调用;通过这个统一入口接口,所有的资源访问都是在内核的控制下执行,以免导致用户程序对资源的越权访问,从而系统的安全和稳定性。
(3)Binder驱动:
通过系统调用,用户空间可以访问内核空间,那么如果一个用户空间想与另一个空间进行通信怎么办呢?很自然想到的是让操作系统内核添加支持;传统的Linux通信机制,比如Socket,管道等都是内和支持的;但是Binder并不是Linux内核的一部分,它是怎么做到访问内核空间的呢?
Linux的动态可加载内核模块(Loadable Kernel Mondule)解决了这个问题;模块是具有独立功能的程序,它只能被单独编译,不能独立运行。它在运行时被链接到内核作为内核的一部分在内核空间运行。这样,Android系统可以通过添加一个内核模块运行在内核空间,用户进程之间通过这个模块作为桥梁,就可以完成通信。
在Android系统中,这个运行在内核空间,负责各个用户进程通过Binder通信的内核模块叫做Binder驱动。
Binder
IPC原理
从进程角度来看IPC机制
每个Android的进程,只能运行在自己进程所拥有的的虚拟地址空间。对应一个4GB的虚拟地址空间,其中3GB是用户空间,1GB是内核空间,当然内核空间的大小是可以通过参数配置调整的。对于用户空间,不同进程之间彼此是不能共享的,而内核空间却是共享的。Client进程向Server进程通信。恰恰是利用进程间可共享的内核内存空间来完成底层通信工作的,Client端与Server端进程往往采用ioctl等方法跟内核空间的驱动进行交互。
Binder原理
Binder通信采用C/S结构,从组件视角来说,包含Client、Server、ServiceManager以及Binder驱动,其中ServiceManager用于管理系统中的各种服务,架构图如下所示:
Binder通信的四个角色:
Client进程:使用服务的进程。
Server进程:提供服务的进程。
ServiceManager进程:ServiceManager的作用是将字符形式的Binder名字转化成Client中对该Binder的引用,使得Client能够通过Binder名字获得对Server中Binder实体的引用。
Binder驱动:
驱动负责进程间Binder通信的建立,Binder在进程间的传递,Binder引用计数管理,数据包在进程间的传递与交互等一系列底层支持。
Binder运行机制:
图中Client/Server/ServiceManager之间的相互通信都是基于Binder机制。既然基于Binder机制通信,那么同样也是C/S结构。则图中的3大步骤都有相应的Client端与Service端。
注册服务:Server进程要先注册Service到 ServiceManager。该过程:Server是客户端,ServiceManager是服务端。
获取服务:Client进程使用某个Service前,须先向ServiceManager中获取相应的Service。该过程:Client是客户端,ServiceManaer是服务端。
使用服务:Client根据得到的Service信息建立与Service所在Service进程通信的道路,然后就可以直接与Service交互。该过程:Client是客户端,Server是服务端。
图中的Client,Server,ServiceManager之间交互都是虚线表示,是由于它们彼此之间不是直接交互的,而是通过与Binder驱动进行交互的,从而实现IPC通信方式。其中Binder驱动位于内核空间,Client,Server,ServiceManager位于用户空间。Binder驱动和Service Manager可以看做是Android平台的基础架构,而Client和Server是Android的应用层,开发人员只需自定义实现Client端、Server端,借助Android的基本平台架构便可以直接进行IPC通信。
Binder运行的实例解释
首先我们看看我们的程序跨进程调用系统服务的简单实例,实现浮动窗口部分代码:
//获取WindowManager服务引用
WindowManager wm = (WindowManager)getSystemService(getApplication().WINDOW_SERVICE);
//布局参数layoutParams相关设置略...
View view=LayoutInflater.from(getApplication()).inflate(R.layout.float_layout, null);
//添加view
wm.addView(view, layoutParams);
注册服务:
在Android开机启动过程中,Android会初始化系统的各种Service,并将这些Service向ServiceManager注册(即让ServiceManager管理)。这一步是系统自动完成的。
获取服务:客户端想要得到具体的Service直接向ServiceManager要即可。客户端首先向ServiceManager查询得到具体的Service引用,通常是Service引用的代理对象,对数据进行一些处理操作。即第二行代码中,得到的wmWindowManager对象的引用。
使用服务:通过这个引用向具体的服务端发送请求,服务端执行完成后就返回。即第6行调用WindowManager的addView函数,将触发远程调用,调用的是运行在systemServer进程中的WindowManager的addView函数。
使用服务的具体执行过程
1.Client通过获得一个server的代理借口,对server进行调用。
2.代理接口中定义的方法与Server中定义的方法是一一对应的。
3.client调用某个代理接口中的方法时,代理接口的方法会将client传递的参数打包成Parcel对象。
4.代理接口将Parcel发送给内核中的binder driver。
5.server会读取binder driver中的请求数据,如果是发送给自己的,解包Parcel对象,处理并将结果返回。
6.整个的调用过程是一个同步过程,在server处理的时候,client会block住。因此client调用过程不应在主线程。
以上就是Binder机制原理的简单介绍,后面以后会以AIDL来具体介绍Binder机制的使用,加深对其的了解。
原文链接:
https://www.jianshu.com/p/4920c7781afe
上一篇: 【汇编语言与计算机系统结构笔记12】序格式与伪操作:简化段的定义、操作符等
下一篇: suse linux +cognos 10+ db2 9.7 【64位】【安装布署记录】 博客分类: BI cognos liunx 布署
推荐阅读
-
简单理解Binder机制的原理
-
这一次,binder真正理解了(五) ----- Binder中Service的查询(获取)
-
Android Binder机制(三) Binder相关的接口和类
-
这一次,binder真正理解了(一) -----跨进程通信以及AIDL的使用
-
HashMap为什么这么快? ---深入理解HashMap的散列机制
-
【C++】C++中的&(引用)的简单理解
-
你真的理解__block修饰符的原理么?
-
搭建一个简单的redis-sentinel(哨兵机制)集群
-
MapReduce原理(3): MapReduce的分片机制 getSplits()方法 源码解析
-
99%的程序员都在用Lombok,原理竟然这么简单?我也手撸了一个!