Android: растровые изображения и производительность

Question

Я читал много сообщений здесь о SO о загрузчиках изображений, растровых изображениях и асинтаксах для загрузки и отображения изображений. Когда вы работаете с небольшим количеством растровых изображений, мой загрузчик изображений в порядке, он загружает изображение и отображает его пользователю, но он также сохраняет WeakReference в HashMap, который я использую в качестве кеша, а также сохраняю изображение на SD-карте в случае, если пользователю необходимо, чтобы изображение отображалось позже, без необходимости его повторной загрузки. Пока все в порядке, мои приложения работали полностью нормально.

Теперь я начал работу над новыми приложениями, где число изображений, отображаемых на одном экране, больше 50 (например), в этом случае экран не будет прокручиваться плавно, и я также найду FPS ниже чем обычно, обеспечивая плохую работу пользователей. У меня заканчиваются идеи о том, что делать дальше. У кого-нибудь есть совет?

Использование WeakReference вместо WeakReference улучшает использование памяти, а также пользовательский интерфейс?

Я не масштабирую растровые изображения, поскольку я загружаю их, так как они уже являются миниатюрами, следует ли их масштабировать? Изображения могут занимать не более 50% ширины экрана.

В настоящее время моя основная забота не связана с временем загрузки, моя забота касается количества отображаемых растровых изображений и того, насколько гладкой должна быть прокрутка. Я не использую gridview, я использую компонент каменной кладки от http://code.google.com/p/android-masonry

Какие предложения у вас есть для меня? С чего начать?

Благодаря Тьяго

Answer 1

Вы использовали DDMS на приложение еще? Является ли приложение из Мусорной коллекции?

У вас ограниченный объем памяти, а растровые изображения трудно справиться. Вы отмечаете в своих комментариях, что кеш - это не проблема, но если у вас мало памяти, вы не хотите больше размещать растровые изображения, чем вам нужно. Вы можете создавать только 50 или около того изображений, но ваш кеш может содержать 100 растровых изображений и потребляющую память. Я бы не отказался от WeakReference, решив проблему для вас, особенно с растровыми изображениями. Вы сделали приблизительную оценку того, сколько памяти потребляет 50 изображений?

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

Еще одна вещь, на которую стоит обратить внимание - BitmapFactory.Options.inPreferredConfig. Попробуйте потянуть все ваши изображения на RGB_555, если сможете. По умолчанию используется ARGB_8888, который в два раза больше, чем RGB_555.

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

Answer 2

Посмотрите новый класс на Андроид Обучение: Displaying Bitmaps Efficiently.В нем обсуждаются многие вопросы, связанные с вашими вопросами, такими как использование памяти, масштабирование изображений, плавная прокрутка (только для таких компонентов, как ListView и GridView), и использование кеша памяти и диска для повышения производительности. В частности, в этом разделе (от Caching Bitmaps):

Примечание: В прошлом популярный реализация кэш-памяти был SoftReference или кэш растровый WeakReference, однако это не рекомендуется. Начиная с Android 2.3 (API уровня 9) сборщик мусора более агрессивен, собирая мягкие/слабые ссылки, что делает их довольно неэффективными. Кроме того, до Android 3.0 (уровень API 11) данные резервного копирования растрового изображения были сохранены в собственной памяти, которая не была выпущена предсказуемым образом, что потенциально может привести к кратковременному превышению пределов памяти и сбоя.

Как упомянуто в другом ответе, вместо этого предпочтительным является кеш сильных ссылок, используя что-то вроде класса LruCache.