盡管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來展示最常見的一種情況。讓我們先來看一個這個實例的結構：
點擊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，我們可以看到：
在整個過程之中，allocation量持續不停地上漲，并且在停止跳轉以后并沒有下降，這說明ViewController的instance沒有被釋放掉。同時我們可以在xcode圖形調試器中觀察到在同一時間，同時存在了九個ViewController的instances：
如果你覺得這還不能說明問題，那么我們uncomment [weak self]以后在運行一次，首先我們觀測到的是每一次deinit method都會被調用。并且在instruments里面我們可以看到：
顯然這一次allocation以后都被釋放了,再來看一下圖形調試器:
很好，這次只有一個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的。
