Android Binder IPC分析.docVIP

Android Binder IPC分析 1 ．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 会block 住。      2 ．service manager Service Manager 是一个linux 级的进程, 顾名思义，就是service 的管理器。这里的service 是什么概念呢？这里的service 的概念和init 过程中init.rc 中的service 是不同，init.rc 中的service 是都是linux 进程，但是这里的service 它并不一定是一个进程，也就是说可能一个或多个service 属于同一个linux 进程。在这篇文章中不加特殊说明均指android native 端的service 。任何service 在被使用之前，均要向SM(Service Manager) 注册，同时客户端需要访问某个service 时，应该首先向SM 查询是否存在该服务。如果SM 存在这个service ，那么会将该service 的handle 返回给client ，handle 是每个service 的唯一标识符。       SM 的入口函数在service_manager.c 中，下面是SM 的代码部分int main(int argc, char **argv){    struct binder_state *bs;    void *svcmgr = BINDER_SERVICE_MANAGER;     bs = binder_open(128*1024);     if (binder_become_context_manager(bs)) {        LOGE(cannot become context manager (%s)/n, strerror(errno));        return -1;    }     svcmgr_handle = svcmgr;    binder_loop(bs, svcmgr_handler);    return 0;}这个进程的主要工作如下：    1. 初始化binder ，打开/dev/binder 设备；在内存中为binder 映射128K 字节空间；    2. 指定SM 对应的代理binder 的handle 为0 ，当client 尝试与SM 通信时，需要创建一个handle 为0 的代理binder ，这里的代理binder 其实就是第一节中描述的那个代理接口；3. 通知binder driver(BD) 使SM 成为BD 的context manager ；4. 维护一个死循环，在这个死循环中，不停地去读内核中binder driver ，查看是否有可读的内容；即是否有对service 的操作要求, 如果有，则调用svcmgr_handler 回调来处理请求的操作。5.SM 维护了一个svclist 列表来存储service 的信息。    这里需要声明一下，当service 在向SM 注册时，该service 就是一个client ，而SM 则作为了server 。而某个进程需要与service 通信时，此时这个进程为client ，service 才作为server 。因此service 不一定为server ，有时它也是作为client 存在的。 由于下面几节会介绍一些与binder 通信相关的几个概念，所以将SM 的功能介绍放在了后面的部分来讲。 应用和service 之间的通信会涉及到2 次 binder 通信。 1. 应用向SM 查询service 是否存在，如果存在获得该service 的代理binder ，此为一次binder 通信；2. 应用通过代理binder 调用service 的方法，此为第二次binder 通信。 3 ．P