iOS内存泄漏检测方法

什么是内存泄漏，通俗来说就是有一块内存区域被你占用了，但你又不使用这块区域也不让别人用，造成内存浪费，这就是内存泄漏，泄漏严重会造成内存吃紧，严重的会使程序崩溃；
内存泄漏对于以前MRC开发来说相当痛苦，需要耗费大量精力管理内存，引入ARC机制后，系统自动管理内存，大大减轻了开发工作量，但一些特殊情况仍然会有内存泄漏发生，需要特别注意。

一般易造成泄漏的点

• Retain Cycle，Block强引用
• NSTimer释放不当
• 第三方提供方法造成的内存泄漏
• CoreFoundation方式申请的内存，忘记释放

eg:

block循环

 [cell setSelectTagCityBlock:^(NSIndexPath *indexPath, NSInteger index){
        [self tableView:_tableViewCityList didSelectRowAtIndexPath:indexPath index:index];
    }];
    

一般用weak打破保留环

@WeakObj(self)
    [cell setSelectTagCityBlock:^(NSIndexPath *indexPath, NSInteger index){
        if (selfWeak)
        {
            [selfWeak tableView:selfWeak.tableViewCityList didSelectRowAtIndexPath:indexPath index:index];
        }
    }];
    

AFNetWorking上的经典代码，防止循环引用的

//创建__weak弱引用，防止强引用互相持有
__weak __typeof(self)weakSelf = self;
AFNetworkReachabilityStatusBlock callback = ^(AFNetworkReachabilityStatus status) {
    //创建局部__strong强引用，防止多线程情况下weakSelf被析构
     __strong __typeof(weakSelf)strongSelf = weakSelf;
    strongSelf.networkReachabilityStatus = status;
    if (strongSelf.networkReachabilityStatusBlock) {
         strongSelf.networkReachabilityStatusBlock(status);
    }
};

weak 本身是可以避免循环引用的问题的，但是其会导致外部对象释放了之后，block 内部也访问不到这个对象的问题，我们可以通过在 block 内部声明一个 strong 的变量来指向 weakObj，使外部对象既能在 block 内部保持住，又能避免循环引用的问题

block 本身无法避免循环引用的问题，但是我们可以通过在 block 内部手动把 blockObj 赋值为 nil 的方式来避免循环引用的问题。另外一点就是 block 修饰的变量在 block 内外都是唯一的，要注意这个特性可能带来的隐患。

 _timer = [NSTimer timerWithTimeInterval:[refreshTime integerValue]
                                             target:self
                                           selector:@selector(doFSearchDoubleBackNumberRequest:)
                                           userInfo:searchResult
                                            repeats:NO];
            [[NSRunLoop mainRunLoop] addTimer:_timer forMode:NSRunLoopCommonModes];
            

Timer 添加到 Runloop 的时候，会被 Runloop 强引用。
Timer 又会有一个对 Target 的强引用。
所以说如果不对Timer进行释放，Timer的targer(self)也一直不会被释放。
有时候我们我们对某个Timer的targer设置了nil。但没设置[timer invalidate]。
其实这个对象还是没被释放的。timer对应的执行方法也一直会在线程中执行。容易造成内存泄露。

注：repeats:NO不会强引用

常规的监测方法

• Analyze静态分析 （command ＋ shift ＋ b）

  主要分析以下四种问题：

  1、逻辑错误：访问空指针或未初始化的变量等；

  2、内存管理错误：如内存泄漏等；

  3、声明错误：从未使用过的变量；

  4、Api调用错误：未包含使用的库和框架。

  静态分析结果会有警告提示

  

  image

• Instruments中的Leak动态分析内存泄漏

  product－>profile －>leaks 打开工具主窗口

  
  
  

  image

  点击暂停，将鼠标移到叉号上面点击锁定，点击下方的“田”字格，选择callTree，

  选择中间的齿轮，选中选项中的 invert Call Tree 和Hide System Libraries

