Android跨进程通信IPC之7——Binder相关结构体简介

Android跨进程通信IPC整体内容如下

• 1、Android跨进程通信IPC之1——Linux基础
• 2、Android跨进程通信IPC之2——Bionic
• 3、Android跨进程通信IPC之3——关于"JNI"的那些事
• 4、Android跨进程通信IPC之4——AndroidIPC基础1
• 4、Android跨进程通信IPC之4——AndroidIPC基础2
• 5、Android跨进程通信IPC之5——Binder的三大接口
• 6、Android跨进程通信IPC之6——Binder框架
• 7、Android跨进程通信IPC之7——Binder相关结构体简介
• 8、Android跨进程通信IPC之8——Binder驱动
• 9、Android跨进程通信IPC之9——Binder之Framework层C++篇1
• 9、Android跨进程通信IPC之9——Binder之Framework层C++篇2
• 10、Android跨进程通信IPC之10——Binder之Framework层Java篇
• 11、Android跨进程通信IPC之11——AIDL
• 12、Android跨进程通信IPC之12——Binder补充
• 13、Android跨进程通信IPC之13——Binder总结
• 14、Android跨进程通信IPC之14——其他IPC方式
• 15、Android跨进程通信IPC之15——感谢

后面就要讲解Binder源码了，会涉及到很多struct，因此这里先铺垫一下，说几个常用的数据结构，内容如下：

1、结构体binder_work
2、结构体binder_thread
3、构体binder_stats
4、结构体binder_proc
5、结构体binder_node
6、结构体binder_ref
7、结构体binder_ref_death
8、结构体binder_state
9、结构体binder_buffer
10、结构体binder_transaction
11、结构体binder_transaction_data
12、结构体transaction_flags
13、结构体flat_binder_object
14、结构体binder_write_read
15、结构体binder_ptr_cookie
16、总结

一、结构体binder_work

1、位置

位置在
Linux的binder.c 240行

2、代码注释

binder_work代表binder驱动中进程要处理的工作项

struct binder_work {
    struct list_head entry;  //用于实现一个双向链表，存储的所有binder_work队列
    enum {
        BINDER_WORK_TRANSACTION = 1,
        BINDER_WORK_TRANSACTION_COMPLETE,
        BINDER_WORK_NODE,
        BINDER_WORK_DEAD_BINDER,
        BINDER_WORK_DEAD_BINDER_AND_CLEAR,
        BINDER_WORK_CLEAR_DEATH_NOTIFICATION,
    } type;  //描述工作项的类型
};

二、结构体binder_thread

1、代码位置

位置在
Linux的binder.c 368行

2、代码注释

binder_thread 代表Binder线程池中的每个线程信息

struct binder_thread {
    //宿主进程，即线程属于那么Binder进程
    struct binder_proc *proc;  
    //红黑树的一个节点，binder_proc使用红黑树来组织Binder线程池中的线程
    struct rb_node rb_node;  
    // 当前线程的PID
    int pid;
    // 当前线程的状态信息
    int looper;
    //事务堆栈，将事务封装成binder_transaction，添加到事务堆栈中，
    //定义了要接收和发送的进程和线程消息
    struct binder_transaction *transaction_stack;
    //队列，当有来自Client请求时，将会添加到to_do队列中
    struct list_head todo;
    // 记录阅读buf事务时出现异常错误情况信息
    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 */
     // 等待队列，当Binder处理事务A依赖于其他Binder线程处理事务B的情况
     // 则会在sleep在wait所描述的等待队列中，知道B事物处理完毕再唤醒
    wait_queue_head_t wait;
     // Binder线程相关统计数据
    struct binder_stats stats;
};

这里面说下上面looper对应的值

enum {
    // Binder驱动 请求创建该线程，通过BC_REGISTER_LOOPER协议通知
    //Binder驱动，注册成功设置此状态
    BINDER_LOOPER_STATE_REGISTERED  = 0x01,
    //该线程是应用程序主动注册的  通过 BC_ENTER_LOOPER 协议
    BINDER_LOOPER_STATE_ENTERED     = 0x02,
    // Binder线程退出
    BINDER_LOOPER_STATE_EXITED      = 0x04,
    // Binder线程处于无效
    BINDER_LOOPER_STATE_INVALID     = 0x08,
    // Binder线程处于空闲状态
    BINDER_LOOPER_STATE_WAITING     = 0x10,
     // Binder线程处于需要返回用户控件
     // 使用场景是：1、线程注册为Binder线程后，还没有准备好去处理进程间通信
     //，需要返回用户空间做其他初始化准备；2、调用flush来刷新Binder线程池                                                                                                                 
    BINDER_LOOPER_STATE_NEED_RETURN = 0x20
};

三、结构体binder_stats

binder_stats 代表d的是Binder线程相关统计数据

1、代码位置

位置在
Linux的binder.c 173行

2、代码注释

