关于Android Binder机制

    binder通信是一种client-server的通信结构，从表面看，是client通过获得一个server的代理接口，对server进行直接调用，实际上，代理接口中定义的方法与server中定义的方法是一一对应，client调用某个代理接口中的方法时，代理接口的方法会将client传递的参数打包成为Parcel对象，代理接口将该parcel发送给内核中的binder driver，server会读取binder driver中的请求数据，如果是发送给自己的，解包parcel对象，处理并将结果返回，整个的调用过程是一个同步的过程，在server处理的时候，client会block住。

    service manager是一个Linux级的进程，顾名思义，就是service的管理器，这里的service的概念和init过程中init.rc中的service是不同，init.rc中的service都是Linux进程，但是这里的service他并不一定是一个进程，也就是说可能一个或多个service属于同一个Linux进程，这里指Android native端的service，任何service在被使用之前，都要向SM注册，同时客户端需要访问某个service时，应该首先向SM查询是否存在该服务，如果SM存在这个service，那么会将该service的handle返回给client，handle是每个service的唯一标识符。这里进程的主要工作是：初始化binder，打开/dev/binder设备，在内存中为binder映射128K字节空间；指定SM对应的代理binder的handle为0，当client尝试与SM通信时，需要创建一个handle为0的代理binder，这里的代理binder其实就是上边描述的代理接口；通知binder driver使得SM成为BD的context manager；维护一个死循环，在这个死循环中，不停的去读取内核中binder driver，查看是否有可读的内容，即是否有对service的操作要求，如果有，则调用svcmgr_handler回调来处理请求的操作；SM维护了一个svclist列表来存储service的信息。

    当service在向SM注册时，该service就是一个client，而SM则作为了server，而某个进程需要与service通信时，此刻这个进程为client，service才作为server，因此service不一定为server，有时他也是作为client存在的。

应用和service之间的通信会涉及到2次binder通信：1.应用向SM查询service是否存在，如果存在获得该service的代理binder，此为一次binder通信；2.应用通过代理binder调用service的方法，此为第二次binder通信。