android binder作用,Android系统之Binder子系统（上）

最新推荐文章于 2024-05-06 16:01:17 发布

xingming Zhenshi

最新推荐文章于 2024-05-06 16:01:17 发布

阅读量206

点赞数

文章标签： android binder作用

今天我们来看看 Android 系统的一个子系统Binder。首先先来介绍下 Binder 子系统，它是 Android 系统中用来进程间通信的一种方式。那么为什么要学习下 binder 系统呢？因为掌握了 binder 子系统，我们就能很好的理解在 Android 系统进程间到底是怎样进行通讯的，并且基于 binder 实现的各种 client 和 server 之间是怎么进行一步步通讯的。下来我们就开始来看看 binder 子系统。

binder 系统的核心是另种通信方式：IPC 和 RPC。IPC 是 src A 直接发给 des B，而 RPC 是 src A 通过远程函数调用 des B。

1、IPC 通信的方式有三个要素：

1. 发送源：A；

2. 目的：B 向 servicemanger 注册 led 服务，A 向 servicemanger 查询 led 服务，得到一个 handle；

3. 数据本身：char buf[512]；

2、RPC 通信方式是远程函数调用：

1. 调用的是哪个函数：sever 的函数编号；

2. 传给它什么参数，返回值。通过 IPC 的 buf 传输。

example：LED 传输。IPC 方式是从 A 直接发送给B；而 RPC 方式是 led_open、led_ctl 进行封装数据，然后发送给 B，在 B 那边调用 led_open，led_ctl 再次取出数据。

我们先来大概介绍下 client、servicemanger、server 三个的作用。

client：

1. 打开驱动；

2. 获取服务：向 servicemanger 查询服务，获得一个 handle；

3. 向 handle 发送数据。

servicemanger：

1. 打开驱动；

2. 告诉驱动，它是 “servicemanger”；

3. while(1) {

读驱动获取数据；

解析数据；

调用：a. 注册服务：在链表中记录服务名；

b. 获取服务：b.1 在链表中查询有无此服务；b.2 返回 “server进程”的 handle。

};

server：

1. 打开驱动；

2. 注册服务：向 servicemanger 发送服务；

3. while(1) {

读驱动获取数据；

解析数据；

调用对应函数。

};

它们三个都是基于 binder 驱动进行工作。我们先来看看 service_manger.c 文件，mian 函数大体如下int main(int argc, char **argv)

