Menu
By my understanding, when an object is sent an autorelease message, if no autorelease pools exist other than the one in main.m, the object gets placed in the one in main.m. Assuming this is correct, I have a couple of questions:
1) Do all autoreleased objects stay in that pool until the termination of the app?
2) If 1 is true, does creating an autoreleased object without a local autorelease pool (therefore placing that object in the main.m pool) keep that object in memory until termination of the app or a memory warning is received?
3) When is the main.m autorelease pool drained, other than when the app receives a memory warning or the application is terminated?
For example, in a cellForRowAtIndexPath delegate method such as this:
UITableViewCell *cell = [tableView dequeueReusableCellWithIdentifier:@"Foobar"];
if (cell == nil) {
// No cell to reuse => create a new one
cell = [[[UITableViewCell alloc] initWithStyle:UITableViewCellStyleSubtitle reuseIdentifier:@"Foobar"] autorelease];
// lots of custom stuff
}
return cell;
when are the cells actually released? They have to be autoreleased, because you can't release them before you return them, and you can't release them after, because they are out of scope. By my current understanding, the cells are placed in the topmost autorelease pool, and released when that pool is drained/released. In this case, that would be the only autorelease pool in the application; the one in main.
4) The problem with this it that even when I am done with those cells and the view controller has been released, the cells stay in memory, yes? If this is not the case, could someone provide an explanation of how the memory management in this situation really works? Thanks!
Note: I have looked at Apple's documentation, but it talks mostly about when to use your own local autorelease pools, but not much about how they actually function.
870
An autorelease pool stores objects that are sent a release message when the pool itself is drained. Important. If you use Automatic Reference Counting (ARC), you cannot use autorelease pools directly. Instead, you use @autoreleasepool blocks.
@John - You shouldn't remove the autorelease pool. Create it within the thread so that it can manage autoreleased objects, but anything you wish to hang around after the thread has finished executing should be manually retained (and later manually released), or initialized using -init or copy .
The autoreleasepool allows you to explicitly manage when autorelease objects are deallocated in Swift, just like you were able to in Objective-C. Note: When dealing with Swift native objects, you generally will not receive autorelease objects.
It is the process by which the memory of objects are allocated when they are required and deallocated when they are no longer required.
From the documentation:
The Application Kit creates an autorelease pool on the main thread at the beginning of every cycle of the event loop, and drains 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.
So, autoreleased objects in the default pool will only survive the duration of the current event.
118
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
