Вы наметили три способа указания качества обслуживания (QoS). Но последние два действительно одинаковы, только один использует блоки, а другой DispatchWorkItem
. Итак, давайте сосредоточимся на этих двух измерениях QoS: на очереди и на отправленной задаче.
Короче говоря, QoS в очереди имеет приоритет над QoS элемента отправки, если только не:
- вы вообще не указали QoS для очереди (например, QoS
.unspecified
); или - вы указали QoS для очереди, но отправили задачу с флагом
.enforceQoS
(который устанавливает приоритет QoS задачи по сравнению с очередью, если «это делает не снижайте качество обслуживания »).
Честно говоря, большую часть времени мы просто устанавливаем очередь QoS и называем это днем. Это ясно, кратко и позволяет легко рассуждать о нашем коде. Задать QoS на уровне задач можно, но это не так часто. И указание QoS для очереди и отправленных элементов и переопределение QoS с флагом .enforceQoS
очень необычно.
Для получения дополнительной информации о QoS в целом см. WWD C 2015 Building Responsive and Эффективные приложения с GCD и WWD C 2016 Параллельное программирование с GCD в Swift 3 . Первое видео знакомит нас с QoS (и, как вы можете видеть, когда они представили эту топи c, фокус был в очередях отправки), но это видео по общему признанию использует старый синтаксис Swift 2, хотя концепции остаются неизменными. Второе видео знакомит нас с современным синтаксисом Swift и кратко подводит итог многим обсуждениям предыдущего видео.
Существуют всевозможные интересные (и необычные) крайние случаи (например, обработка GCD инверсий приоритетов), но это обсуждается в приведенных выше видео и выходит за рамки этого вопроса.