想掌握Android面试官必问的 Binder 机制？那别想绕开 Binder 驱动源码分析！(1)

binder_fops 为 Binder 设备支持的操作函数，如下：

static const struct file_operations binder_fops = {

.owner = THIS_MODULE,

.poll = binder_poll,

.unlocked_ioctl = binder_ioctl,

.mmap = binder_mmap,

.open = binder_open,

.flush = binder_flush,

.release = binder_release,

};

binder_open

用户应用程序通过 Binder 通信时，需先调用 binder_open() 方法打开 binder 驱动，binder_open() 中主要做了两个工作，对应的分为两部分来看：

//binder.c

static int binder_open(struct inode *nodp, struct file *filp)

{

struct binder_proc *proc;

…

proc = kzalloc(sizeof(*proc), GFP_KERNEL); //创建 binder_proc

if (proc == NULL)

return -ENOMEM;

get_task_struct(current);

proc->tsk = current;

INIT_LIST_HEAD(&proc->todo); //初始化 todo 队列

init_waitqueue_head(&proc->wait); //初始化 todo 队列

proc->default_priority = task_nice(current);

上面代码的主要工作是 「创建及初始化 binder_proc」，binder_proc 就是用来存放 binder 相关数据的结构体，每个进程独有一份。

binder_lock(func);

binder_stats_created(BINDER_STAT_PROC);

hlist_add_head(&proc->proc_node, &binder_procs);

proc->pid = current->group_leader->pid;

INIT_LIST_HEAD(&proc->delivered_death);

filp->private_data = proc;

binder_unlock(func);

…

}

第二个主要工作是 「将 binder_proc 记录起来」，方便后续使用，如上代码所示，通过 hlist_add_head() 方法将 binder_proc 记录到了内核的 binder_procs 表中，另外还将 binder_proc 存放在 filp 的 private_data 域，以便于在后续调用 mmap、ioctl 等方法时获取。

binder_mmap

对于 binder 驱动来说，上层应用调用的 mmap() 最终会执行到 binder_mmap() 方法，binder_mmap() 的主要工作是**「将上层应用的虚拟内存块和 Binder 申请的物理内存块建立映射」**，应用程序和 Binder 就拥有了共享的内存空间，这样不同的应用程序之间可以通过 Binder 实现数据共享。

• Binder 中有一物理内存块 P；B 进程中有一内存块 b

• 将 P 分别与 b 建立映射，这样 P、b 就可以看作同一块内存

• 若 A 进程想要发送数据给 B 进程，只需将数据拷贝到 P 内存，B 进程就能直接读取到了

所以 Binder 只需一次拷贝，binder_mmap() 要做的就是将 P 与 b 建立映射，该方法代码较长，分段看关键部分代码：

static int binder_mmap(struct file *filp, struct vm_area_struct *vma){

struct vm_struct *area;

struct binder_proc *proc = filp->private_data;

const char *failure_string;

struct binder_buffer *buffer;

//映射空间至多 4M

if ((vma->vm_end - vma->vm_start) > SZ_4M)

vma->vm_end = vma->vm_start + SZ_4M;

//检查 vma 是否被禁用

if (vma->vm_flags & FORBIDDEN_MMAP_FLAGS) {

ret = -EPERM;

failure_string = “bad vm_flags”;

goto err_bad_arg;

}

• vma(vm_area_struct) 是**「用户态虚拟内存地址空间」**，也就是 b

• area(vm_struct) 是**「内核态虚拟地址空间」**，指向 P

• proc(binder_proc) 即 binder_open() 中创建的、存放 binder 相关数据的结构体

• 另外还做了限制映射空间至多 4M 等映射规则的检查和处理

mutex_lock(&binder_mmap_lock);

//检查是否已执行过 binder_mmap 映射过

if (proc->buffer) {

ret = -EBUSY;

failure_string = “already mapped”;

goto err_already_mapped;

}

//申请内核虚拟内存地址空间

area = get_vm_area(vma->vm_end - vma->vm_start, VM_IOREMAP);

if (area == NULL) {

ret = -ENOMEM;

failure_string = “get_vm_area”;

goto err_get_vm_area_failed;

}

//将内核虚拟内存地址记录在 proc 中

proc->buffer = area->addr;

//记录用户态虚拟内存地址和内核态虚拟内存地址的偏移量

proc->user_buffer_offset = vma->vm_start - (uintptr_t)proc->buffer;

mutex_unlock(&binder_mmap_lock);

• proc->buffer 用于存储最终映射的内核态虚拟地址，并通过此变量控制只能映射一次

• get_vm_area() 方法申请了与用户态空间大小一致的内核态虚拟地址空间，注意此时还没分配实际的物理内存

• proc->user_buffer_offset 记录了用户态虚拟内存和内核态虚拟内存地址的偏移量，这样后续方便获取用户态虚拟内存地址

//分配存放物理页地址的数组

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;

//申请一页物理内存

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

ret = -ENOMEM;

failure_string = “alloc small buf”;

goto err_alloc_small_buf_failed;

}

