Android Framework：Binder全解析（完结篇）

作者: 唐唐_1388 | 来源:发表于2020-12-18 19:15 被阅读0次

作者

前言

在之前的篇章中，我们首先分析了如何注册服务，然后如何获取服务，最后是如何获取ServiceManager。那么问题来了，ServiceManager是如何被启动的呢？又是如何工作的呢？本篇将会从源码分析，一步一步的跟踪流程，分析ServiceManager是如何启动的。

启动过程

ServiceManager是Binder IPC通信过程中的守护进程，本身也是一个Binder服务。自行编写了binder.c直接和Binder驱动来通信，并且只有一个循环binder_loop来进行读取和处理事务，这样的好处是简单而高效。ServiceManager本身工作相对简单，其功能：查询和注册服务。对于Binder IPC通信过程中，其实更多的情形是BpBinder和BBinder之间的通信

ServiceManager是由init进程通过解析init.rc文件而创建的。

init进程是Linux系统中用户空间的第一个进程，进程号固定为1。Kernel启动后，在用户空间启动init进程，并调用init中的main()方法执行init进程的职责。对于init进程的功能分为4部分：

解析并运行所有的init.rc相关文件

根据rc文件，生成相应的设备驱动节点

处理子进程的终止(signal方式)

提供属性服务的功能

其所对应的可执行程序/system/bin/servicemanager，所对应的源文件是service_manager.c，进程名为/system/bin/servicemanager。

service servicemanager /system/bin/servicemanager
    class core
    user system
    group system
    critical
    onrestart restart healthd
    onrestart restart zygote
    onrestart restart media
    onrestart restart surfaceflinger
    onrestart restart drm

启动Service Manager的入口函数是service_manager.c中的main()方法，代码如下：

main

//service_manager.c
int main(int argc, char **argv) {
    struct binder_state *bs;
    //打开binder驱动，申请128k字节大小的内存空间 
    bs = binder_open(128*1024);
    ...

    //成为上下文管理者 
    if (binder_become_context_manager(bs)) {
        return -1;
    }

    selinux_enabled = is_selinux_enabled(); //selinux权限是否使能
    sehandle = selinux_android_service_context_handle();
    selinux_status_open(true);

    if (selinux_enabled > 0) {
        if (sehandle == NULL) {  
            abort(); //无法获取sehandle
        }
        if (getcon(&service_manager_context) != 0) {
            abort(); //无法获取service_manager上下文
        }
    }
    ...

    //进入无限循环，处理client端发来的请求
    binder_loop(bs, svcmgr_handler);
    return 0;
}

简单来说就是做了三件事：

打开binder驱动：binder_open；
注册成为binder服务的大管家：binder_become_context_manager；
进入无限循环，处理client端发来的请求：binder_loop；

首先看看binder_open方法：

打开驱动：binder_open

//frameworks/native/cmds/servicemanager/binder.c
struct binder_state *binder_open(size_t mapsize)
{
    //定义一个binder_state结构体
    struct binder_state *bs;
    struct binder_version vers;

    bs = malloc(sizeof(*bs));
    if (!bs) {
        errno = ENOMEM;
        return NULL;
    }

    //通过系统调用陷入内核，打开Binder设备驱动
    bs->fd = open("/dev/binder", O_RDWR);
    if (bs->fd < 0) {
        goto fail_open; // 无法打开binder设备
    }

     //通过系统调用，ioctl获取binder版本信息
    if ((ioctl(bs->fd, BINDER_VERSION, &vers) == -1) ||
        (vers.protocol_version != BINDER_CURRENT_PROTOCOL_VERSION)) {
        goto fail_open; //内核空间与用户空间的binder不是同一版本
    }

    bs->mapsize = mapsize;
    //通过系统调用，mmap内存映射，mmap必须是page的整数倍
    bs->mapped = mmap(NULL, mapsize, PROT_READ, MAP_PRIVATE, bs->fd, 0);
    if (bs->mapped == MAP_FAILED) {
        goto fail_map; // binder设备内存无法映射
    }

