Java序列化不能也不应充当IPC数据协议底座，仅限同JVM同版本封闭场景；其本质是JVM私有快照机制，缺乏消息边界、校验、版本协商与跨语言兼容性；Android中真正IPC底座是Binder+Parcel，Serializable仅用于低频小数据且经Parcel转换，Parcelable才是Binder优化的原生协议。

Java 序列化在跨进程通信（IPC）中不能也不应充当数据协议底座——尤其在异构环境或现代系统中。它仅能在同 JVM、同版本、同类定义的严格封闭场景下“勉强可用”，但存在本质缺陷，实际工程中已被主流 IPC 机制弃用。

Java 序列化不是为 IPC 设计的协议

它本质是 JVM 内部对象快照机制，不是通信协议：

Java Maven Code Review

审查Java Maven项目（ZIP压缩包或GitLab仓库URL），检查代码规范、命名、模块边界、可维护性问题以及重复代码。

下载

• 输出内容包含类名、字段签名、继承链、对象图引用编号等 JVM 私有元数据；
• 没有消息边界标识、无校验头、无版本协商、不支持流式解析；
• 反序列化依赖目标端完整加载相同 class（含包路径、serialVersionUID、static final 常量值），稍有差异即失败；
• 不提供跨语言、跨平台、跨版本兼容性保证，也无标准化文档或演进规范。

Android 中的 IPC 场景：Serializable 与 Parcelable 的分工很明确

• Serializable：Java 标准接口，写法简单，但性能差、I/O 开销大、GC 压力高；
  • 仅适合低频、小数据、非实时场景，如 Intent 传简单配置对象、本地文件持久化；
  • 在 Binder 通信中会被包装成 Bundle，底层仍经 Parcel 转换，并非直接走序列化字节流。
• Parcelable：Android 原生 IPC 协议底座，专为 Binder 优化：
  • 手动实现 writeToParcel() 和 CREATOR，控制每个字段的序列化顺序与方式；
  • 零反射、内存连续、复用 Parcel 缓冲区，避免临时对象和 GC；
  • 与 Binder 驱动深度协同，支持文件描述符、Binder 引用等 Linux 层语义传递。

真正支撑 IPC 的协议底座是 Binder + Parcel，不是 Java 序列化

• Binder 是 Android 的内核级 IPC 机制，负责进程间内存映射、线程池调度、权限校验；
• Parcel 是 Binder 通信的数据载体格式，类似轻量二进制协议（类似 Protobuf 的 wire format，但无 IDL）；
• Java 层的 Parcelable 接口只是 Parcel 的封装适配层，所有跨进程对象最终都以 Parcel 字节块形式经 Binder 传输；
• AIDL 接口生成的 .java 文件，其参数/返回值自动被转换为 Parcel 操作，全程绕过 ObjectOutputStream。

替代方案：当需要真正可扩展的 IPC 时

• 同一生态内（如 Java/Kotlin 进程间）：用 Parcelable 或 @RemoteCallback（Jetpack Compose 中的跨进程 UI 回调新机制）；
• 需跨语言或长期演进：放弃 Java 序列化，改用契约优先的协议：
  • 定义 .proto → 生成各语言绑定 → gRPC over HTTP/2 或直接 socket；
  • 或用 JSON + RESTful 接口，由 Intent 启动 Service 或通过 ContentProvider 暴露结构化数据；
• 高性能本地 IPC（如渲染进程 ↔ 主进程）：用 MemoryFile、Ashmem 或 SharedMemory 配合自定义二进制协议，完全脱离序列化。

Java 序列化在 IPC 中的角色，本质上是一个“历史包袱”——它曾被误用于早期 RMI 或简单 Intent 传递，但从未胜任协议底座职责。现代 Android 和 Java 生态已用 Parcel、AIDL、gRPC、MessagePack 等更可靠、更可控、更安全的机制取而代之。