1.什么是RPC(远程过程调用)
Binder系统的目的是实现远程过程调用(RPC),即进程A去调用进程B的某个函数,它是在进程间通信(IPC)的基础上实现的。RPC的一个应用场景如下:
A进程想去打开LED,它会去调用led_open,然后调用led_ctl,但是如果A进程并没有权限去打开驱动程序呢?
假设此时有一个进程B由权限去操作LED驱动程序,那么进程A可以通过如下方式来操作LED驱动:
①封装数据,即A进程首先把想要调用的B进程的某个函数的(事先约定好的)代号等信息封装成数据包
②A进程把封装好了的数据包通过IPC(进程间通信)发送给B进程
③B取出数据之后,通过从数据包里解析出来的函数的代号来调用它自己相应的led_open或led_ctl函数
整个过程的结果好像A程序直接来操纵LED一样,这就是所谓的RPC。整个过程涉及到了IPC(进程间通信)的三大要素,源、目的和数据。在这个例子里面,源就是进程A,目的是进程B,数据实际上就是一个双方约定好了数据格式的buffer。
2.Binder系统实现的RPC
Binder系统采用的是CS架构,提供服务的进程称为server进程,访问服务的进程称为client进程,server进程和client进程的通信需要依靠内核中的Binder驱动来进行。同时Binder系统提供了一个上下文的管理者servicemanager, server进程可以向servicemanager注册服务,然后client进程可以通过向servicemanager查询服务来获取server进程注册的服务。
回到上面的例子,A进程想操作LED,它可以通过将B进程的某个函数的(事先约定好的)代号通过IPC发给B进程,通过B进程来间接的操作LED,但是如果A进程不知道可以通过哪个进程来间接的操作LED呢,它应该将封装好了的数据包发送给哪个进程呢?这就引入了Binder系统的大管家servicemanager。首先B进程向servicemanager注册LED服务,然后我们的A进程就可以通过向servicemanager查询LED服务,就会得到一个handle,这个handle就是指向进程B的,这样进程A就知道把数据包(约定好数据格式的buffer)发送给哪个进程就可以间接的操作LED了。在这个例子中进程B就是server进程,进程A是client进程。
小小的总结一下,在 Binder系统中主要涉及到4个东西,一个是我们的A进程也就是client进程,一个是B进程也就是我们的server进程。client进程怎么知道要向哪一个server进程发送数据呢,中间就引入了Binder系统的大管家servicemanager。client进程、server进程和servicemanager之间的通信是建立在内核binder驱动的基础上的,它们四个的关系如下图所示
3.Binder系统的简单应用(基于Android内核,抛开Android系统框架)
在Android源码里面有一些C语言写的binder应用程序
frameworks/native/cmds/servicemanager/bctest.c frameworks/native/cmds/servicemanager/binder.c frameworks/native/cmds/servicemanager/binder.h frameworks/native/cmds/servicemanager/service_manager.c
我们可以参照这些程序,基于Android内核,在Linux上实现一个Binder RPC的程序来理解使用Binder实现进程间通信的整个函数调用过程。
我们首先把android源码frameworks/native/cmds/servicemanager目录下的内容拷贝到我们自己的工程中,然后基于bctest.c来实现我们的server和client程序,因为我们是脱离Android系统来实现的,所以还需要将依赖的头文件拷贝到工程中,然后对service_manager.c和binder.c做一些修改,去掉一些不必要的内容。最后我们还需要写一个Makefile文件来构建整个工程,工程结构如下图所示。
3.1.Server进程
首先实现Server程序,它实现两个函数,sayhello和sayhello_to,并通过binder系统将向ServiceManager注册服务,然后循环的从binder驱动读取client进程发过来请求数据,并且通过这些请求数据调用自己相应的sayhello和sayhello_to函数。整个过程如下图所示。
接着我们就来分析以下具体的代码
/*test_server.h*/ #ifndef _TEST_SERVER_H #define _TEST_SERVER_H /*事先约定好的Server进程的相应函数的代号*/ #define HELLO_SVR_CMD_SAYHELLO 0 #define HELLO_SVR_CMD_SAYHELLO_TO 1 #endif // _TEST_SERVER_H
/*test_server.c*/ /* Copyright 2008 The Android Open Source Project */ #include <stdio.h> #include <stdlib.h> #include <errno.h> #include <linux/types.h> #include<stdbool.h> #include <string.h> #include <private/android_filesystem_config.h> #include "binder.h" #include "test_server.h" int svcmgr_publish(struct binder_state *bs, uint32_t target, const char *name, void *ptr) { int status; unsigned iodata[512/4]; struct binder_io msg, reply; bio_init(&msg, iodata, sizeof(iodata), 4); bio_put_uint32(&msg, 0); // strict mode header bio_put_string16_x(&msg, SVC_MGR_NAME); bio_put_string16_x(&msg, name); bio_put_obj(&msg, ptr); /*远程调用ServiceManager的do_add_service函数*/ if (binder_call(bs, &msg, &reply, target, SVC_MGR_ADD_SERVICE)) return -1; status = bio_get_uint32(&reply); binder_done(bs, &msg, &reply); return status; } void sayhello(void) { static int cnt = 0; fprintf(stderr, "say hello : %d ", cnt++); } int sayhello_to(char *name) { static int cnt = 0; fprintf(stderr, "say hello to %s : %d ", name, cnt++); return cnt; } int hello_service_handler(struct binder_state *bs, struct binder_transaction_data *txn, struct binder_io *msg, struct binder_io *reply) { /* 根据txn->code知道要调用哪一个函数 * 如果需要参数, 可以从msg取出 * 如果要返回结果, 可以把结果放入reply */ /* sayhello * sayhello_to */ uint16_t *s; char name[512]; size_t len; uint32_t handle; uint32_t strict_policy; int i; // Equivalent to Parcel::enforceInterface(), reading the RPC // header with the strict mode policy mask and the interface name. // Note that we ignore the strict_policy and don't propagate it // further (since we do no outbound RPCs anyway). strict_policy = bio_get_uint32(msg); switch(txn->code) { case HELLO_SVR_CMD_SAYHELLO: sayhello(); return 0; case HELLO_SVR_CMD_SAYHELLO_TO: /* 从msg里取出字符串 */ s = bio_get_string16(msg, &len); if (s == NULL) { return -1; } for (i = 0; i < len; i++) name[i] = s[i]; name[i] = '