Instruments Leaks不可以作为debug 内存泄漏唯一工具

尽管block（closure）和delegate会造成memory leak这在iOS开发中从2010年开始就算是一个常识，但是还是有很多初学者甚至干了好几年的工程师也并没有真正注意这个事情。原因就是因为XCode自带的instruments工具中包含的Leak功能并不能很好的发现的所有内存泄露的问题，这篇文章将展示一个instruments无法发现的内存泄露实例，并说明如何正确使用instruments和ABI来发现内存泄露。希望看完以后你能把一点牢记在心，并不是开了Leaks跑一圈一个红叉都没有就代表你的程序不存在内存泄露。

让我们先来重温一下内存泄漏这个概念，内存泄露就是内存被分配出去以后没有办法被及时回收。这个概念其实是很模糊的，问题出在及时这两个字上面。比如，我一个软件在用的时候一直在疯狂吃内存，理论上只要你一直用，终有一天会占满内存但是只要这个软件被关闭，那么内存就会被清空，这叫不叫内存泄露？还是说只有出现系统重启才能释放内存的情况才叫做内存泄露呢？一般情况下，其实内存泄露说的都是第二种情况，但是，对于像移动端开发这样内存相对吃紧的情况来说，我觉得第一种情况也是不容忽视的，而且事实上，移动端大部分的内存泄露都是第一种情况，包括但不限于：
1. closure内引用self
2. 创建未用weak修饰的delegate属性
3. 父类子类互相引用
4. 不应该存在notificationCenter还在接受消息

而第一种内存泄漏中有很多是不会被instruments 这类工具捕获的， 下面我将通过一个project来展示最常见的一种情况。让我们先来看一个这个实例的结构：

Screen Shot 2017-04-25 at 9.14.54 PM.png

点击button，push到第二个View Controller，点击Cell中Press me Button，返回第一个ViewController。为了演示不正确使用closure会造成内存泄露，press me的方法由第二ViewController传入：

import UIKit

class ViewController: UIViewController {

    @IBOutlet weak var myTable: UITableView!
   
    override func viewDidLoad() {
        super.viewDidLoad()
        myTable.estimatedRowHeight = 66
        myTable.rowHeight = UITableViewAutomaticDimension
        automaticallyAdjustsScrollViewInsets = false
    }
    
    override func viewDidAppear(_ animated: Bool) {
        super.viewDidAppear(animated)
    }

    override func didReceiveMemoryWarning() {
        super.didReceiveMemoryWarning()
        // Dispose of any resources that can be recreated.
    }
    
    deinit {
        print("here")
    }

}

extension ViewController:UITableViewDataSource {
    
    func tableView(_ tableView: UITableView, numberOfRowsInSection section: Int) -> Int {
        return 5
    }
    
    func tableView(_ tableView: UITableView, cellForRowAt indexPath: IndexPath) -> UITableViewCell {
        let cell = tableView.dequeueReusableCell(withIdentifier: "Cell", for: indexPath) as! MyTableViewCell
        cell.actionHandler = { //[weak self] in
            self.navigationController!.popViewController(animated: true)
        }
        return cell
    }
}

可以看到，我们如果把[weak self] comment掉以后，这个时候，actionHandler这个closure会持有一个对self也就是ViewController的强reference。因为这个closure本质上是escaping的，所以，会导致ViewController本身无法被释放掉。首先，我们先运行一下这个project，反复两个ViewController钟不断跳转，首先我们观察到的现象是deinit method并没有被执行，如果你还认为这不足以说明问题，那么我们打开instruments，我们可以看到：

Screen Shot 2017-04-25 at 9.29.16 PM.png

在整个过程之中，allocation量持续不停地上涨，并且在停止跳转以后并没有下降，这说明ViewController的instance没有被释放掉。同时我们可以在xcode图形调试器中观察到在同一时间，同时存在了九个ViewController的instances：

Screen Shot 2017-04-25 at 9.56.53 PM.png

如果你觉得这还不能说明问题，那么我们uncomment [weak self]以后在运行一次，首先我们观测到的是每一次deinit method都会被调用。并且在instruments里面我们可以看到：

Screen Shot 2017-04-25 at 9.30.21 PM.png

显然这一次allocation以后都被释放了,再来看一下图形调试器:

Screen Shot 2017-04-25 at 10.00.01 PM.png

很好，这次只有一个instance长期存在。

这个问题发生的原因是什么呢？ 我们来看一下苹果是如何解释Leak的：
A "leak" as an object that's still allocated, but your application no longer has a reference pointing to that object. Since you no longer have a reference, there's no way you will be able to release the object, thus it's a leak.
如果我们从这个定义上来看，我们上面所陈述的情况似乎并不符合Leak的定义，这就是为什么Instruments的Leaks功能认为程序不存在内存泄露的情况。因为AppDelegate中的UIWindow始终持有一个UIViewController的强reference，也就是说，只要app还在前台运行，那么，UIViewController这个object本身总是有指针指向它的，那么不管他有多少个没有人用的instance，这些instance都不能被算作Leak，因为在这个时间点上，的确是有强指针指向这个object的。