Power to the Developers part 1
In my recent Power to the People entry I talked about how bad it is for an application to burn CPU cycles when it's not actively being used. If you're writing an application that does a very simple animation that uses the CPU just 1% of the time, and you leave that animation going all night, every night, you'll cut the standby time on the phone to one tenth of what it should be. Users will have a 200 hour standby phone that will get only 20 hours with your app running. Don't do this.
In this entry I'm going to talk about easy things you can do to solve this problem. These methods are good for stand alone apps, but are probably not sufficient for home screen plugins. The task is a lot harder there. Later on, I'll do a part 2 that talks about what you can do in that case.
There are two main strategies for not beating up the user's battery.
Don't use the CPU unless you really need to
Say you're writing a falling blocks game. Obviously you need animations while the user is playing the game. And that's fine. While the game is being played, the backlight is on anyway, and it's burning more power than the CPU is anyway. But what about when the game is paused? You might be tempted to have a cute animation of a character tapping on the screen and telling the user to play more. But, is it really necessary? Consider carefully.
Maybe you think you should wake up every second, check something, and then go back to sleep. Think long and hard about this. Can you accomplish the same thing in a different way?
Say, you've got a text entry field. Do you really need a blinking cursor? (Yes, Some Microsoft Apps have one. Here's an opportunity for you to do better than us....)
Stop using the CPU as soon as you can
Okay, the reality is, there are a number of places where you do need to use the CPU. Maybe that animation is really important. You need to show more text than fits on the screen, so you scroll it. Or the pause animation is actually very important to the gameplay. Or the text entry just looks wrong without a blinking cursor. These things can be fine, if used in moderation. The problem isn't that you did a little animation for a minute. The problem arrives when you do it overnight while the user is asleep.
There are two very easy things you can do here.
1) Stop using the CPU when your app isn't in the foreground.
2) Stop using the CPU if the user hasn't interacted with your app for a little while
I've put together some sample code here to demonstrate these mechanisms. There are two functionally identical samples there, one native and one managed. The apps run on both PocketPC and Smartphone, and run on WM 2003, WM 2003SE, and WM 5. The solutions are built with Whidbey Beta 2, so if you've got an older version of our development tools, you probably won't be able to open the solutions. But you shouldn't have any trouble opening the code files themselves. Hopefully you'll find that the samples are simple and straightforward.
In part 2 I'll talk about a third thing you can do. You can be notified by Power Manager when the screen goes off and halt your animations and CPU burners then. But I wanted to separate that discussion from this one. Using Power Manager notifications is challenging and the above methods are really easy. I want to make sure that everyone does at least the easy stuff, so I'm calling it out first and separately.
Mike Calligaro
Comments
- Anonymous
August 05, 2005
You are placing too much responsibility on the developers. If I have 10 apps on my device, one of them is guaranteed to be misbehaving with possible severe impact on my battery life. I would have hoped a more advanced OS would protect me from lazy developers by taking proper care of power management.
Surur - Anonymous
August 05, 2005
The comment has been removed - Anonymous
August 05, 2005
Thank you for your response.
I take your point. I guess its similar to knowing whether a program is working very hard or in an infinite loop. I therefore prefer option 3:
----------------
One thing we can and should do is provide tools to users that let them know which of their apps are doing bad things to their power.
-----------------
If there was a Settings screen like the Memory screen, where CPU time usage and estimate of battery usage per app was listed, a user can make the value judgment of usefulness of an app vs battery life, and more easily pressure a developer to fix their product. If you have a number of apps on your device it might otherwise be very difficult to know which software is causing the problem. I assume something like that would not be difficult to code. Information is power after all, and I prefer being empowered vs being kept in the dark.
Surur - Anonymous
August 05, 2005
To first order, it's pretty easy yes. The OS has an API that gives CPU times to the caller. Of course, that only tells us about CPU times. It's harder to know if the app is sending data over the network or has forced the backlight on, etc. Those things burn more power than cpu cycles. But, yes, I think users knowing that this app is running when they don't expect it to be would be a big help.
I'm actually a system/driver dev, but I write little apps in my off time. And doing the above as a powertoy is on my list of things to do.
Mike Calligaro - Anonymous
August 05, 2005
Thank you. I will look forward to your powertoy. I think that solution is perfectly acceptable, as it would only take a few knowledgeable users to let the community as a whole know what software is poorly coded, and give feedback to developers.
Surur - Anonymous
August 10, 2005
In Power to the People we learned some of the differences between how PocketPCs and Smartphones handle... - Anonymous
August 11, 2005
In Power to the People we learned that it's very bad for your app to use the CPU unnecessarily. ... - Anonymous
August 12, 2005
In Power to the People we learned that it's very bad for your app to use the CPU unnecessarily. ... - Anonymous
August 15, 2005
The comment has been removed - Anonymous
March 19, 2007
Every so often, the comment spammers choose a blog entry and just pour comments into it. This entry has been getting around 5 comment spam a day for the last few months and we've been manually cleaning it up. I'm going to have to lock this thread. Yes, I know that the bots will just move on to another one, but we'll get a little bit of peace and quiet before they do. For real people, if you'd like to make a power comment, please use one of the other "Power to the ..." entries. Mike