(disclaimer: I've only used a cellphone and never made one.) I think the problem is much deeper than you'd think. Its very difficult to know the battery cost o

(disclaimer: I've only used a cellphone and never made one.) I think the problem is much deeper than you'd think. Its very difficult to know the battery cost of an action (some CPU ops take less power iirc), and also I'd imagine that certain execution patterns would be more efficient than others. For example, GPS fixes have some caching involved, so two applications with very similar GPS access patterns could possibly halve their power consumption by simply being scheduled back to back. Further, I'm not sure whether CPU is really the killer. CPU drain affects latency, which is bad, but for example keeping the radio running (data access), or keeping say accelerometer sensors on (perhaps the generate constant interrupts that interfere with the system's low power state.) I have an Android phone, and there is some screen that displays uptime statistics and also "time awake" which I think is an indicator for the proportion of the time the CPU is maxed, and even when I run top on my phone I have NO idea what it means or whats at fault. This is partly a tools problem and also partly a problem of some things being products of some particular interleaving. Another thought is that you have to be very careful about what you measure. Even in the desktop, lots of IO will probably show up as IO waits in your process, so latency is suffering even though the process itself is unrunnable (and worse, the blame would fall on the kernel's IO scheduler probably, thus hiding the blame further. And what if you want to write something but your system is already busy? Who's at fault, the other guys in the IO queue? What if all the apps in the queue are being nice and its just say a DB engine with raw disk access? Complicated complicated stuff.)