struct binder_stats {
        // 统计各个binder响应码的个数
    int br[_IOC_NR(BR_FAILED_REPLY) + 1];
        // 统计各个binder请求码的个数
    int bc[_IOC_NR(BC_REPLY_SG) + 1];
        // 统计各种obj创建的个数
    int obj_created[BINDER_STAT_COUNT];
        // 统计各种obj删除个数
    int obj_deleted[BINDER_STAT_COUNT];
};

四、结构体binder_proc

binder_proc 代表的是一个正在使用Binder进程通信的进程，binder_proc为管理其信息的记录体，当一个进程open /dev/binder 时，Binder驱动程序会为其创建一个binder_proc结构体，用以记录进程的所有相关信息，并把该结构体保存到一个全局的hash表中

1、代码位置

位置在
Linux的binder.c 322行

2、代码注释

struct binder_proc {
        /** 进程相关参数 */

        //上述全局hash表中一个节点，用以标记该进程
    struct hlist_node proc_node;
        // 进程组ID
    int pid;
         // 任务控制模块 
    struct task_struct *tsk; 
        // 文件结构体数组
    struct files_struct *files;

       /**  Binder线程池每一个Binder进程都有一个线程池，由Binder驱动来维护，Binder线程池中所有线程由一个红黑树来组织，RB树以线程ID为关键字  */
        //上述红黑树的根节点
    struct rb_root threads;
        
       /** 一系列Binder实体对象(binder_node)和Binder引用对象(binder_ref) */
       /** 在用户控件：运行在Server端称为Binder本地对象，运行在Client端称为Binder代理对象*/
       /**  在内核空间：Binder实体对象用来描述Binder本地对象，Binder引用对象来描述Binder代理对象 */
         // Binder实体对象列表(RB树)，关键字 ptr
    struct rb_root nodes;
         // Binder引用对象，关键字  desc
    struct rb_root refs_by_desc;
         // Binder引用对象，关键字  node
    struct rb_root refs_by_node;
         // 这里有两个引用对象，是为了方便快速查找 


     /**  进程可以调用ioctl注册线程到Binder驱动程序中，当线程池中没有足够空闲线程来处理事务时，Binder驱动可以主动要求进程注册更多的线程到Binder线程池中 */
        // Binder驱动程序最多可以请求进程注册线程的最大数量
    int max_threads;
        // Binder驱动每主动请求进程添加注册一个线程的时候，requested_threads+1
    int requested_threads;
        // 进程响应Binder要求后，requested_thread_started+1，request_threads-1，表示Binder已经主动请求注册的线程数目
    int requested_threads_started;

        // 进程当前空闲线程的数目
    int ready_threads;
        // 线程优先级，初始化为进程优先级
    long default_priority;
        //进程的整个虚拟地址空间
    struct mm_struct *vma_vm_mm;

        /** mmap 内核缓冲区*/
        // mmap——分配的内核缓冲区  用户控件地址(相较于buffer)
    struct vm_area_struct *vma; 
        // mmap——分配内核缓冲区，内核空间地址(相交于vma)  两者都是虚拟地址
    void *buffer;
        // mmap——buffer与vma之间的差值
    ptrdiff_t user_buffer_offset;

        /** buffer指向的内核缓冲区，被划分为很多小块进行性管理；这些小块保存在列表中，buffer就是列表的头部 */
         // 内核缓冲列表
    struct list_head buffers;
         // 空闲的内存缓冲区(红黑树)
    struct rb_root free_buffers;
         // 正在使用的内存缓冲区(红黑树)
    struct rb_root allocated_buffers;
        // 当前可用来保存异步事物数据的内核缓冲区大小
    size_t free_async_space;
        //  对应用于vma 、buffer虚拟机地址，这里是他们对应的物理页面
    struct page **pages;
        //  内核缓冲区大小
    size_t buffer_size;
        // 空闲内核缓冲区大小
    uint32_t buffer_free;

         /** 进程每接收到一个通信请求，Binder将其封装成一个工作项，保存在待处理队列to_do中  */
        //待处理队列
    struct list_head todo;
        // 等待队列，存放一些睡眠的空闲Binder线程
    wait_queue_head_t wait;
        // hash表，保存进程中可以延迟执行的工作项
    struct hlist_node deferred_work_node;
        // 延迟工作项的具体类型
    int deferred_work;
    
        //统计进程相关数据，具体参考binder_stats结构体
    struct binder_stats stats;
        // 表示 Binder驱动程序正在向进程发出死亡通知
    struct list_head delivered_death;
        // 用于debug
    struct dentry *debugfs_entry;
        // 连接 存储binder_node和binder_context_mgr_uid以及name
    struct binder_context *context;
};

五、结构体binder_node

binder_node 代表的是Binder实体对象，每一个service组件或者ServiceManager在Binder驱动程序中的描述，Binder驱动通过强引用和弱引用来维护其生命周期，通过node找到空间的Service对象

1、代码位置

位置在
Linux的binder.c 252行

2、代码注释

struct binder_node {
        // debug调试用的
    int debug_id;
    struct binder_work work;  //binder驱动中进程要处理的工作项 

