对于iOS开发者而言，内存泄漏是一个老生常谈的问题，包括日常开发和面试过程中，都会涉及到这方面的知识。
当然Xcode提供了Instrument工具，我们一般都会用Leaks / Allocations来排查内存泄漏，网上也有一些开源库来进行内存泄漏的排查

MLeaksFinder - 简介

MLeaksFinder 是 WeRead 团队开源的iOS内存泄漏检测工具，wereadteam博客，GitHub。

MLeaksFinder 提供了内存泄露检测更好的解决方案。引进 MLeaksFinder 后，就可以在日常的开发，调试业务逻辑的过程中自动地发现并警告内存泄漏。开发者无需打开 Instrument 等工具，也无需为了找内存泄漏而去跑额外的流程。并且，由于开发者是在修改代码之后一跑业务逻辑就能发现内存泄漏的，这使得开发者能很快地意识到是哪里的代码写得问题。这种及时的内存泄漏的发现在很大的程度上降低了修复内存泄漏的成本。

当发生内存泄漏时，MLeaksFinder会用弹窗alert的形式告诉开发者内存泄漏的对象，开发者可以把alert关掉，并继续调试业务逻辑。

MLeaksFinder - 使用方式

把 MLeaksFinder 目录下的文件添加到你的项目中，就可以在运行时（debug 模式下）帮助你检测项目里的内存泄露了，无需修改任何业务逻辑代码，而且只在 debug 下开启，完全不影响你的 release 包。

引入MLeaksFinder可选择用CocoaPods安装，安装时注意有没有warnings，特别是 OTHER_LDFLAGS 相关的 warnings。如果有 warnings，可以在主工程的 Build Settings -> Other Linker Flags 加上 -ObjC。

亦可手动引入，直接把 MLeaksFinder 的代码放到项目里即生效。如果把 MLeaksFinder 做为子工程，需要在主工程的 Build Settings -> Other Linker Flags 加上 -ObjC。

引入后，先验证引入是否成功，在UIViewController+MemoryLeak.m的+ (void)load方法中添加断点，app启用时进入该方法便引入成功。

引进 MLeaksFinder 的代码后即可检测内存泄漏，但查找循环引用的功能还未生效。可以再手动加入 FBRetainCycleDetector 代码，然后把 MLeaksFinder.h 里的 //#define MEMORY_LEAKS_FINDER_RETAIN_CYCLE_ENABLED 1 打开。

MLeaksFinder 默认只在 debug 下生效，当然也可以通过 MLeaksFinder.h 里的 //#define MEMORY_LEAKS_FINDER_ENABLED 0 来手动控制开关。

MLeaksFinder - 原理

从UIViewController入手，当一个UIViewController被pop或者dismiss后，该VC包括它的子View，或者子view的子view等等都会很快的被释放（除非设计成单例，或者持有它的强引用，但一般很少这样做）。于是，我们只需在一个ViewController被pop或者dismiss一小段时间后，看看该VC，它的subViews等是否还存在。

通过UIViewController+MemoryLeak.h的load方法可以看出，交换了viewDidDisappear:、viewWillAppear:、dismissViewControllerAnimated:completion:三个方法。

下面分析一下方法viewDidDisappear：

- (void)swizzled_viewDidDisappear:(BOOL)animated {
    [self swizzled_viewDidDisappear:animated];
    
    if ([objc_getAssociatedObject(self, kHasBeenPoppedKey) boolValue]) {
        [self willDealloc];
    }
}

调用了当前类的-willDealloc方法，

- (BOOL)willDealloc {
    if (![super willDealloc]) {
        return NO;
    }
    
    [self willReleaseChildren:self.childViewControllers];
    [self willReleaseChild:self.presentedViewController];
    
    if (self.isViewLoaded) {
        [self willReleaseChild:self.view];
    }
    
    return YES;
}

通过super调用父类的-willDealloc，重点说明一下该方法

- (BOOL)willDealloc {
    NSString *className = NSStringFromClass([self class]);
    if ([[NSObject classNamesWhitelist] containsObject:className])
        return NO;
    
    NSNumber *senderPtr = objc_getAssociatedObject([UIApplication sharedApplication], kLatestSenderKey);
    if ([senderPtr isEqualToNumber:@((uintptr_t)self)])
        return NO;
    
    __weak id weakSelf = self;
    dispatch_after(dispatch_time(DISPATCH_TIME_NOW, (int64_t)(2 * NSEC_PER_SEC)), dispatch_get_main_queue(), ^{
        __strong id strongSelf = weakSelf;
        [strongSelf assertNotDealloc];
    });
    
    return YES;
}

• 第一步：首先通过classNamesWhitelist检测白名单，如果对象在白名单之中，便return NO，即不是内存泄漏。

