How to debug iOS crash due to memory pressure
I solved the problem. In my case, the memory pressure, it was due to the constant memory usage by a run loop cycle. The loop is executed every second and works on data that must be analyzed and presented in the views. Another thing, the project initially was not using ARC. After a conversion project to ARC has occurred the problem.
Before the conversion of the project to ARC, at the end of the loop I had a direct call for the release of resources. With ARC of course this is done automatically, and the problem is just that. So for the class that runs the loop, I returned to non-ARC version and I used the tricks to make manually to release the resources that I used.
Autorelease pool blocks provide a mechanism whereby you can relinquish ownership of an object, but avoid the possibility of it being deallocated immediately (such as when you return an object from a method). Typically, you don’t need to create your own autorelease pool blocks, but there are some situations in which either you must or it is beneficial to do so.
@autoreleasepool { // Code that creates autoreleased objects.}At the end of the autorelease pool block, objects that received an autorelease message within the block are sent a release message—an object receives a release message for each time it was sent an autorelease message within the block.
You can place an @autoreleasepool block around any section of code, however you really shouldn't do what I think you're doing.
Autorelease is much less efficient than allowing ARC to add in retain and release calls for you, and it's potentially unsafe. Autorelease puts all of your objects in a "pool" and then when you're out of scope and/or whenever it decides to dump the pool, it "drains" the pool and the objects' retain counts get decremented by one.
The short answer: Leave out the @autorelease blocks completely unless Apple says otherwise in the documentation or the template (for example, main.m will have an @autoreleasepool in it).
This means that your objects could potentially get released before you really wanted them to. @autoreleasepool blocks are more useful for when you have a very tight loop of code that's going to instantiate and then discard a massive amount of objects. For example, a for loop that processes a huge database and allocates string objects and then uses those string objects to fill the properties of instances of a class you've created. In this case, ARC may not release those objects reliably while you're inside the for loop and you may need to create an autorelease pool.
However, ARC not doing the right thing in a tight loop isn't very common. It's really more of a non-ARC concept, where you use an NSAutoreleasePool and you manually drain it.
I hope I have helped others with the same problem.
#pragma mark - Received Memory Warning//memory pressure ios- (void)didReceiveMemoryWarning{ [super didReceiveMemoryWarning]; if ( [self isViewLoaded] && self.view.window == nil ) { self.view = nil; } // Dispose of any resources that can be recreated.}