• Separate by Thread：按线程分开做分析，这样更容易揪出那些吃资源的问题线程。特别是对于主线程，它要处理和渲染所有的接口数据，一旦受到阻塞，程序必然卡顿或停止响应。
• Invert Call Tree：反向输出调用树。把调用层级最深的方法显示在最上面，更容易找到最耗时的操作。
• Hide System Libraries：隐藏系统库文件。过滤掉各种系统调用，只显示自己的代码调用。
• Flattern Recursion：拼合递归。将同一递归函数产生的多条堆栈（因为递归函数会调用自己）合并为一条。

双击左边 Call Tree 下面的任意一行，查看内存泄漏的代码位置

image

• Allocation工具了解内存的分配情况

  每次点击generations(是两个时间标记之间所有仍然活着的对象的快照),生成快照，而且 Allocations 会记录从上回内存快照到这次内存快照这个时间段内，新分配的内存信息，数次 push 跟 pop 之后，内存还不断增长，则有内存泄露

  

  image

  开源项目 HeapInspector-for-iOS 可以说是 Allocations 的改进，它通过 hook 掉 alloc，dealloc，retain，release 等方法，来记录对象的生命周期，亲测不太好用

  其他工具用途

  • Core Data：监测读取、缓存未命中、保存等操作，能直观显示是否保存次数远超实际需要。
  • Cocoa Layout：观察约束变化，找出布局代码的问题所在。
  • Network：跟踪 TCP / IP和 UDP / IP 连接。
  • Automations：创建和编辑测试脚本来自动化 iOS 应用的用户界面测试

XCode8后新特性

• Debug Memory Graph

  Debug Memory Graph, 直接以关系图的形式来告诉你各个对象的持有关系, 泄露时会有紫色的小感叹号出现,
  在开发过程中，因为语法或明显的代码错误(例如Retain Cycle)，编译器可以发现并报黄色或红色警告

image

实时监测内存占用情况

image

直接选择一个对象，查看与其相关的内存关系

image

- 绿色的一般都是 UIKit 控件及其子类
- 蓝色一般 NSObject 类及其子类
- 黄色一般都是容器类型及其子类
- 灰色括号是指 block

第三方工具

• MLeaksFinder

  原理还是很简单的, 它swizzle了NavigationController的Push和Pop相关方法来管理viewController和view的生命周期, 在你Pop掉viewController的时候, 会执行这么一段代码

- (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, @“”);
}

3秒后执行 [weakSelf assertNotDealloc]; 如果这个时候view和viewController已经释放了, 那么weakSelf应该为nil, 所以将不会触发断言, 否则将会打印日志, 触发断言.

• 关于swizzleSEL

一种简写方式

void MethodSwizzle(Class c,SEL origSEL,SEL overrideSEL)  {
        Method origMethod = class_getInstanceMethod(c, origSEL);
        Method overrideMethod= class_getInstanceMethod(c, overrideSEL);
}

传入两个参数，原方法选择子，新方法选择子，并通过class_getInstanceMethod()拿到对应的Method

• 有两种情况要考虑一下。第一种情况是要复写的方法(overridden)并没有在目标类中实现，而是在其父类中实现了。第二种情况是这个方法已经存在于目标类中。这两种情况要区别对待
  （它的目的是为了使用一个重写的方法替换掉原来的方法。但重写的方法可能是在父类中重写的，也可能是在子类中重写的。）

• 对于第一种情况（重写方法不存在），应当先在目标类增加一个新的实现方法(override)，然后将复写的方法替换为原先的实现
• 对于第二情况(目标类存在重写的方法)。这时可以通过method_exchangeImplementations来完成交换.

标准方式

+ (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:)];
    });
}

+ (void)swizzleSEL:(SEL)originalSEL withSEL:(SEL)swizzledSEL {
#if _INTERNAL_MLF_ENABLED
    
#if _INTERNAL_MLF_RC_ENABLED
    // Just find a place to set up FBRetainCycleDetector.
    static dispatch_once_t onceToken;
    dispatch_once(&onceToken, ^{
        dispatch_async(dispatch_get_main_queue(), ^{
            [FBAssociationManager hook];
        });
    });
#endif
    
    Class class = [self class];
    
    Method originalMethod = class_getInstanceMethod(class, originalSEL);
    Method swizzledMethod = class_getInstanceMethod(class, swizzledSEL);
    
    BOOL didAddMethod =
    class_addMethod(class,
                    originalSEL,
                    method_getImplementation(swizzledMethod),
                    method_getTypeEncoding(swizzledMethod));
    
    if (didAddMethod) {
        class_replaceMethod(class,
                            swizzledSEL,
                            method_getImplementation(originalMethod),
                            method_getTypeEncoding(originalMethod));
    } else {
        method_exchangeImplementations(originalMethod, swizzledMethod);
    }
#endif
}

