"Received memory warning" while running app on device - ios

Question

I'm working on an iPhone Video decoder application. I need to convert raw pixel data for each frame and render it on the screen continuously (Hence forming a video). The function below is the one that renders each frame on the screen.
- (void)drawBufferWidth:(int)width height:(int)height pixels:(unsigned char*)pixels
{
CGColorSpaceRef colorSpace = CGColorSpaceCreateDeviceRGB();
CGContextRef gtx = CGBitmapContextCreate(pixels, width, height, BitsPerComponent, BytesPerRow, colorSpace, kCGImageAlphaPremultipliedLast);
CGColorSpaceRelease(colorSpace);
myimage = CGBitmapContextCreateImage(gtx); //myimage is of type CGImageRef
CGContextRelease(gtx);
img.image = [UIImage imageWithCGImage:myimage]; //img is of type UIImageView
[CATransaction flush];
CGImageRelease(myimage);
myimage = Nil;
}
The code is working absolutely fine on the simulator. When I run it on the device, it displays few frames, gives "Received memory warning" and crashes.
I'm not able to figure out where the problem is. Am I not deallocating properly or even though I'm releasing the image, it is still existing in the memory, thus eating up the memory?
Kindly help!
Thanks in advance.
EDIT:
The Xcode organizer says the following:
hevcd[665] has active assertions beyond permitted time:
{(
<SBProcessAssertion: 0x11aacf70> identifier: Suspending process: hevcd[665] permittedBackgroundDuration: 10.000000 reason: suspend owner pid:565 preventSuspend preventThrottleDownCPU preventThrottleDownUI
)}

Answer 1

A couple of observations:
Let's imagine that you have a for loop:
for (i = start; i < end; i++)
{
// doing lots of memory intensive stuff
}
You must recognize that any memory that is auto released during this loop will not actually be yielded back to the operating system until that loop completes and the auto release pool is flushed. When doing memory intensive operations, you could theoretically do:
for (i = start; i < end; i++)
{
#autorelease {
// doing lots of memory intensive stuff
}
}
That way, you're manually creating a new autorelease pool that will be flushed with greater frequency.
Having said that, you really should not be doing prolonged tasks that do not yield back to the operation system (at least on the main thread, and because you're doing UI stuff, you have to do that on the main thread). A better model than performing some prolonged for loop would be let the operating system call your code at some regular interval. Then the standard autorelease pool will do it's job and you should be fine. You create a timer like so:
- (void)startTimer
{
self.timer = [NSTimer scheduledTimerWithTimeInterval:0.1
target:self
selector:#selector(handleTimer:)
userInfo:nil
repeats:YES];
}
You then have a routine to handle the timer:
- (void)handleTimer:(NSTimer *)timer
{
// do what you need here
}
Make sure that you turn off your timer (e.g. when the view disappears), or else when this view controller is dismissed, it won't be released because the timer will maintain its strong reference to it and you'll have a retain cycle (or strong reference cycle) and you'll leak memory.
- (void)viewWillDisappear:(BOOL)animated
{
[self.timer invalidate];
}
You can achieve similar functionality using CADisplayLink, too. You can create the display link:
- (void)startDisplayLink
{
self.displayLink = [CADisplayLink displayLinkWithTarget:self selector:#selector(handleDisplayLink:)];
[self.displayLink addToRunLoop:[NSRunLoop currentRunLoop] forMode:NSDefaultRunLoopMode];
}
- (void)handleDisplayLink:(CADisplayLink *)displayLink
{
// do what you need here
}
and again, you'd want to make sure you stop it when you're done:
- (void)viewWillDisappear:(BOOL)animated
{
[self.displayLink invalidate];
}
All three of those scenarios could probably remedy your memory situation (unless you have some undetected retain cycle or leak).