What type of multitasking is in the newly announced iPhone OS 4?

I read the updates through gizmodo so that may have been tainted by their commentary, but my coworker said "Like Multifinder," which was the old classic Mac System multitasking service.

I'm not sure what the official name might be (Pausing? Delay? Suspend? Snapshot?) I like "carbonite" multitasking, though. It freezes until you need it again.

According to the iPhone OS documentation and what Apple used throughout the presentation today, it's simply called "multitasking."

My personal take is that it's more about being able to: 1) Quickly switch between apps 2) Background apps with the key use cases related to media consumption (e.g., audio), messaging (e.g., Skype or IM), and location (e.g., turn-by-turn navigation).

I ran across an interesting post examining the multitasking that's coming to the iPhone. This paragraph caught my eye:

"One difference between Android and iPad & iPhone is that Android does not kill applications on task switch. The iPad & iPhone will continue to do so. Thus, in some sense, Android has a third solution to application multitasking: We allow apps to actually multitask until the system experiences memory pressure, at which point our OOM killer is able to kill applications in least-recently-used order. Then, our serialization solution kicks in, making their reload transparent to the user."

Android has four kinds of components: Activity, Service, ContentProvider, and BroadcastReceiver. An app can have one or more types of components. If an Activity is visible or a Service is running, the task is not going to be killed unless memory is very low. This should not be a common occurance.

If an app does not have a Service component that is running, and none of the Activity components are visible, it can be killed and restarted from saved state. The Application Fundamentals article explains the Activity lifecycle. This is a common occurance.

From the descriptions here, it sounds like iPhone multitasking is more like a simplified form of Android's lifecycle for apps with Activity components, and that has some special cases that behave like Android Service components.

In Android parlance, a "background process" isn't visible, nor is it running a Service component. It can be killed to claw back resources. A "service process" is not visible, but it does have a Service component that has been started and can be running.

@macslocum: In the article referenced I found the speculation that memory consumption, rather than battery life, as the deciding factor to be of particular interest...

"Having a service API limits the ability of background applications to run errant and destroy battery, but that is not a primary concern. As I stated in my previous post, the real concern with multitasking on an embedded, swapless device is memory consumption. Battery life is a straw man."