Я действительно тяну себя за волосы, похоже, у меня серьезные проблемы с управлением памятью в приложении для iOS.
Вот случай: сначала я загружаю таблицу. Когда пользователь касается ячейки, она представляет сложное представление. Наибольшим объемом памяти для представления является то, что он загружает 20+ UIImage
с 500x500. В этом представлении есть две другие вкладки, загружающие список мультимедиа (эти UIImage
s, но затем в таблицу) и другую простую таблицу.
Когда я возвращаюсь к первому табличному виду, очевидно, более 250 КБ все еще выделяется в куче. Я знаю, что представление сложное, но нет никаких причин, чтобы поддерживать так много памяти. Ну и угадайте, что, когда я часто переключаюсь на представление, в конечном итоге приложение исчерпывает память и убивается.
Что я пытался решить:
- Исправлены все проблемы с анализом, поэтому в соответствии с этим утечки отсутствуют.
- Проверьте все
init
s еще раз для освобождения, используя autorelease
, где это возможно.
- Проверка всех утечек памяти с помощью Инструментов -> Утечки. Во время выполнения 6 я получаю не более 2 или 3 утечек.
- Last, Instruments -> Allocation, проверка кучи. Это то, что беспокоит меня, между двумя отмеченными кучами я получаю разницу в 250+ кБ. Я изучил это, используя подробные представления. Я не могу обдумать это: когда он указывает на один из моих методов / классов, я почти уверен, что все там либо выпущено, либо выпущено автоматически. Это также указывает на множество не моих (скажем,
QuartzCore
) методов / классов.
Кроме того, я не понимаю, почему autorelease
не является автоматическим выпуском. Я имею в виду, что иногда это выглядит как объект, помеченный для автоматического освобождения, выпущен слишком поздно Я не создал ни одного NSAutoreleasePool
, поэтому возможно ли, что пул сливается только после остановки среды выполнения? Как я могу периодически осушать бассейн (даже если он не мой).
Любая помощь очень ценится.
С уважением,
Reinder
Используется для проверки кучи: http://www.friday.com/bbum/2010/10/17/when-is-a-leak-not-a-leak-using-heapshot-analysis-to-find-undesirable-memory-growth/