一句话总结：
选择最高效的跨进程大数据方案，不应是“方案选秀”，而应是由“数据特性”驱动的架构决策。你的数据源自何方、去向何处，决定了你该用哪种“货车”。
一、核心原则：传“凭证”，不传“实体”
所有高效的大数据跨进程方案，都遵循一个核心原则：Binder 只负责传递轻量级的“访问凭证”（如文件描述符 FD），而真正的数据实体则通过由内核管理的更高性能通道（如文件系统、共享内存）来传输。
我们面临的选择，本质上是选择最适合我们数据场景的“凭证”类型。
二、结构化决策：根据你的数据特性选择最佳路径
让我们通过一个决策树来找到最适合你的方案。
第一站：你的数据源自何方？
A）如果你的数据已经存在于一个磁盘文件中（如图库图片、下载的视频、日志文件）：
最佳方案：
ParcelFileDescriptor指向文件
这是最简单、最直接的场景。你无需做任何额外的数据拷贝，只需为现有文件创建一个 ParcelFileDescriptor 并通过 Binder 发送即可。
// 服务端：为现有文件创建 PFD
val file = File(context.cacheDir, "big_data.dat")
// ... 确保文件已写入 ...
val pfd = ParcelFileDescriptor.open(file, ParcelFileDescriptor.MODE_READ_ONLY)
// 通过 Binder 传递 pfd ...
// 客户端：通过 PFD 获取 InputStream
val receivedPfd: ParcelFileDescriptor? = // ... 从 Binder 接收 ...
receivedPfd?.use {
val inputStream = FileInputStream(it.fileDescriptor)
// ... 读取数据流 ...
}
- 优点： 零内存拷贝，实现简单，资源占用最低。
- 适用场景： 分享任何已存在的本地文件。
B）如果你的数据是在内存中动态生成的（如摄像头预览帧、计算结果、网络请求响应）：
进入第二站决策...
第二站：你需要怎样的性能和访问模式？
A）如果你追求极致的性能和实时性，且可能需要双向读写（如图像处理、实时音视频流）：
最佳方案：现代
SharedMemoryAPI
SharedMemory 是 Android 8.0 (API 26) 引入的官方 API，用于创建可被多进程读写的匿名共享内存。它无需磁盘 I/O，速度极快。
// 服务端：创建并写入 SharedMemory
val shm = SharedMemory.create("MySharedMemory", 1024) // 创建 1KB 共享内存
val byteBuffer = shm.mapReadWrite()
byteBuffer.put(bigData) // 写入数据
SharedMemory.unmap(byteBuffer) // 解除映射
// 传递 SharedMemory 对应的 PFD
val pfd = shm.parcelFileDescriptor
// 通过 Binder 传递 pfd ...
// 客户端：映射并读取 SharedMemory
val receivedPfd: ParcelFileDescriptor? = // ...
val shm = SharedMemory.fromFileDescriptor(receivedPfd)
val byteBuffer = shm.mapReadOnly()
val receivedData = ByteArray(byteBuffer.remaining())
byteBuffer.get(receivedData)
SharedMemory.unmap(byteBuffer)
- 优点： 接近零拷贝的性能，无磁盘 I/O，支持多进程双向读写。
- 适用场景： 高性能计算、实时数据交换（摄像头、传感器）、插件化框架中的大规模数据共享。
B）如果你的兼容性要求极高，或数据量仅略超 Binder 限制（如 2-3MB）：
备用方案：数据分块传输
这是“没有办法的办法”。它将数据拆分为多个小块，通过多次 Binder 调用传输。
- 优点： 纯用户态实现，无需特殊权限，兼容所有 Android 版本。
- 缺点： 多次 IPC 调用带来巨大的额外开销，实现逻辑复杂（需要处理状态、重组、校验），是所有方案中性能最差的。
结论： 优先选择 SharedMemory。仅在无法使用 SharedMemory 且数据量不大的情况下，才考虑分块传输作为最后的兼容性手段。
三、特殊场景的“专用列车”
Socket： 当通信跨越设备边界（网络通信）或需要建立一个长期、可靠的流式通道（如长连接推送、视频直播）时，Socket 是不二之选。ContentProvider： 当你需要向整个 Android 系统暴露结构化的数据（如联系人、媒体库），并利用系统提供的权限模型和 URI 规范时，应使用ContentProvider。它底层很多时候也会利用 PFD 来共享文件。
四、决策流程总结
graph TD
A[开始: 我要跨进程传大数据] --> B{数据在磁盘文件里吗?};
B -- 是 --> C[使用 ParcelFileDescriptor 直接指向文件];
B -- 否, 在内存里 --> D{追求极致性能/实时性?};
D -- 是 --> E[使用现代 SharedMemory API];
D -- 否, 兼容性优先 --> F[考虑数据分块传输 (备用方案)];
subgraph "特殊场景"
G[需要网络/跨设备?] --> H[使用 Socket];
I[需要向系统提供结构化数据?] --> J[使用 ContentProvider];
end
C --> Z[结束];
E --> Z[结束];
F --> Z[结束];
通过这个决策流程，你可以根据数据的本质，选择最精准、最高效的 IPC 方案，而不是在功能相似的 API 之间犹豫不决。
