iOS Swift中AWS S3 Transfer Utility分片上传重启恢复延迟问题

你的推测部分存在偏差，两类上传接口恢复速度的差异核心来自本地持久化策略、恢复流程的设计差异，不存在重启后重新组装文件的逻辑（分片最终由S3服务端合并，本地不会做分片组装操作），具体差异如下：

• uploadData 接口恢复无延迟的原因
  调用该接口时，待上传的全量二进制数据会被直接持久化到Transfer Utility的本地沙盒存储中，同时记录上传偏移量。进程重启恢复任务时，不需要访问原文件路径、不需要额外发起网络校验，直接读取本地存储的待传数据即可从断点位置继续上传，因此几乎没有等待耗时。
• uploadUsingMultiPart、uploadFile 接口恢复存在延迟的原因
  这两个面向大文件的上传接口不会将全量文件存入SDK本地数据库，仅持久化原文件路径、文件校验值、已上传分片的本地记录，重启恢复时需要执行两个耗时操作：
  1. 本地文件一致性校验：SDK会重新读取目标路径的文件，计算全文件哈希值，和持久化存储的校验值做比对，确认文件没有被删除、修改，避免续传出现文件损坏问题。100MB级别的文件做全量哈希计算，在旧机型上可能产生数秒的等待。
  2. 服务端分片状态同步：本地校验通过后，SDK会主动向S3服务端发起ListParts请求，拉取当前分片上传任务实际已被服务端接收的分片列表，和本地记录的已上传分片做对账，剔除不一致的无效记录，确认准确的断点位置后才会开始续传，该网络请求的耗时也会叠加到恢复等待时间中。

参考调用代码 #

// 分片上传调用
transferUtility?.uploadUsingMultiPart(fileURL: fileUrl, bucket: self.bucketName, key: myFileKey, contentType: contenType, expression: expression, completionHandler: completionHandler).continueWith { (task) -> Any? in
       if let error = task.error {
                print("error is: \(error.localizedDescription)")
            }
       if let task = task.result {
                
       }
    return nil
}

// 普通文件上传调用
transferUtility?.uploadFile(fileUrl, bucket: self.bucketName, key: fileKey, contentType: "image", expression: expression, completionHandler: completionHandler).continueWith { (task) -> Any? in
        if let error = task.error {
            print("error is: \(error.localizedDescription)")
        }
        return nil
}

小提示：如果需要降低大文件分片上传的恢复延迟，可以将待上传文件提前存入应用沙盒的Documents目录避免访问权限校验带来的额外IO耗时，不建议随意关闭SDK的文件校验、服务端分片对账逻辑，否则可能出现上传文件损坏、重复上传已完成分片的问题。

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