Binder的一次事务通信数据量分析及优化思路
背景
Android官方介绍以及很多文章都讲到Binder的数据一次拷贝，Binder的数据一次拷贝到底是怎么回事呢？一次的数据拷贝真的对性能有很大改善吗？带着这个疑问，分析Binder驱动以及与Binder驱动通信的IPCThreadState。看看数据在Binder通信双方是怎么传递的。
分析从Binder通信发送端的IPCThreadState的talkWithDriver开始，到Binder通信接收端的IPCThreadState的talkWithDriver返回截止。分析transaction传递过程的数据拷贝量。
分析的源码是Android P(http://androidxref.com/9.0.0_r3/xref/frameworks/native/libs/binder/IPCThreadState.cpp)以及4.19内核(https://android.googlesource.com/kernel/common/+/refs/heads/android-4.19/drivers/android/binder.c)
发送端
发送端的数据在进入到talkWithDriver时，已经被封装到名为mOut的Parcel中。talkWithDriver与驱动交换数据需要使用结构体binder_write_read，将mOut的数据地址赋值给 binder_write_read的对象bwr，然后将bwr的地址作为参数ioctl的参数传递给binder驱动。
进入binder.c的binder_ioctl，然后进入binder_ioctl_write_read，在binder_ioctl_write_read中进行了第一次的数据拷贝，目的是获得binder_write_read的对象bwr，拷贝的数据量为sizeof(binder_write_read)。
static int binder_ioctl_write_read(struct file *filp,
unsigned int cmd, unsigned long arg,
struct binder_thread *thread)
{
int ret = 0;
struct binder_proc *proc = filp->private_data;
unsigned int size = _IOC_SIZE(cmd);
void __user *ubuf = (void __user *)arg;
struct binder_write_read bwr;
if (size != sizeof(struct binder_write_read)) {
ret = -EINVAL;
goto out;
}
if (copy_from_user(&bwr, ubuf, sizeof(bwr))) {
ret = -EFAULT;
goto out;
}
...
}
接着，进入binder_thread_write函数。此时传入binder_thread_write的数据地址是 bwr.write_buffer，即mOut.data()。在binder_thread_write中会循环解析bwr.write_buffer中的数据，为了便于分析，假设IPCThreadState只传递了一个CMD及数据。那么在binder_thread_write中首先拷贝一次cmd，大小为sizefo(uint32_t)。
while (ptr < end && thread->return_error.cmd == BR_OK) {
int ret;
if (get_user(cmd, (uint32_t __user *)ptr))
return -EFAULT;
ptr += sizeof(uint32_t);
trace_binder_command(cmd);
...
}
再接着，进入CMD为BC_TRANSACTION的处理流程：
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;
}
在这里，拷贝了IPCThreadState传递下来的BC_TRANSACTION命令对应的数据，大小为sizeof(binder_transaction_data)。然后，进入binder_transaction函数。
在binder_transaction函数中找到target_node后，创建binder_transaction t和binder_work tcomplete ，然后填充数据，大小分别为sizeof(binder_transaction)和sizeof(binder_work)：
/* TODO: reuse incoming transaction for reply */
t = kzalloc(sizeof(*t), GFP_KERNEL);
if (t == NULL) {
return_error = BR_FAILED_REPLY;
return_error_param = -ENOMEM;
return_error_line = __LINE__;
goto err_alloc_t_failed;
}
binder_stats_created(BINDER_STAT_TRANSACTION);
spin_lock_init(&t->lock);
tcomplete = kzalloc(sizeof(*tcomplete), GFP_KERNEL);
if (tcomplete == NULL) {
return_error = BR_FAILED_REPLY;
return_error_param = -ENOMEM;
return_error_line = __LINE__;
goto err_alloc_tcomplete_failed;
}
将数据拷贝到目标进程，大小为tr->data_size + tr->offsets_size：
if (binder_alloc_copy_user_to_buffer(
&target_proc->alloc,
t->buffer, 0,
(const void __user *)
(uintptr_t)tr->data.ptr.buffer,
tr->data_size)) {
binder_user_error("%d:%d got transaction with invalid data ptr\n",
proc->pid, thread->pid);
return_error = BR_FAILED_REPLY;
return_error_param = -EFAULT;
return_error_line = __LINE__;
goto err_copy_data_failed;
}
if (binder_alloc_copy_user_to_buffer(
&target_proc->alloc,
t->buffer,
ALIGN(tr->data_size, sizeof(void *)),
(const void __user *)
(uintptr_t)tr->data.ptr.offsets,
tr->offsets_size)) {
binder_user_error("%d:%d got transaction with invalid offsets ptr\n",
proc->pid, thread->pid);
return_error = BR_FAILED_REPLY;
return_error_param = -EFAULT;
return_error_line = __LINE__;
goto err_copy_data_failed;
}
如果传递有对象的，还需要拷贝对象，为了方便分析，假设没有传递对象。binder_transaction后面的处理没有数据拷贝，然后返回到binder_transaction函数，再到binder_ioctl_write_read函数，在binder_ioctl_write_read中又拷贝一次binder_write_read bwr，将数据拷贝给发送端的用户空间。
binder_debug(BINDER_DEBUG_READ_WRITE,
"%d:%d wrote %lld of %lld, read return %lld of %lld\n",
proc->pid, thread->pid,
(u64)bwr.write_consumed, (u64)bwr.write_size,
(u64)bwr.read_consumed, (u64)bwr.read_size);
if (copy_to_user(ubuf, &bwr, sizeof(bwr))) {
ret = -EFAULT;
goto out;
}
out:
return ret;
最后回到IPCThreadState的talkWithDriver。
接收端
接收端在收到binder数据先，IPCThreadState需要通过talkWithDriver进入内核，然后线程休眠，这部分跟前面介绍的一样，需要使用 binder_write_read的对象bwr，将bwr的地址作为ioctl的参数传递给binder驱动。进入binder.c的binder_ioctl，然后进入binder_ioctl_write_read，在binder_ioctl_write_read中进行了第一次的数据拷贝，目的是获得binder_write_read的对象bwr，拷贝的数据量为sizeof(binder_write_read)。
接收端的线程在binder驱动的binder_thread_read函数中被唤醒，在binder_thread_read函数这里获得发送端传来的binder_transaction t，然后将cmd和binder_transaction_data 拷贝到用户空间，大小为sizeof(uint32_t)和sizeof(binder_transaction_data )：
if (put_user(cmd, (uint32_t __user *)ptr)) {
if (t_from)
binder_thread_dec_tmpref(t_from);
binder_cleanup_transaction(t, "put_user failed",
BR_FAILED_REPLY);
return -EFAULT;
}
ptr += sizeof(uint32_t);
if (copy_to_user(ptr, &tr, trsize)) {
if (t_from)
binder_thread_dec_tmpref(t_from);
binder_cleanup_transaction(t, "copy_to_user failed",
BR_FAILED_REPLY);
return -EFAULT;
}
ptr += trsize;
同样最后在binder_ioctl_write_read中又拷贝一次binder_write_read bwr，将数据拷贝给发送端的用户空间。
至此，数据到达接收端的用户空间，但是在talkWithDriver收到驱动返回的数据后，mIn.setDataSize可能会引发数据拷贝，因为它内部将会调用realloc，该函数在原地址的内存不够时，会重新申请一块足够大的内存，然后发生数据拷贝：
if (bwr.read_consumed > 0) {
mIn.setDataSize(bwr.read_consumed);
mIn.setDataPosition(0);
}
mIn.setDataSize(bwr.read_consumed)设置Parcel的数据大小，进入Parcel的下面流程，调用realloc重新分配内存，这个动作，可能让Binder的数据多一次拷贝，使得官方宣称的一次拷贝付之东流：
status_t Parcel::setDataSize(size_t size)
{
if (size > INT32_MAX) {
// don't accept size_t values which may have come from an
// inadvertent conversion from a negative int.
return BAD_VALUE;
}
status_t err;
err = continueWrite(size);
if (err == NO_ERROR) {
mDataSize = size;
ALOGV("setDataSize Setting data size of %p to %zu", this, mDataSize);
}
return err;
}
status_t Parcel::continueWrite(size_t desired)
{
...
if (mOwner) {
...
} else if (mData) {
if (objectsSize < mObjectsSize) {
// Need to release refs on any objects we are dropping.
const sp<ProcessState> proc(ProcessState::self());
for (size_t i=objectsSize; i<mObjectsSize; i++) {
const flat_binder_object* flat
= reinterpret_cast<flat_binder_object*>(mData+mObjects[i]);
if (flat->hdr.type == BINDER_TYPE_FD) {
// will need to rescan because we may have lopped off the only FDs
mFdsKnown = false;
}
release_object(proc, *flat, this, &mOpenAshmemSize);
}
binder_size_t* objects =
(binder_size_t*)realloc(mObjects, objectsSize*sizeof(binder_size_t));
if (objects) {
mObjects = objects;
}
mObjectsSize = objectsSize;
mNextObjectHint = 0;
mObjectsSorted = false;
}
// We own the data, so we can just do a realloc().
if (desired > mDataCapacity) {
//如果mData指向的内存无法满足desired的大小，将会重新分配一块内存，
//然后将mData的数据拷贝到新分配的内存中。
uint8_t* data = (uint8_t*)realloc(mData, desired);
if (data) {
LOG_ALLOC("Parcel %p: continue from %zu to %zu capacity", this, mDataCapacity,
desired);
pthread_mutex_lock(&gParcelGlobalAllocSizeLock);
gParcelGlobalAllocSize += desired;
gParcelGlobalAllocSize -= mDataCapacity;
pthread_mutex_unlock(&gParcelGlobalAllocSizeLock);
mData = data;
mDataCapacity = desired;
} else {
mError = NO_MEMORY;
return NO_MEMORY;
}
} else {
if (mDataSize > desired) {
mDataSize = desired;
ALOGV("continueWrite Setting data size of %p to %zu", this, mDataSize);
}
if (mDataPos > desired) {
mDataPos = desired;
ALOGV("continueWrite Setting data pos of %p to %zu", this, mDataPos);
}
}
} else {
...
}
...
}
总共拷贝数据量
通过以上分析，一次Binder IPC事务的过程，拷贝的数据量为：
| 数据类型 | 数据大小 | 功能 |
|---|---|---|
| binder_write_read | 48 | 发送端用户空间与驱动通信的结构体数据 |
| uint32_t | 4 | 发送端传给驱动的binder cmd |
| binder_transaction_data | 64 | 用户空间传入的binder数据 |
| binder_transaction | 104 | 传递的事务结构体数据 |
| binder_work | 12 | binder任务结构体数据 |
| binder_transaction_data.ptr.buffer/binder_transaction_data.ptr.offsets | data_size + offsets_size | 拷贝到目标进程的binder数据（官方宣称的一次拷贝的数据） |
| binder_write_read | 48 | 驱动到发送端用户空间 |
| binder_write_read | 48 | 接收端用户空间到驱动 |
| uint32_t | 4 | 接收端传给驱动的binder cmd |
| binder_transaction_data | 64 | 驱动发送到接收端用户空间的binder数据 |
| binder_write_read | 48 | 驱动与发送端用户空间通信的结构体数据 |
| binder_transaction_data.ptr.buffer/binder_transaction_data.ptr.offsets | data_size + offsets_size | 如果realloc需要重新分配内存，则会在Parcel中拷贝一次数据 |
假设binder_transaction_data.ptr.buffer的数据大小为4，binder_transaction_data.ptr.offsets的数据大小为0，realloc不需要重新分配内存，那么一次IPC过程总共需要拷贝的数据量为：448
Binder数据拷贝结论
Binder的一次拷贝，是驱动中将传输的Parcel数据拷贝到接收进程时发生的，但在整个Binder IPC中，实际上传输的Parcel中的数据至少被拷贝一次，为了完成这部分数据的传递，中间需要经历多次相关数据的拷贝，且这些相关数据的数据量可能比传输的Parcel中的数据多。如果IPC传递的是基本数据类型，那么一次IPC的数据拷贝量都是花费在传输过程的相关数据拷贝中，Binder驱动中的一次数据拷贝的数据量相对总数据量的占比并不大。
Binder性能优化的思路
Android上几乎所有进程都涉及到Binder IPC，频繁的IPC会带来一定的性能损耗，其中主要的CPU损耗来源于数据拷贝，并导致IPC延时。所以性能优化可以考虑从Binder入手。从上面的分析可以知道，Binder IPC的过程会产生相关数据的拷贝及其内存申请释放，优化可以从下面的思路入手：
1.简化IPC过程中传递Parcel相关数据的大小；
2.寻找替代realloc的方案；
3.缩短IPC过程中的数据通路。
涉及到Binder基础实现的修改风险还是比较大的，如果不希望修改Binder驱动或者IPCThreadState等的实现，还有另外一个方案是，利用Binder驱动的统计功能对需要IPC的服务端和客户端进行优化，即找出IPC最频繁的进程，优化他们的IPC接口，降低IPC或者减少IPC时的数据量。
