AndroidBinderIPC分析1．binder通信概述binder通信是一种client-server的通信结构，1.从表面上来看，是client通过获得一个server的代理接口，对server进行直接调用；2.实际上，代理接口中定义的方法与server中定义的方法是一一对应的；3.client调用某个代理接口中的方法时，代理接口的方法会将client传递的参数打包成为Parcel对象；4.代理接口将该Parcel发送给内核中的binderdriver.5.server会读取binderdriver中的请求数据，如果是发送给自己的，解包Parcel对象，处理并将结果返回；6.整个的调用过程是一个同步过程，在server处理的时候，client会block住。2．servicemanagerServiceManager是一个linux级的进程,顾名思义，就是service的管理器。这里的service是什么概念呢？这里的service的概念和init过程中init.rc中的service是不同，init.rc中的service是都是linux进程，但是这里的service它并不一定是一个进程，也就是说可能一个或多个service属于同一个linux进程。在这篇文章中不加特殊说明均指androidnative端的service。任何service在被使用之前，均要向SM(ServiceManager)注册，同时客户端需要访问某个service时，应该首先向SM查询是否存在该服务。如果SM存在这个service，那么会将该service的handle返回给client，handle是每个service的唯一标识符。SM的入口函数在service_manager.c中，下面是SM的代码部分intmain(intargc,char**argv){structbinder_state*bs;void*svcmgr=BINDER_SERVICE_MANAGER;bs=binder_open(128*1024);if(binder_become_context_manager(bs)){LOGE("cannotbecomecontextmanager(%s)/n",strerror(errno));return-1;}svcmgr_handle=svcmgr;binder_loop(bs,svcmgr_handler);return0;}这个进程的主要工作如下：1.初始化binder，打开/dev/binder设备；在内存中为binder映射128K字节空间；2.指定SM对应的代理binder的handle为0，当client尝试与SM通信时，需要创建一个handle为0的代理binder，这里的代理binder其实就是第一节中描述的那个代理接口；3.通知binderdriver(BD)使SM成为BD的contextmanager；4.维护一个死循环，在这个死循环中，不停地去读内核中binderdriver，查看是否有可读的内容；即是否有对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．ProcessStateProcessState是以单例模式设计的。每个进程在使用binder机制通信时，均需要维护一个ProcessState实例来描述当前进程在binder通信时的binder状态。ProcessState有如下2个主要功能：1.创建一个thread,该线程负责与内核中的binder模块进行通信，称该线程为Poolthread；2.为指定的handle创建一个BpBinder对象，并管理该进程中所有的BpBinder对象。3.1Poolthread在BinderIPC中，所有进程均会启动一个thread来负责与BD来直接通信，也就是不停的读写BD，这个线程的实现主体是一个IPCThread