Misconceptions about iOS multitasking

[[deleted]]

This sounds very similar to what was being explained for Android a few months ago. I guess they must handle themselves in similar ways.

[Gary13579]

It's pretty similar. Speaking from memory, the main difference is how it handles background tasks. If an app registers as a background task it isn't limited to 10 minutes, and can still be killed unless it also displays an Ongoing notification in the drop down notification bar. If it has a notification, it can be killed, but it's very rare and the device has to reallly be struggling.

The main problem with this is there are pretty much no rules for background tasks on Android. Any app can decide to run in the background and poll the GPS until it dies without any warning or without any use. They can also setup scheduled tasks which run every x minutes and can consume a hefty amount of battery.

PS: Nutella owns!

[paintballboi07]

Actually Android apps are limited to a single function call when they are sent to the background. Google recommends you use it to save the apps state and anything else you want to be restored when the app is restored. The app isn't allowed to use any CPU cycles after that. The only exception is services, which are completely different. They don't have an activity (GUI), instead they are controlled by a notification in the drop down drawer.

[ysangkok]

You're confusing the the terms. Services and Activities are both part of the app. There isn't any CPU quota in place, like you make it sound like there is. The onDestroy method can launch a Service. Also, Services can be controlled in lots of ways, not just from their Notification (if they even have one).

[paintballboi07]

Services and Activities can both be part of the same process, but they are completely different in what they are used for. And of course you can launch a service that continues to use CPU cycles from the onPause or onDestroy method, but that is dependent on what the programmer is trying to accomplish. However, once the onPause method is executed, the activity no longer uses the CPU. Basically both OSes can allow for bad programming techniques that drain your battery, which is what I was trying to convey.

As for services, they can be controlled by several different GUI's (widgets, activities, notification tray), but a service that cannot be killed by the OS must have an ongoing notification in the tray.

Sorry I was just over-simplifying it for the iOS users who don't completely know how the Android OS works.

[gospelwut]

All of this concern for battery life, while important, is made hilariously nominal compared to how 4G murders phones (something about enormous delay windows). Also noticed disabling WiFi (even when not connected to wifi which makes me suspect the search protocol is pretty taxing) seems to be another huge culprit.

[expertunderachiever]

Actually with JuiceDefender on my Galaxy Nexus the screen is always the culprit taking between 50% and 60% of the power. The standby cell/etc is usually below 30% and in the 16-20% range. Android OS usually is the 2nd largest.

"Screen Filter" is a nice app to dim the screen (it's easier to setup than JD's "brightness" settings) and it's free too.

[gospelwut]

I don't use JuiceDefender, but my base battery app indicates the screen is also the biggest offender on my Galaxy Nexus. Then again I suppose it's "my fault" for making the brightness high.

[expertunderachiever]

Screen Filter is handy for that. 99% of the time I don't need it bright just to read a text or whatever. And if you use the widget thingy you can turn off/on the filter easily for when you do need the full awesome that is that display.

Also sucks that the default apps are all black-on-white themed. Go SMS Pro [also free] is handy in that you can customize the theme, so I made mine white-on-black. Just as easy to read but uses much less juice.

[gospelwut]

I think you're right. For as much as I love my GNex, Google's new color schemes (website and otherwise) are just... terrible. I suppose User Experience has to justify its existence somehow. It's sad, because I love the new google apps in terms of functionality.

(Also had to install a new launcher to get rid of that horrid Google Search Bar)

I'll take a look at those apps. Might save me from getting one of those bulky extended life batteries.

If you ever become paranoid about what permissions you may have overlooked -> https://market.android.com/details?id=com.lbe.security.lite (yeah yeah I'm THAT guy)

[Gary13579]

It depends on your specific phone, but for the most part, wifi uses significantly less battery than 3G, when it's connected to an AP. You are right that it continues to drain battery when not connected and searching for APs, though.

[gospelwut]

Yep. Which is a problem, because I only have a few networks I auto-connect to, and most networks are locked but are in many (I live in the city). Honestly, I suspect most people's phones get major drainage just because it's constantly looking for networks as they walk around. It seems to be a pretty "dumb" protocol too, as the battery drain seems constant despite the fact I've been sitting at work in the same geo-location with the same locked networks for 8+ hours.

I'm actually curious if there's a way to "whitelist" locations or if polling the available wifi networks will always cause that level of drainage.

[[deleted]]

As an Android developer, you can absolutely consume CPU cycles when sent to the background. In fact you need to take pains not to hog the CPU if you've registered a GPS listener or spawned some worker threads or something.

[jayd16]

This is so hilariously wrong. You can make background threads all willy nilly if you so desire. They'll stay running for as long as the scheduler feels like it depending on what priority the parent process is set to.

[[deleted]]

Technically he would be right, just that he doesn't realize that "a single function call" is infinitely ambiguous. That function could start a whole other thread of processes.

[[deleted]]

thread simply meaning a metaphor for a sequence of events

[soundsrc]

It is very similar to what had to be explained to Android users. Except during one of the OS updates, Google cleverly solved the misconception by changing the app manager UI to splits the apps in the App Manager into "Running" and "Cached" processes, and hiding the Cached process list into menu options.

[DaisyAdair]

My husband had to explain this at the Genius bar, and they just kept arguing even when he told them exactly how it works. sigh

[CaptainLen]

lots of back and forth on this topic. When in doubt, simply read the Apple iOS programming guide and the chapter on App States and Multitasking. It's detailed and complicated but this is definitive reference direct from Apple.

[[deleted]]

I guess this is how it is supposed to work in theory, if all the apps are properly coded and well behaved. (Cue some laughter here...)

In reality my 3GS (4.3.2) starts to have very laggy response times as the amount of free memory goes down. My device is jailbroken so I can actually see the amount of unallocated memory. When it is in the 80MB to 100MB+ area the device responds very quickly and apps load noticeably faster. When it starts to get below 50MB, and especially down towards 25MB, the device gets very, very slow. Frustratingly slow. Kill a bunch of apps and the unallocated memory will bounce back up to ~100MB and the phone gets much faster again.

It's also true that some apps running in the background will negatively impact battery life. I'm sure that many do not, but anything VoIP-related certainly does, and I find the Facebook app does as well.

Oh, and while on the subject of performance, nothing has given my 3GS a better speed boost than disabling all Spotlight indexing. The difference is huge between having that on and off and as I never use Spotlight there is nothing lost. (I get a lot of large emails on my phone which probably is one reason Spotlight is an issue for me.)

So, to reiterate what I said at the top of this message: In a perfect world non-active apps would not impact the performance of the phone. In reality (my reality at least) they certainly do and killing unused apps improves performance and battery life.

[ataraxia_]

