Поддерживает ли SDWebImage небыструю прокрутку (беглый просмотр) для ленивой загрузки?

При ленивой загрузке (таблица UICollectionView)

для правильного результата НЕ следует начинать загрузку, когда пользователь очень быстро прокручивает коллекцию.

Итак, представьте себе вертикальную прокрутку с 200 панелями, каждая с изображением; четыре или пять человек видны на экране одновременно.

При первой загрузке должны начать загружаться первые 4 видимых изображения. Если вы прокрутите немного вниз, новые видимые изображения должны начать загружаться.

НО, если пользователь: очень быстро прокручивается вниз (скажем) до позиции 100, а затем позиционирует представление, показывающее элементы 100-104... в идеале вам НЕ СЛЕДУЕТ начинать загрузку изображений, которые пользователь "просмотрел" очень быстро (скажем, с 4 по 99), вы должны запускать загрузку только тогда, когда пользователь перестает очень быстро прокручивать и, по-видимому, останавливает или замедляет некоторые изображения.

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

У меня простой вопрос: поддерживает ли SDWebImage эту концепцию? Если нет, есть ли другой популярный готовый подход? Ваше здоровье


ios sdwebimage uicollectionview uitableview lazy-loading
person Fattie    schedule 17.08.2014    source источник

Ответы (1)


arrow_upward
5
arrow_downward

Он не поддерживает это, потому что обычно это категория в представлении изображения, но было бы довольно просто добавить эту возможность самостоятельно.

Предполагая, что вы запускаете загрузку изображения в cellForItem..., вы должны добавить отправку после блока, который запускает загрузку только в том случае, если та же ячейка все еще имеет тот же индексный путь, скажем, через 0,2 секунды.

Я бы проверил, есть ли у вас измеримая проблема, прежде чем что-либо делать - AFAIK SDWebImage (и, безусловно, категория просмотра изображений AFNetworking) отменит любые невыполненные запросы URL-адресов при получении нового, поэтому вы можете выполнять ненужную оптимизацию.

person jrturton    schedule 17.08.2014
comment
привет, JR, спасибо за подтверждение, что он не встроен в SD !! ваше здоровье - person Fattie; 17.08.2014
comment
Эй, JR, знаешь, это отличная идея — просто ждать; мы всегда делали это по-другому, проверяя, быстро ли вы все еще прокручиваете. твоя идея скорее ПОЦЕЛУЙ, офигенно. К вашему сведению, я считаю, что около 0,4 идеально подходит (зависит от используемого макета/размера изображений/других факторов, которые я думаю). Еще раз спасибо! - person Fattie; 18.08.2014
comment
На самом деле я написал исходный ответ, в котором говорилось, что нужно проверять прокрутку / перезагрузку при остановке, после чего мне пришло в голову ожидание. Это кажется намного проще! - person jrturton; 18.08.2014
comment
Я могу подтвердить, что это невероятно проще и на практике работает намного лучше. Это правда, что теоретически вы «бессмысленно» ждете 0,4 секунды, пока загрузятся первые появившиеся ячейки, но что с того? Мы всегда делали это по-другому, проверяя, отображаются ли ячейки, скорость прокрутки и т. д., и теперь я просто чувствую себя глупо :/ ЕЩЕ РАЗ СПАСИБО - person Fattie; 18.08.2014
comment
@Joe Blow: не могли бы вы привести пример кода? Спасибо - person Nam Vu; 10.01.2015
comment
На какое время нам нужно отложить, если количество строк равно 4000? Нужен ли для этого эффективный подход? - person Nghia Luong; 05.10.2015
comment
@NghiaLuong количество строк не имеет значения. - person jrturton; 05.10.2015