    return bs;

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

首先是定义一个binder_state结构体，这个结构体用来存放binder驱动的文件描述符fd，指向mmap的内存地址和内存的大小：

struct binder_state
{
    int fd; // dev/binder的文件描述符
    void *mapped; //指向mmap的内存地址
    size_t mapsize; //分配的内存大小，默认为128KB
};

j接着调用open()打开binder设备，open()方法经过系统调用，进入Binder驱动，然后调用方法binder_open()，该方法会在Binder驱动层创建一个binder_proc对象，再将binder_proc对象赋值给fd->private_data，同时放入全局链表binder_procs。再通过ioctl()检验当前binder版本与Binder驱动层的版本是否一致。

关于binder_open

binder_open方法中创建binder_proc对象，并把当前进程等信息保存到binder_proc对象，该对象管理IPC所需的各种信息并拥有其他结构体的根结构体；再把binder_proc对象保存到文件指针即fd->private_data，以及把binder_proc加入到全局链表。Binder驱动中通过static HLIST_HEAD(binder_procs);，创建了全局的哈希链表binder_procs，用于保存所有的binder_proc队列，每次新创建的binder_proc对象都会加入binder_procs链表中。binder_procs。

再继续就会调用mmap()进行内存映射，同理mmap()方法经过系统调用，对应于Binder驱动层的binder_mmap()方法，该方法会在Binder驱动层创建Binder_buffer对象，并放入当前binder_proc的proc->buffers链表。

关于binder_mmap

主要功能：首先在内核虚拟地址空间，申请一块与用户虚拟内存相同大小的内存；然后再申请1个page大小的物理内存，再将同一块物理内存分别映射到内核虚拟地址空间和用户虚拟内存空间，从而实现了用户空间的Buffer和内核空间的Buffer同步操作的功能。binder_mmap通过加锁，保证一次只有一个进程分配内存，保证多进程间的并发访问。

驱动打开完成并且创建了binder_proc，以及进行了内存映射之后，就要开始下一步成为binder服务的大管家

成为上下文管理者：binder_become_context_manager

//frameworks/native/cmds/servicemanager/binder.c
int binder_become_context_manager(struct binder_state *bs)
{
    //通过ioctl，传递BINDER_SET_CONTEXT_MGR指令
    return ioctl(bs->fd, BINDER_SET_CONTEXT_MGR, 0);
}

成为上下文的管理者，整个系统中只有一个这样的管理者。通过ioctl()方法经过系统调用，对应于Binder驱动层的binder_ioctl()方法

关于binder_ioctl:

binder_ioctl()函数负责在两个进程间收发IPC数据和IPC reply数据。
ioctl(文件描述符，ioctl命令，数据类型)
(1) 文件描述符，是通过open()方法打开Binder Driver后返回值；

(2) ioctl命令和数据类型是一体的，不同的命令对应不同的数据类型

在之前的篇幅中，这个方法想必大家都已经见到过很多次了。这里就不再赘述了。

binder_ioctl

// kernel/drivers/android/binder.c
static long binder_ioctl(struct file *filp, unsigned int cmd, unsigned long arg) {
    binder_lock(__func__);
    switch (cmd) {
      case BINDER_SET_CONTEXT_MGR:
          ret = binder_ioctl_set_ctx_mgr(filp);//
          break;
      }
      case :...
    }
    binder_unlock(__func__);
}

根据参数BINDER_SET_CONTEXT_MGR，最终调用binder_ioctl_set_ctx_mgr()方法，这个过程会持有binder_main_lock，也就是锁

binder_ioctl_set_ctx_mgr

static int binder_ioctl_set_ctx_mgr(struct file *filp)
{
    int ret = 0;
    struct binder_proc *proc = filp->private_data;
    kuid_t curr_euid = current_euid();

    //保证只创建一次mgr_node对象
    if (binder_context_mgr_node != NULL) {
        ret = -EBUSY; 
        goto out;
    }

    if (uid_valid(binder_context_mgr_uid)) {
        ...
    } else {
        //设置当前线程euid作为Service Manager的uid
        binder_context_mgr_uid = curr_euid;
    }

    //创建ServiceManager实体
    binder_context_mgr_node = binder_new_node(proc, 0, 0);
    ...
    binder_context_mgr_node->local_weak_refs++;
    binder_context_mgr_node->local_strong_refs++;
    binder_context_mgr_node->has_strong_ref = 1;
    binder_context_mgr_node->has_weak_ref = 1;
out:
    return ret;
}

