2013-07-01 4 views
8

Имеет интересную проблему, когда есть класс, на который ссылаются в макете XIB (подкласс UIScrollView), и не деизменяется в соответствии с инструментами/распределениями и не нарушает его процедуру dealloc. Назовем это Sclass1.IOS 6.1 с ARC-классом из XIB не освобождается, UIClassSwapper

Существует класс использования (назовем его Uclass), в котором есть файл XIB и розетка.

@property (nonatomic, weak) IBOutlet Sclass1* sclass1; 

Правильно подключен к макету XIB-файла.

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

Сверление в приборах показывает один Malloc и все.

FYI, класс запускается с

[UIClassSwapper initWithCoder:] 

ответ

0

Я думаю, что ваш @property должен быть сильным для класса:

@property (nonatomic, strong) IBOutlet Sclass1* sclass1; 

Поскольку strong является эквивалентом retain и ARC будет управлять релиз для вы.

У вас будет дополнительная информация с Apple Documentation о Transitioning to ARC Release Notes в разделе на атрибуты свойства.

+0

Это правильный ответ, все, что является IBOutlet, должно быть слабым, представление не освобождается, потому что контроллер имеет точку удержания на выходе, а выход имеет ссылку на контроллер. Создание цикла сохранения. Имейте upvote. –

5

Если объект не освобожден от использования в ARC, это означает, что существует сильная ссылка на него. Так как ваше свойство weak, объект должен владеть сильно чем-то, кроме объекта Uclass (иначе он будет освобожден сразу после загрузки XIB). В коде вы при условии, что не ясно, что фактический сильный владелец этого объекта, но я предполагаю, что это может быть один (или более) из следующих действий:

  1. Поскольку класс объекта является UIView подкласса, он может (сильно) ссылаться на его superview, если он добавлен как один из subviews. Это происходит автоматически при загрузке XIB-файла. Если superview не будет освобожден, не будет и объект SClass. Вы можете удалить это право собственности, позвонив по телефону removeFromSuperview
  2. Сильный цикл собственности (цикл сохранения) существует где-то среди иваров объекта SClass1 (т. Е. Одна из сильно принадлежащих переменным экземпляра имеет обратную ссылку на своего владельца - SClass1) , Остерегайтесь того, что любой блок, использующий self, также поддерживает ссылки. Наличие сильной ссылки на блок часто приводит к циклу сохранения. Сохраните self до __weak var и передайте это блоку вместо этого, если у вас нет веской причины не делать этого.
  3. Созданная вручную сильная ссылка существует, например. добавление объекта в контейнер или сохранение указателя на переменную не __weak.

Попытайтесь найти и удалить эти сильные владельцы. Только после удаления всех объектов объект может быть освобожден.

1

Поскольку ваше имущество слабое и оно все еще не освобождено, найдите ссылки на Sclass или его владельца Uclass. Возможно, вы используете Uclass (или Sclass) в блоке напрямую, без __weak typeof (self) weakSelf, и этот блок создает цикл сохранения. Также следите за отношениями родителей и детей и делегатами. Может быть, есть делегат, который силен, а не слабый или два контроллера имеют сильные ссылки на друг друга.

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

+0

Благодарим за указание цикла, вызванного циклом удержания блока. Это действительно общий случай ИМО. Добавил это и к моему ответу. – burax

0

Недавно я имел те же симптомы - решить это в моем случае, мой объект выступает в качестве делегата для ряда других объектов, поэтому пришлось освободить объект от всех своих делегатов обязанностей, прежде чем он будет называть dealloc

Смежные вопросы