記憶體洩漏問題的解決

記憶體洩漏（Memory Leaks）是當一個物件或變數在使用完成後沒有釋放掉，這個物件一直佔有著這塊記憶體，直到應用停止。如果這種物件過多記憶體就會耗盡，其它的應用就無法執行。這個問題在C++、C和Objective-C的MRR中是比較普遍的問題。

在Objective-C中釋放物件的記憶體是傳送release和autorelease訊息，它們都是可以將引用計數減1，當為引用計數為0時候，release訊息會使物件立刻釋放，autorelease訊息會使物件放入記憶體釋放池中延遲釋放。

上程式碼：

-(void)viewDidLoad

{[super viewDidLoad
 
];NSBundle*bundle =[NSBundle mainBundle];NSString*plistPath =[bundle pathForResource:@"team"

ofType:@"plist"];//獲取屬性列表檔案中的全部資料self.listTeams =[[NSArray alloc] initWithContentsOfFile:plistPath];}-(UITableViewCell*)tableView:(UITableView*)tableView cellForRowAtIndexPath:(NSIndexPath*)indexPath

{static
 
NSString*CellIdentifier=@”CellIdentifier”;UITableViewCell*cell =[tableView dequeueReusableCellWithIdentifier:CellIdentifier];if(cell ==nil){

cell =[[UITableViewCell alloc] initWithStyle:UITableViewCellStyleDefault     reuseIdentifier:CellIdentifier];}NSUInteger row =[indexPath row];NSDictionary*rowDict 
 
=[self.listTeams objectAtIndex:row];

cell.textLabel.text =[rowDict objectForKey:@"name"];NSString*imagePath =[rowDict objectForKey:@"image"];

imagePath =[imagePath stringByAppendingString:@".png"];

cell.imageView.image =[UIImage imageNamed:imagePath];

cell.accessoryType =UITableViewCellAccessoryDisclosureIndicator;return cell;}-(void)tableView:(UITableView*)tableView didSelectRowAtIndexPath:(NSIndexPath*)indexPath

{NSUInteger row =[indexPath row];NSDictionary*rowDict =[self.listTeams objectAtIndex:row];NSString*rowValue  =[rowDict objectForKey:@"name"];NSString*message =[[NSString alloc] initWithFormat:@”您選擇了%@隊。”, rowValue];UIAlertView*alert =[[UIAlertView alloc]initWithTitle:@”請選擇球隊”

message:message

delegate:self

cancelButtonTitle:@”Ok”

otherButtonTitles:nil];[alert show];[tableView deselectRowAtIndexPath:indexPath animated:YES];}

大家看看上面的3個方法會有什麼問題呢？如果程式碼是基於ARC的是沒有問題的，遺憾的是基於MRR，上面的程式碼都存在記憶體洩漏的可能性。理論上講內 存洩漏是物件或變數沒有釋放引起的，但實踐證明並非所有的未釋放物件或變數都會導致記憶體洩漏，這與硬體環境和作業系統環境有關，因此我們需要檢測工具幫助 我們找到這些“洩漏點”。

在Xcode中提供了兩種工具幫助查詢洩漏點：Analyze和Profile，Analyze是靜態分析工具可以通過選單 Product→Analyze啟動，為靜態分析之後的程式碼畫面；Profile是動態分析工具，這個工具叫“Instruments”，它是Xcode 整合在一起，可以在Xcode中通過選單Product→Profile啟動，Instruments有很多Trace Template（跟蹤模板）可以動態分析和跟蹤記憶體、CPU和檔案系統。

我們可以兩個工具結合使用查詢洩漏點，先使用Analyze靜態分析查詢可疑洩漏點，再用Profile動態分析中的Leaks和Allocations跟蹤模板進行動態跟蹤分析，確認這些點是否洩漏，或者是否有新的洩漏出現等。

其中的線段表明了程式執行的路徑，在這個路徑中，1:說明在25行Objective-C物件引用計數是1，說明在這裡建立了一個 Objective-C物件；2:說明在27行引用計數為1這個，該物件沒有釋放，懷疑有洩漏。這樣的說明已經很明顯的告訴我們問題所在了， [[NSArray alloc] initWithContentsOfFile:plistPath]建立了一個物件，並賦值給 listTeams屬性所代表的成員變數，然而完成了賦值工作之後，建立的物件並沒有顯示地傳送release和autorelease訊息。程式碼修改

NSArray*array =[[NSArray alloc] initWithContentsOfFile:plistPath];self.listTeams = array;[array release];

我們看一下tableView:cellForRowAtIndexPath:方法中的疑似洩漏點行末尾的藍色圖示展開分析結果

其中主要是說明UITableViewCell*型別的cell物件在64行有可能存在洩漏。在表檢視中 tableView:cellForRowAtIndexPath:方法是為表檢視單元格例項化並設定資料的，因此cell物件例項化後不能馬上 release，應該使用autorelease延遲釋放。可以在建立cell物件的時候傳送autorelease訊息，程式碼修改如下：

if(cell ==nil){

cell =[[[UITableViewCell alloc] initWithStyle:UITableViewCellStyleDefault     reuseIdentifier:CellIdentifier] autorelease];}

我們看一下tableView:didSelectRowAtIndexPath:方法中的疑似洩漏點有兩個，行末尾的圖示展開分析結果。

message物件建立之後沒有釋放，我們只需要在[alert show]之後新增[message release]語句程式碼就可以了。在Objective-C中例項化物件有兩種方式：

NSString*message =[[NSString alloc] initWithFormat:@”您選擇了%@隊。”, rowValue];①NSString*message =[NSString stringWithFormat:@"您選擇了%@隊。", rowValue];②

①行所示以init-開頭構造方法，它的是在alloc之後呼叫該方法我們稱為“例項構造方法”，該方法建立物件所有權是呼叫者，呼叫者需要對它的 生命週期負責，具體說負責建立和釋放。而另一種是②行所示string-（去掉NS後類名）開頭方法，它是通過類直接呼叫我們稱為“類級構造方法”，該方 法是建立的物件所有權非呼叫者所有，呼叫者不無權釋放它，否則就會因過渡釋放而“殭屍化”，這個問題我們會在下一節介紹。

UIAlertView*型別alert物件建立之後沒有釋放，我們只需要在[alert show]之後新增[alert release]語句程式碼就可以了，修改之後的程式碼

-(void)tableView:(UITableView*)tableView didSelectRowAtIndexPath:(NSIndexPath*)indexPath

{NSUInteger row =[indexPath row];NSDictionary*rowDict =[self.listTeams objectAtIndex:row];NSString*rowValue  =[rowDict objectForKey:@"name"];NSString*message =[[NSString alloc] initWithFormat:@”您選擇了%@隊。”, rowValue];UIAlertView*alert =[[UIAlertView alloc]initWithTitle:@”請選擇球隊”

message:message

delegate:self

cancelButtonTitle:@”Ok”

otherButtonTitles:nil];[alert show];[alert release];[message release];[tableView deselectRowAtIndexPath:indexPath animated:YES];}

上面介紹的使用Analyze靜態分析查詢可疑洩漏點，之所以稱為“可疑洩漏點”，但是這些點未必一定洩漏，確認這些點是否洩漏還要通過 Profile動態分析工具Instruments中的Leaks和Allocations跟蹤模板，Analyze靜態分析只是一個理論上的預測過程。 通過選單Product→Profile啟動， Profile動態分析工具中選擇Leaks模板

Instruments中雖然是選擇了Leaks模板，但預設情況也會新增Allocations模板，基本上凡是分析記憶體都會使用 Allocations模板，它可以監控記憶體分佈情況，選中Allocations模板（圖中①區域），右邊③區域會顯示隨著時間的變化記憶體使用折線圖 表，同時在④區域會顯示記憶體使用的詳細資訊，其中剛剛物件分配情況。點選Leaks模板（圖中②區域），可以檢視記憶體洩漏情況，如果在③區域有紅線出現， 則有記憶體洩漏，④區域會顯示洩漏的物件。

出現的洩漏是在點選表檢視中單元格測試tableView:didSelectRowAtIndexPath:方法方法時候發生的，其中 NSCFString型別的物件發生了洩漏，NSCFString型別在NSFoundation中是NSString*型別。點選洩漏物件前面的三角形 展開物件，可以看到它們的記憶體地址、佔用位元組、所屬框架和響應方法資訊。

開啟擴充套件詳細檢視，可以看到右邊的跟蹤堆疊資訊，其中我們自己應用程式碼，可以點選進入我們程式程式碼，會開啟對應程式碼。

程式碼77並不是洩漏點，而是其中的NSString*型別物件在之後發生了洩漏，因此可以斷定是message物件之後沒有釋放導致洩漏。我們修改程式碼如下：

-(void)tableView:(UITableView*)tableView didSelectRowAtIndexPath:(NSIndexPath*)indexPath

{NSUInteger row =[indexPath row];NSDictionary*rowDict =[self.listTeams objectAtIndex:row];NSString*rowValue  =[rowDict objectForKey:@"name"];NSString*message =[[NSString alloc] initWithFormat:@”您選擇了%@隊。”, rowValue];UIAlertView*alert =[[UIAlertView alloc]initWithTitle:@”請選擇球隊”

message:message

delegate:self

cancelButtonTitle:@”Ok”

otherButtonTitles:nil];[alert show];[message release];[tableView deselectRowAtIndexPath:indexPath animated:YES];}

新增[message release]語句。很多人還會猜測alert物件（UIAlertView*）會有洩漏，因此重新執行Instruments工具，反覆點選單元格測 試，並未發現表示記憶體洩漏的紅線！ Instruments工具認為alert物件不釋放不會引起記憶體洩漏，如果我們想進一步評估它對於記憶體的應用，這個時候我們可以看看 Allocations模板的折線圖表，每次點選總佔用記憶體數都有所增加，這說明alert物件沒有釋放雖然不是很嚴重，但是也會增加佔用記憶體，因此 alert物件釋放也是必須的。 

這就是我們介紹的記憶體洩漏問題解決方法，事實上記憶體洩漏是極其複雜問題，工具使用是一方面，經驗是另一方面。提高經驗，然後藉助於工具才是解決記憶體洩漏的根本。