我需要按顺序下载文件。目前我可以在应用程序处于前台时做到这一点。
以下是我使用的逻辑。
创建所有下载任务。
一次恢复一个，当当前完成时从 恢复下一个URLSession:task:didCompleteWithError:。
此逻辑在应用程序处于前台时有效，但一旦应用程序开始在后台运行（通过崩溃）并且我们在下载完成之前再次运行应用程序，所有任务状态已更改为恢复并且所有任务都在同时下载。
这是预期的行为还是我在后台模式下连续订购它时缺少的任何东西？
编辑：
我通过一一创建下载任务来检查。完成第一个任务后在里面创建下一个setTaskDidCompleteBlock，依此类推。它只完成第一个任务，并且在该会话在内部创建任务时崩溃setTaskDidCompleteBlock（这仅在后台模式下运行时发生，前台工作正常）。
这是我的崩溃日志屏幕截图：
和
任何帮助，将不胜感激。
如果您绝对需要按顺序运行这些请求，我建议不要预先实例化所有这些任务，而是一次实例化它们，仅在前一个完成后实例化下一个。
但我们必须认识到，您为按顺序运行请求付出了巨大的性能损失。（并且在使用后台会话时这个问题会被放大。）如果可能的话，看看你是否可以将你的请求更改为并发运行。显然，如果您需要一个输出来创建另一个请求，那么您会被卡住（或者至少在您重构服务器代码之前），但这显然不是这里的问题（因为您创建了所有请求正面）。如果您出于人为原因执行此顺序请求过程（例如，代码正在填充数组并且您希望按顺序执行），那么您可能需要重新设计实现以消除此人为约束。
我也看到过这种情况。如果您在应用程序处于前台时创建了一个 downloadTask 但不调用resume()，它将不会启动 - 但是，它会在应用程序处于后台时自动启动。
suspend()解决方案是在创建每个 downloadTask 时显式调用它。然后，当您准备好开始下载它时，调用resume().
显然，一个新创建的 downloadTask 既没有暂停也没有恢复。它的初始状态不是.Running，但是当应用程序在后台运行时，它会转移到.Running，因为它没有被显式挂起。这是令人惊讶的行为；我不知道为什么后台会话守护程序以这种方式工作。