        /** 每一个binder进程都由一个binder_proc来描述，binder进程内部所有Binder实体对象，
        由一个红黑树来进行组织(struct rb_root nodes)  ； rb_node 则对应nodes的一个节点 */
    union {
        //用于本节点连接红黑树
        struct rb_node rb_node;
        // 如果Binder 实体对象对应的进程死亡，销毁节点时需要将rb_node从红黑树中删除，
        //如果本节点还没有引用切断，则用dead_node将其隔离到另一个链表中，
        //直到通知所有进程切断与该节点的引用后，该节点才能销毁
        struct hlist_node dead_node;
    };

    // 指向该Binder实体对象 对应的进程，进程由binder_proc描述
    struct binder_proc *proc;
    // 该 Binder实体对象可能同时被多个Client组件引用，所有指向本实体对象的引用都
    //保存在这个hash队列中refs表示队列头部；这些引用可能隶属于不同进程，遍历该
    //hash表能够得到这些Client组件引用了这些对象
    struct hlist_head refs;

    /** 引用计数 
     * 1、当一个Binder实体对象请求一个Service组件来执行Binder操作时。会增加该Service
     * 组件的强/弱引用计数同时，Binder实体对象将会has_strong_ref与has_weak_ref置为1 
     *2、当一个Service组件完成一个Binder实体对象请求的操作后，Binder对象会请求减少该
     * Service组件的强/弱引用计数
     * 3、Binder实体对象在请求一个Service组件增加或减少强/弱引用计数的过程中，
     * 会将pending_strong_ref和pending_weak_ref置为1，当Service组件完成增加
     * 或减少计数时，Binder实体对象会将这两个变量置为0
     */

    //远程强引用 计数
    int internal_strong_refs;  //实际上代表了一个binder_node与多少个binder_ref相关联
    //本地弱引用技数
    int local_weak_refs;
     //本地强引用计数
    int local_strong_refs;

    unsigned has_strong_ref:1;
    unsigned pending_strong_ref:1;
    unsigned has_weak_ref:1;
    unsigned pending_weak_ref:1;

     /** 用来描述用户控件中的一个Service组件 */
    // 描述用户控件的Service组件，对应Binder实体对应的Service在用户控件的(BBinder)的引用
    binder_uintptr_t ptr;
    // 描述用户空间的Service组件，Binder实体对应的Service在用户控件的本地Binder(BBinder)地址
    binder_uintptr_t cookie;

     // 异步事务处理，单独讲解
    unsigned has_async_transaction:1;
    struct list_head async_todo;
    // 表示该Binder实体对象能否接收含有该文件描述符的进程间通信数据。当一个进程向
    //另一个进程发送数据中包含文件描述符时，Binder会在目标进程中打开一个相同的文件
    //故设为accept_fds为0 可以防止源进程在目标进程中打开文件
    unsigned accept_fds:1;
     // 处理Binder请求的线程最低优先级
    unsigned min_priority:8;

};

这里说下binder_proc和binder_node关系：

可以将binder_proc理解为一个进程，而将binder_noder理解为一个Service。binder_proc里面有一个红黑树，用来保存所有在它所描述的进程里面创建Service。而每一个Service在Binder驱动里面都有一个binder_node来描述。

3、异步事物处理

异步事务处理，目的在于为同步交互让路，避免长时间阻塞发送送端
异步事务定义：(相对于同步事务)单向进程间通信要求，即不需要等待应答的进程间通信请求
Binder驱动程序认为异步事务的优先级低于同步事务，则在同一时刻，一个Binder实体对象至多只有一个异步事物会得到处理。而同步事务则无此限制。
Binder将事务保存在一个线程binder_thread的todo队列中，表示由该线程来处理该事务。每一个事务都关联Binder实体对象(union target)，表示该事务的目标处理对象，表示要求该Binder实体对象对应的Service组件在制定线程中处理该事务，而如果Binder发现一个事务时异步事务，则会将其保存在目标Binder对象的async_todo的异步事务中等待处理

六、结构体binder_ref

binder_ref 代表的是Binder的引用对象，每一个Clinet组件在Binder驱动中都有一个Binder引用对象，用来描述它在内核中的状态。

1、代码位置

位置在
Linux的binder.c 281行

2、代码注释

struct binder_ref {
    /* Lookups needed: */
    /*   node + proc => ref (transaction) */
    /*   desc + proc => ref (transaction, inc/dec ref) */
    /*   node => refs + procs (proc exit) */
        //debug 调试用的
        int debug_id;
     
        /** binder_proc中使用红黑树(对应两个rb_root变量) 来存储器内部所有引用对象，
         *下面的rb_node则是红黑树中的节点
         */
        //Binder引用的宿主进程
        struct binder_proc *proc;
        //对应 refs_by_desc，以句柄desc索引  关联到binder_proc->refs_by_desc红黑树 
        struct rb_node rb_node_desc;
         //对应refs_by_node，以Binder实体对象地址作为关键字关联到binder_proc->refs_by_node红黑树
        struct rb_node rb_node_node;

