MLeaksFinder is an open source iOS memory leak detection framework by the WeRead team. It is as simple as adding a file to the project and automatically popping up an alert after 3 seconds to catch a recurring reference if there is a memory leak. This makes it possible to quickly find 80% of memory leaks during development, while using Xcode Leak tool is more suitable for large scale, full Leak finding.

MLeaksFinder can help you find memory leaks during the development phase of your iOS app. It can automatically detect leaks in UIView and UIViewController objects, and when memory leaks occur, it will automatically break and print out leaked objects in the View-ViewController stack. You can also use it to detect memory leaks in other types of objects.

Summary of causes of memory leaks

The ARC project can override the dealloc method, and when the object is released, it will be called, but there is no need to manually call the parent class dealloc, when the super dealloc method will be called, because the system will automatically call the parent class dealloc method, there is no need to rewrite; However, sometimes the dealloc method will not be called when the controller is out of the stack. After all, the controller is strongly referenced by some objects, and the reference count of the controller is not 0. Therefore, the system cannot automatically release this part of the memory, so the controller cannot release it actively.

features

Reading the description of MLeaksFinder, you can see that it has the following features

  1. No invasive
  2. A leak stack can be built
  3. Whitelist mechanism
  4. expanding
  5. Some other special treatments
The controller is strongly referenced for:

1. Improper use of block blocks leads to circular references. Because a block automatically retains variables in a method once. References to external variables require __block and calls to self require __weak

The NSTimer used by the controller needs to be destroyed before viewWillDisappear.

Because target:self, which refers to the current viewController, increases the controller’s reference count by one, if the NSTimer is not destroyed, it will keep the viewController unreleased and will not call the dealloc method. So, you need to destroy the NSTimer that your controller is using before viewWillDisappear.

Destruction method:

[timer invalidate]; // Destroy timer timer = nil; / / set to nilCopy the code

3. The proxy in a viewController is not weak. For example, the proxy uses weak references

@property (nonatomic, weak) id delegate;
Copy the code

Because the agent is strongly referenced by the controller, it needs to use weak references itself

Let’s just wait for something more.

But in some cases, such as some custom classes, webBridge situation, will encounter clearly can not find no release problem, but still stubborn display, this is very unfriendly, in this case we need some special treatment:

Exception Mechanism (whitelist)

For some UIView/UIViewControllers, after being popped or dismissed, they will not be released (such as singletons), so you need to provide a mechanism to specify which object will not be released.

1. Override the -willDealloc method of this class and return NO. Applies to custom classes.

- (BOOL)willDealloc {
    return NO;
}
Copy the code

2. Add a class name whitelist. Applies to non-custom classes.

[NSObject addClassNamesToWhitelist:@[NSStringFromClass([self class])]];
Copy the code

extension

MLeaksFinder can be extended to find circular references to classes other than UIView/UIViewController.

For example, to check whether the viewModel property in UIViewController is freed:

- (BOOL)willDealloc {
    if(! [super willDealloc]) {return NO;
    }

    MLCheck(self.viewModel);
    return YES;
}
Copy the code