Управление памятью в Objective C [дубликат]

Вот:

Управление памятью приложения является процессом выделения памяти во время времени выполнения Вашей программы, использование его и освобождение его, когда Вы сделаны с ним. Правильно написанная программа использует как можно меньше памяти. В Objective C это может также рассматриваться как способ распределить владение ресурсов ограниченной памяти среди многих частей данных и кода. Когда Вы закончили работать через это руководство, у Вас будет знание, необходимо управлять памятью приложения путем явного управления жизненным циклом объектов и освобождения их, когда они больше не необходимы.

Хотя управление памятью обычно рассматривают на уровне отдельного объекта, Ваша цель состоит в том, чтобы на самом деле управлять графами объектов. Вы хотите удостовериться, что у Вас больше нет объектов в памяти, чем Вам на самом деле нужно...

Objective C является просто надмножеством C. Что-либо, что можно сделать в C, допустимо в Objective C.

Если это - массив, не стесняйтесь выполнять итерации с указателем. Эквидистантными антенными решетками все еще управляет C. Если это - NSArray, прочитайте документы NSArray. Если они говорят, чтобы сделать это конкретный путь, сделайте это тот путь. При записи для OS X сделайте это книгой.

Можно, конечно, использовать массивы и сделать собственное управление памятью. Самый большой компонент - то, что при создании чего-нибудь, которое это - подкласс NSObject, и Вы создаете его с [XXX выделений] метод, или если Вы получаете его из другой копии с [xxx копия], затем у Вас есть обязанность соответствовать этому связанному выпуску.

Если получают переменную откуда-либо и намереваются иметь в наличии его для больше, чем непосредственное использование, которое Вы выполняете через, то удостоверьтесь, что Вы вызываете [... сохраняют] на нем.

Ссылка http://developer.apple.com/documentation/Cocoa/Conceptual/MemoryMgmt/MemoryMgmt.html имеет все подробности и является определенно первым местом для чтения.

Вот правила:

1. Если Вы создаете объект путем вызова alloc или copy, Вы владеете им, и должен release это, когда Вы сделаны.
2. Если Вы не создали объект, но хотели, чтобы он гарантировал, что слоняется поблизости, прежде чем управление возвращается к циклу выполнения (или, для хранения вещей простыми, возвраты метода), отправьте ему a retain обменивайтесь сообщениями и затем release это позже, когда Вы сделаны.
3. Если Вы создаете объект и хотите возвратить его из своего метода, Вы обязаны выпустить его, но Вы не хотите уничтожать его, прежде чем вызывающая сторона получит шанс видеть его. Таким образом, Вы отправляете его autorelease вместо этого, который помещает его в Пул Автовыпуска, который освобожден, после того как управление возвращается к циклу событий программы. Если никто больше не сохранит объект, то он будет освобожден.

Относительно массивов Вы свободны сделать что-то вроде этого:

NSObject *threeObjects[3];

threeObjects[0] = @"a string";
threeObjects[1] = [NSNumber numberWithInt:2];
threeObjects[2] = someOtherObject;

Причины использовать NSArray так или иначе:

• NSArray будет заботиться о сохранении объектов, как Вы добавляете их и выпуск их, поскольку Вы удаляете их, тогда как в простом массиве C необходимо будет сделать это сами.
• При передаче массива в качестве параметра NSArray может сообщить о количестве объектов, которые это содержит с простым массивом C, необходимо будет провести количество также.

• Смешивание значений квадратной скобки на одной строке чувствует себя странным:

  [threeObjects[0] length]

Обычно не полезно повторить основные правила управления памятью, так как почти неизменно Вы делаете ошибку или описываете их не полностью - как имеет место в ответах, предоставленных 'heckj' и 'benzado'...

Фундаментальные правила управления памятью предоставлены в документации Apple в Правилах управления памятью.

Кстати ответа из 'www.stray-bits.com': заявление, что объекты, возвращенные из "невладения" методами, "автовыпущены", также в лучшем случае вводит в заблуждение. Вы не должны обычно думать с точки зрения того, "автовыпущено" ли что-то, но просто рассмотрите правила управления памятью и определите, владеете ли в соответствии с теми конвенциями Вы возвращенным objet. Если Вы делаете, необходимо оставить владение...

Один контрпример (к размышлению с точки зрения автовыпущенных объектов) - когда Вы считаете проблемы производительности связанными с методами такой как stringWithFormat:. Начиная с Вас обычно (1) не имеют прямого управления за время жизни этих объектов, они могут сохраниться в течение сравнительно долгого времени и излишне увеличить объем потребляемой памяти Вашего приложения. Пока на рабочем столе это может не иметь большого значения, на более ограниченных платформах это может быть значительной проблемой. Это поэтому считают лучшей практикой на всех платформах для использования alloc/init шаблон, и на более ограниченных платформах, где возможный Вы сильно отговорены использовать любые методы, которые привели бы к автовыпущенным объектам.

(1) Можно взять на себя управление при помощи собственных локальных объединений автовыпуска. Для больше на этом, см. Руководство по программированию управления памятью Apple.

Вероятно, также полезно отметить, что для класса обменивается сообщениями как NSString + (NSString *) stringWithFormat: (в основном, сообщения помощника, которые выделяют объект для Вас вместо того, чтобы требовать, чтобы Вы выделили объект сами), полученный объект автовыпущен, если Вы явно не сохраняете его.

Что-то, чтобы знать при использовании массива C-стиля, чтобы хранить объекты и Вы решаете использовать сборку "мусора", необходимо будет выделить ту память с NSAllocateCollectable(sizeof(id)*size, NSScannedOption) и тег та переменная как __strong.

Таким образом, коллектор знает, что содержит объекты и будет рассматривать объекты, хранившие там как корни в течение того времени жизни переменных.

Например, действительно ли это абсолютно недопустимо, чтобы использовать указатель на объект Objective C и рассматривать его как массив?

Если это не массив, то да.

Вы вынуждены использовать NSArray и NSMutableArray для структур данных?

Нет. Можно использовать массивы C, и необходимо смочь использовать C++ векторы STL (хотя я не использую C++, таким образом, я не знаю специфических особенностей как).

Но нет никакой причины не использовать NS{,Mutable}Array. Бойтесь не платформ Какао, поскольку они - Ваш друг.

И не забывайте другие типы набора, такой как NS{,Mutable}Set и NS{,Mutable}Dictionary.