NSTimers, вызывающие утечки

Не звоните в свой NSTimer!

Я знаю, что это звучит нелогично, но когда вы создаете экземпляр, он автоматически регистрируется в текущем (вероятно, основном) цикле выполнения потоков (NSRunLoop). Вот что Apple говорит по этому поводу...

Таймеры работают в сочетании с циклами выполнения. Чтобы эффективно использовать таймер, вы должны знать, как работают циклы выполнения — см. Руководство по программированию NSRunLoop и Threading. В частности, обратите внимание, что циклы выполнения сохраняют свои таймеры, поэтому вы можете сбросить таймер после того, как добавили его в цикл выполнения.

После планирования в цикле выполнения таймер срабатывает с указанным интервалом до тех пор, пока он не станет недействительным. Неповторяющийся таймер становится недействительным сразу после срабатывания. Однако для повторяющегося таймера вы должны сами аннулировать объект таймера, вызвав его метод аннулирования. Вызов этого метода запрашивает удаление таймера из текущего цикла выполнения; в результате вы всегда должны вызывать метод invalidate из того же потока, в котором был установлен таймер. Отключение таймера немедленно отключает его, чтобы он больше не влиял на цикл выполнения. Затем цикл выполнения удаляет и освобождает таймер либо непосредственно перед возвратом метода недействительности, либо в какой-то более поздний момент. После признания недействительными объекты таймера нельзя использовать повторно.

• Цитаты взяты из Ссылка на класс NSTimer.

Таким образом, ваш экземпляр становится...

timer_porthole = [NSTimer scheduledTimerWithTimeInterval:.05
                                                           target:self
                                                       selector:@selector(onTimer_porthole:)
                                                         userInfo:nil
                                                          repeats:YES];

И теперь, когда вы больше не держите ссылку на экземпляр, вам не нужен вызов освобождения в вашем методе Dealloc.

Я видел, что вы уже приняли ответ, но здесь есть две вещи, которые я хотел исправить:

1. нет необходимости сохранять запланированный таймер, но это не приносит никакого вреда (если вы отпустите его, когда он больше не нужен). «Проблемная» часть отношения таймер/цель заключается в том, что...
2. таймер сохраняет свою цель. И вы решили установить для этой цели значение self.
   Это означает, сохраняется он или нет, но таймер будет поддерживать ваш объект в рабочем состоянии до тех пор, пока таймер действителен.

Имея это в виду, давайте пересмотрим ваш код снизу вверх:

- (void)dealloc {
    [timer_porthole invalidate]; // 1
    [timer_porthole release];
    timer_porthole = nil;  // 2

    [super dealloc];
}

1 не имеет смысла:
Если бы timer_porthole все еще был действительным таймером (то есть запланированным в цикле выполнения), он сохранил бы ваш объект, поэтому этот метод не вызывался бы в первую очередь...

2 здесь тоже нет смысла:
Это dealloc! Когда [super dealloc] вернется, память, которую ваш экземпляр занимал в куче, будет освобождена. Конечно, вы можете обнулить свою часть кучи, прежде чем она будет освобождена. Но зачем беспокоиться?

Тогда есть

-(void) kill_timers{
     [timer_porthole invalidate];
     timer_porthole=nil; // 3
}

3 с учетом вашего инициализатора (и, как указывали другие), вы пропускаете свой таймер здесь; перед этой строкой должен быть [timer_porthole release].

PS:

Если вы все обдумаете, то увидите, что сохранение таймера (по крайней мере временно) создает цикл сохранения. В данном конкретном случае это не проблема, которая решается, как только таймер становится недействительным...

Вы пропустили [timer_porthole release]; вызов в своем kill_timers методе. Если вы вызываете kill_timers до вызова метода dealloc, вы устанавливаете timer_porthole в ноль, но не освобождаете его.