I'm experiencing a very weird CPU usage bug with my audio streaming app.
When the app is in the foreground and playing music, the total device CPU usage is only about 15%. However, as soon as the app is put in the background, the CPU usage spikes to 100% and stays there.
About 40% of this is coming from the app process itself, and roughly the other 60% is coming from the SpringBoard process, which apparently handles all Core Animation calls (though I'm not explicitly using Core Animation, I assume that it also handles other UI related activity). Also, according to the "CPU Activity" instrument, most of the additional CPU usage from the app process itself falls into the "graphics" category, though I do see an increase in both the "audio processing" and (strangely) the "foreground app activity" category.
How can I figure out what is causing this problem? Instruments is telling me at high level what is happening, but not why it's happening.
That's extremely odd. However, without any code, it makes it really hard to say anything about anything. Purely based on speculation, I'd say you're updating the UI without knowing it in the background. Perhaps an animation call on -(void)applicationDidEnterBackground? Give us some more to work with! I'm really curious about this now :)
Mystery solved!
Of course I missed the obvious, thank you to Dylan G for pointing me in the right direction. I was running a loop to check the remaining background time. I wasn't sleeping the loop thread at all so it was apparently just running full speed sucking up all CPU power.
I'm not sure why it was looking like it was graphics related and involving the SpringBoard process, but as soon as I added a sleep(1) at the end of the loop, the CPU usage no longer rose when the app was placed in the background. The strange thing is that I'm not calling any UI or graphic related methods in that loop, just calls to [[UIApplication sharedApplication] backgroundTimeRemaining] and accessing some integer and bool properties.
There is still a quick spike of CPU for the second or so after it's placed in the background, and SpringBoard spikes as well, but just for a second, then CPU usage drops back to the same as when the app is running.
Related
I am working on an OpenGL application for the iPhone...
My app has only 2 views:
An OpenGL view and, as a subview for the OpenGL view, a view with the sole purpose of catching touch events...
The problem is that after about 10-15 minutes of keeping the app running on the device, I get a big (0.5s-1s) delay between every touchesMoved:withEvent: call
The animation runs smooth, and CPU usage is also not the problem (10% at most)
I have no idea what might be causing this
That is weird, eh.
This happens ON THE DEVICE right? When you are not running tethered from XCode?
I would guess you are using up a lot of memory, either a leak or just in some way using up more and more memory as time goes on.
Are you familiar with the various memory tools to watch what is going on?
Also, what about this: launch a few other large apps that remain in the background. Run your app until the problem exhibits. Then, kill the other apps. Does the problem suddenly go away? If so that would suggest you're low on memory.
Would be interested to hear.
Occasionally in low-memory conditions the UIImagePickerController I use gets 'stuck' with the shutter closed. Generally when this the WatchDog is allready jettisoning other background apps so within a second or two the low memory condition is over, yet the UIImagePicker controller is still stuck.
Has anyone else encountered this and implemented any sort of workaround or found a way to detect when the picker is in this state, so that it can be removed and a new one put in its place.
Thoughts / Ideas / Solutions??
Have you tried allocating (and then freeing) a megabyte or two of memory using malloc() before starting the UIImagePicker? Or claim it slightly earlier in your app, and then release it when you want to show the picker.
I guess you should be able to see roughly the amount of memory UIImagePicker needs to run successfully by running your app inside of instruments.
Whilst not ideal, it should cause other apps to be given memory warnings earlier on and hence the UIImagePicker should then have enough memory to run.
That's a known behavior of the camera application too. I guess you can't do anything to it except freeing as much memory as you can before starting it. You could raise a memoryWarning yourself so every application will receive it and start freeing memory but I have no idea how I can do that. I started investigate sending the notification myself (UIApplicationDidReceiveMemoryWarningNotification) without success. I guess we need to send an object along the notification to define the warning level but I'm really not sure.
Is there a way to increase the application priority for the CPU on iPhone? I notice that SpringBoard takes up too much CPU at times causing some fluctuation in performance on the device.
What you're seeing is probably an artifact related to Core Animation. The Core Animation server on the iPhone is owned by Springboard, so many Core-Animation-related actions (calculations related to animation, etc.) appear to be performed by Springboard even though they were initiated by your application. This is not a case of Springboard itself burning CPU time in the background, it's just how some of this processing looks when running Instruments or similar tools against the device.
In this case, I'd look at how you were animating things around the screen (even implicitly using the UIKit interface elements), or how those views or layers were being composited, in order to smooth out your performance issues.
I've observed similar behavior in an Apple example app and a game I am working on. In the game, the behavior is eventually causing the app to crash due to running out of memory. The example app is Touches.
At any point when touches are being tracked, which is when you're moving one of the objects around in Touches, and pretty much any time a touch is down in my game, memory usage goes up steadily, for as long as you continue moving the touch around. Once the touch sequence completes, the memory usage does not go back down. I've gotten Touches, which starts off using less than half a meg, up to about 4MB net allocations with a few minutes playing around. That memory is never deallocated.
So my question is: why does this memory never get deallocated? Am I fundamentally misunderstanding something? Is this a framework flaw? I've read some about issues with the accelerometer and touches leaking, but I'm not using the accelerometer at all in this game.
I apologize if this seems TOO elementary, but...
There's no chance you have NSZombiesEnabled set to YES, do you?
That would prevent the deallocation of any objects whatsoever, and if you did allocate new ones, then EVENTUALLY the app will run out of memory.
Use instruments to find what instances are not being deallocated. I had a similar problem, and all it came down to was that I was calling retain, but not release (due to a logic error).
Im in a very similar situation. In fact, if i just let me app run without touching anything (all it does is run an NSTimer to update the display). And i notice the memory slowly but steadily increasing in usage.
If there are memory leaks its not obvious. Because ive seen memory leaks popup whenever it detects one.
So does that mean there are undetectable memory leaks?
I'm programming an puzzle game for iPhone using openGL.
There Is one very weird "bug" ( I'm not sure what It is)... whenever I touch the screen a great number of times in a short period of time my app closes, without giving a warning or error.
What could be the cause ?, I guess It has something to do with the memory, but I would like to know.
Edit:
I also think this happens because I'm calling multiple functions every time the user touches the screen or moves his fingers.
Sounds like you're running out of memory.
A few quick tips that might help out:
Check your memory profile over time using Instruments. If you see a steady incline over time, it's likely to be a memory leak, or an inefficient algorithm that is allocating more memory than you need.
Use a static analyzer to help check for leaks, such as Clang.
Images and image-related files are particularly memory-hungry, so focus on efficiency for them. When you work with textures in OpenGL, use the PVRTC format, which offers awesome compression.
didReceiveMemoryWarning: is your friend - aka a good chance to throw out anything you don't absolutely need in memory. Better to be memory-efficient the whole time, though.
Try setting up an NSUncaughtExceptionHandler. You may also want to setup a signal handler.