浅谈Binder的基本原理

关于binder驱动

Binder在Android里被设计成了一个驱动,安装在/dev/binder,这也是Android和linux的重要区别之一:Android提出了一个新的进程间通信方式(IPC)。另外,这种方式是通过远程过程调用(RPC)实现的。
对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,
};

所有对/dev/binder这个driver做的事情都会转换成binder自己定义的函数。比如当一个进程要打开Binder设备的时候总要调用
static int open_driver()
{
...
int fd =open("/dev/binder", O_RDWR);
...
}

在经过binder驱动解释后就变成了binder_open。
又如:
`status_t IPCThreadState::talkWithDriver(bool doReceive){

#if defined(HAVE_ANDROID_OS)
if (ioctl(mProcess->mDriverFD,BINDER_WRITE_READ, &bwr) >= 0)
err = NO_ERROR;
else
err = -errno;
#else

注意,这里的ioctl因为涉及到进程间通信,需要进行进程切换。

关于如何使用binder

一个serivce:
int main()
{
proc(ProcessState::self());
sm =defaultServiceManager();
sm->addService(“service.name”,newXXXService());
ProcessState::self()->startThreadPool();
IPCThreadState::self()->joinThreadPool();
}

service manager需要把这个service放到一个全局的链表srvlist中,这样,Client就可以根据service的名字找到它了。比如media.player
客户端试图拿到service的Binder时,调用getService,如下:
void addBatteryData(uint32_t params) {
sp<IBinder> binder =
defaultServiceManager()->getService(String16("media.player"));
sp<IMediaPlayerService>service = interface_cast<IMediaPlayerService>(binder);
CHECK(service.get() != NULL);
service->addBatteryData(params);
}

怎么写一个Client呢?

其实Binder机制和Socket编程里的cs架构一样,service有一个loop,不停查找是不是driver上有命令写到了自己的buffer,Client则向binder写数据,当然它要告诉binder谁需要收数据。

一个Service,对于ServiceManager来说也是Client。
Client和Service之间通过什么通信呢?本质上是BpBinder和BBinder,但是上层有一个对他们的封装接口BpInterface和BnInterface。
BpInterface的创建需要一个BpBinder,它的函数remote()返回的也是这个BpBinder。
BpBinder是service上实体Binder的一个代理,跟它聊就等于跟service上的Binder聊
BpBinder::BpBinder(int32_thandle),它是有一个handle构建了,这个handle其实就是Service的索引。ServiceManager的索引是0.

Binder为什么交换次数只有一次?

这是在内核决定的,因为Binder利用mmap把Binder设备同时映射到用户空间和内核空间,所以在一个进程里,不需要进行用户空间和内核空间的copy,而只需要把数据从发送进程的用户空间拷贝到接收进程的内核空间。所以只需要拷贝一次。

ServiceManager

在内核中,misc杂项设备驱动接口是对一些字符设备的简单封装,他们共享一个主设备号,有不同的次设备号,共享一个open调用,其他的操作函数在打开后运用linux驱动程序的方法重载进行装载。
http://blog.csdn.net/yaozhenguo2006/article/details/6760575
service_manager.c (frameworks\native\cmds\servicemanager)
这也是一个可执行文件
struct binder_state *binder_open(size_t mapsize){
bs->fd = open(“/dev/binder”, O_RDWR);
bs->mapsize = mapsize;
bs->mapped = mmap(NULL, mapsize, PROT_READ, MAP_PRIVATE, bs->fd, 0);
}

   void *mmap(void *addr, size_t length, int prot, int flags,
              int fd, off_t offset);
   int munmap(void *addr, size_t length);

抛开一些细节,mmap就是把内核区的内存进行映射到用户空间,在servicemanager中,就是映射到bs->mapped
Kernel处得binder代码在binder.c (kernel\drivers\android)
注意binder注册为miscdevice
misc_register
binder驱动有几个全局链表
static HLIST_HEAD(binder_procs);
static HLIST_HEAD(binder_deferred_list);
static HLIST_HEAD(binder_dead_nodes);
每个进程open binder驱动后,就创建了binder_proc,然后
给一个binder_context_mgr_node赋值
get_vm_area,定义在include/linux/vmalloc.h,目的是为了获取一块连续的内核空间
/**
* get_vm_area - reserve a contiguous kernel virtual area
* @size: size of the area
* @flags: %VM_IOREMAP for I/O mappings or VM_ALLOC
*
* Search an area of @size in the kernel virtual mapping area,
* and reserved it for out purposes. Returns the area descriptor
* on success or %NULL on failure.
*/
struct vm_struct *get_vm_area(unsigned long size, unsigned long flags)
{
return __get_vm_area_node(size, 1, flags, VMALLOC_START, VMALLOC_END,
NUMA_NO_NODE, GFP_KERNEL,
__builtin_return_address(0));
}
输入size,获取用户态和内核态的虚拟内存空间,并建立映射关系。但是目前还没有真正的物理内存。Vma—start是用户空间起始地址,end是中止地址。proc—buffer是内核空间起始地址,
kzalloc,分配物理内存
从mmap怎么调用到binder_mmap?
系统调用,用软中断实现
kernel/arch/arm/include/asm/unistd.h
#define __NR_mmap2 (__NR_SYSCALL_BASE+192)

Service manager进入binder_loop,然后进入binder_parse,进行命令解析,主要看BR_TRANSACTION和BR_REPLY
SM中的很多操作都在binder.c (frameworks\native\cmds\servicemanager) 16577 2015/8/4
所以func是svcmgr_handler,在do_add_service中,会把service对应的结构体插入到svclist
注册死亡通知函数 si->death.func = (void*) svcinfo_death;
然后把它发下去 binder_link_to_death

每个进程只打开一次Binder设备,且只做一次内存映射,所所有需要Binder驱动的线程共享这一资源
Binder需要提供java接口给APK使用
ProcessState是进程内专门管理进程操作的 ProcessStats.java (frameworks\base\core\java\com\android\internal\app)
binder_proc中的几棵红黑树
cpp层相关的binder是frameworks/native/libs/binder

  • 0
    点赞
  • 1
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
Binder通信原理是Android中一种跨进程通信机制。它通过Binder驱动和Binder服务来实现进程间的通信。具体实现方式可以参考。 在Binder通信原理中,有三个关键的组件:Binder驱动、Binder服务和Binder客户端。Binder驱动是操作系统提供的内核模块,它负责在进程间传递消息。而Binder服务是一个独立的进程,用于管理和提供跨进程通信的能力。Binder客户端则是调用Binder服务的进程。 在通信过程中,首先需要调用binder_open函数打开Binder设备,然后使用mmap函数进行内存映射,将用户空间的内存映射到内核空间。接下来,通过ioctl函数进行实际的通信操作。 Android中的四大组件(Activity、Service、BroadcastReceiver和ContentProvider)的启动原理也与Binder IPC机制有关。其中,ActivityManagerService、PackageManagerService、WindowManagerService、PowerManagerService等服务的调用也与Binder IPC机制有关。 综上所述,Binder通信原理是Android中一种跨进程通信机制,通过Binder驱动和Binder服务来实现进程间的通信。<span class="em">1</span><span class="em">2</span><span class="em">3</span> #### 引用[.reference_title] - *1* *3* [Binder通信机制原理解析](https://blog.csdn.net/Awenyini/article/details/78806893)[target="_blank" data-report-click={"spm":"1018.2226.3001.9630","extra":{"utm_source":"vip_chatgpt_common_search_pc_result","utm_medium":"distribute.pc_search_result.none-task-cask-2~all~insert_cask~default-1-null.142^v93^chatsearchT3_2"}}] [.reference_item style="max-width: 50%"] - *2* [Binder通信原理](https://blog.csdn.net/z1804362542/article/details/127959348)[target="_blank" data-report-click={"spm":"1018.2226.3001.9630","extra":{"utm_source":"vip_chatgpt_common_search_pc_result","utm_medium":"distribute.pc_search_result.none-task-cask-2~all~insert_cask~default-1-null.142^v93^chatsearchT3_2"}}] [.reference_item style="max-width: 50%"] [ .reference_list ]

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值