        /** Client通过Binder访问Service时，仅需指定一个句柄，Binder通过该desc找到对应的binder_ref，
         *  再根据该binder_ref中的node变量得到binder_node(实体对象)，进而找到对应的Service组件
         */
        // 对应Binder实体对象中(hlist_head) refs引用对象队列中的一个节点
        struct hlist_node node_entry;
        // 引用对象所指向的Binder实体对象
        struct binder_node *node;
        // Binder引用的句柄值，Binder驱动为binder驱动引用分配一个唯一的int型整数（进程范围内唯一）
        // ，通过该值可以在binder_proc->refs_by_desc中找到Binder引用，进而可以找到Binder引用对应的Binder实体
        uint32_t desc;

        // 强引用 计数
        int strong;
        // 弱引用 计数
        int weak;
      
        //  表示Service组件接受到死亡通知
        struct binder_ref_death *death;
};

七、结构体binder_ref_death

binder_ref_death 一个死亡通知的结构体
我们知道Client组件无法控制它所引用的Service组件的生命周期，由于Service组件所在的进程可能意外崩溃。Client进程需要能够在它所引用的Service组件死亡时获的通知，进而进行响应。则Client进程就需要向Binder驱动注册一个用来接收死亡通知的对象地址(这里的cookie)

1、代码位置

位置在
Linux的binder.c 276行

2、代码注释

struct binder_ref_death {
         //标志该通知具体的死亡类型
        struct binder_work work;   
         // 保存负责接收死亡通知的对象地址
        binder_uintptr_t cookie;
};

这里随带说一下Binder驱动向Client进程发送死亡通知的情况：

• 1、Binder驱动检测到Service组件死亡时，会找到对应Serivce实体对象(binder_node)，再通过refs变量找到引用它的所有Client进程(binder_ref)，再通过death变量找到Client进程向Binder注册的死亡通知接收地址；Binder将死亡通知binder_ref_death封装成工作项，添加到Client进程to_do队列中等待处理。这种情况binder_work类型为BINDER_WORK_DEAD_BINDER
• 2、Client进程向Binder驱动注册一个死亡接收通知时，如果它所引用的Service组件已经死亡，Binder会立即发送通知给Client进程。这种情况binder_work类型为BINDER_WORK_DEAD_BINDER
• 3、当Client进程向Binder驱动注销一个死亡通知时，也会发送通知，来响应注销结果
• ①当Client注销时，Service组件还未死亡：Binder会找到之前Client注册的binder_ref_death，当binder_work修改为BINDER_CLEAR_NOTIFICATION，并将通知按上述步骤添加到Client的to_do队列中
• @当Client注销时，Service已经死亡，Binder同理将binder_work修改为WORK_DEAD_BINDER_AND_CLEAR，然后添加到todo中

八、结构体binder_state

binder_state 代表着binder设备文件的状态

1、代码位置

位置在
/frameworks/native/cmds/servicemanager/binder.c 89行

2、代码注释

struct binder_state
{
    //打开 /dev/binder之后得到的文件描述符
    int fd;
    //mmap将设备文件映射到本地进程的地址空间，映射后的到地址空间中，映射后得到的地址空间地址，及大小。
    void *mapped;
    // 分配内存的大小，默认是128K
    size_t mapsize;
};

九、结构体binder_buffer

binder_buffer 内核缓冲区，用以在进程间传递数据。binder驱动程序管理这个内存映射地址空间方法，即管理buffer~（buffer+buffer_size）这段地址空间的，这个地址空间被划分为一段一段来管理，每一段是结构体struct binder_buffer来描述。每一个binder_buffer通过其成员entry从低到高地址连入到struct binder_proc中的buffers表示链表中去

1、代码位置

位置在
Linux的binder.c 298行

2、代码注释

struct binder_buffer {
        //entry对应内核缓冲区列表的buffers(内核缓冲区列表)
        struct list_head entry; /* free and allocated entries by address */
        //结合free,如果free=1，则rb_node对应free_buffers中一个节点(内核缓冲区)
        //如果free!=1，则对应allocated_buffers中的一个节点
        struct rb_node rb_node; /* free entry by size or allocated entry */
                /* by address */
        unsigned free:1;

         /**  Binder将事务数据保存到一个内核缓冲区(binder_transaction.buffer)，然后交由Binder
          * 实体对象(target_node) 处理，而target_node会将缓冲区的内容交给对应的Service组件
          * (proc) 来处理，Service组件处理完事务后，若allow_user_free=1，则请求Binder释放该
          * 内核缓冲区
          */
        unsigned allow_user_free:1;
         // 描述一个内核缓冲区正在交给那个事务transaction，用以中转请求和返回结果
        struct binder_transaction *transaction;
         // 描述该缓冲区正在被那个Binder实体对象使用
        struct binder_node *target_node;

        //表示事务时异步的；异步事务的内核缓冲区大小是受限的，这样可以保证事务可以优先放到缓冲区
        unsigned async_transaction:1;
         //调试专用
        unsigned debug_id:29;

        /** 
         *  存储通信数据，通信数据中有两种类型数据：普通数据与Binder对象
         *  在数据缓冲区最后，有一个偏移数组，记录数据缓冲区中每一个Binder
         *  对象在缓冲区的偏移地址
         */
        //  数据缓冲区大小
        size_t data_size;
        // 偏移数组的大小(其实也是偏移位置)
        size_t offsets_size;
        // 用以保存通信数据，数据缓冲区，大小可变
        uint8_t data[0];
        // 额外缓冲区大小
        size_t extra_buffers_size;
};

