学步园

Android Binder是一种在Android里广泛使用的一种远程过程调用接口。从结构上来说Android Binder系统是一种服务器/客户机模式，包括Binder
Server、Binder Client和Android Binder驱动，实际的数据传输就是通过Android Binder驱动来完成的，这里我们就来详细的介绍Android Binder驱动程序。

通常来说，Binder是Android系统中的内部进程通讯（IPC）之一。在Android系统中共有三种IPC机制，分别是：

       －标准Linux Kernel IPC接口
       －标准D-BUS接口
       －Binder接口

尽管Google宣称Binder具有更加简洁、快速，消耗更小内存资源的优点，但并没有证据表明D-BUS就很差。实际上D-BUS可能会更合适些，或 许只是当时Google并没有注意到它吧，或者Google不想使用GPL协议的D-BUS库。我们不去探究具体的原因了，你只要清楚Android系统 中支持了多个IPC接口，而且大部分程序使用的是我们并不熟悉的Binder接口。

Binder是OpenBinder的Google精简实现，它包括一个Binder驱动程序、一个Binder服务器及Binder客户端（？）。这里我们只要介绍内核中的Binder驱动的实现。

对于Android Binder，它也可以称为是Android系统的一种RPC（远程过程调用）机制，因为Binder实现的功能就是在本地“执行”其他服务进程的功能的 函数调用。不管是IPC也好，还是RPC也好，我们所要知道的就是Android Binder的功能是如何实现的。

Openbinder介绍

2.1.1 Android Binder协议

