编码篇-ARC下的内存泄漏

</br>

前言

内存泄露是一个相对挺严重的问题，可是它的存在未引起足够的重视，如果程序运行时一直分配内存而不及时释放无用的内存，程序占用的内存越来越大，直到把系统分配给该APP的内存消耗殚尽，程序因无内存可用导致崩溃，这样的情况我们称之为内存泄漏。如果某个对象没有始终在内存中，并且依然会做一些事的时候，这样的的Bug是非常严重而且难以排查的。

内存泄漏可能引起的问题:

• 内存消耗殆尽的时候，程序会因没有内存被杀死，即crash。
• 当内存快要用完的时候，会非常的卡顿
• 如果是ViewController没有释放掉，引起的内存泄露，还会引起其他严重的问题，尤其是和通知相关的。没有被释放掉的ViewController还能接收通知，还会执行相关的动作，所以会引起各种各样的异常情况的发生。

那么ARC下内存泄漏的场景有哪些呢

值得注意的是：ARC是编译器（时）特性，而不是运行时特性，更不是垃圾回收器(GC)。
ARC这是一种编译期的内存管理方式，在编译期间，编译器会判断对象的使用情况，并在合适的位置加上retain和release，使得对象的内存被合理的管理。所以，从本质上说ARC和MRC在本质上是一样的，都是通过引用计数的内存管理方式。

• CF类型内存

ARC 可以帮忙管理 Objective-C 对象, 但是不支持 Core Foundation 对象的管理，所以转换后要注意一个问题：谁来释放使用后的对象。
注意以creat,copy作为关键字的函数都是需要释放内存的，注意配对使用。比如：CGColorCreate<-->CGColorRelease

那Objective-C 和 Core Foundation 对象相互转换时就可能出现内存泄漏的问题，可参考这篇文章处理。

• MRC内存使用

  这部分不做详细介绍，也是注意配对使用，需要说明的是，如果代码中有部分文件是MRC的，在已有文件中加代码的时候注意一下，不能都按照ARC的方式处理。

• 循环引用

  • block引起的循环引用。
    某个类将block作为自己的属性变量，然后该类在block的方法体里面又使用了该类本身;相互持有，导致都释放不了。
    下面这样的方式就可以解决block引起的循环引用：
    __weaktypeof(self) weakSelf =self;
    block内的self，换成weakSelf就行了。
    block不是self的属性或者变量时，在block内使用self不会循环引用;
    像这样的方法中调用self，不会引起，但是属性的形式中调用self就会以

      [self.myTest doSomeTest:^(NSInteger cellIndex) {
          self.allInter = cellIndex;
      }];
    

• 引用大循环
  ​就像前面说的，引用循环可能是一个大循环。我遇到过一种情况，就是给UITableViewCell设置block属性响应事件，在block中强引用了self，
  导致self->tableView->cell->self形成循环。
  有时候随着代码量的增大，逻辑的负责，很容易形成一个很大的循环引用，最后造成内存泄漏。

• ** NSTimer的使用**

  NSTimer，NSTimer会对它的target持有强引用，如果NSTimer不释放掉，就会一直持有它的target的强引用，如果这个NSTimer在被target强引用，会一直都释放不掉，造成内存泄露。

  下面的代码在书写的时候Xcode是不会报任何错误和警告的。但是实际上已经形成了循环引用。造成了内存泄漏。

  @property (nonatomic, strong) NSTimer *timer;
  @property(copy,nonatomic)NSString *name;
   self.timer = [NSTimer scheduledTimerWithTimeInterval:0.1
                                              target:self
                                            selector:@selector(handleTimer)
                                            userInfo:nil
                                             repeats:YES];
  
    - (void)handleTimer
    {
         self.name = @"123";
   }
  

• 单例也会造成内存泄漏

  如果一个单例持有一个block，block内又使用了当前这个ViewController类，会引起循环引用。所以单例持有的代码块中要用弱引用，原因是：单例不会被释放掉，它会一直持有block，导致该block所在的ViewController释放不掉。