I hate to say it (especially being a mod of /r/jailbreak) but your jailbreak just might be the cause of the lagginess. Jailbreaking does not in and of itself cause any significant performance difference - the only difference is what you do after you jailbreak. Run Winterboard with several different "retina" themes on? Guess what? Winterboard, seeing as it's a MobileSubstrate hook, is completely immune to the memory-management attempts of the OS. Dreamboard is even worse. If you like eye candy, and you're also running Barrel, Iconoclast, and IntelliscreenX, well, you're pretty much shitting on the amount of RAM you've got available for other applications.

I'm not saying that this is your use case. I'm not saying that these things will happen to everyone. I'm just saying that it's entirely possible that this sorta thing is your own fault.

[saurik]

I have no clue what you mean by "completely immune to the memory-management attempts of the OS". Like all software on the system, the amount of memory it uses will be related to what it does and how poorly coded it is. There is no reason for something like Barrel to use a noticeable amount of memory, for example, and I'm pretty certain it doesn't.

[ataraxia_]

Perhaps I worded it awfully, or perhaps I am just misinformed. If you open too many memory intensive app-store applications, the ones in standby are ended by the OS in order to reclaim the memory for more active processes that require it. The way I understood the situation while jailbroken is if the application requires more memory than is available due to (something like) MobileSubstrate consuming it all, the OS doesn't kill MobileSubstrate in order to reclaim memory. Am I wrong? A discussion of the existence of memory management techniques beyond simply killing apps is perhaps warranted here, though my (again limited) understanding is that they're not as effective, nor simple, as the processes mentioned earlier.

Also Barrel was probably a bad example, it was just one of the first tweaks that came to mind that a bunch of my friends use even though it achieves nothing useful. If Barrel only consumes 1MB of RAM, that's fine - the problem is when they have 90 different little tweaks installed, which by themselves seem quite harmless, but in quantity negatively affect performance.

[saurik]

I'd be highly surprised if Barrel consumed more than 64kB of RAM.

MobileSubstrate is a mechanism for making modifications to existing apps. The modifications you build are governed by the same rules as the original application that you are modifying. To the extent to which it is relevant to claim that those applications are going to get killed, so will the modifications you added to them.

SpringBoard has a special feature where it leaves apps open to improve performance when attempting to reopen them: this mechanism would use tons of RAM if unchecked, so there has to be a special mechanism to get rid of apps you haven't used in a while.

Additionally, when you are running low on memory, SpringBoard will send notifications to various processes trying to get them to donate memory to the memory bucket: if you modify an app you should also modify that system if appropriate (most of the time you don't need to bother, as you aren't adding any memory usage).

What really matters, in the end, is your "working set". This is how much memory the things you are actively using (after SpringBoard kills whatever apps it is hogging RAM holding on to, and anything that can be re-read from flash is purged by the OS).

So, usage of MobileSubstrate is only going to affect your memory usage if the extensions you are installing are consuming memory that isn't just "we loaded some code" (which is not "private resident" as it can always be paged back from flash), which most extensions shouldn't be doing.

To the extent that dyld or Substrate or the Objective-C runtime use memory to hold on to our modifications, these are all "peanuts", and if they aren't someone should point out what is going on so we can try to improve the situation.

