The following is written to be semi-technical, but should be easy to follow, given that I’m a layperson myself. Some of the analogies will probably be poor or overly simplistic for developers or highly technical people, but should be pretty accurate in a general sense.
Something that’s been irking me lately - the misconception about how iOS backgrounding works. I’ve been hearing about people going through the app drawer (double click the home button) and killing tasks as a routine activity. There seem to be quite a few people that are convinced that this is helping performance of their device or saving battery or something. It’s probably not.
iOS backgrounding doesn’t work the way traditional multitasking does. On a desktop, when you multitask, everything stays running. If you open Safari, then switch to Chrome, the entirety of iTunes stays running, using processor cycles, battery, RAM, etc.
This is not true of iOS multitasking. iOS multitasking has seven distinct things that apps can do in the background, in order to preserve resources. iOS multitasking is designed with mobile concerns in mind - limited CPU, RAM, and battery. And perhaps most importantly, limited interaction from the user in order to work properly. iOS multitasking is designed to work without thinking about it. There are 7 developer APIs to enable multitasking features in iOS.
Background Audio
Background audio wasn’t really a new feature when iOS 4 debuted. It’s actually something that has been around since iPhone 1 with the iPod functionality. The new part of it was allowing developers to access it. Very basically, audio focused apps can continue streaming music in the background without devoting processor time to things that are unnecessary in it’s backgrounded state. It’s not going to keep updating album art and drawing the UI that you can’t see. It only devotes enough time to keep the music playing.
Voice Over IP
VOIP apps work somewhat similarly. Again, it’s not going to continue to use valuable resources to draw UI that isn’t used, or other unnecessary processes utilized by a foreground app. iOS 4 apps using the VOIP API will can continue to show themselves as “online” while in the background while using very little system resource. In addition, a lot of VOIP apps use another multitasking API (push notifications, get to that in a sec) to receive VOIP calls while in the background. Again, this method uses very little resource on the phone, and is actually active whether you kill Skype or other VOIP apps anyway.
Think of it kind of like putting the flag up on the mailbox. This tells the mailman you’ve got a letter, but it really only takes very little energy to get going, and next to nothing to maintain. It’s not as if you have to hold the flag up until the mailman arrives. In this case, it’s kind of like if the flag were to tell people that you are available for a VOIP call instead of having a letter to send.
Entirely anecdotal, but this is one of the few APIs that I’ve heard can be a battery drain, mostly because the app will continue putting that flag up every now and then, which either uses 3G or wifi. Different apps handle this differently, however, so not all VOIP apps offend. I’ve heard that Skype isn’t good for backgrounding because it can be a battery hog, and is one of the only apps I ever intentionally kill. However, I tend not to notice a real difference when I forget to close Skype manually, so I’m probably wasting my time, or it was a bug that was fixed a while ago.
Location Services
Location services only need to be monitored when they display the little location arrow in the notification bar. Location services use less resources in background mode, but still require power to the GPS, and sometimes 3G radio depending on the app. I wouldn’t monitor this any more than you did on iOS 3 or less. Most often when you arrive at the destination, or your location based reminder is complete, these apps will handle killing themselves.
Push Notifications
Push notifications are an alternative to the way a usual app that would require a notification would work. Push notifications allow an app to receive an update without keeping anything from the app alive. This becomes beneficial as more you install and use more apps that need update notifications. Rather than each app keeping a separate process alive to check for notifications, IOS instead keeps a single service alive to accept incoming notifications. The way I understand, it works a lot like a cell phone connection does. It doesn’t constantly update itself, just enough so the network knows which tower you are on.
Local Notifications
Much like push notifications, except they allow apps to notify on the device itself without an outside cloud service. I don’t believe there is anyway to kill the service itself, so killing apps that use it is largely pointless. It’s a bit like a smarter, more limited version of cron, and probably shares more than a few analogues to that. Rather than keeping a process per app alive, the app will simply tell iOS “Send a notification at 14:32, which is when the user wanted the alarm to go off.” The app schedules it, and then does little else. Local notifications can be used in conjunction with other backgrounding APIs, so this can be used to do something like “send the user a notification when the podcast completes it’s download.”
Task Completion
This allows apps that are put into the background continue to devote resources to something while in the background, for a limited time. This way while you don’t need to continue to focus on the Flickr app while an upload completes, or Instacast while a podcast downloads. Since iOS already limits the amount of time an app can continue to do things like this in the background, there is really no reason to manage it yourself aside from maybe limiting your data usage. Although, most data heavy apps that use task completion (like Audible) will limit their own data usage to wifi only, or have a setting allowing you to limit it.
Fast App Switching
This is by far the most used of the APIs, and probably the biggest reason why you do not need to manage multitasking. For this example, look at Alien Blue, a popular reddit client for iOS. In the past, you might browse around on Alien Blue, and find yourself 8 pages in viewing the comments for an article halfway through. You get a call, and when you open Alien Blue back up, you find yourself back on the front page, with all that progress lost.
With FAS, Alien Blue can quickly save it’s state to RAM, and exit. When you go back to the app, you find yourself in the same place and it appears as though the app was there the whole time. In reality, AB was paused in a very small state in RAM.
“But wait, I need all that RAM!” I can hear you say, and you are right. Some games or resource heavy apps will require that RAM. However, iOS is designed to automatically manage those apps that are in RAM. If you do open a resource heavy game, iOS will kill your least used apps to free resources until the required amount of RAM is free.
APIs will be abbreviated from the above, not every API used in each app will be listed, since I didn’t code the apps and they aren’t always obvious.
App: Alien Blue
APIs used: FAS
Effect of Killing Manually: Small amount of RAM is freed (which would have been freed if needed automatically anyway), app will open to Front Page on next run, losing your place. No gain in battery/performance
App: Instacast
APIs used: FAS. BA is used to continue playing podcasts in the background. TC is used to download podcasts while in background. PN is used to inform when new podcasts are available. LN are used to inform user when downloads complete.
Effect of Killing Manually: Audio stops, all downloads (if any) stop. Small battery saving if the app was downloading at it’s death, but only small since iOS will stop the download after a certain time on it’s own.
App: Think Message
APIs used: FAS, PN to deliver incoming text messages from Google Voice
Effect Of Killing Manually: Since PN runs without needing the App in memory, messages should continue to be delivered via PN, unless specifically turned off in settings. Small amount of RAM is freed (which would have been freed if needed automatically anyway). App reloads to default launch point at next run. No battery/performance gain.
App: Due
APis used: LN to deliver alarms at desired interval.
Effect of Killing Manually: LN will also continue to run unless specifically turned off for the app in settings. Small amount of RAM is freed (which would have been freed if needed automatically anyway). No battery/performance gain.
App: Apple stock apps (Mail, Safari, Phone, iPod, some others)
APIs used: Various, as well as undocumented APIs
Effect of Killing: Nothing, aside from an interruption if you were using the app at the time. Most of Apple’s apps will relaunch of their own accord.
First, apologies for butchering some of the explanation, which I’m sure are not entirely correct (although, are correct enough for the average person.) Some of the analogies are likely not perfect as I stated at the outset.
Second, iOS multitasking was designed from the beginning with two clear goals:
Personally, in my extensive use of iOS 4 and 5, I’ve found they’ve done a pretty good job. My only dig about iOS multitasking is that there are only 7 APIs, which means that some specific backgrounding functions are not possible. I personally almost never manually kill apps.
So Why Give Me the Damned Button to Kill Apps?
Basically, in case something misbehaves. In one version of Alien Blue, there was a bug that caused the app to effectively become stuck in a certain place (although, memory escapes as to exactly where). Without the option to kill that app from the task drawer, the only way to get it working again would be:
Some Real Performance Fixes, in no Particular Order
If you do feel like you are suffering performance problems, I recommend backing up everything, doing a full restore, and setting up as new. Keep in mind that you will have to manually add everything back to your apps, but this can be nearly completely alleviated by using the cloud. My books stay in the Kindle app, my contacts on Google, audiobooks in audible, music is all kept on my computer anyway, documents in Dropbox, etc. A full restore for me usually means a lot of entering credentials, and a long sync while apps that I use and music are transferred from my computer. If you use something like Spotify, it’s probably even shorter.
Other options would be to turn off unused services - turn off 3G when not needed, shut off location services, turn off push and only check for new manually, uncheck all Spotlight options. Most of these are only good for battery savings, but there may be a slight performance boost for some.
Using the various Reset options in Settings sometimes can improve cellular performance, and is a step in troubleshooting with most cellular carriers.
Controversial: Don’t jailbreak unless you know what you are doing. If you read through this and it wasn’t review, or you weren’t correcting my mistakes, you should be running vanilla, or the very minimal if you require a carrier unlock. While quite a lot of jailbreak apps and tweaks will not negatively impact battery or performance, just as many do and many don’t respect Apple’s rules for multitasking (which you might consider a feature in some cases). If you are on an older device or your phone isn’t behaving, go back to vanilla and see if you still have a problem. If you do require a carrier unlock, just jailbreak it, install the unlock and nothing else and see if you still have issues. Also note that some jailbreaks will occasionally break things (push notifications is a pretty common one) regardless of what tweaks you have installed.
Finally, take it to Apple. They can do some real diagnostic to discover if you have some sort of hardware problem.
For more, I’d suggest watching the iOS 4 Keynote from Apple. [iTunes Link]