• performSelector的内存问题

  • performSelector 的动态绑定

    SEL selector;
      if (/* some condition */) {
      selector = @selector(newObject);
     } else if (/* some other condition */) {
      selector = @selector(copy);
     } else {
       selector = @selector(someProperty);
    }
    id ret = [object performSelector:selector];
    

  这段代码就相当于在动态之上再动态绑定。在 ARC 下编译这段代码，编译器会发出警告

        warning: performSelector may cause a leak because its selector is unknow [-Warc-performSelector-leak]
  

  正是由于动态，编译器不知道即将调用的 selector 是什么，不了解方法签名和返回值，甚至是否有返回值都不懂，所以编译器无法用 ARC 的内存管理规则来判断返回值是否应该释放。因此，ARC 采用了比较谨慎的做法，不添加释放操作，即在方法返回对象的引用计数可能不会减少，从而可能导致内存泄露。

  以本段代码为例，前两种情况（newObject, copy）都需要再次释放，而第三种情况不需要。这种泄露隐藏得如此之深，以至于使用 static analyzer 都很难检测到。如果把代码的最后一行改成

      [object performSelector:selector];
  

  不创建一个返回值变量测试分析，简直难以想象这里居然会出现内存问题。所以如果你使用的 selector 有返回值，一定要处理掉 手动释放（置为 nil）。

  • performSelector afterDelay 延时操作
    关于内存管理的执行原理是这样的执行
    [self performSelector:@selector(method1:) withObject:self.tableLayer afterDelay:3];
    的时候，系统会将tableLayer的引用计数加1，执行完这个方法时，还会将tableLayer的引用计数减1，有时切换场景时延时函数已经被调用但还没有执行，这时tableLayer的引用计数并没有减少到0，也就导致了切换场景dealloc方法没有被调用，出现了内存泄露。

    解决办法就是取消那些还没有来得及执行的延时函数，代码：

    [NSObject cancelPreviousPerformRequestsWithTarget:self]
    

    当然你也可以一个一个得这样用：

      [NSObject cancelPreviousPerformRequestsWithTarget:self selector:@selector(method1:) object:nil]
    

    加上了这个以后，切换场景后会顺利地执行了dealloc方法，至此内存泄漏问题解决。

• 代理未清空引起野指针

  查看iOS的一些API，发现delegate都是assign的，这样就会引起野指针的问题，可能会引起一些莫名其妙的crash。那么这是怎么引起的，当一个对象被回收时，对应的delegate实体也就被回收，但是delegate的指针确没有被nil，从而就变成了游荡的野指针了。所以在delloc方法中要将对应的assign代理设置为nil，如：

  - (void)viewDidDisappear:(BOOL)animate
  {
    self.myTableView.delegate = nil;
    self.myTableView.dataSource = nil;
    通知注销掉
    kvo remove掉~~
  }
  

那是不是所有的delegate都要这样做呢？一般自己写的一些delegate，我们会用weak，而不是assign，weak的好处是当对应的对象被回收时，指针也会自动被设置为nil。

• 循环未结束

  如果某个ViewController中有无限循环，也会导致即使ViewController对应的view关掉了，ViewController也不能被释放。
  这种问题常发生于animation处理。

  CATransition *transition = [CATransition animation];
  transition.duration = 0.5;
  tansition.repeatCount = HUGE_VALL;
  [self.view.layer addAnimation:transition forKey:"myAnimation"];
  

上例中，animation重复次数设成HUGE_VALL，一个很大的数值，基本上等于无限循环了。
解决办法是，在ViewController关掉的时候，停止这个animation。
-(void)viewWillDisappear:(BOOL)animated {
[self.view.layer removeAllAnimations];
}

• ** try...catch 的使用**
  但如果 doSomethingMayThrowException 方法抛出了异常，那么 object 对象就无法释放。如果 object 对象持有了重要且稀缺的资源，就可能会造成严重后果。

PS其他需要注意的问题

大次数循环内存暴涨问题

记得有道比较经典的面试题，查看如下代码有何问题：

    for (int i = 0; i < 100000; i++) {
        NSString *string = @"Abc";
        string = [string lowercaseString];
        string = [string stringByAppendingString:@"xyz"];
        NSLog(@"%@", string);
}

该循环内产生大量的临时对象，直至循环结束才释放，可能导致内存泄漏，解决方法为在循环中创建自己的autoReleasePool，及时释放占用内存大的临时变量，减少内存占用峰值。

for (int i = 0; i < 100000; i++) {
        @autoreleasepool {
            NSString *string = @"Abc";
            string = [string lowercaseString];
            string = [string stringByAppendingString:@"xyz"];
            NSLog(@"%@", string);
      }
  }

附、如何检测App的内存泄漏问题

• 借助Xcode自带的Instruments工具（选取真机测试）

  Instruments

• 简单暴力的重写dealloc方法，加入断点或打印判断某类是否正常释放。

  dealloc

• 使用Xcode8中自带的有内存检测警告。

  
  

• 通过Facebook出品的FBMemoryProfiler工具类进行检测.

集成后的显示

</br>

这篇ARC下的内存泄漏，洋洋洒洒说了这么多，算是总结的比较详细和全面的。希望对大家有价值。