Minimizing the power consumption of your PC while maximizing the responsiveness and utility (making it “fast and fluid&rdquoWe’ve featured several posts about how we’re working to improve battery life for Windows 8 PCs. In Pat Stemen’s Building a power-smart general-purpose Windows post, we discussed some of the investments that we are making in Windows 8 to enable a new smartphone-like power mode on system-on-a-chip (SOC) hardware, a mode we call Connected Standby. In Updating live tiles without draining your battery, we talked about how we’re enabling live tiles to give you fresh and current information without creating a lot of underlying activity that erodes battery life. In this post, we’ll expand on a few additional innovations that we didn’t cover previously, about how we‘ve minimized the power usage of running apps on Windows 8 PCs while still getting the most out of them., is a significant engineering challenge. While it starts with the work we do in Windows to provide support for the right level resource usage, this work requires developers to take resource utilization into account as they develop their apps. Power efficiency applies to all form factors and all usage scenarios—using less power is the right thing to do for everyone. This is an area of significant innovation for Windows 8 PCs, and builds on the foundation of the new runtime model in WinRT—it is not the sort of thing you can retrofit onto existing desktop applications while still maintaining functionality and compatibility. Much like state migration and setup that we talked about earlier, power consumption is an area of Windows that has been reimagined for new scenarios. With your existing x86-based PC, all of the existing support is still there, and all of the work you do on the desktop continues exactly as it has before (and of course, has been improved, as we have seen). As we see new hardware across all supported SoC hardware (including Intel) this level of power efficiency will be more broadly available. Though we will discuss some of the work we’ve done to improve the power consumption of desktop apps, to enable the all-day, always-connected scenarios we’re going to see new apps written to WinRT that run on a new generation of hardware that supports new power management capabilities.
Sharif Farag and Ben Srour, lead program managers on the Fundamentals and User Experience teams respectively, authored this post.
--Steven
As Pat mentioned in his post, 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 you’re actively using them, but reduce resource utilization to the bare minimum when you’re doing something else. This is true of course for the OS itself as well. Pat covered some of the work we did to improve this, but in fact, there were hundreds of small improvements made on this front—what we call “power hygiene” improvements to limit OS resource usage and activity. We were careful not to take this too far though, and undermine functionality that customers expect – like completing activities that they’ve started and then switched away from.
For example, in response to the live tiles post, @ItsMe asked:
“What about background copy jobs. If I put explorer application to background to look [at or] write a word document, do you mean the copy-job is paused until I "fullscreen" the copy-job again? Seriously?”The answer to that question is no, file copy will definitely continue to work exactly as it does today and will not get suspended if you start a copy job and then go do something else while it completes in the background. This works the same whether you are in front of the PC using it or leave the PC long enough for the screen saver or lock screen to kick in. Suspension of inactive apps only applies to Metro style apps, not to basic OS functions like copying files.
[h=3]Focus on the foreground[/h] For Windows 8, we 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 your battery life. That doesn’t mean WinRT and the user model preclude multi-tasking. There’s a new way of thinking about how and when code takes into account modern hardware capabilities, networking demands, form factors, and reliability/security/privacy. There are going to be some exceptions (e.g. background email syncing, desktop tools), but for the majority of cases, we expect the app to do most of its work while you are actively interacting with it. When an app is not in the foreground, we wanted to ensure that 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.
So basically, this means that an app can be in one of three possible states:
[h=5]Actively running in the foreground[/h] The foreground app actively running is pretty easy, as we just let it run and utilize CPU, disk, memory, and other resources as needed. In this way, Metro style apps are essentially the same as Windows applications have always been. This includes both the case where a single app is full screen, as well as when two apps are on screen with one of them ”snapped” to the side. This applies only when the screen is on, since it means the user is interacting with the PC.
- Actively running in the foreground
- Suspended in the background
- Performing some defined background activity
There are a lot of new factors to consider in developing fast and responsive apps. Much like the transition from character to GUI programming, where concepts were substantially different, building apps that are respectful of power and resource consumption requires some new approaches. As an example, early Windows programmers were sometimes frustrated by the notion of a WNDPROC and felt that the best way to handle typing was by trapping the interrupt and translating the key press—the message-based approach inverted this, and Windows handled the translation and let your app know when to worry about the key press, which was quite different from the earlier way of doing things. In a world where 75% or more of the PCs sold are battery powered, programmers are, by definition, being asked to rethink how to get work done again.
Given this, it is important to think about app development in a forward-looking manner that keeps pace with and plans for the evolution of hardware and customer needs. The existing application model needed to evolve in order to yield the power savings and battery life that customers want. Of course, as we keep saying, desktop applications that you currently have will work exactly like they do on Windows 7 today (and were even improved in many dimensions). But over time, we’re equipping Windows to get more done and use less power, with new applications that help you get that work done—from entertainment to professional tools and everything in between. The resources available to compute, the resources required, and the types of computation done are changing, and Windows 8 is providing new facilities to tap into this opportunity.
In a foreground-based approach, concurrency becomes a big part of how to develop fast, fluid, and responsive apps. At the //build/ conference, we 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 your PC is plugged into the wall. Overall, this is a big win for battery life because code will run only when it is needed instead of all the time. For example, your newsreader app can automatically download content for you in the middle of the night while your PC is plugged in, which allows you to have the freshest content available to you when you launch the app. And this in no way limits the ability to get the work done—it is a new way that gets the work done, and does so in a way that minimizes impact on critical system resources.
On top of improvements to how app code can execute in the background, we’ve 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 solid 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.
[h=5]Suspending apps in the background[/h] In the second state, after you launch 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. Developers may be familiar with this approach, as it is similar to what happens to a process when you are debugging an app and you “pause” it. Essentially, all of the threads running for the app are halted. Suspended apps are in a similar kind of cached state. Since the app is already initialized, you get the benefit of instantaneous app switching. It’s simply a matter of the operating system scheduler allowing the app execution to progress again when it is switched back into the foreground.
The great thing about this new suspended state for your apps is that they are instantly ready for you to get back to them. When you switch to a suspended app, it resumes instantaneously and takes you back to exactly where you left off. With this, you will be able to switch between more apps faster than you ever have before on Windows. You’ll no longer need to care how many apps are running on your PC—with the help of live tiles keeping you informed about what is going in your apps, and the ability for apps to save and restore state, great apps always look like they are running.
For example, let’s say that you have an app that keeps track of what flights you have coming up. This app can show you the status of your next flight through a live tile notification, even though the app may be suspended or not even running in the background. When you switch to this app, it can open to the last place you were in the app (such as flight search), as if you never left. Since the notion of what is running is abstracted, we have made launching an app and switching to an app essentially synonymous. Whether you switch to an app using the back stack, or Alt+Tab, or the Start screen, you can get back to a suspended app instantly.
In this way, the list of “running” programs is for all practical purposes the same as the list of programs you see on the Start screen. (For keyboard users, do keep in mind that Alt+Tab works across all running programs the same as it does in Windows 7, and the Taskbar also works exactly the same (and is even improved for multi-monitor scenarios) for desktop apps.
The benefit of being able to suspend apps is that you get really fast switching between them without negatively impacting the battery life or performance of your system. This is altogether different than traditional desktop apps, where we are all used to optimizing our workflow for those apps that take a long time to launch.
There are two cases, in general, where we won’t suspend an app if it is not doing background activity. First, if you have not yet launched the app in your current logged-in session, then you’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. Memory is a finite resource and we want the apps you are using most frequently to be ready for you instantly. If you have not used an app in a while and the operating system needs more memory, it terminates one of your suspended apps. This should happen relatively infrequently because the memory manager will take your suspended apps and save them to disk (which generally has more capacity than physical memory). When you switch back to these apps, they will be ready instantly. However, there will be cases where the system does have to terminate a suspended app. This typically occurs when there are multiple users logged into one PC, or when you are using a bunch of memory-intensive apps.
The operating system takes several things into account when it decides which apps to terminate, such as when the app was last used, and how much memory it is taking up. Ideally the operating system is terminating as few suspended apps as possible, so you 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. For example, the flight tracking app could remember that you were on the flight search page when you decided to move on to another app, and then use this information to bring you back there when you switch back to the app, even if it happens to have been terminated.
The important thing to underscore is 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 your PC. In fact, you do not need to manage or close apps directly at all. This is a common approach being used across computing devices now and represents a modern view of operating system design (see for example, this blog post about iOS multitasking by Frasier Spears).
Even though you do not need to close apps for improved performance or battery life, you will be able to close apps in the upcoming beta of Windows 8. Sometimes an app may get into a bad state or you are just done and don't want to see it again. You'll be able to use the mouse, a touch action, or a keyboard shortcut, to close an app. We'll have a follow up post that goes into some of the changes we are making here when the beta comes out, so stay tuned!
In the Developer Preview build, you can see the suspended state in action by opening up the new Task Manager after launching a couple of the apps that came with that build, such as the Stocks, News, or Weather app. Notice that the CPU utilization is listed as 0% because, even though those apps are in memory, they are essentially asleep, and cannot negatively impact battery life or performance.
Metro style apps get suspended in the background[h=5]Performing background activities[/h] As we’ve already discussed, developers need to think of how work that was previously done in the background can still be accomplished without impacting battery life. It is easy to ask for multitasking and just enable it, but the downside of this is that if all your apps are always running background tasks then you will never achieve long (or even improved) battery life. In a mobile and constantly connected world of laptops, this is incredibly important. So with Windows 8 and WinRT, we created new APIs to cover background processing for Metro style apps.
Again, your desktop apps will continue to run just as before, but they will also impact battery life just as they currently do (albeit with some improvements we will talk about below).
We set out to achieve a balance between enabling the kinds of rich app capability and multitasking that people expect in Windows, while also being conservative about resource utilization. To do this, we listed out a set of key scenarios we wanted to enable, and set out to achieve each of them in the most resource-efficient way possible. The result is a set of background multitasking APIs, which allow apps to complete an action in the background in a way that is resource- and power-efficient, and allow app developers to focus on what they want the app to do without having to do a bunch of extra work.
We took a scenario-focused approach to enable the most common tasks that apps would need to do in the background. Here is what we enable in the background for Metro style apps in WinRT:
This set of scenarios is based on common patterns used by developers and common patterns we expect to see. Some of these scenarios end up using the same platform affordance, so let’s walk through each of them, so you can understand the landscape and power of Windows 8:
- Playing music
- Downloading a file from or uploading it to a website
- Keeping live tiles alive with fresh content
- Printing
- Receiving a VoIP call
- Receiving an instant message
- Receiving an email
- Sharing content (like uploading photos to Facebook)
- Synchronizing content with a tethered device (like syncing photos)
[h=3]Connected standby and sleep-capable machines[/h] By the time Windows 8 is released, there will be a broader range of PCs available than ever before. Many of these will have similar power options to those running Windows 7 today. Besides turning off completely, they will be able to go into a “sleep” state, either on demand, or after a period of inactivity. During sleep, all system activity is completely suspended.
Application execution on PCs that are sleep-capable (default settings)The chart above shows how, as the PC idles just prior to sleep, desktop apps continue to run in the same way as they have in prior versions of Windows, while Metro style apps run in the managed way I described earlier. When the PC goes to sleep, both desktop apps and Metro style apps are fully suspended. This is great for battery life—when the machine is asleep, it consumes very little power. It’s not as great for a data-freshness though, since when the machine is asleep, it isn’t getting live tile updates, downloading new mail, or getting ready to alert you with alarms or other notifications.
As Pat covered in his post, we’ve 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 amazing battery life. The chart below shows behavior for both desktop and Metro style apps during connected standby. For this to really work effectively though, we had to consider both Metro style apps (which, as you saw earlier, we can very effectively ensure are conservative with system resources), as well as desktop applications, which presented a tougher challenge because they have been designed over the years to expect either full access to system resources (when running in the fore or background) or no access (when the PC is asleep.)
Application execution on PCs that have connected standbyTo this end, we have 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 we allowed apps to continue running unchecked in this low-power mode, the PC would run down the battery more quickly. Instead, we 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 we cannot suspend. These include drivers, some inbox and 3[SUP]rd[/SUP] party services, and of course, the Metro style apps that use the background features mentioned earlier. Many of these provide functionality such as responding to user input when you return to your device, or providing network functionality. We enable these to run in connected standby after careful 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. A great example of this is an antivirus product, which is often scanning in response to activity on the system. When there is background activity occurring such as receiving an incoming email via the background affordances, antivirus can run unimpeded during this time. But during the majority of the time when incoming network activity is not occurring, there is very minimal activity and therefore these components will be throttled to minimize their impact on battery life.
[h=3]Summary[/h] As you can see, we have made significant investments in engineering Windows 8 to be great for battery life. We 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 enable new connected experiences that work in a more power-efficient manner, by taking advantage of the background infrastructure that the operating system provides.
-- Sharif Farag and Ben Srour
More...
