目錄
- 使用實例
- 原理分析
- 特性
- 深入源碼
- 尋找釋放點
- 追蹤泄露
- 報告泄露
- 構建堆棧信息
- 側滑返回特殊處理
序言
MLeaksFinder 是WeRead團隊開源的一款檢測 iOS 內存泄漏的框架,其使用非常簡單,只需將文件加入項目中,如果有內存泄漏,2秒后自動彈出 alert 來捕捉循環(huán)引用。使得可以在開發(fā)快速找到大多數內存泄漏,而使用 Xcode Leak 工具更適合大范圍的,全部的尋找泄漏點。
WeRead團隊博客關于MLeaksFinder的介紹
MLeaksFinder:精準 iOS 內存泄露檢測工具
一 使用實例
1.直接將MLeaksFinder文件夾導入項目中或者使用pod 'MLeaksFinder'都可以
-
ViewControllerpush進FirstViewController頁面,然后在FirstViewController開啟一個定時器,然后點擊返回。
@property(nonatomic,strong)NSTimer *timer;
- (void)addTimer {
_timer = [NSTimer timerWithTimeInterval:1.0 target:self selector:@selector(updateTimer) userInfo:nil repeats:YES];
[[NSRunLoop mainRunLoop] addTimer:_timer forMode:NSRunLoopCommonModes];
}
- (void)updateTimer {
NSLog(@"%s",__func__);
}
執(zhí)行結果

二 原理分析
在 MLeaksFinder 的博客介紹中可以清晰的知道其的工作原理,引用博文所說
MLeaksFinder 一開始從 UIViewController 入手。我們知道,當一個 UIViewController 被 pop 或 dismiss 后,該 UIViewController 包括它的 view,view 的 subviews 等等將很快被釋放(除非你把它設計成單例,或者持有它的強引用,但一般很少這樣做)。于是,我們只需在一個 ViewController 被 pop 或 dismiss 一小段時間后,看看該 UIViewController,它的 view,view 的 subviews 等等是否還存在。
具體的方法是,為基類 NSObject 添加一個方法 -willDealloc 方法,該方法的作用是,先用一個弱指針指向 self,并在一小段時間(2秒)后,通過這個弱指針調用 -assertNotDealloc,而 -assertNotDealloc 主要作用是直接中斷言。
- (BOOL)willDealloc {
__weak id weakSelf = self;
dispatch_after(dispatch_time(DISPATCH_TIME_NOW, (int64_t)(2 * NSEC_PER_SEC)), dispatch_get_main_queue(), ^{
[weakSelf assertNotDealloc];
});
return YES;
}
- (void)assertNotDealloc {
NSAssert(NO, @“”);
}
這樣,當我們認為某個對象應該要被釋放了,在釋放前調用這個方法,如果2秒后它被釋放成功,weakSelf 就指向 nil,不會調用到 -assertNotDealloc 方法,也就不會中斷言,如果它沒被釋放(泄露了),-assertNotDealloc 就會被調用中斷言。這樣,當一個 UIViewController 被 pop 或 dismiss 時(我們認為它應該要被釋放了),我們遍歷該 UIViewController 上的所有 view,依次調 -willDealloc,若2秒后沒被釋放,就會中斷言。
總結起來一句話就是,當一個對象3秒之后還沒釋放,那么指向它的 weak 指針還是存在的,所以可以調用其 runtime 綁定的方法 willDealloc 從而提示內存泄漏。
三 特性
通過閱讀 MLeaksFinder 的介紹可以看出其具有以下幾個特性
- 無侵入性
- 可以構建泄漏堆棧
- 有白名單機制
- 擴展性
- 其他的一些特殊處理
四 深入源碼
先看看文件目錄結構

