Исходя из моего опыта, решения с точки зрения производительности и памяти находятся на противоположных концах слайдера. Вы можете перемещаться со своим решением где-то между этими двумя, но с тем недостатком, что лучшее решение с точки зрения производительности обычно означает худшее решение с точки зрения памяти и наоборот. Надеюсь, я объяснил это достаточно ясно:)
Вот как я решаю проблему отложенной загрузки изображений:
В своем приложении я создал ОДНУ сущность, которую я назвал GlobalImageProvider . Все запросы на изображения проходят через эту сущность. Таким образом, у меня есть контроль над тем, сколько потоков я использую для загрузки, и я могу реализовать систему кэширования (память + локальный диск), все это полностью прозрачно для приложения и с полным контролем.
Контролируя размер кэша, я могу контролировать, насколько быстро приложение чувствует себя. С точки зрения производительности ничто не сравнится с тем, что UIImage
уже создано в памяти.
Что касается памяти, вы даже можете отключить кеш.
Более того, я даже могу динамически изменять количество потоков во время работы приложения в зависимости от качества сети, которая у меня есть.
Чтобы делать онлайн-запросы, я использую NSURLConnection
, но я планирую переключиться на что-то еще, так как я прочитал, что это утечка памяти.
Что касается вида и контроллеров, у меня есть AsyncImageView
, который является просто UIImageView
, который знает, как работать с GlobalImageProvider
. Он знает, как отображать индикатор активности во время загрузки, и может обработать ответ от GlobalImageProvider
.
Если вы знаете URL нужного изображения, все, что вам нужно сделать, это добавить AsyncImageView
на экран и сделать запрос к GlobalImageProvider
с AsyncImageView
в качестве «обработчика» для этого изображения.
Если вам не нравится смешивать данные с представлениями изображений, вы можете добавить ViewController между GlobalImageProvider и AsyncImageView. Он получает ответ изображения и помещает его в ImageView.
Вот и все, надеюсь, это вам немного поможет.