若是你可以真正的理解autorelease,那麼你纔是理解了Objective c的內存管理。Autorelease實際上只是把對release的調用延遲了,對於每個Autorelease,系統只是把該Object放入了當前的Autorelease pool中,當該pool被釋放時,該pool中的全部Object會被調用Release。 html
[1]在Iphone項目中,你們會看到一個默認的Autorelease pool,程序開始時建立,程序退出時銷燬,按照對Autorelease的理解,豈不是全部autorelease pool裏的對象在程序退出時才release, 這樣跟內存泄露有什麼區別? 程序員
答an是,對於每個Runloop, 系統會隱式建立一個Autorelease pool,這樣全部的release pool會構成一個象CallStack同樣的一個棧式結構,在每個Runloop結束時,當前棧頂的Autorelease pool會被銷燬,這樣這個pool裏的每一個Object會被release。 app
那什麼是一個Runloop呢? 一個UI事件,Timer call, delegate call, 都會是一個新的Runloop。例子以下: 函數
NSString* globalObject; - (void)applicationDidFinishLaunching:(UIApplication *)application { globalObject = [[NSString alloc] initWithFormat:@"Test"]; NSLog(@"Retain count after create: %d", [globalObject retainCount]); // output 1. [globalObject retain]; NSLog(@"Retain count after retain: %d", [globalObject retainCount]); // output 2. } - (void)applicationWillTerminate:(UIApplication *)application { NSLog(@"Retain count after Button click runloop finished: %d", [globalObject retainCount]); // 輸出1. Button click loop finished, it's autorelease pool released, globalObject get released once. } -(IBAction)onButtonClicked { [globalObject autorelease]; NSLog(@"Retain count after autorelease: %d", [globalObject retainCount]); // 輸出2。 Autorelease被call, globalObject被加如當前的AutoreleaePool。 }
[2]爲何須要Auto release ? oop
2.1)不少C/C++轉過來的程序員會說,這個auto release有什麼好,象C/C++那樣,本身申請,本身釋放,徹底可控很差麼, 這個auto relase 徹底不可控,你都不知到它何時會被真正的release。個人理解它有一個做用就是能夠作到每一個函數對本身申請的對象負責,本身申請,本身釋放,該函數的調用者不須要關心它內部申請對象的管理。 在下面這個例子中,Func1的調用者不須要再去關心obj的釋放。 spa
ClassA *Func1() { ClassA *obj = [[[ClassA alloc]init]autorelease]; return obj; }
實際上對於 [NSString stringWithFormat:] 這類構造函數返回的對象都是autorelease的。 code
2.2) autorelease pool來避免頻繁申請/釋放內存(就是pool的做用了)。這個應該是相對比較好理解的。 orm
總結:1)必定要注意Autorelease pool的生存週期,理解Runloop,避免在對象被釋放後使用。 htm
2)[NSString stringWithFormat:]這類函數返回的對象是不須要再本身release的,它已經被autorelease了, 若是你想把它當一個全局對象使用,那必須本身再retain, 釋放時再release。 對象
原文標題:Objective C內存管理進階(二):理解autorelease
連接:http://www.cnblogs.com/MobileDevelop/archive/2010/07/19/1779138.html