构建基础白名单时，使用了单例，确保只有一个，这个方法是私有的。

+ (NSMutableSet *)classNamesWhitelist {
    static NSMutableSet *whitelist = nil;
    static dispatch_once_t onceToken;
    dispatch_once(&onceToken, ^{
        whitelist = [NSMutableSet setWithObjects:
                     @"UIFieldEditor", // UIAlertControllerTextField
                     @"UINavigationBar",
                     @"_UIAlertControllerActionView",
                     @"_UIVisualEffectBackdropView",
                     nil];
        
        // System's bug since iOS 10 and not fixed yet up to this ci.
        NSString *systemVersion = [UIDevice currentDevice].systemVersion;
        if ([systemVersion compare:@"10.0" options:NSNumericSearch] != NSOrderedAscending) {
            [whitelist addObject:@"UISwitch"];
        }
    });
    return whitelist;
}

同时，在NSObject+MemoryLeak.h文件中提供了一个方法，使得我们可以自定义白名单

+ (void)addClassNamesToWhitelist:(NSArray *)classNames {
    [[self classNamesWhitelist] addObjectsFromArray:classNames];
}

• 第二步：判断该对象是否是上一次发送action的对象，是的话，不进行内存检测

    NSNumber *senderPtr = objc_getAssociatedObject([UIApplication sharedApplication], kLatestSenderKey);
    if ([senderPtr isEqualToNumber:@((uintptr_t)self)])
        return NO;

• 第三步：弱指针指向self，2s延迟，然后通过这个弱指针调用-assertNotDealloc，若被释放，给nil发消息直接返回，不触发-assertNotDealloc方法，认为已经释放；如果它没有被释放（泄漏了），-assertNotDealloc就会被调用

__weak id weakSelf = self;
    dispatch_after(dispatch_time(DISPATCH_TIME_NOW, (int64_t)(2 * NSEC_PER_SEC)), dispatch_get_main_queue(), ^{
        __strong id strongSelf = weakSelf;
        [strongSelf assertNotDealloc];
    });

assertNotDealloc方法放在最后再谈

接着会调用-willReleaseChildren、-willReleaseChild遍历该对象的子对象，判断是否释放

- (void)willReleaseChild:(id)child {
    if (!child) {
        return;
    }
    
    [self willReleaseChildren:@[ child ]];
}

- (void)willReleaseChildren:(NSArray *)children {
    NSArray *viewStack = [self viewStack];
    NSSet *parentPtrs = [self parentPtrs];
    for (id child in children) {
        NSString *className = NSStringFromClass([child class]);
        [child setViewStack:[viewStack arrayByAddingObject:className]];
        [child setParentPtrs:[parentPtrs setByAddingObject:@((uintptr_t)child)]];
        [child willDealloc];
    }
}

通过代码可以看出，-willReleaseChildren拿到当前对象的viewStack和parentPtrs，然后遍历children，为每个子对象设置viewStack和parentPtrs。
然后会执行[child willDealloc]，去检测子类。

这里结合源码看下viewStack与parentPtrs的get和set实现方法

- (NSArray *)viewStack {
    NSArray *viewStack = objc_getAssociatedObject(self, kViewStackKey);
    if (viewStack) {
        return viewStack;
    }
    
    NSString *className = NSStringFromClass([self class]);
    return @[ className ];
}

- (void)setViewStack:(NSArray *)viewStack {
    objc_setAssociatedObject(self, kViewStackKey, viewStack, OBJC_ASSOCIATION_RETAIN);
}

- (NSSet *)parentPtrs {
    NSSet *parentPtrs = objc_getAssociatedObject(self, kParentPtrsKey);
    if (!parentPtrs) {
        parentPtrs = [[NSSet alloc] initWithObjects:@((uintptr_t)self), nil];
    }
    return parentPtrs;
}

- (void)setParentPtrs:(NSSet *)parentPtrs {
    objc_setAssociatedObject(self, kParentPtrsKey, parentPtrs, OBJC_ASSOCIATION_RETAIN);
}

两者实现方法类似，通过运行时机制，即利用关联对象给一个类添加属性信息，只不过前者是一个数组，后者是一个集合。

关联对象parentPtrs，会在-assertNotDealloc中，会判断当前对象是否与父节点集合有交集。下面仔细看下-assertNotDealloc方法

- (void)assertNotDealloc {
    if ([MLeakedObjectProxy isAnyObjectLeakedAtPtrs:[self parentPtrs]]) {
        return;
    }
    [MLeakedObjectProxy addLeakedObject:self];
    
    NSString *className = NSStringFromClass([self class]);
    NSLog(@"Possibly Memory Leak.\nIn case that %@ should not be dealloced, override -willDealloc in %@ by returning NO.\nView-ViewController stack: %@", className, className, [self viewStack]);
}

