📚 课程目录第3章 Android IPC原理

Android IPC 原理：四种方案深度对比

做 Android 开发这么多年，IPC（跨进程通信）是绕不开的坎。你想想看，一个应用里多个进程互相传数据，总得有个靠谱的通道。Android 提供了好几种方案——Socket、ContentProvider、BroadcastReceiver 和 Binder。今天我就跟你掰扯掰扯，它们各自是什么、坑在哪儿、为什么最后大家都选了 Binder。

Socket —— 传统网络 IPC

Socket 是 Linux 系统最底层的 IPC 方式。说白了，就是两个进程用 TCP 或 UDP 连接，像网络通信一样收发数据。我刚开始做 Android 时，有个项目需要跨进程传大文件，就想过用 Socket。

优点： 跨平台、稳定、能传大文件。适合与服务端通信。

缺点： 你得自己管理连接、处理粘包、序列化数据。每次通信都要新建线程，资源开销大。在 Android 上，进程间频繁小数据交互用 Socket 简直是杀鸡用牛刀——太笨重。

⚠ 我曾经踩过的坑： 用 Socket 做本地 IPC，结果每次连接都会触发系统的 netd 服务，多进程一启动，电量和流量双双飙升。后来全改 Binder 了。

ContentProvider —— 数据共享 IPC

ContentProvider 设计初衷是给不同 App 共享结构化数据的。比如通讯录、媒体库，都通过它暴露给外部。它底层其实还是 Binder，但封装了 CURD 接口。

优点： 天然支持跨进程数据共享，有权限控制，适合给第三方 App 用。你想想看，微信要读你的相册，就是通过 MediaStore 这个 ContentProvider。

缺点： 只能操作数据库或文件类数据，不适合实时性要求高的命令交互。而且调用过程会走 Binder 线程池，大量并发时容易阻塞。

💡 我的建议： 如果只是单纯要跨进程共享数据库，用 ContentProvider 很合适。但如果你需要执行一段逻辑、传一个对象，就别用它了——它太“重”了。

BroadcastReceiver —— 事件广播 IPC

BroadcastReceiver 是 Android 特有的组件间通信方式。它基于 Intent，可以跨进程发送广播。我记得在早期的 Android 版本里，很多人用它来做进程间的“心跳”通信。

优点： 轻量、一对多、解耦。发送方不需要知道接收方是谁。

缺点： 不保证送达，有序广播慢，无序广播乱。而且广播是异步的，不能同步返回结果。你发出一个广播，想要个回复？没门。另外，系统广播容易被其他 App 拦截或伪造，安全性堪忧。

关键点： BroadcastReceiver 只适合做事件通知，不适合做双向数据传输或方法调用。我后来在一个支付项目中用广播传支付结果，结果被恶意 App 拦截，差点出事故——从此再也不敢在关键流程里用广播代替 Binder。

Binder —— Android 的核心 IPC

Binder 是 Android 自己设计的 IPC 机制，也是 Activity、Service、ContentProvider 的底层通信基础。它基于 C/S 架构，客户端通过代理对象调用服务端的方法，流程像本地调用一样。

对比维度	Socket	ContentProvider	BroadcastReceiver	Binder
性能	低（多次拷贝）	中（底层 Binder）	低（序列化 Intent）	高（一次拷贝）
安全性	弱（无权限校验）	中（有 URI 权限）	弱（可被拦截）	高（UID/PID 检查）
易用性	差（需自己编解码）	中（限数据库）	好（但单向）	好（AIDL 生成代码）
适用场景	大文件/跨网络	数据共享	事件通知	方法调用/复杂交互

为什么 Android 选择了 Binder？

你可能想问：既然有 Socket、ContentProvider、广播，为什么 Android 还要自己搞一套 Binder？原因其实很现实——

性能： Binder 把数据从进程 A 拷贝到内核，再直接映射到进程 B 的地址空间，只拷贝一次。而 Socket 至少需要两次拷贝（用户态→内核态→用户态）。你在做高性能 IPC 时，这个差距很大。
安全： Binder 在驱动层就做了 UID/PID 校验，服务端可以精确知道调用方是谁。ContentProvider 和广播都做不到这一点。我记得有个项目用 ContentProvider 做内部 IPC，结果另一个 App 直接通过包名查到了我们的 Provider，差点数据泄露。
易用性： 你写一个 AIDL 接口，编译后自动生成代理和存根代码，同步调用、异步调用都由框架处理。相比 Socket 那些粘包处理、序列化协议，Binder 简单太多了。
稳定性： Binder 驱动是内核的一部分，不会因为 App 崩溃而丢失连接。而 Socket 连接可能被系统回收，广播可能被排队丢弃。

总结一句话： Android 系统里大量服务——ActivityManagerService、PackageManagerService、WindowManagerService 全都是用 Binder 暴露给上层调用的。你引以为傲的 startActivity() 底层就是一次 Binder 调用。它已经是 Android 的骨骼，你没法绕过。

一张图看懂四种 IPC 的差异

下面这张图列出了 Socket、ContentProvider、BroadcastReceiver 和 Binder 在性能、安全、易用性三个核心维度的对比。Binder 在三个维度上都处于优势位置，这也是它成为 Android IPC 首选的根本原因。

你看这张图，Binder 在三个关键维度上都是绿色（优秀），其他方案各有短板。Android 系统选择 Binder 不是偶然的——它兼顾了性能、安全和开发效率。我在后面几章会深入讲 Binder 的驱动层原理，以及如何用 Mock 技术来测试 Binder 调用。今天先把对比搞明白，后面你才能理解为什么 Compose 测试里 Mock Binder 如此重要。