Android“沉默杀手”：TransactionTooLargeException的深层解析TransactionTo

TransactionTooLargeException 是 Android 跨进程通信（IPC）机制的一个致命缺陷。它的根源在于 Binder 框架对 IPC 事务大小的硬性限制。

Binder缓冲区的内存池：每个 Android 进程在启动时，都会向 Binder 驱动申请一块大小为 1MB 的内存池。这个内存池是所有 Binder 事务共享的。
事务数据：所有通过 Binder 传递的数据，包括 Intent 的 extras、onSaveInstanceState 的 Bundle，都会被序列化成一个 Parcel 对象，并被拷贝到这个共享缓冲区中。
刻意限制：这个 1MB 的限制是一个关键设计决策。它旨在防止单个应用通过一个巨大的 IPC 事务耗尽内核资源，从而保护整个 Android 系统的稳定性。

一旦 Parcel 对象的大小超出了缓冲区的容量，Binder 驱动会立即拒绝该事务，并向上层抛出 TransactionTooLargeException。

TransactionTooLargeException 并非只发生在跨应用通信中。它也可能在应用内部的组件间通信中出现。

启动Activity：当通过 Intent 启动一个 Activity 时，即使是在应用内部，Intent 数据也需要通过 ActivityManagerService（一个独立的进程）进行路由。如果 Intent 的 extras 中包含了大型数据，如一个未压缩的 Bitmap 或一个复杂的数据对象列表，就会触发异常。
保存实例状态（onSaveInstanceState） ：这是该异常最隐蔽的来源。当 Activity 被意外销毁（如配置变更、系统回收）时，onSaveInstanceState 会被调用。Bundle 中的数据随后会通过 Binder 事务传递给系统服务进行保存。如果 Bundle 携带了过多的数据，同样会导致异常。

规则很简单：永远不要把 Intent 或 Bundle 当作数据传输的载体。 正确的做法是传递一个唯一标识符，然后通过其他方式共享数据。

场景：在同一个应用的 Activity 或 Fragment 之间传递大型对象。
解决方案：使用 ViewModel 或 Repository Pattern。
- 共享 ViewModel：将 ViewModel 的作用域限定在父 Activity 或导航图上。在源组件中将数据存入 ViewModel，在目标组件中再从中取出。
- 仓库模式：将大型数据存储在内存缓存或数据库中。在 Intent 中只传递一个数据的 ID。接收方组件使用该 ID 从仓库中获取完整的数据。

场景：在不同应用之间共享一个大文件（如照片、文档）。
解决方案：使用 FileProvider。
- 原理：FileProvider 允许你为文件生成一个临时的、安全的 content:// URI。在 Intent 中只传递这个 URI，并附上 FLAG_GRANT_READ_URI_PERMISSION 权限。
- 优势：这种方式既安全又高效，避免了直接传递文件路径所带来的权限问题，也绕过了 Binder 的大小限制。