This is the kind of thing you bookmark: an excellent analysis (at least it seems so to me) by David Quintana, who compares how multitasking is implemented in Android and iPhone 4.0.
I have to confess I don't know who Quintana is: the link to his "mobile multitasking" post was provided by John Gruber on his DaringFireball blog. And it turns out to be pretty popular name when I googled it, so I've not yet tracked down his bona fides. (If anyone knows more about Quintana, please let me know via email or in comments.)
Having said that, his analysis is intriguing: partly because it's clearly, straightforwardly, simply written, there's a sense of a mind really interested in exploring how these two platforms actually implement multitasking, understanding how each works, and what the differences are and what those differences mean.
So, you can read the whole thing but he starts with Android: applications that are no longer visible to the user are suspended -- remaining in memory but without event handling or processing.
If this background app needs processing, it requires a "service" -- which Quintana likens to a kind of separate small application that runs without a user interface, doing stuff like completing a file upload on behalf of the suspended app.
iPhone 4.0 handles app suspension in a very similar manner. The difference lies in how iPhone handles background processing. This is much more bound or limited than in Android, according to Quintana. The iPhone OS doesn't have the same idea of "services." So "If an app merely needs to finish what it is doing before it is suspended, it asks for a limited amount of time to continue processing in the background. An example would be a file upload that needs to finish," he writes. As soon as that task is done, the OS suspends the app as usual.
But things get more complicated if the app needs to continue functioning while in background. If so,"it must either perform one of the permitted background tasks [background audio, VoIP, or background location] or be architected to use notifications.
Apple offers two kinds of notifications: Local Notifications or Apple's Push Notification Service. "Local Notifications are for time-specific alerts that would usually require the use of a timer, like an alarm clock or calendar alert. Instead, before the app is suspended, it schedules with the OS the alerts and times to notify the user. The OS then delivers those notifications while the app is suspended."
The Push Notification Service involves a server that generates time-based querying or polling, and then hands them off to Apple's hosted service, which then pushes the update or notice down to the iPhone client. The example he gives is for Twitter: instead of a Twitter app running on the iPhone checking the Twitter, the server application checks Twitter, finds updates, sends them to the Apple service, which then sends them to the iPhone.