devbox
花生_TL007
这个屌丝很懒，什么也没留下！
关注作者
热门标签
热门文章
当前位置:   article > 正文

Binder系列11 死亡通知机制_uncaught exception from death notification

作者：花生_TL007 | 2024-03-15 23:35:52

赞

踩

uncaught exception from death notification

死亡通知机制概述 　　

如果在 binder 通信已经建立的情况下，出现 binder 服务端的进程意外挂掉，这个挂掉的原因可能是因为进程本身内部发生的错误，也有可能是其它情况导致进程被系统强制结束，总之这个服务端进程是存在意外挂掉的可能的，如果出现这种情况，而 binder 代理端不知道的话，那么代理端继续调用不存在的服务端时肯定会出错．这个时候就需要有一种机制来通知到依赖这个服务的 binder 代理端，好让代理端作出相应的操作，以保证代理端进程不会因为 binder 服务端进程的意外挂掉而出错。这个机制就是 binder 提供的死亡通知机制。

在这种死亡通知机制中，首先是 Binder 代理对象（BpBinder）通过发送命令 BC_REQUEST_DEATH_NOTIFICATION 到驱动，告诉 Binder 驱动这个 Binder 代理对象要注册一个死亡接收通知，注册完成之后，驱动就会在对应 binder_ref 的 death 中做好标记．如果对应的 Binder 服务端的进程因为意外发生挂掉，Binder 驱动会释放掉这个服务端进程对应的 binder_proc 中 nodes 树的所有 binder_node 节点，在释放 binder_node 节点的过程中，会遍历所有引用这个节点的引用树 refs,其中 binder 代理对象在驱动中的表示 binder 引用 binder_ref 就链接在这个引用树中，这样驱动就会找到这个 binder_ref，并检查这个 binder 引用的 death 值是否为空，如果不为空则说明已经注册了死亡通知，如果为空，则说明没有注册死亡通知，这样驱动就根据 binder_ref 的 death 值来决定是否向其发送死亡通知，这个就是大体流程。

