Я столкнулся с подобной проблемой в последнем проекте. Для меня проблема заключалась в том, что он скрыт в неясном операторе retain для свойства делегата, которое удерживало счетчик retain, что приводило к тому, что представление не было успешно освобождено.
Попробуйте эту методику устранения неполадок .....
по-видимому, у вас может быть контроллер навигации для просмотра / вывода.
Учтите, что в представлении есть что-то, удерживающее счетчик сохранения, в результате чего представление остается в памяти (даже если представление выскочило, и вы выполнили оператор освобождения). Еще один признак (не характерный для этой проблемы, но связанный с этим, если сделать всплывающее окно всех контроллеров представления, вы можете даже столкнуться с падением приложения.)
Так что в методах dealloc представления контроллера (ов)
сделать запись в журнале по количеству сохранений соответствующего представления. (и другие объекты, которые вы синтезируете.)
например.
UiNavController
-Level0ViewController
-(void)dealloc{
// HERE TEST FOR RETAIN COUNT OF 2 (2 = one for the alloc / one for the addSubview)
DLog(@"level0view retain count: :%@",[level0view retainCount]);
[level0view release]; // this will make retain count 1.
[super dealloc];
-- Level0View
-(void)dealloc{
DLog(@"dealloc"); // set break points here and confirm this is being called.
}
-- SomeImageView.h
// for me my problem lied here with the infringing line below being RETAIN! it should have been assign. changing this successfully resolved app crash and memory leak.
@property(retain) id delegate
P.S. Посмотрите DLog от Karl Kroft - это очень удобно, когда вы записываете номер строки класса и скрываете хафф, который обычно добавляет NSLog.