class_addMethod:是相对于实现来的说的，将本来不存在于被操作的Class里的newMethod的实现添加在被操作的Class里，并使用origSel作为其选择子

如果发现方法已经存在，会失败返回，也可以用来做检查用,我们这里是为了避免源方法没有实现的情况;如果方法没有存在,我们则先尝试添加被替换的方法的实现

1.如果返回成功:则说明被替换方法没有存在.也就是被替换的方法没有被实现,我们需要先把这个方法实现,然后再执行我们想要的效果,用我们自定义的方法去替换被替换的方法. 这里使用到的是class_replaceMethod这个方法. class_replaceMethod本身会尝试调用class_addMethod和method_setImplementation，所以直接调用class_replaceMethod就可以了)

2.如果返回失败:则说明被替换方法已经存在.直接将两个方法的实现交换即可

class_replaceMethod，addMethod成功完成后，从参数可以看出，目的是换掉method_getImplaementation(roiginMethod)的选择子，将原方法的实现的SEL换成新方法的SEL

• FBRetainCycleDetector

  能够检测指定对象的引用情况，并把所存在的引用循环中各对象和引用在终端进行打印

    #import 
    
    _handlerBlock = ^{
        NSLog(@"%@", self);
    };
    
    FBRetainCycleDetector *detector = [FBRetainCycleDetector new];
    [detector addCandidate:self];
    NSSet *retainCycles = [detector findRetainCycles];
    NSLog(@"%@", retainCycles);
    
打印结果类似于：


```

{(
    (
    "-> DetailViewController ",
    "-> _handlerBlock -> __NSMallocBlock__ "
)
)}

 
 
 
 ```

DetailViewController通过_handlerBlock实例变量引用一个Block对象，而该Block又引用了DetailViewController对象。如果不存在引用循环的话，打印的结果将是空的

原理： 循环引用可以包含任何数量的对象。一个坏的连接会导致很多环的时候，这就复杂了

image

在环中，A→B是一个坏连接，创建了两个环：A-B-C-D 和 A-B-C-E。
这有两个问题：

• 不想给一个坏连接导致的两个循环引用分别标记。
• 不想给可能代表两个问题的两个循环引用一起标记，即使它们共享一个连接。

所以需要给循环引用定义簇组(clusters)，鉴于这些启发，我们写了个算法来找到这些问题。

• 在给定的时间收集所有的环。
• 对于每一个环，提取Facebook特定的类名。
• 对于每一个环，找到包含在环内的被报告的最小的环。
• 依据上面的最小环，将环添加到组中。
• 只报告最小环。

• PLeakSniffer

通过Pod安装后，通过以下代码激活即可。

[[PLeakSniffer sharedInstance] installLeakSniffer];
[[PLeakSniffer sharedInstance] addIgnoreList:@[@"MySingletonController"]];

addIgnoreList可以添加一些特殊的忽略名单，比如单例这种无法正确预测泄漏的对象

原理： 如果Controller被释放了，但其曾经持有过的子对象如果还存在，那么这些子对象就是泄漏的可疑目标

子对象（比如view）建立一个对controller的weak引用，如果Controller被释放，这个weak引用也随之置为nil。那怎么知道子对象没有被释放呢？用一个单例对象每个一小段时间发出一个ping通知去ping这个子对象，如果子对象还活着就会一个pong通知。所以结论就是：如果子对象的controller已不存在，但还能响应这个ping通知，那么这个对象就是可疑的泄漏对象。完整的结构可以用下图表示

image

参考资料

iOS 中的 NSTimer

__weak与__block区别

iOS内存泄漏自动检测工具PLeakSniffer