Некоторые исправления и предложения:
didReceiveMemoryWarning практика
Как вы сказали, реализация контроллера по умолчанию didReceiveMemoryWarning освобождает его представление, если оно «безопасно»сделать это ».Хотя из документов Apple неясно, что означает «сделать это безопасно», это общепризнанно, поскольку у него нет суперпредставления (таким образом, представление не отображается в данный момент), а его метод loadView может перестроить все представление.без проблем.
Лучше всего при переопределении didReceiveMemoryWarning не пытаться вообще освобождать какие-либо объекты вида.Просто отпустите свои пользовательские данные, если они больше не нужны.Что касается представлений, просто позвольте реализации суперкласса разобраться с ними.
Иногда, однако, необходимость данных может зависеть от состояния вашего представления.В большинстве случаев эти пользовательские данные задаются методом viewDidLoad.В этих случаях «безопасно выпускать пользовательские данные» означает, что вы знаете, что loadView и viewDidLoad будут вызваны до того, как контроллер представления снова использует пользовательские данные.
Следовательно, в вашем didReceiveMemoryWarning,сначала вызовите реализацию суперкласса, и если его представление выгружено, то освободите пользовательские данные, потому что вы знаете, что loadView и viewDidLoad будут снова вызываться наверняка.Например,
- (void)didReceiveMemoryWarning {
/* This is the view controller's method */
[super didReceiveMemoryWarning];
if (![self isViewLoaded]) {
/* release your custom data which will be rebuilt in loadView or viewDidLoad */
}
}
Будьте осторожны, чтобы не использовать self.view == nil, потому что self.view предполагает, что представление кому-то необходимо, и сразу же загрузит его снова.
viewDidUnload вызывается, когда контроллер представления выгружает представление из-за предупреждения памяти .Например, если вы удалите представление из суперпредставления и установите для свойства view контроллера значение nil, метод viewDidUnload будет вызываться , а не .Тонкий момент заключается в том, что даже если представление контроллера представления уже освобождено и установлено на ноль к тому времени, когда контроллер получает didReceiveMemoryWarning, так что на самом деле нет никакого представления для выгрузки для контроллера, viewDidUnload будет вызываться, если вывызовите реализацию суперкласса didReceiveMemoryWarning.
. Поэтому не рекомендуется вручную устанавливать для свойства view контроллера представления значение nil.Если вы это сделаете, лучше отправьте сообщение viewDidUnload.Я думаю, ваше понимание viewDidUnload более желательно, но, видимо, это не текущее поведение.
Если вы имеете в виду «удаление из суперпредставления» с помощью «popping», это уменьшает количество сохраненных представлений, но не обязательно освобождает их.
Если вы имеете в виду выход из UINavigationController, это фактически уменьшает количество сохраняемых данных самого контроллера представления.Если контроллер представления не удерживается другим объектом, он будет освобожден, желательно с его представлением.Как я объяснил, viewDidUnload будет не вызываться на этот раз.
Технически, счет удержания может не идтидо нуля.Скорее всего, объект будет просто освобожден без предварительного обнуления счетчика.
Просто чтобы убедиться, что сам контроллер представления обычно не освобождается из-за поведения по умолчанию из-за предупреждения о памяти.