十、结构体binder_transaction

** binder_transaction ** 描述Binder进程中通信过程，这个过程称为一个transaction(事务)，用以中转请求和返回结果，并保存接受和要发送的进程信息

1、代码位置

位置在
Linux的binder.c 383行

2、代码注释

struct binder_transaction {
        //调试调用
        int debug_id;
        // 用来描述的处理的工作事项，这里会将type设置为BINDER_WORK_TRANSACTION，具体结构看binder_work
        struct binder_work work;

        /**   源线程 */
        // 源线程，即发起事务的线程
        struct binder_thread *from;
        // 源线程的优先级
        long    priority;
        //源 线程的用户 ID
        kuid_t  sender_euid;

        /**  目标线程*/
        //  目标进程:处理该事务的进程
        struct binder_proc *to_proc;
        // 目标线程：处理该事务的线程
        struct binder_thread *to_thread;
   
         // 表示另一个事务要依赖事务(不一定要在同一个线程中)
        struct binder_transaction *from_parent;
         // 目标线程下一个需要处理的事务
        struct binder_transaction *to_parent;

        // 标志事务是同步/异步；设为1表示同步事务，需要等待对方回复；设为0异步
        unsigned need_reply:1;
        /* unsigned is_dead:1; */   /* not used at the moment */
     
        /* 参考binder_buffer中解释，指向Binder为该事务分配内核缓冲区
         *  code与flag参见binder_transaction_data
         */
        struct binder_buffer *buffer;
        unsigned int    code;
        unsigned int    flags;

        /**  目标线程设置事务钱，Binder需要修改priority；修改前需要将线程原来的priority保存到
         *    saved_priority中，用以处理完事务回复到原来优先级
         *   优先级设置：目标现场处理事务时，优先级应不低于目标Serivce要求的线程优先级，也
         *   不低于源线程的优先级，故设为两者的较大值。
         */
        long    saved_priority;

};

十一、结构体binder_transaction_data

binder_transaction_data 代表进程间通信所传输的数据：Binder对象的传递时通过binder_transaction_data来实现的，即Binder对象实际是封装在binder_transaction_data结构体中

1、代码位置

位置在
Linux的binder.h 217行

2、代码注释

struct binder_transaction_data {
         //target很重要，我下面重点介绍
         /* The first two are only used for bcTRANSACTION and brTRANSACTION,
         * identifying the target and contents of the transaction.
         */
         union {
               /* target descriptor of command transaction */
               __u32    handle;
               /* target descriptor of return transaction */
               binder_uintptr_t ptr;
         } target;
      
         //Binder实体带有的附加数据
         binder_uintptr_t   cookie; /* target object cookie */
         // code是一个命令，描述了请求Binder对象执行的操作，表示要对目标对象请求的命令代码
         __u32      code;       /* transaction command */

         /* General information about the transaction. */
         // 事务标志，详细看transaction_flag结构体
         __u32          flags;
         // 发起请求的进程PID
         pid_t      sender_pid;
         // 发起请求的进程UID
         uid_t      sender_euid;
         // data.buffer缓冲区的大小，data见最下面的定义；命令的真正要传输的数据就保存data.buffer缓冲区
         binder_size_t  data_size;  /* number of bytes of data */
          // data.offsets缓冲区的大小
         binder_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 */
                        binder_uintptr_t    buffer;
                        /* offsets from buffer to flat_binder_object structs */
                        binder_uintptr_t    offsets;
               } ptr;
               __u8 buf[8];
         } data;
};

这里重点说两个共用体target和data
target

一个共用体target，当这个BINDER_WRITE_READ命令的目标对象是本地Binder的实体时，就用ptr来表示这个对象在本进程的地址，否则就使用handle来表示这个Binder的实体引用。

只有目标对象是Binder实体时，cookie成员变量才有意义，表示一些附加数据。
详解解释一下：传输的数据是一个复用数据联合体，对于BINDER类型，数据就是一个Binder本地对象。如果是HANDLE类型，这个数据就是远程Binder对象。很多人会说怎么区分本地Binder对象和远程Binder对象，主要是角度不同而已。本地对象还可以带有额外数据，保存在cookie中。

data

• 命令的真正要传输的数据就保存在data.buffer缓冲区中，前面的一成员变量都是一些用来描述数据的特征。data.buffer所表示的缓冲区数据分为两类，一类是普通数据，Binder驱动程序不关心，一类是Binder实体或者Binder引用，这需要Binder驱动程序介入处理。为什么?因为如果一个进程A传递了一个Binder实体或Binder引用给进程B，那么，Binder驱动程序就需要介入维护这个Binder实体或者引用引用计数。防止B进程还在使用这个Binder实体时，A却销毁这个实体，这样的话，B进程就会crash了。所以在传输数据时，如果数据中含有Binder实体和Binder引用，就需要告诉Binder驱动程序他们的具体位置，以便Binder驱动程序能够去维护它们。data.offsets的作用就在这里，它指定在data.buffer缓冲区中，所以Binder实体或者引用的偏移位置。
• 进程间传输的数据被称为Binder对象(Binder Object)，它是一个flat_binder_object。Binder对象的传递时通过binder_transaction_data来实现的，即Binder对象实际是封装在binder_transaction_data结构体中。