创建了全局的binder_node对象binder_context_mgr_node，并将binder_context_mgr_node的强弱引用各加1

binder_new_node

static struct binder_node *binder_new_node(struct binder_proc *proc,
                       binder_uintptr_t ptr,
                       binder_uintptr_t cookie)
{
    struct rb_node **p = &proc->nodes.rb_node;
    struct rb_node *parent = NULL;
    struct binder_node *node;
    //首次进来为空
    while (*p) {
        parent = *p;
        node = rb_entry(parent, struct binder_node, rb_node);

        if (ptr < node->ptr)
            p = &(*p)->rb_left;
        else if (ptr > node->ptr)
            p = &(*p)->rb_right;
        else
            return NULL;
    }

    //给新创建的binder_node 分配内核空间
    node = kzalloc(sizeof(*node), GFP_KERNEL);
    if (node == NULL)
        return NULL;
    binder_stats_created(BINDER_STAT_NODE);
    // 将新创建的node对象添加到proc红黑树；
    rb_link_node(&node->rb_node, parent, p);
    rb_insert_color(&node->rb_node, &proc->nodes);
    node->debug_id = ++binder_last_id;
    node->proc = proc;
    node->ptr = ptr;
    node->cookie = cookie;
    node->work.type = BINDER_WORK_NODE; //设置binder_work的type
    INIT_LIST_HEAD(&node->work.entry);
    INIT_LIST_HEAD(&node->async_todo);
    return node;
}

在Binder驱动层创建binder_node结构体对象，并将当前binder_proc加入到binder_node的node->proc。并创建binder_node的async_todo和binder_work两个队列。

在成为了ServiceManager的上下文管理者后，回到main()方法中，在main方法中开启了循环，来处理client的请求。

循环处理请求：binder_loop

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

    bwr.write_size = 0;
    bwr.write_consumed = 0;
    bwr.write_buffer = 0;

    readbuf[0] = BC_ENTER_LOOPER;
    //将BC_ENTER_LOOPER命令发送给binder驱动，让Service Manager进入循环
    binder_write(bs, readbuf, sizeof(uint32_t));

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

        res = ioctl(bs->fd, BINDER_WRITE_READ, &bwr); //进入循环，不断地binder读写过程
        if (res < 0) {
            break;
        }

        // 解析binder信息 
        res = binder_parse(bs, 0, (uintptr_t) readbuf, bwr.read_consumed, func);
        if (res == 0) {
            break;
        }
        if (res < 0) {
            break;
        }
    }
}

进入循环读写操作，由main()方法传递过来的参数func指向svcmgr_handler。

binder_write通过ioctl()将BC_ENTER_LOOPER命令发送给binder驱动，此时bwr只有write_buffer有数据，进入binder_thread_write()方法。接下来进入for循环，执行ioctl()，此时bwr只有read_buffer有数据，那么进入binder_thread_read()方法。

binder_thread_write方法中如下几个参数的作用，此处是BC_ENTER_LOOPER：binder，作用是让ServiceManager开启loop循环：

BC_ENTER_LOOPER：binder主线程(由应用层发起)的创建会向驱动发送该消息；joinThreadPool()过程创建binder主线程;

BC_REGISTER_LOOPER：Binder用于驱动层决策而创建新的binder线程；joinThreadPool()过程,创建非binder主线程;

BC_EXIT_LOOPER：退出Binder线程，对于binder主线程是不能退出;joinThreadPool()的过程出现timeout,并且非binder主线程,则会退出该binder线程;

binder_write最终会调用到内核中的binder_ioctl_write_read方法，将用户空间的binder_write_read结构体拷贝到内核空间.

