Ios 在后台模式下下载多个操作队列不稳定的文件

目前，我想要实现的是从一个阵列下载文件，该阵列一次只下载一个文件，即使应用程序进入后台状态，它仍然执行下载

我使用的是中所述的Rob代码，但他使用的是URLSessionConfiguration.default，我想使用URLSessionConfiguration.background（带标识符：“uniqueID”）

它在第一次尝试时确实有效，但在进入后台后，一切都变得混乱。操作开始一次下载多个文件，不再按顺序进行

---

有什么解决办法吗？或者我应该用什么来实现我想要的。如果在安卓系统中，我们的服务可以轻松处理这一问题。

只有在应用处于活动/运行状态时，才能使用包装请求的整个思想。它非常适合于约束前台请求的并发度、管理依赖项等

不过，对于应用程序挂起后继续进行的后台会话，这些都不相关。创建请求，将其交给后台会话进行管理，并监视为后台会话调用的委托方法。不需要/不需要操作。请记住，这些请求将由后台会话守护进程处理，即使您的应用程序已挂起（或者在其正常生命周期中终止，但如果您强制退出它，则不会）。因此，如果后台

URLSession

守护进程正在处理请求，而您的应用程序未处于活动状态，那么操作、操作队列等的整个概念就毫无意义

请参阅后台会话的示例

---

顺便说一下，当下载可能需要很长时间的大量资源时，真正的后台会话非常有用。但它带来了各种各样的复杂性（例如，您经常希望在未连接到改变应用生命周期的Xcode调试器时进行调试和诊断，因此您必须求助于统一消息等机制；您需要弄清楚如果在启动请求和完成请求之间终止应用，如何恢复UI；等等）

由于这种复杂性，您可能需要考虑这是否是绝对需要的。有时候，如果您只需要不到30秒来完成一些请求，那么在用户离开应用程序后，只需让操作系统在后台运行一段时间就更容易了，只需使用标准<代码> URLStuts。信息，请参阅。这是一个简单得多的解决方案，绕过了许多后台

URLSession

的麻烦。但它只在您只需要30秒或更短的时间时起作用。对于可能超过此小窗口的较大请求，需要一个真正的后台

URLSession

---

下面，你问：

据我所知，[并行下载多个文件]有一些缺点

不，允许下载以异步和并行方式进行总是更好的。它更快、更高效。您想要连续地、一个接一个地执行请求的唯一时间是您需要解析一个请求的响应以准备下一个请求。但这里不是这种情况

这里的例外是默认的前台

URLSession

。在这种情况下，您必须担心后一个请求在等待前一个请求时超时。在这种情况下，您可能会增大超时间隔。或者我们可以将请求包装在

操作

子类中，这样我们不仅可以限制并发请求的数量我们将允许请求，但在较早的请求完成之前不会启动后续请求。但即使在这种情况下，我们通常也不会连续执行请求，而是使用4的

maxConcurrentOperationCount

或类似值

但是对于后台会话，请求不会因为后台守护进程还没有找到它们而超时。只需将您的请求添加到后台

URLSession

，然后让操作系统为您处理。您肯定不想一次下载一个图像，而后台守护进程会在ba中重新启动您的应用程序当一个下载完成后，你可以启动下一个。这将是非常低效的（无论是在用户的电池和速度方面）

您需要在文件数组中循环，然后添加到会话中以使其下载，但它将异步下载，因此很难跟踪，因为文件太多

当然，你不能简单地“添加到数组末尾”如果请求是并行运行的，因为您不能保证它们将完成的顺序。但是在它们进入时捕获这些响应并不困难。只需使用一个字典，例如，可能由原始请求的URL键入。然后您可以轻松地在该字典中查找与parti关联的响应请求URL

这是难以置信的简单。我们现在可以并行执行请求，这是更快和更有效的

你接着说：

[并行下载]可能会导致电池消耗过高，同时会有很多请求。这就是为什么我试图让它一次下载每个文件的原因

不，您永远不需要为了电源而一次下载一个。如果有的话，一次下载一个会更慢，并且需要更多的电源

---

无关，如果您正在下载800多个文件，您可能希望允许用户在“低数据模式”下不执行这些请求。例如，在iOS 13中，您可以设置和

不管怎样（尤其是如果你支持较老的IOS版本），你可能还需要考虑适当的设置和

总之，你要确保尊重用户有限的蜂窝数据