Использование инструментов для поиска утечек памяти
Я пытался прочитать почти каждый приличный учебник в интернете, но до сих пор не могу понять, что на самом деле происходит здесь:
У меня есть "скрыть системные библиотеки" и "инвертировать дерево вызовов", но я не понимаю, как найти фактический код, ответственный, например, за эту утечку. Любые советы приветствуются. Может быть я упускаю что-то очевидное. Я получаю сотни утечек, однако я использую weak в замыканиях у меня нет классов, ссылающихся на каждый других и т. д. Но, похоже, я упускаю что-то фундаментальное.
2 ответов
проблема, показанная на скриншоте, заключается в том, что инструменты не могут найти символы отладки вашего приложения. Приборы показывают адреса памяти вместо имен функций. Вы не сможете найти источник утечек памяти в инструментах без имен функций, даже если вы инвертируете дерево вызовов и скрываете системные библиотеки.
убедитесь, что ваш проект генерирует символы отладки. Убедитесь, что для параметра создания символов отладки установлено значение Да. Если ваш проект генерируя отладочные символы, инструменты могут не найти файл dSYM, содержащий отладочные символы. В меню Инструменты выберите инструмент > дерево вызовов > найти dSYM. DSYM обычно находится в том же каталоге, что и пакет приложений версии выпуска. Дополнительная информация приведена в следующей статье:
утечек памяти может быть трудно отследить. Это, вероятно, будет трудоемкий процесс, поэтому будьте готовы. В конце концов, обычно существует много проб и ошибок при отладке утечек памяти. Инструмент "утечки памяти" фактически обнаружил только одну утечку для меня в прошлом. Мне всегда приходилось отслеживать их самостоятельно, используя инструмент "распределения".
одна из вещей, которая помогла мне в прошлом, - это начать с попытки выяснить, какие объекты на самом деле утечка. Нажмите на инструмент распределения (строка выше "проверка утечки"). Теперь попробуйте отсортировать по количеству освобожденных объектов или объему используемой памяти. Посмотрите, есть ли какие-либо объекты, которые имеют счетчик 0, выпущенный, когда они не должны торчать. Посмотрите, есть ли тип объекта, который принимает аномальный объем памяти.
утечки памяти всегда из-за ошибок разработчика с управлением памятью. Есть некоторые незначительные утечки памяти, которые существуют на нижний уровень частные API в Foundation и UIKit. На этих более низких уровнях они имеют дело с гораздо более ручным управлением памятью, поэтому гораздо проще совершать крошечные ошибки. Вы ничего не можете с этим поделать, но они относительно редки.
Если ваше приложение работает нормально, вам, возможно, не придется беспокоиться об их исправлении. Существует некоторый анализ затрат и выгод, который вы хотите сделать здесь. Если это не влияет на производительность или стабильность, это инвестиции времени в их исправление прямо сейчас стоит незначительных преимуществ, которые он предоставит вам и вашим пользователям?
однако не стоит ничего, что утечки памяти могут сложить, поэтому, если пользователь имеет ваше приложение открытым в течение длительного времени, объем просочившейся памяти в конечном итоге станет проблемой, если вы продолжите утечку больше объектов с течением времени. В какой-то момент приложение рухнет, и пользователю придется повторно открывать. Но если ваши утечки памяти достаточно малы, что это не становится проблемой, если приложение не было открыто в течение нескольких часов, это действительно очень большая проблема в любом случае? С твоей стороны это всегда осуждение.