Correct way to use @autoreleasepools?

I would like to know if the following code is suitable for using the new @autoreleasepool , should I use it that way or let the main autoreleasepool take care of the objects?

  • (void) callAutoReleasedObject will probably be my viewDidAppear or similar function.

Thanks!

 - (UIBarButtonItem*)backButton { UIBarButtonItem* backButton = [[UIBarButtonItem alloc] initWithTitle:@"CustomBackTitle" style:UIBarButtonItemStyleBordered target:nil action:nil]; return [backButton autorelease]; } - (void) callingAutoReleasedObject { @autoreleasepool { [[self navigationItem] setBackBarButtonItem:[self backButton]]; } } 
+4
source share
4 answers

From Apple link :

However, there are three cases where you can use your own abstract pools:

  • If you are writing a program that is not based on a user interface structure, such as a command line tool.

  • If you are writing a loop that creates many temporary objects. You can create an autostart pool in a loop to get rid of these objects before the next iteration. Using the autostart pool in a loop helps reduce the maximum memory footprint of the application.

  • If you create an additional stream. You must create your own auto-advertisement pool as soon as the stream begins; otherwise the application will flow objects. (See "Autorelease Pools and Streams" for details.)

Personally, I created several @autoreleasepool blocks to avoid memory leaks during background synchronization using Core Data, since the framework (which I like) creates a huge amount of auto-implemented objects that MUST be drained to save available memory; )

+8
source

Another reason for creating autoreleasepool is if you are in a loop that creates many objects with auto-implementation.

+2
source

Usually you create an autocomplete pool if:

  • your program starts.
  • you start a new flow
  • you receive a callback from the C or C ++ interface, and you do not know when the caller has set up the pool for you.
  • when you create many objects with auto-implementation. In fact, this should be more common than many people use them. They are easy enough to create.
  • when / ivars data with auto-implemented objects is large and can be freed earlier with an in-place pool. for example, an objc object that contains pixel data or audio data.
  • when debugging offset ref count.

For something as simple as your example, don't worry.

+1
source

The only reason you will need to define your own autodetection pool is if you also create your own streams.

For what you do above, definitely just use the main auto resource pool.

0
source

Source: https://habr.com/ru/post/1393934/


All Articles