Сильная и слабая путаница в iOS
Я немного запутался в использовании Strong или Weak в моем конкретном случае.
У меня есть один класс ParentClass который имеет 3 object ContainerClass1 , ContainerClass2 и ContainerClass3 .
Каждый ContainerClass имеет свои собственные свойства с Mutable объектами, такими как NSMutableArray
Теперь в моем случае я должен показывать только один ContainerClass за раз, поэтому, если ContainerClass1 показан, ContainerClass2 и ContainerClass3 не требуются.
Поэтому я подумал, когда я покажу ContainerClass1 , установит объекты ContainerClass2 и ContainerClass3 на nil . Здесь я смущен, будет ли просто устанавливать другой ContainerClass (не показан) на nil чтобы release его память? потому что они обладают сильными свойствами для других объектов.
Или мне нужно сначала установить все остальные свойства ContainerClass's в nil а затем установить ContainerClass в nil ?
Заранее спасибо.
@zoeb, эта ссылка поможет вам избежать проблем с основной памятью.
как к преодолению-памяти-проблемы-в-iPhone-приложений-с-автоматической ССЫЛКА подсчета
Отредактировано:
Поскольку мы знаем, что Apple представила ARC в IOS 5.0, ARC – это функция уровня компилятора, которая упрощает процесс жизни объектов объектива-c. Перед введением ARC мы управляли памятью вручную – «Ручной подсчет ссылок (MRC)». В MRC разработчику необходимо помнить, когда выпустить или сохранить объект. Означает, что Разработчику необходимо управлять жизненным циклом объектных объектов.
По мнению разработчиков, мы в основном заинтересованы в добавлении новых функций в наше приложение, а не в решении проблем с памятью. Но все уверенно, что управление памятью играет решающую роль в успехе приложения. Чтобы предоставить помощь разработчику, Apple определила способ автоматического управления памятью.
ARC умело управляет памятью, но это не 100 процентов. Нам нужно сосредоточиться на некоторых моментах разработки, чтобы удалить наше приложение из-за недостатка памяти. Здесь я попытаюсь предоставить решение для управления памятью в базовом приложении ARC. что не составляет 100 процентов. но он попытается помочь компилятору оценить жизненный цикл объектного объекта.
Вот некоторые шаги, которые вам необходимо реализовать в каждом контроллере.
Шаг 1. Объявите слабое свойство для каждого элемента управления пользовательского интерфейса, который используется в приложении.
Пример :
@property (nonatomic, weak) IBOutlet UIButton* btnPost;
@property (nonatomic, weak) IBOutlet UITableView* tblMessages;
и т.п.
Шаг 2. Согласно нашему разработчику, наиболее запутанный вопрос заключается в том, позволяет ли компилятор объявить метод «dealloc» в базовом приложении ARC. ответ да, но не разрешено объявлять «[super dealloc]» внутри него. поэтому переопределите метод «dealloc» в каждом контроллере.
-(void)dealloc{ }
Шаг 3. Удалите тяжело нагруженный объект из супервизора в методе «dealloc», а затем установите только «нулевую» ссылку, такую как MKMapview, ScrollView и т. Д.
-(void)dealloc{ dictAddress = nil; arrayList = nil; [map removeFromSuperview]; [scrollView removeFromSuperview]; }
Шаг 4. Избегайте механизма блокировки. (Пример: класс A и класс B. Класс B объявлен делегатом с типом свойства «Сильный», так что класс A и класс B, зависящие друг от друга на одном, будут выпущены, поэтому в этом случае метод «dealloc» не вызываемый ни одним из классов, поэтому этот класс хранится в памяти. Чтобы удалить такие случаи, нам нужно сохранить ссылку «Назначить» для объекта Delegate.) Это, например, только. Нам нужно учитывать и другие вещи, такие как «Сохранять слабую ссылку для блока, чтобы он освобождал объекты после завершения выполнения».
это основные шаги, которые позволяют избежать проблем с памятью. Тем не менее, если вы сталкиваетесь с проблемами памяти, вам необходимо обратиться к аналитику, чтобы найти утечку и использование памяти.
Ниже ссылка поможет вам проанализировать память.
Анализатор Мамори
Путаница между сильными и слабыми будет понятна с помощью ссылки ниже.
Различия между сильными и слабыми в Objective-C