iOS內存暴增問題追查與使用陷阱

iOS平臺的內存使用引用計數的機制，而且引入了半自動釋放機制；這種使用上的多樣性，致使開發者在內存使用上很是容易出現內存泄漏和內存莫名的增加狀況； 本文會介紹iOS平臺的內存使用原則與使用陷阱； 深度剖析autorelease機制；低內存報警後的處理流程；並結合自身實例介紹內存暴增的問題追查記錄以及相關工具的使用狀況；

TAG

內存暴增，內存泄漏，autorelease；內存報警；

 

iOS平臺內存常見問題

做爲iOS平臺的開發者，是否曾經爲內存問題而苦惱過？內存莫名的持續增加，程序莫名的crash，難以發現的內存泄漏，這些都是iOS平臺內存相關的常見問題；本文將會詳細介紹iOS平臺的內存管理機制，autorelease機制和內存的使用陷阱，這些將會解決iOS平臺內存上的大部分問題，提升了程序的穩定性；

1 iOS平臺內存管理介紹

iOS平臺的內存管理採用引用計數的機制；當建立一個對象時使用alloc或者allWithZone方法時，引用計數就會+1；當釋放對象使用release方法時，引用計數就是-1；這就意味着每個對象都會跟蹤有多少其餘對象引用它，一旦引用計數爲0，該對象的內存就會被釋放掉；另外，iOS也提供了一種延時釋放的機制AutoRelease，以這種方式申請的內存，開發者無需手動釋放，系統會在某一時機釋放該內存； 因爲iOS平臺的這種內存管理的多樣性，致使開發者在內存使用上很容易出現內存泄漏或者程序莫名崩潰的狀況，本文會詳細介紹iOS平臺內存的使用規範與技巧以及如何利用工具避免或者發現問題；

下圖是內存從申請到釋放的一個完整示例：

 

 

 

2 iOS平臺內存使用原則

2.1 對象的全部權與銷燬

2.1.1 誰建立，誰釋放；

若是是以alloc，new或者copy，mutableCopy建立的對象，則必須調用release或者autorelease方法釋放內存；

若是沒有釋放，則致使內存泄漏！

2.1.2 誰retain，誰釋放；

若是對一個對象發送 retain消息，其引用計數會+1，則使用完必須發送release或者autorelease方法釋放內存或恢復引用計數；

若是沒有釋放，則致使內存泄漏！

2.1.3 沒建立且沒retain，別釋放；

不要釋放那些不是本身alloc或者retain的對象，不然程序會crash；

不要釋放autorelease的對象，不然程序會crash；

2.2 對象的深拷貝與淺拷貝

通常來講，複製一個對象包括建立一個新的實例，並以原始對象中的值初始化這個新的實例。複製非指針型實例變量的值很簡單，好比布爾，整數和浮點數。複製指 針型實例變量有兩種方法。一種方法稱爲淺拷貝，即將原始對象的指針值複製到副本中。所以，原始對象和副本共享引用數據。另外一種方法稱爲深拷貝，即複製指針 所引用的數據，並將其賦給副本的實例變量。

2.2.1 深拷貝

深拷貝的流程是 先建立一個新的對象且引用計數爲1，並用舊對象的值初始化這個新對象；

ClassA* objA = [[ClassA alloc] init];

ClassA* objB = [objA copy];

objB是一個新對象，引用計數爲1，且objB的數據等同objA的數據；

注意： objB須要釋放，不然會引發內存泄漏！

2.2.2 淺拷貝

淺拷貝的流程是，無需引入新的對象，把原有對象的引用計數+1便可

ClassA* objA = [[ClassA alloc] init];

ClassA* objB = [objA retain];

注意： objB須要釋放，恢復objA的引用計數，不然會引發內存泄漏！

2.3對象的存取方法

2.3.1 屬性聲明和實現

變量聲明的經常使用屬性類型包括readonly，assign，retain和copy；且系統會自動爲聲明瞭屬性的變量生成set和get函數；

readonly屬性： 只能讀，不能寫；

assign屬性： 是默認屬性，直接賦值，沒有任何保留與釋放問題；

retain屬性： 會增長原有對象的引用計數而且在賦值前會釋放原有對象，而後在進行賦值；