这里调用了MLeakedObjectProxy类中的+isAnyObjectLeakedAtPtrs

+ (BOOL)isAnyObjectLeakedAtPtrs:(NSSet *)ptrs {
    NSAssert([NSThread isMainThread], @"Must be in main thread.");
    
    static dispatch_once_t onceToken;
    dispatch_once(&onceToken, ^{
        leakedObjectPtrs = [[NSMutableSet alloc] init];
    });
    
    if (!ptrs.count) {
        return NO;
    }
    if ([leakedObjectPtrs intersectsSet:ptrs]) {
        return YES;
    } else {
        return NO;
    }
}

该方法中初始化了一个单例对象leakedObjectPtrs，通过leakedObjectPtrs与传入的参数[self parentPtrs]检测他们的交集，传入的 ptrs 中是否是泄露的对象。

如果上述方法返回的是NO，则继续调用下面方法+addLeakedObject

+ (void)addLeakedObject:(id)object {
    NSAssert([NSThread isMainThread], @"Must be in main thread.");
    
    MLeakedObjectProxy *proxy = [[MLeakedObjectProxy alloc] init];
    proxy.object = object;
    proxy.objectPtr = @((uintptr_t)object);
    proxy.viewStack = [object viewStack];
    static const void *const kLeakedObjectProxyKey = &kLeakedObjectProxyKey;
    objc_setAssociatedObject(object, kLeakedObjectProxyKey, proxy, OBJC_ASSOCIATION_RETAIN);
    
    [leakedObjectPtrs addObject:proxy.objectPtr];
    
#if _INTERNAL_MLF_RC_ENABLED
    [MLeaksMessenger alertWithTitle:@"Memory Leak"
                            message:[NSString stringWithFormat:@"%@", proxy.viewStack]
                           delegate:proxy
              additionalButtonTitle:@"Retain Cycle"];
#else
    [MLeaksMessenger alertWithTitle:@"Memory Leak"
                            message:[NSString stringWithFormat:@"%@", proxy.viewStack]];
#endif
}

第一步：构造MLeakedObjectProxy对象，给传入的泄漏对象 object 关联一个代理即 proxy

第二步：通过objc_setAssociatedObject(object, kLeakedObjectProxyKey, proxy, OBJC_ASSOCIATION_RETAIN)方法，object强持有proxy， proxy若持有object，如果object释放，proxy也会释放

第三步：存储 proxy.objectPtr（实际是对象地址）到集合 leakedObjectPtrs 里边

第四步：弹框 AlertView若 _INTERNAL_MLF_RC_ENABLED == 1，则弹框会增加检测循环引用的选项；若 _INTERNAL_MLF_RC_ENABLED == 0，则仅展示堆栈信息。

对于MLeakedObjectProxy类而言，是检测到内存泄漏才产生的，作为泄漏对象的属性存在的，如果泄漏的对象被释放，那么MLeakedObjectProxy也会被释放，则调用-dealloc函数

集合leakedObjectPtrs中移除该对象地址，同时再次弹窗，提示该对象已经释放了

- (void)dealloc {
    NSNumber *objectPtr = _objectPtr;
    NSArray *viewStack = _viewStack;
    dispatch_async(dispatch_get_main_queue(), ^{
        [leakedObjectPtrs removeObject:objectPtr];
        [MLeaksMessenger alertWithTitle:@"Object Deallocated"
                                message:[NSString stringWithFormat:@"%@", viewStack]];
    });
}

当点击弹框中的检测循环引用按钮时，相关的操作都在下面 AlertView 的代理方法里边，即异步地通过 FBRetainCycleDetector 检测循环引用，然后回到主线程，利用弹框提示用户检测结果。

image.png

同时控制台会有相关输出

image.png

可以快速定位到内存泄漏的位置。

另外，针对一些特殊情况：

• 有时候即使调了pop，dismiss，也不会被释放，比如单例。如果某个特别的对象不会被释放，开发者可以重写willDealloc，return NO
• 部分系统的view是不会被释放的，需要建立白名单
• MLeaksFinder支持手动扩展，通过MLCheck()宏来检测其他类型的对象的内存泄露，为传进来的对象建立View-ViewController stack信息
• 结合FBRetainCycleDetector一起使用时：
  • 内存泄漏不一定是循环引用造成的
  • 有的循环引用 FBRetainCycleDetector 不一定能找出

原文地址：
原文地址传送

参考资料：

MLeaksFinder：精准 iOS 内存泄露检测工具

MLeaksFinder 新特性

MLeaksFinder- GitHub