Andorid Binder进程间通信---Binder对象死亡通知机制

首页 > 代码库 > Andorid Binder进程间通信---Binder对象死亡通知机制

Andorid Binder进程间通信---Binder对象死亡通知机制

2024-07-06 17:57:11 225人阅读

本文参考《Android系统源代码情景分析》，作者罗升阳。

一、Binder库(libbinder)代码：

~/Android/frameworks/base/libs/binder

----BpBinder.cpp

----Parcel.cpp

----ProcessState.cpp

----Binder.cpp

----IInterface.cpp

----IPCThreadState.cpp

----IServiceManager.cpp

----Static.cpp

~/Android/frameworks/base/include/binder

----Binder.h

----BpBinder.h

----IInterface.h

----IPCThreadState.h

----IServiceManager.h

----IBinder.h

----Parcel.h

----ProcessState.h

驱动层代码：

～/Android//kernel/goldfish/drivers/staging/android

----binder.c

----binder.h

二、总体概述

如果Binder本地对象意外死亡，会导致依赖于它的Binder代理对象变得无效。

我们将分析Binder对象死亡通知机制，它可以监控到Binder本地对象的死亡事件，然后通知那些引用了它的Binder代理对象，从而在一定程度上解决无效Binder代理对象的问题。

在这种死亡机制中，首先是Binder代理对象将一个死亡接收通知注册到Binder驱动程序中，然后当Binder驱动程序监控到它所引用的Binder本地对象死亡时，Binder驱动程序就会向它发送一个死亡通知。

另外，当一个Binder代理对象不需要接收它所引用的Binder本地对象的死亡通知时，它也可以注销之前所注册的死亡接受通知。

三、注册死亡通知

Binder代理对象在注册它所引用的Binder本地对象的死亡接受通知之前，首先要定义好死亡通知接受者。Binder库定义了死亡通知接受者必须要继承的基类DeathRecipient，它的实现如下所示：

~/Android/frameworks/base/include/binder

----IBinder.h

class IBinder : public virtual RefBase
{
public:
   
    class DeathRecipient : public virtual RefBase
    {
    public:
        virtual void binderDied(const wp<IBinder>& who) = 0;//重写父类DeathRecipient的成员函数binderDied
    };

    ......
};

自定义的死亡通知接受者必须要重写父类DeathRecipient的成员函数binderDied。当Binder驱动程序通知一个Binder代理对象它所引用的Binder本地对象已经死亡时，就会调用它所指定的死亡通知接受者的成员函数binderDied。

定义好死亡通知接受者之后，我们就可以调用Binder代理对象的成员函数linkToDeath来注册一个死亡接受通知了。实现如下：

~/Android/frameworks/base/libs/binder

----BpBinder.cpp

status_t BpBinder::linkToDeath(
    const sp<DeathRecipient>& recipient, void* cookie, uint32_t flags)
{
    Obituary ob;
    ob.recipient = recipient;
    ob.cookie = cookie;//用来标识死亡接受者
    ob.flags = flags;//用来标识死亡接受者

    ......

    {
        AutoMutex _l(mLock);

        if (!mObitsSent) {//mObitsSent用来表示Binder驱动程序是否已经向它发送过死亡通知，如果是，直接返回DEAD_OBJECT
            if (!mObituaries) {//第一次注册
                mObituaries = new Vector<Obituary>;//初始化卟告列表
                if (!mObituaries) {
                    return NO_MEMORY;
                }
                LOGV("Requesting death notification: %p handle %d\n", this, mHandle);
                getWeakRefs()->incWeak(this);//增加了弱引用计数
                IPCThreadState* self = IPCThreadState::self();
                self->requestDeathNotification(mHandle, this);//调用requestDeathNotification
                self->flushCommands();//促使当前线程马上通过IO控制命令BINDER_WRITE_READ进入到Binder驱动程序中，以便可以执行注册死亡接受通知的操作
            }
            ssize_t res = mObituaries->add(ob);//非第一个注册，直接加入到卟告列表中
            return res >= (ssize_t)NO_ERROR ? (status_t)NO_ERROR : res;
        }
    }

    return DEAD_OBJECT;
}

该函数第一个参数为自定义的死亡通知接受者，第二个参数cookie和第三个参数flags也是用来标志一个死亡通知接受者的，在注销死亡接受通知时会用到。

我们可以为一个Binder代理对象同时注册多个死亡通知接受者，它们保存在Binder代理对象内部的一个卟告列表mObituaries中。