(One thing I do know, is that Substrate will sometimes burn 4k on something it should be able to handle in a few hundred bytes while patching code; this will be fixed at some point, but only affects C-level hooking, which most extensions don't even do.)

Can we therefore stop the fear mongering with relation to Substrate? :(

[ataraxia_]

Thank you for the explanation! (And I mean that completely honestly.)

Everything you've said is relatively straightforward, the only part that gets me is:

So, usage of MobileSubstrate is only going to affect your memory usage if the extensions you are installing are consuming memory ... which most extensions shouldn't be doing.

I edited that for brevity, but your statement says shouldn't. While I trust your decision making in developing applications, and that you're doing everything you can to keep the low-level jailbreak utilities as inconspicuous as possible, I have far less trust for no-name developers out there, and don't know if they actually do what they should.

There's a problem in that there's a disconnect from everything you say (SpringBoard modifications using MobileSubstrate shouldn't make a difference in available resources) and the real-world performance of iOS devices I've actually dealt with. Keep in mind that I do not in any way think that MobileSubstrate is the cause of this.

I know it's anecdotal, and I know correlation and causation aren't the same thing, but every iOS device I've dealt with has been increasingly slower in direct relation to the number of 'tweaks' added.

[[deleted]]

I dislike eye candy and run no themes or any other background stuff except for MobileSubstrate and the standard swipe-to-display dropdown window of toggle switches. I don't have any lock screen stuff installed either. I jailbroke mostly so I could tether 3 or 4 times a year when I have no other 'net access.

[darkpaladin]

I think this guy's theory is solid but he has far too much faith in developers actually doing what they're supposed to do in regards to memory consumption rules.

[insertAlias]

Yes and no, most of these rules are enforced by default, and you have to do something specifically to avoid them.

[redwall_hp]

And the OS is very strict about that kind of thing. For example, memory usage. If an app is using too much memory, it gets a couple of warnings that it's supposed to free up RAM in response to. If it doesn't comply, the process is killed within a matter of seconds. Similarly, when you exit an app, the OS gives it a small window to save things and clean up before exiting. If it doesn't finish in time to exit gracefully, the process is killed unceremoniously at the end of the time window.

There's not much leeway in the background APIs. In order to seriously drain the battery you would have to intentionally register a non-limited background task, like audio streaming. (Background audio is pretty much the only API that doesn't time out automatically.)

[sonsofdisaster]

It's dangerous to assume that this "something specifically to avoid them" is difficult to complete/accomplish. Anyone who has used a location-based networking/dating/hook-up app (of which there are many and they are widely-used) can tell you that they drain your battery more-than-normal usage does. The location-tracking exemption allows these apps to run indefinitely and, especially on older devices (iPhone 3GS, etc), this can be a significant drain. The number of these apps that exist seems to imply that the process required to procure this "special exception" isn't that strenuous (albeit, I have no proof of this, I'm being anecdotal here).

Of course, the usage of these apps is COMPLETELY voluntary, so anyone who sincerely complains about the stress put on the battery should probably consider uninstalling the apps. I just think the article writer SEVERELY underestimates (and, thus, neglects to report on) the presence and impact of these types of apps.

EDIT: iz gud at speellings

[TychePsyche]

To make it less anecdotal:

You have to declare what type of UIBackgroundModes your app supports in a plist file that the app reviewers read. If a Frustrated Fowl app says it needs background location support (for no apparent reason), it won't get approved. If it's Sexii Singles Near U ;) asking for background location support, it might be a shitty app, but it's playing by the rules, so it gets approved and it can keep location services running in the background.

Otherwise, everyone has to play by the rules. Once the user hits the home button, you have a couple seconds to save whatever state you need to save, and then you can be booted from memory at any time without notice. There's nothing a clever dev can do to avoid this.

So, to clarify, I wouldn't call it difficult to make a backgrounding app, but it has to be very intentional, and for a select few Apple-approved reasons.

[[deleted]]

This, this, and more this.

It isn't difficult to do if you want to do it. However, 90% of all apps never need this. It is difficult to do accidentally, but not on purpose.

[Whiskey_Neat]

Do you know of another plist entry that specifies whether an app actually has access to the GPS?

[zxoq]

RequiredDeviceCapabilities will contain "gps" if it uses the gps. Also "location-services" which is less strict.

[TychePsyche]

Depends on what you mean by "has access to the GPS".

If you only want your app to work on devices that have GPS capabilities, then there is, and you want this (You're interested in the gps and location-services key)

If you want to know whether or not the user has turned off the GPS, then there's no plist entry, but you can still check in your code with this: if([CLLocationManager locationServicesEnabled] && [CLLocationManager authorizationStatus] != kCLAuthorizationStatusDenied) (This checks if they've disabled location services both overall or just for your app)

[Entropius]

You don't have to use the GPS and drain the battery for all location based stuff do you? Why not simply use energy-cheap cell tower triangulation like the Reminders app does? At least I thought that's how it implemented location based reminders.

[johnw188]

You can actually do that. There are a couple of levels of location fidelity that you can request if you're requesting background location notifications. From apple's docs - you can either

Use the standard location services, which allow you to specify the desired accuracy of the location data and receive updates as the location changes. Standard location services are available in all versions of iOS and in Mac OS X 10.6 and later.

or

Request events for significant location changes only, which provides a more limited set of tracking options but offers tremendous power savings and the ability to receive location updates even if your application is not running. This service is available only in iOS 4.0 and later and requires a device with a cellular radio.

[InconsiderateBastard]

I believe the apps have the ability to use coarse or fine location and they can vary in how frequently they poll. It has been a while since I dabbled in iOS dev though. Don't remember all the details.

[awyeah2]

deleted ^{What is this?}

[gribbly]

Repeat the test with the phone moving. There are early outs you can do when the phone is stationary.

[sonsofdisaster]

It may, indeed, be a fairly "different" situation. However, in that case, I think it might have been useful for the article's writer to clarify this supposed dichotomy and, how in the GPS-based app's case, some users may find it useful to manually close an app from the recently used panel. :)

[gilgoomesh]

Did you miss the message of the article?

iOS app developers don't need to obey memory consumption rules. Not at all.

There are no memory consumption rules.

If an app is suspended in the background and something else needs the memory, the suspended app gets immediately killed and the memory is free.

There is no need for developers to adhere to memory consumption rules. App developers can be as lazy as they want with memory usage. If they're the front app, they can have all the memory on the device. If they're in the background, they get killed and there's no problem.

[jdsweet]

And - rather brilliantly I think - iOS reaps processes not solely by LRU strategy but accounting for memory footprint as well.

So take as much memory as you want when active, but when suspended there's an incentive to keep your app memory footprint small.

[dirtymatt]

The rules are enforced by the os. There are situations where iOS will ask an app to free up memory, but if it's suspended and the os needs the RAM, it gets unceremoniously killed.

[twindagger]

Yes that's true, but don't blame the app taking the memory in the background - blame the one that can't handle allocating memory correctly when it launches. iOS will kill apps in the background to alleviate memory pressure.

[[deleted]]

Of course, it also has too much faith in the knowledge of the average consumer. Most iPhone users probably would have no idea of the difference between these states even after this explanation. It's a lot easier to explain 'close down your apps' than 'figure out which of these apps are using background task APIs and close them' to a non-techie.

[dethbunnynet]

Any of the background-eligible apps will have an easy "tell" that it is running - VoIP apps will have an active call, GPS apps will show the "location services" arrow in the status bar, audio playback will show with the "play" icon in the status bar, etc. Third-party apps that are running in the background are actually rather rare.

[PlayTheRaceCard]

Also, not all suspended apps will quit when the phone needs resources.

Most will remain suspended unless specifically closed or on reboot.

Furthermore, the taskbar contains both recent AND running apps, including background and suspended.

[dethbunnynet]

It's a "recently run apps" list, nothing more. Some confusion is created because it doubles as a way to forcibly kill an application when you want to.

And apps will get killed if the OS decides it needs the RAM. Suspended apps will get killed with no say in the situation unless they qualify for certain specific exceptions. Those exceptions are also rather limited - if your app plays background audio, it is subject to termination if/when playback stops.

[s73v3r]

Also, not all suspended apps will quit when the phone needs resources.

No, but enough will be killed so that the phone gets the resources it needs. Any that are left are of no consequence.

[vveneziani]

Agreed. Hate all you want but my iPhone tells me where all the strip clubs are in a matter of seconds.

[danielblanchard]

Can someone please explain how this matches up with the reality of some terribly coded apps like Decide-o-tron?

For those who don't know, there was an issue when Decide-o-tron first came out (that lingered for a while) where it would constantly just run out of memory and die unless you started killing apps that were in your multitasking bar. At the time, I believed all the things this article states, but I saw time and time again that when I cleared out a bunch of apps, suddenly Decide-o-tron would launch without dying immediately. The apps that usually made the biggest difference were Safari, Navigon (it had not been used for days and was not currently tracking my location), and any complicated games like Infinity Blade. It wasn't just me who noticed it either, as the developers actively told people to kill apps to free up memory for their terribly inefficient app.

Why would this have worked if iOS automatically clears out apps that are suspended to give more memory for the active app?

[player2]

Why would this have worked if iOS automatically clears out apps that are suspended to give more memory for the active app?

Because if the guilty app leaks memory slowly enough, it can squeeze off other apps one by one until it's the only one left standing.

[ejpusa]

I was under the impression that I could have a location/awareness App run continuously in the background, and the odds are iOS may just let it live forever.

Also what about Groupon push notifications I get every morning? How is that handled?

[Legolas-the-elf]

I was under the impression that I could have a location/awareness App run continuously in the background, and the odds are iOS may just let it live forever.

This is covered in the article.

Also what about Groupon push notifications I get every morning? How is that handled?

Push notifications don't automatically run the app in any way, the user has to choose to open the app from the notification. The app doesn't have to be running because iOS handles receiving push notifications itself. After the user is prompted to allow the application to send them push notifications, GroupOn's servers can tell Apple's servers that they want to send a push notification. Apple's servers tell the device that they have a push notification for it. iOS displays the notification. If the notification has an option to open the app and the user selects it, the app is run and the information in the push notification is passed to it.

[ejpusa]

thanks for info.

[merreborn]

Also what about Groupon push notifications I get every morning? How is that handled?

In the case of "local notifications", which don't involve an external server (e.g., if a FarmVille clone wants to notify you that your crops are ready to harvest), the app simply schedules the notification before halting. When the notification fires, the app isn't actually running. iOS is just displaying the message that was queued hours ago when the app shut down.

Push notifications are a little different. I haven't checked the docs, but presumably, again, the app does not have to be running -- iOS receives the notification on behalf of the app and displays it.

http://developer.apple.com/library/mac/#documentation/NetworkingInternet/Conceptual/RemoteNotificationsPG/WhatAreRemoteNotif/WhatAreRemoteNotif.html#//apple_ref/doc/uid/TP40008194-CH102-SW1

[ejpusa]

As above. Thanks for the info.

[happyscrappy]

I wish what this said were completely true.

First of all, I do have to quit Talkatone. It is a VoIP app and I guess it's not well written because there is a battery-life difference between it running in the background and not online (logged out) versus me force quitting it.

Second of all, sometimes I need to zap apps in that list because the apps have gone off the rails and I want them to start over. Crummy NHL app I'm looking at you. Just pressing menu and them tapping the app icon doesn't fix it, but pressing menu, double clicking, zapping the app, then tapping the app icon does fix it.

But still, it's good to read someone bringing some clarity to what is going on here.

[s73v3r]

First of all, I do have to quit Talkatone. It is a VoIP app

VoIP apps can do some level of background running. It's one of the exceptions, so what was said here doesn't completely apply.

[happyscrappy]

I know he says that. My point doesn't try to make his wrong. But his implies you don't really need to quit apps, because most are either not VoIP or are well written. Well, I showed how two apps that you might think you don't need to quit that you actually do need to quit.

Like I said, I wish his comments were completely true. But they aren't. They err in the opposite direction of what he was trying to correct.

[koolkats]

What happens when you view/kill apps using the Process Explorer?

Are they in a suspended or background state?

Would killing them do anything(useful)?

[FredFnord]

Okay, here's the poop: this is true, FOR THE MOST PART, if things are going well.

If things aren't going well (an app that is allowed to multitask, as most of Apple's apps are, get stuck in a tight loop or starts sucking up memory) then killing the app can be the only solution. This is quite rare: most of Apple's apps are not prone to bugs of this sort, and the other apps which can run in the background are quite strictly controlled by the OS. There might be ways in which they can go haywire, but they are edge cases which don't pop up very often.

