Понимание влияния на сохранение количества методов, кроме сохранения и выпуска - PullRequest
0 голосов
/ 22 ноября 2011

У меня есть подпрограмма для правильного выделения и освобождения моего подкласса UIView, но когда я устанавливаю точку останова в - (void) dealloc класса, я вижу, что он не вызывается, и у меня огромная утечка памяти.

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

[myObject removeFromSuperview];

А теперь он освобожден. Что заставляет меня понять, что ранее я отправил:

[self.view bringSubviewToFront:myObject];

ОЧЕНЬ ТРУДНО знать, что когда я использую bringSubviewToFront:, мне всегда приходится звонить removeFromSuperview. Существуют ли другие подобные методы, которые могут увеличить счет удержания?

Если бы этот объект не был подклассом и был всего лишь UIView, я бы никогда не узнал, что создал утечку памяти.

Итак, как я могу действительно знать, что мои объекты были освобождены и что память свободна?

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

Когда я не использовать removeFromSuperview,

Memory used 16687.1 ( +5378), free 262213.6 kb
Memory used 19451.9 ( +2765), free 257159.2 kb
Memory used 19451.9 (    +0), free 259530.8 kb 
Memory used 21844.0 ( +2392), free 257830.9 kb 
Memory used 24313.9 ( +2470), free 256356.4 kb 
Memory used 25260.0 (  +946), free 253141.0 kb
Memory used 27848.7 ( +2589), free 252874.8 kb
Memory used 30142.5 ( +2294), free 250814.5 kb
Memory used 30814.2 (  +672), free 247787.5 kb

Вы можете видеть, что использование памяти только увеличивается, но когда я делаю , использую это:

Memory used 16105.5 ( +4829), free 262619.1 kb
Memory used 16527.4 (  +422), free 262815.8 kb
Memory used 14168.1 ( -2359), free 262832.1 kb
Memory used 16769.0 ( +2601), free 263266.3 kb
Memory used 16560.1 (  -209), free 264785.9 kb 
Memory used 14200.8 ( -2359), free 264794.1 kb 
Memory used 16789.5 ( +2589), free 264290.3 kb 
Memory used 16597.0 (  -193), free 264499.2 kb 
Memory used 14237.7 ( -2359), free 264515.6 kb 
Memory used 16609.3 ( +2372), free 264290.3 kb 
Memory used 16560.1 (   -49), free 264425.5 kb 
Memory used 14200.8 ( -2359), free 264441.8 kb 

теперь память увеличивается и уменьшается, как я хочу.

Я получил код для регистрации использования памяти с https://stackoverflow.com/q/7990532/632472.

Ответы [ 3 ]

2 голосов
/ 22 ноября 2011

Вы делаете что-то подобное?

self.subView = [[UIView alloc] init];

Если это так, это может быть вашей проблемой. Число сохранений будет равно 2. Один раз для alloc и один раз для набора свойств. Возможно, вы захотите добавить вызов в autorelease

self.subView = [[[UIView alloc] init] autorelease];
1 голос
/ 23 ноября 2011

Я предполагаю, что где-то в вашем коде вы добавляете этот объект в представление с чем-то вроде этого:

[self.view addSubview:myObject];

Если это так, то это точка дополнительного сохранения, поскольку любой UIView сохраняет свое содержимое. На самом деле позвоните

[myObject removeFromSuperView];

делает магию освобождения для вас ...

1 голос
/ 22 ноября 2011

Нет требования, чтобы вы звонили removeFromSuperview после звонка bringSubviewToFront:. Существует только требование, чтобы вы высвобождали то, что вы сохраняете. removeFromSuperview вызывается, когда вы хотите удалить представление из его иерархии представлений. То, что он также называет release, не имеет значения.

Скорее всего, здесь у вас есть какое-то другое превышение myObject. Вы всегда используете аксессуары для своих иваров? Прямой доступ к ivars (кроме init и dealloc) - наиболее частая причина утечек памяти. Если myObject не хранится в ivar, то запустите анализатор, чтобы убедиться, что вы не переоцениваете myObject где-то более очевидное. (Анализатор плохо разбирается в ivars, но использование аксессоров обычно решает эти проблемы.)

...