Android系统源码分析-进程间通信机制binder(一)：守护进程servicemanager

1.简介：

在上一篇（Android系统源码分析-从init进程开始 ）中，我们已经看到，servicemanager是init进程通过init.rc的service指令来启动的守护进程。用linux的ps命令也可以看到servicemanager进程是init进程的子进程。那么，这个进程的作用是什么？他的初始化过程又是怎样被执行的？本节我们一起来分析一下。

Binder源码分析系列文章：

Android系统源码分析-进程间通信机制binder(一)：守护进程servicemanager

Android系统源码分析-进程间通信机制binder(二)：binder内存映射

Android系统源码分析-进程间通信机制binder(三)：从framework层到Native层

Android系统源码分析-进程间通信机制binder(四)：从Native层到Driver层

2.servicemanager进程的作用-Android进程间通信的基石：

 Android系统是基于Linux系统的，从进程的角度来说，Android继承了Linux的进程间通信机制，例如共享内存，信号量，管道，socket等，除此之外，Android系统的最大特点之一就是提供了独有的进程间通信机制，即binder机制。而servicemanager进程正是支持binder机制的基石。

在应用开发时，经常通过mContext.getSystemService（xxx）来获取一个系统服务，其实，在Android系统底层（kernel之上），就是通过servicemanager进程来获取的这个服务。例如，

获取输入法服务的代码如下：

(InputMethodManager) mContext.getSystemService(Context.INPUT_METHOD_SERVICE);

servicemanager进程的作用：

servicemanger提供了注册服务，查询服务等功能。

3.servicemanager进程的代码分析（初始化）：

 在代码分析过程中，主要从一下几个角度去看待：

初始化流程

注册一个service的流程

binder的底层数据存储结构

servicemanager进程的代码位置：

servicemanager进程是一个守护进程，核心代码都是用c语言编写的，代码目录是：

frameworks/base/cmds/servicemanager

代码：

3.1从service_manager.c文件的main函数开始开始

service_manager.c文件的main韩式是整个进程的入口函数。代码如下：

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)) {
        ALOGE("cannot become context manager (%s)\n", strerror(errno));
        return -1;
    }

    svcmgr_handle = svcmgr;
    binder_loop(bs, svcmgr_handler);
    return 0;
}

可以看到，仅仅十几行代码，看起来也非常精美。

代码分析：

1. BINDER_SERVICE_MANAGER的值的定义（在binder.h）如下：

#define BINDER_SERVICE_MANAGER ((void*) 0)

这个值有什么意义呢？

每一个service都需要注册到servicemanager中，都对应有一个handler，这些service就是通过这个handler来区分的。而servicemanager本省也是一个service，它的handler是0，即BINDER_SERVICE_MANAGER。要查找一个service，都是从servicemanager开始进行查询。

2. binder_open(128*1024)

非常重要的一个函数。这个函数主要功能就是初始化binder。即打开binder驱动并且映射到一块128*1024大小的内存中。

binder_open的代码如下：

在binder.c中：

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);
    if (bs->fd < 0) {
        fprintf(stderr,"binder: cannot open device (%s)\n",
                strerror(errno));
        goto fail_open;
    }

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

分析：

1）. bs->fd = open("/dev/binder", O_RDWR);

打开 了驱动/dev/binder。可以看出，原理binder最底层是有一个/dev/binder存在的。

2）. mmap：通过mmap系统调用把/dev/binder映射在一块内存中，大小就是128*1024byters。

3）.返回的是 struct binder_state 类型的一个指针，这个结构体中保存了binder驱动的文件句柄，内存映射大小，以及这块内存区域的地址等。

struct binder_state的定义：

struct binder_state
{
    int fd;
    void *mapped;
    unsigned mapsize;
};

 另外一个非常重要的数据结构是：struct svcinfo

struct svcinfo 
{
    struct svcinfo *next;
    void *ptr;
    struct binder_death death;
    int allow_isolated;
    unsigned len;
    uint16_t name[0];
};

