首先交代一下背景:
在 ARC 时代较常见的内存泄露是循环引用导致的,开发中也较容易被忽略.而苹果的 Instrument 操作起来既不简单又不粗暴,而且有些工具还查不出来这类问题.
那么这篇文章适合你吗?
- 你需要一个简单粗暴的检测工具吗?
- 你是否对当前项目内存问题做过整体的跟踪监测?
- 你想要一个即时,精准,让你无拖延的解决问题的辅助工具吗?
如果你都不需要,其实你也可以了解一下,因为他并不能耽误你几分钟时间,下面我们来看看如何
使用及效果:
第一步: 通过 pod 直接安装或下载拖入
pod 'MLeaksFinder'
第二步: 给你的基类或任何一个类添加上这样一部分内容
- (BOOL)willDealloc
{
__weak id weakSelf = self;
dispatch_after(dispatch_time(DISPATCH_TIME_NOW, (int64_t)(3*NSEC_PER_SEC)), dispatch_get_main_queue(), ^{
[weakSelf assertNotDealloc];
});
return YES;
}
- (void)assertNotDealloc
{
NSAssert(NO, @“”);
}
第三步: 跑起来试试吧! 如果哪个类侧漏了,那么将会进入断言直接停止运行.
中断言时，我们通过控制台如下提示可以看出 SearchResultBaseVC 这个类没有释放。
debug.png
那么如果我们找到了那个类,那么应该怎么确定问题呢?
- (BOOL)willDealloc
{
if(![super willDealloc]) {
return NO;
}
// 可以这样 我们来看看是哪个对象没有被释放
MLCheck(object);
return YES;
}
从 MLeaksFinder 的使用方法可以看出，MLeaksFinder 具备以下优点：
1.使用简单，不侵入业务逻辑代码，不用打开 Instrument
2.不需要额外的操作，你只需开发你的业务逻辑，在你运行调试时就能帮你检测
3.内存泄露发现及时，更改完代码后一运行即能发现（这点很重要，你马上就能意识到哪里写错了）
4.精准，能准确地告诉你哪个对象没被释放
当然,它也有一些缺点,比如一些不能被释放的(单例,一级界面,某些系统的私有 View,手势返回机制问题等),我们需要添加白名单.
就这么简单了.
这里非常感谢 WeRead团队博客 提供的内容,如您欲详细了解请移步 中文介绍
