后台任务是指系统提供的可以在后台运行的进程，即使应用程序已经被挂起 或者不再运行了，但是属于该应用程序的后台任务还可以继续默默地执行相关的操作。它们通常在不打扰用户其它工作的时候默默的执行。这样的任务叫后台任务。与之对比，前台任务就是用户看得见的。

后台任务跟应用程序的关系，可以理解为后台任务是应用程序里面一个非常独立的组件，它并不是运行在应用程序的线程上的，它运行的线程是完全独立的，后台任务与前台任务的区别是：前台任务会占据整个屏幕，用户直接与其进行交互：而后台任务不能与用户交互是后台务依然可以对磁贴(Tile)，吐司通知(Toast)和锁屏(Lock Screen)进行更新和操作。因为前台要与用户交互，它使用所有可用的系统资源，包括CPU处理时间和网络资源等，并且不受限，而后台任务使用系统资源的时候是受限制的。

我们知道，Windows 应用程序的生命周期分为Running、Suspcnded、Terminated三种状态。应用程序处于前台时，为Runnmg状态；处于后台时，为Suspended状态，用户关闭应用程序时或者在Suspended状态太久，系统自动关闭应用程序时，为Terminated状态。那么，后台任务应该在应用程序的3种状态下运行，也就是说它对于应用程序的状态是完全独立，但是如果应用程序在Running状态下，应用程序是可以对后台任务进行操作的，比如关闭、汇报进度等，应用程序在前台运行的时候可以对后台任务进行控制。

虚线两边分别表示Application和System。Application就是我们的应用程序，System就是负责处理后台任务的Service。首先，在应用程序里面，我们要注册Trigger，也就是任务的触发器，相当于是在某个时机适当地触发后台任务的运行。其次，在应用程序中注册后台任务，在后台任务里面会实现相关的操作以及包含了什么样的Trigger可以触发这个后台任务，注册之后，在System Infrastructure(系统的基础服务)中就保留了这个注册信息。不论是关闭了应用程序还是重新启动了设备，这个注册信息都会存在，但是要注意如果应用程序被用户卸载了，那么该应用程序所对应的后台任务也不复存在了。再次，当合适的Trigger事件来临，System Infrastructure会搜索与这个Trigger相匹配的后台任务，然后启动该后台任务。

后台任务可以在应用程序处于挂起状态时运行。但是，如果应用程序己挂起，则它无法运行任何代码。那么，后台任务如何才能知道何时运行？当然，己挂起的应用程序不能启动后台任务。后台任务由操作系统运行。它们关联到一个用于通知任务运行的触发器， 此外，它们还可以关联到一组可选的条件。

例如，有一个名为UscrPresent的触发器。该触发器表示以下事件：用户登录到计算机， 或者休息(在短时间内计算机上没有用户活动)后返冋计算机。与该触发器结合使用， InternetAvailable条件表示后台任务将在用户在场并且Internet可用的情况下立即启动。如果用户返回计算机，但Internet不可用，那么后台任务不会启动。

当然，操作系统必须知道应用程序具有一个或多个后台任务，而且它还必须知道特定任务所绑定到的触发器和条件。由应用程序负责与操作系统协商有关其自己的后台任务的各种情景方案。如图1所示，整个过程分为以下几个步骤。

(1)包含后台任务的应用程序注册有关应该用于启动后台任务的触发器的详细信息. 在上述特定情况中，应用程序注册UserPresent触发器，这是一个系统事件触发器。

(2)该应用程序在系统基础结构中注册用于实现后台任务的类。在该阶段中，应用程序会传递在上一步中指定的有关触发器的详细信息。

(3)当事件触发时(在该示例中，为UscrPresent事件)，系统会通知后台任务基础架构。

(4)基础结构知道在发生特定事件时应该启动的所有后台类(由于有了之前的注册过程)，并通过实例化指定的后台任务类启动相应的任务。

每个后台任务都可以向其应用程序通报其任务进度和完成情况。当然.这些信息仅在应用程序正在运行时是有用的.而在应用被挂起和终止时是没有意义的，因此.通知机制是不可靠的，并且应用程序也不应该请求获取这些通知。下面将简要地介绍如何启用这些通知。在应用程序和其后台任务之间进行可靠数据传输的最佳方式是使用程序包数据设置或文件。如果应用程序和其后台任务都在运行，其中一方可以通过调用 ApplicationData的SignalDataChanged方法将其改变情况通知给另一方。

首先，应用程序必须获取后台任务的BackgroundTaskRegistration对象的引用。通过则用 BackgroundTaskBuilder的Register方法，或者调用 BackgroundTaskRegistration 类的静态AllTasks属性，就可以获取该引用。

一旦我们获取了BackgroundTaskRegistration对象，该对象公开的Progress事件和Completed事件就可以用于登记回调方法。注意，这些回调方法不是使用GUI线程调用的，因此，如果需要操纵用户交互界面的组件。我们必须调用CoreDispatcher的RunAsync方法。

在任务每次运行时，其Run方法都会被传入一个实现了IBackgroundTasklnstance接口的新对象：

该交互界面定义了一个UInt32 Progress属性。当后台任务对该属性进行设置时, Windows会在应用程序中引发Progress事件(如果该应用正在运行)，并将进度状态值传递给应用程序。应用程序的回调方法会接收到一个BackgroundTaskProgressEventArgs对象.该对象的只读Progress 属性会返回系统代码设置的任意值。

当任务的Run方法返回时，Windows会在应用程序中引发Completed事件（如果该应用正在运行应用程序的回调方法会接收到一个BackgroundTaskCompletedEventArgs对象.该对象程序包含一个 CheckResult方法。如果任务的Run方法抛出了一个未处理的异常，CheckResult方法将再次引发该异常，以便我们能够知道任务是否成功地完成。注意，该机制是十分不可靠的。仅当 任务的Run方法同步执行各项工作时，CheckResult方法才能正常运行。也就是说，Run方法不能是异步方法，也不能含有延时。然而，需要说明的是，同步执行Run方法是很好的途径，因为GUI线程不会执行这样的任务。事实上，同步执行各项工作甚至有可能是迫切需要的，因为这种方式可以减少内存开支并且改善性能，由于配额有限，这一点会是重要的考虑因素。

Completed事件和Progress事件的处理程序都将原始的注册任务作为一个BackgroundTaskRegistration 参数进行接收。这允许Completed事件和Progress事件对多个已注册的任务逬行区别，而这些任务都使用相同的Completed事件和Progress事件处理器方法。例如，应用程序可以注册维护触发器，也可以注册系统触发器。这两种触发器都可以使用相同的Completed事件处理程序。然而，两者的BackgroundTaskRegistration 对象的名称和任务ID是不同的。同样地，BackgroundTaskProgressEventArgs对象和BackgroundTaskCompletedEventArgs对象都具有InstanceId属性，应用程序可以借此对不同的任务实例进行区分，例如，当我们在短时间内接收到多个网络条件改变的信号时，就可能发生这种情况。

比如，一个文本编辑软件，帮助用户编辑文字的任务都是前台执行的。如果这个软件做得好，最好还有自动保存文件的功能，这样在系统突然崩溃之后，不至于所有用户做的改动都白费。自动保存这个功能一般都被作为后台任务，他在执行时，不打扰用户其它工作。