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

Question

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

Так что, вообще-то, плохой практике использовать много просмотров через интерфейс-строитель или что его автоматически позаботились по оригинальной UIViewController реализации didReceiveMemoryWarning(iOS 6+) or viewDidUnload (iOS 5 and below)?

Answer 1

Поведение по умолчанию для viewcontroller заключается в загрузке его иерархии представлений при первом доступе к свойству представления и последующем хранении в памяти до тех пор, пока контроллер вида не будет удален. Нет никаких указаний на то, что представление, созданное с использованием кода, отличается от представления, созданного в Interface Builder. Я лично предпочитаю InterfaceBuilder из-за обслуживания приложений, так как код пользовательского интерфейса становится довольно сложным, и разделение элементов пользовательского интерфейса на функциональный аспект элементов пользовательского интерфейса - это чистая бифуркация, позволяющая новому программисту поддерживать вашу базу кода.

Но когда дело доходит до освобождения памяти didReceiveMemoryWarning, делегат должен использоваться для явного освобождения иерархии представлений, если для вашего приложения требуется дополнительная память.

- (void)didReceiveMemoryWarning 
{ 
    [super didReceiveMemoryWarning]; 

    // Add code to clean up any of your own resources that are no longer necessary. 
    if ([self.view window] == nil) 
    { 
     // Add code to preserve data stored in the views that might be 
     // needed later. 

     // Add code to clean up other strong references to the view in 
     // the view hierarchy. 
     self.view = nil; 
    } 
    return; 
} 

Обратите внимание, что мы проверяем, не видны ли на экране диспетчера вида вид на экране. Если представление связано с окном, то оно очищает любые сильные ссылки контроллера представления на представление и его подпункты. Если представления хранят данные, которые необходимо воссоздать, реализация этого метода должна сохранять эти данные перед выпуском любой ссылки на эти представления. Сохраняя либо вы можете сохранить его в памяти как часть предыдущей памяти диспетчера просмотра, либо сохранить ее в корневом или некотором другом постоянном (дисковый кеш и т. Д.) Способом.

В следующий раз, когда открывается свойство view, представление перезагружается точно так же, как это было в первый раз. Pictographically это имеет смысл -

[source]