I've noticed that since iOS 4.0, the apps I developed started to not "exit" when the home button is pressed, but rather they stay in the "system tray" thing which pops out when you double click the system.
At around the same time, I noticed that the battery in my phone starts draining a lot faster. Then again, theoretically all the app should be using right now is only memory, because it is not currently active.
Which begs the question, has there ever been any benchmark on what causes the iPhone to drain the most batteries? Perhaps opengl calls, which use the graphics card would consume quite a bit? Or maybe just having the apps active mean there's less memory, and this causes faster battery loss (say, because the memory allocator must do more work etc)?
I am keen to know what other developers have tried to do to optimise battery usage.
its not opengl or allocations that cause the battery drain in fact the variables are saved on the hard disk when the application quit. They don't stay in memory cause this wouldn't be possible with running all apps at the same time. (see comments)
special thanks to Stephen Furlani for this guide in documentation
I think the only ones that can cause the faster drain are background processes that still accepted to be run in background like the voice over IP feature from Skype. (the features where big announced at the iOS 4 SDK preview back then). Background audio/video, network transfers like pandora etc. (I can't name all) but not every app!
And by the way, I also noticed that my battery sometimes not hold as long as possible on other days. But I can't locate which App cause that :(
Related
I'm building my app on a development device that does not have too many apps running at the same time. I'm expecting my customers to run the app with any number of other apps open. To ensure my app wont crash due to memory issues, I would like to test my app under expected operating conditions.
This poses a question - does the number of other apps visible in the double tap home button bar affects the memory usage of the device? In other words, if I open every app on the device, then start my app, am I more likely to receive memory warnings than if I have all other apps closed?
I remember hearing a WWDC presentation that mentioned that for some apps that use <8mb of memory, their memory gets written to disk while the app is minimized, not sure what this changes.
Thank you for the clarification.
does the number of other apps visible in the double tap home button
bar affects the memory usage of the device?
No. The multi-tasking bar is just a history of recent apps. Some of them may still be in memory, others not. There is no way for you to know just by looking at it.
When low on memory, iOS will terminate the most memory-hungry background apps first. If your app allocates a lot of memory in a short period of time, it can happen that iOS isn't able to reclaim memory fast enough and will terminate your app immediately.
All you can do is reduce your footprint as much as possible, and try not to allocate huge buffers in one go.
Just a quick note. I found out that having other apps open does affect real memory allocation. Profiling the app with "activity monitor" lets you see which apps are currently loaded in memory and how much they use. Assuming the device has 512mb, you have 512 - (what's open) to use, and iOS may kill some apps to free up memory for your app.
Yes I think the number of opened apps affects the way your app
receives memory warning. Closing all the apps running in the
background or restarting the device can decrease the memory warning
messages sent to your app (you can see this effect by using instruments).
Advise:
When you receive memory warning try to do the following:
- Stop timers and other periodic tasks.
- Stop any running metadata queries.
- Do not initiate any new tasks.
- Pause movie playback (except when playing back over AirPlay).
- Enter into a pause state if your app is a game.
- Throttle back OpenGL ES frame rates.
- Suspend any dispatch queues or operation queues executing non-critical code. (You can continue processing network requests and other time-sensitive background tasks while inactive.)
I've been surprised that iOS 5.1 does not manage memory quite as I expected. When the device is running a lot of apps, it appears that iOS does not kill memory hogging apps in the background, but sends memory warning to my own app as well.
For example showing a UIImagePicker crashed the app on two test devices. Double tapping the home key and killing some of the background apps prevents the app from receiving the memory warning and crashing.
I'm wandering if iOS would not free up memory for me, is it acceptable to show some sort of alert view notifying the user that the memory is low and some of the background tasks have to be killed?
I'm at a loss of how to deal with such events - does it take time for iOS to clean up some memory (while apps respond to memory warnings)?
iOS does a lot of stuff before bothering you with memory warnings, including killing backgrounded Apps. Since iOS 5, iOS is even going to annoy you as less as possible with memory warnings, meaning that you only get one if there really is a need for you to get rid of stuff that is using memory but not needed right now (and that you can safely recreate in the future without taking hours for it). If your App crashes without giving you a memory warning first, chances are that you allocated so much memory that the system can't tell you that its running out of memory before it decides to kill you, the reason for this is that the memory warning is scheduled on the runloop of the main thread and until you give the runloop time to do another iteration, you won't receive the warning.
Also, Apple doesn't like you to tell the user that there is a memory problem; Its your App that has to deal with it, not the user! So its very very likewise that your App gets rejected if a memory warning comes up while the review team is reviewing your app (rumor says that they send these warnings to test how your App reacts to them)
Soo, to sum it up: iOS does work like you expected by killing what it can and even shutting down other system daemons, only after this happening you will be notified that memory is low. The correct way to respond to these warnings is to free up as much memory as you can, start with the big stuff that can be easily recreated in the future (eg. if your app shows loads of pictures but not all are visible at a time, throw away the ones that aren't visible right now). Telling the user is the wrong way to deal with the problem and Apple doesn't like it, so try to solve the problem on your end.
I have an iPad app that has a process for downloading lots of map files (a couple of gigs of data and 10s of thousands of files).
In my most recent test release, the device will sometimes reboot during the download process, (downloads can take a couple of hours).
When the app reboots, it does not leave a crash report. We have observed this behavior on both an iPad 1 and an iPad 2 running 4.3.3.
The only thing I can think of is we increased the max concurrent threads from 4 to 20 for doing these downloads.
Completely exhausting the system memory triggers a hard reboot of the device. This used to be more common in iPhone OS 2.0, running on the limited hardware of the initial iPhones and iPod touches. In recent OS versions, Apple has more rigidly enforced the hard kill of your application when it exceeds its memory ceiling, so it's become much harder to do this. Also, the devices have much more memory than they used to.
One way that you can sometimes do this is by loading many large textures or other graphical components that may not be immediately identified as memory used by your application. I've been able to cause a system reboot when loading a pile of data onto the GPU in a tight loop. You may be encountering something similar here.
I doubt that this is related to the number of active threads you have going, although they probably make it easier for you to dump a mess of data into memory before the system can kill your application.
As an aside, rather than having piles of threads, which consume resources, have you looked at using GCD or a queue-based framework like ASIHTTPRequest? These might be more efficient for your application, yet still provide the concurrency you need.
Your app is crashing most likely due to memory management. Since you are downloading several GB's of data, maybe you are running out of disk space? I am not sure why it would take your device several hours to reboot.
Try posting some code.
Have you debugged in Instruments? This will show you if allocations are rising and filling memory. If you are attempting to load these GBs into memory, then of course your going to experience a crash.
Also, have you looked at dispatch_apply instead of threads? GCD automatically distributes and increases/reduces the threads it uses based on load. This way you don't have to manage this yourself. It might be worth a shot.
I'm reading some people stating that if another (3rd party) app on someone's iPhone has been leaking memory, that this may reduce the (mystery) amount of RAM your app would otherwise have available.
This confuses me -- does not all app memory get released when the app is closed by the user? And only one app is open at a time on iPhone?
Normally, any memory that your application allocates will be freed when it exits. However, many of Apple's applications continue running after they're "closed", so memory leaks in Mail, for instance, can affect available memory.
In addition, there are apps out there that claim to free up allocated memory. They really don't do anything other than force some dirty pages out of the buffer cache, but they appear to do something, so people believe they must be doing something useful.
On a jailbroken phone - yes, third party apps can be running at the same time as yours. Running out of memory is common with people who like to have many apps running at once hence the need for task managers, killing tasks etc.
On an unhacked phone - no. Yours is the only non-apple app that is running, no others can run at the same time.
So what can you do? All you can do is try to use the minimum memory possible which you're probably already doing. Realistically you can only test with a factory, unhacked phone, unless you are going to spend hours trying to please everyone. If you think you are maybe using too much you could identify the larger allocations using the instruments tools ("Run with performance tool >" from within Xcode) and then post that chunk of code here to get ideas of how to reduce it.
You should run Instruments and then add the instrument "Memory Monitor" to see the memory use of all of the other processes on your phone. (Add with Window -> Library , then drag the Memory Monitor instrument to the instrument panel.
What I'm still trying to determine is why is iOS releasing memory from MY app, and not all of the other memory pig apps that are not currently running.
I'm developing a new application for the iphone.
I want to understand something - does the memory that my application uses shared with other applications?
What if an application causes memory leaks, does it effect the device performances after the user closes the application?
thanks.
At the moment, on iPhone you'll only be sharing memory with a certain few applications - MobilePhone, MobileMail, MobileMessaging, Safari, iPod and a few minor daemons.
If you're the active application and you need more memory than is free, then some of these applications (but not the most critical ones, like MobilePhone) will be terminated in order for you to continue. If you continue to use memory, you'll be terminated before the critical apps.
The amount of memory you can use depends on which device you're on and what else is going on on the device. Common advice is that as long as you stay under 30Mb, you'll be fine.
Once an application is terminated, the fact that it leaked memory (or not) is no longer an issue - the system will clean up and free it's entire address space.
Apps sometimes say that you should reboot your iPhone before running the app, clearing the RAM that critical daemons use for caching or whatever during normal use.
If you ever find yourself doing this, stop. If you ship an app with this requirement, you fail as a programmer and should be banned from programming. Why? Look up the amount of RAM a Playstation 2 has, then look at games like Gran Turismo and Grand Theft Auto.