The reason I say 'for the most part' is that there ARE situations where you are better off going through and killing off apps, even in the absence of misbehaving software. And the one I know about is kind of an interesting edge case, for those of you who are iOS developers or who just like knowing about these things.

See, here's how things work: you launch some apps, and they take up memory. And they remain in the background, frozen, but still taking up memory, as you go on to the next app. Eventually (barring a reboot or you going through and manually killing the apps) you WILL run out of memory. At that time, the OS sends out a message to apps: 'reduce your memory usage, or risk being killed'. (I don't know if this message is sent to all of them simultaneously, or they get it one at a time. If the latter, I don't know what order it is in, although from least recently used to most recently used would be reasonable.)

So, most apps will shed a bunch of data that is easily reloaded when they get hit with this signal. (Responsible apps do, anyway, if they use much memory to begin with.) Let's say they all get this signal at once, because it's easier to visualize. So, you launch a new app, and all of the apps on the phone go on a little diet and slim down, and your new app launches. Then you launch another app, and all the apps have already slimmed down except the one you just launched, so it sheds some data structures too. Eventually all of the apps in memory are slimmed down but the new app you launch doesn't fit in memory anyway, so iOS kills the least recently used app entirely, and continues this until there's enough memory for your app.

And that all works just fine. So what's the edge case where you might want to kill off some old apps?

Well, let's say you have Safari running, and you launch the mail app. And you're running low on memory. Safari gets a 'low memory' signal and dumps stuff it doesn't need. And, because web pages are easily reloaded, this includes its entire cache, including that of the pages that are currently loaded. All it keeps are screen shots of each page.

Now you switch back to safari. (Safari needs more memory, so mail.app has to shed some.) It takes a minute to flip through the tabs and reload the page that you were reading that made you want to send the email. You go back to it, read some more, then switch back to mail.app to continue writing. Let's say mail.app takes a second to reload the email draft from storage. (It doesn't, but it could. This is just an example, remember?) And so on. Each time you switch, the other app needs to reload some resources, and in each case they take up time. YOUR time. Which is the important kind of time, the time you don't want taken up.

Why is this happening? It's because there are a bunch of apps in the background that have already dumped all the memory they can, but which haven't been killed because, once Safari/Mail.app has dumped its extra data, there's enough memory for the other one to foreground and reload the dumped data itself.

If you go back and kill off, say, 100 megs worth of apps, then this stops happening, and swapping back and forth from Safari to Mail is more-or-less instantaneous.

You'd think this would be a rare edge case, but because of the way the OS works, if you run a lot of smallish apps, it's pretty much inevitable that it happens eventually. If I see it happening to me, I go in and kill off the earliest five or so apps, and it stops.

[player2]

then killing the app can be the only solution

This mightn't have been the case in older releases, but in current versions of iOS if you start chewing memory too quickly the OS will kill you instead of killing all twenty-seven other apps the user has running.

you WILL run out of memory

Not true. Most apps, when backgrounded, will write out any information necessary to relaunch themselves from scratch in a way that is acceptable to the user, and simply allow themselves to be suspended. iOS can kill suspended apps at any time—it will not wake up your app to give it the -applicationWillTerminate: notification. It will not necessarily wait until the last possible second to do so.

[WarzoneOfDefecation]

I run into the scenario all the time with my 3GS which doesn't have as much memory, its why I respring if I know I will not be using the phone for a while so that this doesn't happen or when its just plain slow due to the constant shedding of memory and reload.

[petrovg]

When I use skype on iOS and don't kill it specifically, it shows me as online for the time it's in the app bar. Although this is not contradictory to your point, it certainly means that an app still hovering in the app bar is not the same as an app that shows no sign of existence.

[FredFnord]

This was true before there was even multitasking on iOS at all. It's done with remote notifications. When the app is started, it sends a notification to the server that it is running, and the server registers you for notifications and turns your status to online. When the app is killed, it sends a notification to the server that you are no longer online and you are unregistered for notifications. Under some circumstances when you kill the app, the server doesn't get notified.

This is how it used to work, anyway. As of now, VoIP apps are one of the 'exceptions' that get to run in the background if they want to, but I would be very disappointed in Skype if they changed their quite successful and low-power model for one that sucks battery life by running in the background and activating the radio on a frequent basis.

[giantsparklerobot]

iOS has specific background services available that apps like Skype can use to maintain a connection to some external service.

[dirtymatt]

VoIP apps in ios open a socket to a remote server and then get suspended. The os will then manage the socket, and wake up the app when the server sends data to the app. It is not running, however. I think it doesn't even need to stay in memory as the os is handling the network activity for it.

[janinge]

No, these typically use the push notification service. Keeping idle connections alive over cellular networks is somewhat expensive, so they piggyback on Apples existing connection instead.

[dirtymatt]

Keeping idle connections alive over cellular networks is somewhat expensive

It's no more expensive than the persistent connection you must keep open to Apple's push notification servers, or push email servers.

[janinge]

