內(nèi)存泄漏指一個(gè)對(duì)象或變量在使用完成后沒有釋放掉，這個(gè)對(duì)象一直占用這部分內(nèi)存，直到應(yīng)用停止。如果這種對(duì)象過多，內(nèi)存就會(huì)耗盡，其他應(yīng)用就無法運(yùn)行。這個(gè)在問題C++、C和Objective-C的MRC中是比較普遍的問題。

在Objective-C中，釋放對(duì)象的內(nèi)存時(shí)，可以發(fā)送release和autorelease消息，它們都可以將引用計(jì)數(shù)減1。當(dāng)引用計(jì)數(shù)為0時(shí)，release消息會(huì)使對(duì)象立刻釋放，autorelease消息會(huì)將對(duì)象放入內(nèi)存釋放池中延遲釋放。

下面徐州APP制作開發(fā)公司-百恒網(wǎng)絡(luò)為您介紹一下Objective-C工程中ViewController的代碼片段：

大家看看，上面的這3個(gè)方法會(huì)有什么問題呢?如果代碼基于ARC，這是沒有問題的，但遺憾的這是基于MRC的，都存在內(nèi)存泄漏的可能性。從理論上講，內(nèi)存泄漏是由對(duì)象或變量沒有釋放引起的，但實(shí)踐證明并非所有的未釋放對(duì)象或變量都會(huì)導(dǎo)致內(nèi)存泄漏，這與硬件環(huán)境和操作系統(tǒng)環(huán)境有關(guān)，因此我們需要檢測工具幫助我們找到這些“泄漏點(diǎn)”。

在Xcode中，共提供了兩種工具幫助查找泄漏點(diǎn)：Analyze和Instruments。Analyze是靜態(tài)分析工具。可以通過Product→Analyze菜單項(xiàng)啟動(dòng)。圖1所示為使用Analyze工具進(jìn)行靜態(tài)分析之后的代碼界面。Instruments是動(dòng)態(tài)分析工具，它與Xcode集成在一起，可以在Xcode中通過Product→Profile菜單項(xiàng)啟動(dòng)。如圖2所示，Instruments有很多跟蹤模板可以動(dòng)態(tài)分析和跟蹤內(nèi)存、CPU和文件系統(tǒng)。

我們可以結(jié)合使用這兩個(gè)工具查找泄漏點(diǎn)。先使用Analyze靜態(tài)分析查找可疑泄漏點(diǎn)，再用Instruments動(dòng)態(tài)分析中的Leaks和Allocations跟蹤模板進(jìn)行動(dòng)態(tài)跟蹤分析，確認(rèn)這些點(diǎn)是否泄漏，或者是否有新的泄漏出現(xiàn)等。

在圖1所示的Analyze靜態(tài)分析結(jié)果中，凡是有圖標(biāo)的行都是工具發(fā)現(xiàn)的疑似泄漏點(diǎn)。點(diǎn)擊viewDidLoad方法中疑似泄漏點(diǎn)行末尾的圖標(biāo)，會(huì)展開分析結(jié)果，具體如圖3所示。

圖3中的線表明了程序執(zhí)行的路徑。在這個(gè)路徑中，第1處說明在第25行中，Objective-C對(duì)象的引用計(jì)數(shù)是1，說明在這里創(chuàng)建了一個(gè)Objective-C對(duì)象。第2處說明在第27行中引用計(jì)數(shù)為1，該對(duì)象沒有釋放，懷疑有泄漏。這樣的說明已經(jīng)很明顯地告訴我們問題所在了，[[NSArray alloc] initWithContentsOfFile:plistPath]創(chuàng)建了一個(gè)對(duì)象，并賦值給listTeams屬性所代表的成員變量，然而完成了賦值工作之后，創(chuàng)建的對(duì)象并沒有顯式地發(fā)送release和autorelease消息。這里可以將代碼修改如下：

NSArray *array = [[NSArray alloc] initWithContentsOfFile:plistPath];

self.listTeams = array;

[array release];

點(diǎn)擊tableView:cellForRowAtIndexPath:方法中疑似泄漏點(diǎn)行末尾的圖標(biāo)，展開分析結(jié)果，如圖4所示。

這主要說明UITableViewCell *類型的cell對(duì)象在第64行有可能存在泄漏。在表視圖中，tableView:cellForRowAtIndexPath:方法用于實(shí)例化表視圖單元格并設(shè)置數(shù)據(jù)，因此cell對(duì)象實(shí)例化后不能馬上釋放，而應(yīng)該使用autorelease延遲釋放。可以在創(chuàng)建cell對(duì)象時(shí)發(fā)送autorelease消息，將代碼修改如下：

