Weak IOS reference

Keep an object and create a "strong" reference to this object. An object can be recycled only when all its strong references are released. Therefore, the lifecycle of an object depends on its strongly referenced owner. In some cases, such behavior may be unsatisfactory. You may want to reference an object without interfering with the collection of the object itself. In this case, you can obtain a weak reference. Weak references are created by storing a pointer to an object, rather than retaining the object.
Weak references are essential when cyclic references may occur. For example, if object A and object B communicate with each other, both must reference each other. If each object retains the other object, the two objects can only be recycled after the connection between them is interrupted, but the connection between them can only be interrupted after the object is recycled. To break this loop, an object must assume a subordinate role to obtain a weak reference of another object. For example, in the view hierarchy, the parent view has its child views, so it can retain the child views, but the parent view is not owned by the child views; however, the child view still needs to know who is its parent view, so it maintains a weak reference to its parent view.
Other applicable scenarios of weak references in cocoa include: Table data sources, outline view items, notification observers, and other items, but not limited to the above situations.
Be cautious when sending messages to your weak referenced objects. If you send a message to an object after it is recycled, your applicationProgramWill crash. You must set clearly-defined conditions for when an object is valid. In most cases, the weak referenced object knows the weak references of other objects, which is the same as the loop reference, it can also notify other objects when they are recycled. For example, when you register an object with the notification center, the notification center stores a weak reference to the object and, when appropriate messages are published, messages are also sent to the object. When an object is recycled, You need to register it with the notification center to prevent the notification center from sending messages to this nonexistent object. Similarly, when a delegate object is recycled, You need to delete the delegate link by sending a setdelegate: message with the NIL parameter to other objects. These messages are usually sent by the dealloc method of the object.