Android 的Binder机制是基于OpenBinder (http://www.angryredplanet.com/~hackbod/openbinder/docs/html/BinderIPCMechanism.html)来实现的，是一个OpenBinder的Linux实现。

Android Binder的协议定义在binder.h头文件中，Android的通讯就是基于这样的一个协议的。

• Binder Type

（描述binder type的功能）

Android定义了五个（三大类）Binder类型，如下：

enum {
   BINDER_TYPE_BINDER      = B_PACK_CHARS('s', 'b', '*', B_TYPE_LARGE),
   BINDER_TYPE_WEAK_BINDER  = B_PACK_CHARS('w', 'b', '*', B_TYPE_LARGE),
   BINDER_TYPE_HANDLE    = B_PACK_CHARS('s', 'h', '*', B_TYPE_LARGE),
   BINDER_TYPE_WEAK_HANDLE= B_PACK_CHARS('w', 'h', '*', B_TYPE_LARGE),
   BINDER_TYPE_FD              = B_PACK_CHARS('f', 'd', '*', B_TYPE_LARGE),
};

• Binder Object

进程间传输的数据被称为Binder对象（Binder Object），它是一个flat_binder_object，定义如下：

struct flat_binder_object {
    /* 8 bytes for large_flat_header. */ 
    unsigned long        type;
    unsigned long        flags;
    /* 8 bytes of data. */ 
    union {
        void        *binder;    /* local object */ 
        signed long    handle;        /* remote object */ 
    };
    /* extra data associated with local object */ 
    void            *cookie;
};

其中，类型字段描述了Binder 对象的类型，flags描述了传输方式，比如同步、异步等。

enum transaction_flags {
    TF_ONE_WAY    = 0x01,    /* this is a one-way call: async, no return */ 
    TF_ROOT_OBJECT    = 0x04,    /* contents are the component's root object */ 
    TF_STATUS_CODE    = 0x08,    /* contents are a 32-bit status code */ 
    TF_ACCEPT_FDS    = 0x10,    /* allow replies with file descriptors */ 
};

传输的数据是一个复用数据联合体，对于BINDER类型，数据就是一个binder本地对象，如果是HANDLE类型，这数据就是一个远程的handle 对象。该如何理解本地binder对象和远程handle对象呢？其实它们都指向同一个对象，不过是从不同的角度来说。举例来说，假如A有个对象X，对于 A来说，X就是一个本地的binder对象；如果B想访问A的X对象，这对于B来说，X就是一个handle。因此，从根本上来说handle和
binder都指向X。本地对象还可以带有额外的数据，保存在cookie中。

Binder对象的传递是通过binder_transaction_data来实现的，即Binder对象实际是封装在binder_transaction_data结构体中。

• binder_transaction_data

这个数据结构才是真正要传输的数据。它的定义如下：

struct binder_transaction_data {
    /* The first two are only used for bcTRANSACTION and brTRANSACTION,
     * identifying the target and contents of the transaction.
     */ 
    union {
        size_t    handle;    /* target descriptor of command transaction */ 
        void    *ptr;    /* target descriptor of return transaction */ 
    } target;
    void        *cookie;    /* target object cookie */ 
    unsigned int    code;        /* transaction command */ 
    /* General information about the transaction. */ 
    unsigned int    flags;
    pid_t        sender_pid;
    uid_t        sender_euid;
    size_t        data_size;    /* number of bytes of data */ 
    size_t        offsets_size;    /* number of bytes of offsets */ 
    /* If this transaction is inline, the data immediately
     * follows here; otherwise, it ends with a pointer to
     * the data buffer.
     */ 
    union {
        struct {
            /* transaction data */ 
            const void    *buffer;
            /* offsets from buffer to flat_binder_object structs */ 
            const void    *offsets;
        } ptr;
        uint8_t    buf[8];
    } data;
};

结构体中的数据成员target是一个复合联合体对象，请参考前面的关于binder本地对象及handle远程对象的描述。code是一个命令，描述了请求Binder对象执行的操作。

• 对象的索引和映射

Binder中的一个重要概念就是对象的映射和索引。就是要把对象从一个进程映射到另一个进程中，以实现线程迁移的概念。前面描述过Binder的一个重 要概念是进程/线程迁移，即当一个进程需要同另一个进程通信时，它可以“迁移”远程的进程/线程到本地来执行。对于调用进程来说，看起来就像是在本地执行 一样。这是Binder与其他IPC机制的不同点或者说是优点。当然迁移的工作是由Binder驱动来完成的，而实现的基础和核心就是对象的映射和索引。

Binder中有两种索引，一是本地进程地址空间的一个地址，另一个是一个抽象的32位句柄（HANDLE），它们之间是互斥的：所有的进程本地对象的索 引都是本地进程的一个地址(address, ptr, binder)，所有的远程进程的对象的索引都是一个句柄（handle）。对于发送者进程来说，索引就是一个远端对象的一个句柄，当Binder对象数 据被发送到远端接收进程时，远端接受进程则会认为索引是一个本地对象地址，因此从第三方的角度来说，尽管名称不同，对于一次Binder调用，两种索引指
的是同一个对象，Binder驱动则负责两种索引的映射，这样才能把数据发送给正确的进程。

对于Android的Binder来说，对象的索引和映射是通过binder_node和binder_ref两个核心数据结构来完成的，对于 Binder本地对象，对象的Binder地址保存在binder_node->ptr里，对于远程对象，索引就保存在 binder_ref->desc里，每一个binder_node都有一个binder_ref对象与之相联系，他们就是是通过ptr和desc
来做映射的，如下图：

flat_binder_object就是进程间传递的Binder对象，每一个flat_binder_object对象内核都有一个唯一的 binder_node对象，这个对象挂接在binder_proc的一颗二叉树上。对于一个binder_node对象，内核也会有一个唯一的 binder_ref对象，可以这么理解，binder_ref的desc唯一的映射到binder_node的ptr和cookie上，同时也唯一的映
射到了flat_binder_object的handler上。而binder_ref又按照node和desc两种方式映射到binder_proc 对象上，也就是可以通过binder_node对象或者desc两种方式在binder_proc上查找到binder_ref或 binder_node。所以，对于flat_binder_object对象来说，它的binder+cookie和handler指向了同一个 binder_node对象上，即同一个binder对象。

• BinderDriverCommandProtocol

Binder驱动的命令协议（BC_命令），定义了Binder驱动支持的命令格式及数据定义（协议）。不同的命令所带有的数据是不同的。Binder的 命令由binder_write_read数据结构描述，它是ioctl命令（BINDER_WRITE_READ）的参数。

struct binder_write_read {
    signed long    write_size;    /* bytes to write */ 
    signed long    write_consumed;    /* bytes consumed by driver */ 
    unsigned long    write_buffer;
    signed long    read_size;    /* bytes to read */ 
    signed long    read_consumed;    /* bytes consumed by driver */ 
    unsigned long    read_buffer;
};

对于写操作，write_buffer包含了一系列请求线程执行的Binder命令；对于读（返回）操作，read_buffer包含了一系列线程执行后填充的返回值。

Binder命令（BC_）用于BINDER_WRITE_READ的write操作。

Binder的BC的命令格式是：| CMD | Data... |

• BinderDriverReturnProtocol

Binder驱动的响应（返回，BR_）协议，定义了Binder命令的数据返回格式。同Binder命令协议一样，Binder驱动返回协议也是通过BINDER_WRITE_READ ioctl命令实现的，不同的是它是read操作。

Binder BR的命令格式是：| CMD | Data... |

• Android Binder 进程 / 线程模型

（描述Android的进程模型）

2.1.2 驱动接口

Android Binder设备驱动接口函数是

device_initcall(binder_init);

我们知道一般来说设备驱动的接口函数是module_init和module_exit，这么做是为了同时兼容支持静态编译的驱动模块（buildin） 和动态编译的驱动模块（module）。但是Android的Binder驱动显然不想支持动态编译的驱动，如果你需要将Binder驱动修改为动态的内 核模块，可以直接将device_initcall修改为module_init，但不要忘了增加module_exit的驱动卸载接口函数。

• binder_init

初始化函数首先创建了一个内核工作队列对象（workqueue），用于执行可以延期执行的工作任务：

static struct workqueue_struct *binder_deferred_workqueue ;
binder_deferred_workqueue = create_singlethread_workqueue("binder");

挂在这个workqueue上的work是binder_deferred_work，定义如下。当内核需要执行work任务时，就通过workqueue来调度执行这个work了。

static DECLARE_WORK(binder_deferred_work , binder_deferred_func);
queue_work(binder_deferred_workqueue , &binder_deferred_work );

既然说到了binder_deferred_work，这里有必要来进一步说明一下，binder_deferred_work是在函数binder_defer_work里调度的：

static void
binder_defer_work(struct binder_proc *proc, enum binder_deferred_state defer)
{
    mutex_lock(&binder_deferred_lock);
    proc->deferred_work |= defer;
    if (hlist_unhashed(&proc->deferred_work_node)) {
        hlist_add_head(&proc->deferred_work_node,
                &binder_deferred_list);
        queue_work(binder_deferred_workqueue, &binder_deferred_work); 
    }
    mutex_unlock(&binder_deferred_lock);
}

deferred_work有三种类型，分别是BINDER_DEFERRED_PUT_FILES，BINDER_DEFERRED_FLUSH 和BINDER_DEFERRED_RELEASE。它们都操作在binder_proc对象上。

enum binder_deferred_state {
    BINDER_DEFERRED_PUT_FILES    = 0x01,
    BINDER_DEFERRED_FLUSH        = 0x02,
    BINDER_DEFERRED_RELEASE      = 0x04,
};

就现介绍到这里了，关于deferred的具体操作在后面还会有详细的介绍。下面回到我们的初始化函数主题上。

初始化函数接着使用proc_mkdir创建了一个Binder的proc文件系统的根节点 （binder_proc_dir_entry_root，/proc/binder），并为binder创建了binder proc节点（binder_proc_dir_entry_proc，/proc/binder/proc），注意不要混淆Linux Proc和Binder
Proc。

然后Binder驱动使用misc_register把自己注册为一个Misc设备（/dev/misc/binder）。

最后，如果驱动成功的创建了/proc/binder根节点，就调用create_proc_read_entry创建只读proc文件：/proc /binder/state，/proc/binder/stats，/proc/binder/transactions，/proc/binder /transaction_log，/proc/binder/failed_transaction_log。

这个初始化函数有个小小的问题，它没有判断Misc设备是否注册成功了，如果注册失败了，那么Binder就不能正常工作了，因此这里应该有个错误处理流程。

注：
workqueue是Linux2.6内核的一种延期执行任务的一种机制，用于提到古老的任务队列（task queue）机制，workqueue机制非常灵活，简单，易于使用。 
mutex_lock和 mutex_unlock是一种内核同步机制。

2.1.3 Binder核心数据

在进一步介绍Binder驱动之前，我们有必要了解一下Binder的核心数据。

• binder_proc

struct binder_proc {
    struct hlist_node proc_node;
    struct rb_root threads;
    struct rb_root nodes;
    struct rb_root refs_by_desc;
    struct rb_root refs_by_node;
    int pid;
    struct vm_area_struct *vma;
    struct task_struct *tsk;
    struct files_struct *files;
    struct hlist_node deferred_work_node;
    int deferred_work;
    void *buffer;
    ptrdiff_t user_buffer_offset;
    struct list_head buffers;
    struct rb_root free_buffers;
    struct rb_root allocated_buffers;
    size_t free_async_space;
    struct page **pages;
    size_t buffer_size;
    uint32_t buffer_free;
    struct list_head todo;
    wait_queue_head_t wait;
    struct binder_stats stats;
    struct list_head delivered_death;
    int max_threads;
    int requested_threads;
    int requested_threads_started;
    int ready_threads;
    long default_priority;
};

binder_proc用于保存调用binder的各个进程或线程信息，比如线程id、进程id、binder状态信息等。
（各个数据的意义？）

• binder_node

struct binder_node {
    int debug_id;
    struct binder_work work;
    union {
        struct rb_node rb_node;
        struct hlist_node dead_node;
    };
    struct binder_proc *proc;
    struct hlist_head refs;
    int internal_strong_refs;
    int local_weak_refs;
    int local_strong_refs;
    void __user *ptr;
    void __user *cookie;
    unsigned has_strong_ref : 1;
    unsigned pending_strong_ref : 1;
    unsigned has_weak_ref : 1;
    unsigned pending_weak_ref : 1;
    unsigned has_async_transaction : 1;
    unsigned accept_fds : 1;
    int min_priority : 8;
    struct list_head async_todo;
};

• binder_thread

struct binder_thread {
        struct binder_proc *proc;
        struct rb_node rb_node;
        int pid;
        int looper;
        struct binder_transaction *transaction_stack;
        struct list_head todo;
        uint32_t return_error; /* Write failed, return error code in read buf */ 
        uint32_t return_error2; /* Write failed, return error code in read */ 
        /* buffer. Used when sending a reply to a dead process that */
        /* we are also waiting on */ 
        wait_queue_head_t wait;
        struct binder_stats stats;
        };

• binder_ref

struct binder_ref {
    /* Lookups needed: */
    /*   node + proc => ref (transaction) */
    /*   desc + proc => ref (transaction, inc/dec ref) */
    /*   node => refs + procs (proc exit) */ 
    int debug_id;
    struct rb_node rb_node_desc;
    struct rb_node rb_node_node;
    struct hlist_node node_entry;
    struct binder_proc *proc;
    struct binder_node *node;
    uint32_t desc;
    int strong;
    int weak;
    struct binder_ref_death *death;
};

2.1.4 用户接口

驱动程序的一个主要同能就是向用户空间的程序提供操作接口，这个接口是标准的，对于Android Binder驱动，包含的接口有：
       －Proc接口（/proc/binder）
              . /proc/binder/state
              . /proc/binder/stats
              . /proc/binder/transactions
              . /proc/binder/transaction_log
              . /proc/binder/failed_transaction_log
              . /proc/binder/proc/

       - 设备接口（/dev/binder）
              . binder_open
              . binder_release
              . binder_flush
              . binder_mmap
              . binder_poll
              . binder_ioctl

这些内核接口函数是在驱动程序的初始化函数(binder_init)中初始化的，感兴趣的读者可以阅读相关函数的实现代码，很简单明了，一共才十几行的代码。

• binder_open

通常来说，驱动程序的open函数是用户调用驱动接口来使用驱动功能的第一个函数，称为入口函数。同其他驱动一样，对于Android驱动，任何一个进程及其内的所有线程都可以打开一个binder设备。首先来看看Binder驱动是如何打开设备的。

首先，binder驱动分配内存以保存binder_proc数据结构。

然后，binder填充binder_proc数据（初始化），增加当前线程/进程的引用计数并赋值给tsk

get_task_struct(current); 
proc->tsk = current;

初始化binder_proc的队列及默认优先级

INIT_LIST_HEAD(&proc->todo); 
init_waitqueue_head(&proc->wait); 
proc->default_priority = task_nice(current);

增加BINDER_STAT_PROC的对象计数，并把创建的binder_proc对象添加到全局的binder_proc哈希列表中，这样任何一个进程就都可以访问到其他进程的binder_proc对象了。

binder_stats.obj_created[BINDER_STAT_PROC]++; 
hlist_add_head(&proc->proc_node, &binder_procs);

把当前进程/线程的线程组的pid（pid指向线程id）赋值给proc的pid字段，可以理解为一个进程id（thread_group指向线程组中的 第一个线程的task_struct结构）。同时把binder_proc对象指针赋值给filp的private_data对象保存起来。

proc->pid = current->group_leader->pid; 
INIT_LIST_HEAD(&proc->delivered_death); 
filp->private_data = proc;

最后，在bindr proc目录中创建只读文件（/proc/binder/proc/$pid）用来输出当前binder proc对象的状态。

这里要注意的是，proc->pid字段，按字面理解它应该是保存当前进程/线程的id，但实际上它保存的是线程组的pid，也就是线程组中的第一个线程的pid（等于tgid，进程id）。

这样当一个进程或线程打开一个binder设备时，驱动就会在内核中为其创建binder_proc结构来保存打开此设备的进程/线程信息。

• binder_release

binder_release是一个驱动的出口函数，当进程退出(exit)时，进程需要显示或隐式的调用release函数来关闭打开的文件。Release函数一般来清理进程的内核数据，释放申请的内存。

Binder驱动的release函数相对比较简单，它删除open是创建的binder proc文件，然后调度一个workqueue来释放这个进程/线程的binder_proc对象（BINDER_DEFERRED_RELEASE）。 这里要提的一点就是使用workqueue（deffered）可以提高系统的响应速度和性能，因为Android Binder的release及flush等操作是一个复杂费事的任务，而且也没有必要在系统调用里完成它，因此最好的方法是延迟执行这个费时的任务。其
实在中断处理函数中我们经常要把一些耗时的操作放到底半部中处理（bottom half），这是一样的道理。

当然真正的释放工作是在binder_deferred_release函数里完成的，后面在做详尽的介绍。

workqueue 是 Linux 系统中延迟执行任务的一种机制

• binder_flush

flush操作在关闭一个设备文件描述符拷贝时被调用，Binder的flush函数十分简单，它只是简单的调度一个workqueue执行 BINDER_DEFERRED_FLUSH操作。flush操作比较简单，内核只是唤醒所有睡眠在proc对象及其thread对象上的所有函数。

• binder_mmap

mmap（memory map）用于把设备内存映射到用户进程地址空间中，这样就可以像操作用户内存那样操作设备内存。（还有一种说法，mmap用于把用户进程地址空间映射到设备内存上，尽管说法不同，但是说的是同一个事情）

Binder设备对内存映射是有些限制的，比如binder设备最大能映射4M的内存区域；binder不能映射具有写权限的内存区域。

不同于一般的设备驱动，大多的设备映射的设备内存是设备本身具有的，或者在驱动初始化时由vmalloc或kmalloc等内核内存函数分配 的，Binder的设备内存是在mmap操作时分配的，分配的方法是先在内核虚拟映射表上获取一个可以使用的区域，然后分配物理页，并把物理页映射到获取 的虚拟空间上。由于设备内存是在mmap操作中实现的，因此每个进程/线程只能做映射操作一次，其后的操作都会返回错误。

具体来说，binder_mmap首先检查mmap调用是否合法，即是否满足binder内存映射的条件，主要检查映射内存的大小、flags，是否是第一次调用。

if ((vma->vm_end - vma->vm_start) > SZ_4M)
vma->vm_end = vma->vm_start + SZ_4M;
if (vma->vm_flags & FORBIDDEN_MMAP_FLAGS) {
…
}
vma->vm_flags = (vma->vm_flags | VM_DONTCOPY) & ~VM_MAYWRITE;
if (proc->buffer) {
…
}

然后，binder驱动从系统申请可用的虚拟内存空间（注意不是物理内存空间），这是通过get_vm_area内核函数实现的：（get_vm_area是一个内核，功能是在内核中申请并保留一块连续的内核虚拟内存空间区域）

area = get_vm_area(vma->vm_end - vma->vm_start, VM_IOREMAP);
proc->buffer = area->addr;
proc->user_buffer_offset = vma->vm_start - (uintptr_t)proc->buffer;

然后根据请求映射的内存空间大小，分配binder核心数据结构binder_proc的pages成员，它主要用来保存指向申请的物理页的指针。

proc->pages = kzalloc(sizeof(proc->pages[0]) * ((vma->vm_end - vma->vm_start) / PAGE_SIZE), GFP_KERNEL);
proc->buffer_size = vma->vm_end - vma->vm_start;

一切都准备就绪了，现在开始分配物理内存（page）了。这是通过binder驱动的帮助函数binder_update_page_range来实现 的。尽管名字上称为update page，但在这里它是在分配物理页并映射到刚才保留的虚拟内存空间上。当然根据参数，它也可以释放物理页面。在这里，Binder使用 alloc_page分配页面，使用map_vm_area为分配的内存做映射关系，使用vm_insert_page把分配的物理页插入到用户vma区
域。函数传递的参数很有意识，我们来看一下：

binder_update_page_range(proc, 1, proc->buffer , proc->buffer + PAGE_SIZE ,
vma)；

开始地址是proc->buffer很容易理解，但是也许你会奇怪为什么结束地址是proc->buffer+PAGE_SIZE？这是因为，在这里并没有全部分配物理内存，其实只是分配了一个页的物理内存（第 一，函数是在分配物理页，就是说物理内容的分配是以页面为单位的，因此所谓的开始地址和结束地址是用来计算需要分配多少物理页面的，这是开始地址和结束地
址的含义。第二，前面已经提到mmap的最大物理内存是4M，因此需要的最多的pages就是1K，一个指针是4个字节，因此最大的page指针 buffer就是4K，也就是一个页的大小。第三，不管申请mmap物理内存是多大，内核总是分配一个页的指针数据，也就是每次都分配最多的物理页。） 下面来看看物理页是如何分配的：

*page = alloc_page(GFP_KERNEL | __GFP_ZERO); 
tmp_area.addr = page_addr;
tmp_area.size = PAGE_SIZE + PAGE_SIZE /* guard page? */;
page_array_ptr = page;
ret = map_vm_area(&tmp_area, PAGE_KERNEL, &page_array_ptr); 
user_page_addr = (uintptr_t)page_addr + proc->user_buffer_offset;
ret = vm_insert_page(vma, user_page_addr, page[0]);

注： alloc_page, map_vm_area 和 vm_insert_page 都是 Linux 内核中内存相关函数。

物理页分配完后，这个物理内存就交给binder_buffer来管理了，刚刚申请的物理内存以binder_buffer的方式放到proc->buffers链表里。

struct binder_buffer *buffer;
buffer = proc->buffer; 
INIT_LIST_HEAD(&proc->buffers);
list_add(&buffer->entry, &proc->buffers);
buffer->free = 1;
binder_insert_free_buffer(proc, buffer);
proc->free_async_space = proc->buffer_size / 2;

binder_buffer和proc->buffer的关系如下图：

当然，这里会使用到的核心数据结构binder_proc，用到的主要域是

buffer                            记录binder_proc的内核虚拟地址的首地址
buffer_size                    记录binder_proc的虚拟地址的大小
user_buffer_offset        记录binder_proc的用户地址偏移，即用户进程vma地址与binder申请的
                                    vma地址的偏差
pages                            记录指向binder_proc物理页（struct page）的指针（二维指针）
free                    
free_async_space        
files                                记录进程的struct file_struct 结构
vma                                记录用户进程的vma结构

显然，这些都同内存相关。

• binder_poll

poll函数是非阻塞型IO（select，poll调用）的内核驱动实现，所有支持非阻塞IO操作的设备驱动都需要实现poll函数。