解析binder信息：binder_parse

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

    while (ptr < end) {
        uint32_t cmd = *(uint32_t *) ptr;
        ptr += sizeof(uint32_t);
        switch(cmd) {
        case BR_NOOP:  //无操作，退出循环
            break;
        case BR_TRANSACTION_COMPLETE:
            break;
        case BR_INCREFS:
        case BR_ACQUIRE:
        case BR_RELEASE:
        case BR_DECREFS:
            ptr += sizeof(struct binder_ptr_cookie);
            break;
        case BR_TRANSACTION: {
            struct binder_transaction_data *txn = (struct binder_transaction_data *) ptr;
            ...
            binder_dump_txn(txn);
            if (func) {
                unsigned rdata[256/4];
                struct binder_io msg; 
                struct binder_io reply;
                int res;
                ////初始化binder_io对象
                bio_init(&reply, rdata, sizeof(rdata), 4);
                bio_init_from_txn(&msg, txn); //从txn解析出binder_io信息，将readbuf的数据赋给bio对象的data
                 //此处func为svcmgr_handler
                res = func(bs, txn, &msg, &reply);
                //返回信息
                binder_send_reply(bs, &reply, txn->data.ptr.buffer, res);
            }
            ptr += sizeof(*txn);
            break;
        }
        case BR_REPLY: {
            struct binder_transaction_data *txn = (struct binder_transaction_data *) ptr;
            ...
            binder_dump_txn(txn);
            if (bio) {
                bio_init_from_txn(bio, txn);
                bio = 0;
            }
            ptr += sizeof(*txn);
            r = 0;
            break;
        }
        case BR_DEAD_BINDER: {
            struct binder_death *death = (struct binder_death *)(uintptr_t) *(binder_uintptr_t *)ptr;
            ptr += sizeof(binder_uintptr_t);
            // binder死亡消息【见小节3.3】
            death->func(bs, death->ptr);
            break;
        }
        case BR_FAILED_REPLY:
            r = -1;
            break;
        case BR_DEAD_REPLY:
            r = -1;
            break;
        default:
            return -1;
        }
    }
    return r;
}

此处func为svcmgr_handler，故当cmd命令为BR_TRANSACTION时，调用了svcmgr_handler方法，该方法的功能：查询服务，注册服务，以及列举所有服务。每一个服务用svcinfo结构体来表示，该handle值是在注册服务的过程中，由服务所在进程那一端所确定的。

struct svcinfo
{
    struct svcinfo *next;
    uint32_t handle; //服务的handle值
    struct binder_death death;
    int allow_isolated;
    size_t len; //名字长度
    uint16_t name[0]; //服务名
}

ServiceManager核心方法

servicemanager的核心工作就是注册服务和查询服务。

首先是查询服务

查询服务:do_find_service

//service_manager.c
uint32_t do_find_service(struct binder_state *bs, const uint16_t *s, size_t len, uid_t uid, pid_t spid)
{
    //查询相应的服务
    struct svcinfo *si = find_svc(s, len);

    if (!si || !si->handle) {
        return 0;
    }

    if (!si->allow_isolated) {
        uid_t appid = uid % AID_USER;
        //检查该服务是否允许孤立于进程而单独存在
        if (appid >= AID_ISOLATED_START && appid <= AID_ISOLATED_END) {
            return 0;
        }
    }

    //服务是否满足查询条件
    if (!svc_can_find(s, len, spid)) {
        return 0;
    }
    return si->handle;
}

find_svc方法中从svclist服务列表中，根据服务名遍历查找是否已经注册。当服务已存在svclist，则返回相应的服务名，否则返回NULL。

当找到服务的handle, 则调用bio_put_ref(reply, handle)，将handle封装到reply.

注册服务：do_add_service

int do_add_service(struct binder_state *bs,
                   const uint16_t *s, size_t len,
                   uint32_t handle, uid_t uid, int allow_isolated,
                   pid_t spid)
{
    struct svcinfo *si;

    if (!handle || (len == 0) || (len > 127))
        return -1;

    //权限检查
    if (!svc_can_register(s, len, spid)) {
        return -1;
    }

    //服务检索
    si = find_svc(s, len);
    if (si) {
        if (si->handle) {
            svcinfo_death(bs, si); //服务已注册时，释放相应的服务
        }
        si->handle = handle;
    } else {
        si = malloc(sizeof(*si) + (len + 1) * sizeof(uint16_t));
        if (!si) {  //内存不足，无法分配足够内存
            return -1;
        }
        si->handle = handle;
        si->len = len;
        memcpy(si->name, s, (len + 1) * sizeof(uint16_t)); //内存拷贝服务信息
        si->name[len] = '\0';
        si->death.func = (void*) svcinfo_death;
        si->death.ptr = si;
        si->allow_isolated = allow_isolated;
        si->next = svclist; // svclist保存所有已注册的服务
        svclist = si;
    }

    //以BC_ACQUIRE命令，handle为目标的信息，通过ioctl发送给binder驱动
    binder_acquire(bs, handle);
    //以BC_REQUEST_DEATH_NOTIFICATION命令的信息，通过ioctl发送给binder驱动，主要用于清理内存等收尾工作。[见小节3.3]
    binder_link_to_death(bs, handle, &si->death);
    return 0;
}

