Binder 是如何贯穿 ART / Native / Kernel 的？

在理解了 Android Native 层如何运行 ART 与 Native Libraries 之后，接下来一定会遇到一个绕不开的问题：

Binder 到底是怎么把 ART、Native 和 Linux Kernel 串成一个整体的？

很多资料只会告诉你一句话：

Binder 是 Android 的 IPC 机制

但真正的系统级理解，应该回答的是：

• Binder 在 ART / Native / Kernel 各自扮演什么角色？
• Java Binder 和 Native Binder 是不是两套？
• 一次 Binder 调用，真实的执行链路是什么？

这篇文章，我们就从运行机制出发，把 Binder 彻底讲透。

一、先给结论（直接定锚）

Binder 不是某一层的组件，而是一套贯穿用户态与内核态的 IPC 机制体系：

• ART 层：Java Binder（Framework / App 使用）

• Native 层：C++ Binder（libbinder）

• Kernel 层：Binder Driver（真正的 IPC 实现）

👉 三层协作，缺一不可。

二、Binder 在 Android 架构中的位置

基于我们前面采用的系统分层模型：

Application
Application Framework
Native Layer
 ├─ Android Runtime（ART）
 └─ Native Libraries（libbinder 等）
HAL
Linux Kernel（Binder Driver）

可以看到：

• Binder 横向贯穿多层
• 唯一运行在内核态的是 Binder Driver
• ART 和 Native 层只是 Binder 的 使用者和封装者

三、Kernel 层：Binder Driver（真正的核心）

1. Binder Driver 是什么？

Binder Driver 是一个 Linux 内核驱动，主要职责只有三件事：

1. 跨进程数据传输
2. 线程唤醒与调度
3. 对象引用与生命周期管理

📌 它并不理解 Java、也不理解 C++，只做 IPC。

2. Binder Driver 的工作方式（简化）

Client Process
   ↓ ioctl
Binder Driver（Kernel）
   ↓
Server Process

• 通过 ioctl 与用户态通信
• 数据在内核中完成拷贝或映射
• 唤醒目标进程的 Binder 线程

👉 所有 Binder 通信，最终都必须经过 Binder Driver。

四、Native 层：C++ Binder（libbinder）

1. libbinder 的角色

Native 层通过 libbinder 对 Binder Driver 做了一层 面向对象封装：

• IBinder
• BpBinder（Proxy）
• BBinder（Stub）
• Parcel

📌 libbinder 是 Native 世界中 Binder 的"门面"。

2. Native Binder 的典型调用链

Client (Native)
   ↓
BpBinder.transact()
   ↓
libbinder
   ↓ ioctl
Binder Driver
   ↓
BBinder.onTransact()

典型使用场景：

• SurfaceFlinger
• CameraServer
• AudioServer
• HAL Service

📌 这些调用完全不经过 ART。

五、ART 层：Java Binder（Framework / App 使用）

1. Java Binder 从哪来？

Java Binder 并不是"新实现的一套 Binder"，而是：

Java 层对 Native Binder 的封装

关键组件包括：

• android.os.Binder
• android.os.IBinder
• Parcel
• BinderProxy

2. Java Binder 的真实执行路径

Framework / App (Java)
   ↓
android.os.Binder
   ↓ JNI
libbinder（Native）
   ↓ ioctl
Binder Driver（Kernel）
   ↓
Target Process

📌 Java Binder 最终仍然会落到 libbinder + Binder Driver。

六、一次完整的 Binder 调用，全链路长什么样？

以 Framework 调用 Native Service 为例：

Framework (Java)
   ↓ Java Binder
ART Runtime
   ↓ JNI
libbinder (Native)
   ↓ ioctl
Binder Driver (Kernel)
   ↓
Native Service (C++)
   ↓
Native Libraries / HAL

关键点总结：

• ART 不参与 IPC 本身
• ART 只负责 Java → Native 的桥接
• 真正的 IPC 在 Native + Kernel 完成

七、为什么 Binder 要这样分三层？

1️⃣ 内核只做"最小职责"

• 不关心语言
• 不关心对象模型
• 只负责 IPC

👉 保持 Kernel 简洁、稳定、安全

---

2️⃣ Native 层负责"通用能力封装"

• 面向对象
• 高性能
• 供 ART 和 Native Service 共用

---

3️⃣ ART 层只做"语言适配"

• Java API 友好
• 生命周期受控
• 不引入性能敏感逻辑

👉 这是 Android 可维护性的关键设计。

八、一个常见误解（一定要避开）

❌ 错误理解：

Binder 是 ART 的一部分

✔ 正确认知：

Binder 的核心在 Linux Kernel ，

ART 只是 Binder 的一个使用者。

九、一句话总结（系统工程级）

Binder 是一套以内核 Binder Driver 为核心，通过 Native libbinder 向上抽象，并由 ART 提供 Java 封装的跨进程通信机制，贯穿了 Android 的 ART、Native 与 Kernel 三个世界。

写在最后

当你真正理解 Binder 时，你会发现：

• Android 的 IPC 并不"魔法"
• Binder 只是一个 设计非常克制的内核机制
• 复杂性被分摊到了合适的层级

而这，正是 Android 能支撑庞大系统服务的根本原因。