copy屬性：  會複製原有對象，並在賦值前釋放原有對象，而後在進行賦值；

2.3.2 使用屬性聲明可能帶來的隱患

當一個非指針變量使用retain（或者copy）這個屬性時，儘可能不要顯性的release這個變量；直接給這個變量置空便可；不然容易產生過分釋放，致使程序crash； 例如：

ClassA類的strName是NSString* 類型的變量且聲明的屬性爲retain；

ClassA.strName = nil;  /* 釋放原有對象且對此對象賦值爲空 */

[ClassA.strName release]; /* strName內存可能已經被釋放過了，將致使程序crash */

Assign這個屬性通常是非指針變量（布爾類型，×××等）時用這個類型；屬於直接賦值型，不須要考慮內存的保留與釋放；

若是一個指針類型的變量使用assign類型的屬性，有可能引用已經釋放的變量；致使程序crash； 例如：

ClassB* obj =[[[ClassB alloc] init] autorelease];

……

ClassA.strName = obj; /* strName 指向obj的內存地址*/

後續在使用ClassA.strName的時候， 由於obj是autorelease的，可能obj的內存已經被回收；致使引用無效內存，程序crash；

3iOS平臺AutoRelease機制

3.1 自動釋放池的常見問題

你們在開發iOS程序的時候，是否遇到過在列表滑動的狀況內存莫名的增加，頻繁訪問圖片的時候內存莫名的增加，頻繁的打開和關閉數據庫的時候內存莫名的增加…… 這些都是拜iOS的autorelease機制所賜；具體分析以下：

1: 滑動列表的時候，內存出現莫名的增加，緣由可能有以下可能：

1：沒有使用UITableView的reuse機制； 致使每顯示一個cell都用autorelease的方式從新alloc一次； 致使cell的內存不斷的增長；

2：每一個cell會顯示一個單獨的UIView， 在UIView發生內存泄漏，致使cell的內存不斷增加；

2: 頻繁訪問圖片的時候，內存莫名的增加；

頻繁的訪問網絡圖片，致使iOS內部API，會不斷的分配autorelease方式的buffer來處理圖片的解碼與顯示； 利用圖片cache能夠緩解一下此問題；

 

3: 頻繁打開和關閉SQLite，致使內存不斷的增加；

在進行SQLite頻繁打開和關閉操做，並且讀寫的數據buffer較大，那麼SQLite在每次打開與關閉的時候，都會利用autorelease的方式分配51K的內存； 若是訪問次數不少，內存立刻就會頂到幾十兆，甚至上百兆！ 因此針對頻繁的讀寫數據庫且數據buffer較大的狀況， 能夠設置SQLite的長鏈接方式；避免頻繁的打開和關閉數據庫；

3.2 自動釋放池的概念

NSAutoreleasePool內部包含一個數組（NSMutableArray），用來保存聲名爲autorelease的全部對象。若是一個對象聲明爲autorelease，系統所作的工做就是把這個對象加入到這個數組中去。

ClassA *obj1 = [[[ClassA alloc] init] autorelease]; //retain count = 1，把此對象加入autorelease pool中

NSAutoreleasePool自身在銷燬的時候，會遍歷一遍這個數組，release數組中的每一個成員。若是此時數組中成員的retain count爲1，那麼release以後，retain count爲0，對象正式被銷燬。若是此時數組中成員的retain count大於1，那麼release以後，retain count大於0，此對象依然沒有被銷燬，內存泄露。

3.3 自動釋放池的做用域與嵌套

AutoreleasePool是能夠嵌套使用的！
池是被嵌套的，嵌套的結果是個棧，同一線程只有當前棧頂pool實例是可用的：

 

當短生命週期內，好比一個循環中，會產生大量的臨時內存，能夠建立一個臨時的autorelease pool，這樣能夠達到快速回收內存的目的；

3.4 自動施放池的手動建立與自動建立

3.4.1 須要手動建立自動釋放池

●若是你正在編寫一個不是基於Application Kit的程序，好比命令行工具，則沒有對自動釋放池的內置支持；你必須本身建立它們。

●若是你生成了一個從屬線程，則一旦該線程開始執行，你必須當即建立你本身的自動釋放池；不然，你將會泄漏對象。