Binder代理对象内部的成员变量mObitsSent用来表示Binder驱动程序是否已经向它发送过死亡通知，如果是，这个成员变量的值就等于1，在这种情况下，Binder代理对象的成员函数linkToDeath就会直接返回一个DEAD_OBJECT值，表示对应的Binder本地对象已经死亡了。

如果mObitsSent的值等于0，那么成员函数linkToDeath首先将死亡通知接受者封装成一个Obituary对象，接着将它添加到内部的卟告列表mObituaries中。如果是第一次注册，那么函数会调用当前线程中的IPCThreadState对象的成员函数requestDeathNotification，它的实现如下：
~/Android/frameworks/base/libs/binder
----IPCThreadState.cpp

status_t IPCThreadState::requestDeathNotification(int32_t handle, BpBinder* proxy)
{
    mOut.writeInt32(BC_REQUEST_DEATH_NOTIFICATION);
    mOut.writeInt32((int32_t)handle);//Binder代理对象的句柄值
    mOut.writeInt32((int32_t)proxy);//Binder代理对象的地址值
    return NO_ERROR;
}

传递了三个参数，第一个是命令，第二个是Binder代理对象的句柄值，第三个参数是Binder代理对象的地址值。

回到Binder代理对象的成员函数linkToDeath中，接下来就会调用当前线程的IPCThreadState对象的成员函数flushCommands促使当前线程马上通过IO控制命令BINDER_WRITE_READ进入到Binder驱动程序中，以便可以执行注册死亡接受通知的操作。
~/Android/frameworks/base/libs/binder
----IPCThreadState.cpp

void IPCThreadState::flushCommands()
{
    if (mProcess->mDriverFD <= 0)
        return;
    talkWithDriver(false);
}

进入到Binder驱动程序之后，函数binder_thread_write就会被调用来处理BC_REQUEST_DEATH_NOTIFICATION协议，如下：

～/Android//kernel/goldfish/drivers/staging/android

---binder.c

