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

  • 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 <FBRetainCycleDetector/FBRetainCycleDetector.h>
      
      _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