Power Management: Designing Applications to Conserve Battery Life

by ContentMaster Ltd.


Introduction

Application developers accustomed to creating software for desktops and servers are typically not used to thinking about topics like power conservation and battery life. However, with the rise of wireless capability in the enterprise, these are topics that should be of increasing interest to application developers on all platforms. In this paper, we explain why developers should strive to create energy-efficient applications, and provide a brief overview of some of the technologies available for accomplishing this.

This paper is targeted primarily at application developers working on Windows*-powered mobile devices. The technologies described here can be applied in full, or in part to laptops, Tablet PCs, and PDAs powered by Windows 98, 98se, Millennium, XP, XP Tablet Edition*, CE*, and CE.NET*.

Definitions

    • Active state – a state in which an application is performing useful work.
    • Hibernate – a state in which a mobile device has written the contents of its desktop and open files to permanent storage before powering itself down.
    • Idle state – a state in which an application is not performing any useful work.
    • MFC – Microsoft Foundation Classes, the rich set of Win32 APIs which support application development on the Windows platform.
    • p/Invoke – a method for invoking native code from the .NET Common Language Runtime (CLR).
    • Power Scheme – one of several pre-set configurations within the Windows operating system that allow users to customize the behavior of their system under various power situations – for example, low batteries vs. full-power.
    • Resume – an event triggered when a mobile device returns from either Stand By or Hibernate mode.
    • Stand By – a state in which a mobile device begins shutting down hardware such as monitors, printers, and fixed storage in order to conserve limited power supplies.
    • Suspend – an event triggered when a mobile device enters into either Standby or Hibernate mode.

Background

The explosion of mobility has brought with it a set of opportunities and challenges which were previously unknown in the realm of software development. Intermittent network connectivity, diverse form factors, and sluggish performance are just a few of the many impediments to writing great "mobile-aware" software. The effect of a fourth impediment – limited battery life – can be lessened by application developers willing to devote the time needed to customize their applications for operation in settings where power may be an issue.

The Windows platform provides numerous techniques for extending the useful life of devices running on battery power. To fully leverage these techniques, it is vitally important that you first understand why as an application developer – this should be your concern at all. Once you understand this, you are ready to examine exactly what kinds of things you can do to create applications that conserve battery life.


Why every mobile developer should consider battery life

Most developers on desktops and servers are used to operating in environments with an ample supply of AC power to run their applications. However, many of these developers are likely to find themselves writing device-based applications in the near future.

On one hand, this is true because of recent technology trends. The number of mobile devices is increasing exponentially every year. Simultaneously, the prices of these devices are falling dramatically. Tablet PCs and notebook computers are being more widely deployed throughout the enterprise. Also, with the release of Microsoft's .NET Compact Framework*, the seven million developers for Visual Studio .NET* have become empowered to create mobile applications for Pocket PCs and other handheld devices running Windows CE .NET using exactly the same tools and skills they have previously leveraged on the desktop.

On the other hand, there are compelling reasons for creating mobile software that go far beyond mere numbers. Only mobile software can promise to bring customers access to their vital data and operations anytime, anywhere. However, this is a promise that cannot be kept if the devices intended to support it are constantly running out of the power that they need to operate!

Modern operating systems provide some mechanisms for dealing with limited battery life – leading some developers to think that they can disregard this issue altogether. However, the solutions that these operating systems provide by themselves are far too coarsely-grained to constitute a full solution for the problem of limited battery life. Instead, the APIs and events exposed by these operating systems – such as the Power Management APIs exposed by the Windows platform – should be leveraged by application developers to create "power-smart applications."

One thing that such an application might do is to listen for notifications from the operating system which indicate that a Suspension is about to take place or that a Resume has just taken place. Suspension is an action which may result in the loss of application data if not handled properly. A well-designed mobile application, therefore, should take care to persist its data and close open resources prior to a Suspension. It should then, upon Resume, take care of retrieving this data from storage and re-opening these resources.

Similarly, applications can take numerous measures to conserve power once they are notified that it may be running low. This has value to you, as an application developer, simply because it can extend the length of time during which people are able to use and benefit from your applications.


How to conserve battery life in Win32 applications

The Windows platform provides two main technologies for application development: Win32 and .NET. The Win32 technology represents a suite of APIs that work at a native level to directly interact with the operating system via direct invocations and function callbacks. .NET, on the other hand, is a virtualized execution environment that sits on top of the Win32 APIs and provides a "managed" environment for code execution.

All of the APIs that are important for battery conservation at the Win32 level are found in either the kernel32.lib or powrprof.lib libraries. Chief among these are:

    • GetSystemPowerStatus – a function which returns a data structure completely describing the current power status (AC or DC, levels, etc.) of a mobile device
    • GetActivePwrScheme – a function which returns the current power scheme being utilized by a device
    • EnumPwrSchemes – a function that returns a detailed list of power schemes defined on the current device.
    • SetExecutionState – using this function, an application can prevent the operating system from going into Suspend mode for as long as a stipulated operation is still being performed. For example, Suspend can be delayed until a given animation is finished being displayed.

For in-depth information on the functioning of these APIs, as well as their proper use, please consult the resources referenced at the end of this paper.

Supporting these APIs is an event-notification mechanism which can alert your applications to significant changes in the current power status of your device. These messages, such as the WM_POWERBROADCAST message, typically come in via the WndProc method on your Windows forms and controls.


How to conserve battery life under .NET

At one level, .NET simply provides a way in which to wrap these events and APIs to access them from an environment which is both safer and more reliable. For example, the GetSystemPowerStatus, GetActivePwrScheme, and SetExecutionState APIs can all be successfully called from .NET via the p/Invoke mechanism. Similarly, on the desktop, the WndProc method on Windows forms can be overridden to provide logic capable of responding to system power status changes.

Windows CE.NET has its own set of quirks and concerns as well. One of these quirks is that there is no WM_POWERBROADCAST message. In fact, the ability to query system power status is only available on devices where the optional Power Manager component has been installed by the device manufacturer. This means that - instead of listening for power management messages - you should periodically poll the system to find the current state of your device's battery.

Polling in general, though, is a bad idea on mobile devices. It will consume more CPU cycles than average and cause your battery power to be more quickly depleted. Instead, you should leverage asynchronous callbacks wherever your application logic allows.

Finally, whenever using the .NET Compact Framework (the version of .NET intended for use on Windows CE and CE.NET devices), you should always strive to suspend the performance of any resource-intensive tasks by applications that have been minimized to the background. Perhaps the best example of this would be .NET Timers. Whenever a .NET application is deactivated, Timers should be cancelled.


Conclusion

This paper explains why it is important that application developers take responsibility for the conservation of limited battery life on mobile devices. There are a number of tools and technologies that are available under the Windows platform to help you. Regardless of the method you choose, it is important to remember that even the greatest application in the world is useless without sufficient power to make it run.


References


Для получения подробной информации о возможностях оптимизации компилятора обратитесь к нашему Уведомлению об оптимизации.
Теги: