слабый или сильный для IBOutlet и других [дубликаты]

This question already has an answer here:

Should IBOutlets be strong or weak under ARC? 11 answers

Я переключил свой проект на ARC, и я не понимаю, нужно ли мне использоватьstrong или жеweak для IBOutlets. XCode сделать это: в конструкторе интерфейса, если создатьUILabel например, и я подключаю его с помощью помощника редактора к моемуViewControllerСоздайте это:

@property (nonatomic, strong) UILabel *aLabel;

Он используетstrongвместо этого я прочитал учебник на сайте RayWenderlich, который говорит это:

But for these two particular properties I have other plans. Instead of strong, we will declare them as weak.

@property (nonatomic, weak) IBOutlet UITableView *tableView;
@property (nonatomic, weak) IBOutlet UISearchBar *searchBar;

Weak is the recommended relationship for all outlet properties. These view objects are already part of the view controller’s view hierarchy and don’t need to be retained elsewhere. The big advantage of declaring your outlets weak is that it saves you time writing the viewDidUnload method.

Currently our viewDidUnload looks like this:

- (void)viewDidUnload
{
    [super viewDidUnload];
    self.tableView = nil;
    self.searchBar = nil;
    soundEffect = nil;
}

You can now simplify it to the following:

- (void)viewDidUnload
{
    [super viewDidUnload];
    soundEffect = nil;
}

Так что используйтеweakвместоstrongи удалите набор в ноль вvideDidUnloadвместо Xcode используйтеstrongи использоватьself... = nil вviewDidUnload.

Мой вопрос: когда я должен использоватьstrong, и когдаweak? I want also use for deployment target iOS 4, so when do I have to use the unsafe_unretain? Любой может помочь объяснить мне хорошо с небольшим учебником, когда использованиеstrong, weak а такжеunsafe_unretain с дугой?

Ответы на вопрос(2)

Решение Вопроса

A rule of thumb

When a parent has a reference to a child object, you should use a strong reference. When a child has a reference to its parent object, you should use a weak reference or a unsafe_unretained one (if the former is not available). A typical scenario is when you deal with delegates. For example, a UITableViewDelegate doesn't retain a controller class that contains a table view.

enter image description here

Здесь простая схема для представления основных понятий.

Предположим, что первые A, B и Cstrong Рекомендации. В частности, С имеетstrong ссылка на его родителя. Когда obj1 освобождается (где-то), ссылка A больше не существует, но у вас есть утечка, поскольку существует цикл между obj1 и obj2. Говоря с точки зрения сохранения количества (only for explain purposes), obj1 имеет счет сохранения 2 (obj2 имеетstrong ссылка на него), в то время как obj2 имеет счет сохранения 1. Если obj1 освобожден, его счет хранения теперь равен 1, а егоdealloc метод не вызывается. obj1 и obj2 все еще остаются в памяти, но никто не имеет ссылки на них:Leak.

На этой странице, если только А и Вstrong ссылки и C квалифицируется какweak все нормально. У вас нет утечек. Фактически, когда obj1 выпущен, он также выпускает obj2. Говоря с точки зрения количества сохранений, obj1 имеет счет сохранения 1, obj2 имеет счет сохранения 1. Если obj1 выпущен, его счет хранения теперь равен 0, а егоdealloc метод называется. obj1 и obj2 удаляются из памяти.

A simple suggestion: Start to think in terms of object graph when you deal with ARC.

Что касается вашего первого вопроса, оба решения действительны, когда вы имеете дело с XIB. В общемweak ссылки используются, когда вы имеете дело с циклами памяти. Что касается файлов XIBs, если вы используетеstrong вам нужно установитьnil вviewDidUnload поскольку, если вы этого не сделаете, в условиях нехватки памяти вы можете вызвать неожиданные утечки. Вы не выпускаете их вdealloc потому что ARC сделает это за вас. weak вместо этого эта обработка не требуется, поскольку, когда целевой объект уничтожается, эти значения устанавливаются какnil автоматически. Никаких висящих указателей больше.

Если вы заинтересованы, я действительно предлагаю вам прочитатьПятницы-QA-2012-04-13-СИБ-управления памятью отMike Ash.

По поводу вашего второго вопроса, если вам нужно поддерживать iOS 4, а неweak ты должен использоватьunsafe_unretained.

Внутри ТАМ много вопросов / ответов. Вот основные из них:

Как заменить слабые ссылки при использовании ARC и ориентации на iOS 4.0?

Какой тип утечек не предотвращает или минимизирует автоматический подсчет ссылок в Objective-C?

с использованием ARC, присваивания пожизненного квалификатора и unsafe_unretained

сильный / слабый / сохранить / unsafe_unretained / assign

Надеюсь, это поможет.

Update

Согласно комментарию shaunlim, начиная с iOS 6viewDidUnload метод устарел. Здесь я действительно предлагаю увидеть ответ Роба:iOS 6 - переход с viewDidUnload на didReceiveMemoryWarning?.

 15 авг. 2014 г., 23:24
Просто наткнулся на это и хотел указать, что viewDidUnload с тех пор устарел. Это все еще невероятно информативный ответ!
 24 авг. 2014 г., 15:13
@shaunlim Спасибо большое! Я буду обновлять ответ на основе вашего комментария. Спасибо вам.
 23 июн. 2012 г., 18:15
Это то же самое. С помощьюweak позволяет сэкономить время на написание кода (две строки в вашем случае) вручную. Но XCode делает это для вас. Мое личное мнение. Я люблю использоватьstrong.
 Piero23 июн. 2012 г., 18:10
Вы говорите, что для iboutlet, если я использую сильный, я должен использовать nil в viewdidunload, а для низкого объема памяти у меня нет утечек, вместо слабого я не должен использовать nil в videwdidunlaod, а для предупреждения о недостаточном объеме памяти - это ''; Лучше сильное решение или слабое?

которые связаны через IBOutlets с объектами в IB, потому что в этом случае объекты будут там, пока существует суперпредставление. Это потому, что суперпредставление имеет сильный указатель на свои подпредставления.

Если указатель, который вы определяете, является единственным указателем на объект, вы должны объявить его как сильный.

Если вы являетесь зарегистрированным разработчиком, я настоятельно рекомендую вам посмотреть видео с WWDC11 и WWDC12. Еще один хороший ресурс - это подкаст для разработчиков iOS отСтэнфорд.

 23 июн. 2012 г., 16:49
Я предполагаю, что сильный в некотором смысле безопаснее, потому что выходы сохраняются «еще раз». кроме того, что было оставлено супервизором в детстве. Представьте, что вы программно добавляете / удаляете некоторые подпредставления во время выполнения. Имея сильную ссылку, удаленные подпредставления сохраняются (не освобождаются). В обмен вы должны установить сильные ссылки на nil в viewDidUnload.
 23 июн. 2012 г., 16:51
С другой стороны, если вы установили свой кончик в IB, и он останется таким же навсегда (без удаления / повторного добавления подпредставлений во время выполнения), то слабого должно быть достаточно (или «unsafe_unretained, в pre-iOS 5)»
 Piero23 июн. 2012 г., 13:55
хорошо, но я не понимаю, мой вопрос охватывает также unsafe_unretain, но для IBOutlet я хорошо объясняю, почему яблоко использует сильное? ... вместо использования слабое? ... так что я должен следовать за яблоком? или следовать учебнику raywenderlich, где я пишу над фрагментом, который использует слабый?
 23 июн. 2012 г., 13:21
Видео WWDC12 уже доступны?
 23 июн. 2012 г., 13:22
Да! Действительно быстро в этом году.

Ваш ответ на вопрос