iOS4 - быстрое переключение контекста

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

Но в своем приложении я использую контроллер навигации, чтобы нажимать и открывать представления. После перехода примерно с 20 разных страниц использование грязной памяти достигает 30 МБ или около того.

Также для dismissModalViewControllerAnimated и popViewControllerAnimated, dealloc не вызывается.

У меня два сомнения:

  1. С каким объемом грязной памяти допустимо выйти в эфир?
  2. Какой альтернативный контроллер навигации поддерживает кнопку возврата?

Заранее спасибо.


iphone ios4 context-switching
person Sunil    schedule 06.07.2010    source источник
comment
1. Не 30МБ. Старые устройства iOS имеют только 128 МБ оперативной памяти, поэтому одно ваше приложение может заполнить это примерно на 23% ... 2. Если вы действительно теряете 30 МБ, вы, вероятно, что-то не выпускаете где-то, это не UINavigationController вина.   -  person Douwe Maan    schedule 06.07.2010
comment
Привет, Доу, спасибо за ответ. Почему я сомневаюсь в UINavigationController, потому что я продолжаю вставлять в него контроллеры представления. И когда я открываю контроллеры представления из контроллера навигации, метод dealloc не вызывается там, где я освобождаю определенные переменные экземпляра. И память не очищается, используемая всеми этими переменными экземпляра. Я делаю что-то неправильно? Должен ли я очищать переменные экземпляра где-нибудь еще, а не в dealloc?   -  person Sunil    schedule 06.07.2010
comment
Есть ли у вас какие-либо другие ссылки на контроллеры представления в другом месте вашего приложения? Если вы открываете их, но по-прежнему имеете ссылку на контроллер где-то еще, он не будет GCed.   -  person blueberryfields    schedule 28.09.2010

Ответы (2)


arrow_upward
4
arrow_downward

У вас все еще могут быть ваши UIViewControllers, если не вызывается dealloc.

Возможно, вы устанавливаете делегаты или другие классы в этих UIViewControllers, которые сохранили и ссылались на резервную копию дерева (циклические ссылки).

Вы можете отладить это, перегрузив сохранение и освобождение в UIViewController, а также установив точку останова и войдите в файл keepCount.

Вот волшебный фрагмент, который я оставляю для себя, который очень помогает мне, когда я не могу понять, почему я все еще что-то сохраняю.

- (id)retain
{
    NSLog(@"retain \t%s \tretainCount: %i", __PRETTY_FUNCTION__ , [self retainCount]);
    return [super retain];
}
- (void)release
{
    NSLog(@"release \t%s \tretainCount: %i", __PRETTY_FUNCTION__ , [self retainCount]);
    [super release];
}
- (id)autorelease
{
    NSLog(@"autorelease \t%s \tretainCount: %i", __PRETTY_FUNCTION__ , [self retainCount]);
    return [super autorelease];
}

__PRETTY_FUNCTION__ - это специальный скрытый макрос в CLang, который дает красивое имя функции Objective-C в виде массива символов.

person Zac Bowling    schedule 11.02.2011

arrow_upward
0
arrow_downward

  1. Когда в iOS начинает не хватать памяти, она пытается убить фоновые процессы, которые используют больше всего памяти. Так что, хотя абсолютного хорошего числа нет, свести к минимуму объем используемой памяти - хорошая идея. Оставить 30 МБ - это значит гарантировать, что ваше приложение будет убито.
  2. Если вы не хотите изменить свой пользовательский интерфейс, нет необходимости использовать что-либо, кроме UINavigationController, для работы с вашей кнопкой возврата. Я думаю, проблема в том, что если dealloc не вызывается при всплывающей подсказке или отклонении, у вас есть утечка памяти.

Почти все контроллеры представлений содержат данные, которые эффективно кэшируются и могут быть восстановлены, когда приложение вернется на передний план. Подумайте о данных, которые вы выпускаете, когда получаете предупреждение о памяти во время работы приложения. (Вы ведь отвечаете на предупреждения о памяти, верно?) Это то, что нужно выпускать, когда вы переходите в фоновый режим.

person Stephen Darlington    schedule 11.02.2011