内存泄露检测
从苹果的开发者文档里可以看到，一个 app 的内存分三类：
Leaked memory: Memory unreferenced by your application that cannot be used again or freed (also detectable by using the Leaks instrument).
Abandoned memory: Memory still referenced by your application that has no useful purpose.
Cached memory: Memory still referenced by your application that might be used again for better performance.
其中 Leaked memory 和 Abandoned memory 都属于应该释放而没释放的内存，都是内存泄露，而 Leaks 工具只负责检测 Leaked memory，而不管 Abandoned memory。ARC 中更常见的内存泄露是循环引用导致的 Abandoned memory，Leaks 工具查不出这类内存泄露，应用有限。
Allocations通过MarkGeneration检测abandoned memory(仍然被引用但是没用的内存)，操作麻烦，不够及时精准定位，无法及时得知泄露
MLeaksFinder
简介
MLeaksFinder 提供了内存泄露检测更好的解决方案。只需要引入 MLeaksFinder，就可以自动在 App运行过程检测到内存泄露的对象并立即提醒，无需打开额外Instrument等工具，也无需为了检测内存泄露而一个个场景去重复地操作。MLeaksFinder 目前能自动检测 UIViewController 和 UIView 对象的内存泄露，而且也可以扩展以检测其它类型的对象。最重要的是开发者在写完代码之后运行代码就能发现内存泄露，这样可以及时的发现内存泄露，降低了修复内存泄露的成本。当发生内存泄漏时，MLeaksFinder会用弹窗alert的形式告诉开发者内存泄漏的对象，开发者可以把alert关掉，并继续调试业务逻辑。
使用
MLeaksFinder 的使用很简单，参照 github.com/Zepo/MLeaks… 基本上就是把 MLeaksFinder 目录下的文件添加到你的项目中，就可以在运行时（debug 模式下）帮助你检测项目里的内存泄露了，无需修改任何业务逻辑代码，而且只在 debug 下开启，完全不影响你的 release 包。
原理
MLeaksFinder 一开始从 UIViewController 入手。我们知道，当一个 UIViewController 被 pop 或 dismiss 后，该 UIViewController 包括它的 view，view 的 subviews 等等将很快被释放（除非你把它设计成单例，或者持有它的强引用，但一般很少这样做）。于是，我们只需在一个 ViewController 被 pop 或 dismiss 一小段时间后，看看该 UIViewController，它的 view，view 的 subviews 等等是否还存在。
UIViewController+MemoryLeak.h
+ (void)load {
static dispatch_once_t onceToken;
dispatch_once(&onceToken, ^{
[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:)];
});
}
UIVIewController +MemoryLeak类 交换了三个方法，核心是调用了该类的willDealloc方法
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;
}
super调用父类的-willDealloc方法，也就是NSObject+MemoryLeak。 该方法的作用是，先用一个弱指针指向 self，并在一小段时间(3秒)后，通过这个弱指针调用 -assertNotDealloc，而 -assertNotDealloc 主要作用是直接中断言。
NSObject+MemoryLeak.h
- (BOOL)willDealloc {
NSString *className = NSStringFromClass([self class]);
//判断该对象是否在白名单内
if ([[NSObject classNamesWhitelist] containsObject:className])
return NO;
//如果该对象为上一次发送action的对象，不进行内存检测
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;
}
当我们认为某个对象应该要被释放了，在释放前调用这个方法，如果3秒后它被释放成功，weakSelf 就指向 nil，不会调用到 -assertNotDealloc 方法，也就不会中断言，如果它没被释放（泄露了），-assertNotDealloc 就会被调用中断言。这样，当一个 UIViewController 被 pop 或 dismiss 时（我们认为它应该要被释放了），我们遍历该 UIViewController 上的所有 view，依次调 -willDealloc，若3秒后没被释放，就会中断言。
接下来调用-willReleaseChildren、-willReleaseChild遍历该对象的子对象，判断是否释放
NSObject+MemoryLeak.h
- (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,为该对象的viewStack加上子对象的类名。设置子对象的parentPtrs，为该对象的parentPtrs加上子对象的地址。 然后会执行[child willDealloc]，去检测子类。调用-willDealloc方法会调用-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]);
}
关联对象parentPtrs，会判断当前对象是否与父节点集合有交集，调用了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中移除该对象地址，同时再次弹窗，提示该对象已经释放了