十二、结构体transaction_flags

transaction_flags 描述传输方式，比如同步或者异步等

1、代码位置

位置在
Linux的binder.h 210行

2、代码注释

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 */
        // 表示data所描述的数据缓冲区内 同时一个4bit的状态码
        TF_STATUS_CODE  =  0x08,    /* contents are a 32-bit status code */
        // 允许数据中包含文件描述
        TF_ACCEPT_FDS   =  0x10,    /* allow replies with file descriptors */
};

十三、结构体flat_binder_object

flat_binder_object 描述进程中通信过程中传递的Binder实体/引用对象或文件描述符

1、代码位置

位置在
Linux的binder.h 68行

2、代码注释

/*
 * This is the flattened representation of a Binder object for transfer
 * between processes.  The 'offsets' supplied as part of a binder transaction
 * contains offsets into the data where these structures occur.  The Binder
 * driver takes care of re-writing the structure type and data as it moves
 * between processes.
 */
struct flat_binder_object {
    struct binder_object_header hdr;
    __u32               flags;

    /* 8 bytes of data. */
    union {
        binder_uintptr_t    binder; /* local object */
        __u32           handle; /* remote object */
    };

    /* extra data associated with local object */
    binder_uintptr_t    cookie;
};

这个比较重要我们就一个一个来说，首先看下struct binder_object_header hdr;
里面涉及到一个结构体binder_object_header，这个结构体在Linux的binder.h 57行，代码如下：

/**
 * struct binder_object_header - header shared by all binder metadata objects.
 * @type:   type of the object
 */
struct binder_object_header {
    __u32        type;
};

flat_binder_object通过type来区分描述类型，可选的描述类型如下：
代码在
Linux的binder.h 30行

enum {
        //强类型Binder实体对象
    BINDER_TYPE_BINDER  = B_PACK_CHARS('s', 'b', '*', B_TYPE_LARGE),
        //弱类型Binder实体对象
    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_TYPE_FDA     = B_PACK_CHARS('f', 'd', 'a', B_TYPE_LARGE),
    BINDER_TYPE_PTR     = B_PACK_CHARS('p', 't', '*', B_TYPE_LARGE),
};

当描述实体对象时，cookie表示Binder实体对应的Service在用户空间的本地Binder(BBinder)地址，binder表示Binder实体对应的当描述引用对象时，handle表示该引用的句柄值。

PS:

关于BINDER_TYPE_FDA和BINDER_TYPE_PTR我也不是很清楚，有懂的兄弟，在下面留言，谢谢

十四、结构体binder_write_read

binder_write_read 描述进程间通信过程中所传输的数据

1、代码位置

位置在
Linux的binder.h 165行

2、代码注释

/*
 * On 64-bit platforms where user code may run in 32-bits the driver must
 * translate the buffer (and local binder) addresses appropriately.
 */

struct binder_write_read {

        /** 输入数据 从用户控件传输到Binder驱动程序的数据
         *  数据协议代码为命令协议码，由binder_driver_command_protocol定义
         */
        // 写入的大小
        binder_size_t       write_size; /* bytes to write */
        // 记录了从缓冲区取了多少字节的数据
        binder_size_t       write_consumed; /* bytes consumed by driver */
        // 指向一个用户控件缓冲区的地址，里面的内容即为输入数据，大小由write_size指定
        binder_uintptr_t    write_buffer;
        
         /** 输出数据，从Binder驱动程序，返回给用户空间的数据
          *  数据协议代码为返回协议代码，由binder_driver_return_protocol定义
          */
        //读出的大小
        binder_size_t       read_size;  /* bytes to read */
        // read_buffer中读取的数据量
        binder_size_t       read_consumed;  /* bytes consumed by driver */
        // 指向一个用户缓冲区一个地址，里面保存输出的数据
        binder_uintptr_t    read_buffer;
};

里面涉及到两个协议，我们就在这里详细讲解下

3、binder_driver_command_protocol协议

代码在Linux的binder.h 366行

enum binder_driver_command_protocol {
      
        /**  下面这两个命令数据类型为binder_transaction_data，是最常用到的 */
        /**一个Client进程请求目标进程执行某个事务时，会使用BC_TRANSACTION请求Binder驱
         *动程序将通信数据传递到Server目标进程
         * 使用者：Client进程   用处：传递数据
         */ 
        BC_TRANSACTION = _IOW('c', 0, struct binder_transaction_data),
         /** 当Server目标进程处理完事务后，会使用BC_REPLY请求Binder将结果返回给Client源进程
          * 使用者：Server进程  用处：返回数据
          */
        BC_REPLY = _IOW('c', 1, struct binder_transaction_data),