当然，如果一个 Binder 代理对象（BpBinder）不需要接收它所引用的 Binder 本地对象(BBinder）的死亡通知时，它也可以注销之前所注册的死亡接受通知。

下面我们从死亡通知的注册，注销，触发和处理四个方面分别阐述其过程，以了解其原理。最后分析下 java 层如何通过 JNI 和 native 进行通信以及使用例子。

相关代码路徑：

  1. frameworks/base/core/java/android/os/Binder.java
  2. frameworks/base/core/jni/android_util_Binder.cpp
  3. frameworks/native/libs/binder/BpBinder.cpp

一　死亡通知的注册

Binder 代理对象（BpBinder）通过 linkToDeath 函数实现对死亡通知的注册，代码如下：

BpBinder.cpp

  1. status_t BpBinder::linkToDeath(
  2.     const sp<DeathRecipient>& recipient, void* cookie, uint32_t flags)
  3. {
  4.     Obituary ob;
  5.     ob.recipient = recipient;// 具体的死亡接收通知
  6.     ob.cookie = cookie;　// 这个参数一般为 null
  7.     ob.flags = flags;　// 生成一个新的 Obituary,并赋值
  8.  
  9.     LOG_ALWAYS_FATAL_IF(recipient == NULL,
  10.                         "linkToDeath(): recipient must be non-NULL");
  11.  
  12.     {
  13.         AutoMutex _l(mLock);
  14.  
  15. //驱动是否已经发送过死亡通知，如果没有发送过则执行注册操作
  16.         if (!mObitsSent) {　
  17.             if (!mObituaries) {//向量表不存在的话，生成新的向量表，
  18. // 并向驱动发送注册请求，如果向量表存在的话，就不需要向驱动发送请求
  19. // 直接把 Obituary 添加到 mObituaries 向量表中既可
  20.                 mObituaries = new Vector<Obituary>;
  21.                 if (!mObituaries) {
  22.                     return NO_MEMORY;
  23.                 }
  24.                 ALOGV("Requesting death notification: %p handle %d\n",
  25. this, mHandle);
  26.                 getWeakRefs()->incWeak(this);
  27.                 IPCThreadState* self = IPCThreadState::self();
  28. // 向mOut写入注册死亡通知的命令
  29.                 self->requestDeathNotification(mHandle, this);
  30.                 self->flushCommands();
  31.             }
  32. //把新生成的Obituary放入向量表中
  33.             ssize_t res = mObituaries->add(ob);
  34.             return res >= (ssize_t)NO_ERROR ? (status_t)NO_ERROR : res;
  35.         }
  36.     }
  37.  
  38.     return DEAD_OBJECT;
  39. }

以上死亡通知的注册函数有以下几个关键变量需要注意：

mObituaries 是一个向量表，里边是 Obituary 的集合，而 Obituary 是封装了死亡接收通知 DeathRecipient 的一个对象，我们可以认为，每一个 Obituary 就代表注册了一个死亡接收通知，从代码中可以看出一个 Binder 代理对象可以注册多个死亡接收通知 Obituary，并把这些注册好的 Obituary 放到向量表 mObituaries 中。

mObitsSent 这个变量代表 Binder 驱动是否已经向 binder 代理发送了死亡通知，如果已经发送了则为１，否则为 0，如果已经发送了，则就不需要注册了，直接返回 DEAD_OBJECT。

从以上代码中还可以看到负责注册死亡通知的函数 requestDeathNotification 只会在第一次创建 mObituaries 的时候会被执行．其它情况下只需要把死亡接收通知 Obituary 直接添加到 mObituaries 中既可，不需要多次注册．也就是不管 binder 代理端调用 linkToDeath 函数多少次，实际上只会向驱动请求一次，并且是第一次的时候向驱动请求。

只向驱动请求一次的原因是 Binder 代理注册死亡通知后，驱动就已经知道了，如果服务端进程挂掉，那么我就要通知这个 Binder 代理，当 binder 代理收到死亡通知后，只需要遍历 mObituaries 向量表中的 Obituary，分别回调其中的 DeathRecipient 的 binderDied 方法既可，所以就不需要多次向 Binder 驱动重复请求了．

IPCThreadState.cpp

  1. status_t IPCThreadState::requestDeathNotification(int32_t handle,
  2.         BpBinder* proxy)
  3. {
  4.     mOut.writeInt32(BC_REQUEST_DEATH_NOTIFICATION);
  5.     mOut.writeInt32((int32_t)handle);
  6.     mOut.writePointer((uintptr_t)proxy);
  7.     return NO_ERROR;
  8. }

从以上代码中可以看到 requestDeathNotification 就是把　BC_REQUEST_DEATH_NOTIFICATION 命令发送到 Binder 驱动端，其中的参数是 binder 代理对象的句柄 handle，还有 binder 代理对象的地址 proxy，把这些数据填充到 mOut 中，然后整理成 binder_write_read 数据，通过 ioctl 的 BINDER_WRITE_READ 协议写入到 Binder 驱动中。其中的 BC_REQUEST_DEATH_NOTIFICATION 就是向 Binder 驱动注册死亡接收通知的命令。

接着看 binder 驱动端如何处理 BC_REQUEST_DEATH_NOTIFICATION 命令，代码如下：

  1. static int binder_thread_write(struct binder_proc *proc,
  2. 			struct binder_thread *thread,
  3. 			binder_uintptr_t binder_buffer, size_t size,
  4. 			binder_size_t *consumed)
  5. {
  6. 	uint32_t cmd;
  7. 	struct binder_context *context = proc->context;
  8. 	void __user *buffer = (void __user *)(uintptr_t)binder_buffer;
  9. 	void __user *ptr = buffer + *consumed;
  10. 	void __user *end = buffer + size;
  11.  
  12. 	while (ptr < end && thread->return_error.cmd == BR_OK) {
  13. 		int ret;
  14.  
  15. 		if (get_user(cmd, (uint32_t __user *)ptr))
  16. 			return -EFAULT;
  17. 		ptr += sizeof(uint32_t);
  18. 		trace_binder_command(cmd);
  19. 		if (_IOC_NR(cmd) < ARRAY_SIZE(binder_stats.bc)) {
  20. 			atomic_inc(&binder_stats.bc[_IOC_NR(cmd)]);
  21. 			atomic_inc(&proc->stats.bc[_IOC_NR(cmd)]);
  22. 			atomic_inc(&thread->stats.bc[_IOC_NR(cmd)]);
  23. 		}
  24. 		switch (cmd) {
  25. 		case BC_INCREFS:
  26. 		case BC_ACQUIRE:
  27. 		case BC_RELEASE:
  28. 　　　　．．．．．．．．．．．．．．．．．
  29. 　　　　　　　　　case BC_REQUEST_DEATH_NOTIFICATION:
  30. 		case BC_CLEAR_DEATH_NOTIFICATION: {
  31. // BpBinder对应的句柄值，用来找到驱动端对应的 binder_ref
  32. 			uint32_t target;　
  33. // 代理对象 BpBinder 的地址
  34. 			binder_uintptr_t cookie; 
  35. 			struct binder_ref *ref;
  36. // binder_ref 对应的死亡通知
  37. 			struct binder_ref_death *death = NULL;
  38. // 从用户空间获取代理对象的句柄值
  39. 			if (get_user(target, (uint32_t __user *)ptr))　
  40. 				return -EFAULT;
  41. 			ptr += sizeof(uint32_t);
  42. // 获取代理对象的地址
  43. 			if (get_user(cookie, (binder_uintptr_t __user *)ptr))
  44. 				return -EFAULT;
  45. 			ptr += sizeof(binder_uintptr_t);
  46. 			if (cmd == BC_REQUEST_DEATH_NOTIFICATION) {
  47. 				/*
  48. 				 * Allocate memory for death notification
  49. 				 * before taking lock
  50. 				 */
  51. // 给 binder_ref_death 分配地址空间
  52. 				death = kzalloc(sizeof(*death), GFP_KERNEL);
  53. 				if (death == NULL) {
  54. 					WARN_ON(thread->return_error.cmd !=
  55. 						BR_OK);
  56. 					thread->return_error.cmd = BR_ERROR;
  57. 					binder_enqueue_thread_work(
  58. 						thread,
  59. 						&thread->return_error.work);
  60. 					binder_debug(
  61. 						BINDER_DEBUG_FAILED_TRANSACTION,
  62. 						"%d:%d BC_REQUEST_DEATH_NOTIFICATION failed\n",
  63. 						proc->pid, thread->pid);
  64. 					break;
  65. 				}
  66. 			}
  67. 			binder_proc_lock(proc);
  68. // 根据句柄获得对应的 binder_ref
  69. 			ref = binder_get_ref_olocked(proc, target, false);
  70. 			if (ref == NULL) {
  71. 				binder_user_error("%d:%d %s invalid ref %d\n",
  72. 					proc->pid, thread->pid,
  73. 					cmd == BC_REQUEST_DEATH_NOTIFICATION ?
  74. 					"BC_REQUEST_DEATH_NOTIFICATION" :
  75. 					"BC_CLEAR_DEATH_NOTIFICATION",
  76. 					target);
  77. 				binder_proc_unlock(proc);
  78. 				kfree(death);
  79. 				break;
  80. 			}
  81.  
  82. 		.......................
  83.  
  84. 			binder_node_lock(ref->node);
  85. 			if (cmd == BC_REQUEST_DEATH_NOTIFICATION) {
  86. 				if (ref->death) {
  87. 					binder_user_error(
  88. "%d:%d BC_REQUEST_DEATH_NOTIFICATION death notification already set\n",
  89. proc->pid, thread->pid);
  90. 					binder_node_unlock(ref->node);
  91. 					binder_proc_unlock(proc);
  92. 					kfree(death);
  93. 					break;
  94. 				}
  95. 				binder_stats_created(BINDER_STAT_DEATH);
  96. // 初始化 binder_ref_death 的 work
  97. 				INIT_LIST_HEAD(&death->work.entry);
  98. // 把代理对象地址赋值给 death 的 cookie
  99. 				death->cookie = cookie;
  100. // 把 binder_ref_death 赋值给 binder_ref 的 death,完成死亡通知的注册
  101. 				ref->death = death; 
  102. // 代理对象对应的服务端进程已经死亡（异常情况）
  103. 				if (ref->node->proc == NULL) {
  104. // 修改 work type，这个代表死亡通知
  105. 					ref->death->work.type = BINDER_WORK_DEAD_BINDER;
  106.  
  107. 					binder_inner_proc_lock(proc);
  108. // 把 binder_ref_death 的 work 添加到代理端进程的等待队列 todo 中
  109. 					binder_enqueue_work_ilocked(
  110. 						&ref->death->work, &proc->todo);
  111. // 唤醒代理端进程来处理死亡通知
  112. 					binder_wakeup_proc_ilocked(proc);
  113. 					binder_inner_proc_unlock(proc);
  114. 				}
  115. 			} else {
  116. 				．．．．．．．．．．．．．．．．．．．．．．
  117. 			}
  118. 			binder_node_unlock(ref->node);
  119. 			binder_proc_unlock(proc);
  120. 		} break;

从以上代码可以看到向 Binder 驱动注册死亡接收通知非常简单，其实就是新建一个 binder_ref_death 对象，把代表 Binder 代理对象的 cookie 赋值给 binder_ref_death 的 cookie，并初始化其中的 wrok，然后把 binder_ref_death 对象赋值给代理对象对应的 binder_ref 的 death 就可以了．以后 binder 驱动会根据 binder_ref 的 death 是否存在来决定是否向其发送死亡通知。

从代码中可以看到对 binder_ref 的 death 赋值完毕后，会有一个 ref->node->proc 是否为空的判断，也就是在刚注册完死亡通知后，驱动程序会立马判断服务端进程是否已经挂掉，如果已经挂掉了，那么把这个 death 的 work 赋值为 BINDER_WORK_DEAD_BINDER 并添加到代理端进程的等待队列 todo 中，并唤醒代理端进程，处理 BINDER_WORK_DEAD_BINDER 任务，这个就是处理死亡通知的事情了，后面会介绍．其中发送的 BINDER_WORK_DEAD_BINDER 就是发送死亡通知了．这个情况也是考虑到在注册死亡通知的时候，服务端进程其实已经挂掉了，虽然概率很低，但是如果不检查的话，那么注册后，后续 Binder 代理是收不到死亡通知的，这个需要注意。

  1. struct binder_ref_death {
  2. 	/**
  3. 	 * @work: worklist element for death notifications
  4. 	 *        (protected by inner_lock of the proc that
  5. 	 *        this ref belongs to)
  6. 	 */
  7. 	struct binder_work work;
  8. 	binder_uintptr_t cookie;
  9. };

死亡接收通知的注册已经讲完了，说白了就是对 Binder 代理对象驱动层对应的 binder_ref 的 death 赋值，只要有了这个 death 值，驱动就知道这个 binder 引用 binder_ref 已经注册了死亡接收通知。这样一旦服务端进程意外挂掉的话，binder 驱动就会遍历服务端进程 binder_proc 中的 nodes 树中所有的 binder_node 节点，并对每个 binder_node 节点的 refs 链表做遍历操作，找出其中的每个依赖此 binder_node 节点的 binder_ref，然后检查 binder_ref 的 death 值，如果不为空，则就向其发送死亡通知。

二　死亡通知的注销

Binder 代理对象（BpBinder）通过 unlinkToDeath 函数实现对死亡通知的注销的，代码如下：

BpBinder.cpp

  1. status_t BpBinder::unlinkToDeath(
  2.     const wp<DeathRecipient>& recipient, void* cookie, uint32_t flags,
  3.     wp<DeathRecipient>* outRecipient)
  4. {
  5.     AutoMutex _l(mLock);
  6.  
  7.     if (mObitsSent) { // 已经发送过死亡通知了直接返回
  8.         return DEAD_OBJECT;
  9.     }
  10.  
  11.     const size_t N = mObituaries ? mObituaries->size() : 0;
  12. // 遍历 mObituaries 查找匹配的已经注册过的 DeathRecipient
  13.     for (size_t i=0; i<N; i++) {
  14.         const Obituary& obit = mObituaries->itemAt(i);
  15.         if ((obit.recipient == recipient
  16.                     || (recipient == NULL && obit.cookie == cookie))
  17.                 && obit.flags == flags) {
  18. // 匹配成功，找到之前已经注册过的 DeathRecipient
  19.             if (outRecipient != NULL) {
  20.                 *outRecipient = mObituaries->itemAt(i).recipient;
  21.             }
  22.             mObituaries->removeAt(i); // 执行移除操作
  23.             if (mObituaries->size() == 0) {
  24. // 全部移除完毕了，才会向驱动发送清除死亡消息的命令
  25.                 ALOGV("Clearing death notification: %p handle %d\n", 
  26.     this, mHandle);
  27.                 IPCThreadState* self = IPCThreadState::self();
  28.                 self->clearDeathNotification(mHandle, this);
  29.                 self->flushCommands();
  30.                 delete mObituaries;
  31.                 mObituaries = NULL;
  32.             }
  33.             return NO_ERROR;
  34.         }
  35.     }
  36.  
  37.     return NAME_NOT_FOUND;
  38. }

从以上代码可以看到 Binder 代理通过 unlinkToDeath 函数来注销注册过的死亡接收通知，每次执行一次注销操作，都会遍历 mObituaries 向量表，找出之前注册过的 Obituary，找到并匹配成功后，从 mObituaries 表中移除即可．当注册过的死亡通知全部被移除后，才会向 Binder 驱动发送注销死亡接收通知的命令，同注册时候一样，注销也是只向驱动发送一次注销命令．原因相同。

IPCThreadState.cpp

  1. status_t IPCThreadState::clearDeathNotification(int32_t handle,
  2.         BpBinder* proxy)
  3. {
  4.     mOut.writeInt32(BC_CLEAR_DEATH_NOTIFICATION);
  5.     mOut.writeInt32((int32_t)handle);
  6.     mOut.writePointer((uintptr_t)proxy);
  7.     return NO_ERROR;
  8. }

把 BC_CLEAR_DEATH_NOTIFICATION 命令　附带 binder 代理对象的句柄 handle 和 binder 代理对象的地址 proxy 添加到 mOut 中，然后发送给 binder 驱动，下面看驱动如何处理：

  1. static int binder_thread_write(struct binder_proc *proc,
  2. 			struct binder_thread *thread,
  3. 			binder_uintptr_t binder_buffer, size_t size,
  4. 			binder_size_t *consumed)
  5. {
  6. 	uint32_t cmd;
  7. 	struct binder_context *context = proc->context;
  8. 	void __user *buffer = (void __user *)(uintptr_t)binder_buffer;
  9. 	void __user *ptr = buffer + *consumed;
  10. 	void __user *end = buffer + size;
  11.  
  12. 	while (ptr < end && thread->return_error.cmd == BR_OK) {
  13. 		int ret;
  14.  
  15. 		if (get_user(cmd, (uint32_t __user *)ptr))
  16. 			return -EFAULT;
  17. 		ptr += sizeof(uint32_t);
  18. 		trace_binder_command(cmd);
  19. 		if (_IOC_NR(cmd) < ARRAY_SIZE(binder_stats.bc)) {
  20. 			atomic_inc(&binder_stats.bc[_IOC_NR(cmd)]);
  21. 			atomic_inc(&proc->stats.bc[_IOC_NR(cmd)]);
  22. 			atomic_inc(&thread->stats.bc[_IOC_NR(cmd)]);
  23. 		}
  24. 		switch (cmd) {
  25. 		case BC_INCREFS:
  26. 		case BC_ACQUIRE:
  27. 		case BC_RELEASE:
  28. 　　　　．．．．．．．．．．．．．．．．．
  29. 　　　　　　　　　case BC_REQUEST_DEATH_NOTIFICATION:
  30. 		case BC_CLEAR_DEATH_NOTIFICATION: {
  31. 			uint32_t target;// binder 代理对象的句柄值
  32. 			binder_uintptr_t cookie; // binder 代理对象的地址
  33. 			struct binder_ref *ref;
  34. 			struct binder_ref_death *death = NULL;
  35.  
  36. 			if (get_user(target, (uint32_t __user *)ptr))
  37. 				return -EFAULT;
  38. 			ptr += sizeof(uint32_t);
  39. 			if (get_user(cookie, (binder_uintptr_t __user *)ptr))
  40. 				return -EFAULT;
  41. 			ptr += sizeof(binder_uintptr_t);
  42. 			．．．．．．．．．．．．．．．．．
  43.  
  44. 			binder_proc_lock(proc);
  45. // 获取对应的 binder_ref
  46. 			ref = binder_get_ref_olocked(proc, target, false);
  47. 			if (ref == NULL) {
  48. 				......
  49. 			}
  50.  
  51. 			.............................
  52.  
  53. 			binder_node_lock(ref->node);
  54. 			if (cmd == BC_REQUEST_DEATH_NOTIFICATION) {
  55. 				.......................
  56.  
  57. 			} else { // 走入 BC_CLEAR_DEATH_NOTIFICATION 分支
  58. 				if (ref->death == NULL) {
  59. 					binder_user_error(
  60. "%d:%d BC_CLEAR_DEATH_NOTIFICATION death notification not active\n",
  61. 						proc->pid, thread->pid);
  62. 					binder_node_unlock(ref->node);
  63. 					binder_proc_unlock(proc);
  64. 					break;
  65. 				}
  66. 				death = ref->death;
  67. 				if (death->cookie != cookie) {
  68. 					......
  69. 				}
  70. // 把 binder_ref 的 death 赋值为 null,实现对死亡接收通知的注销操作
  71. 				ref->death = NULL;
  72. 				binder_inner_proc_lock(proc);
  73. 				if (list_empty(&death->work.entry)) {
  74. 					death->work.type = BINDER_WORK_CLEAR_DEATH_NOTIFICATION;
  75. 					if (thread->looper &
  76. 					    (BINDER_LOOPER_STATE_REGISTERED |
  77. 					     BINDER_LOOPER_STATE_ENTERED))
  78. // 当前线程为 binder 线程,则直接添加到当前线程的 todo 队列
  79. 						binder_enqueue_thread_work_ilocked(
  80. 								thread,
  81. 								&death->work);
  82. 					else {
  83. // 否则添加到进程的 todo 队列
  84. 						binder_enqueue_work_ilocked(
  85. 								&death->work,
  86. 								&proc->todo);
  87. 						binder_wakeup_proc_ilocked(
  88. 								proc);
  89. 					}
  90. 				} else {
  91. // 如果&death->work.entry 不为空，说明服务端进程已经死亡了，并且已经添加
  92. // work 到进程或线程的 todo 队列了，直接修改 work type 为
  93. // BINDER_WORK_DEAD_BINDER_AND_CLEAR 既可，不需要执行再次添加 work 
  94. // 到相关 todo 队列的操作了
  95. 					BUG_ON(death->work.type != BINDER_WORK_DEAD_BINDER);
  96. 					death->work.type = BINDER_WORK_DEAD_BINDER_AND_CLEAR;
  97. 				}
  98. 				binder_inner_proc_unlock(proc);
  99. 			}
  100. 			binder_node_unlock(ref->node);
  101. 			binder_proc_unlock(proc);
  102. 		} break;

以上驱动对死亡接收通知的注销操作主要做了两件事情：

一）把 binder 代理对象对应的 binder 引用的 binder_ref 的 death 对象赋值为 null。这样驱动就不会再向其发送死亡通知了

二）注销后还需要把相关的消息反馈到 binder 代理端（通过添加 work 到代理端进程或线程的 todo 队列的方式），代理端需要执行一些操作，比如减少引用等操作

在把 binder_ref_death 的 work 提交到代理端进程或线程的 todo 队列的过程中，会对这个 work 进行判断，如果 work 的 entry 为空，则说明驱动还没有发送死亡通知，直接发送 BINDER_WORK_CLEAR_DEATH_NOTIFICATION 即可，如果 work 的 entry 不为空，则说明驱动已经发送死亡通知了，并且已经把 work 添加到 binder 代理端的进程或线程的 todo 队列中了，这个时候只需要修改 work type 为 BINDER_WORK_DEAD_BINDER_AND_CLEAR 即可，不需要在执行 todo 队列入队操作．正常的注销操作应该是 work 的 entry 为空，并且发送 BINDER_WORK_CLEAR_DEATH_NOTIFICATION。

接下来看代理端的 read 操作

  1. static int binder_thread_read(struct binder_proc *proc,
  2. 			      struct binder_thread *thread,
  3. 			      binder_uintptr_t binder_buffer, size_t size,
  4. 			      binder_size_t *consumed, int non_block)
  5. {
  6. 	void __user *buffer = (void __user *)(uintptr_t)binder_buffer;
  7. 	void __user *ptr = buffer + *consumed;
  8. 	void __user *end = buffer + size;
  9.  
  10. 	int ret = 0;
  11. 	int wait_for_proc_work;
  12.  
  13. 	if (*consumed == 0) {
  14. 		if (put_user(BR_NOOP, (uint32_t __user *)ptr))
  15. 			return -EFAULT;
  16. 		ptr += sizeof(uint32_t);
  17. 	}
  18. ．．．．．．．．．．．．．．．．．．．．．
  19.  
  20.  
  21. 　　　　  case BINDER_WORK_DEAD_BINDER:
  22. 		case BINDER_WORK_DEAD_BINDER_AND_CLEAR:
  23. 		case BINDER_WORK_CLEAR_DEATH_NOTIFICATION: {
  24. 			struct binder_ref_death *death;
  25. 			uint32_t cmd;
  26. 			binder_uintptr_t cookie;
  27. // 根据 work 找到对应的 binder_ref_death
  28. 			death = container_of(w, struct binder_ref_death, work);
  29. 			if (w->type == BINDER_WORK_CLEAR_DEATH_NOTIFICATION)
  30. // 如果是单纯的 clear 操作，则向代理端发送 BR_CLEAR_DEATH_NOTIFICATION_DONE
  31. // 命令，完成引用减少操作即可
  32. 				cmd = BR_CLEAR_DEATH_NOTIFICATION_DONE;
  33. 			else
  34. // 如果不是单纯的 clear,则发送 BR_DEAD_BINDER，代理端执行发送死亡通知
  35. 				cmd = BR_DEAD_BINDER;
  36. // death 中存储的代理端的代理对象地址，赋值给 cookie
  37. 			cookie = death->cookie;
  38.  
  39. 			......
  40. 			if (w->type == BINDER_WORK_CLEAR_DEATH_NOTIFICATION) {
  41. 				binder_inner_proc_unlock(proc);
  42. 				kfree(death);// 在驱动端 free 掉 death
  43. 				binder_stats_deleted(BINDER_STAT_DEATH);
  44. 			} else {
  45. // 添加 work 到 delivered_death 中，在代理端发送死亡通知后，然后向驱动发送
  46. // BC_DEAD_BINDER_DONE 命令，再这个命令中处理
  47. 				binder_enqueue_work_ilocked(
  48. 						w, &proc->delivered_death);/
  49. 				binder_inner_proc_unlock(proc);
  50. 			}
  51. 			if (put_user(cmd, (uint32_t __user *)ptr)) // 写命令到用户空间
  52. 				return -EFAULT;
  53. 			ptr += sizeof(uint32_t);
  54. 			if (put_user(cookie,
  55. 				     (binder_uintptr_t __user *)ptr))
  56. // 写 cookie 到用户空间，这个代表 binder 代理对象的地址
  57. 				return -EFAULT;
  58. 			ptr += sizeof(binder_uintptr_t);
  59. 			binder_stat_br(proc, thread, cmd);
  60. 			if (cmd == BR_DEAD_BINDER)
  61. 				goto done; 
  62.   /* DEAD_BINDER notifications can cause transactions */
  63. 		} break;
  64. ．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．
  65. ｝

从以上代码可以看到先定位到 BINDER_WORK_CLEAR_DEATH_NOTIFICATION 命令，这个命令就是正常的注销操作，驱动端读取这个命令后，先设置 cmd 为BR_CLEAR_DEATH_NOTIFICATION_DONE，然后 free 掉这个 death，做后把命令和参数反馈到用户空间．接下来看用户空间对 BR_CLEAR_DEATH_NOTIFICATION_DONE 的处理过程

IPCThreadState.cpp

  1. status_t IPCThreadState::executeCommand(int32_t cmd)
  2. {
  3.     BBinder* obj;
  4.     RefBase::weakref_type* refs;
  5.     status_t result = NO_ERROR;
  6.  
  7.     switch ((uint32_t)cmd) {
  8.     case BR_ERROR:
  9.         result = mIn.readInt32();
  10.         break;
  11.  
  12.     case BR_OK:
  13.         break;
  14. ．．．．．．．．．．．．．．．．．．．．．．．
  15. 　　case BR_CLEAR_DEATH_NOTIFICATION_DONE:
  16.         {
  17.             BpBinder *proxy = (BpBinder*)mIn.readPointer();
  18.             proxy->getWeakRefs()->decWeak(proxy);
  19.         } break;
  20.  
  21. ．．．．．．．．．．．．．．．
  22.  
  23. ｝

很简单，就是通过读取从内核空间传过来的参数 cookie，获取 binder 代理对象 proxy，并对引用做 decWea 操作。

以上就是死亡通知的注销流程，简单总结就是 binder 代理端的 binder 代理对象发送 BC_CLEAR_DEATH_NOTIFICATION 命令，在驱动端先把 binder_ref 的 death 保存起来，然后把binder_ref 的 death 置为 null，最后把保存起来的这个 death 的 work type 修改为 BINDER_WORK_CLEAR_DEATH_NOTIFICATION，并且把这个 death 的 work 添加到代理端进程或线程的 todo 队列中。

当代理端接收到这个 work 后，会先把命令 cmd 赋值为 BR_CLEAR_DEATH_NOTIFICATION_DONE，然后 free 掉这个 binder_ref_death，最后向 binder 代理端返回，代理端在接收到这个命令后，执行对代理对象的引用做减少操作。

三　死亡通知的触发

当 Binder 服务所在的进程死亡后，会释放掉进程相关的资源，Binder 也是一种资源，也需要释放。

Binder 驱动将设备文件 /dev/binder 的释放操作方法设置为函数 binder_release，也就是释放 binder 驱动设备的时候，会回调到 binder_release 方法，这个是正常死亡的时候，然而如果是非正常死亡呢，即它没有正常关闭设备文件 /dev/binder，那么内核就会负责关闭它，这个时候也会触发函数 binder_release 的调用。因此，Binder 驱动程序只要在函数 binder_release 中释放相关 binder 资源就可以了，在释放 binder 资源的过程中，如果发现有对应的 binder_ref 引用其中的 binder_node，那么查看是否有 death 值，如果有则向其发送死亡通知，下面看详细过程

  1. static const struct file_operations binder_fops = {
  2. 	.owner = THIS_MODULE,
  3. 	.poll = binder_poll,
  4. 	.unlocked_ioctl = binder_ioctl,
  5. 	.compat_ioctl = binder_ioctl,
  6. 	.mmap = binder_mmap,
  7. 	.open = binder_open,
  8. 	.flush = binder_flush,
  9. 	.release = binder_release,
  10. };

接着调用 binder_release

  1. static int binder_release(struct inode *nodp, struct file *filp)
  2. {
  3. 	struct binder_proc *proc = filp->private_data;
  4.  
  5. 	debugfs_remove(proc->debugfs_entry);
  6. 	binder_defer_work(proc, BINDER_DEFERRED_RELEASE);
  7.  
  8. 	return 0;
  9. }

 binder_defer_work

  1. static DECLARE_WORK(binder_deferred_work, binder_deferred_func);
  2.  
  3. static void
  4. binder_defer_work(struct binder_proc *proc, enum binder_deferred_state defer)
  5. {
  6. 	mutex_lock(&binder_deferred_lock);
  7. 	proc->deferred_work |= defer;
  8. 	if (hlist_unhashed(&proc->deferred_work_node)) {
  9. 		hlist_add_head(&proc->deferred_work_node,
  10. 				&binder_deferred_list);
  11. 		schedule_work(&binder_deferred_work);
  12. 	}
  13. 	mutex_unlock(&binder_deferred_lock);
  14. }

主要操作为：把 proc 中的 deferred_work 赋值为 BINDER_DEFERRED_RELEASE，然后检查 proc 的 deferred_work_node 是否已经添加到哈希链表 binder_deferred_list 中，如果没有添加，则做添加操作，然后调用声明的 binder_deferred_func 函数执行 binder_deferred_work 工作队列

  1. static void binder_deferred_func(struct work_struct *work)
  2. {
  3. 	struct binder_proc *proc;
  4. 	int defer;
  5.  
  6. 	do {
  7. 		mutex_lock(&binder_deferred_lock);
  8. 		if (!hlist_empty(&binder_deferred_list)) {
  9. 			proc = hlist_entry(binder_deferred_list.first,
  10. 					struct binder_proc, deferred_work_node);
  11. 			hlist_del_init(&proc->deferred_work_node);
  12. 			defer = proc->deferred_work;
  13. 			proc->deferred_work = 0;
  14. 		} else {
  15. 			proc = NULL;
  16. 			defer = 0;
  17. 		}
  18. 		mutex_unlock(&binder_deferred_lock);
  19.  
  20. 		if (defer & BINDER_DEFERRED_FLUSH)
  21. 			binder_deferred_flush(proc);
  22.  
  23. 		if (defer & BINDER_DEFERRED_RELEASE)
  24. 			binder_deferred_release(proc); /* frees proc */
  25. 	} while (proc);
  26. }

从 binder_deferred_func 函数可以看到，会从 binder_deferred_list 中找到上面添加到头部的 deferred_work_node，然后根据 deferred_work_node 找到对应的 proc，最后调用 binder_deferred_release 方法进行释放资源操作

  1. static void binder_deferred_release(struct binder_proc *proc)
  2. {
  3. 	struct binder_context *context = proc->context;
  4. 	struct rb_node *n;
  5. 	int threads, nodes, incoming_refs, outgoing_refs, active_transactions;
  6.  
  7. 	mutex_lock(&binder_procs_lock);
  8. 	hlist_del(&proc->proc_node); // 把 proc 从进程链表 procs 中删除
  9. 	mutex_unlock(&binder_procs_lock);
  10.  
  11. 	mutex_lock(&context->context_mgr_node_lock);
  12. 	if (context->binder_context_mgr_node &&
  13. 	    context->binder_context_mgr_node->proc == proc) {
  14. 		binder_debug(BINDER_DEBUG_DEAD_BINDER,
  15. 			     "%s: %d context_mgr_node gone\n",
  16. 			     __func__, proc->pid);
  17. // 如果是 servicemanager 进程挂掉，则对相应的 binder_node 置为null
  18. 		context->binder_context_mgr_node = NULL;
  19. 	}
  20. 	mutex_unlock(&context->context_mgr_node_lock);
  21. 	binder_inner_proc_lock(proc);
  22. 	/*
  23. 	 * Make sure proc stays alive after we
  24. 	 * remove all the threads
  25. 	 */
  26. 	proc->tmp_ref++;
  27.  
  28. 	proc->is_dead = true; // 进程标记为 dead
  29. 	threads = 0;
  30. 	active_transactions = 0;
  31. 	while ((n = rb_first(&proc->threads))) {
  32. // 遍历进程的线程树，找到每一个相关线程
  33. 		struct binder_thread *thread;
  34.  
  35. 		thread = rb_entry(n, struct binder_thread, rb_node);
  36. 		binder_inner_proc_unlock(proc);
  37. 		threads++;
  38. // 释放线程
  39. 		active_transactions += binder_thread_release(proc, thread);
  40. 		binder_inner_proc_lock(proc);
  41. 	}
  42.  
  43. 	nodes = 0;
  44. 	incoming_refs = 0;
  45. 	while ((n = rb_first(&proc->nodes))) {
  46. // 遍历进程的节点树，找到每一个相关节点
  47. 		struct binder_node *node;
  48.  
  49. 		node = rb_entry(n, struct binder_node, rb_node);
  50. 		nodes++;
  51. 		/*
  52. 		 * take a temporary ref on the node before
  53. 		 * calling binder_node_release() which will either
  54. 		 * kfree() the node or call binder_put_node()
  55. 		 */
  56. 		binder_inc_node_tmpref_ilocked(node);
  57. 		rb_erase(&node->rb_node, &proc->nodes);
  58. 		binder_inner_proc_unlock(proc);
  59. // 释放节点
  60. 		incoming_refs = binder_node_release(node, incoming_refs);
  61. 		binder_inner_proc_lock(proc);
  62. 	}
  63. 	binder_inner_proc_unlock(proc);
  64.  
  65. 	outgoing_refs = 0;
  66. 	binder_proc_lock(proc);
  67. 	while ((n = rb_first(&proc->refs_by_desc))) {
  68. // 遍历进程的引用树，找到每一个相关引用
  69. 		struct binder_ref *ref;
  70.  
  71. 		ref = rb_entry(n, struct binder_ref, rb_node_desc);
  72. 		outgoing_refs++;
  73. 		binder_cleanup_ref_olocked(ref);
  74. 		binder_proc_unlock(proc);
  75. // 释放引用
  76. 		binder_free_ref(ref);
  77. 		binder_proc_lock(proc);
  78. 	}
  79. 	binder_proc_unlock(proc);
  80.  
  81. // 释放进程的等待队列 todo
  82. 	binder_release_work(proc, &proc->todo);
  83. // 释放进程的 delivered_death
  84. 	binder_release_work(proc, &proc->delivered_death);
  85.  
  86. 	......
  87.  
  88. 	binder_proc_dec_tmpref(proc);
  89. }

此处的参数 proc 就是死亡的服务端进程，因为我们关注的是死亡通知的发送，所以我们重点关注 binder_node_release 函数，如下：

  1. static int binder_node_release(struct binder_node *node, int refs)
  2. {
  3. 	struct binder_ref *ref;
  4. 	int death = 0;
  5. 	struct binder_proc *proc = node->proc;
  6.  
  7. 	binder_release_work(proc, &node->async_todo);
  8.  
  9. 	binder_node_lock(node);
  10. 	binder_inner_proc_lock(proc);
  11. 	binder_dequeue_work_ilocked(&node->work);
  12. 	/*
  13. 	 * The caller must have taken a temporary ref on the node,
  14. 	 */
  15. 	BUG_ON(!node->tmp_refs);
  16. 	if (hlist_empty(&node->refs) && node->tmp_refs == 1) {
  17. 		binder_inner_proc_unlock(proc);
  18. 		binder_node_unlock(node);
  19. 		binder_free_node(node);
  20.  
  21. 		return refs;
  22. 	}
  23.  
  24. 	node->proc = NULL;
  25. 	node->local_strong_refs = 0;
  26. 	node->local_weak_refs = 0;
  27. 	binder_inner_proc_unlock(proc);
  28.  
  29. 	spin_lock(&binder_dead_nodes_lock);
  30. 	hlist_add_head(&node->dead_node, &binder_dead_nodes);
  31. 	spin_unlock(&binder_dead_nodes_lock);
  32.  
  33. 	hlist_for_each_entry(ref, &node->refs, node_entry) {
  34. // 遍历 node 的引用链表 refs
  35. 		refs++;
  36. 		/*
  37. 		 * Need the node lock to synchronize
  38. 		 * with new notification requests and the
  39. 		 * inner lock to synchronize with queued
  40. 		 * death notifications.
  41. 		 */
  42. 		binder_inner_proc_lock(ref->proc);
  43. 		if (!ref->death) {
  44. // 如果对应的 binder_ref 的 death 为空，则跳出本次循环继续遍历
  45. 			binder_inner_proc_unlock(ref->proc);
  46. 			continue;
  47. 		}
  48.  
  49. 		death++;
  50.  
  51. 		BUG_ON(!list_empty(&ref->death->work.entry));
  52. 		ref->death->work.type = BINDER_WORK_DEAD_BINDER;
  53. // death 不为空，则修改 work type，发送死亡通知
  54.  
  55. // 并把 work 添加到代理端进程的 todo 队列中
  56. 		binder_enqueue_work_ilocked(&ref->death->work,
  57. 					    &ref->proc->todo);
  58.  
  59. // 唤醒代理端进程
  60. 		binder_wakeup_proc_ilocked(ref->proc);
  61. 		binder_inner_proc_unlock(ref->proc);
  62. 	}
  63.  
  64. 	binder_debug(BINDER_DEBUG_DEAD_BINDER,
  65. 		     "node %d now dead, refs %d, death %d\n",
  66. 		     node->debug_id, refs, death);
  67. 	binder_node_unlock(node);
  68. 	binder_put_node(node);
  69.  
  70. 	return refs;
  71. }

该方法会遍历依赖该 binder_node 的所有 binder_ref, 并检查对应的 binder_ref 是否注册过死亡通知，如果注册过，这里表现为 binder_ref 的 death 不为空，则向相应的 binder_ref 所在进程的 todo 队列添加 BINDER_WORK_DEAD_BINDER 事务并唤醒代理端进程执行这个事务。

这个就是死亡通知的触发过程。

四　死亡通知的处理

在前面发送死亡通知后，数据来到了 binder 代理端驱动层的 read 线程中

  1. static int binder_thread_read(struct binder_proc *proc,
  2. 			      struct binder_thread *thread,
  3. 			      binder_uintptr_t binder_buffer, size_t size,
  4. 			      binder_size_t *consumed, int non_block)
  5. {
  6. 	void __user *buffer = (void __user *)(uintptr_t)binder_buffer;
  7. 	void __user *ptr = buffer + *consumed;
  8. 	void __user *end = buffer + size;
  9.  
  10. 	int ret = 0;
  11. 	int wait_for_proc_work;
  12.  
  13. 	if (*consumed == 0) {
  14. 		if (put_user(BR_NOOP, (uint32_t __user *)ptr))
  15. 			return -EFAULT;
  16. 		ptr += sizeof(uint32_t);
  17. 	}
  18.     ......
  19. 　　　　 case BINDER_WORK_DEAD_BINDER:
  20. 		case BINDER_WORK_DEAD_BINDER_AND_CLEAR:
  21. 		case BINDER_WORK_CLEAR_DEATH_NOTIFICATION: {
  22. 			struct binder_ref_death *death;
  23. 			uint32_t cmd;
  24. 			binder_uintptr_t cookie;
  25.  
  26. // 根据 work 找到对应的 binder_ref_death
  27. 			death = container_of(w, struct binder_ref_death, work);
  28. 			if (w->type == BINDER_WORK_CLEAR_DEATH_NOTIFICATION)
  29. 				cmd = BR_CLEAR_DEATH_NOTIFICATION_DONE;
  30. 			else
  31. 				cmd = BR_DEAD_BINDER; // 添加死亡命令
  32. 			cookie = death->cookie;
  33.  
  34. 			......
  35. 			if (w->type == BINDER_WORK_CLEAR_DEATH_NOTIFICATION) {
  36. 				binder_inner_proc_unlock(proc);
  37. 				kfree(death);
  38. 				binder_stats_deleted(BINDER_STAT_DEATH);
  39. 			} else {
  40. // 把 work 添加到 proc 中的 delivered_death 中
  41. 				binder_enqueue_work_ilocked(
  42. 						w, &proc->delivered_death);
  43. 				binder_inner_proc_unlock(proc);
  44. 			}
  45. // 命令返回到用户空间
  46. 			if (put_user(cmd, (uint32_t __user *)ptr))
  47. 				return -EFAULT;
  48. 			ptr += sizeof(uint32_t);
  49. // 代理对象的地址返回到用户空间
  50. 			if (put_user(cookie,
  51. 				     (binder_uintptr_t __user *)ptr))
  52. 				return -EFAULT;
  53. 			ptr += sizeof(binder_uintptr_t);
  54. 			binder_stat_br(proc, thread, cmd);
  55. 			if (cmd == BR_DEAD_BINDER)
  56. 				goto done; 
  57. 		} break;
  58.  
  59.  
  60. ｝

数据传递到用户空间处理如下：

  1. status_t IPCThreadState::executeCommand(int32_t cmd)
  2. {
  3.     BBinder* obj;
  4.     RefBase::weakref_type* refs;
  5.     status_t result = NO_ERROR;
  6.  
  7.     switch ((uint32_t)cmd) {
  8.     case BR_ERROR:
  9.         result = mIn.readInt32();
  10.         break;
  11.  
  12.     case BR_OK:
  13.         break;
  14.  
  15.     ......
  16. 　　case BR_DEAD_BINDER:
  17.         {
  18.             BpBinder *proxy = (BpBinder*)mIn.readPointer();
  19.             proxy->sendObituary();
  20.             mOut.writeInt32(BC_DEAD_BINDER_DONE);
  21.             mOut.writePointer((uintptr_t)proxy);
  22.         } break;
  23.  
  24. ｝

从以上代码中可以看到获取 binder 代理对象 proxy 后，然后调用 binder 代理对象的 sendObituary 方法

  1. void BpBinder::sendObituary()
  2. {
  3.     ALOGV("Sending obituary for proxy %p handle %d, mObitsSent=%s\n",
  4.         this, mHandle, mObitsSent ? "true" : "false");
  5.  
  6.     mAlive = 0;
  7.     if (mObitsSent) return; // 驱动已经发送过死亡通知,直接返回
  8.  
  9.     mLock.lock();
  10.     Vector<Obituary>* obits = mObituaries;
  11.     if(obits != NULL) {
  12.         IPCThreadState* self = IPCThreadState::self();
  13.         self->clearDeathNotification(mHandle, this); // 注销死亡通知
  14.         self->flushCommands();
  15.         mObituaries = NULL;
  16.     }
  17.     mObitsSent = 1; // 标记已经发送过死亡通知
  18.     mLock.unlock();
  19.  
  20.     ALOGV("Reporting death of proxy %p for %zu recipients\n",
  21.         this, obits ? obits->size() : 0U);
  22.  
  23.     if (obits != NULL) {
  24.         const size_t N = obits->size();
  25.         for (size_t i=0; i<N; i++) {
  26. // 遍历 mObituaries 中的每个死亡接收通知对象，
  27. // 然后回调该对象的 binderDied 方法
  28.             reportOneDeath(obits->itemAt(i));
  29.         }
  30.  
  31.         delete obits;
  32.     }
  33. }

以上 sendObituary 方法，先检查 mObituaries 是否为空，如果不为空那么注销死亡通知，这个流程在第二部分死亡通知的注销流程一样，然后把 mObitsSent 设置为１，标记驱动已经发送过死亡通知了。最后遍历 mObituaries，对其中的每个对象 Obituary 的 recipient 回调 binderDied 函数，这个函数最终会在代理端实现，作出一些操作，避免发生异常错误

  1. void BpBinder::reportOneDeath(const Obituary& obit)
  2. {
  3.     sp<DeathRecipient> recipient = obit.recipient.promote();
  4.     ALOGV("Reporting death to recipient: %p\n", recipient.get());
  5.     if (recipient == NULL) return;
  6.  
  7.     recipient->binderDied(this);
  8. }

以上就是死亡通知注册，注销，触发和处理的流程

下面讨论下 java 端如何注册使用死亡通知，以及数据是如何传递到 navie 端的。

先看 java 端对应的 Binder 和 BinderProxy 中对死亡通知的注册和注销接口，如下：

  1. public class Binder implements IBinder {
  2.     public void linkToDeath(DeathRecipient recipient, int flags) {
  3.     }
  4.  
  5.     public boolean unlinkToDeath(DeathRecipient recipient, int flags) {
  6.         return true;
  7.     }
  8. }
  9.  
  10. final class BinderProxy implements IBinder {
  11.     public native void linkToDeath(DeathRecipient recipient, int flags)
  12.         throws RemoteException;
  13.     public native boolean unlinkToDeath(DeathRecipient recipient,
  14.         int flags);
  15. }

当作为 Binder 服务端，则相应的两个方法实现为空，没有实现具体功能

当作为 BinderProxy 代理端，则调用 native 方法来实现相应功能，这里真正实现了注册和注销的操作。

原因也很好理解，因为注册死亡通知就是 binder 代理端的事情，和 binder 服务端没有关系。

接着看位于 ActivityManagerService 中的 AppDeathRecipient 类，这个类实现了 IBinder 的 DeathRecipient 接口，实现了其中最重要的 binderDied 方法，这个方法最终会被回调

  1. private final class AppDeathRecipient implements IBinder.DeathRecipient {
  2.         final ProcessRecord mApp;
  3.         final int mPid;
  4.         final IApplicationThread mAppThread;
  5.  
  6.         AppDeathRecipient(ProcessRecord app, int pid,
  7.                 IApplicationThread thread) {
  8.             if (DEBUG_ALL) Slog.v(
  9.                 TAG, "New death recipient " + this
  10.                 + " for thread " + thread.asBinder());
  11.             mApp = app;
  12.             mPid = pid;
  13.             mAppThread = thread;
  14.         }
  15.  
  16.         @Override
  17.         public void binderDied() {
  18.             if (DEBUG_ALL) Slog.v(
  19.                 TAG, "Death received in " + this
  20.                 + " for thread " + mAppThread.asBinder());
  21.             synchronized(ActivityManagerService.this) {
  22.                 appDiedLocked(mApp, mPid, mAppThread, true);
  23.             }
  24.         }
  25.     }

再看 AppDeathRecipient 的注册

  1. 　　　　try {
  2.             AppDeathRecipient adr = new AppDeathRecipient(
  3.                     app, pid, thread);
  4.             thread.asBinder().linkToDeath(adr, 0);
  5.             app.deathRecipient = adr;
  6.         } catch (RemoteException e) {
  7.             app.resetPackageList(mProcessStats);
  8.             startProcessLocked(app, "link fail", processName);
  9.             return false;
  10.         }

可以看到 new 了一个 AppDeathRecipient，然后通过 binder 代理的 linkToDeath 方法实现对 DeathRecipient 的注册。

这个最终会调用到 jni 层

  1. static void android_os_BinderProxy_linkToDeath(JNIEnv* env, jobject obj,
  2.         jobject recipient, jint flags) // throws RemoteException
  3. {
  4.     if (recipient == NULL) {
  5.         jniThrowNullPointerException(env, NULL);
  6.         return;
  7.     }
  8.  
  9.     IBinder* target = (IBinder*)
  10.         env->GetLongField(obj, gBinderProxyOffsets.mObject);
  11.     if (target == NULL) {
  12.         ......
  13.         assert(false);
  14.     }
  15.  
  16.     LOGDEATH("linkToDeath: binder=%p recipient=%p\n", target, recipient);
  17.  
  18.     if (!target->localBinder()) {
  19.         DeathRecipientList* list = (DeathRecipientList*)
  20.                 env->GetLongField(obj, gBinderProxyOffsets.mOrgue);
  21.         sp<JavaDeathRecipient> jdr = 
  22.         new JavaDeathRecipient(env, recipient, list);
  23. // 这个 target 就是 BpBinder 对象
  24.         status_t err = target->linkToDeath(jdr, NULL, flags);
  25.         if (err != NO_ERROR) {
  26.             // Failure adding the death recipient, so clear its reference
  27.             // now.
  28.             jdr->clearReference();
  29.             signalExceptionForError(env,
  30.                  obj, err, true /*canThrowRemoteException*/);
  31.         }
  32.     }
  33. }

以上代码中有个 JavaDeathRecipient 对象被注册到 BpBinder 中，从我们之前了解到的，这个应该是一个 DeathRecipient 对象，下面看定义：

  1. class JavaDeathRecipient : public IBinder::DeathRecipient
  2. {
  3. public:
  4.     JavaDeathRecipient(JNIEnv* env, jobject object,
  5.         const sp<DeathRecipientList>& list)
  6.         : mVM(jnienv_to_javavm(env)), mObject(env->NewGlobalRef(object)),
  7.           mObjectWeak(NULL), mList(list)
  8.     {
  9.         // These objects manage their own lifetimes so are responsible
  10.         // for final bookkeeping.
  11.         // The list holds a strong reference to this object.
  12.         LOGDEATH("Adding JDR %p to DRL %p", this, list.get());
  13.         list->add(this);// 将当前对象 sp 添加到列表 DeathRecipientList
  14.  
  15.         android_atomic_inc(&gNumDeathRefs);
  16.         incRefsCreated(env);
  17.     }
  18.  
  19.    void binderDied(const wp<IBinder>& who)
  20.     {
  21.         LOGDEATH("Receiving binderDied() on JavaDeathRecipient %p\n", this);
  22.         if (mObject != NULL) {
  23.             JNIEnv* env = javavm_to_jnienv(mVM);
  24.  
  25. // 调用 BinderProxy 的 sendDeathNotice 方法
  26.             env->CallStaticVoidMethod(gBinderProxyOffsets.mClass,
  27.                     gBinderProxyOffsets.mSendDeathNotice, mObject);
  28.             if (env->ExceptionCheck()) {
  29.                 jthrowable excep = env->ExceptionOccurred();
  30.                 report_exception(
  31. env, excep,
  32. "*** Uncaught exception returned from death notification!");
  33.             }
  34.  
  35.   // Serialize with our containing DeathRecipientList so that we can't
  36.   // delete the global ref on mObject while the list is being iterated.
  37.             sp<DeathRecipientList> list = mList.promote();
  38.             if (list != NULL) {
  39.                 AutoMutex _l(list->lock());
  40.  
  41.   // Demote from strong ref to weak after binderDied()
  42.   // has been delivered, to allow the DeathRecipient and
  43.   // BinderProxy to be GC'd if no longer needed.
  44.                 mObjectWeak = env->NewWeakGlobalRef(mObject);
  45.                 env->DeleteGlobalRef(mObject);
  46.                 mObject = NULL;
  47.             }
  48.         }
  49.     }
  50. }

再看 DeathRecipientList

  1. class DeathRecipientList : public RefBase {
  2.     List< sp<JavaDeathRecipient> > mList;
  3.     Mutex mLock;
  4.  
  5. public:
  6.     DeathRecipientList();
  7.     ~DeathRecipientList();
  8.  
  9.     void add(const sp<JavaDeathRecipient>& recipient);
  10.     void remove(const sp<JavaDeathRecipient>& recipient);
  11.     sp<JavaDeathRecipient> find(jobject recipient);
  12.  
  13.     Mutex& lock();  
  14. // Use with care; specifically for mutual exclusion during binder death
  15. };

DeathRecipientList 中存储的是 JavaDeathRecipient 对象。

再回到 android_os_BinderProxy_linkToDeath 函数可以看到，每调用一次 linkToDeath 函数，都会生成一个新的 JavaDeathRecipient 对象，并且保存到 DeathRecipientList 列表中，然后调用 BpBinder 代理对象的 linkToDeath 函数注册这个 JavaDeathRecipient，这样当对应服务端进程死亡的情况下，最终会调用到 JavaDeathRecipient 的 bindeDied方法，在这个方法中会回调 BinderProxy 的 sendDeathNotice 方法，如下：

  1. private static final void sendDeathNotice(DeathRecipient recipient) {
  2.         if (false) Log.v("JavaBinder", "sendDeathNotice to " + recipient);
  3.         try {
  4.             recipient.binderDied();
  5.         }
  6.         catch (RuntimeException exc) {
  7.             Log.w("BinderNative", 
  8. "Uncaught exception from death notification", exc);
  9.         }
  10.     }

最终调用到 recipient 的 binderDied 方法，这个 recipient 就是前面的 AppDeathRecipient。

至此 binder 的死亡通知机制全部阐述完毕，各位读者如有不同意见望不吝指出，感谢感谢。

声明：本文内容由网友自发贡献，转载请注明出处：【wpsshop】
推荐阅读
相关标签

Copyright © 2003-2013 www.wpsshop.cn 版权所有，并保留所有权利。

  

闽ICP备14008679号