这是一个列表，存放的就是所有注册的service。

通过这个列表就能遍历到所有的service。 

3. binder_become_context_manager函数：

int binder_become_context_manager(struct binder_state *bs)
{
    return ioctl(bs->fd, BINDER_SET_CONTEXT_MGR, 0);
}

分析：

通过ioctl servicemanaer就成为了service的服务管理者。

4.binder_loop函数：

void binder_loop(struct binder_state *bs, binder_handler func)
{
    int res;
    struct binder_write_read bwr;
    unsigned readbuf[32];

    bwr.write_size = 0;
    bwr.write_consumed = 0;
    bwr.write_buffer = 0;
    
    readbuf[0] = BC_ENTER_LOOPER;
    binder_write(bs, readbuf, sizeof(unsigned));

    for (;;) {
        bwr.read_size = sizeof(readbuf);
        bwr.read_consumed = 0;
        bwr.read_buffer = (unsigned) readbuf;

        res = ioctl(bs->fd, BINDER_WRITE_READ, &bwr);

        if (res < 0) {
            ALOGE("binder_loop: ioctl failed (%s)\n", strerror(errno));
            break;
        }

        res = binder_parse(bs, 0, readbuf, bwr.read_consumed, func);
        if (res == 0) {
            ALOGE("binder_loop: unexpected reply?!\n");
            break;
        }
        if (res < 0) {
            ALOGE("binder_loop: io error %d %s\n", res, strerror(errno));
            break;
        }
    }
}

 分析：

在loop中，不停地通过ioctl对/dev/binder驱动进行访问，

readbuf用于存储读取到的消息数据；

BINDER_WRITE_READ用于读取消息数据。

然后，再进行解析，即

        res = binder_parse(bs, 0, readbuf, bwr.read_consumed, func);

再看binder_parse是如何工作的：

int binder_parse(struct binder_state *bs, struct binder_io *bio,
                 uint32_t *ptr, uint32_t size, binder_handler func)
{
    int r = 1;
    uint32_t *end = ptr + (size / 4);

    while (ptr < end) {
        uint32_t cmd = *ptr++;
#if TRACE
        fprintf(stderr,"%s:\n", cmd_name(cmd));
#endif
        switch(cmd) {
        case BR_NOOP:
            break;
        case BR_TRANSACTION_COMPLETE:
            break;
        case BR_INCREFS:
        case BR_ACQUIRE:
        case BR_RELEASE:
        case BR_DECREFS:
#if TRACE
            fprintf(stderr,"  %08x %08x\n", ptr[0], ptr[1]);
#endif
            ptr += 2;
            break;
        case BR_TRANSACTION: {
            struct binder_txn *txn = (void *) ptr;
            if ((end - ptr) * sizeof(uint32_t) < sizeof(struct binder_txn)) {
                ALOGE("parse: txn too small!\n");
                return -1;
            }
            binder_dump_txn(txn);
            if (func) {
                unsigned rdata[256/4];
                struct binder_io msg;
                struct binder_io reply;
                int res;

                bio_init(&reply, rdata, sizeof(rdata), 4);
                bio_init_from_txn(&msg, txn);
                res = func(bs, txn, &msg, &reply);
                binder_send_reply(bs, &reply, txn->data, res);
            }
            ptr += sizeof(*txn) / sizeof(uint32_t);
            break;
        }
        case BR_REPLY: {
            struct binder_txn *txn = (void*) ptr;
            if ((end - ptr) * sizeof(uint32_t) < sizeof(struct binder_txn)) {
                ALOGE("parse: reply too small!\n");
                return -1;
            }
            binder_dump_txn(txn);
            if (bio) {
                bio_init_from_txn(bio, txn);
                bio = 0;
            } else {
                    /* todo FREE BUFFER */
            }
            ptr += (sizeof(*txn) / sizeof(uint32_t));
            r = 0;
            break;
        }
        case BR_DEAD_BINDER: {
            struct binder_death *death = (void*) *ptr++;
            death->func(bs, death->ptr);
            break;
        }
        case BR_FAILED_REPLY:
            r = -1;
            break;
        case BR_DEAD_REPLY:
            r = -1;
            break;
        default:
            ALOGE("parse: OOPS %d\n", cmd);
            return -1;
        }
    }

    return r;
}

 分析：

