你的位置:首页 > 操作系统

[操作系统]Android进程间通讯


最近研究了一下Android进程间通讯,原来只是会用,但是只是会用是不行滴,就来研究一下。

刚开始看的时候,我的头是这么大,看了一夜的时候,头就变成这样了,,吓得宝宝赶紧上床休息了,、

先喝喝茶讲个故事再来说这个通讯。

(写完之后,看到这个终于承认了自己写作的能力很烂,但是好歹也是自己一个一个敲上去的,不能白白辛苦啊,嘿嘿)

-----------------------------------------------------------------------------------------------------------------

  话说我有一哥们,最近他前女友来找他复合,但是他现在有女友,所以很是烦恼,整天吃不好睡不着,所以他打算问问上帝有什么好主意,可是为了安全起见,他又不能直接去找上帝,总不能一天死个5,6次吧,人生是没有bug的。那怎么办呢,幸好这世上还有一种生物叫神父,然后他就去找神父。

“father ,我最近很烦恼,你可以帮我问问上帝该怎么办吗”

“oh my son 上帝是万能的,他可以帮我们解决任何问题,有什么就说吧”

“我现在有女朋友了,可是我的前女友最近又来找我复合,两个都对我很好,我该怎么办呢。。。。。(此处省略N多字)”

神父把上帝从睡梦中喊醒“上帝啊,这人有病啊,有两个女的都喜欢他,直接收了不就完了,他还在纠结该选那个,您看这个怎么办才好呢”

“哦,这件事我知道,他不是有个好朋友叫杨XX吗,我已经施法让他的前女友喜欢上杨XX了,哈哈”

“son,上帝已经施法让你的前女友喜欢上了别人,是你的一个好朋友杨XX,你看这样好不”

。。。。。。。。。。

情景转到篮球场,我正在一群少女的欢呼中挥洒魅力,突然被一个手臂一拉。

“XX,你知道我最近很烦心的那个事吗?”

我正因为被他从少女的崇拜中打搅不爽“不就是那个前女友吗,怎么了”

“哈哈,我今天去找上帝,上帝已经帮我解决了”

“哦,怎么解决的,看你高兴的”

“上帝施法让我的前女友喜欢你了”

我眼前一黑,一口心血喷出“上帝,卧槽你X“

我的女友是跆拳道黑带三段。

---------------------------------------------------------------------------------------------------------------

(我又看了一遍,这个故事的确有点扯。。。。)


好了,忘掉吧,你可能会感到这个故事跟进程间通讯半毛钱关系没有,但我感觉还是挺好的。。

Android进程间通讯,

  为什么不能直接跨进程进行通讯啊?

    • 因为,为了安全考虑。Android系统中,应用所在的内存是独立的,无法相互访问,各个应用的数据都在自己的内存中。

  那么如何跨进程进行通讯呢?

    • 要想跨进程,必须找一个公共的大家都能访问的地方,通过暗号来达到通讯的目的。

  Android中的跨进程通讯采用的是binder机制。

  那么什么是binder呢,这个工作原理是什么呢,

  Binder呢,其实就是一块内存,它在Linux层面属于一个驱动,但是这个驱动不是驱动硬件,而是驱动一块内存。不同的应用通过对一块公共的内存进行数据的读写,来达到通讯的目的。而且应用之间进行通讯,

必须要有暗号(没有暗号就成了火锅,乱套了!),当两个应用持有相同的暗号(AIDL时),才可以进行通讯。

知道了为什么跨,怎么跨,那么具体步骤怎么写呢?

  由于不是本文重点,请看官方开发文档,现在开发文档越来越详细,估计人家美国12岁的小学生都能随便开发一个简单的应用。唉 英语啊。

知道了以上这些东西,可是binder是怎么工作的,却还不知道,接下来为大家介绍一下binder的工作原理。

  在Android系统中的binder机制中,分别由Client,Server,ServiceManager和Binder驱动程序组成,其中Client、Server和Service Manager运行在用户空间,Binder驱动程序运行内核空间。Binder驱动程序是核

心组件, Service Manager是一个守护进程,用来管理Server,并向Client提供查询Server接口的功能,开发者只需要在用户空间实现自己的Client和Server即可。而Client和Server正是在Binder驱动和ServiceManager提供的基础设施上,进行通信的。

  binder工作原理:

