Android Binder通信02 - 驱动分析 - 架构介绍
一、前言：
上一篇文章介绍了Binder通信系统Framework（用户态）的架构，并且结合代码说明了下注册ServiceManager，注册服务，注册客户端，客户端和服务端通信的业务场景，本节我们继续深入挖掘下，Framework层调用响应API之后，驱动层（内核态）如何处理的，这才是Binder系统的精髓所在！
二、架构图：
- 在内核态驱动里，会为每一个服务创建一个
binder_node，记录了进程的信息，比如：binder_node.proc=server进程； ServiceManager启动时候，会在驱动层创建一个全局的binder_node保存到binder_context_mgr_node当中；其他进程都有一个BpServiceManager，它的BpBinder句柄是0，表示binder_context_mgr_node，所以，其他进程都是可以直接和ServiceManager通信的。ServiceManager还会再驱动中创建一个binder_ref（是个红黑树），它是binder_node的引用；ServiceManager在用户态创建一个服务链表svcinfo，里面保存了name和handle；Client向ServiceManager查询某个服务的时候，只需要传入name（因为它好记，友好）；ServiceManager就在链表中根据name找到这个节点，将对应的handle（因为它不好记，但是它不容易重复）传给驱动层；- 驱动程序在
ServiceManager的binder_ref红黑树当中，根据handle这个键找到对应的binder_ref; - 由于
binder_ref当中保存了自己是谁的引用，也就是binder_node，因此，我们就获得了binder_node，代表服务； - 再给
Client创建新的binder_ref，驱动就返回一个handle（这里面是desc，从1开始）client； - 同理，
Client要和Service通信，首先，client根据handle找到binder_ref，再根据binder_ref找到binder_node，最后根据binder_node找到Service进程；
三、关键数据结构:
前面一直说通过这个找到那个，又通过那个找到nie个，你肯定有点蒙圈，这里面涉及几个关键的数据结构，即：binder_node和binder_ref和binder_proc以及binder_thread，我们就重点介绍下。
1、binder_ref:
// 在驱动代码的binder.c当中：
struct binder_ref {
/* Lookups needed: */
/* node + proc => ref (transaction) */
/* desc + proc => ref (transaction, inc/dec ref) */
/* node => refs + procs (proc exit) */
struct binder_ref_data data;
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; // binder_ref就是这个node的引用
struct binder_ref_death *death;
};
看到着里面有个binder_node就表示自己是这个node的引用；
2、binder_node:
struct binder_node {
int debug_id;
spinlock_t lock;
struct binder_work work;
union {
struct rb_node rb_node;
struct hlist_node dead_node;
};
struct binder_proc *proc; // 代表binder_node依附于哪个进程
struct hlist_head refs;
// 省略一部分乱七八糟的代码...
struct list_head async_todo;
};
里面记录了自己依附于哪个进程；
3、binder_proc:
struct binder_proc {
struct hlist_node proc_node;
struct rb_root threads; // 其实就是binder_thread
struct rb_root nodes;
struct list_head todo; // todo链表
// 删除了一些乱起八糟代码...
};
这里面的threads就是binder_thread类型
4、binder_thread：
struct binder_thread {
struct binder_proc *proc; // 同样也记录了自己属于哪个进程
struct list_head todo; // todo链表
// 删除了一些乱七八糟代码...
};
注意，任何人给我发数据都放到我的todo链表中去，更要注意，进程和线程都有todo链表。
5、小结：
- handle在服务端里面是一个数字，表示某个服务；
- handle对应的是一个binder_ref；
- binder_ref里面又有个成员变量node指向这个服务的binder_node；
- binder_node这个服务又依附于某个进程，因此又有个成员变量proc表示进程binder_proc；
- binder_proc里面又有很多线程去处理客户端的请求啊，因此有个成员变量threads（用红黑树实现），表示一个binder_thread；
- binder_thread里面又有个todo链表，需要处理的任务都放到这个里面去；
四、数据传输：
1、数据流转图：
觉得文字比较匮乏，画了一个数据流转图，很直观：
2、数据复制次数：
对于一般应用程序，发送时候Client将数据从用户空间拷贝到内核空间一次，Server接收到之后，要从内核空间拷贝到用户空间一次。数据至少需要复制两次。
但是，对于我们binder系统，Server进程的用户空间和内核空间通过mmap做了映射，所以省去了这一次拷贝。数据只需要拷贝一次。但是注意，数据头还是需要拷贝两次的。
五、总结：
本章着重讲了一下架构，并没有涉及多少代码，后续通过实际用到的情景进行分析代码。