IOS memory leak

IOS memory leak

Divide the memory according to the reference status of the memory block:
Cached memory, leaked memory, abandoned memory and Zombies memory

Cache memory: memory normally used
Memory leak: memory that is not referenced or released can be detected with leaks. MRC is common, and arc is mostly caused by the failure to release the core related libraries
Obsolete memory: there are still references to memory, but they cannot be used, and cannot be detected with leaks. You can try to use allocations for troubleshooting, which is generally caused by circular references

1、 Memory classification

According to the reference status of memory blocks, memory can be divided into cached memory, leaked memory, abandoned memory and Zombies memory. Leaked memory and abandoned memory are the main reasons for memory growth, and the use of zombie memory will lead to program crash

Cached memory: Memory still referenced by your application that might be used again for better performance.
Leaked memory: Memory unreferenced by your application that cannot be used again or freed (also detectable by using the Leaks instrument).
Abandoned memory: Memory still referenced by your application that has no useful purpose.
Zombies: objects that are called after they’ve been released and no longer exist

Memory leak: the memory is not released and there is no corresponding reference, which can be detected by leaks tool.
Common situations: there is no corresponding release for retain in MRC, which generally occurs in arc. Most of these situations are that C related objects do not call the corresponding release method

Example 1:
NSString * testStr = (__bridge NSString *)(CFURLCreateStringByAddingPercentEscapes(kCFAllocatorDefault,(CFStringRef)[NSString stringWithFormat:@"%@",self],NULL,CFSTR("!*'();:@&=+$,/?%#[]"),kCFStringEncodingUTF8));
// CFRelease(testStr);
Example 2:
CGImageRef imageRef = CGImageCreateWithImageInRect([[UIImage imageNamed:@"xxx"] CGImage], CGRectZero);
// CFRelease(imageRef);

Obsolete memory: the memory has no valid reference and cannot be used by the program. It cannot be detected by leaks. It can be analyzed by allocations
Common situations: mainly circular references and strong holding of resident objects. For example, delegate is declared as a strong reference, attribute block holds a circular reference caused by external variables, nstimer is not released in time, etc

Example 1:
self.callback = ^ {

Example 2:
self.timer = [NSTimer scheduledTimerWithTimeInterval:1 target:self selector:@selector(task) userInfo:nil repeats:YES];
// [self.timer invalidate];
//It should be noted that if the object is strongly referenced by runloop due to timer, the timer will not take effect in dealloc of the object. Because the object will not be released due to strong reference, dealloc will not be called

Zombie memory: the object memory has been released, and there are still corresponding references pointing to this part of the area. Using this part of the area by reference may cause exc_ BAD_ Access exception
Common situations: released objects execute release or receive other calls; Object is used without being strongly referenced after creation

1、 Memory leak troubleshooting

1.1 static analysis

Through the Xcode analyze function, statically analyze the code and select the Xcode Project menu product – analyze. The static analysis can analyze the useless variables of the program, branches that cannot be executed, abandoned interfaces, static memory leaks, etc
Note: pod install is required to switch from cocoapods debug to release, otherwise release may not be generated xcconfig

IOS memory leak

1.2 runtime analysis leaks & allocations

Use Xcode leak tool to analyze the code when running Xcode. Select product – profile, install the program to the real machine in the form of profile, open leaks in instruments, select the recording button in the upper left corner, and select the corresponding program to start the analysis

Common settings:
Call tree: check the source of the leak by calling the stack
Invert call tree: invert the call stack to directly display the leaked call at the top level
Hide system libraries: hide the symbols related to the system library. Since there is no symbolic information, it is recommended to hide it
Automatic snapshot: automatic scanning, which takes a long time. Large clients are recommended to turn off automatic scanning, increase the scanning interval, or use manual snapshot, otherwise it may get stuck and the program will exit abnormally
Memory snapshot: now scan once

IOS memory leak

IOS memory leak

Note: if the symbolic stack information cannot be displayed, you need to check whether the corresponding dsym is generated under release in the project configuration

IOS memory leak