ICalculator calculator = ...;

杀掉远端服务后这个 Java 变量不会自动变成 nullcalculator.getClass 仍然是同一个 Proxy；但下一笔真实事务可能抛出 DeadObjectException。于是“我还持有对象”和“对象仍可远程调用”第一次明确分裂。

再加上 isBinderAlivelinkToDeath 与 binderDied表面上似乎有三种“是否存活”的答案。它们分别能证明什么，远端死亡时内核又不可能直接调用 Java callback，那条通知怎样跨过 Driver、libbinder 和 JNI？

这篇文章沿四个追问推进：

为什么本地 Proxy 生命周期与远端 node / proc 生命周期彼此独立？linkToDeath 注册的监视关系最终保存在哪里？远端死亡怎样变成 BR_DEAD_BINDER，再扇出到 Java recipients？收到 binderDied 后为什么仍要用 generation 管理重新发现与状态恢复？按理说，

这里要解释的是“旧远端失效如何被观察和治理”。不是把 DeathRecipient 包装成保活或自动重连机制。

Proxy 还在为什么下一笔 transact 仍会失败？

本地代理、驱动引用与远端 node 为什么有三套生命周期？

生命周期	由谁决定	“仍存在”能证明什么
Java 业务 Proxy / BinderProxy 客户端	Java 引用和 GC 客户端仍持有本地代理对象	BpBinder / binder_ref 客户端仍有一条远端引用记录
BpBinder / native 引用与驱动状态	native 引用与驱动状态 客户端仍有一条远端引用记录	远端 binder_node / proc 服务端进程生命周期 目标端点仍有宿主并可被路由
远端 binder_node / proc 服务端进程	程序调度/进程生存状态

使用者痛点：

• 持有的 BinderProxy 并没有变成 null
• 下一次 .transact 却抛出 DeadObjectException
• 误以为 “只要 Proxy 不为空，服务就一定活着” 的错误认知

与 binderDied> 之间隔着哪些层？

阅读链路时可以拆成两条链：

注册链：Java → JNI → BpBinder
通知链的观点是，Driver → BR_DEAD_BINDER → BpBinder → Java callback

注意：

• The driver never calls Java directly;it only pushes a command to client’s Binder thread.
• User‑space libbinder and JNI are responsible for turning that command into a Java callback.

返回 true，为什么下一行仍可能失败？

if ) {
// 这里远端仍可能立刻死亡
binder.transact;}

The official documentation of explicitly states:

A concise comparison:

• isBinderAlive: best‑effort snapshot at call time.
• linkToDeath: asynchronous receipt of future death events.
• .transact: concrete evidence that current call failed.

The three mechanisms cannot replace each or.

注册 DeathRecipient 时远端已经死亡怎么办？

private final IBinder.DeathRecipient mDeathRecipient = -> {
// 这里只做轻量失效和转交，不做长耗时恢复
mHandler.post;}，void watch throws RemoteException {
IBinder binder = calculator.asBinder;binder.linkToDeath;}

The registration itself suffers from a race condition: after obtaining proxy but before actually registering,remote side may already be dead. According to official API,in this case can throw a . Therefore。following three signals should be treated as a single “old generation invalidated” state machine rar than three independent recovery paths:

• registration failure; 说起来，
• .transact throwing DeadObjectException;
• A previously registered DeathRecipient receiving binderDied .

 boolean watchOrInvalidate { IBinder binder = calculator . asBinder;IBinder . DeathRecipient recipient = newDeathRecipient;retainRecipientForGeneration;try { binder . linkToDeath;return true，} catch { invalidateGenerationAndScheduleReconnect;return false;} }

The helper method must be idempotent:

 void invalidateGenerationAndScheduleReconnect { // Remove candidate from local generation container // Perform best‑effort unlinkToDeath ignoring any exception // Schedule a single reconnection task }

If you only schedule a reconnection while leaving failed candidate in your container,you risk “old callbacks” interfering with newly published generations.

驱动知道远端死了怎样把消息送到 Java？

Java recipient 怎样先桥接到 Native BpBinder？

 linkToDeathNative;

The JNI entry point ) creates a native JavaDeathRecipient,n forwards request to native BpBinder instance:

 target -> linkToDeath;

多个 recipient 为什么可以共享同一远端死亡订阅？

The native class BpBinder::linkToDeath maintains an internal obituary list:

 B p B i n d e r └─ 多个 DeathRecipient / cookie / flags 

When list is created for first time,it asks driver for a death notification:

 IPCThreadState * self = IPCThreadState :: self;self -> requestDeathNotification,this );self -> flushCommands;

Thus all Java/Native recipients share one driver‑side monitor;when kernel notifies that monitor,B p B i n d e r fans out to every registered listener.

驱动用什么对象把死亡订阅绑定到客户端引用？

The kernel data structures look like:

 struct binder_ref_death * death;

This field lives inside a binder_ref,which in turn belongs to a specific client process . When remote process exits and its node is destroyed。driver walks all references pointing to that node and enqueues a death work item for each interested client.

The flow can be visualized as:

• BR_DEAD_BINDER

  A client process must have a Binder thread or some event loop that continues reading commands from driver. When it reads a death work item,it receives it as a  .

  The handling in Android’s IPC layer looks like: cpp case BR_DEAD_BINDER: { BpBinder* proxy = mIn.readPointer;proxy->sendObituary;mOut.writeInt32;mOut.writePointerproxy);break，} So  first lands on a **client‑side Binder thread**,not on any business UI thread.

  BpBinder::sendObituary

  This method extracts its local obituary list and invokes each native .

  The Java side path looks like:
  • B p B i n d e r :: sendObituary → native  DeathRecipient ::binderDied → JavaDea thRec ipient → user‑defined IBinde r.DeathRec ipient .b inderD ied .
  The full notification chain is refore: text Remote proc/node dies ↓ driver queues death work for each client’s binder_ref ↓ client Binder thread reads BR_DEAD_BINDER ↓ IPCThreadState::executeCommand ↓ BpBinder::sendObituary ↓ JavaDeathRecipient ↓ DeathRecipient.binderDied

  binderDied 后为什么还不能宣布恢复成功？​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​

---