{

struct binder_state *bs;

bs = binder_open(128*1024); // 对应上面的第一步。打开驱动

if (!bs) {

ALOGE("failed to open binder driver\n");

return -1;

}

if (binder_become_context_manager(bs)) {

ALOGE("cannot become context manager (%s)\n", strerror(errno));

return -1;

}

selinux_enabled = is_selinux_enabled();

sehandle = selinux_android_service_context_handle();

if (selinux_enabled > 0) {

if (sehandle == NULL) {

ALOGE("SELinux: Failed to acquire sehandle. Aborting.\n");

abort();

}

if (getcon(&service_manager_context) != 0) {

ALOGE("SELinux: Failed to acquire service_manager context. Aborting.\n");

abort();

}

union selinux_callback cb;

cb.func_audit = audit_callback;

selinux_set_callback(SELINUX_CB_AUDIT, cb);

cb.func_log = selinux_log_callback;

selinux_set_callback(SELINUX_CB_LOG, cb);

svcmgr_handle = BINDER_SERVICE_MANAGER; // 对应上面的第二步。告诉驱动，它是 ServiceManager

binder_loop(bs, svcmgr_handler); // 对应上面的第三步。 while 循环所做的事情

return 0;

}

我们再来看看 binder.c (对应于上面的 server)，其中 binder_loop 函数就在此文件中。我们来看看 binder_loop 函数所做的事情，code 如下void binder_loop(struct binder_state *bs, binder_handler func)

{

int res;

struct binder_write_read bwr;

uint32_t readbuf[32];

bwr.write_size = 0;

bwr.write_consumed = 0;

bwr.write_buffer = 0;

readbuf[0] = BC_ENTER_LOOPER;

binder_write(bs, readbuf, sizeof(uint32_t));

for (;;) {

bwr.read_size = sizeof(readbuf);

bwr.read_consumed = 0;

bwr.read_buffer = (uintptr_t) readbuf;

res = ioctl(bs->fd, BINDER_WRITE_READ, &bwr); // 读取驱动获得数据

if (res

ALOGE("binder_loop: ioctl failed (%s)\n", strerror(errno));

break;

}

res = binder_parse(bs, 0, (uintptr_t) readbuf, bwr.read_consumed, func); // 解析数据

if (res == 0) {

ALOGE("binder_loop: unexpected reply?!\n");

break;

}

if (res

ALOGE("binder_loop: io error %d %s\n", res, strerror(errno));

break;

}

我们再来看看 bctest.c 文件(对应于上面的 client)，code 如下int main(int argc, char **argv)

{

int fd;

struct binder_state *bs;

uint32_t svcmgr = BINDER_SERVICE_MANAGER;

uint32_t handle;

bs = binder_open(128*1024);

if (!bs) {

fprintf(stderr, "failed to open binder driver\n");

return -1;

}

argc--;

argv++;

while (argc > 0) {

if (!strcmp(argv[0],"alt")) {

handle = svcmgr_lookup(bs, svcmgr, "alt_svc_mgr");

if (!handle) {

fprintf(stderr,"cannot find alt_svc_mgr\n");

return -1;

}

svcmgr = handle;

fprintf(stderr,"svcmgr is via %x\n", handle);

} else if (!strcmp(argv[0],"lookup")) {

if (argc

fprintf(stderr,"argument required\n");

return -1;

}

handle = svcmgr_lookup(bs, svcmgr, argv[1]); // 获取服务

fprintf(stderr,"lookup(%s) = %x\n", argv[1], handle);

argc--;

argv++;

} else if (!strcmp(argv[0],"publish")) {

if (argc

fprintf(stderr,"argument required\n");

return -1;

}

svcmgr_publish(bs, svcmgr, argv[1], &token); // 注册服务

argc--;

argv++;

} else {

fprintf(stderr,"unknown command %s\n", argv[0]);

return -1;

}

argc--;

argv++;

}

return 0;

}

先来看看 svcmgr_lookup 函数是怎么来获取服务的，code 如下uint32_t svcmgr_lookup(struct binder_state *bs, uint32_t target, const char *name)

{

uint32_t handle;

unsigned iodata[512/4];

struct binder_io msg, reply;

// 构造 binder_io

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);

if (binder_call(bs, &msg, &reply, target, SVC_MGR_CHECK_SERVICE)) // 获取服务

return 0;

handle = bio_get_ref(&reply);

if (handle)

binder_acquire(bs, handle);

binder_done(bs, &msg, &reply);

return handle;

}

我们看到其中核心函数是 binder_call 函数。再来看看 svcmgr_publish 函数是怎么来注册服务的，code 如下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);

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;

}

其中核心函数还是 binder_call 函数。binder_call 函数的参数作用分别是：1、远程调用；2、向谁发送数据；3、调用那个函数；4、提供什么参数；5、返回值。

那么 binder_call 函数中的参数作用如下：

1、bs 是一个结构体，代表远程调用；

2、msg 中含有服务的名字；

3、reply 中含有servicemanager回复的数据, 表示提供服务的进程；

4、target 代表是的

0，表示servicemanager, (if (target == 0))；

5、SVC_MGR_CHECK_SERVICE

表示要调用servicemanager中的"getservice函数"。

下来我们具体来看看 binder_call 的实现int binder_call(struct binder_state *bs,

struct binder_io *msg, struct binder_io *reply,

uint32_t target, uint32_t code)

