對(duì)于iOS開(kāi)發(fā)者而言，內(nèi)存泄漏是一個(gè)老生常談的問(wèn)題，包括日常開(kāi)發(fā)和面試過(guò)程中，都會(huì)涉及到這方面的知識(shí)。
當(dāng)然Xcode提供了Instrument工具，我們一般都會(huì)用Leaks / Allocations來(lái)排查內(nèi)存泄漏，網(wǎng)上也有一些開(kāi)源庫(kù)來(lái)進(jìn)行內(nèi)存泄漏的排查

MLeaksFinder - 簡(jiǎn)介

MLeaksFinder 是 WeRead 團(tuán)隊(duì)開(kāi)源的iOS內(nèi)存泄漏檢測(cè)工具，wereadteam博客，GitHub。

MLeaksFinder 提供了內(nèi)存泄露檢測(cè)更好的解決方案。引進(jìn) MLeaksFinder 后，就可以在日常的開(kāi)發(fā)，調(diào)試業(yè)務(wù)邏輯的過(guò)程中自動(dòng)地發(fā)現(xiàn)并警告內(nèi)存泄漏。開(kāi)發(fā)者無(wú)需打開(kāi) Instrument 等工具，也無(wú)需為了找內(nèi)存泄漏而去跑額外的流程。并且，由于開(kāi)發(fā)者是在修改代碼之后一跑業(yè)務(wù)邏輯就能發(fā)現(xiàn)內(nèi)存泄漏的，這使得開(kāi)發(fā)者能很快地意識(shí)到是哪里的代碼寫(xiě)得問(wèn)題。這種及時(shí)的內(nèi)存泄漏的發(fā)現(xiàn)在很大的程度上降低了修復(fù)內(nèi)存泄漏的成本。

當(dāng)發(fā)生內(nèi)存泄漏時(shí)，MLeaksFinder會(huì)用彈窗alert的形式告訴開(kāi)發(fā)者內(nèi)存泄漏的對(duì)象，開(kāi)發(fā)者可以把alert關(guān)掉，并繼續(xù)調(diào)試業(yè)務(wù)邏輯。

MLeaksFinder - 使用方式

把 MLeaksFinder 目錄下的文件添加到你的項(xiàng)目中，就可以在運(yùn)行時(shí)（debug 模式下）幫助你檢測(cè)項(xiàng)目里的內(nèi)存泄露了，無(wú)需修改任何業(yè)務(wù)邏輯代碼，而且只在 debug 下開(kāi)啟，完全不影響你的 release 包。

引入MLeaksFinder可選擇用CocoaPods安裝，安裝時(shí)注意有沒(méi)有warnings，特別是 OTHER_LDFLAGS 相關(guān)的 warnings。如果有 warnings，可以在主工程的 Build Settings -> Other Linker Flags 加上 -ObjC。

亦可手動(dòng)引入，直接把 MLeaksFinder 的代碼放到項(xiàng)目里即生效。如果把 MLeaksFinder 做為子工程，需要在主工程的 Build Settings -> Other Linker Flags 加上 -ObjC。

引入后，先驗(yàn)證引入是否成功，在UIViewController+MemoryLeak.m的+ (void)load方法中添加斷點(diǎn)，app啟用時(shí)進(jìn)入該方法便引入成功。

引進(jìn) MLeaksFinder 的代碼后即可檢測(cè)內(nèi)存泄漏，但查找循環(huán)引用的功能還未生效?？梢栽偈謩?dòng)加入 FBRetainCycleDetector 代碼，然后把 MLeaksFinder.h 里的 //#define MEMORY_LEAKS_FINDER_RETAIN_CYCLE_ENABLED 1 打開(kāi)。

MLeaksFinder 默認(rèn)只在 debug 下生效，當(dāng)然也可以通過(guò) MLeaksFinder.h 里的 //#define MEMORY_LEAKS_FINDER_ENABLED 0 來(lái)手動(dòng)控制開(kāi)關(guān)。

MLeaksFinder - 原理

從UIViewController入手，當(dāng)一個(gè)UIViewController被pop或者dismiss后，該VC包括它的子View，或者子view的子view等等都會(huì)很快的被釋放（除非設(shè)計(jì)成單例，或者持有它的強(qiáng)引用，但一般很少這樣做）。于是，我們只需在一個(gè)ViewController被pop或者dismiss一小段時(shí)間后，看看該VC，它的subViews等是否還存在。

通過(guò)UIViewController+MemoryLeak.h的load方法可以看出，交換了viewDidDisappear:、viewWillAppear:、dismissViewControllerAnimated:completion:三個(gè)方法。

下面分析一下方法viewDidDisappear：

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

調(diào)用了當(dāng)前類的-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;
}

通過(guò)super調(diào)用父類的-willDealloc，重點(diǎn)說(shuō)明一下該方法

- (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;
}

• 第一步：首先通過(guò)classNamesWhitelist檢測(cè)白名單，如果對(duì)象在白名單之中，便return NO，即不是內(nèi)存泄漏。

構(gòu)建基礎(chǔ)白名單時(shí)，使用了單例，確保只有一個(gè)，這個(gè)方法是私有的。

+ (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;
}

同時(shí)，在NSObject+MemoryLeak.h文件中提供了一個(gè)方法，使得我們可以自定義白名單

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

