Android Binder为何需要mmap？为何用ioctl而非mmap收发数据？

首先纠正一个普遍的认知偏差：Binder实现里的mmap从来不是用来开放给用户态直接读写、替代ioctl做数据传输的，两者是分工配合的关系，核心目标是在保证IPC安全可控、调度有序的前提下，实现跨进程数据的单次拷贝，比传统管道、Socket类IPC少一次内存拷贝开销。

为什么不能跳过ioctl，直接读写mmap映射的共享内存收发数据？ #

根本原因是Binder不是无管控的裸共享内存IPC，它是带权限校验、对象生命周期管理、调度能力的面向对象IPC机制，直接开放映射区读写会直接击穿核心设计：

• 没有安全边界：如果允许用户态随意写mmap区域，内核无法校验写入的事务是否合法——比如目标Binder句柄是不是当前进程有权访问的、传递的Binder对象引用是不是伪造的、事务结构有没有被恶意篡改，也没法在事务流转时自动做Binder引用计数增减、死亡通知投递、UID/PID身份校验这些安全逻辑，整个IPC机制完全不可控。
• 没有事务调度能力：Binder的请求-响应模型是内核统一调度的，事务入队、对端进程唤醒、阻塞等待超时、事务优先级继承这些逻辑，都需要一个明确的系统调用入口触发内核介入。如果跳过ioctl直接写内存，内核根本感知不到有新的事务产生，总不能让接收端进程一直轮询映射区等新数据，功耗和性能都完全没法用在移动端场景。

那mmap的实际作用是什么？为什么不能在binder_open流程里直接分配缓冲区？ #

mmap的核心价值根本不是“给用户态分一块能读写的内存”，而是建立物理内存的内核态/用户态双映射，这是实现单次拷贝的核心：

• 当进程调用binder_mmap时，内核会申请一段物理内存页，同时将这段页映射到当前进程的用户态地址空间、以及内核自身的地址空间。当发送方通过ioctl提交跨进程发送请求时，内核只需要通过一次copy_from_user，把发送方用户态构造好的事务数据，直接写入接收方进程对应的双映射物理页里，接收方不需要再经过一次copy_to_user，直接读自己用户态映射的地址就能拿到数据——这就是Binder号称“一次拷贝”的本质，这个双映射能力是mmap独有的，你在binder_open里用普通内核内存分配接口（比如kmalloc）申请的内存只有内核能访问，根本没法映射给用户态直接读，传数据的时候还得多做一次从内核到用户态的拷贝，性能直接掉一档。
• 至于为什么不把mmap的逻辑合并到binder_open里，本质是资源利用效率的考虑：mmap的地址空间是预留的，物理页是实际访问时才通过缺页中断按需分配的，不需要一开始就占住固定大小的物理内存；同时不同进程的Binder通信需求差异极大，有的进程几乎不用Binder，有的进程（比如system_server）需要几兆的Binder缓冲区，把mmap做成独立调用，可以让进程根据自身需求传入要映射的缓冲区大小，比open时硬编码固定大小灵活太多，也不会浪费内存。

补充一点：读源码看到的copy_from_user/copy_to_user，只有传输小的控制指令、读写事务返回值的时候才会走，真正大块的跨进程业务数据，全是靠mmap的双映射区域完成传输的，ioctl本质上只是个控制入口，负责告诉内核“我要发/收数据了，帮我做校验、调度、拷贝、唤醒”，从来不是用来传全量数据的通道。

内容的提问来源于stack exchange，提问作者Daniel.W