int
binder_thread_write(struct binder_proc *proc, struct binder_thread *thread,
		    void __user *buffer, int size, signed long *consumed)
{
	uint32_t cmd;
	void __user *ptr = buffer + *consumed;
	void __user *end = buffer + size;

	while (ptr < end && thread->return_error == BR_OK) {
		if (get_user(cmd, (uint32_t __user *)ptr))
			return -EFAULT;
		ptr += sizeof(uint32_t);
		.......
		switch (cmd) {//BC_REQUEST_DEATH_NOTIFICATION
		.......

		case BC_REQUEST_DEATH_NOTIFICATION:
		case BC_CLEAR_DEATH_NOTIFICATION: {
			uint32_t target;
			void __user *cookie;
			struct binder_ref *ref;
			struct binder_ref_death *death;

			if (get_user(target, (uint32_t __user *)ptr))//Binder代理对象的句柄值
				return -EFAULT;
			ptr += sizeof(uint32_t);
			if (get_user(cookie, (void __user * __user *)ptr))//Binder代理对象的地址值
				return -EFAULT;
			ptr += sizeof(void *);
			ref = binder_get_ref(proc, target);//根据句柄值target得到一个Binder引用对象ref
			if (ref == NULL) {
				.....
				break;
			}

			......

			if (cmd == BC_REQUEST_DEATH_NOTIFICATION) {
				if (ref->death) {//为NULL
					binder_user_error("binder: %d:%"
						"d BC_REQUEST_DEATH_NOTI"
						"FICATION death notific"
						"ation already set\n",
						proc->pid, thread->pid);
					break;
				}
				death = kzalloc(sizeof(*death), GFP_KERNEL);//分配一个binder_ref_death结构体
				if (death == NULL) {
					......
				}
				.......
				INIT_LIST_HEAD(&death->work.entry);//初始化成员变量work
				death->cookie = cookie;//Binder代理对象的地址值
				ref->death = death;//将它保存在Binder引用对象ref的成员变量death中
				if (ref->node->proc == NULL) {//正在注册的Binder引用对象所引用的Binder本地对象已经死亡了
					ref->death->work.type = BINDER_WORK_DEAD_BINDER;//将一个类型为BINDER_WORK_DEAD_BINDER的工作项添加到当前线程或者当前线程所在的Client进程的todo队列中，以便可以向Client进程发送一个死亡接受通知
					if (thread->looper & (BINDER_LOOPER_STATE_REGISTERED | BINDER_LOOPER_STATE_ENTERED)) {
						list_add_tail(&ref->death->work.entry, &thread->todo);//Binder线程
					} else {
						list_add_tail(&ref->death->work.entry, &proc->todo);//不是一个Binder线程
						wake_up_interruptible(&proc->wait);
					}
				}
			} else {
				.......
			}
		} break;
		......
		*consumed = ptr - buffer;
	}
	return 0;
}

分别将Client进程传进来的Binder代理独象的句柄值和地址值保存在变量target和cookie中，然后根据句柄值target得到一个Binder引用对象ref。如果ref的成员变量death为NULL，那么创建一个binder_ref_death结构体，接着将用户空间传过来的参数cookie保存在它的成员变量cookie中，最后再将它保存在Binder引用对象ref的成员变量death中。

死亡接受通知的注册操作就完成了。但是可能会出现这样一种情况，即正在注册的Binder引用对象所引用的Binder本地对象已经死亡了。这时候驱动程序就需要马上向Client进程发送一个死亡接受通知；否则，以后就没有机会发送这个通知了。现在的问题是，如何判断一个Binder引用对象所引用的Binder本地对象已经死亡了呢？一个Binder引用对象所引用的Binder实体对象保存在它的成员变量node中，而一个Binder实体对象的宿主进程结构体为NULL，那么就说明它所引用的Binder本地对象已经死亡了，因为它所在的进程已经不存在了。

在正在注册的Binder引用对象所引用的Binder本地对象已经死亡了这种情况下，将一个类型为BINDER_WORK_DEAD_BINDER的工作项添加到当前线程或者当前线程所在的Client进程的todo队列中，以便可以向Client进程发送一个死亡接受通知。

如果当前线程是Binder线程，这时候就可以将一个死亡接受通知就近发送给它处理了。如果当前线程不是一个Binder线程，那么Binder驱动程序就会将发送死亡接受通知的工作项添加到Client进程的todo队列中，等待其他的Binder线程来处理。

四、发送死亡接受通知

Server进程本来是应该常驻在系统中为Client进程提供服务的，但是可能会出现意外情况，导致它异常退出，Server进程一旦异常退出之后，运行在它里面的Binder本地对象就意外死亡了。这时候Binder驱动程序就应该向那些引用了它的Binder代理对象发送死亡接受通知，以便它们可以知道自己引用了一个无效的Binder本地对象。

现在的关键问题是，Binder驱动程序是如何知道一个Server进程退出运行了呢？Binder驱动程序将设备文件/dev/binder的释放操作方法设置为函数binder_release。Server进程在启动时，会调用函数open来打开设备文件/dev/binder。一方面，在正常情况下，它退出时会调用函数close来关闭设备文件/dev/binder，这时候就会触发函数binder_releasse被调用；另一方面，如果Server进程异常退出，即它没有正常关闭设备文件/dev/binder，那么内核就会负责关闭它，这个时候也会触发函数binder_release被调用。因此，Binder驱动程序就可以在函数binder_release中检查进程退出时，是否有Binder本地对象在里面运行。如果有，就说明它们是死亡了的Binder本地对象了。

binder_release实现如下：

～/Android//kernel/goldfish/drivers/staging/android

---binder.c

static int binder_release(struct inode *nodp, struct file *filp)
{
	struct binder_proc *proc = filp->private_data;
	if (binder_proc_dir_entry_proc) {
		char strbuf[11];
		snprintf(strbuf, sizeof(strbuf), "%u", proc->pid);
		remove_proc_entry(strbuf, binder_proc_dir_entry_proc);
	}

	binder_defer_work(proc, BINDER_DEFERRED_RELEASE);
	
	return 0;
}

首先将之前为进程在/proc/binder/proc目录中创建的文件删除。由于检查进程中是否有Binder本地对象，以及资源释放操作都比较耗时，因此调用函数binder_defer_work将一个BINDER_DEFERRED_RELEASE类型的延迟操作添加到一个全局的hash列表中。

BINDER_DEFERRED_RELEASE类型的延迟操作最终是由函数binder_deferred_release来执行的。

～/Android//kernel/goldfish/drivers/staging/android

---binder.c

static void binder_deferred_release(struct binder_proc *proc)
{
	struct hlist_node *pos;
	......
	nodes = 0;
	incoming_refs = 0;
	while ((n = rb_first(&proc->nodes))) {
		struct binder_node *node = rb_entry(n, struct binder_node, rb_node);//检查目标进程proc的Binder实体对象列表nodes的每一个Binder实体对象

		......
		if (hlist_empty(&node->refs)) {
			.....
		} else {
			struct binder_ref *ref;
			.....

			hlist_for_each_entry(ref, pos, &node->refs, node_entry) {//得到这些Binder实体对象的Binder引用对象列表refs
				........
				if (ref->death) {//如果注册过死亡接受通知
					......
					if (list_empty(&ref->death->work.entry)) {
						ref->death->work.type = BINDER_WORK_DEAD_BINDER;//将一个BINDER_WORK_DEAD_BINDER类型的工作项添加到对应的Client进程的todo队列中
						list_add_tail(&ref->death->work.entry, &ref->proc->todo);
						wake_up_interruptible(&ref->proc->wait);//来唤醒这些Client进程来处理这些死亡接受通知
					} else
						BUG();
				}
			}
			.....
		}
	}
	......

while循环检查目标进程proc的Binder实体对象列表nodes的每一个Binder实体对象，如果这些Binder实体对象的Binder引用对象列表refs不为空，就检查这些Binder引用对象对应的Binder代理对象注册过死亡接受通知。如果注册过死亡接受通知，那么就将一个BINDER_WORK_DEAD_BINDER类型的工作项添加到对应的Client进程的todo队列中，并调用函数wake_up_interruptible来唤醒这些Client进程来处理这些死亡接受通知。

Client进程中的Binder线程在空闲时，会睡眠在Binder驱动程序的函数binder_thread_read中，因此，当它们被唤醒之后，就会继续执行函数binder_thread_read，并且检查自己以及宿主进程的todo队列，看看有没有工作项要处理。

～/Android//kernel/goldfish/drivers/staging/android

---binder.c

static int
binder_thread_read(struct binder_proc *proc, struct binder_thread *thread,
	void  __user *buffer, int size, signed long *consumed, int non_block)
{
	void __user *ptr = buffer + *consumed;
	void __user *end = buffer + size;
        .........

	while (1) {
		uint32_t cmd;
		..... 
		struct binder_work *w;
		.....

		if (!list_empty(&thread->todo))
			w = list_first_entry(&thread->todo, struct binder_work, entry);
		else if (!list_empty(&proc->todo) && wait_for_proc_work)
			w = list_first_entry(&proc->todo, struct binder_work, entry);
		else {
			..........
		}

		......

		switch (w->type) {
		......
		case BINDER_WORK_DEAD_BINDER:
		case BINDER_WORK_DEAD_BINDER_AND_CLEAR:
		case BINDER_WORK_CLEAR_DEATH_NOTIFICATION: {
			struct binder_ref_death *death = container_of(w, struct binder_ref_death, work);
			uint32_t cmd;
			if (w->type == BINDER_WORK_CLEAR_DEATH_NOTIFICATION)
				cmd = BR_CLEAR_DEATH_NOTIFICATION_DONE;
			else
				cmd = BR_DEAD_BINDER;
			if (put_user(cmd, (uint32_t __user *)ptr))
				return -EFAULT;
			ptr += sizeof(uint32_t);
			if (put_user(death->cookie, (void * __user *)ptr))
				return -EFAULT;
			ptr += sizeof(void *);
			.....
			if (w->type == BINDER_WORK_CLEAR_DEATH_NOTIFICATION) {
				......
			} else
				list_move(&w->entry, &proc->delivered_death);
			if (cmd == BR_DEAD_BINDER)
				goto done; /* DEAD_BINDER notifications can cause transactions */
		} break;
		}

		......
done:
	*consumed = ptr - buffer;
	......
	return 0;
}

死亡接收通知的类型有三种，除了前面我们遇到的BINDER_WORK_DEAD_BINDER之外，还有BINDER_WORK_CLEAR_NOTIFICATION和BINDER_WORK_DEAD_BINDER_AND_CLEAR。其中BINDER_WORK_CLEAR_NOTIFICATION类型的死亡接受

声明：以上内容来自用户投稿及互联网公开渠道收集整理发布，本网站不拥有所有权，未作人工编辑处理，也不承担相关法律责任，若内容有误或涉及侵权可进行投诉：投诉/举报工作人员会在5个工作日内联系你，一经查实，本站将立刻删除涉嫌侵权内容。

联系
我们

首页 > 代码库 > Andorid Binder进程间通信---Binder对象死亡通知机制

Andorid Binder进程间通信---Binder对象死亡通知机制

看完仍有疑问？有类似问题直接问程序猿