//最后的收尾工作：将内存记录到相应链表中，设置状态等

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;

proc->files = get_files_struct(current);

proc->vma = vma;

• proc->pages 是一个二维指针，用于存放管理物理页面

• binder_update_page_range() 方法真正的申请物理页面，并分别映射到内核态和用户态的虚拟内存地址空间

至此 binder_mmap 方法执行结束，我们继续分析**「binder_update_page_range()」** 方法，此方法代码非常有助于我们理解页框以及与虚拟内存地址的映射逻辑。先了解此方法的参数：

• proc：申请内存的进程所持有的 binder_proc 对象

• allocate：1 表示申请内存，0 表示释放内存

• start：虚拟内存地址起点

• end：虚拟内存地址终点

• vma：用户态虚拟内存地址空间

static int binder_update_page_range(struct binder_proc *proc, int allocate,

void *start, void *end,

struct vm_area_struct *vma){

if (allocate == 0) //区分是申请还是释放

goto free_range;

//依据 start、end 循环分配物理页

for (page_addr = start; page_addr < end; page_addr += PAGE_SIZE) {

//每次分配 1 个页框*/

*page = alloc_page(GFP_KERNEL | __GFP_HIGHMEM | __GFP_ZERO);

//将页框映射到内核态虚拟内存地址

ret = map_kernel_range_noflush((unsigned long)page_addr, PAGE_SIZE, PAGE_KERNEL, page);

//根据 binder_mmap 方法中记录的偏移量计算出用户态虚拟内存地址

user_page_addr = (uintptr_t)page_addr + proc->user_buffer_offset;

//将页框映射到用户态虚拟内存地址

ret = vm_insert_page(vma, user_page_addr, page[0]);

}

return 0;

binder_mmap() 的 allocate 参数传入 1 为申请内存，执行上面的代码。若为释放则执行以下代码：

free_range:

//依据 start、end 从后往前遍历

for (page_addr = end - PAGE_SIZE; page_addr >= start; page_addr -= PAGE_SIZE) {

page = &proc->pages[(page_addr - proc->buffer) / PAGE_SIZE];

if (vma)

//解除用户态虚拟地址和物理页框的映射

zap_page_range(vma, (uintptr_t)page_addr + proc->user_buffer_offset, PAGE_SIZE, NULL);

err_vm_insert_page_failed:

//解除内核态虚拟地址和物理页框的映射

unmap_kernel_range((unsigned long)page_addr, PAGE_SIZE);

err_map_kernel_failed:

//释放页框物理内存

__free_page(*page);

*page = NULL;

}

binder_ioctl

binder 驱动并不提供常规的 read()、write() 等文件操作，全部通过 binder_ioctl() 实现，所以 binder_ioctl() 是 binder 驱动中工作量最大的一个，它承担了 binder 驱动的大部分业务。这里不深入分析源码，只列出 binder_ioctl() 支持的命令列表：

| 命令 | 说明 |

| — | — |

| BINDER_WRITE_READ | 向 binder 驱动写入或读取数据 |

| BINDER_SET_MAX_THREADS | 设置支持的最大线程数 |

| BINDER_SET_CONTEXT_MGR | Service Manager 专用的注册命令 |

| BINDER_THREAD_EXIT | 通知 binder 驱动某线程退出，释放相应资源 |

| BINDER_VERSION | 获取 Binder 版本号 |

其中 BINDER_WRITE_READ 最为关键，分为若干子命令：

| 命令 | 说明 |

| — | — |

| BC_INCREFS、BC_ACQUIRE、BC_RELEASE、BC_DECREFS | 管理 binder_ref 的引用计数 |

| BC_INCREFS_DONE、BC_ACQUIRE_NODE | 管理 binder_node 的引用计数 |

| BC_FREE_BUFFER | 释放 Binder 内存缓冲区 |

| BC_TRANSACTION | 向 binder 驱动发送通信数据(主动调用) |

| BC_REPLY | 向 binder 驱动发送通信数据(返回结果) |

| BC_REGISTER_LOOPER、BC_ENTER_LOOPER、BC_EXIT_LOOPER | 设置 Binder looper 状态 |

| BC_REQUEST_DEATH_NOTIFICATION | 注册 Binder 死亡通知 |

| BC_CLEAR_DEATH_NOTIFICATION | 清除 Binder 死亡通知 |

| BC_DEAD_BINDER_DONE | 告知 Binder 已处理完 Binder 死亡通知 |

以上均为 binder 驱动作为接收方 binder_ioctl() 方法接收的命令，还有一些与之对应的 BR_ 开头的命令，由 binder 驱动主动发出，比如 BR_TRANSACTION、BR_REPLY，在一次 IPC 调用中是这样应用的：
自我介绍一下，小编13年上海交大毕业，曾经在小公司待过，也去过华为、OPPO等大厂，18年进入阿里一直到现在。

深知大多数初中级Android工程师，想要提升技能，往往是自己摸索成长或者是报班学习，但对于培训机构动则近万的学费，着实压力不小。自己不成体系的自学效果低效又漫长，而且极易碰到天花板技术停滞不前！

因此收集整理了一份《2024年Android移动开发全套学习资料》，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友，同时减轻大家的负担。

既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，基本涵盖了95%以上Android开发知识点，真正体系化！

由于文件比较大，这里只是将部分目录截图出来，每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频，并且会持续更新！

如果你觉得这些内容对你有帮助，可以扫码获取！！（备注：Android）

重要知识点

下面是有几位Android行业大佬对应上方技术点整理的一些进阶资料。

高级进阶篇——高级UI，自定义View（部分展示）

UI这块知识是现今使用者最多的。当年火爆一时的Android入门培训，学会这小块知识就能随便找到不错的工作了。不过很显然现在远远不够了，拒绝无休止的CV,亲自去项目实战，读源码，研究原理吧！

• 面试题部分合集
  

《互联网大厂面试真题解析、进阶开发核心学习笔记、全套讲解视频、实战项目源码讲义》点击传送门即可获取！

重要知识点

下面是有几位Android行业大佬对应上方技术点整理的一些进阶资料。

[外链图片转存中…(img-oOzzWejm-1713614806468)]

高级进阶篇——高级UI，自定义View（部分展示）

UI这块知识是现今使用者最多的。当年火爆一时的Android入门培训，学会这小块知识就能随便找到不错的工作了。不过很显然现在远远不够了，拒绝无休止的CV,亲自去项目实战，读源码，研究原理吧！

[外链图片转存中…(img-8hBo23Ot-1713614806469)]

• 面试题部分合集
  [外链图片转存中…(img-koeI4p1d-1713614806470)]

《互联网大厂面试真题解析、进阶开发核心学习笔记、全套讲解视频、实战项目源码讲义》点击传送门即可获取！