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的博客，的确大牛。