JNI、Binder、NDK 的关系解析（类比 + 场景化说明）

a55662551

于 2025-03-25 18:43:17 发布

阅读量635

点赞数 23

分类专栏： Android 文章标签： binder JNI Android NDK

本文链接：https://blog.youkuaiyun.com/a5566255/article/details/146509763

版权

Android 专栏收录该内容

1 篇文章

订阅专栏

一、核心概念速览（类比理解）

技术	定义（类比）	核心作用
JNI	Java 与本地代码（C/C++）的 “翻译官”（类似中英翻译员，让不同语言的人对话）	连接 Java 层与 Native 层（C/C++），实现跨语言函数调用
Binder	Android 的 “快递系统”（跨进程通信的专车，支持多进程间数据 / 指令运输）	跨进程通信（IPC），支持 Java 层和 Native 层的进程间交互
NDK	Native 开发的 “工具箱”（包含锤子、螺丝刀等工具，帮你用 C/C++ 盖房子）	提供工具链（编译器、调试器等），支持用 C/C++ 开发 Android Native 模块

二、两两关系拆解

1. JNI ↔ NDK（工具与能力的结合）

NDK 是 JNI 的 “基础设施”：
NDK 提供javah（生成 JNI 头文件）、交叉编译器（如 Clang）、调试工具（GDB）等，让开发者能用 C/C++ 实现 JNI 接口。
类比：NDK 是厨师的厨房（工具齐全），JNI 是菜谱（规定如何用工具做菜）。
JNI 是 NDK 的 “桥梁”：
通过 JNI，NDK 开发的 C/C++ 代码可被 Java 调用（如游戏引擎、音视频处理），反之 Java 也能调用 Native 功能。
场景：用 NDK 写一个 C++ 的加密函数，通过 JNI 供 Java 层调用。

2. Binder ↔ NDK（Native 层的 IPC 实现）

Binder 在 Native 层的 “原生支持”：
Android 框架在 Native 层（C/C++）提供 Binder 库（如libbinder.so），NDK 开发者可直接使用 Binder 实现跨进程通信。
类比：Binder 是公路，NDK 是卡车（用 C/C++ 驾驶卡车在公路上运输货物）。
典型场景：
- 自定义 Native 服务：用 NDK 写一个 C++ 的系统服务（如硬件驱动），通过 Binder 供其他 Native 进程或 Java 层调用。
- 替代 Java Binder：对性能敏感的场景（如游戏），用 Native Binder 减少 Java 层开销。

3. JNI ↔ Binder（跨语言的 IPC 协作）

Java Binder ↔ Native Binder 的 “翻译”：
Java 层的 Binder（如 AIDL 生成的Stub/Proxy）通过 JNI 调用 Native 层的 Binder 实现（如android_os_Binder的 JNI 方法）。
类比：Java Binder 是前台客服（接收请求），JNI 是翻译员，将请求转给 Native Binder（后台处理）。
技术细节：
- Java 层的IBinder对象对应 Native 层的BBinder（服务端）或BpBinder（客户端）。
- 通过 JNI 的GetObjectField等方法，可在 Java 和 Native 层传递 Binder 句柄（mObject字段）。

4. 三者的 “三角关系” 总结

plaintext

Java层 ←JNI→ Native层（NDK开发）
        ↘Binder↗ （跨进程通信）

Java 层：通过 JNI 调用 Native 代码，或通过 Java Binder（AIDL）跨进程通信。
Native 层（NDK）：通过 JNI 响应 Java 调用，或直接使用 Native Binder 实现跨进程通信。
Binder：贯穿 Java 和 Native 层，是 Android 系统级 IPC 的 “主干道”。

三、实战场景示例

场景 1：系统服务的跨层实现（如 MediaPlayer）

Java 层：调用MediaPlayer.create()（Java Binder 接口）。
JNI 桥梁：Java Binder 通过 JNI 进入 Native 层（android_media_MediaPlayer.cpp）。
Native Binder：Native 层通过 Binder 与 MediaServer 通信（C++ 实现的 Binder 服务）。
NDK 角色：MediaServer 是 NDK 开发的 Native 进程，使用 Binder 库（libbinder.so）提供服务。

场景 2：自定义高性能 IPC（游戏引擎与渲染进程）

需求：游戏逻辑（C++，NDK）与渲染（另一个 C++ 进程，NDK）高速通信。
方案：
1. 用 NDK 实现 Native Binder 服务（类似 Java 的 AIDL，但全 C++）。
2. 通过 JNI 在 Java 层暴露简化接口（可选）。
3. Binder 驱动负责跨进程数据传输（一次内存拷贝，高性能）。

四、对比与总结

维度	JNI	Binder	NDK
作用	跨语言（Java ↔ C/C++）	跨进程（IPC）	支持 Native 开发（C/C++）
层级	语言边界	进程边界	开发工具链
协作场景	Java 调用 Native Binder 实现	Native 进程间通信（NDK 开发）	用 C/C++ 写 Binder 服务（JNI 可选）
典型案例	系统服务（如 ActivityManager）	系统服务、自定义 IPC	游戏引擎、硬件驱动

一句话总结：

JNI 是 Java 与 Native 的 “翻译官”，Binder 是跨进程通信的 “专车”，NDK 是 Native 开发的 “工具箱”。三者协同：NDK 开发 Native 模块（含 Binder 服务），通过 JNI 与 Java 层交互，最终由 Binder 实现跨进程（甚至跨语言）的高效通信。

五、扩展知识：Android 架构中的位置

plaintext

Framework层（Java）
  ↓ JNI（桥梁）
Native层（C/C++，NDK开发）
  ↓ Binder驱动（内核）
用户空间进程（Java/Native） ↔ 内核空间（Binder驱动）

Binder 的跨层支持：无论是 Java 还是 Native 层，Binder 的核心逻辑（如内存映射、线程池）均由内核驱动实现，上层通过 JNI 或 Native API 调用。
NDK 的灵活性：可完全脱离 Java（纯 Native 进程），仅用 Binder 和 NDK 实现 IPC（如部分系统服务）。

常见问题 Q&A

Q：NDK 开发必须用 Binder 吗？
A：不一定。NDK 可用于纯本地功能（如算法优化），Binder 是可选的 IPC 方案（替代 Socket 等）。
Q：JNI 能直接操作 Binder 吗？
A：是的。Java 层的IBinder对象通过 JNI 可获取 Native 的BinderProxy指针，进而调用 Native Binder 接口（如transact）。
Q：为什么 Binder 在 NDK 中性能更高？
A：减少 Java 层的序列化 / 反序列化开销，直接操作 C++ 对象（如Parcel在 Native 层是结构体），适合高频 IPC 场景。

总结图示

plaintext

Java应用 ──JNI──▶ Native模块（NDK）──Binder──▶ 另一个进程（Java/Native）
          ↳ AIDL（Java Binder） ↘               ↗（Native Binder）
                     ↳ Binder驱动（内核）