通過文件目錄結構,我們知道MLeaksFinder主要是實現(xiàn)了幾個重要類的分類,包括UINavigationController,UITabBarController,UIViewController,UIView,NSObject,UIApplication等分類。
4.1 尋找釋放點
論無侵入性的最佳實踐還是使用 AOP 面向切面的編程,通過 Method Swizzling 系統(tǒng)方法來添加額外的功能。
接下來我們以UIViewController為例
-
UIViewController+MemoryLeak.h,其 Swizzling 了幾個 ViewController 釋放方法
[self swizzleSEL:@selector(viewDidDisappear:) withSEL:@selector(swizzled_viewDidDisappear:)];
[self swizzleSEL:@selector(viewWillAppear:) withSEL:@selector(swizzled_viewWillAppear:)];
[self swizzleSEL:@selector(dismissViewControllerAnimated:completion:) withSEL:@selector(swizzled_dismissViewControllerAnimated:completion:)];
通過替換viewDidDisappear、viewWillAppear、dismissViewControllerAnimated:completion:方法來跟蹤一個viewcontroller 的釋放
- (void)swizzled_viewDidDisappear:(BOOL)animated {
[self swizzled_viewDidDisappear:animated];
if ([objc_getAssociatedObject(self, kHasBeenPoppedKey) boolValue]) {
[self willDealloc];
}
}
- (void)swizzled_viewWillAppear:(BOOL)animated {
[self swizzled_viewWillAppear:animated];
objc_setAssociatedObject(self, kHasBeenPoppedKey, @(NO), OBJC_ASSOCIATION_RETAIN);
}
在swizzled_viewWillAppear和swizzled_viewDidDisappear里面關聯(lián)了一個變量kHasBeenPoppedKey,其作用是標記當前VC是否出棧,也就是說只有當其出棧后,再在swizzled_viewDidDisappear方法中校驗是否發(fā)生內存泄露才有意義。
該變量kHasBeenPoppedKey只有在當前控制器出棧時才會設置為YES,設置位置在UINavigationController+MemoryLeak分類中
- (UIViewController *)swizzled_popViewControllerAnimated:(BOOL)animated {
UIViewController *poppedViewController = [self swizzled_popViewControllerAnimated:animated];
if (!poppedViewController) {
return nil;
}
// Detail VC in UISplitViewController is not dealloced until another detail VC is shown
if (self.splitViewController &&
self.splitViewController.viewControllers.firstObject == self &&
self.splitViewController == poppedViewController.splitViewController) {
objc_setAssociatedObject(self, kPoppedDetailVCKey, poppedViewController, OBJC_ASSOCIATION_RETAIN);
return poppedViewController;
}
// VC is not dealloced until disappear when popped using a left-edge swipe gesture
extern const void *const kHasBeenPoppedKey;
objc_setAssociatedObject(poppedViewController, kHasBeenPoppedKey, @(YES), OBJC_ASSOCIATION_RETAIN);
return poppedViewController;
}
-
UINavigationController+MemoryLeak.h,Swizzling了幾個常用的pop和push方法
[self swizzleSEL:@selector(pushViewController:animated:) withSEL:@selector(swizzled_pushViewController:animated:)];
[self swizzleSEL:@selector(popViewControllerAnimated:) withSEL:@selector(swizzled_popViewControllerAnimated:)];
[self swizzleSEL:@selector(popToViewController:animated:) withSEL:@selector(swizzled_popToViewController:animated:)];
[self swizzleSEL:@selector(popToRootViewControllerAnimated:) withSEL:@selector(swizzled_popToRootViewControllerAnimated:)];
4.2 追蹤泄漏
通過代碼查找,我們發(fā)現(xiàn)追蹤到一個頁面需要釋放的時候會調用一個叫willDealloc的方法,該方法在 NSObject+MemoryLeak 分類里面, 而這個方法做了什么呢?
- (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;
}
源碼解讀
[[NSObject classNamesWhitelist] containsObject:className]
首先判斷這個 class 是不是在白名單之中,如果是則忽略它, 這也就是上文提過的白名單機制了。
NSNumber *senderPtr = objc_getAssociatedObject([UIApplication sharedApplication], kLatestSenderKey);
if ([senderPtr isEqualToNumber:@((uintptr_t)self)])
return NO;
這個方法是干嘛的呢,這就得提到 UIControl 的target-action 機制了,此段代碼的意義在與,如果當前的對象在發(fā)送 action 則忽略它(因為 willDealloc 總會先于他們調用)。
__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];
});
之后設置一個 weak 指針,在調用 dispatch_after 在2秒后調用 assertNotDealloc 方法,如果還沒釋放,那么會進入這個方法,如果已經釋放了,那么這個方法是進不去的。
4.3 報告泄漏
當進入 assertNotDealloc 方法,很不幸,這個對象極有可能是泄漏了,這個時候應該做的報告此處發(fā)生了泄漏。
- (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]);
}
MLeaksFinder 是如何報告的呢,我們一步步追蹤代碼分析
- 1 是否已經添加進泄漏對象名單
- (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]);
}
- (NSSet *)parentPtrs {
NSSet *parentPtrs = objc_getAssociatedObject(self, kParentPtrsKey);
if (!parentPtrs) {
parentPtrs = [[NSSet alloc] initWithObjects:@((uintptr_t)self), nil];
}
return parentPtrs;
}
這個方法主要是判斷當前這個對象時候已經添加到了泄漏對象名單,如果是,那么就不在添加了,否則就添加。
- MLeakedObjectProxy類中
// 是否添加進內存泄露名單
+ (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;
}
}
// 添加進內存泄露名單
+ (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 對象,并將其加入到 leakedObjectPtrs 集合中,彈出 alert 框,然后需要找到引用環(huán),將此對象指針傳給 FBRetainCycleDetector 來確定循環(huán)引用發(fā)生在哪里(這塊功能是0.2版本新增的)。之后在屏幕上打印出堆棧信息,看到這里,還有一個疑問:MLeaksFinder 是如何構建堆棧?
4.4 構建堆棧信息
我們可以注意到,在 UIViewController 的分類中有這樣一段代碼
- UIViewController+MemoryLeak.h
- (BOOL)willDealloc {
if (![super willDealloc]) {
return NO;
}
[self willReleaseChildren:self.childViewControllers];
[self willReleaseChild:self.presentedViewController];
if (self.isViewLoaded) {
[self willReleaseChild:self.view];
}
return YES;
}
其中willReleaseChildren、willReleaseChild,就是構造堆棧信息的秘密所在,我們可以看到 NSObject+MemoryLeak分類中的實現(xiàn)方法
- (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];
}
}
// 通過關聯(lián)對象kViewStackKey獲取值,如果為空,則創(chuàng)建
- (NSArray *)viewStack {
NSArray *viewStack = objc_getAssociatedObject(self, kViewStackKey);
if (viewStack) {
return viewStack;
}
NSString *className = NSStringFromClass([self class]);
return @[ className ];
}
// 關聯(lián) kViewStackKey 對象,并將viewStack值保存到kViewStackKey中
- (void)setViewStack:(NSArray *)viewStack {
objc_setAssociatedObject(self, kViewStackKey, viewStack, OBJC_ASSOCIATION_RETAIN);
}
// 通過關聯(lián)對象kParentPtrsKey獲取值,如果為空,則創(chuàng)建
- (NSSet *)parentPtrs {
NSSet *parentPtrs = objc_getAssociatedObject(self, kParentPtrsKey);
if (!parentPtrs) {
parentPtrs = [[NSSet alloc] initWithObjects:@((uintptr_t)self), nil];
}
return parentPtrs;
}
// 關聯(lián) kParentPtrsKey 對象,并將viewStack值保存到parentPtrs中
- (void)setParentPtrs:(NSSet *)parentPtrs {
objc_setAssociatedObject(self, kParentPtrsKey, parentPtrs, OBJC_ASSOCIATION_RETAIN);
}
willReleaseChildren 和willReleaseChild 方法的作用是向這個對象之中的子對象調用釋放的方法,如 view 的 subviews, UINavigationController 的 viewcontrollers 等等的子對象。構造堆棧信息的原理就是,遞歸遍歷子對象,然后將父對象 class name 加上子對象 class name,一步步構造出一個 view stack。出現(xiàn)泄漏則直接打印此對象的 view stack 即可。
4.5 側滑返回特殊處理
在 UIViewController 側滑的時候釋放方法需要做特殊的處理,在 MLeaksFinder 中添加了 kHasBeenPoppedKey 屬性來判斷是否釋放代碼如下
// 設置側滑的key
- (UIViewController *)swizzled_popViewControllerAnimated:(BOOL)animated {
UIViewController *poppedViewController = [self swizzled_popViewControllerAnimated:animated];
if (!poppedViewController) {
return nil;
}
// Detail VC in UISplitViewController is not dealloced until another detail VC is shown
if (self.splitViewController &&
self.splitViewController.viewControllers.firstObject == self &&
self.splitViewController == poppedViewController.splitViewController) {
objc_setAssociatedObject(self, kPoppedDetailVCKey, poppedViewController, OBJC_ASSOCIATION_RETAIN);
return poppedViewController;
}
// VC is not dealloced until disappear when popped using a left-edge swipe gesture
extern const void *const kHasBeenPoppedKey;
objc_setAssociatedObject(poppedViewController, kHasBeenPoppedKey, @(YES), OBJC_ASSOCIATION_RETAIN);
return poppedViewController;
}
總結
總得來說 MLeaksFinder 是一個質量很高的庫,在實用性和便利性上做到了完美結合,日常開發(fā)中也為我們的項目尋找到了泄漏點。
本文參考
MLeaksFinder
MLeaksFinder:精準 iOS 內存泄露檢測工具