我有一个CPU任务，当应用程序在后台运行时（通过获取或静默通知）需要执行。在前台运行时此任务大约需要1s，而在后台运行时大约需要9s。基本上，它将大约100K文本条目保存到数据库中。无论我使用FileHandle操作还是Core Data sqlite解决方案，性能配置文件都差不多（令人惊讶的是Core Data慢一点）。
我真的不想深入了解代码的细节。我已经剖析出了地狱，而在前景方面，它表现得很出色。但是很明显，当应用在后台运行时，iOS对其进行了节流，使其速度降低了9倍。除了响应iOS的无声通知外，这不是什么大问题，iOS仅允许应用程序完成30-40秒，而此9s任务可以使其超出限制。 （其余部分正在等待我无法控制的子系统。）
问题是
有什么办法告诉iOS 嗨，是的，我在后台，但是我真的需要这段代码才能快速运行并避免您的麻烦？ FWIW我已经在.userInitiated qos分配队列中运行：
DispatchQueue.global(qos: .userInitiated).async {
// code to run faster goes here
}
谢谢！
答案 0 :(得分：4)
首先，不。节流是有目的的，您无法阻止它。我很好奇，当您在后台使用.userInitiated队列是否比默认队列实际提高了性能。即使今天是对的，我也不会打赌，通常来说，您不应标记用户发起的明显不是用户发起的内容。在后台运行该队列时，我不会过苹果。
与其要求运行更快，还不如要求操作系统花更多时间。为此，您可以在开始处理数据时调用beginBackgroundTask(expirationHandler:)，然后在完成后调用endBackgroundTask(_:)。这告诉操作系统您正在做的事情将对您有所帮助，并且可能会给您几分钟的时间。当您用尽了所有时间后，它将调用expirationHandler，您可以保存此时的位置，以便稍后继续工作。
如果时间用完了，您只会花几秒钟来完成到期处理程序，因此此时您可能无法将大量数据写入磁盘。如果数据来自网络，则可以通过首先下载数据（使用URLSessionDownloadTask）来解决此问题。这些功能非常节能，在数据下载完成之前，您的应用程序甚至不会启动。然后开始阅读和处理，如果时间用完了，您会松开用户默认设置的位置，以便下次启动时可以再次选择它。完成后，删除文件。