android核心分析(三)

IPC

 

  • IPC,进程间通信,这是属于比较底层的东西,属于Linux底层的实现。
  • 四大核心组件都是工作在一定的进程或者线程的上下文之中,他们之间通信需要底层的IPC的支持。
  • 采用的是COBAR的架构,客户服务模型,中间插入代理。客户端一个proxy,服务端一个native的代理。客户端需要穿过这两个代理才能达到真正的服务。
  • 在服务管理器中有一个服务是管理其他的服务的,其id号为0。所有的服务性成列表,每一项包含了服务的名字和一个handler,handler可能是一个服务程序的入口函数的地址,当然,也可能是和一个入口函数的地址对应。
  • 请求一个服务的时候要经过两次和服务管理器进行交互,第一次传递参数0,表示请求id号为0的服务,这个服务将会check请求的服务x是否存在,如果存在,则返回相关的信息。第二次,才是请求服务x为客户端服务。这时,在服务端,服务x将提供服务。
  • Binder在这里充当了一个IPC请求的封装,上层看不到这些底层实现的细节,事实上,上层并不关心这些细节。客户端要做的就是发起服务请求,然后得到服务的结果。
  • Binder建立了客户端和服务端通信的几个通道。在Linux中,Binder实现为一个driver,放在driver目录下。打开一个binder,写入数据,从binder读取数据,通信就完成了。这一点和socket很像。所以说binder是一个抽象的通信接口。
  • Binder对于app也不可见,单从程序的角度,应用看不到Binder的存在,因此也无需关心它。
posted @ 2012-02-26 12:08  爱心觉罗氏  阅读(220)  评论(0编辑  收藏  举报