Comments 19
Тяжело читать вообще с такой разметкой, как кода, так и основного текста.
мне вот не нравится подобная штука тем, что она не дает мне контроля над этим всем…

в своем проекте я создавал один Downloader, который получает «запросы», а потом как скачает передает уже загрузчику (который уже с ФС грузит) и потом уже вызвается колбек onImageLoaded(Bitmap, ImageDescription)

все это делается в два потока…

в общем-то не могу понять что лучше. ведь у нас мобильная платформа и ускорение использования трафика и загрузка с карты в несколько потоков ест проц, а соотв. батарейку…

хм…
а так очень похоже на то, что я делал только у меня в одном потоке делается работа (ну или можно расширить класс на несколько), а тут множество AsyncTask'ов.
и да — зачем weak reference? там же gc будет часто работать — ведь с изображениями работаем, а они память едят.
Виртуальной машиной под приложение на самых слабых телефонах (зависит от железа) выделяется 15 мегабайт, если мне не изменяет память. А теперь представьте что мы прокрутили список с сотней картинок на 100k каждая. Приложение вылетит с out of memory.
Ну это при условии, что 5 мегабайт уже забито программой, что бывает довольно часто.
ну уж нет. не в этом случае. тут используется примерно столько ImageView, сколько влезает на экран (5-7) и больше 5-7 указателей на AsyncTask не будет.

Пардон. Думал используется weakRef для кэширования уже скаченных изображений, как обычно делается.
а вот лучше юзать softRef, а не weakRef для кеша. и то там не все так просто — для изображений нормально мне его зюзать не удалось — как-то криво картинки из памяти удаляются если их просто делать как weak/soft ref.
мне тоже кажеться, что лучше юзать один Executor — так вы контролируете количество потоков и знаете очередность загрузки картинок.

+ ко всему этому мне кажется что не стоит передавать туда ImageView — а лучше сделать какойто кеш для этих картинок и у же в getView — смотреть — если в кэше етсь картинка для этого объекта, то ставим ее, если нет то ставим иконку — загружается.
сама-то статья достаточно неплохая, но вот с заголовком не совсем согласен
точно сформулировать, увы, сходу не смог, потому и не написал сразу.

не «многопоточность», а «правильная многопоточность — перенос тяжёлых операций в background thread», не «повышает эффективность», а «повышает отзывчивость UI»
Only those users with full accounts are able to leave comments. Log in, please.