AWS SDK for iOS 大文件上传重启问题分析与修复

问题背景

在使用AWS SDK for iOS的TransferUtility功能时，开发者发现当上传超过2.1GB的大文件时，如果应用被系统终止后重新启动，上传任务无法正确恢复。具体表现为上传进度始终为0，最终导致上传失败并返回错误信息。

问题现象

当上传文件大小超过2.1GB时：

1. 应用被系统终止后重新启动
2. 上传任务看似恢复，但进度始终为0
3. 最终失败并报错："Expected to send [负值]，but sent [正值] and there are no remaining parts"

对比测试发现，小于2.1GB的文件上传能够正常恢复，而大于2.1GB的文件则会出现上述问题。

根本原因

经过分析，问题出在数据库读取文件大小时使用了32位有符号整数(intForColumn)而非64位整数(longForColumn)。当文件大小超过2,147,483,647字节(约2.1GB)时，32位有符号整数会溢出变为负值。

例如：

• 原始文件大小：2,332,786,803字节
• 读取后变为：-1,962,180,493字节

这个错误的负值导致上传任务无法正确计算剩余部分，最终失败。

解决方案

修复方案是将数据库读取方法从intForColumn改为longForColumn，确保能够正确处理大文件大小。这个修复已经合并到主分支，并在2.38.0版本中发布。

技术细节

在AWSS3TransferUtilityDatabaseHelper.m文件中，修改了从数据库读取contentLength的代码：

// 修复前
task.contentLength = [resultSet intForColumn:@"content_length"];

// 修复后
task.contentLength = [resultSet longForColumn:@"content_length"];

这个简单的改动确保了即使是大文件也能正确读取其大小值。

替代方案讨论

AWS团队建议开发者考虑迁移到Amplify Swift或AWS SDK for Swift，它们是基于Swift原生开发的现代解决方案。不过需要注意：

1. Amplify Swift目前尚未完全实现TransferUtility的所有功能
2. AWS SDK for Swift是全新架构，与iOS SDK不直接兼容
3. 开发者可以根据需求选择部分使用Amplify组件，而不必完全迁移整个Amplify栈

最佳实践建议

对于需要处理大文件上传的iOS应用：

1. 立即升级到AWS SDK for iOS 2.38.0或更高版本
2. 如果考虑长期维护，评估迁移到Swift生态方案的可能性
3. 实现完善的错误处理和重试机制，特别是对于大文件上传场景
4. 在应用设计中考虑后台任务管理的复杂性

总结

这个案例展示了底层数据类型选择对系统稳定性的重要影响。通过将32位整数升级为64位整数，解决了大文件上传恢复的问题。同时，这也提醒开发者在处理可能的大数值时要特别注意数据类型的选择。