ios - 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 设备断开连接的原因，但即使您更改了它并使其每次发送一个字节的虚假 header 直到数据准备好五秒钟，您仍然会遇到问题。

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

长时间运行的服务器处理的一个更好的方法是异步执行:

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

除了轮询请求两侧的几秒钟之外，这种方法避免了 radio 保持热状态，并且它使超时问题完全没有意义。