В Cocoa нужно ли удалять объект из приема уведомлений KVO при его освобождении?

Вам нужно использовать -removeObserver:forKeyPath: , чтобы удалить наблюдателя перед запуском -[NSObject dealloc] , так что да, это будет работать в методе -dealloc вашего класса.

Но еще лучше было бы иметь детерминированную точку, в которой тот, кто владеет объектом, осуществляющим наблюдение, мог бы сказать ему, что это сделано и будет (в конечном счете) освобождено. Таким образом, вы можете немедленно прекратить наблюдение, когда вещь, делающая наблюдение, больше не нужна, независимо от того, когда она на самом деле освобождена.

Это важно иметь в виду, потому что время жизни объектов в Cocoa не является столь детерминированным, как некоторые люди, кажется, думают. Различные фреймворки Mac OS X сами отправят ваши объекты -retain и -autorelease, продлевая их срок службы за пределы того, что вы могли бы в противном случае подумать.

Кроме того, когда вы перейдете к сборке мусора Objective-C, вы обнаружите, что -finalize будет выполняться в очень разное время — и в очень разных контекстах — чем -dealloc . Во-первых, завершение происходит в другом потоке, поэтому вы действительно не можете безопасно отправить -removeObserver:forKeyPath: другому объекту в методе -finalize .

Придерживайтесь управления памятью (и другими дефицитными ресурсами) в -dealloc и -finalize и используйте отдельный метод -invalidate , чтобы владелец сказал объекту, что вы закончили с ним в детерминированной точке; делайте такие вещи, как удаление KVO наблюдений там. Цель вашего кода будет яснее, и вы будете иметь меньше тонких ошибок, чтобы заботиться о них.

Немного дополнительной информации, которую я получил в результате болезненного опыта: хотя NSNotificationCenter использует обнуление слабых ссылок при запуске под сборкой мусора, KVO этого не делает. Таким образом, вы можете не удалять NSNotificationCenter наблюдателя при использовании GC (при использовании retain/release, вам все равно нужно удалить своего наблюдателя), но вы все равно должны удалить KVO наблюдателей, как описывает Крис.

Определенно соглашусь с Крисом по поводу " прилипания к памяти (и другим дефицитным ресурсам) управления in-dealloc и-finalize..." комментарий. Много раз я буду видеть, как люди пытаются сделать недействительными объекты NSTimer в своих функциях dealloc. Проблема в том, что NSTimer сохраняет свои цели. Поэтому, если цель этого NSTimer самостоятельно, dealloc никогда не вызывается, в результате чего некоторые потенциально неприятные утечки памяти.

Аннулируйте в -invalidate и выполните другую очистку памяти в ваших dealloc и finalize.