        /*
         * binder_transaction_data: the sent command.
         */
        //当前版本not support  在Linux中的binder.c就是这么写的
        BC_ACQUIRE_RESULT = _IOW('c', 2, __s32),

        /*
         * not currently supported
         * int:  0 if the last BR_ATTEMPT_ACQUIRE was not successful.
         * Else you have acquired a primary reference on the object.
         */

        // 数据类型为int类型，指向Binder内部一块内核缓冲区
        // 目标进程处理完源进程事务后，会使用BC_FREE_BUFFER来释放缓冲区
        BC_FREE_BUFFER = _IOW('c', 3, binder_uintptr_t),
    /*
     * void *: ptr to transaction data received on a read
     */

        //通信类型为int类型，表示binder_ref的句柄值handle
        // 增加弱引用数
        BC_INCREFS = _IOW('c', 4, __u32),
        // 减少弱引用数
        BC_DECREFS = _IOW('c', 7, __u32),
        // 增加强引用数
        BC_ACQUIRE = _IOW('c', 5, __u32),
        // 减少强引用数
        BC_RELEASE = _IOW('c', 6, __u32),
    
        /*
         * int: descriptor
         */
        /** Service进程完成增加强/弱引用的计数后，会使用这两个命令通知Binder */
        // 增加强引用计数后
        BC_INCREFS_DONE = _IOW('c', 8, struct binder_ptr_cookie),
        //增加弱引用计数后
        BC_ACQUIRE_DONE = _IOW('c', 9, struct binder_ptr_cookie),

        /*
         * void *: ptr to binder
         * void *: cookie for binder
         */
        //当前版本不支持 
        BC_ATTEMPT_ACQUIRE = _IOW('c', 10, struct binder_pri_desc),

        /*
         * not currently supported
         * int: priority
         * int: descriptor
         */
        // Binder驱动程序 请求进程注册一个线程到它的线程池中，新建立线程会使用
        //BC_REGISTER_LOOPER来通知Binder准备就绪
        BC_REGISTER_LOOPER = _IO('c', 11),

        /*
         * No parameters.
         * Register a spawned looper thread with the device.
         */
        //一个线程自己注册到Binder驱动后，会使用BC_ENTER_LOOPER通知Binder准备就绪
        BC_ENTER_LOOPER = _IO('c', 12),
        // 线程发送退出请求
        BC_EXIT_LOOPER = _IO('c', 13),

        /*
         * No parameters.
         * These two commands are sent as an application-level thread
         * enters and exits the binder loop, respectively.  They are
         * used so the binder can have an accurate count of the number
         * of looping threads it has available.
         */
        // 进程向Binder注册一个死亡通知
        BC_REQUEST_DEATH_NOTIFICATION = _IOW('c', 14,
                        struct binder_handle_cookie),
        /*
         * int: handle
         * void *: cookie
         */
         // 进程取消之前注册的死亡通知
        BC_CLEAR_DEATH_NOTIFICATION = _IOW('c', 15,
                        struct binder_handle_cookie),
        /*
         * int: handle
         * void *: cookie
         */
        // 数据指向死亡通知binder_ref_death的地址，进程获得Service组件的死亡通知，
        // 会使用该命令通知Binder其已经处理完死亡通知
        BC_DEAD_BINDER_DONE = _IOW('c', 16, binder_uintptr_t),
        /*
         * void *: cookie
         */

        BC_TRANSACTION_SG = _IOW('c', 17, struct binder_transaction_data_sg),
        BC_REPLY_SG = _IOW('c', 18, struct binder_transaction_data_sg),
        /*
         * binder_transaction_data_sg: the sent command.
         */
};

在上述枚举命令成员中，最重要的是BC_TRANSACTION和BC_REPLY命令，被作为发送操作的命令，其数据参数都是binder_transaction_data结构体。其中前者用于翻译和解析将要被处理的事务数据，而后者则是事务处理完成之后对返回"结果数据"的操作命令。

4、binder_driver_return_protocol协议

Binder驱动的响应（返回，BR_）协议，定义了Binder命令的数据返回格式。

代码在Linux的binder.h 278行

enum binder_driver_return_protocol {
         // Binder驱动程序处理进程发送的请求时，发生异常，在返回BR_ERROR通知该进程
         // 数据类型为int，表示错误代码
        BR_ERROR = _IOR('r', 0, __s32),
    /*
     * int: error code
     */

        // 表示通知进程成功处理了该事务
        BR_OK = _IO('r', 1),
    /* No parameters! */
        
        // 与上面的 BC_ 相对应
        //  Client进程向Server进程发送通信请求(BC_) ，Binder使用BR_TRANSACTION通知Server
        // 使用者 :   Binder驱动程序     用途：通知Server
        BR_TRANSACTION = _IOR('r', 2, struct binder_transaction_data),
        // Server处理完 请求 使用 BC_ 通知Binder，Binder使用BR_REPLY通知Client
        // 使用者：Binder驱动程序，用途：通知Client
        BR_REPLY = _IOR('r', 3, struct binder_transaction_data),
    /*
     * binder_transaction_data: the received command.
     */

