Room存储Bitmap后操作条目触发TransactionTooLargeException崩溃

崩溃的直接诱因是Binder事务缓冲区1MB硬限制，具体触发逻辑如下：

• 核心错误是使用SafeArgs在Fragment间传递包含完整Bitmap的实体类。Bitmap实现了Parcelable接口，你在列表项点击跳转时把整个实体（连带几MB的Bitmap）塞进了导航参数Bundle，而Fragment返回栈会持续持有每个Fragment实例的arguments引用，不会自动回收。每完成一次listFragment和updateFragment间的跳转，返回栈里就多存一份Bitmap的序列化拷贝，所以你看到parcel数据大小会随导航次数线性上涨，单次跳转存4.6MB左右的Bitmap数据，跳5次累计就到23MB，和你日志里的数值完全匹配。
• 平时更新、删除条目不崩溃，是因为这些操作都在应用进程内完成，不会触发全量Parcel数据的跨进程传输。只有两个场景会触发崩溃：
  • 调起系统相机：这是跨进程IPC操作，启动相机前系统会要求当前应用保存所有Activity、Fragment的状态，把所有SavedStateRegistry绑定的Bundle数据序列化后通过Binder传给系统服务，累计的超量数据直接突破1MB缓冲区限制，抛出TransactionTooLargeException。相机本身运行在独立系统进程，所以不会跟着崩溃。
  • 按Home键退后台：系统为了保留最近任务的恢复状态，会执行和上述完全一致的状态保存流程，同样会触发超限崩溃。
• 你提到的Bitmap复用完全没有生效：通过Bundle传递Bitmap本质是做序列化内存拷贝，不是传递内存引用，哪怕你逻辑上想复用同一张图，每次传参都会生成一份新的Bitmap字节拷贝，越积越多。另外直接通过@TypeConverter把Bitmap存进Room本身就是不合理的实现，高清图转字节数组动辄数MB，查库时会全量加载进内存，IO和内存开销都极高。

按优先级依次处理即可彻底解决问题：

1. 禁止在导航参数、状态保存Bundle里传递大对象
   • Fragment跳转时的Bundle/SafeArgs仅用来传轻量数据：比如条目的主键ID、短字符串、基础类型值。列表跳更新页时只传对应条目的id，updateFragment拿到id后自行从Room数据库查询对应条目数据，从根源上杜绝大Bitmap进入Parcel缓存。
   • 如果需要传递图片资源，仅传图片对应的文件路径、FileProvider生成的Uri字符串，目标页拿到路径/Uri后自行异步加载图片，绝对不要直接传Bitmap实例。
2. 修正Bitmap存储逻辑
   • 移除Room里直接存Bitmap的TypeConverter：拍照后的图片存到应用私有存储目录，Room表内仅存储图片的路径/Uri字段。图片显示时用图片加载库按目标ImageView尺寸做采样加载：列表项加载小尺寸缩略图，表单、详情页加载适配控件尺寸的压缩图，不要全尺寸加载高清Bitmap在不同页面间传递。
3. 清理返回栈冗余实例
   • 在updateFragment完成更新、删除操作返回listFragment时，调用NavController.popBackStack()将updateFragment实例从返回栈中弹出，避免无用的Fragment实例长期持有旧的arguments数据占用内存。
   • 不要在onSaveInstanceState回调的Bundle中存入任何大尺寸对象，避免系统做状态保存时序列化多余数据。

内容的提问来源于stack exchange，提问作者nikenzo