Кстати, реализация от Криса Бэйнса — единственная, которая до сих пор активно развивается (последний коммит был буквально позавчера). Остальные же либо обошлись одноразовым коммитом, либо забросили развитие проекта.
Не особо дружу с Maven'ом, но не в этом дело.
На текущий момент, я считаю, проект не готов в качестве отдельной библиотеки. Сейчас многие параметры ImageLoader'а можно настраивать под себя (они у меня сейчас в Constants). А когда все задуманные фичи будут завершены, и я придумаю красивый способ предоставить настройку ImageLoader'а не меняя исходники — тогда, почему бы и нет, можно и в maven-репозиторий закинуть.
При превышении размера кэша удаляется «сильная» ссылка на Bitmap, но остается «слабая». Я не знаю, когда Bitmap будет собран сборщиком, а до этого делать recycle() ему нельзя, т.к. он может быть ещё переиспользован. В окончательном стирании Bitmap'ов полагаюсь на Android, ибо
"This is an advanced call, and normally need not be called, since the normal GC process will free up this memory when there are no more references to this bitmap."
Этот проект (LazyList), как и мой, базировался на LazyImageLoader'e (ссылку на который я давал в статье). Там (в LazyList) приведена в порядок работа с потоками, своя реализация кэша, и другие мелкие улучшения. Кое-что там действительно можно подсмотреть :) Но, на мой взгляд, UniversalImageLoader более гибкий, ибо с этой целью он разрабатывается.
Если я правильно понял первый пункт — это для того если уменьшенная картинка уже есть в кэше в памяти, а мы хотим ее отобразить в ImageView больше предыдущего по размерам. Справедливо. В «дисковом» кэше хранятся полноразмерные картинки, если что.
Насчет второго пункта, гугло-доки гласят: «Note: the decoder will try to fulfill this request, but the resulting bitmap may have different dimensions that precisely what has been requested. Also, powers of 2 are often faster/easier for the decoder to honor. „
И я боюсь что декодирование до точных размеров снизит производительность, может даже и существенно. Тут, пожалуй, можно отдать данное решение на выбор разработчику, что для него приоритетнее: память или процессорное время.
Кстати любые предложения по улучшению функциональности ImageLoader'а приветствуются. Возможно кто-то имеет свои use-case'ы, для которых ImageLoader можно адаптировать.
Ну да, моторолер не мой... Приведите код в порядок.
На текущий момент, я считаю, проект не готов в качестве отдельной библиотеки. Сейчас многие параметры ImageLoader'а можно настраивать под себя (они у меня сейчас в Constants). А когда все задуманные фичи будут завершены, и я придумаю красивый способ предоставить настройку ImageLoader'а не меняя исходники — тогда, почему бы и нет, можно и в maven-репозиторий закинуть.
"This is an advanced call, and normally need not be called, since the normal GC process will free up this memory when there are no more references to this bitmap."
Спасибо за замечания, все учту.
Насчет второго пункта, гугло-доки гласят:
«Note: the decoder will try to fulfill this request, but the resulting bitmap may have different dimensions that precisely what has been requested. Also, powers of 2 are often faster/easier for the decoder to honor. „
И я боюсь что декодирование до точных размеров снизит производительность, может даже и существенно. Тут, пожалуй, можно отдать данное решение на выбор разработчику, что для него приоритетнее: память или процессорное время.