Понимание Инструмента для проверки утечки памяти - iPhone
Пока Вы указываете оба ключа в запросе, не имеет значения, что приказывает, чтобы они имели в запросе, и при этом не имеет значения, что приказывает, чтобы Вы указали их в индексе.
Однако не маловероятно, что у Вас иногда будут только один или другие из ключей. Если у Вас иногда есть id_1 только, то это должно быть первым (но Вам все еще только нужен один индекс).
, Если Вы иногда имеете один, иногда другой, иногда оба, Вам будут нужны один индекс с обоими ключами и второй (групповой) индекс с одним полем - более выборочные из этих двух ключей - и основной сводный индекс должны запуститься с другого ключа.
5 ответов
Не обращайте внимания на цвета, в этом случае [DashBoard viewDidLoad] является источником утечки, что-то в том, как он инициализирует URLConnection (возможно, вы не освободили его, когда соединение было завершено?)
Теперь, чтобы ответить на другие ваши вопросы:
- Почему мы должны устранить все утечки? - даже одна утечка может забить iPhone?
Да. Отчасти причина заключается не только в том, что вам просто не хватит памяти, но и в том, что для всего телефона достаточно памяти, поэтому приложение сторожевого пса постоянно отслеживает ваше приложение и закроет его раньше, если увидит использование памяти. только когда-либо растет ...
- Почему iPhone позволяет утечкам оставаться в памяти? / почему сборка мусора не выполняется автоматически после завершение работы приложения?
Вся память вашего приложения освобождается, когда приложение завершает работу.
- Если я попытаюсь освободить объекты, которые должен быть освобожден в соответствии с инструменты, Мое приложение завершается ненормально. Если я не dealloc, мое приложение запускается отлично, как?
Здесь я не могу помочь, вам действительно нужно больше узнать о цикле сохранения / освобождения памяти ... если вы освобождаете объект, у которого счетчик удержания равен 0, приложение вылетает, потому что объект
- Почему вам предлагается подождать вид до 10 и более секунд, если есть утечка, утечка будет обнаружены инструментами?
Потому что инструменты работают по принципу дискретизации памяти время от времени, поэтому инструментам может потребоваться немного времени, чтобы прочитать память после действия.
Прежде всего, объекты в стеке окрашены в зависимости от библиотеки, из которой они взяты, поэтому в нем не так много информации.
Во-вторых, вместо того, чтобы беспокоиться о том, сколько утечек iPhone может выдержать, я бы сосредоточился на том, чтобы он не протекал.
Чтобы найти утечки, есть пара вариантов:
- Используйте статический анализатор CLANG при создании проекта
- Посмотрите на утечки вручную. Вы должны всегда следовать Правилам управления памятью: если вы
alloc,сохраняетеиликопируетеобъект (включая использование@property (сохранить)или(копия)), вы должнывыпуститьилиавтоматическиего.
Цвета представляют различные библиотеки, через которые проходит стек вызовов.
Утечка вызвана фреймом в вашем коде, который выполнил распределение, даже если фактическое распределение происходит глубоко в библиотеке ОС. Инструменты показывают вам точно , где была выделена утечка памяти. Вам нужно будет выяснить, какая строка в вашем коде привела к утечке выделения, который будет одним из фреймов в стеке справа.
Настоящий iPhone не имеет много оперативной памяти, доступной вашему приложению. Я склонен консервативно оценивать около 25 МБ ОЗУ для работы моего приложения. Любая утечка, какой бы небольшой она ни была, может потопить пресловутый корабль, если использовать код достаточно.
Найдите имя своего приложения в расширенном представлении стека. Распределение памяти обычно отображается в конце, поэтому вы точно знаете, какая библиотека отвечает за выделение памяти. Таким образом, вы должны проследить от строки, где находится ваш код, вниз до конца. Цвета просто упрощают отслеживание строк кода, относящихся к одним и тем же библиотекам. Вызовы одной и той же библиотеки будут окрашены в один цвет.
Что касается самой трассировки утечки. Сначала перейдите к вызову вашего приложения, дважды щелкнув строку в расширенном представлении, и попытайтесь понять, что именно происходит. Иногда вы можете заменить протекающий вызов на не протекающий. Например, я использовал вызов imageNamed для получения изображений из пакета, приложение постоянно вылетало из-за нехватки памяти. Я просто погуглил утечки imageNamed и нашел очень полезную статью о том, как реализовать кэш изображений в моем приложении. Действительно, утечка API imageNamed. В iphone SDK есть утечка API.
Также попробуйте проверить, как вы работаете с распределением / сохранением / освобождением и т. Д., Освобождаете ли вы выделенную память или автоматически освобождаете ее.
Удачи в вашей детективной работе.
У меня тоже есть проблемы с утечками в инструментах. Сегодня я впервые запустил свое приложение с использованием утечек и обнаружил несколько утечек. Утечки, которые не должны быть утечками, потому что нет никакого способа для них, если только какой-то магический код не выполняет и не увеличивает счетчик retain для моих объектов. Я понимаю рекомендации по управлению памятью, знаю, как использовать пулы автоосвобождения и т.д. Но даже пустое приложение, основанное на представлении, содержит утечки, если я помещу на него несколько элементов управления. И просто щелкнуть по нему 2-3 раза. Попробуйте. Я не совсем понимаю, какую информацию пытаются предоставить инструменты. Являются ли эти "утечки" действительно утечками, или это просто подозрительные вещи для приложения instruments? Должно ли пустое приложение без пользовательского кода, только несколько элементов управления, размещенных на пустом представлении утекать в память?