Xcode8的調試技能又增加了一個黑科技：Debug Memory Graph。簡單的說就是可以在運行時將內存中的對象生成一張圖。它可以方便快捷的定位出內存泄漏問題，是iOS開發者的福音。
隨著技術的不斷進步，硬件的不斷升級，iOS的內存管理機制早已從MRC升級到ARC，開發者不用過多的
關注內存泄漏問題，蘋果系統已經幫大家處理好了絕大部分工作，讓大家可以專心的編寫邏輯代碼。
當你的app功能持續疊加，文件越來越多，包體積越來越大時，如果你沒有做好內存處理，那各種頁面卡頓，手機使用app發熱耗電快，莫名的崩潰問題逐漸暴露出來。
崩潰
崩潰就像是一種急性病，發病快，容易復現，可以快速的定位排除出原因，那解決就很方便了。業內也有很多的強大的崩潰日志捕獲工具，比如bugly、友盟SDK、Google Analytics等等，可以幫助開發者快速定位分析。這塊網上有豐富的資料，不再細述。
內存泄漏
而內存泄漏就像是慢性病，當內存泄漏時，程序不會立即崩潰，它會慢慢的侵蝕設備的內存，影響用戶的體驗，折磨用戶的內心。當內存全部侵蝕完，就會執行內存警告方法，app回到初始狀態。這個體驗是非常糟糕的。
比如我們項目中因為各種原因導致的內存泄漏，原因可能是
1、NSTimer的使用不當
2、Block的循環引用
3、通知沒有移除
這些內存泄漏導致的隱患不是馬上就能發現的，很多程序員不能及時發現，這是很危險的，因為他不崩潰，也不報錯，特殊情況下才能發現。
內存泄漏怎么治呢？
原先常見的方法：
1、通過靜態檢查工具，檢查一些語法問題。只能檢查一部分簡單的潛在語法問題，許多動態運行的內存問題是檢查不出來的。
2、通過人工代碼code review，持續進行優化重構。比較耗時耗力，但這個工作不能不做，好的代碼不僅是給機器看的，更是給人看的。
3、對一些卡頓、厚重的頁面、類進行dealloc檢查。體力勞動比較耗時。還有很多小的變量、閉包內存泄漏問題不能發現。
Debug Memory Graph
調試內存圖橫空出世，解決了這一難題，為什么，因為你只需要點一下這個圖標，就可以很直觀的看到哪個VC還沒有釋放，這樣的調試界面更人性化了，讓我們苦逼的程序員用肉眼很直觀的看到內存圖。Debug Memory Graph 操作超級簡單，結果快速高效，問題清晰了然。
操作步驟：
1、運行你的程序，把自己的頁面、功能全部跑一遍。
2、點擊控制臺工具欄。
3、立即生成內存截圖。
4、有紫色感嘆號，表示有內存泄漏。（有紫色感嘆號不一定泄漏，沒有姿色感嘆號可能存在泄漏。）
5、有些實例雖然沒有顯示感嘆號，但是如果存在多份，也表示不能及時釋放。可能產生內存高峰，潛在威脅。
6、沒有感嘆號，也可能存在內存泄漏！
代碼示例
總結
Debug Memory Graph工具強大，操作方便，可以快速的定位出內存泄漏問題。但也有一些缺點，工具只是輔助手段，
經常會出現誤報、漏報的情況。有姿色感嘆號，不一定泄漏，沒有姿色感嘆號，也可能存在泄漏。不管怎么說，這也是蘋果的一大進步，可以提高開發者定位分析的效率。
