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.
Related
I'm making an iPhone game which has a quite intense use of pixel shaders. Some effects make my fps rate sometimes drop down to ~22 FPS in the 3GS, but it is around ~27 most of the time.
When the FPS rate is down there, the touch gesture response becomes extremely choppy. In other words, the gesture update time reaches nearly 5hz, which is much slower than the game itself.
Has anyone experienced similar problems? Is there any way around it?
Note1: I'm already using CADisplayLink
EDIT: I had a significant improvement by manually skipping even frames. I'm not sure if that is a good thing to do but the game remained quite playable and I'm sure it is using much less CPU now.
I have a similar situation in one of my applications, where I have very heavy shaders that can lead to slower rendering on older devices, but I still want to have the framerate be as fast as it can on more powerful hardware.
What I do is use a single GCD serial queue for all OpenGL ES rendering-related actions, combined with a dispatch semaphore. I use CADisplayLink to fire at 60 FPS, then within the callback I dispatch a block for the actual rendering action. I use a dispatch semaphore so that if the CADisplayLink tries to add another block to the rendering queue while one is running, that new block is dropped and never added.
I describe this approach in detail in this answer, and you can download the source code for my application which uses this here.
The GCD queue lets you move this rendering to a background thread, which leaves your interface responsive, while scaling the FPS so that your rendering runs as fast as your hardware supports. This has particular advantages on the new dual core iOS devices, because I noticed significant rendering speed increases just by performing my OpenGL ES updates on this background queue.
However, as I describe in that answer, you'll need to funnel all of your OpenGL ES updates through this queue to avoid the potential for more than one thread from simultaneously accessing an OpenGL ES context (which causes a crash).
If your app's game loop run at 22 fps, but is requesting 30 fps, that means that the app is oversubscribing the total number of CPU cycles available per second in the UI run loop. Either try putting more stuff in background threads, or turn your requested frame rate down to below what you can actually get (e.g. set it to 20 fps), so that there is more time left for UI stuff, such as touch event delivery.
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.
I made a board game with includes just some little animations. I reduced the fps from 60 to 30 to reduce the processor load. But the device still gets very warm.
Another application made without cocos2d is not heating it so much.
Are there any methods to calm the iPhone down?
The device state is as follows:
Wifi is always enabled
The app uses gamecenter
GPS is inactive
fps is always on 30
I use cocos2d-iphone as engine
It might be worth experimenting with different director types, e.g. kCCDirectorTypeNSTimer, and seeing if that helps at all. Those will have the biggest effect on the main loop of the game.
You should also spend some time with Instruments if you've not already, as that will show you where the CPU is spending its time and give you some hints on where you could ease things up.
I've noticed that a sequence of small time animations in cocos2d takes a lot of processor time. I've tried making tips at the level which will pulse in size. 0.1 second pulse up, 0.15 down and 0.2 stay. And i've put it all in a repeat forever sequence. Everything was terribly slow. Then i've just made the animation manually and the device calmed down and fps increased back to 60
When showing menus or dialogs that do not require animation, you can actually lower your framerate even further.
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.
I'm writing a finger sketch type app and had the app working great on iOS 3.0. However, running the app under iOS 4.0 or greater is causing problems. Specifically, I am receiving touch events to my app approximately 5x slower on the new OS than on the old. This obviously causes my app to draw poorly because I'm capturing 5x less data points to draw between.
Any ideas on how to speed up touch event frequency on iOS4?
Certain graphics operations take a lot longer in iOS4.x than in 3.x (somewhere between 2X to 10X slower). The longer graphics execution times could be blocking the main UI thread, and not leaving enough time for the main thread run loop to handle user (touch) events.
Profile your drawRect code and see if it's now taking longer that one refresh rate tick time. If so, try speeding up or breaking up your graphics renders, or try a lower frame rate, and see if any of that helps.
You should profile your code with Shark to see where the bottleneck is. What is probably happening is some of your code that executes on the main thread (most likely something that runs in response to a touch) is taking longer than expected which is preventing your app from receiving touch events
Block the main thread less.