有时候我们需要延迟一个对象的引用计数减一操作,比如:
+ (NSArray *)array { return [[NSArray alloc] init] autorelease]; }
由于方法名并不以alloc, new, copy, mutableCopy开头,并且方法内部使用了alloc,需要对因此产生的引用计数负责。
不过如果直接调用release,将会返回野指针,所以我们需要autorelease机制来延迟释放。
我们需要先创建一个autorelease pool,才能有效地实现autorelease机制,否则会导致内存泄露。
当向一个对象obj发送autorelease消息时,会发生如下过程:
- 获取当前autorelease pool,即离事件发生处最近的(inner-most)自动释放池,NSAutoreleasePool实例。
- NSAutoreleasePool实例将obj添加到内部维护的数组中,记录起来。
- 当发送drain消息给自动释放池时,它会遍历内部维护的数组,向每个元素发送一个release消息。
除了我们显式创建的NSAutoreleasePool实例,系统会默认为我们在主线程创建一个:
@autoreleasepool { return UIApplicationMain(argc, argv, nil, NSStringFromClass([AppDelegate class])); }
从可见代码来看,这个自动释放池建立在main函数中,对于我们编码过程中创建的自动释放对象有什么帮助呢?
等到结束UIApplicationMain才释放,跟不释放基本没差别,因为程序运行即将结束。
所以,如果事实真相如此,那么是不合理的。
苹果官方文档有这么一段话:
The Application Kit creates an autorelease pool on the main threadat the beginning of every cycle of the event loop, anddrains it at the end, thereby releasing any autoreleased objects generated while processing an event. If you use the Application Kit, you therefore typically don’t have to create your own pools. If your application creates a lot of temporary autoreleased objects within the event loop, however, it may be beneficial to create “local” autorelease pools to help to minimize the peak memory footprint.
可见,在主线程中每个event loop开始的时候会创建一个autorelease pool,在循环结束时清空自动释放池。
当然,如果在某个局部地方创建很多临时对象,最好也显式创建autorelease pool降低内存峰值。
用代码来求证:
- (void)touchesBegan:(NSSet *)touches withEvent:(UIEvent *)event { TestObject *testObject = [[[TestObject alloc] init] autorelease]; } - (void)touchesEnded:(NSSet *)touches withEvent:(UIEvent *)event { NSLog(@"Touches Ended\n"); [NSAutoreleasePool showPools]; }
通过在TestObject的release方法中输出日志信息,可以看到testObject是在touchesEnded事件前被释放的,即event loop结束前。
这是对主线程而言,那么对其它线程呢?
下面又有一段说明:
Each thread (including the main thread) maintains its own stack of NSAutoreleasePool objects (see “Threads”). As new pools are created, they get added to the top of the stack. When pools are deallocated, they are removed from the stack. Autoreleased objects are placed into the top autorelease pool for the current thread. When a thread terminates, it automatically drains all of the autorelease pools associated with itself.
从上面这段话可以得知每个线程都维护着与自己对应的NSAutoreleasePool对象,将其放在线程栈的栈顶。当线程结束时,会清空自动释放池。
同样地可以用代码来说明:
[NSThread detachNewThreadSelector:@selector(onNewThread:) toTarget:self withObject:nil]; - (void)onNewThread:(id)info { TestObject *testObject = [[[TestObjectalloc] init] autorelease]; }
通过输出结果也可以得知线程结束时,testObject得到释放。
不过,紧接着的一段说明说明了些例外情况:
If you are making Cocoa calls outside of the Application Kit’s main thread—for example if you create a Foundation-only applicationor if youdetach a thread—you need to create your own autorelease pool.
不过当我detach了多个线程出来,发现每个线程仍然有维护autorelease pool。是不是上面这段话我哪里没理解对?幸好在没有autorelease pool存在时,我们向对象发送autorelease消息会有警告输出。
最后,探讨下NSRunLoop和autorelease的关系。
当我们分离了个线程,并且让runloop跑起来,我们可以发现与主线程类似:每个runloop循环结束时会drain下autorelease pool。
通过观察runloop状态可以验证:
#pragma mark - RunLoop Observer - (void)onNewThread:(id)info { NSRunLoop *runloop = [NSRunLoop currentRunLoop]; if (!runloop) { return ; } NSTimer *timer = [NSTimer scheduledTimerWithTimeInterval:5.0f target:self selector:@selector(onTimerFired:) userInfo:nil repeats:NO]; [runloop addTimer:timer forMode:NSRunLoopCommonModes]; CFRunLoopObserverContext context = { 0, self, NULL, NULL, NULL }; CFRunLoopObserverRef observerRef = CFRunLoopObserverCreate(kCFAllocatorDefault, kCFRunLoopAllActivities, YES, 0, &runloopObserverCallback, &context); CFRunLoopAddObserver([runloop getCFRunLoop], observerRef, kCFRunLoopCommonModes); [runloop run]; CFRunLoopRemoveObserver([runloop getCFRunLoop], observerRef, kCFRunLoopCommonModes); CFRelease(observerRef); } static void runloopObserverCallback(CFRunLoopObserverRef observer, CFRunLoopActivity activity, void *info) { CFRunLoopActivity currentActivity = activity; switch (currentActivity) { casekCFRunLoopEntry: NSLog(@"kCFRunLoopEntry \n"); break; casekCFRunLoopBeforeTimers: NSLog(@"kCFRunLoopBeforeTimers \n"); break; casekCFRunLoopBeforeSources: NSLog(@"kCFRunLoopBeforeSources \n"); break; casekCFRunLoopBeforeWaiting: NSLog(@"kCFRunLoopBeforeWaiting \n"); break; casekCFRunLoopAfterWaiting: NSLog(@"kCFRunLoopAfterWaiting \n"); break; casekCFRunLoopExit: NSLog(@"kCFRunLoopExit \n"); break; default: NSLog(@"Activity not recognized!\n"); break; } }
--------------------------------------------------
Jason Lee @ Hangzhou
2012.08.15