Линукс из памяти, убивающий мое приложение для Android.

Question

Это происходит во встроенной системе, использующей пользовательскую сборку платформы Android 4.0.2. Я вижу, что одно из наших приложений для приложений для Android растет примерно до 400 МБ (rss-размер, когда вызывается «ps») и убивается убийцей Linux OOM. Платформа Android была настроена с максимальным размером кучи, установленным на 62M. Я не знаю, как Dalvik VM позволил деятельности расти до 400 МБ.

Не должно ли приложение извлекать исключения из памяти Java, когда куча достигает 60 МБ? Мы не видим эти исключения Java в журналах logcat или в трассировках anr.

Мы реализовали выборочную активность, которая последовательно распределяет байтовые массивы и задает каждый байт для фиктивного значения. Мы видим исключения Outofmemory, когда активность распределяется около 60 МБ.

Существуют ли пути выделения в android, которые не учитываются в бюджете кучи? Действие отображает растровые изображения, загруженные с веб-сайта.

Ниже приведены результаты "getprop" на нашей платформе.

$ adb shell getprop | grep -i heap

Я ценю любые указатели.

Благодаря

Отредактировано: Примечание: Ниже выводится пс. Pss и Uss около 316M, что выше.

 
          PID  Vss  Rss  Pss Uss cmdline 
logcat: hd[0]: pexecd(65): 982 351512K 351316K 326300K 316632K mytest.home^M 
logcat: hd[0]: pexecd(65): 660 679916K 61044K 57200K 56952K ./videngine^M 

RAM: 741764K total, 20320K free, 2148K buffers, 80104K cached, 24964K shmem, 10368K slab 

Answer 1

Прямые распределения в собственном коде не учитываются в общей сумме кучи Java. Могут быть и другие возможности (возможно, страницы отображаются и заполнены из файлов?).

Если у вас есть специальная сборка Android, вы можете установить значения убийцы OOM, чтобы сохранить собственное приложение.

Answer 2

Я вижу один из наших андроид приложений деятельности, растущих около 400MB (размер RSS, когда «пс» вызывается)

Цитирую Dianne Hackborn, о выходе ps на Android: «ВСС и Rss-столбцы в основном представляют собой шум (это прямое адресное пространство и использование ОЗУ в процессе, где, если вы добавляете объем использования ОЗУ в процессы, вы получаете смехотворно большое число) «

Я сердечно призываю вас читать her epic SO answer on measuring an app's memory footprint. Примечательно, что Rss не играет никакой роли в ее анализе, помимо цитируемой мной цитаты. Следовательно, я бы предложил не беспокоиться о Rss и сосредоточиться на других показателях.

Answer 3

Вот что вы можете сделать, чтобы понять, какую память использует ваше приложение.

Перейти к DDMS, и создать дамп кучи, нажав на иконку, которая выглядит следующим образом:

Следующих конвертировать HPROF в андроида формата обычного формата HPROF с помощью инструмента HPROF-сопу в androir-SDK/tools.

Затем откройте кучу кучи с Eclipse Memory Analyser (MAT) и посмотрите на дерево доминанта, там вы увидите список переменных, которые ваше приложение вынуждает Хранитель мусора Dalvik (GC) сохранить. Щелкните правой кнопкой мыши на них и перейдите к «Путь к корню GC» и «Исключить слабые ссылки», покажут ссылки, которые поддерживают эти объекты. Посмотрите, есть ли у вас какие-либо устаревшие ссылки, которые были сохранены как утечка памяти.

Вы можете посмотреть this video для подробного поиска утечки памяти в приложении для Android.