Почему Android 4.0 / Ice Cream Sandwich выделяет столько памяти? - PullRequest
15 голосов
/ 10 февраля 2012

Я заметил, что на моем Galaxy Nexus android.content.res.Resources выделяет около 11 МБ. Я обнаружил это, когда находился в процессе профилирования, используя DDMS и опцию «Dump HPROF file». Итак, я потратил два часа, пытаясь выяснить, было ли это связано с чем-то из моего кода или вспомогательных библиотек. Я удалил все свои данные, кучу классов, все свои библиотеки и не увидел никаких изменений. После размещения точки останова в моем коде в начале метода действия onCreate() он показал, что выделение 11 МБ уже имеется.

После полной растерянности я решил подключить свой рутированный Nook Color под управлением CM7, чтобы посмотреть, что он сообщает о начальном использовании памяти для точно такого же приложения. Память наихудшего случая «Подозреваемый в проблеме», о которой сообщает МАТ, весит всего 896 КБ.

Является ли ICS настолько тяжелой? Я что-то здесь упускаю? Насколько я могу судить, мое приложение функционирует правильно, но использование кучи указывает на заполнение 97%, и я беспокоюсь о возможных сбоях.

Если это помогает, MAT указывал, что первичными объектами, потребляющими всю память, были растровые изображения, BitmapDrawables и NinePatchDrawables. Я не понимаю, откуда эти ассигнования.

1 Ответ

6 голосов
/ 13 февраля 2012

Перед сотой (<3.0), растровые изображения были выделены в собственной куче и не отображались в дампах кучи Dalvik, как показано в Eclipse MAT, и т. Д. Это собственное распределение все еще способствовало достижению максимальных пределов кучи Dalvik для приложения и по-прежнему вызывало сборка мусора должна выполняться примерно в правильное время при приближении к ситуации с нехваткой памяти. Это использование может быть измерено с помощью <code>Debug.getNativeHeapAllocatedSize().

Начиная с Android 3.0 (включая ICS), он теперь распределяет данные пикселей для растровых изображений в обычных байтовых массивах в куче Dalvik. Практическими эффектами этого являются улучшенное / упрощенное поведение сборки мусора для растровых изображений (поскольку их можно обрабатывать более ортодоксальным способом) и возможность отслеживать распределение растровых изображений в дампах кучи Dalvik.

Я не думаю, что фактическое использование памяти для конкретного приложения значительно отличается между предшествующими Honeycomb и более поздними выпусками, и что это просто вопрос альтернативной практики учета.

Анализ памяти для Android

Битовые карты в Android

...