一句话总结：
Bundle传递对象需要序列化，是因为Android要将你的内存对象“打包”成字节流，以便通过底层的Binder机制进行跨进程传输，或在Activity重建时持久化状态。这是Android组件化通信和生命周期管理的基础。
1. 核心原因：为何必须“打包”对象？
Android应用中的组件（Activity, Service等）可能运行在不同的进程中，它们的内存空间是相互隔离的。你不能直接将一个对象的内存地址从A进程传递给B进程。因此，必须将对象本身的状态数据提取出来，转换成一块通用的、扁平化的字节流（序列化），传递到目标进程后再根据这些字节流恢复成一个一模一样的对象（反序列化）。
这个过程主要服务于两个场景：
- 跨进程通信 (IPC) ：这是最主要的原因。当你使用
Intent启动另一个应用的Activity或本应用的Service时，Intent携带的Bundle数据需要穿过进程边界。这个过程由Android的 Binder IPC机制 完成，而Parcelable正是为Binder量身定制的高性能“包裹格式”。 - 进程内状态持久化：当屏幕旋转或内存不足导致Activity被系统销毁重建时，系统会调用
onSaveInstanceState()。你需要将UI状态存入Bundle，这个Bundle会被系统暂时持有，等Activity重建后再还给你。这个“暂存”过程也需要序列化。
2. 序列化方案对决：Parcelable vs Serializable
| 特性 | Parcelable (Android推荐) | Serializable (Java标准) |
|---|---|---|
| 核心机制 | 将对象拆解，主动、有序地将每个字段写入一块共享内存（Parcel），读取时再反向操作。 | 使用反射来遍历对象的所有成员变量，通过I/O流将其写入字节序列。 |
| 性能 | 高。无反射，直接内存操作，开销极小。是Serializable的数倍乃至数十倍。 | 低。大量反射调用非常耗时，且会创建大量临时对象，频繁触发GC，可能导致UI卡顿。 |
| 实现方式 | 相对复杂，但Kotlin的@Parcelize注解让它变得极其简单。 | 极其简单，只需实现一个空接口。 |
| 适用场景 | Android所有组件间（IPC）的数据传递、Bundle中的状态保存。 | 仅适用于临时性、非核心、对性能无要求的场景，或需要与某些只支持Serializable的旧Java库交互时。 |
| 主要风险 | 传递的数据过大（如图、大型列表）会导致TransactionTooLargeException崩溃。 | 性能问题导致ANR；版本不兼容（serialVersionUID）问题。 |
Kotlin下的最佳实践：@Parcelize
// 只需一个注解，即可拥有Parcelable的极致性能和Serializable的便捷性
import kotlinx.parcelize.Parcelize
@Parcelize
data class User(val name: String, val age: Int) : Parcelable
3. 场景化技术选型：不止于Parcelable
Parcelable和Serializable主要解决运行时的数据传递问题。当涉及持久化存储或网络通信时，我们有更好的选择。
-
场景一：通过
Intent传递对象- 唯一推荐：
Parcelable（使用@Parcelize）。
- 唯一推荐：
-
场景二：将对象存入文件或数据库
- 最佳实践：使用JSON格式。配合Kotlinx Serialization, Moshi, 或 Gson等库，将对象转换为JSON字符串进行存储。
- 优点：JSON可读性强，跨平台，生态成熟，库功能强大且稳定。
-
场景三：通过网络API传输对象
- 行业标准：同样使用JSON。
结论：Parcelable用于内存，JSON用于存储和网络。 这是现代Android开发应当遵循的核心原则。
避坑指南
- 警惕
TransactionTooLargeException：Binder的通信缓冲区上限约为1MB。切勿在Bundle中传递大型数据（如Bitmap对象或庞大的列表）。应考虑传递ID或URI，由接收方根据ID/URI从数据库或网络加载数据。 Serializable的性能陷阱：即使在进程内使用，如果频繁地序列化/反序列化Serializable对象（例如在列表中），也可能因GC压力导致性能问题。- 版本兼容性：如果使用
Serializable进行数据持久化，一旦类的结构（如增删字段）发生变化，如果serialVersionUID不匹配，反序列化会失败。JSON库通常对此有更好的兼容策略。
