你真的理解Binder“一次拷贝“吗,下血本买的

本文详细解释了内存映射在Android系统中Binder通信过程中的作用,以及用户空间和内核空间如何通过binder_mmap、binder_write_readbwr和copy_from_user等函数进行数据交换和内存映射的操作.

}

}

注意mmap上方的注释,已经说的很清楚了,这块内存映射只是作为接收transactions来使用的,也就是说往驱动写数据的时候是与内存映射无关的。记住这一点。

下面我们看一下内核空间相应的调用:

binder_mmap

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

{

ret = binder_alloc_mmap_handler(&proc->alloc, vma);

}

真正的映射操作由函数binder_alloc_mmap_handler()完成。这里我们只需要记住这个函数的第一个入参&proc->alloc。通过这个结构体我们就能找到映射好的内存块。

内存映射完成之后,就让我们看一下Binder的传输过程中哪里使用到了这块特殊的内存。

Binder传输过程


传输过程我们只关注内存和数据。

发起方用户空间

发起方用户空间做的事情其实就像发快递一样不停的打包,注意一下都包了些啥。

IPCThreadState::writeTransactionData

// 我们要传输的数据在data这个入参中

status_t IPCThreadState::writeTransactionData(… const Parcel& data…)

{

binder_transaction_data tr;

//tr.data.ptr.buffer保存了指向data的指针

tr.data_size = data.ipcDataSize();

tr.data.ptr.buffer = data.ipcData();

tr.offsets_size = data.ipcObjectsCount()*sizeof(binder_size_t);

tr.data.ptr.offsets = data.ipcObjects();

// 将tr写入mOut。

mOut.writeInt32(cmd);

mOut.write(&tr, sizeof(tr));

return NO_ERROR;

}

这里tr只保存了指向数据的指针。然后tr被写入mOut这个Parcel。

IPCThreadState::talkWithDriver

status_t IPCThreadState::talkWithDriver(bool doReceive)

{

binder_write_read bwr;

bwr.write_size = outAvail;

bwr.write_buffer = (uintptr_t)mOut.data();

bwr.write_consumed = 0;

ioctl(mProcess->mDriverFD, BINDER_WRITE_READ, &bwr) >= 0

}

这里又包了一层,bwr。其中bwr.write_buffer保存了指向mOut.data()的指针。在这里也就是指向了tr。

所以在发起方:

  • bwr含有指向tr的指针。

  • tr含有指向data的指针。

记住上面两点,接下来我们看一下内核空间是怎么取包的:

发起方内核空间

binder_ioctl_write_read

static int binder_ioctl_write_read(struct file *filp,

unsigned int cmd, unsigned long arg,

struct binder_thread **threadp)

{ …

void __user *ubuf = (void __user *)arg;

struct binder_write_read bwr;

if (copy_from_user(&bwr, ubuf, sizeof(bwr))) {

ret = -EFAULT;

goto out;

}

ret = binder_thread_write(proc, *threadp,

bwr.write_buffer,

bwr.write_size,

&bwr.write_consumed);

}

这里我们遇到了第一个copy_from_user()调用。这个调用会把用户空间的bwr给拷贝到内核空间。但是要注意,copy_from_user()的第一个入参是拷贝的目标地址,这里给的是&bwr,函数内部的一个结构体。显然此处和内存映射没有关系。接下来就进入binder_thread_write。入参有bwr.write_buffer,回头看用户空间最底层那里,指向的是不是tr?

binder_thread_write

static int binder_thread_write(struct binder_proc *proc,

struct binder_thread *thread,

binder_uintptr_t binder_buffer, size_t size,

binder_size_t *consumed)

{

void __user *buffer = (void __user *)(uintptr_t)binder_buffer;

void __user *ptr = buffer + *consumed;

case BC_TRANSACTION:

case BC_REPLY: {

struct binder_transaction_data tr;

if (copy_from_user(&tr, ptr, sizeof(tr)))

return -EFAULT;

ptr += sizeof(tr);

binder_transaction(proc, thread, &tr,

cmd == BC_REPLY, 0);

break;

}

}

这里我们遇到了第二个copy_from_user()。这回会把用户空间的那个tr,也就是IPCThreadState.mOut,给拷贝到内核中来,看它的第一个入参,还是和内存映射没有关系。接下来就进入关键的binder_transaction()了。

binder_transaction

static void binder_transaction(struct binder_proc *proc,

struct binder_thread *thread,

struct binder_transaction_data *tr, int reply,

binder_size_t extra_buffers_size)

