For iOS, modify weak, assign, and weakassign for proxy

For iOS, modify weak, assign, and weakassign for proxy

1. for strong: delegate is strongly referenced by this object. The delegate object cannot be destroyed by the outside world, leading to Retain Cycles)

Because we usually proxy the current controller such as scrollView. delegate = self; at this time, it becomes a circular reference of the above circle. If delegate is a strong pointer, The retainCount of UIViewController and scrollView will always be at least 1. Therefore, the object with a strong pointer will not be destroyed, resulting in Memory leakage. Therefore, to avoid Memory leakage, that is, to avoid loop references like the above, the delegate must be a weak pointer. In this way, when uiviewcontrler finishes running its own scope and needs to be destroyed, no strong Pointer Points to itself, and retainCount = 0, so it is automatically destroyed, and the UIView to which it points has no strong pointer pointing, so retainCount = 0, therefore, NSArray is also destroyed, and scrollView is also destroyed to avoid Memory leakage.

2. For assing: it also has the weak function. However, if assign is used to assign values to pointers on the internet, no reference counting operation is performed. If it is not set to nil after use, a wild pointer may be generated. If weak is not used, it will never be used, and no wild pointer will be generated.

After some research, we found that

@ Property (nonatomic, assign, readwrite) id delegate;

Declare a delegate. Even if the delegate object is destroyed, the address of the previous object will still be saved in the delegate, that is, the delegate becomes a wild pointer...

 

3. For weak: It indicates that this object is not responsible for keeping the delegate object. The destruction of the delegate object is under external control.

However, if weak is used, the preceding problem will not occur. After the delegate object is destroyed, delegate = nil,

So the answer is to use weak.