Загрузка/кэширование изображения вне основного потока

Я не верю, что ваша производительность прокрутки связана с fetchImage. Хотя в Synchronized есть небольшие проблемы с производительностью, этого, вероятно, недостаточно, чтобы объяснить ваши проблемы. При этом здесь есть несколько проблем, но блокировка основной очереди, похоже, не является одной из них.

Более вероятным виновником может быть извлечение ресурсов, которые больше, чем представление изображения (например, большой ресурс в представлении маленького изображения требует изменения размера, что может заблокировать основной поток) или какая-то ошибка в логике выборки. Когда вы говорите «не вижу желаемой производительности прокрутки», это заикание или просто медленное? Природа проблемы «производительности прокрутки» будет диктовать решение.

Несколько несвязанных наблюдений:

1. Synchronised, используемый со словарем, не является потокобезопасным. Да, геттер и сеттер для value синхронизируются, но не последующие манипуляции с этим словарем. Это также очень неэффективно (хотя вряд ли достаточно неэффективно, чтобы объяснить проблемы, которые у вас возникают).

   Я бы предложил не синхронизировать поиск и настройку всего словаря, а создать тип синхронизированного словаря:

   public class SynchronisedDictionary<Key: Hashable, Value> {
       private var _value: [Key: Value]
   
       private let queue = DispatchQueue(label: "com.sync", qos: .userInitiated, attributes: .concurrent)
   
       public init(_ value: [Key: Value] = [:]) {
           _value = value
       }
   
       // you don't need/want this
       //
       // public var value: [Key: Value] {
       //     get { queue.sync { _value } }
       //     set { queue.async(flags: .barrier) { self._value = newValue } }
       // }
   
       subscript(key: Key) -> Value? {
           get { queue.sync { _value[key] } }
           set { queue.async(flags: .barrier) { self._value[key] = newValue } }
       }
   
       var count: Int { queue.sync { _value.count } }
   }
   

   В моих тестах в релизной сборке это было примерно в 20 раз быстрее. Кроме того, он потокобезопасен.

   Но идея состоит в том, что вы не должны открывать базовый словарь, а просто открывать любой интерфейс, необходимый для типа синхронизации для управления словарем. Вы, вероятно, захотите добавить дополнительные методы к вышеперечисленному (например, removeAll или что-то еще), но вышеперечисленного должно быть достаточно для ваших непосредственных целей. И вы должны уметь делать такие вещи, как:

   var dictionary = SynchronizedDictionary<String, UIImage>()
   
   dictionary["foo"] = image
   imageView.image = dictionary["foo"]
   print(dictionary.count)
   

   В качестве альтернативы вы можете просто отправить все обновления словаря в основную очередь (см. пункт 4 ниже), тогда вам вообще не нужен этот тип синхронизированного словаря.

2. Вы можете рассмотреть возможность использования NSCache вместо собственного словаря для хранения изображений. Вы хотите убедиться, что вы реагируете на нехватку памяти (очистка кеша) или некоторый фиксированный предел общей стоимости. Кроме того, NSCache уже является потокобезопасным.

3. В fetchImage у вас есть несколько путей выполнения, где вы не вызываете обработчик завершения. По соглашению вам нужно убедиться, что обработчик завершения всегда вызывается. Например. что, если вызывающая сторона запустит счетчик перед получением изображения и остановит его в обработчике завершения? Если вы не можете вызвать обработчик завершения, то счетчик также может никогда не остановиться.

4. Точно так же, когда вы вызываете обработчик завершения, вы не всегда отправляете его обратно в основную очередь. Я бы либо всегда отправлял обратно в основную очередь (избавляя вызывающего от необходимости делать это), либо просто вызывал обработчик завершения из текущей очереди, но только отправка некоторых из них в основную очередь вызывает путаницу.

FWIW, вы можете создать цель модульных тестов и продемонстрировать разницу между исходным Synchronised и SynchronisedDictionary, протестировав массовую параллельную модификацию словаря с concurrentPerform:

// this is not thread-safe if T is mutable

public class Synchronised<T> {
    private var _value: T

    private let queue = DispatchQueue(label: "com.sync", qos: .userInitiated, attributes: .concurrent)

    public init(_ value: T) {
        _value = value
    }

    public var value: T {
        get { queue.sync { _value } }
        set { queue.async(flags: .barrier) { self._value = newValue }}
    }
}

// this is thread-safe dictionary ... assuming `Value` is not mutable reference type

public class SynchronisedDictionary<Key: Hashable, Value> {
    private var _value: [Key: Value]

    private let queue = DispatchQueue(label: "com.sync", qos: .userInitiated, attributes: .concurrent)

    public init(_ value: [Key: Value] = [:]) {
        _value = value
    }

    subscript(key: Key) -> Value? {
        get { queue.sync { _value[key] } }
        set { queue.async(flags: .barrier) { self._value[key] = newValue } }
    }

    var count: Int { queue.sync { _value.count } }
}

class SynchronisedTests: XCTestCase {
    let iterations = 10_000

    func testSynchronised() throws {
        let dictionary = Synchronised([String: Int]())

        DispatchQueue.concurrentPerform(iterations: iterations) { i in
            let key = "\(i)"
            dictionary.value[key] = i
        }

        XCTAssertEqual(iterations, dictionary.value.count)  //  XCTAssertEqual failed: ("10000") is not equal to ("834")
    }

    func testSynchronisedDictionary() throws {
        let dictionary = SynchronisedDictionary<String, Int>()

        DispatchQueue.concurrentPerform(iterations: iterations) { i in
            let key = "\(i)"
            dictionary[key] = i
        }

        XCTAssertEqual(iterations, dictionary.count)        // success
    }
}