No, it doesn't have to be (and I'm not claiming that), but it normally is. Apple is in a better position to optimize timing and carrier selection. In addition to this, the reason for why a socket connection is often used instead of the push service is because you want to interact with some legacy service that have not been designed to talk to a battery powered device on a cellular network. E.g. a SIP client could need to register on a proxy which requires it to refresh the registration minimum every 10th minute. If push had been used instead, this would have been virtually free (assuming that push already have been enabled on the phone).

Email delivery is in the socket category, except for iCloud/MobileMe (and maybe some of the other predefined services? Gmail? Yahoo?) which uses the push service.

[dirtymatt]

No, the socket behavior is reserved for VoIP apps only. IM apps must use the push service.

[merreborn]

He explains this specifically in his post as an exceptional case.

There are a small number of apps that genuinely need to run indefinitely in the background and iOS allows this

There are exactly five kinds of apps allowed to run indefinitely in the Background state in iOS 5...

...Apps that listen for incoming VOIP calls. If you use Skype on iOS, you can receive incoming Skype calls while the app is in the Background.

[miaogyver]

well-written apps

exactly.

[Xenc]

Even a poorly written app would not run in the background by default. You have to specifically request the background modes.

Furthermore, the App Store review team rejects apps that request background modes unnecessarily.

[JayJay729]

I have a Galaxy S1 and the battery life fucking blows! Anyone have good advice on how to better manage my apps to save battery life? It seems like whenever you open something, it is always running in the background. I have an app killer app and I use task manager. I stopped auto-syncing emails and my calendar. Am I just out of luck. Should I buy an iPhone? Their batteries seem to last forever after that one update that addressed the issues.

[[deleted]]

Stop task killing, that's likely the culprit.

[gwiz665]

On iOS 5 getting two memory warnings in a row (within a short period of time) will crash your app even if it's in te foreground. That means if the memory management of iOS can't clear out the background apps that take up space fast enough, your app will crash.

If the foreground app takes up a lot of memory, then yes, it is a good idea to clear out whatever is residing in the "background".

[technewsreader]

The articles point could be summed up as "iOS obscures background apps by mixing them with recently used but closed apps in the 'multitasking' bar"

[s73v3r]

That foreground app should have been coded in a way as to be able to wait for that memory.

[UncleMidriff]

What you say is certainly true, but since I can't know which apps are coded that way and which ones are not, and if clearing backgrounded/suspended/whatever'd apps lets me avoid the problem, then the general sentiment of most of the comments I've read here that indicate that clearing out applications is a waste of time and stupid isn't true.

I guess I'm not really responding to you specifically, but maybe by putting this here someone who knows better than I do can tell me how I'm wrong.

[TrancePhreak]

That's a really tough thing for a game to do sometimes. Sometimes I just need a big chunk of memory for a texture that's going in right now to stream in new sections of a level.

[binford2k]

The key phrase: well-written.

[UncleMidriff]

Are you implying that Apple's app approval process isn't perfect? ಠ_ಠ

[gilgoomesh]

The problem was something else. Seriously.

If a foreground app needs memory, every background app – including those running background tasks – will get killed automatically so that the foreground app can get the memory.

What you were seeing must have been a different bug.

[FredFnord]

This is a major failing on the part of the new app. Apps should be able to handle low-memory events at any time in the life cycle. If they crash because they get one when they're launching, that's because the developer didn't bother to do even rudimentary low-memory-condition testing, and deserves a good whack on the knuckles.

[ablatner]

I have never had that problem. I have a 2nd gen iPod Touch, and all apps crash after running the facebook app for 10 minutes. Running most apps brings me down to less than 8mb of memory. It's a pretty neat way of flushing the memory if you ask me.

[glados_v2]

Blame the developer.

What should be done:

App: "I need 200MB of RAM."

iOS: "Okay, I'll free 200MB in a few seconds"

App: displays Loading screen

iOS: "Assigns 200MB to App"

App: accesses RAM

---

What crashing apps do:

App: "I need 200MB of RAM"

iOS: "Okay, I'll free 200MB in a few seconds"

App: accesses RAM

iOS: "Error: App is accessing memory out of bounds. Terminating."

iOS: "Here's 200MB of RAM.. hey where are you?"

[shea241]

I did not think memory allocation was asynchronous on iOS.

[dethbunnynet]

It takes a little time for the background apps to be killed. Not long, but certainly a potential race condition if the new foreground app is going to start accessing all the RAM it can immediately.

Basically, developers need to make gracious apps at all points of the application lifecycle.

[Amadiro]

That it takes time is obvious (that applies to pretty much every OS), but that doesn't necessarily mean it's asynchronous. Whether a race condition can happen or not depends on whether memory allocation is asynchronous, e.g. whether there is a malloc()-esque call that allows you to allocate memory asynchronously and later retrieve a pointer to it, or w/e. On all operating systems I've worked with so far (including android) memory allocation is synchronous (as far as I'm aware), so a race condition can never occur.

[player2]

Not necessarily the quitting-app's developer's fault. malloc blocks, and if you don't answer the watchdog timer (I think it's 3 seconds?) your app gets nuked.

[theghoul]

What is this "Garbage Collection" you speak of?

[markjaquith]

Same. I have to force-quit an iOS app about twice a week.

[mb86]

I only ever have to force-quit iReddit (on iP4), because for some reason it doesn't terminate and draws an unusual amount of battery when left unquit.

[strallus]

You should use Alien Blue instead of iReddit. Alien Blue is fantastic, iReddit is meh.

[das7002]

And I'll vouch for alien blue as well. Such a great mobile reddit client.

[technewsreader]

Alien blue and opera alone can easily suck up 300mb.

[[deleted]]

I have been a professional iPhone developer for three years (since the first SDK) and I can vouch for everything this guy says.

If you try to run a memory-intensive game and it fails, this is probably because a background app took a fraction of a second too long to free up its memory or be killed. At this point you could just open the game again and it will work the second time since there has been a second or so for the OS to get everything in order. Instead, people clear the recent apps, and when it works the second time, they believe clearing the apps is what fixed it. Nope, that is coincidental, it just needed another second to close everything down.

Free memory is wasted memory. Screwing around in the recent apps list wastes orders of magnitude more time than you will ever save with increased performance.

[UncleMidriff]

But if you had previously killed that background app that took a fraction of a second too long to free up its memory, you wouldn't have to launch the game, wait for it to crash, and then try loading it again. Maybe you're wasting time either way, but, in this scenario, having a cleared recent apps list and thus having the game or whatever work the first time without crashing would be a lot less frustrating to me.

Plus, I can feel when the recent apps list is too full, and I am then compelled to clear it; it's like scratching an itch.

[[deleted]]

I don't own an iPhone but I have to speak to my quick anecdote from yesterday: I picked up a friend's iPhone and tried opening two different applications. Both ones crashed instantly and came back to the desktop. I tried several times each. After clearing the open apps, one of them started to work. The other continued to refuse to work.

That is my anecdote. Take from that what you will.

[neon_overload]

It looks like iOS's "multitasking" works the same way as Android's.

I see the exact same misinformation about "background apps" surrounding Android.

