今天上扛推位的是:"MLeaksFinder"这个库

首先交代一下背景:

在 ARC 时代较常见的内存泄露是循环引用导致的,开发中也较容易被忽略.而苹果的 Instrument 操作起来既不简单又不粗暴,而且有些工具还查不出来这类问题.

那么这篇文章适合你吗?

  1. 你需要一个简单粗暴的检测工具吗?
  2. 你是否对当前项目内存问题做过整体的跟踪监测?
  3. 你想要一个即时,精准,让你无拖延的解决问题的辅助工具吗?

如果你都不需要,其实你也可以了解一下,因为他并不能耽误你几分钟时间,下面我们来看看如何

使用及效果:

第一步: 通过 pod 直接安装或下载拖入

pod 'MLeaksFinder'

https://github.com/Zepo/MLeaksFinder.git

第二步: 给你的基类或任何一个类添加上这样一部分内容

- (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团队博客 提供的内容,如您欲详细了解请移步 中文介绍

你可能感兴趣的:(今天上扛推位的是:"MLeaksFinder"这个库)