Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
This explanation is purely from personal experience and logical thinking
I believe most of the third party apps that ‘suspend on exit’ take a screenshot and then save their state to the .app folder (not sure, it could be to the RAM but I doubt it). When you open up the app again, it shows the screenshot (the current status bar is shown but everything else is the screenshot) while it loads the app up to the point it was at before. When it is done loading, the screenshot goes away and you are left with the interface that you left with.

This technique has been used by some apps since before iOS4, but is not what is being referred to as fast task switching. With the new OS, the ability for a fast resume was added. This allows the app to actually stay in RAM in a suspended state in order to eliminate any delay when switching apps. Apps are automatically killed when resources are needed by the OS and could default back the method you describe.
 
This technique has been used by some apps since before iOS4, but is not what is being referred to as fast task switching. With the new OS, the ability for a fast resume was added. This allows the app to actually stay in RAM in a suspended state in order to eliminate any delay when switching apps. Apps are automatically killed when resources are needed by the OS and could default back the method you describe.

In addition - the iPhone 4 now has 512megs of RAM - making it easier to dedicate apps to memory in the background without "incident"
 
IDespite this, I was suggesting that bugs in either the OS or App could account for apps continuing to execute.
I wouldn't discount other user experiences just because they don't match yours. I have too many convincing accounts of abnormal power drain being "corrected" by killing apps for it to be entirely in peoples heads.

I have not seen anything I consider actual evidence. I'd like to see a proper trial, rather than anecdotes from non-developers.

I do think there are occasional rogue processes in iOS. But such rogues need a reboot to kill them.

I get the feeling that Jailbreaking might be behind some of these stories.

C.
 
This technique has been used by some apps since before iOS4, but is not what is being referred to as fast task switching. With the new OS, the ability for a fast resume was added. This allows the app to actually stay in RAM in a suspended state in order to eliminate any delay when switching apps. Apps are automatically killed when resources are needed by the OS and could default back the method you describe.

Alright, Ill edit my post for anybody that is reading through it and needs an explanation.



This explanation is purely from personal experience and logical thinking. If I were to design multitasking, this is exactly how I would map it out on a device like an iPhone.

When you exit an app with ‘suspend-on-exit’ functionality, the app saves it’s state to the RAM and waits to be reopened. When you open it up, it will load automatically as if it was running on CPU and RAM the whole time.

If an app needs more memory than is available, or if there are too many ‘running,’ iOS will take a screenshot of a running app and then save their state to a folder (most likely the apps .app folder). When you open up the app again, it shows the screenshot (the current status bar is shown but everything else is the screenshot) while it loads the app up to the point it was at before. When it is done loading, the screenshot goes away and you are left with the interface that you left with
 
Alright, Ill edit my post for anybody that is reading through it and needs an explanation.

Gotcha. Your essential describing a specialized page file. It was perfected ages ago on desktop OS's and probably had to be explicitly ripped out of the underlying memory manager for iOS. I'm not sure what is limiting Virtual Memory from being used on mobile platforms, but it's conspicuously missing from all handheld OS's.
 
Gotcha. Your essential describing a specialized page file. It was perfected ages ago on desktop OS's and probably had to be explicitly ripped out of the underlying memory manager for iOS. I'm not sure what is limiting Virtual Memory from being used on mobile platforms, but it's conspicuously missing from all handheld OS's.

I think you are misinterpreting what is happening.

As I understand it, paging is where "pages" of main memory are swapped out to a secondary file system - such as a disk drive - to present an illusion of more memory than the system actually has. The system tracks whether pages are in memory or on disk. And reloads data back into main memory if it is accessed.

This is not what is happening in iOS4. Nothing is being swapped out to flash memory. Apps and their data are simply being paused. They remain entirely resident in main memory. The amount of RAM is quite abundant. Sufficient for many apps and their data. If RAM does run low, the least-used apps are immediately terminated, and the memory occupied by the code and the data is freed up.

Virtual memory has no place on a mobile device. Because there's only negative consequences to treating a small memory like it is a large memory. Better to create software that fits within the constraints of the hardware.

C.
 
Man, some of you guys are anal.

If you want to only see what's running rather than a list of recently opened programs, you should jailbreak and install "remove recents."

My experience with "remove recents" is that is causes a battery drain. Is is consuming power just to keep the multitask clear?
 
I think you are misinterpreting what is happening.

As I understand it, paging is where "pages" of main memory are swapped out to a secondary file system - such as a disk drive - to present an illusion of more memory than the system actually has. The system tracks whether pages are in memory or on disk. And reloads data back into main memory if it is accessed.

This is not what is happening in iOS4. Nothing is being swapped out to flash memory. Apps and their data are simply being paused. They remain entirely resident in main memory. The amount of RAM is quite abundant. Sufficient for many apps and their data. If RAM does run low, the least-used apps are immediately terminated, and the memory occupied by the code and the data is freed up.

Virtual memory has no place on a mobile device. Because there's only negative consequences to treating a small memory like it is a large memory. Better to create software that fits within the constraints of the hardware.

C.
I wasn't describing iOS4's memory management, I was commenting on Corndog5595's description of what he felt iOS "should" do. I agree that conventional virtual memory paging would be bad. Page swapping is an intensive operation and should to be avoided for foreground operations; however, utilizing a Process Virtual Machine to provide each app a unique RAM address space does have benefits. Virtualization of the process space would add significant overhead, but could allow seamless application level hibernation, even between reboots. Imaging your phone appearing as if every app was suspended in the background, always returning were you left it. It maybe workable given the relatively small RAM footprint of most iPhone apps. FYI - this tech is already used in a limited capacity the desktop world.
I'm not suggesting that this should be implemented since it addressing a very minor circumstance that would be better handled today by the apps simply saving state and re-launching. Still I find the idea interesting as mobile hardware gets more powerful.
In any case, it's a bit off topic for this tread.
 
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.