記憶體二三事: Xcode 記憶體圖、Instruments 視覺化檢測迴圈引用
這麼用，
在重點測試的介面，多操作，然後退出。
重複幾次。確認系統快取已初始化。 退出重點測的介面後，開記憶體圖， 如果記憶體釋放的乾淨，就沒什麼 retain cycle 等記憶體洩漏。
記憶體圖自帶斷點效果，會暫停 app 的執行
可以看到此刻存在的所有物件。
環節短的迴圈引用，明顯可見，找起來很快。
通過記憶體圖，左邊列表中，可以看到當前的所有物件，以及它們的數量。
最關心的就是感嘆號，代表異常， 就是記憶體洩漏， 一般是 Retain Cycle
本文 Demo ，可見系統的代理 AppDelegate 例項, 相關 ViewController . 可看到圖片檢視有 24個。
中間大片的區域是物件的記憶體圖，可看到他們是怎麼關聯的。可參考下
左邊欄的右下方按鈕，可以直接篩選出記憶體有錯誤的物件，方便找出記憶體洩漏的物件
可看出本文 Demo 記憶體洩漏嚴重。左邊欄，點開幾個帶感嘆號的，看情況。
右邊欄，有一些具體資訊
photo 照片模型物件，持有一個 location 位置的模型物件， location 位置的模型物件，持有一個物件，
那物件，又持有 photo 照片模型物件。
三個物件，構成了一個強引用的圈， retain cycle
發現問題了，解決就是改程式碼 很熟悉，直接改。
可以全域性搜關鍵字，本文 demo 搜 .location
可以根據右邊欄的資訊找，
知道是哪個類，又有一個 closure 物件
可找到錯誤程式碼
photoModel.location?.reverseGeocodedLocation(completion: {(locationModel) in
self.photoLocationLabel.attributedText = photoModel.locationAttributedString(withFontSize: 14.0)
})
}
複製程式碼
photoModel 有一個 location 的屬性，location 持有一個匿名函式 closure. 這個 closure 又引用了 photoModel。
不知道這個 closure 有沒有 retain 該 photoModel，
點進方法看， 這是一個逃逸閉包，賦給了 LocationModel 的 placeMarkCallback 屬性，強引用
func reverseGeocodedLocation(completion: @escaping ((LocationModel) -> Void)) {
if placemark != nil {
completion(self)
}
else {
// 檢視 completion
placeMarkCallback = completion
if !placeMarkFetchInProgress {
beginReverseGeocodingLocationFromCoordinates()
}
}
}
複製程式碼
與 Xcode 記憶體圖檢查到的一致。
解決迴圈引用，一般加 weak
ARC , 自動引用記數， iOS 用來管理記憶體的。 迴圈引用，retain cycle， 是 ARC 搞不定的地方
一個物件的引用記數, 就是有多少個其他的物件，持有對他的引用。
（ 就是有多少個其他的物件，有指標指向他）
當這個物件的引用計數為 0， iOS 的 ARC 記憶體機制知道這個物件不必存在了，會找一個合適的時機釋放。
迴圈引用，多個物件相互引用，形成了一個圈（ 引用的鏈路 ）
迴圈引用，問題很嚴重，記憶體洩漏了 ( 打個比方: 你找 iOS 系統借了錢，少還一大截。人家系統沒說什麼， 心裡都記著 )
加 weak, ARC 就明白了， （ 因為 weak 是弱引用，不會增加該物件的引用記數。 直接寫，隱含了一個 strong 的語義，預設 retain , 該物件的引用記數 + 1 ）
鏈路就斷了，記憶體回收成功。
Swift 的 closure 中，可以新增一個弱引用列表。 這個捕獲列表可以讓指定的屬性弱引用。 closure 使用弱引用，就好
func reverseGeocode(locationForPhoto photoModel: PhotoModel) {
photoModel.location?.reverseGeocodedLocation(completion: {[ weak photoModel] (locationModel) in
self.photoLocationLabel.attributedText = photoModel?.locationAttributedString(withFontSize: 14.0)
})
}
複製程式碼
Xcode 的除錯計量工具很強大，除錯記憶體的時候，可切換除錯檢視層級等
左邊欄的右上方的按鈕，可以切換除錯的選項， 記憶體轉 UI, 記憶體轉執行緒
通過使用 Xcode 記憶體圖，記憶體洩漏少了很多。 重複操作三五次，又發現一個記憶體洩漏
物件結點很多，看圖挺複雜的
可以用 Instruments 的 Leaks
Leaks 自帶兩個模版 Allocation 和 Leaks，
Allocation 模版對 app 執行過程中分配的所有物件的記憶體，都追蹤到了。 上方的時間線展示了，已經分配了多少兆的記憶體。
All Heap & Anonymous VM, 所有堆上的記憶體，和虛擬記憶體 （ WWDC 2018/416 , 講的比較詳細）
下方的標記按鈕，可以做分代標記
Leaks 模版會檢查 app 所有的記憶體，找出洩漏的物件 （ 釋放不了的物件 ）
Instruments 的記憶體檢查機制是，預設每隔 10 秒鐘，自發的取一個記憶體快照分析
反覆操作，找到第一個 Leaks, 可以暫停下
下方的 Leaks 詳情表中，頭部的 Leaks 按鈕，有三個選項， 預設選項就是第一個， Leaks, 展示了所有記憶體洩漏的物件。
下方的右邊欄就是更多資訊，展示了詳情介面每一列物件的進一步的資料
Leaks 詳情表中，每一列物件，有一個灰色的箭頭按鈕，
點進去，可以看引用計數的增減日誌
一般先看看第二個 Cycles & Roots， 又是一張記憶體圖
photoModel 是迴圈圈的根結點，與左邊的物件結點列表一致
有用的是第三個選項 Call Tree , 呼叫樹
與 Time Profiler 的 Call Tree 不一樣，
Time Profiler 的 Call Tree 採集的是應用中所有的方法呼叫， Leaks 的 Call Tree 採集的是分配記憶體與記憶體洩漏相關的方法呼叫。
Call Tree 的選項一般勾選 Hide System Libraries 和 Separate by Thread. Hide System Libraries ,
隱藏系統的方法。系統的方法改不了，是黑盒，參考意義有限。
Separate by Thread. 將方法堆疊，按執行緒分開。一般出問題多在主執行緒，優先看 main thread.
按住 Alt 鍵，點選方法名稱左邊的小三角，可以展開呼叫棧。
又看到了這個方法 func reverseGeocode(locationForPhoto photoModel: PhotoModel)
再檢查下
func reverseGeocode(locationForPhoto photoModel: PhotoModel) {
photoModel.location?.reverseGeocodedLocation(completion: {[ weak photoModel] (locationModel) in
self.photoLocationLabel.attributedText = photoModel?.locationAttributedString(withFontSize: 14.0)
})
}
複製程式碼
self 是一個 CatPhotoTableViewCell 例項，self 持有 photoModel 屬性，
（ 函式裡面的 photoModel， 使用的是 func updateCell(with photo: PhotoModel?) { 方法中傳入的 self 的 photoModel 屬性）
photoModel 持有 location 屬性， location 屬性持有一個逃逸閉包， 該逃逸閉包持有 self.
之前用 weak 處理了三物件的迴圈引用，現在有一個四物件的迴圈引用。
四物件的迴圈引用中 photoModel 在之前的處理中，已經弱引用了。本來好像沒什麼問題的。
估計系統沒及時釋放的 weak 的 photoModel，又洩漏了。
本文中，採用 Xcode 記憶體圖，難以復現。有時候有。
解決就是再加一個 weak.
檢查專案中的迴圈引用，通常使用分代式分析 ( Generational Analysis )
先記錄一個記憶體使用的基線 A ( 當前使用場景， 建議用重點測的場景前的那一個 ),
進入一個場景 ( Controller 重點測的場景), 打個標 ( 記錄現在的記憶體使用情況 ) B ，
再退出該場景，再打一個標 C。
如果 A < B , A = C , 正常，記憶體回收的不錯。 如果 A < B <= C , 異常，記憶體很可能洩漏了
換句話，套路很簡單，設立記憶體基線，點選進入新介面，（操作一下，滾一滾） 然後彈出，記憶體往往會先升後降。
這種操作，需要重複幾次。找出必然。確認系統快取已初始化，在執行。
( 有點類似蘋果的單元測試算函式執行時間，跑一遍，就是運行了好幾次的函式，取的平均值。 )
這裡有一個很經典的面試題:
app 釋出前，一般會系統檢查迴圈引用，記憶體洩漏，怎麼處理呢?
( 換個說法， 怎麼分析 app 堆的快照? )
方案見前文