android framwork 分析之binder

   binder是用来实现进程间通信的，当两个进程需要通信时候比方说A进程需要使用B进程的服务 由于进程间的是不允许的 （他们分别运行在自己的用户空间），那怎么解决这个问题呢？

那就是利用binder驱动来中转了  binder驱动是运行在内核空间的 所有的进程共享！所以我们可以利用binder的中转来实现B进程的服务，怎么实现的呢 ？首先把B进程的服务可以共享给其他进程的功能注册到binder驱动中  当A进程要使用的时候 请求binder驱动程序执行相应的B进程服务的功能后返回给A 这就好像A也有了这样的功能了。

现在的关系是： A进程（client）  --> binder驱动  <--B 进程(service)；   

由于A进程或者B进程需要额外的专门来给binder驱动打交道 所以为何不搞一个代理来完成这样的事情呢？！于是关系就成这样了 ： A进程（client） --> 客户端代理 （proxy）--> binder驱动<--服务器代理(stub)  <--B 进程(service)；

现在A进程他还不够透明化 因为他知道要调用的是本地对象还是代理对象以及代理的一些方法  所以得搞个类manager来专门的负责这些调用代理的方法或者本地的方法 这样上层应用就不需要关心这些东西了 只需调用manager暴露的方法即可，比如我们常用的 获取一些服务的方法getServiceManager(xxx)获取一个manager对象，后面就直接调用manager中封装好的服务方法即可；所以现在的关系应该是这样的： A进程（client）-->封装好的代理服务(manager) --> 客户端代理 （proxy）--> binder驱动<--服务器代理(stub)  <--B 进程(service);

那最后还有个问题，当A需要调用B服务的时候 那前提使用获得该服务的manager或者proxy才可以呢，那怎么获取呢 ？这个时候servicemanager就出场了 他是init进程启动的（init进程是系统启动的第一个进程）所以他早就启动了；我们可以利用servicemanager来获取需要的服务B 当然B服务要先把自己注册到servicemanager中，那B是一个进程 而servicemanager也是一个进程 那又是一个进程间的通信了，那怎么办？也就是B服务怎么来获取servicemanager的proxy或者manager呢？由于servicemanager的特殊身份 ，这个manager我们可以直接拿到的！这样的话那B服务就可以注册到servicemanager中了，然后A进程直接从某处拿到servicemanager查询servicemanager中的B服务而调用它的功能了！

那首先来看看servicemanager这个类 他在frameworks/base/cmds/servicemanager目录下，先来看看main方法：

int main(int argc, char **argv)
{
    struct binder_state *bs;//结构体 里面有文件的描述符 映射的大小及地址
    void *svcmgr = BINDER_SERVICE_MANAGER;//宏定义 用来表示servicemanager的特殊之处


    bs = binder_open(128*1024);//打开binder文件


    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;
}

一进来就定义了个结构体：binder_state  那就来看看他的定义

struct binder_state
{
    int fd;//打开的/dev/binder设备文件描述符
    void *mapped;//设备文件/dev/binder映射到进程空间的起始地址
    unsigned mapsize;//内存映射空间的大小
};

再来看看这代码：void *svcmgr = BINDER_SERVICE_MANAGER;  这里BINDER_SERVICE_MANAGER是一个宏，定义frameworks/base/cmds/servicemanager/binder.h文件中  下面是他的宏定义：

/* the one magic object */
#define BINDER_SERVICE_MANAGER ((void*) 0)

这代表他的句柄是0 （句柄是用来标识远程接口的，由binder自动创建），其余的句柄都是大于0的 这就是刚才说的servicemanager的特殊之处

现在代码执行到： bs = binder_open(128*1024); 这表明打开一个binder文件了 看看他的代码实现：

struct binder_state *binder_open(unsigned mapsize)
{
    struct binder_state *bs;


    bs = malloc(sizeof(*bs));//分配内存
    if (!bs) {
        errno = ENOMEM;
        return 0;
    }


    bs->fd = open("/dev/binder", O_RDWR);//打开目标文件 /dev/binder
    if (bs->fd < 0) {
        fprintf(stderr,"binder: cannot open device (%s)\n",
                strerror(errno));
        goto fail_open;
    }


    bs->mapsize = mapsize;//给mapsize大小赋值
    bs->mapped = mmap(NULL, mapsize, PROT_READ, MAP_PRIVATE, bs->fd, 0);//赋值指向的地址值
    if (bs->mapped == MAP_FAILED) {
        fprintf(stderr,"binder: cannot map device (%s)\n",
                strerror(errno));
        goto fail_map;
    }


        /* TODO: check version */


    return bs;


fail_map:
    close(bs->fd);
fail_open:
    free(bs);
    return 0;

最后执行到binder_loop时候就一直循环等待！servicemanager的大概原理就是这样的 其中会涉及到内核驱动的 由于现在还不是很理解 所以暂时不去分析了！

一开始就提到了要请求服务的话 就得拿到servicemanager后才能获取相应的服务 那怎么拿到这个manager呢？刚才知道了servicemanager的句柄值是0 所以可以通过他来获取 ，获取Service Manager远程接口的函数是defaultServiceManager，这个函数声明在frameworks/base/include/binder/IServiceManager.h，实现在frameworks/base/libs/binder/IServiceManager.cpp 

sp<IServiceManager> defaultServiceManager()
{//单列模式
    if (gDefaultServiceManager != NULL) return gDefaultServiceManager;
    
    {
        AutoMutex _l(gDefaultServiceManagerLock);//锁保护
        if (gDefaultServiceManager == NULL) {
            gDefaultServiceManager = interface_cast<IServiceManager>(
                ProcessState::self()->getContextObject(NULL));
        }
    }
    
    return gDefaultServiceManager;
}