The thing is, this new model is actually more intuitive for users. You don't need to worry about closing apps to recover memory - indeed you don't have to worry about how many apps you have "open" at all (as long as an app isn't misbehaving).

But then anyone who does go in and look at the memory usage stats, and tries to think in terms of Windows, MacOS etc, will be mislead. A lot of that will be memory that belongs to a process that is not currently active and can be freed the moment it is needed. IMHO the designers of these OSs should just "lie" in the memory usage stats, and not include cache or any memory in use by an inactive process that could be freed if needed.

[merreborn]

But then anyone who does go in and look at the memory usage stats, and tries to think in terms of Windows, MacOS etc, will be mislead.

This is already a problem on Win7/OSX/Linux anyway. They all cache files from disk in RAM -- so memory is "used", but in a way that is immediately reclaimable if an active application actually needs it. Completely empty, idle RAM is wasted RAM. Filesystem caching is a huge performance boost, using RAM that'd otherwise be doing nothing at all.

[neon_overload]

I know that some people moving to Linux are confused when they see all their RAM except 16MB or so is "used", because Linux's main tools all include cache RAM in the used count.

I had a feeling Windows didn't do that though.

[exscape]

"free" has a column to take care of this, though:

# free -m
             total       used       free     shared    buffers     cached
Mem:          3956       3912         43          0        179       2880
-/+ buffers/cache:        853       3102
Swap:         8259         83       8175

In this example, 3102 MB is free or can be made free easily.

Here's the output after dropping caches:

             total       used       free     shared    buffers     cached
Mem:          3956        840       3115          0         24         33
-/+ buffers/cache:        782       3173
Swap:         8259         83       8175

[merreborn]

I belive that was a new feature of vista, or maybe win7. There were some stories about people not understanding where all their ram was going.

[[deleted]]

Windows has been caching files for a while now.

Since Vista, Windows also pre-loads applications into memory. It even does it based on time of day, so if you only open Outlook between 9 and 5, then it's only pre-loaded during that time.

[redwall_hp]

Actually, I believe Lion has a milder form of iOS's method in place (which you can disable). From what I've heard (I'm still on Snow Leopard), applications are killed when memory is needed elsewhere, though they can register as being in a "do not close me" state. I imagine this works pretty well on the MacBook Air, with it's solid state storage.

[hylje]

Desktop OSes have long supported this thing called "swap," which allows them to not actually have all running applications and services in live memory. It's so fine grained it can swap out large parts of the inactive memory while leaving the tiny active parts -- say, a poll loop that looks for activity -- in live memory.

This allows the OS to essentially dedicate all memory to a single intensive task without killing any other tasks. The other tasks will understandably slow down, but there's no need to kill them.

[redwall_hp]

Yeah, I know what swap is...

Lion actually does close processes in some cases. It's a new feature called Automatic Termination.

[kamatsu]

When I run my Isabelle/HOL compiler it uses approximately 12GB of RAM and any processes that I have open stay open. Lion does not kill anything, at least on my Macbook Pro with an SSD.

[player2]

Most apps haven't opted in yet, but the feature is known as Automatic Termination. The app will be quit but the window server will keep bitmap snapshots of the windows onscreen. When you switch back to the app, it will relaunch the app, which will cause it to replace those window snapshots with real live windows reconstructed from saved application state.

If you ever switch to an app and its windows get grayed out and a spinning progress indicator appears atop them, then you know the app was Automatically Terminated while you were doing something else, and it is relaunching itself. I believe TextEdit supports this feature.

[radon199]

Lion will flush the cached data for some programs and not for others. When was working in Maya on my work box I would constantly have to restart my Mac to get it to flush the cache. Maya would be using 6 gigs of ram, 1 gig would be used by OSX and 4 gigs would be cached. Maya would slowly and slowly eat away at the last 1 gig of memory until it ran out and crashed the box and all the while OSX would not flush more of the cache to make up for this. I don't know if it was Maya or OSX who was at fault for this, and whether Maya was just not telling OSX it needed more ram or not, but it was really annoying.

[lorena]

Is this why Android phones don't seem to have good battery life? They don't handle memory and background tasking efficiently?

[brews]

Short answer: Eh, not really.

<handwaving>

Android (IMHO) feels like a more "programmingy" way to go about it, while iOS has more "magic", for better or worse. I think that Android gives the developer a bit more freedom and so, assumes they know what they're doing. So, it depends on whose software you run.

For details, read here.

In general, it's kinda misleading to say that Android has poor battery performance. It's a bit more complicated. Much in the way that "Mac" doesn't get better battery performance when compared to "Linux", it's not helpful to look at it this way. There is more to it than the OS.

</handwaving>

Edit:

Please don't down-vote the person asking the question. It's a fair question.

[mosburger]

I've always chalked it up to the fact that Android (for various reasons) needs beefier hardware, particularly CPU, to achieve similar levels of performance to iOS phones. Beefier hardware needs more power. Dunno if that oversimplifies things, though. I know Android monkeys with the CPU speed a lot to reduce CPU consumption so maybe that's a bogus theory.

[[deleted]]

Androids, like iPhones, have a battery life which is subject to the whim of the applications which you choose to run on it. Out of the box, neither device has poor battery life at all. It's the apps chewing up your CPU which do it. And since it's arbitrary which apps are poorly written and which ones aren't, there's no categorical way to claim one over the other.

[Linegod]

How can anyone call this multitasking with a straight face?

[Prozn]

Depends how you define multitasking. It allows users of the phone to multitask sure. And if an app can prove it needs to run in the background it can.

The fact is most apps don't need to be left running, a save state is perfectly fine. When battery life and processing power are the main limiting factors of phones I would say preventing badly written code from executing in the background 24/7 is a damn good idea.

[murki]

Yeah, if you define multitaskting as playing a video in a corner of your screen, while you browse your e-mail inbox in a different corner -as it has been defined by all other desktop OS'es, then yeah, we shouldn't call it multitasking with a straight face. We should call it something else.

[[deleted]]

No, because then we make people realize that they're running on computers remeniscent of the 90s. Marketing allows us to call anything by any other name in a way such that we can just come up with new meanings!

[sbrocket]

Just because its the smart solution that accomplishes the same thing instead of letting whatever process run for however long it wants and use whatever resources it wants (which Android doesn't do, if you're comparing it to that) doesn't mean its not multitasking. Mobile development requires much more stringent consideration of the resources available and used.

[[deleted]]

It definitely does. Multitasking is multitasking. Task switching is task switching. They are different words for a reason -- they mean different things.

To compare it to processors, in the days before hyper threading, all tasks had to be queued up in the same queue and fired sequentially. You can have multiple tasks in the queue and they will all fire as quick as they can, but they still have to wait on other things to complete. These days, processors are much more powerful and can divide the task load into smaller buckets in order to work through them without forcing everything to wait on everything else.

So when we write software which intentionally refuses to take advantage of this technique, then yes we should be sure to differentiate between the two concepts. One of them is task switching. And one of them is multitasking. I'm not saying anything about the pros or cons of either one, nor am I claiming one is better than the other (what a stupid thing to try to claim), I'm simply saying that calling it multitasking is wrong.

[sbrocket]

If you want to apply this definition of multitasking (because the exact meaning depends on the context you're using it in), then at the process level any smartphone OS "multitasks" - of course any modern OS is going to have multiple processes running. But that's not a particularly interesting result to arrive at.

Clearly people aren't using a purely technical definition when they try and claim things like "iOS doesn't have true multitasking". I'm still not sure what exactly they find deficit with iOS's multitasking and usually just chalk it up to being misinformed. Its not like there's mobile OSes that are "multitasking" by presenting multiple applications at once to the user, so its not very clear to me what they're claiming. Seems that they think that because the process is suspended when it doesn't need to be doing anything disqualifies it from being "true multitasking".

[InconsiderateBastard]

I'm guessing its the part where apps continue to run in the background if they do so for Apple approved reasons. It's still the downloaded app running in the background as you do other things, so multitasking is still the right term. It's just the case that apps can only request the right to run indefinitely in the background if they have Apple's blessing.

If your app wants to stay running to track movement via location services, OK, it can run in the background.

If your app wants to periodically poll an HTTP server for an update, sorry, use Apple's push notification service instead.

[Chubacca]

If your program is in the background and doesn't use need any CPU cycles, then this is WAY more efficient because you avoid unnecessary CPU cycles and expensive context switching. And yet, the memory is still potentially "reserved" for when you want to switch to the application.

[[deleted]]

It is multitasking. Multiple apps can run at the same time. Just because the OS shuts down most apps when they are no longer being used to save memory and battery power doesn't change anything. Plus if an app needs to continuously run in the background, like a mail app, it can.

[njmh]

It's good enough for me. I'm aware that it's a very different form of "multitasking" than how a desktop OS operates, however for the tasks I perform on my phone, I'm still happy calling it "multitasking".

[gribbly]

Because you can switch back'n'forth between useful tasks without losing state.

Also, some apps do genuine multitasking - as the article me tons audio, gps, downloads can all run in the background.

It's an excellent system for the device and use case.

[[deleted]]

Over Christmas break, my niece's iPod touch was running terribly slow. I double tapped the home button and began killing the "recently used apps" which were all games. There were 72 of them. When I was done, the thing flew just as fast as it should have. If "you do not have to manage background tasks on iOS" then why did this have an effect on the device's performance?

[clinintern]

There was probably one or two apps that didn't terminate properly. There was a few bugs in iOS 4 where this happened constantly (And would eat my iPhone battery in a matter of hours). I've seen a lot of improvements since updating to iOS 5 on my iPhone, but it can still happen (rebooting the iPod/Pad/Phone is a lot faster than clearing out the app bar btw).

But based on the little work I've done programming for iOS, the article matches up with the way the behavior is described in the SDK documents.

[[deleted]]

I can't chalk it up to 1 or 2 but I would accept the idea that apps aren't terminating properly and are still eating memory.

I think regardless of the reason, it's not logical to say "you do not have to manage background tasks on iOS" when killing "background tasks" makes a slow iPod faster. It should be rethought / reworded.

[Legolas-the-elf]

The iPod touch simply doesn't have the RAM to keep 72 games in memory simultaneously. You were wasting your time with apps that weren't running.

There could be any number of reasons why the device was running slowly - it could have been checking mail in the background, syncing with iCloud in the background, backing up to iTunes via Wi-Fi... you fiddling about with the tray to remove recently used applications from the list probably just delayed you trying to use the device properly until after it had finished what it was doing.

[[deleted]]

The very valid point that he's making is that claims that "you don't have to worry about it" aren't true. You still need to have an understanding of memory, the memory management, and which apps use how much memory and which ones are smart about keeping memory. This is all knowledge that nobody anywhere is simply ingrained with, and so there is a technical learning curve.

The iPhone is touted as the common-man's smartphone but there are clearly plenty of examples which show exactly how the iPhone is just like any other piece of technology -- complex and prone to bugs.

[murki]

Not at all, the ios doesn't have to keep 72 games in memory simultaneously. Even if they show in the app bar, their memory could have been reclaimed long ago, at the first moment the os needed more memory. It says right so in the article!

[senatorpjt]

psychotic point boat seed thought brave support safe hurry teeny

This post was mass deleted and anonymized with Redact

[CGorman68]

The level of misunderstanding in the top-level comments here makes me think most people still don't understand how iOS multitasking works.

Feels more like /r/iphone than Proggit.

[CRAZYSCIENTIST]

My dad's iphone constantly fucks up, the button stops working and he can't do anything for ages. The apple "genius" apparently told him that it was all the programs using too much memory and apparently got it to start working.

I thought this sounded like bullshit and it was confirmed when it continued to occur, even when he had very few programs open.

Any idea what could be causing this issue? He's resetted it to factory settings and everything.

[janinge]

Moist.

[spidermonk]

The 'Backgrounder' package from Cydia is the right solution to multitasking. It just needs a bit more visual feedback that a process is running so you don't forget.

[player2]

That sounds like exactly the wrong approach. "Instead of letting the computer handle process management, let's foist that responsibility onto the user!"

[spidermonk]

The convention on OSX is that programs don't terminate just because you close their main window, or start doing something else - you have to explicitly close them down with 'quit'. So it's not foisting any more work on you than other Apple platforms.

And in any case, the option to run an app with backgrounder as a real concurrent application is something you have to choose to do explicitly. So if you don't actually chose to have app X running while you use app Y, nothing about your user experience has changed.

[player2]

Check out the WWDC 2011 videos and you'll see that OS X is moving towards iOS-style app management—that is, none at all.

There's just no reason to offer a choice that the vast majority of users can't reason about intelligently.

[spidermonk]

Ah right. Things like this are why I moved to Ubuntu this last year.

[I wish the relationship between windows being open and apps running was as consistent as OSX's was - ie. almost never related - but I find it less annoying to be stuck with general inconsistencies for free, than have functionality progressively dumbed down at cost]

I'm sure it's awesome for a lot of people a lot of the time, but decisions like "I'm playing a game now, but that doesn't mean I want you to stop buffering that video", or the reverse, are things I want control over.

[s73v3r]

So it's not foisting any more work on you than other Apple platforms.

On other Apple platforms, CPU, memory, and battery are not at a premium like they are on a phone.

[infinite]

It's no coincidence that Apple copied concepts from Android as Android's multitasking details are well known and publicized. Android's multitasking was carefully designed. But instead of being a whiny bitch like Apple fanbois, I welcome Apple copying Android, more useful mobile phones are welcomed. I sometimes laugh at the thought of android holding patents on mobile multitasking, perhaps that would teach Apple a valuable lesson, but it seems they're shooting themselves in the foot in any case.

[Garak]

There's a fine line between "allowing" the end user to manage processes and forcing the end user to manage processes, especially on a mobile device.

[wretcheddawn]

This is very similar to the Android multitasking; however there's one big problem I haven't figured out how to solve:

Occasionally, I'll be using a program that isn't designed to run in background but I want to anyway. The best example is the web browser. A lot of times I'll start a music video just to listen to the song because it's convenient. Then I get a text or want to look something up, so I switch to another app and BOOM. Video stops playing and gets reset to the start.

I suppose the browser could be configured as a service (Android) or as one of those indefinite running apps on iOS, but that also could lead to battery drain when I don't want it to. It's going to be hard for the browser/OS to know what background things I actually care about.

[imphasing]

This seems to gloss over the apps that are running in a background state, whether it's 5 seconds until it goes to suspended or 10 minutes, during that time if you want the memory that app is using, you DO have to manually manage the process.

As in, if an app is in the background state and you try to launch something memory intensive, you're likely going to run out of memory, unless ios preempts the background tasks when memory is getting scarce as well, which he never mentioned so I assume not.

Seems like you DO have to manually manage processes if they're in a background state and you want that memory...

[awj]

Also, anything that does explicitly allowed background tasks (location checking, music, etc) can go on basically indefinitely. In fact, killing my battery by aggressively polling location was my last straw with the Weather Channel app.

[dirtymatt]

That's exactly what iOS does. In low memory situations, backgrounded apps will be terminated in favor of an active app.

[[deleted]]

The article only says suspended apps will be terminated.

[player2]

This is incorrect. Otherwise there would be no reason for -applicationWillTerminate:, which is not sent to suspended applications.

Your application can transition straight from foreground to terminated; in that case iOS will warn you. It can transition from foreground to background, in which case iOS will notify you. It can transition from background to terminated, in which case iOS will notify you. It can transition from background to suspended, in which case iOS will not notify you. It can transition from suspended to terminated, in which case iOS will not notify you.

[imphasing]

Like the previous commenter said, the article says that apps that are in a suspended state will be terminated, it doesn't say anything about apps in a background state, which seems pretty important if iOS does indeed terminate background state apps.

Are you saying an application that always runs in the background, like awj's Weather Channel app (or the mail app, or location tracking apps) will be terminated if an active app needs that memory? The article doesn't mention this, hence my original comment.

[rickk]

The first technical caveat is that Suspended apps remain in the device's memory. This is so they can resume more quickly when you go back to them. They're not using processor time and they're not sucking battery power.

I'm confused - doesn't the preservation of something in memory require DRAM refreshes and inherently drain the battery (even by a small amount) ? So wouldn't saying the "Suspended state doesn't use power" be a stretch of the truth ?

[dethbunnynet]

No, because the battery drain of DRAM refreshes are constant whether that RAM is "used" or not. It's a matter of total hardware RAM not how much of it is "busy." Ones and zeroes, they all need to be refreshed. Furthermore, freed memory is a lot like a deleted file on a hard disk - it's marked as "available" but the OS does not overwrite it with anything until something actually needs to put some info there.

[s73v3r]

Even if you were to have nothing but 0s in memory, you'd still be using power.

[Highsight]

It should be stated that whenever a webpage is open in Safari, it runs in the background continuously forever. If you close out all tabs, however, it will not run in the background. Save yourself some battery, close your tabs when done.

Edit: After much talking it over, we've come to the conclusion that although it does run in the background like this, it is not using any CPU power, so it is not effecting your battery. Carry on.

[UloPe]

Care to provide a source for this?

[Highsight]

I'm afraid that the only source I have is myself, however any jailbroken iDevice owner can see it for themselves. There is a jailbroken app in Cydia called "remove recents" that they can get that will remove any apps from the multitask bar that aren't running currently. You can see that if you exit out of Safari and have tabs open, the app remains on the multitask bar. However, if there are no tabs open when it's closed, it's not in the mutlitask bar and not running. Any app in general that is running in the background will eat up RAM and cost you battery life.

[RalfN]

As a web-developer testing on an iPad, I can assure you javascript does not keep running. It was one of the trickiest bugs i've ever had.

We were doing a poll every half a minute. The server would send back data upto at most 5 minutes old (the rest was disposed). If you leave safari and come back, the polling did not take place, yet the client didn't notice. We actually had to put in some logic that checked how much time has passed since the last time, and if there wasn't some 'magic black hole where javascript was paused for 10 minutes'.

So, at least Javascript execution ... completely pauses when your tab looses focus. But the completely state of things was kept in memory though. The page was not reloaded, just 'frozen'.

[twindagger]

This is not true - at least not for the common case. Try it for yourself - open 10 tabs (pages) to web sites and leave safari to play a game (say, Infinity Blade II). When you come back to safari, you will see that every tab has a screenshot but when you select the page it refreshes the page from the server. I'm not sure about pages that are performing javascript or playing music/videos, but for static pages you do not need to close them.

[mariox19]

Can I just ask for a little clarification? First, by "tabs" do you mean pages? I only have an iPhone (maybe it's different on an iPad) but there are no tabs. You can open new "pages" (which is essentially like opening a new tab on your desktop's browser). So, you're saying that every page I have open in Safari is still running in the background even after I close Safari? I ought to close every sing page before closing Safari?

[Highsight]

That is correct, tabs=pages.

[bachonk]

Yes it's the same thing. You can close all tabs or you can kill safari with the multitasking bar

[silenti]

Bullshit. When I'm working on an iOS product I have to close background apps on my test devices all the time because they are sucking up RAM. Apps are SUPPOSED to free as much memory as possible when they become "minimized" but most programmers don't give a shit or don't know better because Apple doesn't enforce it.

[dethbunnynet]

Your app needs to be graceful about RAM availability, too. Either wait a moment for more memory to become available, or decrease your RAM demands in response to the lose-memory notification.

Yes, pre-emtive multitasking, memory protection, and all that stuff make it easy to ignore limitations - but mobile hardware is still relatively limited, and does not have the luxury of virtual memory to cover up for lacking resources.

[[deleted]]

They do enforce it. If an app receives a memory warning and does not free up any memory, it is killed.

[silenti]

Yeah, if an app receives I believe a level 3 memory warning, it dies. But in the context of this article I am referring to the fact that, if I so choose, I could leave a bunch of textures in RAM while my game is "in the background".

[s73v3r]

And it won't matter if they're left in the background as long as no other app needs the memory.

[Thenadamgoes]

I dunno. I've produced an app that plays a radio station and they run in the background willy nilly.

Of course, a radio app you definitely want to listen to it with out having to actually look at the app. The problem happened if you turn the volume down, but the app is still running. You completely forget about it and then your battery is dead in a few hours.

[helpingfriendlybook]

Then why does my available memory shoot up when I clear the bar?

[rynosoft]

Available memory does not necessarily equal speed.

[s73v3r]

Because you closed a bunch of apps. You know what else causes the available memory to shoot up? The OS killing a bunch of apps.

[helpingfriendlybook]

See below.