@zoeb, может эта ссылка поможет вам держаться подальше от проблем с основной памятью.
how-to-overcome-memory-problems-in-iphone-applications-with-automatic-reference-counting
Отредактировано:
Как мы знаем, что компания Apple представила ARC в IOS 5.0, ARC является компилятор функция уровня, который упрощает процесс жизни Objective-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.) Это, например, только. Нам нужно учитывать и другие вещи, такие как «Сохранять слабую ссылку для блока, чтобы он освобождал объекты после завершения выполнения».
Это основные шаги, которые позволяют избежать проблем с памятью. Тем не менее, если вы сталкиваетесь с проблемами памяти, вам необходимо обратиться к аналитику, чтобы найти утечку и использование памяти.
Ниже ссылка поможет вам проанализировать память.
Mamory analyzer
Прежде всего, вы должны быть всегда слабы для IBOutlets. И да, когда вы устанавливаете ContainerClass2 на ноль, все его IBOutlets становятся нулевыми, потому что его родительский номер равен нулю. –
Согласен с Yogesh для IBOutlets :) –
http://www.rypress.com/tutorials/objective-c/properties – Yuyutsu