Потенциальная утечка памяти в iOS

Так что я просто сделал приложение, которое загружает карту с некоторыми маркерами на ней. В приложении есть контроллер навигации, который переходит с главного экрана на карту и обратно. Во время запуска приложения на моем телефоне и симуляторе я заметил, что если бы я пошел туда и обратно между главным экраном и картой, объем памяти, который использовал приложение, просто продолжал расти на неопределенный срок. Есть ли способ помочь в процессе управления памятью (я знаю, что система использует ARC)? Я использую google maps sdk btw.Потенциальная утечка памяти в iOS

Спасибо!

источник

2013-12-26 CoderNinja

См WWDC видео 2013 [Исправление проблем с памятью] (https://developer.apple.com/wwdc/videos/?include=410#410) или WWDC 2012 видео [IOS Производительность приложения: память] (https://developer.apple.com/videos/wwdc/2012/?id=242). Они описывают категории проблем с памятью и иллюстрируют, как использовать Инструменты для их идентификации. В ответ на ваш вопрос может быть сильный справочный цикл, который мешает тому, чтобы материал освобождался, какая-то другая утечка, заброшенная память или плохо разработанный кэш. На основании того, что вы до сих пор говорили, невозможно сказать. – Rob

Вы используете сегу, чтобы вернуться на главный экран? Если это так, это ваша проблема. – rdelmar

Я просто разматываю segue (через кнопку обратной связи на UINavBar) – CoderNinja

Приводит ли приложение к изъятию из памяти и сбою?

Или он использует тонну памяти, получает предупреждение о памяти и сбрасывает память?

Таким образом, если это не вызывает сбои, это может привести к правильной работе.

источник

2013-12-26 01:52:19 bbum

Это может вести себя правильно, но маловероятно, и, конечно же, не то, что кто-то должен взять на веру. Это безответственное приложение для случайного использования памяти до тех пор, пока оно не закончится; если ничего другого вы, вероятно, излишне отбрасываете другие приложения. Похвально, что CoderNinja пытается понять, почему приложение потребляет память. ИМХО, единственными проблемами, которые попадают в категорию «не потеть», являются те _de mimimis_ утечки (буквально) всего несколько сотен байтов, которые могут вызвать некоторые стандартные элементы управления UIKit. Но что-нибудь существенное должно анализироваться в Инструментах и отслеживаться. – Rob

@Rob Я в основном согласен, поэтому я специально вызвал * это сбой * случай. То, с чем я не согласен, заключается в том, что плохое поведение приложения для кэширования до момента получения предупреждения о памяти, очистка указанного кеша, а затем переход. Это хорошо соответствует проектным параметрам системы и одной из целей. Плохо для активного фонового приложения, чтобы сделать это, конечно, но текущее приложение свободно потребляет столько ресурсов, сколько хочет дать пользователю лучший опыт. С учетом сказанного ** оптимизация абсолютно критическая **, как понимание того, что происходит! – bbum

Мы просто соглашаемся не соглашаться на достоинства подхода «использование памяти, пока вы не получите предупреждение».В этих видеороликах WWDC говорится о том, что неспособность смягчить знаки высокой воды может привести к (а) уменьшению многозадачности UX, если фоновые приложения регулярно выселяются; (б) большая фрагментация кучи; и (c) вам технически не гарантировано получать предупреждения о памяти. Несмотря на это, похоже, мы согласны с более широким моментом: я просто боялся, что ваш ответ можно интерпретировать как «эй, если он не сбой, тогда не волнуйся», но это звучит не так, как ты пытались сказать вообще. – Rob

Apple имеет обширную и хорошо документированную поддержку для диагностики этих проблем. См. "Locating Memory Issues in Your App".

источник

2013-12-26 01:54:14

Проверьте коды, используя блоки NSThreads и GCD. Если в некоторых местах создано много потоков, рекомендуется добавить блок autoreleasepool.

память может протекать в этих ситуациях:

Если вы пишете программу, которая не основан на структуру пользовательского интерфейса, такие как инструмент командной строки.
Если вы пишете цикл, который создает много временных объектов.
Если вы создаете дополнительный поток.

Для справки: Using Autorelease Pool Blocks

источник

2013-12-26 03:02:25 ziggear

Да, если вы вручную создаете свои собственные потоки, то вам обязательно нужно создать пулы автоопределений, но в противном случае '@ autoreleasepool' вряд ли будет плодотворным в решении проблем памяти, подобных описанным OP. Бассейны не изменяют то, что есть и что не освобождается, а просто обеспечивают небольшой контроль за сроками этих освобождений. – Rob

Я не думаю (думаю) я создаю любые темы? По крайней мере, не явно – CoderNinja

Потенциальная утечка памяти в iOS

ответ

Смежные вопросы