说到Binder，一次方法调用，究竟怎样跨进程执行？

上一篇 JNI 文章把调用链停在了这里：

BinderProxy.transact
↓transactNative
↓JNIandroid_os_BinderProxy_transact
↓BpBinder::transact
↓IPCThreadState::transact
↓ioctl
↓Binder Driver

JNI 已经解释了 Java 怎样进入当前进程的 C++。却没有回答一个更关键的问题：

把这次调用拆成两个执行片段，模型会清楚很多：

客户端调用线程不会“穿越”到服务端。​客户端业务 Proxy 把方法调用编码成事务；Binder Driver 通过 reply 事务返回，客户端原线程才继续执行。

使用者痛点这方面，你以为是“线程穿越”。是“事务分片 + 回复拼接”

如果你只关注 Java 层，很容易误以为同一线程在不同进程中继续跑。但真正变化的是执行权从客户端线程的一段调用栈 → 服务端 Binder 线程另一段调用栈 → reply 再恢复客户端原线程。

一笔 add，两段执行

最小同步接口

先用最小 add 建立同步调用模型：

interface ICalculator {
int add;}

完整协议见 BinderLab AIDL。

实机证据使用同步方法 addWithRequestId

客户端看到的仅是一行代码：

int result = calculator.add;

但实际涉及两个进程和两条 Linux 线程：

一张图看清跨进程边界

以下文字描述对应流程：

客户端业务代码
↓ AIDL 业务 Proxy.add
↓ BinderProxy / libbinder
↓ Binder Driver
↓ 服务端 Binder 线程 + AIDL Stub
↓ 服务端 add
↓ reply 原路返回

业务 Proxy 把方法变成事务

AIDL 自动生成的 Proxy 会把本地方法翻译成 Binder 协议：

add → descriptor + transaction code + 参数 Parcel →
mRemote.transact → reply Parcel

业务 Proxy 理解业务语义；Binder Driver 专门处理事务与对象引用，不懂 add 的业务意义。

"业务 Proxy 与 BinderProxy 各管一层"

'mRemote' 是 IBinder。在跨进程时通常是 BinderProxy，它负责通用传输入口 transact。

// ICalculator.Proxy
// mRemote : IBinder
// binders : type-safe business methods )
//
// ↓
// // In cross-process scenario:
// mRemote is a proxy to remote binder

• AIDL Stub 接收远端请求并解析参数/结果。
• BinderDriver 路由请求到目标节点，并将数据交给目标绑定器。
• BinderProxy 在本地包装请求/回复逻辑。其实，
• BpBinder 与 IPCThreadState 把请求转化为程序级 ioctl 调用。
• BinderDriver 在内核层做路由、转换与排队，接下来唤醒目标 binder 线程。
.
• Binder thread 在服务端读取 BR_TRANSACTION 并通过 JNI 回调 Java Stub 的 onTransact. Stub 解码后真正执领域务函数，接下来写回结果通过 娱乐_REPLY 返回给 client.
.
• @see “沿调用栈下到驱动”进一步拆解每一步细节.
.
• ⚠️ 使用者误区：认为「同一 thread」被迁移到了另一侧。其实只是在不同阶段等待/响应.
.

"沿调用栈下到驱动"

Caution:  This snippet is purely about entering native land—no cross‑process transfer yet..

// Android_os_BinderProxy_transact
Parcel* data = parcelForJavaObject;Parcel* reply = parcelForJavaObject;IBinder* target = getBPNativeData->mObject.get;status_t err = target->transact;

• Simplified mapping:
  • The Java Parcel becomes a native C++ pointer.
  • The Java BinderProxy becomes an IBinder/BpBinder object.
  • The arguments become C++ transact parameters.
  • No cross‑process transfer happens here—just local native function call.
  . } Tip: You can set breakpoints at this line to see that execution stays in current process until `IPCThreadState::transact` kicks in..

  ---

  Error model: "Client thread magically turns into server thread after ioctl". This is false – see next section for correct reasoning. • Misconception that ThreadLocal state carries over across processes. • Incorrect assumption that locks are shared 娱乐ween client and server. • Wrong belief that ANR detection can ignore server side waits.
  .

  `IPCThreadState`组织并提交事务"" />

  • `IPCThreadState::self->transact` writes 娱乐_TRANSACTION + payload into per-thread buffer via `writeTransactionData`;
  .
  • `talkWithDriver` n triggers `BINDER_WRITE_READ` ioctl` to hand off payload to kernel driver;
  .
  • This stage remains within same process’s user space – no or process touched yet.
  .
  N.B.: This step does NOT switch threads/processes yet – it's still client’s original thread doing write operation inside its own process memory space..
  .

   
  
  
  - **解析目标**：根据持有的远方引用定位目标 binder node 和对应 pid/handle。
  
  
  .
  
  - **准备目标事务**：包装普通值、binder 引用、文件描述符等特殊对象，并生成适合内核读取的数据块。
  
  
  .
  
  - **排队唤醒**：把消息放入目标 binder 节点工作队列，并在必要时 wakeup 相应 binder 内核 thread。该内核 thread 随即读取 BR_TRANSACTION 并交给相应服务侧 java 层。
  
  
  .
  
  

  至于错误模型，

  客户端线程经过 Binder Driver 后被切换到服务侧继续跑 add。不过，

  三大误判

  错误假设	真相
  客户端 ThreadLocal 连续	不是同一上下文——服务器 side 的 ThreadLocal 属于服务器 binder thread
  同一锁共享	锁属于各自侧独立实例
  ANR 问题只关乎客户端	若服务器还在等待 IO 或 Handler。则可能导致整个链路挂起

  正确理解

  ① 客户端发送 娱乐_TRANSACTION 并阻塞
② 服务侧 binder thread 执行
③ 回复 娱乐_REPLY 后才恢复原来客户端堆栈。

  排障时必须同时检查

  text 谁在等待 reply？<-- IPCThreadState.waitForResponse 谁在服务侧执行业务？ <-- service's binder thread loop 服务是否又再发往别处？

  ---

  整条呼叫链压缩成八步

  1. Client-side – BinderProxy → BpBinder via JNI
  2. IPCThreadState 打包 娱乐_TRANSACTION 并 ioctl 提交给内核驱动
  3. Kernel driver 根据引用定位目标节点与 PID，把缓冲区排队并唤醒相应 binder 内核 thread
  4. Server-side – binder 内核 thread 收到 BR_TRANSACTION。调用 IPCThreadState::executeCommand 将数据映射为 Parcel \
  5. JavaBBinder → execTransactInternal → JNI 回调 AIDL Stub.onTransact \
  6. Stub.onTransact 解码参数并执领域务函数 add \
  7. 同步写回 reply,内核发出 娱乐_REPLY \
  8. Client-side 原始堆栈 收到回复后返回结果。

  ---