Microsoft has been working on improving the power consumption of desktop apps for Windows 8 OS, to enable the all-day, always-connected scenarios.
Microsoft engineered the new application model to deliver consistently long battery life while enabling connected experiences. Applications that were designed for Windows 7 will continue to work as they have before with no change in behavior, and new Metro style apps can be developed to work in a more power-efficient manner, by taking advantage of the background infrastructure that the new operating system provides.
Windows 8 will enable a new smartphone-like power mode on system-on-a-chip (SOC) hardware, a mode Microsoft calls "Connected Standby." In Updating live tiles without draining the battery, Microsoft is enabling live tiles to give users fresh and current information without creating a lot of underlying activity that erodes battery life. In addition, Microsoft has been trying to minimize the power usage of running apps on Windows 8 PCs.
Applications can influence power consumption by consuming resources - CPU, disk, memory, and other resources - as each of those resources has a power cost associated. So the trick is to let applications utilize the resources they need while someone is actively actively using them, but reduce resource utilization to the bare minimum when the user is doing something else.
For Windows 8, Microsoft started off with a rule that would apply to the large majority of Metro style apps: if an app is not on screen, and the screen is not on, it should not impact the battery life. That doesn't mean WinRT and the user model preclude multi-tasking. When an app is not in the foreground, it would either suspend completely, or use limited resources based on a set of common background capabilities (like copying files), which the app can access.
For applications that run in the foreground, the existing application model needed to evolve in order to yield power savings. Of course, desktop currently available applications will work exactly like they do on Windows 7 today. But over time, Microsoft is equipping Windows to get more done and use less power.
In a foreground-based approach, concurrency becomes a big part of how to develop fast, fluid, and responsive apps. At the //build/ conference, Microsoft showed how to use the new tools and APIs to develop highly concurrent applications. This enables developers to think differently about how to code scenarios. So for example, rather than keeping a separate background app always running to do something even when it isn't needed (which wastes battery life), programmers can take advantage of the new OS background tasks infrastructure to complete the necessary activity in the background in a power-efficient manner. Background Tasks can be invoked in a number of ways, such as from a push notification, from a timed event, or even from incoming network data. The system is also smart enough to allow apps to run more often in the background when a PC is plugged into the wall.
On top of improvements to how app code can execute in the background, Microsoft has made many improvements in the tools infrastructure and WinRT API to make asynchronous programming easier and more powerful. Fast and responsive apps are built on a foundation of asynchronous programming. In a main session at the //build/ conference, Anders Hejlsberg showed off a WinRT approach to building an asynchronous user experience centered on viewing a huge catalog of items. Leveraging techniques like these will help deliver great scenarios and foreground performance for apps, and extend battery life.
Windows 8 will also suspended apps running on the background. After someone launches an app and then switch away from it, the operating system suspends it. This means that the Windows scheduler (the component that schedules CPU access for processes and threads) does not include it in the CPU scheduling. Since the operating system is not scheduling the app, the app is not using the CPU, and it is possible for the CPU to drop into lower power states. Getting the CPU into low power states can be critical to achieving better battery life. Suspended apps are in a similar kind of cached state. Since the app is already initialized, users get the benefit of instantaneous app switching.
The benefit of being able to suspend apps is that users get really fast switching between them without negatively impacting the battery life or performance of the system.
There are two cases, in general, where Microsoft won't suspend an app if it is not doing background activity. First, if users have not yet launched the app in their current logged-in session, then they'll have to tap the app's tile to launch it. The second case is more interesting. The system may remove an app from the suspended state and terminate the app if the system starts to run low on memory. If users have not used an app in a while and the operating system needs more memory, it terminates one of the suspended apps. This should happen relatively infrequently because the memory manager will take the suspended apps and save them to disk (which generally has more capacity than physical memory). When users switch back to these apps, they will be ready instantly.
Ideally the operating system is terminating as few suspended apps as possible, so users can switch back to suspended apps as often as possible.
"Even though an app may be terminated from the suspended state, there is really very little impact to your experience, because the app model has evolved to easily allow developers to save state incrementally while the app is being used, and restore it when the apps is re-launched," explains Sharif Farag and Ben Srour, lead program managers on Microsoft's Fundamentals and User Experience teams, respectively.
Microsoft underscored that even though there may be several suspended apps in the background taking up memory, there is no negative performance or battery life impact to a PC.
PCs are currently able to go into a "sleep" state, either on demand, or after a period of inactivity. During sleep, both desktop apps and Metro style apps will be fully suspended, saving battery power.
However, when the machine is asleep, it isn't getting live tile updates, downloading new mail, or getting ready to alert users with alarms or other notifications. So Microsoft enabled a new smartphone-like power state for a new class of PCs that rarely get turned off completely. Typically based on "System on Chip" (SoC) architectures, these PCs are interesting because instead of turning off during periods of inactivity they go into a very low power state while still running. This new state is referred to as "connected standby." This enables some great connected scenarios, such as always having email up-to-date, and being able to receive instant messages or phone calls, while still delivering long battery life.
To this end, Microsoft has added a new component to Windows 8 called the "Desktop Activity Moderator," which only runs on these new connected standby-capable platforms. This component is designed to help reduce the resource utilization of desktop apps when the device goes into connected standby. If Microsoft allowed apps to continue running unchecked in this low-power mode, the PC would run down the battery more quickly. Instead, Microsoft suspend desktop applications, stopping their resource use and maximizing battery life. From the applications' perspective, it will appear as if the PC has simply been put to sleep. When the PC is woken from connected standby, the app will resume as if the PC had been woken from a sleep state.
However, there are actually several components on the system that are required for connected standby, which Microsoft cannot suspend. These include drivers, some inbox and 3rd party services, and of course, the Metro style apps that use the background features. Microsoft enable these to run in connected standby after evaluation to ensure they do not have a significant impact on battery life. In addition, there are a set of processes that need to run in response to activity on the system. These processes are throttled to only run for short periods of time until a background activity is initiated, at which point they are allowed to run unimpeded.