Автоматический подсчет ссылок (Automatic Reference Counting, ARC) для языка Objective-C был представлен компанией Apple еще в 2011 году для iOS 4.0 и выше, Mac OS X 10.6 и выше, с использованием xCode 4.2 и выше. И, хотя всё больше библиотек, фреймворков и проектов сегодня используют ARC, до сих пор среди программистов встречается либо неприятие этой технологии, либо eё неполное понимание. Опытные программисты, привыкшие к retain/release, иногда считают, что они лучше и эффективней справяться с подсчетом ссылок, чем это за них сделает компилятор, а новички, начищающие сразу использовать ARC, полагают, что им не надо вообще думать об управлении памятью, и всё сделается магическим образом само.
ARC — не сборщик мусора
В отличае от сборщика мусора, ARC не занимается автоматическим освобождением памяти от отработанных объектов и не запускает никаких фоновых процессов. Всё что он делает — это при сборке приложения анализирует и расставляет retain/release в компилируемый код за программиста.
Вы не можете напрямую вызвать retain, release, retainCount, autorelease.
Можно переопределить dealloc, но вызывать [super dealloc] не надо, за вас это сделает ARC, а так же освободит при этом все property и instance variables, которые в этом нуждаются. Переопределять dealloc бывает необходимо для того, чтобы, например, отписаться от нотификаций, удалить объект из иных служб и менеджеров, на которые он подписан, инвалидировать таймеры, а так же чтобы освободить не Objective-C объекты.
Код без ARC:
- (void)dealloc
{
[_someIvar release];
[_anotherIvar release];
[[NSNotificationCenter defaultCenter] removeObserver:self];
[super dealloc];
}
Код с ARC:
- (void)dealloc
{
[[NSNotificationCenter defaultCenter] removeObserver:self];
}
Сильные и слабые ссылки
Вместо атрибутов retain и assign для properties в ARC используются атрибуты strong и weak (__strong и __weak для локальных переменных и ivars). Это не совсем их аналоги, но об этом позже. Атрибут strong используется по умолчанию, так что указывать его явно не обязательно.
@property AnyClass *strongReference; //(atomic, strong) по умолчанию
@property (nonatomic, weak) id delegate;
Properties, переменные которых ссылаются на объекты «вверх» по иерархии и делегаты должны быть слабыми, чтобы избежать циклических ссылок.
Поскольку локальные переменные по умолчанию сильные (__strong), возможны такие конструкции в коде:
NSDate *originalDate = self.lastModificationDate;
self.lastModificationDate = [NSDate date];
NSLog(@"Last modification date changed from %@ to %@", originalDate, self.lastModificationDate);
Объект, сохраненный в переменной originalDate будет жив до тех пор, пока ARC не найдет последнюю строку, где используется эта переменная, а затем тут же ее освободит (подставит release).
Для создания слабой ссылки используется атрибут __weak:
NSDate * __weak originalDate = self.lastModificationDate;
self.lastModificationDate = [NSDate date];
В данном примере originalDate может перестать существовать уже на второй строчке, если на этот объект больше нет сильных ссылок.
Важная и полезная особенность ARC: сразу после деаллокации слабые и сильные ссылки обнуляются, то есть становятся равными nil.
А поскольку в Objective-C nil может принимать любые сообщения, проблемы с EXC_BAD_ACCESS уходят в прошлое. Это и есть отличие от атрибутов retain/assign. Подобное происходит и при объявлении объектов: они неявно инициализируются nil'ом. Полезным приёмом является кэширование слабых property в сильных локальных переменных, чтобы быть уверенным, что объект будет жив необходимое время:
- (void)someMethod {
NSObject *cachedObject = self.weakProperty;
[cachedObject doSomething];
[cachedObject doSomethingElse];
}
По этой же причине при проверке слабых property на nil, например, делегатов, нужно их кэшировать:
id cachedObject = self.delegate;
if (cachedObject) {
[self.delegate doSomeTask];
}
cachedObject = nil;
Присваивание кэшированному объекту nil убирает сильную ссылку, и если на него больше нет других сильных ссылок, объект будет деаллоцирован.
В редких случаях нужно, чтобы ссылки на объект после его уничтожения не обнулялись. Для этого существует атрибут unsafe_unretained:
@property (unsafe_unretained) NSObject *someProperty;
NSObject *__unsafe_unretained someReference;
Autorelease
Объекты, созданные с помощью статических методов (например: [NSData data...], [NSArray array...] и т. д.) и литералов (@«string», @42, @[], @{} ) больше не авторелизные. Время жизни таких обьектов задается только сильными ссылками на них.
Существует атрибут __autoreleasing, который, согласно документации, рекомендуется использовать для двойных указателей (* id) в случае, если необходимо передать результат в параметр.
NSError *__autoreleasing error;
BOOL ok = [database save:&error];
if (!ok) {
//обрабатываем ошибку
}
Tогда метод save должен иметь следующую сигнатуру:
- (BOOL)save:(NSError * __autoreleasing *) error;
Это гарантирует сохранность созданного внутри метода объекта. Если объявить переменную без этого атрибута, то компилятор создаст временную авторелизную переменную, которую передаст в метод:
NSError * error;
NSError *__autoreleasing tmp;
BOOL ok = [database save:&tmp];
error = tmp;
NSAutoreleasePool теперь недоступен для прямого использования. Вместо него предлагается использовать директиву @autoreleasepool {}. При входе в такой блок состояние пула сохраняется, при выходе восстанавливается, освобождая все объекты, созданные внутри. Рекомендуется использовать @autoreleasepool в циклах, если создается большое количество временных обьектов.
for (id object in hugeArray) {
@autoreleasepool {
//использование временных объектов
}
}
Блоки
Блоки по-прежднему необходимо копировать.
//property
@property (nonatomic, copy) SomeBlockType someBlock;
//локальная переменная
someBlockType someBlock = ^{NSLog(@"hi");};
[someArray addObject:[someBlock copy]];
О циклических ссылках компилятор предупредит:
warning: capturing 'self' strongly in this block is likely to lead to a retain cycle
[-Warc-retain-cycles,4]
SomeBlockType someBlock = ^{
[self someMethod];
};
Когда блок будет скопирован, он также захватит self, если в нем используются instance varisbles.
Чтобы избежать таких случаев, нужно создать слабую ссылку на self:
__weak SomeObjectClass *weakSelf = self;
SomeBlockType someBlock = ^{
SomeObjectClass *strongSelf = weakSelf;
if (strongSelf) {
[strongSelf someMethod];
}
};
Необходимо заботиться о любых объектах в блоках, объявленных снаружи, используя атрибут __weak.
Строим мосты
Как же быть с объектами CoreFondation? Для них ручной подсчет ссылок никто не отменял. Прямой каст теперь не работает, для этого есть несколько специальных ключевых слов.
id my_id;
CFStringRef my_cfref;
NSString *a = (__bridge NSString*)my_cfref; // пустой каст
CFStringRef b = (__bridge CFStringRef)my_id; // пустой каст
NSString *c = (__bridge_transfer NSString*)my_cfref; // -1 к количеству ссылок CFRef
CFStringRef d = (__bridge_retained CFStringRef)my_id; // вернет CFRef +1
- __bridge не делает ничего с количеством ссылок, просто приведет объект к нужному типу.
- __bridge_transfer нужен для смены типа объекта с CF на Objective-C. ARC декрементирует счетчик ссылок CF, так что убедитесь, что он больше нуля.
- __bridge_retained нужен для смены типа объекта с Objective-C на CF. Он вернет CF-объект c счетчиком ссылок +1. Не забудьте освободить объект вызовом CFRelease().
Заключение
Используйте ARC. Это проще, безопаснее и сэкономит вам время и нервы.
Ссылки
Раздел документации Clang об ARC
Статья о быстродействии ARC
Автор: alamantrah
