Утечка памяти с помощью [NSKeyedUnarchiver decodeObjectForKey]

Я бы предложил заменить эту строку:

venueIOList = [[decoder decodeObjectForKey:inKey] mutableCopy];

с участием:

ListClassName *decodedList = [decoder decodeObjectForKey:inKey];
self.venueIOList = decodedList;

Это делает понятным управление памятью decodedList. Рекомендуется назначать переменные экземпляра с помощью метода доступа (кроме методов инициализации). В вашей текущей реализации, если вы когда-нибудь вызовете readVenueArchiveFile: второй раз для того же объекта, вы получите утечку (как если бы у decodedList уже было значение). Более того, вы можете поместить логику копирования в свой метод доступа и забыть об этом, вместо того, чтобы запоминать mutableCopy каждый раз, когда вы назначаете новое значение (при условии, что есть веская причина для создания изменяемой копии?).

Снижение пикового объема памяти

В общем, рекомендуется избегать создания автоматически выпускаемых объектов.

[Большая часть этого абзаца изменена из этого вопроса.] Поскольку вы обычно (1 ) не имеют прямого контроля над своим временем жизни, автоматически выпущенные объекты могут сохраняться в течение сравнительно долгого времени и излишне увеличивать объем памяти, занимаемый вашим приложением. Хотя на настольных компьютерах это может не иметь большого значения, на более ограниченных платформах это может стать серьезной проблемой. Поэтому на всех платформах, и особенно на платформах с более ограниченными возможностями, по возможности настоятельно не рекомендуется использовать методы, которые могут привести к автоматическому выпуску объектов, и вместо этого рекомендуется использовать шаблон alloc / init.

Я бы предложил заменить это:

theData = [NSData dataWithContentsOfFile:inFile];

с участием:

theData = [[NSData alloc] initWithContentsOfFile:inFile];

затем в конце метода добавьте:

[theData release];

Это означает, что theData будет освобожден до выхода из метода. У вас должно получиться:

- (void)readVenueArchiveFile:(NSString *)inFile key:(NSString *)inKey
{
    NSMutableData *theData;
    NSKeyedUnarchiver *decoder;

    theData = [[NSData alloc] initWithContentsOfFile:inFile];
    decoder = [[NSKeyedUnarchiver alloc] initForReadingWithData:theData];
    ListClassName *decodedList = [decoder decodeObjectForKey:inKey];
    self.venueIOList = decodedList;
    [decoder finishDecoding];
    [decoder release];
    [theData release];

}

Это проясняет семантику управления памятью и максимально быстро освобождает память.

(1) Вы можете взять под контроль свои собственные локальные пулы с автоматическим выпуском. Подробнее об этом см. Руководство по программированию Apple Memory Management.

Не беспокойтесь о сохраненных счетах, беспокойтесь о балансе внутри метода. То, что вы делаете в этом методе, выглядит правильно, если предположить, что venueIOList является переменной экземпляра.

Чтобы немного расширить мой ответ: разархиватор может сохранить ваши данные во время операции разархивирования, а затем отправить данные -autorelease, когда это будет сделано, вместо -release. Поскольку это не то, что вы сделали, это не то, о чем вы должны заботиться.

Конечным источником информации об управлении памятью, связанной с подсчетом ссылок, по-прежнему остается, ИМО, «Держи меня, используйте Я, освободи меня " от Stepwise.

Ваш код правильный; утечки памяти нет.

theData = [NSData dataWithContentsOfFile:inFile];

эквивалентно

theData = [[[NSData alloc] initWithContentsOfFile:inFile] autorelease];

В этот момент theData имеет счетчик ссылок 1 (если меньше, он будет освобожден). В какой-то момент в будущем счетчик ссылок будет автоматически уменьшен пулом автозапуска.

decoder = [[NSKeyedUnarchiver alloc] initForReadingWithData:theData];

Объект декодера хранит ссылку на theData, которая увеличивает его счетчик ссылок до 2.

После возврата из метода пул автозапуска уменьшает это значение до 1. Если вы отпустите Data в конце этого метода, счетчик ссылок станет 0, объект будет освобожден, и ваше приложение выйдет из строя, когда вы попытаетесь его использовать.