Objective C. Практика. События и «мертвые» объекты

Многие, вероятно, знают, что при работе с событиями изменения свойств с помощью key-value observing существует очень удобный механизм, предотвращающий появление в приложении «метрвых» объектов, которые представляют собой получателей вызовов. В действительности, первый же мертвый объект «валит» приложение, при поступлении ему события — это закономерно, так как объект уже не существует и никаких методов вызвать у него уже не получится.

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

В процессе работы над классом, который я использовал для событий, мне захотелось создать аналогичный механизм, так как ошибки в событийной логике довольно сложно прогнозировать, и страховка здесь не помешает.

Данная статья рассчитана на разработчиков, имеющих опыт работы с платформой и знающих, каким образом определяется жизненный цикл объекта. Если у вас есть определенные пробелы в этой области (а я неоднократно встречал даже опытных разработчиков, которые не знают, каким образом работает счетчик ссылок и не представляющих, во что разворачивается @synthesize), то вы можете прочитать мою старую статью, посвященную исследованию данного вопроса. Остальных прошу к столу.

Итак, чего мы хотим? Мы хотим, чтобы как только объект, который подписан на событие через механизм, описанный в предыдущем выпуске, уничтожался, мы получали информацию об этом в отладчике.

Что для этого нужно? Очевидное решение — каким-то образом при подписке на событие перехватывать вызов dealloc объекта-подписанта и сообщать об этом разработчику. Однако, вот незадача — невозможно штатными средствами перехватить dealloc (или, по крайней мере, я такого способа не нашел).

К счастью, Objective C дает возможность довольно красиво обойти это ограничение с помощью своего runtime. Идею этого решения я подсмотрел в заметке некого codeshaker, и она оказалась невероятно красива и элегантна. Переделав ее под свои нужды, я получил следующий код:

@interface NSObject (NSObjectDeallocInfo)

-(void)dealloc_override;

@end

@implementation NSObject (NSObjectDeallocInfo)

+(void)load
{
	method_exchangeImplementations(class_getInstanceMethod(self, @selector(dealloc)), class_getInstanceMethod(self, @selector(dealloc_override)));
}

-(void)dealloc_override
{
	[self dealloc_override];
}

@end

Фактически этот код заменяет метод-обработчик сообщения dealloc на наш обработчик dealloc_override, а кажущийся рекурсивным вызов [self dealloc_override] на самом деле теперь ведет в стандартный метод.

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

Определим некоторый уникальный идентификатор нашего свойства.

static void* AW_EVENTHANDLER_KEY = (void *)0x2781;

Тепреь привяжем его к классу NSObject, используя ту же самую категорию, которой мы воспользовались для переопределения метода.

@interface NSObject (NSObjectDeallocInfo)

@property (nonatomic, assign) AWEventHandlersList *attachedEventHandler;
-(void)dealloc_override;

@end

@implementation NSObject (NSObjectDeallocInfo)

+(void)load
{
	method_exchangeImplementations(class_getInstanceMethod(self, @selector(dealloc)), class_getInstanceMethod(self, @selector(dealloc_override)));
}

-(void)dealloc_override
{
	[self dealloc_override];
}

-(AWEventHandlersList *)attachedEventHandler
{
	return (AWEventHandlersList *)objc_getAssociatedObject(self, AW_EVENTHANDLER_KEY);
}

-(void)setAttachedEventHandler:(AWEventHandlersList *)attachedEventHandler
{
	objc_setAssociatedObject(self, AW_EVENTHANDLER_KEY, attachedEventHandler, OBJC_ASSOCIATION_ASSIGN);
}

@end

Теперь у любого объекта типа NSObject есть виртуальное свойство attachedEventHandler, которое мы будем использовать для хранения нужной нам информации.

Расширим код класса AWEventHandlersList, чтобы он записывал в это поле объект привязанного события и добавим метод, возвращающий YES если объект подписан на событие.

-(void)addReceiver:(id)receiver delegate:(SEL)delegate
{
	[self removeReceiver:receiver delegate:delegate];
	
	[receiver setAttachedEventHandler:self];
	[_handlers addObject:[AWEventHandler handlerWithTarget:receiver method:delegate]];
}

-(void)removeReceiver:(id)receiver delegate:(SEL)delegate
{
	[receiver setAttachedEventHandler:nil];
	for(AWEventHandler *handler in [[_handlers copy] autorelease])
		if(handler.method == delegate && handler.target == receiver)
			[_handlers removeObject:handler];
}

-(BOOL)isReceiverInList:(id)receiver
{
	for(AWEventHandler *handler in _handlers)
		if(handler.target == receiver)
			return YES;
	return NO;
}

-(void)clearReceivers
{
	for(AWEventHandler *handler in _handlers)
		[handler.target setAttachedEventHandler:nil];
	[_handlers removeAllObjects];
}

Теперь становится довольно просто реализовать то, ради чего это затевалось — проверку на момент деаллокации объекта.

-(void)dealloc_override
{
	AWEventHandlersList *handler = self.attachedEventHandler;
	if(handler)
		if([handler isReceiverInList:self])
		{
			NSLog(@"Event handler (%@) target is released while subscribed", handler.name);
			[NSException raise:@"E_HANDLERRELEASED" format:@"Event handler (%@) target is released while subscribed", handler.name];
		}
	[self dealloc_override];
}

Теперь в случае, если объект был уничтожен, пока он подписан на событие, то будет выбрасываться исключение. Что самое приятное — исключение выбрасывается в месте, где срабатывает деструктор объекта, что позволяет видеть стек ошибки в crash reports.

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