●若是你編寫了一個循環，其中建立了許多臨時對象，你能夠在循環內部建立一個自動釋放池，以便在下次迭代以前銷燬這些對象。這能夠幫助減小應用程序的最大內存佔用量。

3.4.2 系統自動建立自動釋放池

Application Kit會在一個事件週期（或事件循環迭代）的開端—好比鼠標按下事件—自動建立一個自動釋放池，而且在事件週期的結尾釋放它.

4 iOS平臺內存使用陷阱

4.1 重複釋放

在前文已經提到，不要釋放不是本身建立的對象；

釋放本身的autorelease對象，app會crash；

釋放系統的autorelease對象，app會crash；

4.2 循環引用

 

循環引用，容易產生野引用，內存沒法回收，最終致使內存泄漏！能夠經過弱引用的方式來打破循環引用鏈；所謂的弱引用就是不須要retain，直接賦值的方式，這樣的話，能夠避免循環引用的問題，可是須要注意的是，避免重複釋放的問題；

5 iOS平臺內存報警機制

因爲iOS平臺的內存管理機制，不支持虛擬內存，因此在內存不足的狀況，不會去Ram上建立虛擬內存；因此一旦出現內存不足的狀況，iOS平臺會通知全部已經運行的app，不管是前臺app仍是後臺掛起的app，都會收到 memory warning的notice；一旦app收到memory warning的notice，就應該回收佔用內存較大的變量；

5.1 內存報警處理流程

1： app收到系統發過來的memory warning的notice；

2： app釋放佔用較大的內存；

3： 系統回收此app所建立的autorelease的對象；

4： app返回到已經打開的頁面時，系統從新調用viewdidload方法，view從新加載頁面數據；從新顯示；

5.2 內存報警測試方法

在Simulate上能夠模擬低內存報警消息；

iOS模擬器 -> 硬件 -> 模擬內存警告；

開發者能夠在模擬器上來模擬手機上的低內存報警狀況，能夠避免因爲低內存報警引出的app的莫名crash問題；

6 iOS平臺內存檢查工具

6.1 編譯和分析工具Analyze

iOS的分析工具能夠發現編譯中的warning，內存泄漏隱患，甚至還能夠檢查出logic上的問題；因此在自測階段必定要解決Analyze發現的問題，能夠避免出現嚴重的bug；

內存泄漏隱患提示：

Potential Leak of an object allocated on line ……

數據賦值隱患提示：

The left operand of …… is a garbage value;

對象引用隱患提示：

Reference-Counted object is used after it is released;

 

以上提示均比較嚴重，可能會引發嚴重問題，須要開發者密切關注！

6.2 內存檢測工具

6.2.1 內存泄漏檢測工具—Leak

Leak工具能夠很容易的統計全部內存泄漏的點，並且還能夠顯示在那個文件，哪行代碼有內存泄漏，這樣定位問題比較容易，也比較方面；可是Leak在統計內存泄漏的時候會把autorelease方式的內存也統計進來； 因此咱們在查找內存泄漏狀況的時候，能夠autorelease的狀況忽略掉；

Leak工具：

 

 

經過Leak工具能夠很快發現代碼中的內存泄漏，經過工具也能夠很快找到發生內存泄漏的代碼段：

 

6.2.2 內存猛增檢測工具—Allocations

Allocations工具能夠很容易的列出全部分配內存的點，這樣咱們能夠按照分配內存大小來進行排序， 這樣能夠很容易的發現哪些點分配的內存最多，並且是持續分配，這樣咱們來針對性的分析這些持續分配較大內存的地方；

 

此工具會顯示出全部申請內存的地方，並統計申請的次數和大小； 從這個列表中能夠找出內存申請次數最多且申請內存最大的語句；從而分析出哪些地方使用的內存最多，進而能夠優化和改進；

 

上圖是按照申請內存多少來排序的，能夠方便的瞭解哪些代碼申請的內存多；

7 參考資料

http://www.cocoachina.com/bbs/read.php?tid=15963

http://developer.apple.com/library/IOs/navigation/

 

by lixin

 

【本文首發於： 搜索研發部官方博客】 http://stblog.baidu-tech.com/?p=1371

【 關注百度技術沙龍】