"Reading notes" Ios-coco memory management rules-owning objects

One, the event loop. A typical graphical application often spends a lot of time waiting for the user to operate. The program will remain idle until a decision is made very slowly by the person controlling the control, such as clicking the mouse or pressing a key. When such an event occurs, the program wakes up and starts working, performing certain actions necessary to respond to this event. After the event is processed, the program returns to hibernation and waits for the next event to occur. To reduce the memory footprint of the program, Cocoa creates an auto-free pool before the program starts processing events, and destroys the auto-free pool after the event processing finishes. This keeps the number of temporary objects that are accumulating to a minimum.

Second, the time for the auto-release pool to be cleaned is completely deterministic: either it is displayed in your own code, or it is destroyed using AppKit at the end of the event loop. You don't have to worry about how the daemon randomly destroys the auto-free pool. Because the auto-free pool is not destroyed when the function is called, you do not have to keep every object that you use.

Reference: "Object-c Basic Course"

"Reading notes" Ios-coco memory management rules-owning objects