{

int res;

struct binder_write_read bwr;

struct {

uint32_t cmd;

struct binder_transaction_data txn;

} __attribute__((packed)) writebuf;

unsigned readbuf[32];

if (msg->flags & BIO_F_OVERFLOW) {

fprintf(stderr,"binder: txn buffer overflow\n");

goto fail;

}

// 构造参数

writebuf.cmd = BC_TRANSACTION;

writebuf.txn.target.handle = target;

writebuf.txn.code = code;

writebuf.txn.flags = 0;

writebuf.txn.data_size = msg->data - msg->data0;

writebuf.txn.offsets_size = ((char*) msg->offs) - ((char*) msg->offs0);

writebuf.txn.data.ptr.buffer = (uintptr_t)msg->data0;

writebuf.txn.data.ptr.offsets = (uintptr_t)msg->offs0;

bwr.write_size = sizeof(writebuf);

bwr.write_consumed = 0;

bwr.write_buffer = (uintptr_t) &writebuf;

hexdump(msg->data0, msg->data - msg->data0);

for (;;) {

bwr.read_size = sizeof(readbuf);

bwr.read_consumed = 0;

bwr.read_buffer = (uintptr_t) readbuf;

res = ioctl(bs->fd, BINDER_WRITE_READ, &bwr); // 调用 ioctl 发数据

if (res

fprintf(stderr,"binder: ioctl failed (%s)\n", strerror(errno));

goto fail;

}

res = binder_parse(bs, reply, (uintptr_t) readbuf, bwr.read_consumed, 0);

if (res == 0) return 0;

if (res

}

fail:

memset(reply, 0, sizeof(*reply));

reply->flags |= BIO_F_IOERROR;

return -1;

}

我们看到在 writebuf 中构造参数，构造参数放在 buf 中，用 binder_io 来描述。先把 binder_io 转换为 binder_write_read；在 ioctl 中调用它来发送数据；最后在 binder_parse 函数将 binder_write_read 转换为 binder_io。

下来我们再来看看 IPC 是怎么进行数据交互的。我们前面说了，IPC 传输方式有三个要素：

1. 源(自己)

2. 目的：用 handle 表示“服务”，即向实现该“服务”的进程发送数据；handle 是“服务”的引用。

3. 数据。

handle 是进程 A 对进程 B 提供的服务 S 的引用。

下来我们来解释下上面那句话中的一些关键词：

引用，code 如下struct binder_ref {

/* Lookups needed: */

/* node + proc => ref (transaction) */

/* desc + proc => ref (transaction, inc/dec ref) */

/* node => refs + procs (proc exit) */

int debug_id;

struct rb_node rb_node_desc;

struct rb_node rb_node_node;

struct hlist_node node_entry;

struct binder_proc *proc;

struct binder_node *node;

uint32_t desc;

int strong;

int weak;

struct binder_ref_death *death;

};

我们看到 binder_ref 结构体中有个 binder_node 结构体，这个 binder_node 便指的是服务 S。code 如下struct binder_node {

int debug_id;

struct binder_work work;

union {

struct rb_node rb_node;

struct hlist_node dead_node;

};

struct binder_proc *proc;

struct hlist_head refs;

int internal_strong_refs;

int local_weak_refs;

int local_strong_refs;

void __user *ptr;

void __user *cookie;

unsigned has_strong_ref:1;

unsigned pending_strong_ref:1;

unsigned has_weak_ref:1;

unsigned pending_weak_ref:1;

unsigned has_async_transaction:1;

unsigned accept_fds:1;

unsigned min_priority:8;

struct list_head async_todo;

};

在 binder_node 结构体中有个 binder_proc 结构体，这个 binder_proc 便指的是进程 B。code 如下struct binder_proc {

struct hlist_node proc_node;

struct rb_root threads;

struct rb_root nodes;

struct rb_root refs_by_desc;

struct rb_root refs_by_node;

int pid;

struct vm_area_struct *vma;

struct mm_struct *vma_vm_mm;

struct task_struct *tsk;

struct files_struct *files;

struct hlist_node deferred_work_node;

int deferred_work;

void *buffer;

ptrdiff_t user_buffer_offset;

struct list_head buffers;

struct rb_root free_buffers;

struct rb_root allocated_buffers;

size_t free_async_space;

struct page **pages;

size_t buffer_size;

uint32_t buffer_free;

struct list_head todo;

wait_queue_head_t wait;

struct binder_stats stats;

struct list_head delivered_death;

int max_threads;

int requested_threads;

int requested_threads_started;

int ready_threads;

long default_priority;

struct dentry *debugfs_entry;

};

在 binder_proc 结构体中有个 threads 结构体，这个 threads 便指的是多线程。code 如下struct binder_thread {

struct binder_proc *proc;

struct rb_node rb_node;

int pid;

int looper;

struct binder_transaction *transaction_stack;

struct list_head todo;

uint32_t return_error; /* Write failed, return error code in read buf */

uint32_t return_error2; /* Write failed, return error code in read */

/* buffer. Used when sending a reply to a dead process that */

/* we are also waiting on */

wait_queue_head_t wait;

struct binder_stats stats;

};

现在我们就知道多线程是怎么来进行信息的传输了。

server 传入一个 flat_binder_object 给驱动：

1. 在内核态驱动里为每个服务创建 binder_node。binder_node.proc = server 进程

2. service_manger 在驱动中创建 binder_ref，引用 binder_node 。binder_ref.desc = 1，2，3... ；在用户态创建服务链表(name，handle)，handle 指的是前面的 binder_ref.desc

3. client 向 service_manger 查询服务，传 name

4. service_manger 返回 handle 给驱动程序

5. 驱动程序在 service_manger 的 binder_ref 红黑树中根据 handle 找到 binder_ref，再根据 binder_ref.node 找到 binder_node，最后给 client 创建新的 binder_ref(它的 desc 从 1 开始)。驱动返回 desc 给 client，它即为 handle

6. client：驱动根据 handle 找到 binder_ref，根据 binder_ref 找到 binder_node，最后根据 binder_node 找到 server 进程。

下来我们来看看数据传输过程(进程切换)

client 到 server ，是先写后读：

1. client 构造数据，调用 ioctl 发数据；

2. 驱动里根据 handle 找到 server 进程；

3. 把数据放入进程的 binder_proc.todo；

4. 休眠；

5. 被唤醒；

6. 从 todo 链表中取出数据，返回用户空间。

server端，先读后写：

1. 读数据休眠；

2. 被唤醒；

3. 从 todo 链表中取出数据，返回用户空间；

4. 处理数据；

5. 把结果写给 client，也就是放入 client 的 binder_proc.todo 链表，唤醒 client。

那么一般情况下，数据是如何进行复制的呢？一般方法，需要 2 次复制。

1. client 构造数据；

2. 驱动：copy_from_user

3. server：3.1 驱动，copy_to_user

3.2 用户态处理

binder复制数据的方法是只需 1 次复制。

1. server 进行 mmap 映射，用户态可以直接访问驱动中的某块内存。

2. client 构造数据，驱动：copy_from_user

3. server 可以在用户态直接使用数据。

但是值得注意的是：在 binder 方法中，从 test_client 到 test_server 端有个数据需复制 2 次。在 ioctl 时，binder_write_read 结构体先 copy_from_user 到某个内存局部变量，然后再 copy_to_user 到 test_server 端。别的数据都是从 test_cliet 端 copy_from_user 到内核内存，然后 test_server 端直接通过 mmap 可以访问到内核内存，不用经过 copy_to_user 复制。因此 binder 系统在进行通信时效率能提高一倍。

接下来我们来看看服务注册过程，我们先来看看 binder 的驱动框架。我们在 binder_init 函数中看到它是使用 misc_register 来注册的，说明它是 misc 设备驱动。通过注册 binder_miscdev 结构体以达到调用 binder_fops 结构体，在 binder_fops 结构体中就含有 binder 驱动各种操作的入口函数。具体代码如下static int __init binder_init(void)

{

int ret;

binder_deferred_workqueue = create_singlethread_workqueue("binder");

if (!binder_deferred_workqueue)

return -ENOMEM;

binder_debugfs_dir_entry_root = debugfs_create_dir("binder", NULL);

if (binder_debugfs_dir_entry_root)

binder_debugfs_dir_entry_proc = debugfs_create_dir("proc",

binder_debugfs_dir_entry_root);

ret = misc_register(&binder_miscdev);

if (binder_debugfs_dir_entry_root) {

debugfs_create_file("state",

S_IRUGO,