Pocket PC Power Management Series 9: Battery Life Matters
====>SiteMap of this Blog<===
Pocket PC Power Management Series 9: Battery Life Matters
In my previous series, I talked about the reasons why Pocket PC's battery life is not that great in general. Part of the reason is the intrinsic design problems that we developers have to live with. This reminds me of what the VP in my company once talked to me regarding the battery life in Symbian devices.
Symbian OS runs in a much larger number of handheld units worldwide. Very possibly you, as the reader, is using a phone powered by Symbian OS. In general, the Symbian phones have considerably longer battery life than Pocket PCs (and smartphones). My VP once had a conversation with Symbian guys how they achieve the goal to save battery. His wonder is understandable, since Symbian OS is also numerous lines of human-made codes, so there is no magic. The answer from Symbian guys is that they have put battery-life as the top priority when the OS was designed. They make the kernel and shell very efficient in terms of CPU usage.
One can argue that Windows CE is much more powerful than Symbian OS, so a little more power-hungry is acceptable. Well, probably the argument is not to the point. Smartphone is also powered by Windows CE OS, but have better battery life than Pocket PC. Again, one can argue that smartphone does not have a touch screen, and its LCD is much smaller than that of Pocket PC, so smartphone's LCD consumes less power than Pocket PC. Well, probably the point is missed again. How do you explain the mysterious "\Software\Microsoft\Shell\LowMem" registry setting in Smartphone (which controls how the Shell killed user application at will)? Looks like in Pocket PC, Microsoft suspends itself and all user applications to save battery. In smartphones, Microsoft changed the strategy. It kills user applications to save battery!
Enough for the debate. Developers have to live with it anyway, and have to code prudently to not unnecessarily burn precious battery. How? Again I strongly recommend you to read the two excellent articles from Mike Calligaro:
Mike generalizes the following principles:
- Don't use the CPU unless you really need to
- Stop using the CPU as soon as you can
- Stop using the CPU when your app isn't in the foreground.
- Stop using the CPU if the user hasn't interacted with your app for a little while
- Stop using the CPU when your app isn't in the foreground.
Also Mike presents a great multi-threaded sample to catch any power state change reported by OS's Power Manager.
Still we may have to develop certain applications that need to run continuously (I called it case-1 programs), or applications that need to run periodically (I called it case-2 programs). See my Series 2 for the problem domain and Series 5 for details of case-1 and case-2. For such programs, Mike's principles still apply, but I'd like to add the following suggestions specific to our problem domain:- Prefer CeSetUserNotificationEx than SystemIdleTimerReset. The latter one I
called it a brutal way to force the device to run, and the former one a gentle way to request the device to run. You may not really need to run the program continuously. "Downgrade" to running periodically if possible. - Offer your user a choice to control the time period and frequency when the program runs. I bet the user will thank you for your extra work in putting a Control Panel Applet there!
- Make sure not to turn on the display unnecessarily even when your program has to run unattended. Some options of CeSetUserNotificationEx might turn on the LCD display, but probably only on some models. You need to diligently test the physical device.
- The ancient advice holds true: Make your code efficient. Avoid unnecessary loop. Cache your data if making sense. Do not write too computationally-intensive code. The list goes on and on. In general, if you come from Desktop Windows world and probably forget those algorithms taught in data structure classes, now probably is time to pick up again!
Category: [Power Management]