Objective-C記憶體管理 調試記憶體泄露

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記憶體管理 調試記憶體泄露的內容介紹完了，希望本文對你有所協助。