5 ms·

True. However I should point out that cleanup and shutdown is pretty minimal: it's killed without warning. (I don't know if you even get a signal handler called

True. However I should point out that cleanup and shutdown is pretty minimal: it's killed without warning. (I don't know if you even get a signal handler called.) A hibernating app is not allowed to execute any code.

saurik 15y ago
This only happens when memory has become critical and not enough applications can free memory fast enough; initially, applications get a low-memory warning and they have an opportunity to deallocate things they are not using in the hope that the system will not have to kill processes. This includes things the developer may not even have explicitly coded, such as dumping video surfaces and sqlite caches. I'm willing to believe (as I have never specifically tested this) that suspended third-party from-the-App-Store ("User") applications are immediately killed without this first stage (although then it would seem weird that they participate in the cross-application memory warning system at all), but the default Apple-provided ("System") applications (such as Safari, Mail, etc.) definitely get this opportunity.
- masklinn 15y ago
  > I'm willing to believe (as I have never specifically tested this) that suspended third-party from-the-App-Store ("User") applications are immediately killed without this first stage (although then it would seem weird that they participate in the cross-application memory warning system at all) According to the iOS Application Programming Guide[0], > Suspended apps are not notified of termination but f your app is currently running in the background state (and not suspended), the system calls the applicationWillTerminate: method of your app delegate. (this is the iOS5 doc, but the iOS 4 version essentially said the same thing) So a suspended app is killed immediately, a running (backgrounded) app gets the standard applicationWillTerminate: message. [0] http://developer.apple.com/library/ios/#documentation/iPhone/Conceptual/iPhoneOSProgrammingGuide/ManagingYourApplicationsFlow/ManagingYourApplicationsFlow.html#//apple_ref/doc/uid/TP40007072-CH4-SW49 http://developer.apple.com/library/ios/#documentation/iPhone...
  - Someone 15y ago
    I guess the logic behind that decision is that unsuspending an app and allowing it to run arbitrary code while the system is in a low memory condition will take memory. Because of that, the likely effect of informing swapped-out processes that they will be killed is an avalanche of suspend/unsuspend events, resulting in an unresponsive sytem, similar to the effect of VM trashing.
    - masklinn 15y ago
      > I guess the logic behind that decision is that unsuspending an app and allowing it to run arbitrary code while the system is in a low memory condition will take memory. Even more so as a suspended application already got a message indicating that it was suspended, so it already had the opportunity to perform operations it needs to perform (mostly persisting state). > Because of that, the likely effect of informing swapped-out processes iOS does not swap, the VM only ever uses real memory, suspended processes live fully in real memory.
- andrewflnr 15y ago
  I know the Pandora app will sometimes delete playing history between times when I have it active. I have always assumed this was because of some memory early-warning system.
- saurik 15y ago
  I feel like part of the point of this comment went un-understood: my "I'm willing to believe" aside was meant to downplay the importance of user applications; the fact that system applications do not get randomly killed when suspended means that the low-memory notification system is actually much more expensive than "kill some processes" (which, honestly, is still quite expensive, given that the detection is done asynchronously in a different process and requires a bunch of context switches, page-table flushes, and zeroing in order to reclaim that memory).
phil 15y ago
You don't get a signal handler; there's no opportunity to execute code.

saurik 15y ago

This only happens when memory has become critical and not enough applications can free memory fast enough; initially, applications get a low-memory warning and they have an opportunity to deallocate things they are not using in the hope that the system will not have to kill processes. This includes things the developer may not even have explicitly coded, such as dumping video surfaces and sqlite caches. I'm willing to believe (as I have never specifically tested this) that suspended third-party from-the-App-Store ("User") applications are immediately killed without this first stage (although then it would seem weird that they participate in the cross-application memory warning system at all), but the default Apple-provided ("System") applications (such as Safari, Mail, etc.) definitely get this opportunity.

masklinn 15y ago
> I'm willing to believe (as I have never specifically tested this) that suspended third-party from-the-App-Store ("User") applications are immediately killed without this first stage (although then it would seem weird that they participate in the cross-application memory warning system at all) According to the iOS Application Programming Guide[0], > Suspended apps are not notified of termination but f your app is currently running in the background state (and not suspended), the system calls the applicationWillTerminate: method of your app delegate. (this is the iOS5 doc, but the iOS 4 version essentially said the same thing) So a suspended app is killed immediately, a running (backgrounded) app gets the standard applicationWillTerminate: message. [0] http://developer.apple.com/library/ios/#documentation/iPhone/Conceptual/iPhoneOSProgrammingGuide/ManagingYourApplicationsFlow/ManagingYourApplicationsFlow.html#//apple_ref/doc/uid/TP40007072-CH4-SW49 http://developer.apple.com/library/ios/#documentation/iPhone...
- Someone 15y ago
  I guess the logic behind that decision is that unsuspending an app and allowing it to run arbitrary code while the system is in a low memory condition will take memory. Because of that, the likely effect of informing swapped-out processes that they will be killed is an avalanche of suspend/unsuspend events, resulting in an unresponsive sytem, similar to the effect of VM trashing.
  - masklinn 15y ago
    > I guess the logic behind that decision is that unsuspending an app and allowing it to run arbitrary code while the system is in a low memory condition will take memory. Even more so as a suspended application already got a message indicating that it was suspended, so it already had the opportunity to perform operations it needs to perform (mostly persisting state). > Because of that, the likely effect of informing swapped-out processes iOS does not swap, the VM only ever uses real memory, suspended processes live fully in real memory.
andrewflnr 15y ago
I know the Pandora app will sometimes delete playing history between times when I have it active. I have always assumed this was because of some memory early-warning system.
saurik 15y ago
I feel like part of the point of this comment went un-understood: my "I'm willing to believe" aside was meant to downplay the importance of user applications; the fact that system applications do not get randomly killed when suspended means that the low-memory notification system is actually much more expensive than "kill some processes" (which, honestly, is still quite expensive, given that the detection is done asynchronously in a different process and requires a bunch of context switches, page-table flushes, and zeroing in order to reclaim that memory).

phil 15y ago

You don't get a signal handler; there's no opportunity to execute code.