Wednesday, April 28, 2010

Micro Four Thirds

Wanting a lighter kit than the Canon 5D Mark II for my honeymoon, I recently jumped on the Micro Four Thirds bandwagon with a purchase of the Olympus E-PL1 and Panasonic 20mm pancake lens.

This crazy sunset is my first shot:

Sunset over Boston's Back Bay
Sunset over Boston's Back Bay

Shot in JPEG, not RAW, and oversharpened a bit, but the image quality is quite good. What's with the grey sky and bright red sunlight?

Thursday, April 8, 2010

iPhone OS 4 and Multitasking

What follows is a first-look at the just-announced multitasking features in the next iPhone OS. It is solely my opinion.

As I predicted in my previous post on the iPad & iPhone and multitasking, Apple is adding multitasking-like support to iPhone OS 4. And as I wildly speculated, that support is largely (although not completely) in the form of background services. Let's take an initial look.

First, as I wrote in my previous post, both the iPad and iPhone support multitasking today. At the system level, many processes run concurrently, and Apple-provided applications are allowed to multitask. What we are discussing here when we say "multitasking" is specifically the ability for third-party applications to multitask.

Second, this is a very early look at what Apple announced at today's event, which is still going on as I type this. Thus, cut me some slack. Developers should consult more detailed documents, which ought to crop up over the next few days and weeks.

What did Apple announce? A lot of spin, actually, but also two simple features. These features do not allow third-party applications to multitask. That is, on iPhone OS 4, as with now, only one applications runs at a time. What these new features do enable is functionality that fulfills many of the same use cases as multitasking. Let's look at them:

Services. Apple is adding a set of service APIs that allow background processes access to a subset of the device's functionality. Such services have access to, at least, notifications, geolocation, deferred computation, VoIP, and media playback. 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. So how do services solve the memory consumption problem? Alone, as described in the event, they don't. But iPhone OS will continue to kill applications that leave the foreground. Thus, applications will need to be refactored to provide a background component that only uses the new Service APIs. Without the risk of unbounded multitasking, memory pressure is greatly relieved.

Serialization. This was tacked onto the end of the discussion of the new services API, as if it was another service. But it is not. Described as "fast app switching" during the event, this is essentially a serialization API. When apps exit, they may choose to save their state to the backing store. When they restart, they reload this state. iPhone OS provides a simple object serializer today, called NSCoder. It is unclear if Apple is just pushing for better use of this class, or if they are adding additional APIs to make serialization both easier and more powerful. Either way, this will make it appear as if applications are actually multitasking—even though they are not—by allowing them to recover their exact state on restart.

So what about these solutions is "gonna be the best?" Nothing. In fact, what was announced is not even multitasking. Moreover, the new functionality isn't anything that other platforms don't offer today. Android, for example, provides excellent support for both of these features via Services and Bundles, respectively. The new iPhone APIs are not novel. But, despite the spin, that isn't what matters. All that matters is the user. If these APIs are sufficiently robust, they will benefit the user by enabling developers to make better apps.

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.

Saturday, April 3, 2010

Why the iPad and iPhone don’t Support Multitasking

Why don't the iPad and iPhone support multitasking? The answer isn't what you think.

There is a lot of misconception around support for multitasking in the iPhone and its giant cousin, the iPad. What follows is my analysis of the situation. I am not privy to any insider Apple information. Moreover, while my knowledge is certainly colored by my work on Android, I’m not drawing a comparison or using any Google-specific knowledge.

First, obviously the iPhone and the iPad do support multitasking. This is 2010 and both are built on modern, powerful operating systems that provide support for preemptive multitasking. Indeed, at the system level, there are many processes running concurrently. And some Apple-provided applications, such as the music player, clearly multitask.

So let’s redefine the complaint. What in actuality is not supported is the ability for third-party applications to multitask. That is, the system enforces a policy whereby once an application leaves the foreground, it terminates. In some ways, this makes sense. The iPad and iPhone user interfaces are single window, single document. Not allowing for background applications probably works out for a whole lot of use cases.

Apple says they do not support multitasking because it is a hamper to stability and a drain on battery life. That clearly isn’t true—the iPad has plenty of processing power and battery capacity. Rumor is that Apple is going to add multitasking in a future OS release. This rumor likely is true. Is Apple somehow going to make background applications not consume any battery? Of course not. These excuses are straw men.

The real reason that the iPad and iPhone do not allow third-party applications to multitask is likely more complex, more technical. Bear with me here. Both the iPad and iPhone, as mobile devices, have limited memory (256MB in the current incarnations) and no hard drive. No hard drive means no swap file. Limited memory and no swap imply that applications have a small, fixed amount of memory at their disposal. They don’t have the luxury of seemingly-infinite memory, as a modern system with swap has. Memory consumption is thus a critical system constraint. Like most systems, the iPad and iPhone deal with this by killing applications that use too much memory via a mechanism called the out of memory (OOM) killer. Unlike most systems, applications designed for the iPad and iPhone know how much memory they have at their disposal, and are designed to operate within those constraints. This is classic memory management in embedded programming. No swap, fixed memory, you deal.

What would happen if third-party applications could multitask? Some number of applications would be in the background. But each application was written presuming it had access to some fixed amount of memory. Thus, if the background applications consumed too much memory, the operating system would have to kill them. But the user would expect that he or she could switch back to an old application, and it would still be running where it was left. He or she certainly doesn’t expect applications to just die every time a new application is run, losing state and even data.

Simply put, the reason the iPad and iPhone do not support multitasking is because it is hard to allow multitasking in a system with no swap and a limited amount of memory. Apple could enable multitasking—indeed, there is no reason that the devices couldn’t support it right now, with a one or two line code change—but your applications would constantly be killed. That isn’t a very useful feature.

So how is Apple going to enable support for multitasking? Likely similar to how Android allows it. The Android platform was designed from the ground up for use on phones and other embedded devices. Consequently, we built in a mechanism whereby applications can save their state, including their current view, with the system. In fact, through this state saving mechanism, which we call Bundles, Android applications can operate as if they are stateless.

Thus, allowing for multitasking on Android is easy. Like the iPad and iPhone, we have a powerful, modern operating system (in Android’s case, based on the Linux kernel). Unlike the iPad and iPhone, we also have Bundles, which allow apps to save their state. Android’s OOM killer is aware of background applications and is capable of killing them in least-recently-used order. If the user switches back to an application that has been killed, the Android platform reloads the application’s state via Bundles. The whole process is seamless. Because Android has this state-saving framework, multitasking is feasible even on a device with limited memory and no swap.

In summary, the iPad and iPhone don’t support multitasking not because it would hurt battery life, but because it is hard to do so on a swapless, embedded device without platform support for serialization, which the devices lack. It is likely that Apple will add the requisite functionality in a future OS release. Until then, enjoy your giant iPhone. Or rock a Nexus One, which multitasks.

Update: Folks have asked me how a serialization system such as Bundles enable support for persistent applications, such as music players or IM clients. You wouldn't want these applications killed, even in low memory situations, and their state is ever changing so saving it isn't productive. There are many ways Apple can provide this support. On Android, we do so via Services. Most applications use the Bundle framework to save their state and are thus easily interruptible. Applications that provide a service to other applications, are a server, or function as a long-running background task use the Service framework. These applications are managed by the system more like Unix daemons and are not killed in least-recently-used order when memory is low.