Intelligent Power
The main reason behind the Apple's decision to reject Adobe Flash was power consumption. It was bogging down CPUs, which in turn were drawing juice from batteries at a full rate. MacBook Air with Flash installed lives barely half the advertised time.
But it is not only Flash. There are many subsystems in a mobile device, contributing to the overall power consumption. The last weekend I went skiing with a group of friends. We had a lot of fun with the Map-To-Snow iPhone application. Unfortunately it was eating through the iPhone battery in about five hours. So at the end of the day we were unable to reclaim prizes, by simply being unable to present collected pins on the iPhone, because the battery was dead.
We need bigger batteries. But more than that, we need intelligent mobile operating systems, paying a lot of attention to state estimation, to manage hardware and applications.
State estimation is based on intelligent processing of data collected from various system sensors to manage power consumption of device subsystems. Take the GPS, which is a good example of a subsystem responsible for majority of power consumption in a mobile device. Therefore it should be turned of when not in use. Automatically. When and how? By gathering data from an accelerometer. If two subsequent positions gathered from GPS are equal, it means the device does not move. So turn the GPS off. Save juice. Now when the accelerometer goes active, turn the GPS on again. I know I am simplifying. But the general idea is there and it works. Whenever I stop, the GPS goes into power saving mode. When I start moving, it tracks my position. A good application should be able to do this.
But this really should be done at the operating system level. Applications should not care.
Different example? Heavy downloads or uploads. Like application updates. Almost every Wednesday, when I get on a commuter train, my Windows laptop starts downloading patch-Tuesday system updates over the GSM connection. Why? When I am on GSM, the OS should route only the priority traffic. Applications should advertise their classes of traffic, and OS should let them go on mains / WiFi and block unimportant packets on battery / GSM.
There are many more scenarios. The bottom line is the OS has the potential to extend the battery life. The problem (and opportunity) here is none on the market today is doing the job well enough.
Why the OS? Why not the hardware? The body of the problem seems to me to mainly exist in the design of the hardware anyway; and in the interaction between the hardware and low-level software secondly.
ReplyDeleteUsing just the examples above. The GPS hardware knows nothing about the accelerometer. The GSM modem cannot decide on its own what kind of traffic to pass through when you want to stay online but conserve your battery. This is the job of the OS. To estimate the state and manage the hardware components accordingly.
ReplyDelete