         // 当前不支持 
        BR_ACQUIRE_RESULT = _IOR('r', 4, __s32),
    /*
     * not currently supported
     * int: 0 if the last bcATTEMPT_ACQUIRE was not successful.
     * Else the remote object has acquired a primary reference.
     */

        // Binder处理请求时，发现目标进程或目标线程已经死亡，通知源进程
        BR_DEAD_REPLY = _IO('r', 5),
    /*
     * The target of the last transaction (either a bcTRANSACTION or
     * a bcATTEMPT_ACQUIRE) is no longer with us.  No parameters.
     */

        // Binder 接收到BC_TRANSACATION或BC_REPLY时，会返回 BR_TRANSACTION_COMPLETE通知源进程命令已经接收
        BR_TRANSACTION_COMPLETE = _IO('r', 6),
    /*
     * No parameters... always refers to the last transaction requested
     * (including replies).  Note that this will be sent even for
     * asynchronous transactions.
     */

        // 增加弱引用计数
        BR_INCREFS = _IOR('r', 7, struct binder_ptr_cookie),
        // 增加强引用计数
        BR_ACQUIRE = _IOR('r', 8, struct binder_ptr_cookie),
        // 减少强引用计数
        BR_RELEASE = _IOR('r', 9, struct binder_ptr_cookie),
         // 减少弱引用计数
        BR_DECREFS = _IOR('r', 10, struct binder_ptr_cookie),
    /*
     * void *:  ptr to binder
     * void *: cookie for binder
     */

         //当前不支持
        BR_ATTEMPT_ACQUIRE = _IOR('r', 11, struct binder_pri_ptr_cookie),
    /*
     * not currently supported
     * int: priority
     * void *: ptr to binder
     * void *: cookie for binder
     */

        // Binder通过源进程执行了一个空操作，用以可以替换为BR_SPAWN_LOOPER
        BR_NOOP = _IO('r', 12),
    /*
     * No parameters.  Do nothing and examine the next command.  It exists
     * primarily so that we can replace it with a BR_SPAWN_LOOPER command.
     */

         // Binder发现没有足够的线程处理请求时，会返回BR_SPAWN_LOOPER请求增加新的新城到Binder线程池中
        BR_SPAWN_LOOPER = _IO('r', 13),
    /*
     * No parameters.  The driver has determined that a process has no
     * threads waiting to service incoming transactions.  When a process
     * receives this command, it must spawn a new service thread and
     * register it via bcENTER_LOOPER.
     */

         // 当前暂不支持
        BR_FINISHED = _IO('r', 14),
    /*
     * not currently supported
     * stop threadpool thread
     */


        /** Binder检测到Service组件死亡时，使用BR_DEAD_BINDER通知Client进程，Client请求
         *  注销之前的死亡通知，Binder完成后，返回BR_CLEAR_DEATH_NOTIFACTION_DONE
         */
        // 告诉发送方对象已经死亡
        BR_DEAD_BINDER = _IOR('r', 15, binder_uintptr_t),

    /*
     * void *: cookie
     */
        //清理死亡通知
        BR_CLEAR_DEATH_NOTIFICATION_DONE = _IOR('r', 16, binder_uintptr_t),
    /*
     * void *: cookie
     */

         // 发生异常，通知源进程
        BR_FAILED_REPLY = _IO('r', 17),
    /*
     * The the last transaction (either a bcTRANSACTION or
     * a bcATTEMPT_ACQUIRE) failed (e.g. out of memory).  No parameters.
     */
};

5、Binder通信协议流程

单独看上面的协议可能很难理解，这里我们以一次Binder请求为过程来详细看一下Binder协议是如何通信的，就比较好理解了。这幅图的说明如下：

• 1 Binder是C/S架构的，通信过程牵涉到Client、Server以及Binder驱动三个角色
• 2 Client对于Server的请求以及Server对于Client的回复都需要通过Binder驱动来中转数据
• 3 BC_XXX命令是进程发送给驱动命令
• 4 BR_XXX命令是驱动发送给进程的命令
• 5 整个通信过程由Binder驱动控制

Binder通信过程.png

PS:这里补充说明一下，通过上面的Binder协议的说明，我们看到，Binder协议的通信过程中，不仅仅是发送请求和接收数据这些命令。同时包括了对于引用计数的管理和对于死亡通知的管理(告知一方，通讯的另外一方已经死亡)。这个功能的流程和上述的功能大致一致。

十五、结构体binder_ptr_cookie

binder_ptr_cookie 用来描述一个Binder实体对象或一个Service组件的死亡通知

1、代码位置

位置在
Linux的binder.h 257行

2、代码注释

struct binder_ptr_cookie {
    binder_uintptr_t ptr;
    binder_uintptr_t cookie;
};

• 当描述Binder实体对象：ptr,cookie见binder_node
• 当描述死亡通知：ptr指向一个Binder引用对象的句柄值，cookie指向接收死亡通知的对象地址

十六、总结

结构体就是这样的

image.png

如果以结构体为标的来看整个Binder传输过程则如下：

结构体为标的.png