• 第二步：判斷該對(duì)象是否是上一次發(fā)送action的對(duì)象，是的話，不進(jìn)行內(nèi)存檢測(cè)

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

• 第三步：弱指針指向self，2s延遲，然后通過(guò)這個(gè)弱指針調(diào)用-assertNotDealloc，若被釋放，給nil發(fā)消息直接返回，不觸發(fā)-assertNotDealloc方法，認(rèn)為已經(jīng)釋放；如果它沒(méi)有被釋放（泄漏了），-assertNotDealloc就會(huì)被調(diào)用

__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方法放在最后再談

接著會(huì)調(diào)用-willReleaseChildren、-willReleaseChild遍歷該對(duì)象的子對(duì)象，判斷是否釋放

- (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];
    }
}

通過(guò)代碼可以看出，-willReleaseChildren拿到當(dāng)前對(duì)象的viewStack和parentPtrs，然后遍歷children，為每個(gè)子對(duì)象設(shè)置viewStack和parentPtrs。
然后會(huì)執(zhí)行[child willDealloc]，去檢測(cè)子類。

這里結(jié)合源碼看下viewStack與parentPtrs的get和set實(shí)現(xiàn)方法

- (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);
}

兩者實(shí)現(xiàn)方法類似，通過(guò)運(yùn)行時(shí)機(jī)制，即利用關(guān)聯(lián)對(duì)象給一個(gè)類添加屬性信息，只不過(guò)前者是一個(gè)數(shù)組，后者是一個(gè)集合。

關(guān)聯(lián)對(duì)象parentPtrs，會(huì)在-assertNotDealloc中，會(huì)判斷當(dāng)前對(duì)象是否與父節(jié)點(diǎn)集合有交集。下面仔細(xì)看下-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]);
}

這里調(diào)用了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;
    }
}

該方法中初始化了一個(gè)單例對(duì)象leakedObjectPtrs，通過(guò)leakedObjectPtrs與傳入的參數(shù)[self parentPtrs]檢測(cè)他們的交集，傳入的 ptrs 中是否是泄露的對(duì)象。

如果上述方法返回的是NO，則繼續(xù)調(diào)用下面方法+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
}

第一步：構(gòu)造MLeakedObjectProxy對(duì)象，給傳入的泄漏對(duì)象 object 關(guān)聯(lián)一個(gè)代理即 proxy

第二步：通過(guò)objc_setAssociatedObject(object, kLeakedObjectProxyKey, proxy, OBJC_ASSOCIATION_RETAIN)方法，object強(qiáng)持有proxy， proxy若持有object，如果object釋放，proxy也會(huì)釋放

第三步：存儲(chǔ) proxy.objectPtr（實(shí)際是對(duì)象地址）到集合 leakedObjectPtrs 里邊

第四步：彈框 AlertView若 _INTERNAL_MLF_RC_ENABLED == 1，則彈框會(huì)增加檢測(cè)循環(huán)引用的選項(xiàng)；若 _INTERNAL_MLF_RC_ENABLED == 0，則僅展示堆棧信息。

對(duì)于MLeakedObjectProxy類而言，是檢測(cè)到內(nèi)存泄漏才產(chǎn)生的，作為泄漏對(duì)象的屬性存在的，如果泄漏的對(duì)象被釋放，那么MLeakedObjectProxy也會(huì)被釋放，則調(diào)用-dealloc函數(shù)

集合leakedObjectPtrs中移除該對(duì)象地址，同時(shí)再次彈窗，提示該對(duì)象已經(jīng)釋放了

- (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]];
    });
}

當(dāng)點(diǎn)擊彈框中的檢測(cè)循環(huán)引用按鈕時(shí)，相關(guān)的操作都在下面 AlertView 的代理方法里邊，即異步地通過(guò) FBRetainCycleDetector 檢測(cè)循環(huán)引用，然后回到主線程，利用彈框提示用戶檢測(cè)結(jié)果。

image.png

同時(shí)控制臺(tái)會(huì)有相關(guān)輸出

image.png

可以快速定位到內(nèi)存泄漏的位置。

另外，針對(duì)一些特殊情況：

• 有時(shí)候即使調(diào)了pop，dismiss，也不會(huì)被釋放，比如單例。如果某個(gè)特別的對(duì)象不會(huì)被釋放，開(kāi)發(fā)者可以重寫(xiě)willDealloc，return NO
• 部分系統(tǒng)的view是不會(huì)被釋放的，需要建立白名單
• MLeaksFinder支持手動(dòng)擴(kuò)展，通過(guò)MLCheck()宏來(lái)檢測(cè)其他類型的對(duì)象的內(nèi)存泄露，為傳進(jìn)來(lái)的對(duì)象建立View-ViewController stack信息
• 結(jié)合FBRetainCycleDetector一起使用時(shí)：
  • 內(nèi)存泄漏不一定是循環(huán)引用造成的
  • 有的循環(huán)引用 FBRetainCycleDetector 不一定能找出

原文地址：
原文地址傳送

參考資料：

MLeaksFinder：精準(zhǔn) iOS 內(nèi)存泄露檢測(cè)工具

MLeaksFinder 新特性

MLeaksFinder- GitHub