swift中后台队列的性能？

Question

在这里跟进我的问题。

我有一个方法lotsOfWork（）可能需要一些时间才能完成。 在运行时，用户需要等待它完成。 我想向用户提供反馈，以便他看到发生了什么。

我现在有以下代码来运行我的lotsOfWork（）方法，同时允许它更新显示其进度的标签：

import UIKit

class ViewController: UIViewController {

    @IBOutlet weak var label: UILabel!

    override func viewDidAppear(_ animated: Bool) {
        super.viewDidAppear(animated)

        DispatchQueue.global(qos: .background).async {
            self.lotsOfWork()
        }
    }

    func lotsOfWork() {
        for i in 1...10 {
            DispatchQueue.main.async {
                self.label.text = "Working on item \(i)..."
            }
            sleep(1) // Simulating lots of work
        }
    }
}

但这也意味着lotsOfWork（）方法将在后台队列中执行，而不是在main中执行。

当lotsOfWork（）运行时，主队列中没有任何事情发生 - 除了更新标签。 除了等待，用户不能做任何事情。

问题1：这是一个重大的性能问题吗？ 这项工作需要更多时间才能完成吗？

问题2：如果这是一个问题，有没有办法让lotOfWork（）方法在main中运行， 同时仍然能够更新label.text ？

我尝试使用DispatchQueue.main.async甚至2个嵌套的DispatchQueue.main.async，但这不会更新label.text。

我也尝试使用setNeedsDisplay（）和setNeedsLayout（），但这并没有改变任何东西。

在main中执行lotsOfWork（）不是问题，因为用户需要等待这项工作完成才能继续。 但是如果lotsOfWork（）在main中运行，我无法实时更新label.text。

Answer 1

您请求的QoS（服务质量）不正确。 你已经要求background ：

用于非用户启动或可见的工作。 通常，用户不会意识到这项工作甚至正在发生。 例如，预读内容，搜索索引，备份或与外部系统同步数据。

后台任务是优先级最低的任务，原则上可能永远不会执行（至少，您应该愿意接受数小时或更长时间的延迟）。

如果用户请求了操作并且必须等待它完成，那么正确的QoS是.userInitiated ：

用于执行用户明确请求的工作，并且必须立即显示结果以允许进一步的用户交互。 例如，在用户在消息列表中选择电子邮件后加载电子邮件。

这个QoS级别可以（并且经常）与主队列一样高效，但您通常应该避免借调猜测系统将执行的操作，并确保使用与意图匹配的QoS标记操作。 所有这些的最佳介绍是在Swift 3中使用GCD进行并发编程 。

我通常发现当人们选择.background （最低的QoS）时，他们通常意味着.utility ，当他们选择.userInteractive （最高级别）时，他们通常意味着.userInitiated 。 最高级别和最低级别具有非常特殊的用例，这些用例不常出现。 如果您在不到一天的时间内需要结果，那么您并不是指.background ，如果完成时间超过.background ，则.userInteractive 。

Answer 2

1. 根据Apple文档在此处找到：

由于优先级较高的工作比低优先级工作执行得更快，资源更多，因此通常需要比低优先级工作更多的能量。 为您的应用程序执行的工作准确指定适当的QoS类可确保您的应用程序具有响应性和节能性。

答案是肯定的 。 较低优先级队列可能获得较少的资源，因此执行速度较慢。

2. 答案是否定的 。 在不阻止UI更新的情况下，您无法在main上执行相对繁重的工作。

---

如果你对学习Swift中的Concurrency感兴趣，我建议你阅读Umberto Raimondi创建的这篇文章 。 这是迄今为止我见过的最好的Swift并发指南。