[TOC]
簡介
MLeaksFinder 是WeRead團(tuán)隊(duì)開源的一款檢測 iOS 內(nèi)存泄漏的框架，其使用非常簡單，只需將文件加入項(xiàng)目中，如果有內(nèi)存泄漏，3秒后自動(dòng)彈出 alert 來捕捉循環(huán)引用。使得可以在開發(fā)快速找到80%內(nèi)存泄漏，而使用 Xcode Leak 工具更適合大范圍的，全部的尋找泄漏點(diǎn)。
特性
通過閱讀 MLeaksFinder 的介紹可以看出其具有以下幾個(gè)特性
- 無侵入性
- 可以構(gòu)建泄漏堆棧
- 有白名單機(jī)制
- 擴(kuò)展性
- 其他的一些特殊處理
深入源碼
實(shí)現(xiàn)的核心
在 MLeaksFinder 的博客介紹中可以清晰的知道其的工作原理，引用博文所說
MLeaksFinder 一開始從 UIViewController 入手。我們知道，當(dāng)一個(gè) UIViewController 被 pop 或 dismiss 后，該 UIViewController 包括它的 view，view 的 subviews 等等將很快被釋放（除非你把它設(shè)計(jì)成單例，或者持有它的強(qiáng)引用，但一般很少這樣做）。于是，我們只需在一個(gè) ViewController 被 pop 或 dismiss 一小段時(shí)間后，看看該 UIViewController，它的 view，view 的 subviews 等等是否還存在。
具體的方法是，為基類 NSObject 添加一個(gè)方法 -willDealloc 方法，該方法的作用是，先用一個(gè)弱指針指向 self，并在一小段時(shí)間(3秒)后，通過這個(gè)弱指針調(diào)用 -assertNotDealloc，而 -assertNotDealloc 主要作用是直接中斷言。這樣，當(dāng)我們認(rèn)為某個(gè)對(duì)象應(yīng)該要被釋放了，在釋放前調(diào)用這個(gè)方法，如果3秒后它被釋放成功，weakSelf 就指向 nil，不會(huì)調(diào)用到 -assertNotDealloc 方法，也就不會(huì)中斷言，如果它沒被釋放（泄露了），-assertNotDealloc 就會(huì)被調(diào)用中斷言。這樣，當(dāng)一個(gè) UIViewController 被 pop 或 dismiss 時(shí)（我們認(rèn)為它應(yīng)該要被釋放了），我們遍歷該 UIViewController 上的所有 view，依次調(diào) -willDealloc，若3秒后沒被釋放，就會(huì)中斷言。
總結(jié)起來一句話就是，當(dāng)一個(gè)對(duì)象3秒之后還沒釋放，那么指向它的 weak 指針還是存在的，所以可以調(diào)用其 runtime 綁定的方法 willDealloc 從而提示內(nèi)存泄漏。
接下來我們來看看具體實(shí)現(xiàn)
尋找釋放點(diǎn)
論無侵入性的最佳實(shí)踐還是使用 AOP 面向切面的編程，通過 Method Swizzling 系統(tǒng)方法來添加額外的功能。
在 MLeaksFinder 中，其 Swizzling 了幾個(gè) ViewController 釋放方法
// UIViewController 的方法
[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: 方法來跟蹤一個(gè) modal viewcontroller 的釋放
// UINavigationController
[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:)];
而在 UINavigationController 方面，hook 了 pushViewController:animated:、 popViewControllerAnimated:、popToViewController:animated:、popToRootViewControllerAnimated:方法來追蹤一個(gè) UINavigationController 棧的釋放。
然而代碼中沒發(fā)現(xiàn) UIPageViewController、UISplitViewController等方法的 hook ，可以自己實(shí)現(xiàn)來擴(kuò)展此。
追蹤泄漏
willDealloc是一個(gè)重要的方法。在之前的追蹤到一個(gè)頁面需要釋放的時(shí)候會(huì)調(diào)用此方法， 而這個(gè)方法做了什么呢？，在 NSObject 的 MemoryLeak 分類里面可以找到這個(gè)答案。
NSString *className = NSStringFromClass([self class]);
if ([[NSObject classNamesInWhiteList] 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;
代碼清晰易懂，其原理是首先判斷這個(gè) class 是不是在白名單之中，如果是則忽略它， 這也就是上文提過的白名單機(jī)制了，下面一段代碼很有意思，
NSNumber *senderPtr = objc_getAssociatedObject([UIApplication sharedApplication], kLatestSenderKey);
這個(gè)方法是干嘛的呢，這就得提到 UIControl 的target-action 機(jī)制了，具體可以參考這篇文章。此段代碼的意義在與，如果當(dāng)前的對(duì)象在發(fā)送 action 則忽略它（因?yàn)?willDealloc 總會(huì)先于他們調(diào)用）， 之后設(shè)置一個(gè) weak 指針，在調(diào)用 dispatch_after 在2秒后調(diào)用 assertNotDealloc 方法，如果還沒釋放，那么會(huì)進(jìn)入這個(gè)方法，如果已經(jīng)釋放了，那么這個(gè)方法是進(jìn)不去的。
報(bào)告泄漏
當(dāng)進(jìn)入 assertNotDealloc 方法，很不幸，這個(gè)對(duì)象極有可能是泄漏了，這個(gè)時(shí)候應(yīng)該做的報(bào)告此處發(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 是如何報(bào)告的呢，我們一步步追蹤，
首先
if ([MLeakedObjectProxy isAnyObjectLeakedAtPtrs:[self parentPtrs]]) {
return;
}
這個(gè)是什么東西，
@interface MLeakedObjectProxy : NSObject
+ (BOOL)isAnyObjectLeakedAtPtrs:(NSSet *)ptrs;
+ (void)addLeakedObject:(id)object;
@end
可以看出這個(gè)是泄漏對(duì)象的代理，這個(gè)對(duì)象只有2個(gè)類方法，分別是做什么的呢，先來看 isAnyObjectLeakedAtPtrs 這個(gè)方法
+ (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;
}
}
結(jié)合上文中的 assertNotDealloc 方法可以看出，這個(gè)方法主要是判斷當(dāng)前這個(gè)對(duì)象時(shí)候已經(jīng)添加到了泄漏對(duì)象名單，如果是，那么就不在添加了。
還有一個(gè) addLeakedObject 方法，看名字不難看出是將泄漏對(duì)象添加到泄漏對(duì)象名單，以下下是其具體實(shí)現(xiàn)
+ (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)造了一個(gè) MLeakedObjectProxy 對(duì)象，并將其加入到 leakedObjectPtrs 集合中，彈出 alert 框，然后需要找到引用環(huán)，將此對(duì)象指針傳給 FBRetainCycleDetector 來確定循環(huán)引用發(fā)生在哪里（這塊功能是0.2版本新增的）。之后在屏幕上打印出堆棧信息，看到這里，還有一個(gè)疑問：MLeaksFinder 是如何構(gòu)建堆棧？
構(gòu)建堆棧信息
我們可以注意到，在 UIViewController 的分類中有這樣一段代碼
- (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，就是構(gòu)造堆棧信息的秘密所在，我們可以看到 NSObject 分類中的實(shí)現(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];
}
}
- (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);
}
willReleaseChildren 和 willReleaseChild 方法的作用是向這個(gè)對(duì)象之中的子對(duì)象調(diào)用釋放的方法，如 view 的 subviews， UINavigationController 的 viewcontrollers 等等的子對(duì)象。構(gòu)造堆棧信息的原理就是，遞歸遍歷子對(duì)象，然后將父對(duì)象 class name 加上子對(duì)象 class name，一步步構(gòu)造出一個(gè) view stack。出現(xiàn)泄漏則直接打印此對(duì)象的 view stack 即可。
其他
在 UIViewController 側(cè)滑的時(shí)候釋放方法需要做特殊的處理,在 MLeaksFinder 中添加了 kHasBeenPoppedKey 屬性來判斷是否釋放代碼如下
//設(shè)置側(cè)滑的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
...
// 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;
}
//發(fā)現(xiàn)是側(cè)滑則直接調(diào)用willDealloc方法
- (void)swizzled_viewDidDisappear:(BOOL)animated {
[self swizzled_viewDidDisappear:animated];
if ([objc_getAssociatedObject(self, kHasBeenPoppedKey) boolValue]) {
[self willDealloc];
}
}
總結(jié)
總得來說 MLeaksFinder 是一個(gè)質(zhì)量很高的庫，在實(shí)用性和便利性上做到了完美結(jié)合，日常開發(fā)中也為我們的項(xiàng)目尋找到了泄漏點(diǎn)，值得一用，至于 FBRetainCycleDetector 如何檢測循環(huán)引用環(huán)，那得發(fā)一篇文章的篇幅來介紹了