binder通信是一种client-server的通信结构,

    1.从表面上来看,是client通过获得一个server的代理接口,对server进行直接调用;

    2.实际上,代理接口中定义的方法与server中定义的方法是一一对应的;

    3.client调用某个代理接口中的方法时,代理接口的方法会将client传递的参数打包成为Parcel对象;

    4.代理接口将该Parcel发送给内核中的binder driver.

    5.server会读取binder driver中的请求数据,如果是发送给自己的,解包Parcel对象,处理并将结果返回;

 6.整个的调用过程是一个同步过程,在server处理的时候,client会阻塞

直接看不好理解,还好有图。

  前面已经说过,Service Manager组件是用来管理Server并且向Client提供查询Server远程接口的功能,那么,Service Manager就必然要和Server以及Client进行通信了。然而,Service Manager、Client和

Server三者分别是运行在独立的进程当中,这样它们之间的通信也属于进程间通信了,而且也是采用Binder机制进行进程间通信,因此,ServiceManager在充当Binder机制的守护进程的角色的同时,也在充当Server

的角色,也就是说,它是一种特殊的Server。

   其实在平时开发中,系统服务就是通过Binder机制来和应用通讯的,接下来为大家详细解释一下系统服务和应用通讯流程,以帮助大家更容易深刻的理解binder机制。

  系统服务和应用的通信机制

 

系统服务:

  1.是一个Binder类的子类,一旦创建后,就开启一个线程死循环用来检测某段内存是否有数据写入。

  2.它自身创建时,创建一个xxxRemote远程对象,存放到Binder驱动中,xxxRemote远程对象可以和xxxService系统服务通信

应用端:

  通过context. getSystemService获取xxxServiceProxy对象,该对象内部引用了xxxRemote对象, xxxServiceProxy和xxxService具有相同的API,我们调用xxxServiceProxy时,xxxServiceProxy就调用

xxxRemote并等待xxxRemote返回。xxxRemote会往某段内存中写入数据,写完后就开始监视该内存区域,Binder驱动会把xxxRemote写入的数据拷贝到xxxService监视着的内存区域,当xxxService一旦发现有数

据,就读取并进行处理,处理完毕后,就写入该区域,这时Binder驱动又会把该数据拷贝到xxxRemote监视的内存区域,当xxxRemote发现内存区域有数据读取该区域数据,并把内容返回给xxxServiceProxy。这样

就完成了一次进程间的通信。

  所以一个系统服务会产生两个Binder对象,一个是运行在系统中的系统服务本身,一个是存放到Binder驱动中的远程对象。所不同的是系统服务Binder对象会开启一个线程监听消息,远程对象不会,它是运行在

调用者的线程中。

  客户端也可以不使用系统服务的远程Binder对象,而是自己创建一个Binder对象,通过Binder驱动和系统服务进行关联,这样的好处客户端可以随时通知系统服务,系统服务也可以随时通知客户端,而不是像上

面所说的系统服务只能被动的等着客户端调用。

 

那么binder内部是怎么操作的

  Binder对象都有各自的内存区域,当Binder1想要向Binder2发送数据时,就会把数据写入自己的内存区域,然后通知Binder驱动,Binder驱动会把数据拷贝到Binder2的内存区

域,然后通知Binder2进行读取,Binder2读取完毕后,将把数据写入binder2的内存区域,然后通知Binder驱动,Binder驱动将会把数据拷贝到Binder1的内存区域中。这样就完成

了一次通信。

  如果Binder1是系统服务,Binder2是系统服务的远程对象,这样任何应用程序在获取了Binder2的引用后,都可以和Binder1进行通信。但是缺点也很明显,只能由应用端请求

系统服务,系统服务不能主动去联系应用端。WifiManagerService之类的就是采用这种方式。

   还有一种方式是Binder1是系统服务,Binder2是应用端创建的Binder对象,他们两者通过Binder驱动进行连接后,应用端可以主动调系统服务,系统服务也可以主动调用应用

端。WindowManagerService就是采用的这种方式。

 我是看了很多资料才写出的这篇博客,大家有兴趣可以去看看http://blog.csdn.net/luoshengyang/article/details/6618363#comments的博客,的确大牛。