1 OC Memory management

Each time runloop completes a loop, it checks the retainCount of the object. If returnCount is 0, no reference to the object is available and the object can be released. When the reference count is reduced to zero, the system automatically calls the dealloc method to reclaim memory.

The golden rule: if an object using alloc, copy, mutablecopy, retain, must have the corresponding release, autorealse.

1.1 Causes of Memory Management

Memory is limited, and the memory occupied by a program is also limited. When the required memory exceeds the memory allocated by the program, the program will crash and blink. Memory management to clear up the occupied memory space at the appropriate time, can improve the utilization of memory, let the program run more smoothly

1.2 Scope of Memory management

Memory management manages objects and blocks that inherit from NSObject; other non-objects do not need to be managed. OC objects are stored in the heap and non-OC objects are stored in the stack. Heap memory is allocated dynamically and needs to be allocated and reclaimed manually. Stacks are allocated by the system for collection.

1.3 Memory Management Mode

  • Manual retained -release (MRC)/ Manual retaincount-release (MRR) manual memory management
  • ARC (automatic reference counting) automatic reference counting, launched after iOS5.0 version, as long as no pointer to the object, the object will be released, the compiler implicitly manages memory, in the proper position insert retain, release, autorelease
  • Garbage collection is supported in MacOS development, but not in iOS

2 Memory Leakage

Object is no longer used, but the object is not destroyed and space is not freed

2.1 Memory Leakage

  • Strong references between objects

strong A -> strong B -> strong A

For example, if you use weak for the delegate property instead of strong, you can also use assign, and you can copy the delegate pointer to point to an object, and when the object is destroyed, the pointer doesn’t automatically set to nil, there’s the possibility of wild Pointers, but for the delegate, in most cases, The lifetime of the object referred to as a delegate overwrites the lifetime of the object that holds the delegate.

Weak is safer. For example, if the delegate object is a property of a ViewController, and the ViewController is destroyed, the delegate object should be destroyed as its property, but it is strongly referenced by another object, so it is not destroyed. The Assign delegate points to the object that should be destroyed

  • Object of a temporary variable created within the loop

Due to the excessive number of loops, a large number of temporary variables are generated in the loop. Each loop will add an NSString* object to the automatic release pool of the current runloop. These nsStrings will be released only when the automatic release pool is released. Memory overflow occurs

Use @Autoreleasepool {} to box the outside of the loop for a large number of times

For extremely large loops, use @Autoreleasepool {} to box inside

Objects in autoReleasepool are released once they are out of scope, and destruction is not guaranteed

for(int i = 0; i < 1000000; i++){
	NSString * s = ...
    //dosomething
}
Copy the code

  • An infinite loop

For example, if the ViewController has an animation set to loop HUGE_VAL almost indefinitely, it cannot be released when the ViewController disappears.

The animation should be removed from view disappear