Objective-C內存管理 調試內存泄露是本文要介紹的內容，解決內容問題應該每個迭代周期要做一些壓力和內存測試，我們先來看內容。

1、內存的問題是發現越早，解決的代價就越小。所以最重要的是理解Objective-C內存管理，遵循我之前提到的實踐準則和編碼規范。另外,在每個迭代周期要做一些壓力和內存測試,盡早發現問題。

2、利用Clang靜態檢測工具。在XCode 3.2之后的版本里，Clang已經被集成進來。Build ->Build & Analyze即可運行，它可以發現大部分因為疏忽造成的內存泄露。比如有Alloc沒有release等。下圖是一次靜態檢測的結果. 如圖所示，Clang清楚的告訴你在145行有潛在的內存泄露，即label有alloc沒有release。（單擊放大）

圖一 Clang靜態檢測

3、如果靜態檢測工具不能解決問題,就需要更多的分析和借助instruments工具。

（1）首先要重現問題，找到是哪些操作容易產生內存泄露。主要通過一些測試和推理來判斷,比如找出哪些操作重復進行時，內存增長比較明顯或者會Crash。

b)借助instruments工具。instruments是在程序運行時在程序中注入一些代碼來動態的檢測內存分配狀況和泄露問題。Run -> Run with perfomance tools - > leaks  即可啟動。下圖是運行leak instrument的一次結果，如果leak是你的代碼引起的，你還可以直接查看到引起泄露的代碼。（單擊放大）

圖二  leaked Blocks

圖三 leaked code（單擊放大）

（2）還有一個instrument叫Allocation，它可以實時監測當前分配了多少內存。結合這個來進行a）步驟的推斷，往往會比較有效。可以通過Run -> Run with perfomance tools - >Allocations啟動，也可以在instruments啟動后通過window->library ->Allocations加進來。

4、可以找你的同事codereview，旁觀者往往能發現問題。有時候內存泄露是一些理解上的誤區造成的。比如我以前一直以為 -viewDidUnload是在這個View被unload之后調用，所以我在里面做一些清理工作，比如Remove EventHandler等， 后來才知道這個函數是在內存不足需要unload view時才被調用，這個理解誤區導致我花了一周的時間解決一個內存泄露的bug。 還有一個例子，之前我的一個同事一直以為[NSDate new]是產生當前時間，并不需要釋放，這也是一個比較低級的理解誤區。

5、有些內存問題可能是緩存引起的，并不一定是泄露。比如在Three20(Facebook IPhone Library)里，出于性能的考慮，默認會在內存里cache一些網絡圖片. [UIImage imageNamed:]也會把圖片放到system cache里面，這不能算是泄露，但有時候會引起內存不足。

小結：Objective-C內存管理 調試內存泄露的內容介紹完了，希望本文對你有所幫助。