1）. 解析以BR开头的这些命令；

2）. 以case BR_TRANSACTION为例子：

        case BR_TRANSACTION: {
            ...
            res = func(bs, txn, &msg, &reply); //处理消息
            //返回处理结果
            inder_send_reply(bs, &reply, txn->data.ptr.buffer, res); 
            ...
            break;
        }

res = func(bs, txn, &msg, &reply);

作用：用于处理消息；func就是在前面已经注册的service的handler，可以认为是具体的service。通过func，就回调到了具体的service中的对应函数中。

inder_send_reply(bs, &reply, txn->data.ptr.buffer, res); ：

作用：返回处理结果。

4. 注册service：

在binder_loop中的第二个参数，即svcmgr_handler，

这个就是service的注册函数，具体代码如下：

int svcmgr_handler(struct binder_state *bs,
                   struct binder_txn *txn,
                   struct binder_io *msg,
                   struct binder_io *reply)
{
    struct svcinfo *si;
    uint16_t *s;
    unsigned len;
    void *ptr;
    uint32_t strict_policy;
    int allow_isolated;

//    ALOGI("target=%p code=%d pid=%d uid=%d\n",
//         txn->target, txn->code, txn->sender_pid, txn->sender_euid);

    if (txn->target != svcmgr_handle)
        return -1;

    // Equivalent to Parcel::enforceInterface(), reading the RPC
    // header with the strict mode policy mask and the interface name.
    // Note that we ignore the strict_policy and don't propagate it
    // further (since we do no outbound RPCs anyway).
    strict_policy = bio_get_uint32(msg);
    s = bio_get_string16(msg, &len);
    if ((len != (sizeof(svcmgr_id) / 2)) ||
        memcmp(svcmgr_id, s, sizeof(svcmgr_id))) {
        fprintf(stderr,"invalid id %s\n", str8(s));
        return -1;
    }

    switch(txn->code) {
    case SVC_MGR_GET_SERVICE:
    case SVC_MGR_CHECK_SERVICE:
        s = bio_get_string16(msg, &len);
        ptr = do_find_service(bs, s, len, txn->sender_euid);
        if (!ptr)
            break;
        bio_put_ref(reply, ptr);
        return 0;

    case SVC_MGR_ADD_SERVICE:
        s = bio_get_string16(msg, &len);
        ptr = bio_get_ref(msg);
        allow_isolated = bio_get_uint32(msg) ? 1 : 0;
        if (do_add_service(bs, s, len, ptr, txn->sender_euid, allow_isolated))
            return -1;
        break;

    case SVC_MGR_LIST_SERVICES: {
        unsigned n = bio_get_uint32(msg);

        si = svclist;
        while ((n-- > 0) && si)
            si = si->next;
        if (si) {
            bio_put_string16(reply, si->name);
            return 0;
        }
        return -1;
    }
    default:
        ALOGE("unknown code %d\n", txn->code);
        return -1;
    }

    bio_put_uint32(reply, 0);
    return 0;
}

 分析：

1）case SVC_MGR_ADD_SERVICE:的执行就是service的注册；

2）case SVC_MGR_CHECK_SERVICE:的执行就是service的查询；

3）case SVC_MGR_LIST_SERVICES:的执行就是列出所有service。

do_add_service函数：

如果已经注册了对应的service，就不再注册。否则，将新的节点添加到svclist中。

这样，整个servicemangar进程就初始化完成了。再总结一下：

打开binder驱动->注册servicemanager（handler为0）->binder loop。

---

Android进程间通信之binder，必须掌握的底层代码。