NSURLSessionConfiguration 的 timeoutIntervalForRequest 不适用于后台 URLSession

Question

我按照这个教程Downloading files in background with URLSessionDownloadTask

还有这个苹果文档Downloading Files in the Background

我尝试设置，因为我们有一个长时间运行的 API

let config = URLSessionConfiguration.background(withIdentifier: "\(Bundle.main.bundleIdentifier!).background")
    config.timeoutIntervalForRequest = 120
    config.timeoutIntervalForResource = 180

但我遇到了这个奇怪的问题：

如果服务器没有响应任何数据，意味着

func urlSession(_ session: URLSession, downloadTask: URLSessionDownloadTask, didWriteData bytesWritten: Int64, totalBytesWritten: Int64, totalBytesExpectedToWrite: Int64)

根本不会被调用。

应用程序将终止先前的请求，并每 66 秒重试一次新请求。我不知道这个数字是从哪里来的，但根据我的实验，大约是 66 秒

如果我将timeoutIntervalForRequest = 10 设置得足够好，应用程序将每 10 秒重试一次请求，但任何将其设置为 66 秒以上的尝试都不起作用

不确定是否有人遇到同样的问题并找到了解决方案。

只需 1 条注意：当达到 180 秒时，整个事情将超时，并且应用程序停止重试新请求

Answer 1

首先，这是一个错误。请在 bugreport.apple.com 上提交。不应像那样忽略超时。当然，这很有可能是一个电源管理问题并且无法修复，所以我不会屏住呼吸。

其次，您处理问题的方式几乎可以保证会导致问题，即使超时错误已得到修复。您的服务器没有发回任何字节以保持连接活动的事实当然是 iOS 设备断开连接的原因，但即使您更改它并使其每次发送一个字节的虚假标头直到数据准备好五秒钟，您仍然会遇到问题。

基本上，在移动设备上，您真的不应该出于任何原因保持与远程服务器的长时间运行连接。保持 Wi-Fi 无线电持续打开会大量浪费电池，更不用说蜂窝无线电，更糟糕的是，当用户走出范围、切换蜂窝站点或以其他方式暂时失去连接时，连接可能随时失败。网络很垃圾——蜂窝网络更是如此。

对于长时间运行的服务器处理，一种更好的方法是异步进行：

• 向服务器发出请求。
• 让服务器向您发回与请求关联的唯一标识符，以及（可选）估计的完成时间。
• 等到预计完成时间，然后询问服务器进展情况（提供唯一标识符）。
• 继续定期轮询服务器，直到服务器表示任务已完成（或已失败）。
• 当服务器表示任务已完成时，发出请求以检索结果，然后发出请求以释放已完成的结果。
• 使用 cron 作业或类似任务定期清理服务器上旧的、未收集的结果。

这种方法可以避免在轮询请求的任一侧保持无线电保持热状态，除非在轮询请求的任一侧保持几秒钟，并且它使超时问题完全没有意义。