Step 1: Tap the Start button.
Step 2: Sit back and bask in the glow of a phone that doesn't require you to manage apps running in the background.*
That's it.
*The only apps that can continue to run in the background are location tracking (e.g. Here Drive+), and background audio (e.g. Pandora).
So you're looking for more detail? Read on.
Application Lifecycle
Windows Phone uses an application life cycle that only allows one application to run at a time, and only if it is in the foreground, with the exception of the app types above. When you start an app, it becomes THE running app. If you back out of it, it is gone. If you tap the start button (or switch apps due to a toast, reminder, phone call, text message, etc.), the app is placed on the "back stack" and its state is "suspended." The back stack is the list of apps (up to 7) that you can get to by hitting the back button.
A suspended app is still in memory, but uses no CPU cycles. It is still in memory, but it has stopped doing anything at all. It is just there. If you hit the back button, it will be just as you left it. Depending on how the developer wrote the app, it may look like it kept running, but it didn't. One example that comes to mind is a timer. If you leave the app, and come back to it, it looks like time kept ticking. That's because the developer wrote it such that it tracked the time at which the app was suspended, and it looked at the system clock when reactivated and compensated for the time that it wasn't running. I've done this in one of my own apps.
If you keep going, starting another app and hitting the start button, the original app will move further down the back stack. The OS can take memory from apps in the back stack if needed by the foreground app, or for other reasons, and take that app out of memory. In this case, its state becomes "Tombstoned". If an app is tombstoned, you may see varying results when you go back into the app, because the developer has to actually program the app to accomodate being tombstoned. It may end up looking wrong going back to it, if the app wasn't developed with tombstoning in mind. I can't think of any cases off the top of my head where I've seen this, but I'm sure it's out there.
When an app is tombstoned, it calls a method - or a procedure - where it runs whatever steps the developer has defined for the tombstoning process. This would most likely be to save the data that was on the screen into the app's isolated storage (this is a whole different subject that I won't go into right now). The app can still be returned to from the back button, but it may take a couple seconds as it reloads the saved data, since it is no longer in memory.
If a different app is in the foreground, and there is enough memory use that the OS needs to take more, you can actually see an app removed from the back stack without it being bumped past the 7th.
Background Tasks
Background agents (or tasks) can be set up by the developer, and they can also be blocked by the user (from the Settings | Applications | Background Tasks). For this reason the developer should always write his app such that background agents enhance the user experience, but are not necessary for a good user experience.
Background agents come in a couple different varieties. There is the Periodic Task (which I would venture to guess is most common), and the Resource Intensive Agent. The periodic task typically runs approximately every 30 minutes, but can be scheduled to run with other system processes, so this time can drift by up to 10 minutes. The battery saver mode can disable periodic tasks as well, and so can the user (mentioned above). A periodic task is limited to 25 seconds, can consume no more than 11 MB (audio agents can consume 15 MB) of memory, they expire after 14 days (if you don't use an app for 14 days, its live background agents - which could be updating live tiles - will no longer run until you run the app again), and if the background agent has an error that causes it to fail two times consecutively, it will be disabled. Also, there is a limit to the number of background agents that can be enabled, and that limit varies by phone. Low-memory devices cannot have background agents.
Something to think about: Rarely, there can be instances where a background agent will have an excessively detrimental effect on battery life. I say rare, because most background agents run for a very short time, often less than a second, occasionally a few seconds, and rarely for the full 25 seconds that they are allowed. Since periodic tasks run every 30 +/- 10 minutes, theoretically you can have the agents running every 20 minutes. Three times an hour. That means that theoretically a task can use up to 30 minutes of processing time per day. Since you can have up to 15 background agents active (that's the most I've seen, but I've also seen the limit lower than that), assuming the worst case scenario, where you have 15 tasks that use 25 seconds of processing per execution, and the tasks run every 20 minutes, we're talking about up to 7.5 hours of processing time. Of course, this is the perfect storm of background tasks, and is highly unlikely, but given the constraints, it is theoretically possible.
Resource Intensive Agents are for doing things that require more resources, such as downloading podcasts or music in the background. Resource Intensive Agents can run for 10 minutes, but some conditions can cause them to terminate early. External power is required, as is a WiFi connection (or connection through a PC), and these agents will not run unless the battery is at least 90% charged and the screen is locked, and will not run during an active phone call. The external power and WiFi requirements can be bypassed by the developer, though I believe this requires specific (one-time) permission from the user in order to pass certification. In any case, there is a hard limit to the file size that can be transferred. While under cellular, that limit is 20 MB. On WiFi and without external power it is 100 MB, and to download more than 100 MB, external power is required.
Summary
I've put this together because I repeatedly see new users coming from other phones asking questions like "Is there a better way to exit an application?" The fact is that you don't need a better way with Windows Phone. The Windows Phone OS manages memory and battery life for you. You can do things like back out of all apps (if you're OCD like me), or you can just hit Start and let the app die in the background. Hopefully this post will help people to better understand not just that you don't need a task manager, but why you don't need one.
Sources:
App activation and deactivation for Windows Phone
Background agents for Windows Phone
Edit:
Applications Running Under Lockscreen
Another situation is that developers can set their apps to run under lockscreen. This means that if the lockscreen is on, or the phone is in the "standby" mode (screen off), the application can still run. This would be the case with such an app if you do NOT leave the app by using either the back button or pressing Start to get back to the start screen, before your phone either times out and shuts the screen off, or you turn the screen off with the power button. If I remember correctly, it used to be a requirement that the app notify you before doing this, but apparently either that requirement was dropped or I don't remember correctly. All I can find at the moment is this:
I had an instance where I was playing one of the Angry Birds games, my wife called me to do something, and a half an hour later when I turned my screen back on to continue playing, the phone was in battery saver mode, where it had more than 50% battery before I'd shut it off. Since then I don't trust the Rovio brand to not run under lock. Keep in mind that the only thing you have to do to avoid this problem is hit the start button.
Debugging Battery Life Problems:
While there is no way currently to tell what app(s) is using the most battery power, you can use Data Sense (if available) to help. Consider that most of the time if an app is using a lot of juice, it is probably also using a lot of data. This isn't always the case - an example would be a graphics intensive game that doesn't use data, or a video that isn't streaming - but for the most part, given the connectedness of our phones, if it's using a lot of power, it's probably using a lot of data. Use Data Sense to see how much data apps are using, and sometimes you'll find yourself wondering, "Why in the world does THIS app use so much data?" In the case of apps using a lot of data and you wouldn't expect them to, try blocking a background agent or not using the app, or even uninstalling it, and see if your battery life improves.
Edit:
Live Tiles
I've seen questions about tile updates, so I thought I'd add a little snippet about that here. There are three ways that a tile can be updated. First, and probably most common (though I'm guesstimating here), would be through a background agent, where the background agent runs every 30 +/- 10 minutes as explained above, maybe goes to the web and grabs some data, or maybe it generates its own data to update with, and updates a live tile. A background agent can also pop-up a toast notification in addition to other things it can do, too.
The second way is that the tile can be updated while the app is running. An example of this is say you have a tile that has a number on it, with notifications. You tap the tile to see what's new. When you back out of the app, the tile no longer has a number. The tile was updated while the app was running. It doesn't have to be a number of notifications that is updated - the app can change the tile image, text, whatever. Just as if it had been run by a background agent.
The third way is that a tile can get an update through push notifications. There doesn't have to be a scheduled agent running to receive this kind of update. The push server can send data to the app if it is registered with the server, and when the app receives that notification, it can update a tile, pop-up a toast notification, or even save data changes into the isolated storage of the app.
Step 2: Sit back and bask in the glow of a phone that doesn't require you to manage apps running in the background.*
That's it.
*The only apps that can continue to run in the background are location tracking (e.g. Here Drive+), and background audio (e.g. Pandora).
So you're looking for more detail? Read on.
Application Lifecycle
Windows Phone uses an application life cycle that only allows one application to run at a time, and only if it is in the foreground, with the exception of the app types above. When you start an app, it becomes THE running app. If you back out of it, it is gone. If you tap the start button (or switch apps due to a toast, reminder, phone call, text message, etc.), the app is placed on the "back stack" and its state is "suspended." The back stack is the list of apps (up to 7) that you can get to by hitting the back button.
A suspended app is still in memory, but uses no CPU cycles. It is still in memory, but it has stopped doing anything at all. It is just there. If you hit the back button, it will be just as you left it. Depending on how the developer wrote the app, it may look like it kept running, but it didn't. One example that comes to mind is a timer. If you leave the app, and come back to it, it looks like time kept ticking. That's because the developer wrote it such that it tracked the time at which the app was suspended, and it looked at the system clock when reactivated and compensated for the time that it wasn't running. I've done this in one of my own apps.
If you keep going, starting another app and hitting the start button, the original app will move further down the back stack. The OS can take memory from apps in the back stack if needed by the foreground app, or for other reasons, and take that app out of memory. In this case, its state becomes "Tombstoned". If an app is tombstoned, you may see varying results when you go back into the app, because the developer has to actually program the app to accomodate being tombstoned. It may end up looking wrong going back to it, if the app wasn't developed with tombstoning in mind. I can't think of any cases off the top of my head where I've seen this, but I'm sure it's out there.
When an app is tombstoned, it calls a method - or a procedure - where it runs whatever steps the developer has defined for the tombstoning process. This would most likely be to save the data that was on the screen into the app's isolated storage (this is a whole different subject that I won't go into right now). The app can still be returned to from the back button, but it may take a couple seconds as it reloads the saved data, since it is no longer in memory.
If a different app is in the foreground, and there is enough memory use that the OS needs to take more, you can actually see an app removed from the back stack without it being bumped past the 7th.
Background Tasks
Background agents (or tasks) can be set up by the developer, and they can also be blocked by the user (from the Settings | Applications | Background Tasks). For this reason the developer should always write his app such that background agents enhance the user experience, but are not necessary for a good user experience.
Background agents come in a couple different varieties. There is the Periodic Task (which I would venture to guess is most common), and the Resource Intensive Agent. The periodic task typically runs approximately every 30 minutes, but can be scheduled to run with other system processes, so this time can drift by up to 10 minutes. The battery saver mode can disable periodic tasks as well, and so can the user (mentioned above). A periodic task is limited to 25 seconds, can consume no more than 11 MB (audio agents can consume 15 MB) of memory, they expire after 14 days (if you don't use an app for 14 days, its live background agents - which could be updating live tiles - will no longer run until you run the app again), and if the background agent has an error that causes it to fail two times consecutively, it will be disabled. Also, there is a limit to the number of background agents that can be enabled, and that limit varies by phone. Low-memory devices cannot have background agents.
Something to think about: Rarely, there can be instances where a background agent will have an excessively detrimental effect on battery life. I say rare, because most background agents run for a very short time, often less than a second, occasionally a few seconds, and rarely for the full 25 seconds that they are allowed. Since periodic tasks run every 30 +/- 10 minutes, theoretically you can have the agents running every 20 minutes. Three times an hour. That means that theoretically a task can use up to 30 minutes of processing time per day. Since you can have up to 15 background agents active (that's the most I've seen, but I've also seen the limit lower than that), assuming the worst case scenario, where you have 15 tasks that use 25 seconds of processing per execution, and the tasks run every 20 minutes, we're talking about up to 7.5 hours of processing time. Of course, this is the perfect storm of background tasks, and is highly unlikely, but given the constraints, it is theoretically possible.
Resource Intensive Agents are for doing things that require more resources, such as downloading podcasts or music in the background. Resource Intensive Agents can run for 10 minutes, but some conditions can cause them to terminate early. External power is required, as is a WiFi connection (or connection through a PC), and these agents will not run unless the battery is at least 90% charged and the screen is locked, and will not run during an active phone call. The external power and WiFi requirements can be bypassed by the developer, though I believe this requires specific (one-time) permission from the user in order to pass certification. In any case, there is a hard limit to the file size that can be transferred. While under cellular, that limit is 20 MB. On WiFi and without external power it is 100 MB, and to download more than 100 MB, external power is required.
Summary
I've put this together because I repeatedly see new users coming from other phones asking questions like "Is there a better way to exit an application?" The fact is that you don't need a better way with Windows Phone. The Windows Phone OS manages memory and battery life for you. You can do things like back out of all apps (if you're OCD like me), or you can just hit Start and let the app die in the background. Hopefully this post will help people to better understand not just that you don't need a task manager, but why you don't need one.
Sources:
App activation and deactivation for Windows Phone
Background agents for Windows Phone
Edit:
Applications Running Under Lockscreen
Another situation is that developers can set their apps to run under lockscreen. This means that if the lockscreen is on, or the phone is in the "standby" mode (screen off), the application can still run. This would be the case with such an app if you do NOT leave the app by using either the back button or pressing Start to get back to the start screen, before your phone either times out and shuts the screen off, or you turn the screen off with the power button. If I remember correctly, it used to be a requirement that the app notify you before doing this, but apparently either that requirement was dropped or I don't remember correctly. All I can find at the moment is this:
- [Optional] To have a great user experience with user in control, you should prompt the user so they opt-in into running under lock.
- [Optional] You should expose as part of your application configuration settings an option for the user to change their mind or simply want to disable it and conserve power.
I had an instance where I was playing one of the Angry Birds games, my wife called me to do something, and a half an hour later when I turned my screen back on to continue playing, the phone was in battery saver mode, where it had more than 50% battery before I'd shut it off. Since then I don't trust the Rovio brand to not run under lock. Keep in mind that the only thing you have to do to avoid this problem is hit the start button.
Debugging Battery Life Problems:
While there is no way currently to tell what app(s) is using the most battery power, you can use Data Sense (if available) to help. Consider that most of the time if an app is using a lot of juice, it is probably also using a lot of data. This isn't always the case - an example would be a graphics intensive game that doesn't use data, or a video that isn't streaming - but for the most part, given the connectedness of our phones, if it's using a lot of power, it's probably using a lot of data. Use Data Sense to see how much data apps are using, and sometimes you'll find yourself wondering, "Why in the world does THIS app use so much data?" In the case of apps using a lot of data and you wouldn't expect them to, try blocking a background agent or not using the app, or even uninstalling it, and see if your battery life improves.
Edit:
Live Tiles
I've seen questions about tile updates, so I thought I'd add a little snippet about that here. There are three ways that a tile can be updated. First, and probably most common (though I'm guesstimating here), would be through a background agent, where the background agent runs every 30 +/- 10 minutes as explained above, maybe goes to the web and grabs some data, or maybe it generates its own data to update with, and updates a live tile. A background agent can also pop-up a toast notification in addition to other things it can do, too.
The second way is that the tile can be updated while the app is running. An example of this is say you have a tile that has a number on it, with notifications. You tap the tile to see what's new. When you back out of the app, the tile no longer has a number. The tile was updated while the app was running. It doesn't have to be a number of notifications that is updated - the app can change the tile image, text, whatever. Just as if it had been run by a background agent.
The third way is that a tile can get an update through push notifications. There doesn't have to be a scheduled agent running to receive this kind of update. The push server can send data to the app if it is registered with the server, and when the app receives that notification, it can update a tile, pop-up a toast notification, or even save data changes into the isolated storage of the app.
Last edited:
Facebook
Twitter
Instagram