ARC模式下的循环引用引起内存泄漏

   <h2><strong>ARC模式下的循环引用引起内存泄漏</strong></h2>    <p>​ 自从iOS 5时代自动引用计数（Automatic Reference Counting）技术发布，Cocoa工程师们才扔下了内存管理的包袱，从此在Objective－C修行道路上的一座大山被削平。然而，即使ARC很强大，我们日常搬砖时同样是有内存泄漏风险的，今天我就跟大家聊聊这些你可能还没有注意到的坑。</p>    <h2><strong>测试原理</strong></h2>    <p>​ 我们知道ARC模式下， NSObject 的 MRC 相关方法都不可以使用了，但 dealloc 方法如果实现了，同样还是会调用的，只是不允许在 dealloc 方法中调用 [super dealloc] ，所以我们在 dealloc 方法中加入log信息就可以跟踪到我们的实例是否释放。</p>    <h2><strong>容易忽视的引用循环</strong></h2>    <p>​ 我们知道 引用计数 内存管理的设计理念，就是根据实例的计数值来决定是否释放实例内存空间。</p>    <p>​ 例如我们的ViewController拥有一个block类型的property</p>    <pre>  <code class="language-objectivec">@property (nonatomic, strong) void (^ testBlock)(void);</code></pre>    <p>​ 我们在viewDidLoad中加入如下代码</p>    <pre>  <code class="language-objectivec">[self setTestBlock:^{      self.title = @"测试";  }];</code></pre>    <p>​ 这个代码从表面上看没有什么问题，但编译器会给出warning，</p>    <p>Catering 'self' strongly in this block is likely to lead a retain cycle</p>    <p>​ 翻译过来意思是在block中使用self指针，可能会引起一个引用循环，导致self无法释放。</p>    <h3><strong>什么是引用循环（retain cycle）</strong></h3>    <p>​ 假设我们有两个实例A和B，B是A的一个strong型的property，则B的引用计数是1，当A的需要释放的时候，A则会调用 [B release] 来释放B，B的引用计数则减为0，释放。</p>    <p>​ 可如果这时候将B的一个strong型property指向A，则A与B互相为强引用，问题就来了。因为B强引用A，A的引用计数永远不会减为0，当A原本的强引用对象被释放以后，A和B成为了一个相互引用的孤岛，永远不会被释放了，这就会引起内存泄漏。</p>    <p>​ 在上面的例子中，就是一种非常普遍的引用循环情况，加入如上代码的VC在dismiss或者pop以后，并不会执行dealloc方法，证明内存泄漏了。而引起泄漏的原因就是在作为self的property的block中，使用self指针导致self被block强引用，形成引用循环。</p>    <h2><strong>如何解决引用循环问题</strong></h2>    <p>​ 在编译器提示上面的warning的时候一定不要忽视，正确的解决办法如下：</p>    <pre>  <code class="language-objectivec">__unsafe_unretained Demo1ViewController * weakSelf = self;  [self setTestBlock:^{         weakSelf.title = @"测试";  }];</code></pre>    <p>​ 或者使用__weak也可以，原理也很简单，就是声明一个弱引用对象在block中替代self，这样在我们测试中，下面代码就能正常输出log，标志着VC被正确释放。</p>    <pre>  <code class="language-objectivec">- (void)dealloc  {      NSLog(@"%s",__func__);  }</code></pre>    <p>2016-09-07 13:17:38.879 ReactiveCocoaDemo[7473:3432323] -[Demo1ViewController dealloc]</p>    <h2><strong>其他会引起引用循环的状况</strong></h2>    <h3><strong>NSTimer</strong></h3>    <p>​ NSTimer 在VC释放前，一定要调用 [timer invalidate] ，不调用的后果就是 NSTimer 无法释放其target，如果target正好是self（VC本身），则引用循环。</p>    <p>​ 这里要补充一点，引用循环不是只能有两个对象，三个四个更多都是可以的，甚至环数也不一定只有一个，所以要养成良好的代码习惯，在 NSTimer 停用前调用 invalidate 方法。</p>    <h3>WKUserContentController</h3>    <p>​ 这个类一般会在使用 WKWebView 的时候配套使用，如果你发现项目中调用了 addScriptMessageHandler 方法，就要注意了，检查有没有在VC释放前对称调用 removeScriptMessageHandlerForName 方法，如果没有则引起引用循环。</p>    <p>​ 调用方法如下：</p>    <pre>  <code class="language-objectivec">[self.wkWebView.configuration.userContentController removeScriptMessageHandlerForName:@"qdpay"];</code></pre>    <p>​ 注意 WKUserContentController 和 WKWebView 中还有一个 WKWebViewConfiguration 。</p>    <h2><strong>引用大循环</strong></h2>    <p>​ 就像前面说的，引用循环可能是一个大循环。我遇到过一种情况，就是给 UITableViewCell 设置block属性响应事件，在block中强引用了self，导致self->tableView->cell->self形成循环。</p>    <h2><strong>改善block写法避免强引用self</strong></h2>    <p>​ 如果要从根本改变这种易发的错误，要从写法开始改变，开始避免。将上面的代码改写如下：</p>    <pre>  <code class="language-objectivec">@property (nonatomic, strong) void (^ testBlock)(__kindof UIViewController* sender);     [self setTestBlock:^(__kindof UIViewController * vc) {          vc.title = @"123";   }];         self.testBlock(self);</code></pre>    <p>​ 将self作为参数传入block即可避免强引用，从逻辑角度来看，代码更健壮。</p>    <h2><strong>结束</strong></h2>    <p>​ 上面列举的几个引用循环引起的内存泄漏，编译器是没有任何提示的，并且也不影响App运行，不会crash，但作为严谨的程序猿，我们不能容忍这种的小泄漏，虽然不影响大局，但积少成多终将影响系统的运行速度。</p>    <p> </p>    <p>来自：https://segmentfault.com/a/1190000006840077</p>    <p> </p>