Discusses declaring UI control properties when to use weak when to use strong

Maybe when we were studying, someone would tell us that UI control properties are decorated with weak, and that the controls dragged out of the storyboard are also decorated with weak, so in practice, we always use weak to decorate. In some cases, however, this can be problematic, and we must use strong to modify it.

Before exploring, we should first understand the memory management mechanism of objective c, that is, reference counting.
when will an object be released? The answer is, when the reference count is 0.

Create a UIView, declare a control property, decorate with weak

@property (nonatomic, weak) UIView *aview;

then we will test it in two different cases. First, initialize the control in Viewdidload.

You can see that the compiler has given a warning that the UIView will be released when this line of code is finished.
then we'll change the way we do.

At this point the compiler will not give an error, but it is problematic to write, when the most below the curly brace, the object will be no longer exist. will also become nil.

or lazy loading

Eh, that's what we write about in our usual way. So why does this view not go away? And the other way to access the Self.aview is also worth it.
we can see this property in the UIView.h header file of the system. When we execute the Addsubview: method, the subsequent view is placed in the array.

As you can see, this array is decorated with copy, which means that this is a strong reference. It is for this reason that we can use weak to modify a control. Therefore, you can keep the reference count of this control at 0, and it will not be released.

so we are in the development, in the end is to use weak or strong.

1, if you are really afraid of trouble, do not want to understand what memory management, you use strong on the right.
2, can be divided into cases, if you decorate the property with strong, and also addsubview:, although the reference count is 2, but when the entire parent view is destroyed, the two reference counts will become 0, so there is no memory leak.
3, the specific situation is that we sometimes in a view 1, the requirements require us to declare a view 2, this view 2 is not necessarily a sub-view of view 1, if view 2 has a value: then weak, the reference count is 0, this view is equivalent to not exist. When strong, the reference count is 1, and regardless of whether you add a child view that is not added to view 1, view 2 exists. Briefly summarize:

If view 2 has value, how to ensure that it does not disappear. is to ensure that it is not released.
Weak: View 1 exists, view 2 does not necessarily exist. Depends on whether View 2 has a strong reference.
Strong: View 1 exists, view 2 exists. Because strong will make the reference count +1. refer to another article: Explore the memory management of OC