Очень высокое потребление памяти на Nexus 7 с Android Jelly Bean

У меня есть приложение, которое потребляет много памяти - обрабатывает большие растровые изображения. Я настроил приложение, используя хорошо известные методы обработки таких растровых изображений (пожалуйста, не указывайте ссылки на руководства в ответах...), чтобы оно работало нормально без каких-либо OutOfMemoryError исключений, но только на устройствах с HC и ICS, на Jelly Bean одно и то же приложение имеет почти на 80 % более высокое потребление памяти, что приводит к плохому взаимодействию с пользователем, приложение отстает и работает медленно.

Я подготовил простой тест, просто создал простейшее Android-приложение, используя шаблон в Eclipse; приложение имеет только одно действие с фоновым растровым изображением (1280 x 800). На устройстве с Android 3.1 (Asus A500) выделяется:

01-23 12:28:02.402: D/dalvikvm(31706): GC_FOR_ALLOC freed 65K, 4% free 6559K/6787K, paused 17ms
01-23 12:28:02.402: I/dalvikvm-heap(31706): Grow heap (frag case) to 10.355MB for 4096016-byte allocation
01-23 12:28:02.432: D/dalvikvm(31706): GC_CONCURRENT freed 1K, 3% free 10558K/10823K, paused 1ms+2ms

На Nexus 7 с JellyBean 4.2.1 выделяется:

01-23 12:13:49.740: D/dalvikvm(23815): GC_FOR_ALLOC freed 84K, 4% free 7464K/7700K, paused 18ms, total 18ms
01-23 12:13:49.750: I/dalvikvm-heap(23815): Grow heap (frag case) to 11.338MB for 4096016-byte allocation
01-23 12:13:49.770: D/dalvikvm(23815): GC_FOR_ALLOC freed 1K, 3% free 11463K/11704K, paused 23ms, total 23ms
01-23 12:13:49.800: D/dalvikvm(23815): GC_CONCURRENT freed <1K, 3% free 11463K/11704K, paused 2ms+2ms, total 23ms
01-23 12:13:49.900: D/dalvikvm(23815): GC_FOR_ALLOC freed <1K, 3% free 11463K/11704K, paused 12ms, total 13ms
01-23 12:13:49.920: I/dalvikvm-heap(23815): Grow heap (frag case) to 18.259MB for 7259056-byte allocation
01-23 12:13:49.940: D/dalvikvm(23815): GC_FOR_ALLOC freed 0K, 2% free 18552K/18796K, paused 16ms, total 16ms
01-23 12:13:49.960: D/dalvikvm(23815): GC_CONCURRENT freed <1K, 2% free 18552K/18796K, paused 3ms+2ms, total 17ms

Итак, у меня есть два вопроса:

1, почему приложение потребляет столько памяти при использовании только одного битмапа на фоне своей основной деятельности?

2, почему устройство с JellyBean потребляет почти на 80% больше памяти при запуске того же приложения?

EDIT1:

Все устройства имеют одинаковое разрешение экрана: 1280 x 800 px.


android android-4.2-jelly-bean
person vitakot    schedule 23.01.2013    source источник
comment
С Jelly bean была улучшена плавность пользовательского интерфейса. Может ли это быть достигнуто за счет двойной буферизации определенных изображений и/или областей отображения?   -  person Robert    schedule 23.01.2013
comment
Глядя на документы Bitmap с целевым API, установленным на 15, два набора методов становятся светло-серыми, что может повлиять на использование памяти: isPremultiplied() и hasMipMap(). Может быть, один из них меняет значение по умолчанию с false на true в обновлении платформы?   -  person Barend    schedule 23.01.2013

Ответы (1)


arrow_upward
1
arrow_downward

Я сталкиваюсь с тем же. К сожалению, я подозреваю, что это вызвано тем, что последние версии Android будут пытаться максимально использовать 3D-ускоритель — они берут копию вашего изображения и передают его на 3D-ускоритель. when затем используется для рендеринга фактических пикселей, которые видит пользователь. Вот почему вы видите более высокое потребление памяти.

А что с этим можно сделать - к сожалению, не очень. Это более высокое использование памяти приводит к гораздо более плавному пользовательскому интерфейсу (это проектное масло, которое появилось в Android 4.1). Если вы уже изучили различные руководства, такие как Google, эффективное отображение растровых изображений тогда все, что я могу предложить, это попробовать включить largeHeap в элемент приложения манифеста - вот что сработало для меня.

Кроме того, в зависимости от того, как работает ваше приложение, может быть возможно повторно использовать растровые изображения. В этом видео DevBytes от Google объясняется, как это сделать.

person Luke Sleeman    schedule 03.02.2013