{

struct binder_transaction *t;

t->buffer = binder_alloc_new_buf(&target_proc->alloc, tr->data_size,

tr->offsets_size, extra_buffers_size,

!reply && (t->flags & TF_ONE_WAY));

copy_from_user(t->buffer->data, (const void __user *)(uintptr_t)

tr->data.ptr.buffer, tr->data_size)

自我介绍一下,小编13年上海交大毕业,曾经在小公司待过,也去过华为、OPPO等大厂,18年进入阿里一直到现在。

深知大多数初中级安卓工程师,想要提升技能,往往是自己摸索成长,但自己不成体系的自学效果低效又漫长,而且极易碰到天花板技术停滞不前!

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

由于文件比较大,这里只是将部分目录截图出来,每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频
如果你觉得这些内容对你有帮助,可以添加下面V无偿领取!(备注Android)
img

总结

首先是感觉自己的基础还是不够吧,大厂好像都喜欢问这些底层原理。

另外一部分原因在于资料也还没有看完,一面时凭借那份资料考前突击恶补个几天居然也能轻松应对(在这里还是要感谢那份资料,真的牛),于是自我感觉良好,资料就没有怎么深究下去了。

之前的准备只涉及了Java、Android、计网、数据结构与算法这些方面,面对面试官对其他基础课程的考察显得捉襟见肘。

下一步还是要查漏补缺,进行针对性复习。

最后的最后,那套资料这次一定要全部看完,是真的太全面了,各个知识点都涵盖了,几乎我面试遇到的所有问题的知识点这里面都有!在这里也免费分享给大家,希望大家不要犯和我一样的错误呀!!!一定要看完!


获取方式:点击我的GitHub

,面对面试官对其他基础课程的考察显得捉襟见肘。

下一步还是要查漏补缺,进行针对性复习。

最后的最后,那套资料这次一定要全部看完,是真的太全面了,各个知识点都涵盖了,几乎我面试遇到的所有问题的知识点这里面都有!在这里也免费分享给大家,希望大家不要犯和我一样的错误呀!!!一定要看完!
[外链图片转存中…(img-UJTaRezH-1710739101083)]

[外链图片转存中…(img-Wj53fuB7-1710739101083)]

[外链图片转存中…(img-Jp4hFrXS-1710739101084)]
获取方式:点击我的GitHub

<think>我们正在讨论Binder机制中数据拷贝次数少于Socket的原因。根据引用[2]和引用[4],Binder通过一次拷贝实现进程间通信,而Socket需要两次拷贝。下面我将详细解释这一机制。 ### 1. **Binder一次拷贝机制** Binder使用内存映射(mmap)技术实现一次拷贝。具体过程如下: - **内存映射设置**:在Binder通信初始化时,内核空间和用户空间会映射到同一块物理内存(引用[4])。具体来说: - Binder驱动在内核空间分配一块物理内存。 - 该物理内存同时映射到**目标进程的用户空间**和**内核空间**的虚拟地址上。 - **数据传输过程**: 1. 发送方(客户端)将数据写入自己的用户空间缓冲区。 2. Binder驱动通过`copy_from_user()`将数据从**发送方用户空间**拷贝到**内核空间**的映射区(第一次拷贝)。 3. 由于映射区的物理内存已预先映射到**接收方(服务端)的用户空间**,接收方可以直接读取该数据,无需额外拷贝。 > 因此,Binder的数据传输仅需一次拷贝(从发送方用户空间到内核映射区),接收方通过内存映射直接访问数据(引用[2][4])。 ### 2. **Socket的两次拷贝机制** Socket通信需要两次数据拷贝: 1. **发送方**:将数据从用户空间缓冲区拷贝到内核的Socket发送缓冲区(第一次拷贝)。 2. **内核协议栈**:处理数据(如TCP分段、添加包头等)。 3. **接收方**:数据到达接收方内核的Socket接收缓冲区后,需再拷贝到接收方用户空间(第二次拷贝)。 > 因此,Socket通信至少需要两次拷贝(用户空间→内核→用户空间),且涉及内核协议栈的复杂处理(引用[2][3])。 ### 3. **性能对比** | **通信方式** | 拷贝次数 | 性能影响 | |--------------|----------|------------------------| | **Binder** | 1次 | 高效,延迟低 | | **Socket** | 2次 | 延迟高,CPU开销大 | - **额外开销**:Socket还需处理网络协议(如TCP三次握手、分包/组包),进一步增加开销(引用[2][3])。 - **数据大小限制**:Binder单次传输数据上限约4MB(引用[3]),而Socket理论上无此限制(但受缓冲区设置影响)。 ### 4. **技术原理图解** ```mermaid graph LR subgraph Binder A[发送方用户空间] -- copy_from_user --> B[内核映射区] B == 内存映射 ==物理内存==> C[接收方用户空间] end subgraph Socket D[发送方用户空间] -- 拷贝1 --> E[内核Socket缓冲区] E -- 协议处理 --> F[接收方内核Socket缓冲区] F -- 拷贝2 --> G[接收方用户空间] end ``` ### 5. **为什么Binder能减少拷贝次数?** 核心在于**内存映射(mmap)**: - 传统IPC(如Socket)需在发送方用户空间、内核空间、接收方用户空间之间来回拷贝数据。 - Binder通过预先建立的共享映射区,使接收方用户空间直接“看到”内核缓冲区的数据,省去一次拷贝(引用[4])。 > ⚠️ **注意**:Binder的“一次拷贝”仅指数据传输环节。实际通信中还有控制信息的传递(如Binder对象引用),但这些开销远小于数据拷贝(引用[1][2])。 ### 总结 - **Binder优势**:一次拷贝 + 无协议解析 → 高效、低延迟,适合高频次系统调用(如Activity启动)。 - **Socket适用场景**:大数据传输(如文件传输)或网络通信(引用[3])。 --- §§相关问题§§ 1. Binder驱动如何管理内存映射区的生命周期? 2. 为什么Binder的数据传输大小被限制在4MB? 3. Socket的两次拷贝在Linux内核中具体如何实现? 4. 匿名共享内存(Ashmem)与Binder的内存映射有何异同?</think>### Binder 机制中数据拷贝次数少于 Socket 的原因 #### **核心机制对比** | **通信方式** | **数据拷贝次数** | **关键技术** | **性能影响** | |--------------|------------------|-------------------|----------------------------| | **Binder** | 1 次 | 内存映射 (mmap) | 高效,延迟低 | | **Socket** | 2 次 | 内核缓冲区拷贝 | 延迟高,CPU 开销大 | --- ### 一、Binder 的 "一次拷贝" 实现原理 Binder 通过 **内存映射 (mmap)** 技术实现单次数据拷贝,具体流程如下: 1. **共享内存映射初始化** - Binder 驱动在内核空间分配物理内存页。 - 该物理内存页**同时映射**到: - 进程的用户空间虚拟地址(如 `0x7F000000`) - 进程的内核空间虚拟地址(如 `0xFFFF0000`) *(引用[4])* 2. **数据传输过程** ```mermaid graph LR A[发送方用户空间] -- 1. copy_from_user --> B[内核映射区] B -- 2. 直接访问 --> C[接收方用户空间] ``` - **步骤1**:发送方调用 `copy_from_user()` 将数据从**用户空间**拷贝到**内核映射区**(仅此一次拷贝)。 - **步骤2**:接收方通过内存映射直接访问内核映射区的数据,**无需额外拷贝**(引用[2][4])。 > 💡 **关键优势**:接收方通过内存映射直接读写内核区的数据,省去了 `copy_to_user()` 的第二次拷贝。 --- ### 二、Socket 的 "两次拷贝" 实现原理 Socket 通信需经过两次独立的数据拷贝: ```mermaid graph LR A[发送方用户空间] -- 1. 拷贝到内核缓冲区 --> B[内核Socket缓冲区] B -- 2. 协议栈处理 --> C[接收方内核缓冲区] C -- 3. 拷贝到用户空间 --> D[接收方用户空间] ``` 1. **第一次拷贝**:数据从发送方用户空间 → 内核 Socket 缓冲区(`copy_from_user`)。 2. **第二次拷贝**:数据从接收方内核缓冲区 → 接收方用户空间(`copy_to_user`)。 *(引用[2][3])* > ⚠️ **额外开销**:Socket 还需处理 TCP/IP 协议栈(如分包/组包、校验和计算),进一步增加延迟(引用[3])。 --- ### 三、性能差异分析 | **维度** | **Binder** | **Socket** | |----------------|---------------------------|--------------------------| | **拷贝次数** | 1 次 | 2 次 | | **延迟** | 微秒级 (μs) | 毫秒级 (ms) | | **CPU 开销** | 低(无协议栈处理) | 高(TCP/IP 协议处理) | | **适用场景** | 高频小数据(如系统调用) | 大数据流(如文件传输) | #### 数据验证(引用[3]): - **Binder** 单次传输上限约 **4MB**(受内存映射区大小限制)。 - **Socket** 单次传输上限理论无限制(实际受内核缓冲区约束,默认约 **64KB**)。 --- ### 四、技术本质差异 1. **Bindermmap 优化** 通过共享物理内存页,让用户空间和内核空间**直接访问同一块物理内存**,打破传统用户/内核空间隔离(引用[4])。 2. **Socket 的固有缺陷** 必须经过内核协议栈的完整处理流程,且用户空间与内核空间始终隔离,无法绕过两次拷贝。 > 📌 **结论**:Binder 的 "一次拷贝" 本质是 **"用内存映射替代第二次拷贝"**,而非完全消除拷贝(引用[2][4])。 ---
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值