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的存在，因此也无需关心它。