Android Binder传输大文件

问题和解决方案

想要在自定义安卓系统服务中传输较大的数据,由于系统服务使用binder进行IPC,而binder最大只能传输(1mb-8kb)的数据,目前想到的解决方案是把数据拆分为多份,然后多次传输。本文记录这个解决方案遇到的一些坑

先放上关键的代码:

auto myService = aidl::android::MyService::fromBinder(ndk::SpAIBinder(AServiceManager_getService("myservice")));
int pack_size = 0x7E000;  // 必须为4kb整数倍,且长度最好在1mb-8kb的一半以内
int count = (size / pack_size); // size是数据长度
if(count >= 255){
    return false;
}

// 分块传输, binder限制,每次只能传输1mb不到的数据
for(int i=0; i < count; i++){
    // begin是要传输的数据的首地址, size是数据长度
    std::vector buff(begin + i*pack_size, begin + (i+1)*pack_size);
    // 传输pid、begin等参数,用于标记具体数据来源,传输参数i,用于标记块的顺序,方便服务端进行文件重组
    myService->trans_data(pid, begin, size, i, buff);
    usleep(5); //第二章会说明为什么要sleep
}
std::vector buff(begin + count*pack_size, begin + size);
// 这里别忘了把额外的数据也补齐到4kb的整数倍,这里略过了补齐的代码
myService->trans_data(pid, begin, size, count, buff);
usleep(5);

数据必须为4kb的整数倍

刚开始我把数据拆分为每块1000000byte,可是服务端只接收到了999424byte数据,接收到的部分数据我保存为文件之后,如下所示:

-rw-rw---- 1 root root 999424 2023-08-09 16:24 part_2
-rw-rw---- 1 root root 999424 2023-08-09 16:24 part_3
-rw-rw---- 1 root root 999424 2023-08-09 16:24 part_4
-rw-rw---- 1 root root 999424 2023-08-09 16:24 part_5

999424换成16进制,就是0xF4000,是4kb的整数倍,这里我没有进一步确认是vector的问题还是binder的问题(也不知道为啥要舍弃掉多余的字符,而不是填充0补齐到整数倍,想弄懂原理估计很麻烦,这里先放着了),总之先把每块的数据调整为4kb的倍数。

调整后客户端发送的和服务端接收到的数据都是999424byte,保持一致,这个问题解决。

buffer释放问题

服务端处理数据的速度过慢时,会导致buffer来不及释放的问题。

比如每次只传999504byte数据,此时一个binder的buffer还会剩下40880byte内存,如果下一条数据已经准备开始传输了,同时上一条数据还没有处理完,buffer没有释放,这时只能在剩下的40880byte内存中申请999504byte的数据,很明显是不够的

注:我每块大小为999424byte,但是log显示要申请999504byte数据,猜测是其他的参数或者某些额外的数据结构多占了部分空间,这个对我最终目标没影响所以也不过多研究了

仔细观察报错,可以发现正常传输数据的间隔大概在3ms,而报错的地方与上一条log只差了1ms,于是修改代码,在每次循环中加入5ms的等待时间

15:46:26.473  1258  1310 W         ==Mytag==
15:46:26.476  1258  1310 W         ==Mytag==
15:46:26.475     0     0 E         : c4   5038 binder_alloc: 1258: binder_alloc_buf size 999504 failed, no address space
15:46:26.475     0     0 E         : c4   5038 binder_alloc: allocated: 999504 (num: 1 largest: 999504), free: 40880 (num: 1 largest: 40880)
15:46:26.475     0     0 I         : c4   5038 binder: 5038:5038 transaction failed 29201/-28, size 999504-0 line 3317
15:46:26.480  1258  1310 W         ==Mytag==
15:46:26.483  1258  1310 W         ==Mytag==
15:46:26.486  1258  1310 W         ==Mytag==

但是修改之后还是会报同样的错,只不过频率低了很多,连续多次传输只报了一次错误,没修改之前几乎每次都会报错。而且观察修改后的log,其中的Mytag的时间间隔依旧在3ms,那么剩下的问题肯定不在我们客户端的数据传输间隔上了

重点转移到服务端,众所周知,binder服务端是可以多线程处理任务的,binder多个线程是共用一块buffer内存,所以减少多线程数量,即可减少多个线程争抢一块内存的情况。我这里用的是android系统服务的ndk后端,使用ABinderProcess_setThreadPoolMaxThreadCount 来设置最大线程数,我这里设定为5,但是依旧会出现上面的报错。

最后想到一个办法:把每块的大小限制在(1mb-8kb)的一半以内(一半是0x7F000,我最终设定为0x7E000),那么即使出现了上面没有及时释放buffer的情况,剩下的一半空间也能够支持一次数据传输。在循环加入等待时间之后,出现报错的频率已经大幅减少,在加上大小限制在一半的操作,最后终于稳定的通过了测试,多轮数据传输测试下来,基本没有再出现过报错了。

你可能感兴趣的:(Android Binder传输大文件)