注册服务的分以下3部分工作：

svc_can_register：检查权限，检查selinux权限是否满足；
find_svc：服务检索，根据服务名来查询匹配的服务；
svcinfo_death：释放服务，当查询到已存在同名的服务，则先清理该服务信息，再将当前的服务加入到服务列表svclist；

当循环处理请求，binder_loop方法中执行binder_parse方法，先调用svcmgr_handler()，再然后执行binder_send_reply过程。该方法会调用 binder_write进入binder驱动后，将BC_FREE_BUFFER和BC_REPLY命令协议发送给Binder驱动，向client端发送reply. 其中data的数据区中保存的是TYPE为HANDLE。

总结

ServiceManger集中管理系统内的所有服务，通过权限控制进程是否有权注册服务,通过字符串名称来查找对应的Service; 由于ServiceManger进程建立跟所有向其注册服务的死亡通知, 那么当服务所在进程死亡后, 会只需告知ServiceManager. 每个Client通过查询ServiceManager可获取Server进程的情况，降低所有Client进程直接检测会导致负载过重。

ServiceManager启动流程：

打开binder驱动，并调用mmap()方法分配128k的内存映射空间：binder_open();
通知binder驱动使其成为守护进程：binder_become_context_manager()；
验证selinux权限，判断进程是否有权注册或查看指定服务；
进入循环状态，等待Client端的请求：binder_loop()。
注册服务的过程，根据服务名称，但同一个服务已注册，重新注册前会先移除之前的注册信息；
死亡通知: 当binder所在进程死亡后,会调用binder_release方法,然后调用binder_node_release.这个过程便会发出死亡通知的回调.

ServiceManager最核心的两个功能为查询和注册服务：

注册服务：记录服务名和handle信息，保存到svclist列表；
查询服务：根据服务名查询相应的的handle信息。

一张图来总结把~

到此为止，我们的Binder之旅就结束了。

觉得文章有点意思的话，不妨点个赞再走呀，啊呜~

最后

Android 开发相关源码精编解析

随着Android开发行业逐渐饱和，对Android开发者的面试要求也越来越高，是否掌握底层源码，便是考验一名Android开发者的重要一环。面试被问到源码问题答不出来，会掉身价、砍薪资尚且不谈，甚至连面试都过不了！

网上各类源码解析的文章博客五花八门、良莠不齐。杂乱、要么内容质量太浅，零散、碎片化，总看着看着就衔接不上了。

所以特意将我在疫情期间花了4个月整理出来的《Android 开发相关源码精编解析》分享出来大家

由于内容较多，避免影响到大家的阅读体验，在此只截图展示目录部分，487详细完整版的《Android 开发相关源码精编解析》电子书文档可以在我的GitHub获取百度网盘下载地址。。也欢迎大家找我探讨Android技术问题~

目录：一共18节，487页PDF，包括MMKV 源码，ARouter 源码，AsyncTask 源码，Volley 源码，Retrofit 源码，OkHttp 源码，ButterKnife 源码，Okio 源码，SharedPreferences 源码，EventBus 源码，Android 自定义注解初探，View 的工作机制源码分析，Android 触摸事件分发机制源码分析，Android 按键事件分发机制源码分析，深入解析 Handler 源码，深入解析 Binder 源码，深入解析 JNI 源码，深入解析 Glide 源码。

《Android 开发相关源码精编解析》电子书文档可以在我的GitHub获取百度网盘免费下载地址。

Android Framework：Binder全解析（完结篇）

作者

前言

启动过程

main

打开驱动：binder_open

成为上下文管理者：binder_become_context_manager

binder_ioctl

binder_ioctl_set_ctx_mgr

binder_new_node

循环处理请求：binder_loop

ServiceManager核心方法

查询服务:do_find_service

注册服务：do_add_service

总结

最后

Android 开发相关源码精编解析

相关文章

网友评论

延伸阅读

深度阅读

栏目导航

热点阅读

Android技术知识