Signal-Android项目中长文本转发导致的附件重复问题分析

问题背景

在Signal-Android即时通讯应用中，用户发现当转发长文本消息（系统自动转换为text/x-signal-plain类型附件）时，会出现一个异常现象：每增加一个转发联系人，目标会话中就会额外生成一份重复的附件副本。这个问题不仅导致数据库冗余，在备份场景下还会显著增加存储空间占用。

技术细节

问题复现路径

1. 触发条件：用户选择转发超过显示限制的长文本消息（显示"Read more..."结尾的LONG_TEXT类型）
2. 异常表现：
   • 转发给N个联系人时，第N个接收会话会生成N个相同附件
   • 数据库attachment表中出现相同content_type、data_size的多条记录
   • 原始消息仅含1个附件，转发后呈现1→2→3...的递增复制

底层机制分析

通过调试日志可见核心问题发生在AttachmentTable的insertAttachmentsForMessage操作：

• 首次转发（消息771）：正常插入1个附件（insertParts(1)）
• 二次转发（消息772）：异常插入2个附件（insertParts(2)）
• 三次转发（消息773）：异常插入3个附件（insertParts(3)）
  这表明转发逻辑中存在附件对象的错误累积，而非预期的单次复制。

影响评估

1. 存储效率：20MB文本转发4次会产生额外120MB冗余数据
2. 备份系统：影响备份文件体积和传输效率
3. 数据一致性：虽然UI层不显示重复内容，但底层存在数据异常

解决方案建议

1. 附件引用机制：应改为引用原始附件URI而非创建新副本
2. 转发逻辑优化：在MessageSender层面对附件进行去重处理
3. 数据库约束：增加(message_id, content_type, data_size)的唯一性校验

开发者启示

该问题揭示了消息转发场景下的几个关键设计考量：

1. 附件生命周期管理需要区分"物理存储"和"逻辑引用"
2. 批量操作时需注意对象引用的深拷贝/浅拷贝问题
3. 长文本这种特殊消息类型需要专门的转发处理逻辑

用户建议

普通用户可通过以下方式规避影响：

1. 对超长文本考虑分段发送
2. 优先使用单次转发而非批量转发
3. 定期清理历史备份文件