if (cell == nil) {

cell = [[[UITableViewCell alloc] initWithStyle:UITableViewCellStyleDefault

reuseIdentifier:CellIdentifier] autorelease];

}

我們?cè)倏匆幌聇ableView:didSelectRowAtIndexPath:方法中的疑似泄漏點(diǎn)，共有兩個(gè)。點(diǎn)擊行末尾的圖標(biāo)，展開分析結(jié)果，具體如圖5和圖6所示。

圖5所示的是message對(duì)象創(chuàng)建之后沒有釋放，我們只需要在[alert show]之后添加[message release]語句代碼就可以了。

在Objective-C中，實(shí)例化對(duì)象有如下兩種方式：

NSString *message = [[NSString alloc] initWithFormat:@'您選擇了%@隊(duì)。', rowValue]; ①

NSString *message = [NSString stringWithFormat:@'您選擇了%@隊(duì)。', rowValue]; ②

第①行所示的以init開頭的構(gòu)造方法在alloc之后調(diào)用，我們將其稱為“實(shí)例構(gòu)造方法”。對(duì)于使用該方法創(chuàng)建的對(duì)象，其所有權(quán)是調(diào)用者，調(diào)用者需要對(duì)它的生命周期負(fù)責(zé)，具體說就是負(fù)責(zé)創(chuàng)建和釋放。第②行所示的以string開頭的方法，它通過類直接調(diào)用，我們將其稱為“類級(jí)構(gòu)造方法”。對(duì)于使用該方法創(chuàng)建的對(duì)象，其所有權(quán)非調(diào)用者所有，調(diào)用者無權(quán)釋放它，否則就會(huì)因過度釋放而“僵尸化”。

圖6所示的是UIAlertView *類型的alert對(duì)象創(chuàng)建后沒有釋放，我們只需要在[alert show]之后添加[alertrelease]語句就可以了。修改之后的代碼如下：

上面介紹的是使用Analyze靜態(tài)分析查找可疑泄漏點(diǎn)。之所以稱為“可疑泄漏點(diǎn)”，是因?yàn)檫@些點(diǎn)未必一定泄漏。確認(rèn)這些點(diǎn)是否泄漏，還要通過Instruments動(dòng)態(tài)分析工具中的Leaks和Allocations跟蹤模板。Analyze靜態(tài)分析只是一個(gè)理論上的預(yù)測過程。在Xcode中通過Product→Profile菜單項(xiàng)啟動(dòng)Instruments動(dòng)態(tài)分析工具，接著選擇Leaks模板，打開的界面如圖7所示。

在Instruments中，雖然選擇了Leaks模板，但默認(rèn)情況下也會(huì)添加Allocations模板。基本上凡是分析內(nèi)存都會(huì)使用Allocations模板，它可以監(jiān)控內(nèi)存分布情況。選中Allocations模板(圖中①區(qū)域)，右邊的③區(qū)域會(huì)顯示隨著時(shí)間的變化內(nèi)存使用的折線圖，同時(shí)在④區(qū)域會(huì)顯示內(nèi)存使用的詳細(xì)信息以及對(duì)象分配情況。點(diǎn)擊Leaks模板(圖中②區(qū)域)，可以查看內(nèi)存泄漏情況。如圖8所示，如果在③區(qū)域有紅線出現(xiàn)，則有內(nèi)存泄漏，④區(qū)域則會(huì)顯示泄漏的對(duì)象。

圖8中出現(xiàn)的泄漏是在點(diǎn)擊表視圖中單元格測試tableView:didSelectRowAtIndexPath:方法時(shí)發(fā)生的，點(diǎn)擊泄漏對(duì)象Address列后面的按鈕，會(huì)進(jìn)入如圖9所示的詳細(xì)界面。可以發(fā)現(xiàn)，里面有兩個(gè)對(duì)象，可以看到它們的內(nèi)存地址、占用字節(jié)、所屬框架和響應(yīng)方法等信息。

在圖9中，點(diǎn)擊右邊的跟蹤堆棧信息按鈕，如圖10所示，其中圖標(biāo)所示的條目是我們自己應(yīng)用的代碼，點(diǎn)擊它即可進(jìn)入程序代碼，如圖11所示。

圖11所示的第84行代碼是可能的泄漏點(diǎn)。事實(shí)上，內(nèi)存泄漏是極其復(fù)雜的問題，工具使用是一方面，經(jīng)驗(yàn)是另一方面。提高經(jīng)驗(yàn)，然后借助于工具才是解決內(nèi)存泄漏的根本。