再看Binder。客户端拿到的 BinderProxy，到底指向远端什么对象？

前两篇已经完成：

第一篇：一次调用怎样跨进程并返回。说到第二篇，方法、参数和返回值怎样变成 AIDL 协议。

现在剩下整个 Binder 对象模型最关键的问题：

沿着代理逐层向下看。得到的不是远端地址，而是一组映射：

客户端持有的不是服务端对象地址，而是一条分层远端引用链。Java这方面，业务 Proxy → BinderProxyNative：BinderProxy → BpBinder
说到Kernel，当前进程的 binder_ref → 服务端 binder_node
说到服务端。事务到达拥有进程后通过 ptr/cookie 恢复 BBinder / JavaBBinder → Java Stub

BinderProxy 只是这条链在客户端 Java 层的入口。真正让“远端对象引用”成立的是：

• 使用者态代理
• 进程内 handle
• 驱动层的 binder_ref/binder_node
• 服务端侧的 BBinder/JavaBBinder

远端引用为什么不能是一段地址？老实说，

地址只在所属进程里有意义

使用者痛点：开发者常误以为获取到的句柄就是服务器对象的内存指针。导致调试时盲目比较 “0x7a12340000”。这个值在不同进程中毫无关联。

假设服务端创建了一个已经实现全部 AIDL 方法的 Stub：

ICalculator.Stub calculatorBinder = ...;

这个 Java 对象、对应的 native JavaBBinder还有它们使用的内存地址都属于服务端进程地址空间。

即使客户端得到一个数值相同的地址 0x7a12340000它在客户端也可能：

• 没有任何映射；
• 映射到完全无关的数据；
• 在下一次运行中变化；
• 不具备访问权限。话说回来，

Binder 不能把普通对象指针直接交给客户端。它必须建立一种“可跨进程引用、但不暴露远端内存”的对象模型。

三层对象映射概览

使用者痛点：面对多层结构时经常不知道每一层到底保存了什么信息，导致定位问题时“找不到根源”。下面用表格把各层职责梳理清楚。

对象	所在位置	代表什么
I计算器.Proxy	客户端 Java 进程 业务代码层面	业务接口的强类型代理
BinderProxy	持有进程 Java 层，包装 native IBinder
BpBinder	持有进程 Native 层，用 handle 标识远端 node
binder_ref	持有进程 Kernel 中，用 desc 索引本地表
binder_node	拥有进程 Kernel 中。对应本地 BBinder/JavaBBinder 实体
Bb/JavaBBinder	拥有进程使用者态，本地实现 AIDL Stub
I计算器.Stub	拥有进程 Java 层，接收事务并分发业务方法

从 BinderProxy 追踪到 handle 的方法示例

ICalculator.Proxy ↓ mRemote.transact
BinderProxy
↓ native IBinder
↓ BpBinder::transact
↓ binderHandle
↓ IPCThreadState::transact
↓ kernel 通过 handle 找到 binder_ref → binder_node
↓ 服务端 BBinder / JavaBBinder 恢复并执行 onTransact

使用者态代理与驱动引用怎样接起来？

BinderProxy 在 native 层持有 IDbinder>

The method `javaObjectForIBinder`** distinguishes two cases:

• If native IBinder is a local JavaBBinder>。it returns original Java object.
• If it is remote,it creates or reuses a BINDER_PROXY_TYPE_JA_BINDER_PROXY_OBJECTS`.
\end{itemize}

The core native structure looks like:

struct BinderProxyNativeData {
sp mObject;// 保存 remote IBinder
};BinderProxyNativeData* nativeData = new BinderProxyNativeData;nativeData->mObject = val;

The remote IBind​er is usually a BpBinder` instance. Its transact eventually extracts process‑local handle and hands it to `IPCThreadState::transact`.

BB i nder / B pBi nder : 本 地 端 点 与 远 程 代 理

记住两个方向性概念：

• BB i nder : 本 进 程 持 有 的 本 地 Binder 实体。
• BP i nder : 本 进 程 持 有 的 对 远 程 服务 的 代 理。

同一进程可以同时拥有本地 BB i nder 和远 程 B P i n der，两者之间没有固定“服务器/客户”角色划分——角色取决于当前事务是发起方还是被调用方。话说回来，

b i n d e r _n o d e : 属 于 服务 器 侧 的 内 核 表 示

驱动中的 `binder_node` 保存了本地 Binder 实体的信息。包括：

• node->proc : 拥有该 node 的 binder_proc。
• node->ptr / node->cookie : 用于在事务到达时恢复本地 BB i nder / JavaBBind er。
• node->refs : 哪些外部进程通过 binder_ref 持有对它的引用。

`binder_node` 并不直接对应任何 Java 对象。也不理解 AIDL 接口，它仅仅是驱动用于路由、引用计数和生命周期管理的抽象节点。老实说，

b i n d e r _r e f : 属 于 引 用 持 有 方 的 表 示

每个 `binder_ref` 包含三类信息：

• ref->proc : 持有该引用的客户端进程。
• ref->node : 引用指向哪个服务端 `binder_node`。
• ref->data.desc : 客户端看到的 handle。

源码注释把它描述为：“从 procA 指向 procB 中目标 node 的引用结构”。关系可以简化为：

客户端 binderproc
└─ binderref
└─ target bindernode
└─ 服务端 binderproc
.
.
.
.
.
.

---