Нативная куча продолжает расти на регулярные суммы, хотя куча java держится устойчиво, затем фатальный сигнал 6 crash

Question

Приложение для Android загружает большое количество изображений с помощью Universal Image Loader в серии фрагментов. Я проверил hprofs в Memory Analyzer и после исправления различных утечек я больше не вижу. Размер кучи javascript для DDMS немного увеличивается примерно до 16, но пока я проверяю Debug.getNativeHeapAllocatedSize и вижу, что раздуваются примерно на 90 МБ при замене каждого фрагмента. Около 600 МБ нативной кучи, приложение выдает фатальный сигнал 6 SIGABRT, как правило, при попытке создания пользовательского интерфейса с высоким качеством изображения при возврате данных. Но никогда не бывает ошибок в памяти.

Является ли прирост кучи причиной причинения фатального сигнала 6 аварии, или это застопорился UI? И какой лучший способ отлаживать продолжающееся увеличение родной кучи?

Answer 1

Изображения были красной селедкой. Фатальный 6 действительно был связан с постоянно растущей кучей.

Помимо множества изображений приложение создало множество пользовательских текстовых элементов для каждого экрана, а у предыдущего разработчика был вызов Typeface.createFromAsset в init для этих настраиваемых текстовых элементов. Так тысячи шрифтов были добавлены в кучу. Жестко создавая статический шрифт, только фиксировав это.

Для отладки наилучшим подходом было удаление подозреваемого. После нескольких часов работы с изображениями и настроек конфигурации UniversalImageLoader я взял загрузку изображений (должен был сделать это первым) и все еще видел, что куча вышла из-под контроля - таким образом, пришлось искать в другом месте, а затем было найдено несколько минут.