CN105677431A

CN105677431A - 将后台工作和前台工作解耦合

Info

Publication number: CN105677431A
Application number: CN201610097863.4A
Authority: CN
Inventors: J.A.小施瓦茨; A.U.基尚; R.K.涅夫斯; D.B.普罗伯特; H.普拉帕卡; A.F.格夫劳特
Original assignee: Microsoft Technology Licensing LLC
Current assignee: Microsoft Technology Licensing LLC
Priority date: 2011-09-01
Filing date: 2012-09-03
Publication date: 2016-06-15
Anticipated expiration: 2032-09-03
Also published as: CN102866903A; US9361136B2; EP2751676A1; EP3660666A1; EP2751676A4; US10628238B2; US20150301835A1; CN102866903B; US9032413B2; US20170031734A1; CN105677431B; WO2013032502A1; US20130061249A1

Abstract

用于分开地加载和管理应用的前台工作和后台工作的系统、方法和装置。在一些实施例中，提供一种方法用于由在至少一个计算机上执行的操作系统使用。操作系统可以识别应用的至少一个前台组件和至少一个后台组件，并且可以与至少一个后台组件分开地加载至少一个前台组件用于执行。例如，操作系统可以执行至少一个前台组件，而不执行至少一个后台组件。在一些其它实施例中，操作系统可以使用与该应用相关联的规范来识别实现该至少一个后台组件的至少一个计算机可执行代码块。

Description

将后台工作和前台工作解耦合

背景技术

传统的操作系统实现少许不同的执行模型来管理应用的前台工作和后台工作。可被看作前台工作的处理任务的示例包括但不限于呈现图形用户界面、响应用户输入以及与用户交互有关的任何其它类型的工作。可被看作后台工作的处理任务的示例包括但不限于下载和安装软件更新、与服务器同步以及可以不牵涉用户注意力的任何其它类型的工作。

在第一模型中，允许在前台和后台中并行执行任意数目的应用，并且竞争诸如处理器周期和存储器之类的资源。该模型在桌面型计算机和膝上型计算机上普遍实现。

在第二模型中，除了“激活的”应用（即，用户正在主动与之交互的应用）之外，阻止执行所有应用。该模型在移动设备上普遍实现，其中在任意给定时刻，用户通常与满屏显示的单个应用交互。

在第三模型中，将同一应用的前台工作和后台工作处理为互相排斥的，使得在前台中执行的应用不被调度来同时进行任何后台工作，反之亦然。

在第四模型中，可以针对前台工作和后台工作分开地对应用进行实例化，其中两个实例并行执行并且竞争资源。

发明内容

前述内容是本发明的非限制性概要，本发明由所附权利要求限定。

本发明人已经认识和理解到现有操作系统执行模型所产生的若干缺点，并且已经开发了新的执行模型，该新的执行模型提供诸如改善的电池寿命和用户体验之类的优点。

在一些实施例中，可以将针对前台工作和后台工作的应用逻辑解耦合，使得允许操作系统分开地加载前台工作和后台工作，并且使得当作出调度决策时不同地处理前台工作和后台工作。例如，应用可以包括分开的组件，一些组件指定为前台组件，其它组件指定为后台组件。操作系统可以基于组件的指定来向它们应用不同的策略，其中可以设计策略以促使资源的有效使用同时向用户提供丰富的多任务处理体验。

在一些其它实施例中，可以在能够独立于彼此而执行的分开的可执行代码块中提供前台组件和后台组件。操作系统也可以在分开的进程中例如通过在受特定资源限制的指定环境中（例如对主机后台组件构建的沙盒（sandbox））隔离后台工作来加载前台组件和后台组件。备选地，操作系统可以在同一进程中但在不同线程中加载前台组件和后台组件，并且仍能够将与后台工作相关联的执行线程和与前台工作相关联的执行线程区分开并且相应地作出调度决策。

在一个实施例中，提供一种方法以供在至少一个计算机上执行的操作系统使用。该方法包括以下的动作：识别应用的至少一个前台组件；识别应用（100）的至少一个后台组件；以及与至少一个后台组件分开地加载至少一个前台组件用于执行。

在其它实施例中，提供至少一个计算机可读介质，其上至少编码有：至少一个第一计算机可执行代码块，实现应用的至少一个前台组件；至少一个第二计算机可执行代码块，实现应用的至少一个后台组件；以及规范（specification），将至少一个第二代码块识别为与应用的后台工作相关联。

在另一其它实施例中，提供一种计算机实现的方法，包括以下的动作：响应于用户动作，执行实现应用的至少一个前台组件的至少一个第一计算机可执行代码块；以及使用与应用相关联的规范来识别实现应用的至少一个后台组件的至少一个第二计算机可执行代码块，其中执行至少一个前台组件而不执行至少一个后台组件。

应理解到的是，前述概念和下面更详细讨论的附加概念（假设这样的概念并不相互矛盾）的所有组合被考虑为这里公开的本发明主题的一部分。特别是，出现在本公开结尾处的请求保护的主题的所有组合被考虑为这里公开的本发明主题的一部分。

附图说明

附图并不一定按照比例绘制。

图1示出根据一些实施例的具有针对前台工作和后台工作的解耦合逻辑的说明性应用100。

图2示出根据一些实施例的针对应用的说明性状态图，该应用具有可以并行执行的前台工作和后台工作。

图3A示出根据一些实施例的其中操作系统在分开的进程中加载前台组件和后台组件的示例。

图3B示出根据一些实施例的其中操作系统在同一进程中加载前台组件和后台组件的示例。

图4示出根据一些实施例的适于分开地管理后台工作和前台工作的操作系统的示例。

图5是根据一些实施例的可以响应于部署代理事件的请求而由代理（broker）组件执行的说明性进程的流程图。

图6示出根据一些实施例的可以由代理组件用来存储有关代理事件的信息的说明性数据结构。

图7是根据一些实施例的可以由代理组件执行以确定何时通过信号发送代理事件的说明性进程的流程图。

图8A是根据一些实施例的可以由代理基础架构执行以将后台组件与代理事件相关联的说明性进程的流程图。

图8B示出根据一些实施例的可以用来存储与后台组件相关联的代理事件的说明性数据结构。

图9示出根据一些实施例的可以由代理基础架构执行以确定何时执行后台组件和如何管理后台组件的执行的说明性进程900。

图10示意性地示出其上可以实现本公开内容的各方面的说明性计算机。

具体实施方式

例如，允许并行执行任意数目的应用的第一执行模型可能导致太多进程竞争诸如处理器周期和存储器之类的资源。这可能又导致资源约束环境中的迟缓性能，资源约束环境诸如在具有有限处理速度和存储器的移动设备上。如果该移动设备依靠电池能量运行，则无差别地执行进程可能也导致缩短的电池寿命。

另一方面，阻止除了一个激活的应用外的所有应用的第二执行模型可能排除期望的多任务处理场景，诸如用户在写邮件，同时听音乐、接收全球定位系统（GPS）位置更新和/或接听进来的因特网协议上语音（VoIP）呼叫。这些多任务处理场景需要即使当用户主动与另一应用交互时也能够一定程度地执行应用。

第三执行模型，即，按照相互排斥方式执行同一应用的前台工作和后台工作，可以类似地排除期望的多任务处理场景，诸如用户经由网页浏览器阅读一个网页页面，同时等待完成网页下载。

尽管分开实例化的第四执行模型可以允许操作系统并行执行同一应用的后台工作和前台工作，但仍然存在很多潜在缺陷。例如，太过于依赖应用开发者编写表现为与前台-后台区别一致的方式的代码。即使应用揭示呼叫参数以允许操作系统指示针对前台工作对应用进行实例化还是针对后台工作对应用进行实例化，开发者也可能非故意地忽略在针对前台工作对应用进行实例化时防止执行后台工作的程序逻辑，或者反之亦然。这破坏了操作系统有效控制后台工作的资源消耗的能力，因为操作系统可能难以确定声称的前台实例是否仅执行前台工作（例如，响应经由用户接口接收到的输入）并且不执行任何不必要或者效率不高的后台工作（例如，周期性地与服务器同步）。

分开实例化方法也可能给用开发者施加了负担来操控有关并行执行的复杂性。例如，当同一应用的前台实例和后台实例并行执行时，两个实例可能在不同的上下文中执行并且可能不共享状态。作为结果，两个实例可能能够仅通过明确由操作系统提供的机制来通信，这可能使得计算机代码复杂化。本发明人已经认识和理解到，尽管后台工作和前台工作之间的这种解耦合可能是期望的，但也会期望赋予开发者选项，以不支持在不同上下文中并行执行多个实例。

因此，在一些实施例中，提供更灵活的执行模型以允许操作系统与前台工作不同地管理后台工作。

在一个方面中，可以解耦合针对前台工作和后台工作的应用逻辑，使得允许操作系统分开地加载前台工作和后台工作，并且使得当作出调度决策时不同地处理前台工作和后台工作。

例如，在一些实施例中，应用可以包括分开的组件，一些组件指定为前台组件，其它组件指定为后台组件。操作系统可以基于组件的指定向它们施加不同的策略，其中可以设计策略以促进资源的有效使用，同时向用户提供丰富的多任务处理体验。

例如，可以针对后台组件实施一个或更多个资源管理策略。这些策略可以设计为基于将由后台组件使用的资源限制何时执行该后台组件。实施这种策略可以有助于为激活的应用（即，用户主动与之交互的应用）保存能量和/或保留充足的资源。这种策略尽管不是必须但可以通过在诸如本领域已知的沙盒之类的受控执行环境中执行后台组件来进行实施，由此将后台组件与前台组件隔离开。

在另一方面中，应用开发者可以具有选项，以不支持在不同进程中并行执行同一应用的前台组件和后台组件。选择这样的选项可以导致更简单且更有效的程序代码。

在一些实施例中，可以在能够独立于彼此而执行的分开的可执行代码块中提供前台组件和后台组件。在一些其它实施例中，前台组件和后台组件可以具有不同的进入点，使得操作系统可以在同一进程中但在不同线程中加载前台组件和后台组件，由此使得前台组件和后台组件能够在共享的状态下一起执行。以此方式，操作系统仍能够将与后台工作相关联的执行线程和与前台工作相关联的执行线程区分开，而不需要应用操控在不同进程中并行执行的各种复杂性。

如果应用确实支持并行执行，则操作系统可能能够选择在同一进程或者在分开的进程中加载前台组件和后台组件。在这些选项之间进行选择可能考虑多种因素。例如，如上所讨论的，将后台工作与前台工作分开可以允许操作系统在受特定资源约束的指定环境（例如，为主控后台组件而构建的沙盒）中运行后台工作。此外，将后台工作与前台工作分开可以减少存储器占用面积（footprint），因为当应用仅执行后台工作时不需要加载仅与用户接口（UI）功能性有关的可执行代码（例如库）。另一方面，如果应用频繁地执行后台工作，或者如果一个或更多个用户频繁地与应用交互，则将前台工作和后台工作共同定位在同一进程中可以是有利的，使得在前台组件和后台组件之间分担进程启动成本。然而，操作系统也能够通过在分开的环境（例如，软件容器）中执行后台工作并且对该环境进行高速缓冲来减少进程启动成本。

在又一方面中，操作系统基于应用提供的指明后台工作的执行预定所处的特定情形的信息可以确定何时执行后台工作。例如，在一些实施例中，操作系统可以仅响应于一个或更多个指明的事件（也称为“触发器（trigger）”）调度后台工作用于执行。触发器的示例包括但不限于有关网络活动的事件（例如，来自网络的分组）、有关用户活动的事件（例如，用户登录或注销）、调度事件（例如，定时器到期）、有关外围设备的事件（例如，打印机通知）等。

在一些其它实施例中，操作系统可以关于何时将执行后台工作而覆写应用的规范。例如，操作系统可以作为对旨在触发后台工作的事件进行过滤的“代理”来起作用。在这种“代理执行”模型中，应用可以向操作系统注册用于使得后台组件执行的一个或更多个触发器，例如以执行后台工作的特定单元（也称为“后台任务”或者“工作项”）。并不是让这种触发器直接引起后台组件的执行，而是操作系统可以引入作决策的附加层。例如，当应用指明的触发器起动时，操作系统可以决定是否通过信号发送所谓的“代理事件”，该“代理事件”又可以使后台组件得以执行。以此方式，操作系统可以最终决定何时执行后台组件。例如，电子邮件客户端可以注册后台同步任务用于周期性执行（例如，每15分钟），并且操作系统可以设定适当的定时器，并且当定时器到期时，基于那时存在的操作条件来决定是否执行该任务。备选地或者附加地，操作系统可以实现如下策略，该策略限制应用可以向操作系统注册多少个特定类型的触发器。在一个示例中，操作系统可以限制应用可以将警报时间注册为触发器的次数，其中该限制可以为任意适当定义的值。这种策略可能是有利的，因为警报事件可以将计算机从“睡眠”模式中“唤醒”，使得限制警报事件的发生可以提高电池寿命。

如上所述，操作系统可以实施一个或更多个资源管理策略，该一个或更多个资源管理策略被设计为控制后台工作的资源消耗。在一些实施例中，可以通过智能地控制代理事件的信号发送来使用代理执行模型实施资源管理策略，由此防止相关联的后台工作消耗太多的功率和/或影响激活应用的响应度。在一个示例中，当确定剩余电池功率低于所选阈值时，操作系统可以推迟一个或更多个代理时间的信号发送，并由此推迟特定的非关键性后台工作。在另一示例中，当检测到高网络时延时，操作系统可以降低通过信号发送一个或更多个代理事件的频率并由此降低应用与服务器同步的频率。在又一示例中，操作系统可以推迟一个或更多个代理事件的信号发送，因为相关联的应用已经用尽可应用的后台处理指标，其形式可以被指定为特定时间段期间允许的后台处理的特定数量（但并非必需）。在又一示例中，操作系统可以推迟一个或更多个代理事件的信号发送，因为特定服务活动可能在进行中，从而相关的可执行文件可能暂时不可用。在又一示例中，多个后台工作项可能要求公共设施（例如，网络连接、图形处理单元、网络摄像机等），该公共设施在接通和断开时会消耗大量能量。因此，操作系统可以控制一个或更多个代理事件的信号发送，以巩固这些工作项的执行并且减少公共设施接通和断开的次数，由此节约能量。

本发明人已经进一步认识和理解到，一些类型的后台工作可能是不必要的和/或效率不高的。例如，如被调度为与电子邮件服务器同步而被唤醒的电子邮件客户端可能发现并不存在网络连接并且可以简单地回到在未来将再次被唤醒的挂起状态。在这种情形下，可以仅花费功率来简单地唤醒电子邮件客户端以检查网络可用性，而可以不执行有用工作。因此，可以期望的是，推迟唤醒电子邮件客户端直到特定系统条件使得有可能执行有用工作。这种系统条件的示例包括但不限于诸如到因特网的连接和硬件组件打开（例如显示器、扬声器等）之类的资源的可用性。

因此，在一些实施例中，除了一个或更多个触发器之外，操作系统可以将后台组件与一个或更多个条件相关联。当触发器起动时，操作系统可以检查相关联的条件，并且只有满足所有相关联的条件时才可以调度后台组件用于执行。因而，通过为后台组件指明一个或更多个条件，应用开发者可以向操作系统标识一组情形，在这组情形下，后台组件有可能有成效地执行并且操作系统可以相应地调度后台组件用于执行。

在一些其它实施例中，如果操作系统确定在触发器起动时不满足一个或更多个相关联的条件，则操作系统可以被配置用于锁存触发器。以此方式，操作系统可以继续检查相关联的条件，如果并且当变得满足所有相关联的条件时，可以执行后台组件。备选地或者附加地，如果在触发器起动时不满足一个或更多个相关联的条件，则操作系统可以简单地丢弃起动的触发器。

在又一些其它实施例中，操作系统可以被配置用于维持可以用来评估与后台组件相关联的一个或更多个条件的状态信息。操作系统可以进一步被配置用于检测所维持的状态信息中的变化并且响应于检测到变化来评估相关联的条件。这可以允许操作系统检测在已经锁存用于后台组件的触发器之后将何时执行该后台组件（例如，因为在触发器起动时不是所有用于后台组件的条件都满足）。备选地或者附加地，操作系统可以获得评估条件所需的相关信息，而无需将这种信息存储为状态信息。

以下为有关用于管理后台工作和前台工作的本发明的系统、方法和装置的各种概念以及其实施例的更具体描述。应理解到的是，上面引入且在下面更具体讨论的各种概念可以按照多种方式中的任何方式实现，因为所公开的概念并不限于任何特定的实现方式。例如，本公开并不限于各图中所示出的组件的特定布置，因为其它布置也是适合的。提供具体实现和应用的这种示例仅用于说明性目的。附加地，尽管这里公开的各种概念对于资源约束计算环境中的资源保留是有用的，但这些概念并不限于在这样的环境中运用。例如，所公开的技术的任何组合可以不仅在移动设备中运用，而且可以在桌面型计算机、服务器计算机等中运用。

图1示出根据一些实施例的具有针对前台工作和后台工作的解耦合逻辑的说明性应用架构。在这样的架构中，可以利用适于允许操作系统分开地管理前台工作和后台工作的接口来将前台工作和后台工作作为分开的应用组件提供。适于分开地管理前台工作和后台工作的操作系统的示例在下面结合图4进行描述。

在图1所示的示例中，应用100包括多个分开的组件，诸如一个或更多个前台组件（例如，前台组件105）、一个或更多个后台组件（例如，工作项110A、110B、110C、……）以及一个或更多个其它组件（例如，共享对象115A、115B、……）。这些组件可以按照使得它们逻辑上彼此解耦合这样的方式来实现。例如，在一些实施例中，这些组件可以在能够独立于彼此而执行的分开的可执行代码块中提供。这些分开的可执行代码块可以具有不同进入点以供操作系统用来分开地加载对应的组件。

例如，在一些实施例中，操作系统可以响应于用户动作而在前台中发起应用100。在前台中发起应用100可以包括经由对应的进入点启动前台组件105。另一方面，操作系统可以响应于检测到一个或更多个事件（例如，上述一个或更多个触发器）的出现而在后台中发起该应用100。在后台中发起应用100可以包括经由与用于前台组件105的进入点不同的对应进入点启动诸如工作项110A之类的后台组件。例如，在一个实施例中，工作项110A可以实现为动态链接库（DLL），并且操作系统可以通过加载DLL和执行DLL的进入点函数来在后台中执行工作项110A。

可以使得在前台中发起应用的用户动作的示例包括但不限于：用户在对应于应用的图块（tile）或者图标上点击，用户登录，用户尝试访问针对其而言应用被识别为默认应用的文件或对象，等等。可以用作触发器来使得在后台中发起应用的事件的示例包括但不限于：定时器到期，网络连接性的改变，从服务器接收到有新内容（例如，电子邮件消息、多媒体内容等）可供下载的通知，等等。然而，应理解到的是，这些动作和事件仅是说明性的，因为其它动作和事件也可以使得发起应用。例如，操作系统开发者、应用开发者和/或用户可以指明用于使得在前台中发起应用的任何适当动作和用于使得在后台中发起应用的任何适当事件。这种事件的示例包括但不限于由操作系统创建的用于组织工作以便资源的有效和/或经济使用的综合事件，诸如指示被指定用于维护的操作时段开始的事件、指示一个或更多个外部服务器的高可用性的事件以及指示低成本网络（例如，自由无线网络）的可用性的事件。

在一些实施例中，可以按照使得便于并行执行这样的方式来在逻辑上解耦合前台组件和后台组件。在一个示例中，可以实现前台组件和后台组件以避免直接通信，这可以减少悬挂（hanging）（例如，前台组件和后台组件同时等待彼此完成相应的任务，或者在与前台组件相同的线程上执行的后台组件阻止前台活动的立即处理）的可能性。因而，在一些实施例中，后台组件可以依赖操作系统向对应的前台组件报告进展，诸如通知前台组件后台组件已经完成执行。操作系统可以经由前台组件提供的后台状态报告接口（诸如图1所示前台组件105的“BG状态”接口）来这样做。这种报告机制可以允许前台组件和后台组件一起工作来向用户提供单一的一体化体验。作为具体示例，当后台组件从服务器下载电子书时，下载的进展可以在用户发起前台组件时经由对应的前台组件传送给用户。

解耦合的另一说明性方法是避免对共享数据的直接操作，这可以减少数据损坏的可能性。例如，在一个实施例中，前台组件和后台组件可以将持久存储用于一些或者所有数据通信以减少数据损坏的可能性。在一些其它实施例中，前台组件和后台组件可以在诸如图1所示的共享对象115A和115B之类的共享对象上操作，但仅通过调用共享对象上的一个或更多个接口（未示出）。这样的共享对象可以适于将数据访问串行化，由此防止数据损坏。

应理解到的是，经由操作系统和/或共享对象的通信只是可以单独或者组合使用来在逻辑上将后台组件与前台组件解耦合的说明性方式。可以使用其它解耦合方式，因为本公开内容的各方面并不限于任何特定的解耦合方式。

在图1所示示例中，应用100进一步包括规范120，该规范120包含可以由操作系统用来分开地加载和管理前台组件和后台组件的信息。规范120可以按照操作系统被配置用于进行处理的任何适当格式编写。例如，规范120可以为按照适当标记语言（诸如可扩展标记语言（XML））编写的应用表现形式。

规范120可以包含对操作系统有用的信息的任何适当组合。在一个示例中，规范120可以识别对应于后台组件（例如，工作项110A、110B、110C、……中的一个）的可执行代码以及对应的“启动”和“取消”接口以供操作系统用于分别启动和停止后台组件的执行。

在另一示例中，规范120可以指明操作系统响应于其而将执行后台组件的一个或更多个触发器。在一些实施例中，规范120可以进一步指明在操作系统执行后台组件之前将要检查的一个或更多个条件。如下面结合图5至图7更详细讨论的那样，这些触发器和/或条件可以由操作系统使用来确定何时将执行后台组件，例如以控制后台组件的资源消耗。

在又一示例中，规范120可以指明由前台组件实现的一个或更多个后台工作状态报告接口（例如，图1所示的前台组件105的“BG状态”接口）。如上所述，操作系统可以使用这样的接口来报告后台组件的执行进展。

同样，上述信息项仅是说明性的。应用开发者可以选择在规范中包括信息的任何适当组合，以帮助操作系统分开地加载和管理前台组件和后台组件。备选地或者附加地，操作系统提供者可以请求规范中提供的信息和/或工具的一些所选项以供操作系统使用来分开地加载和管理前台组件和后台组件。

在一些实施例中，可以充分地解耦合应用的前台组件和后台组件，使得操作系统能够分开地移动前台组件和后台组件通过它们相应的生命周期。图2示出具有可以并行执行的前台组件和后台组件的应用的说明性状态图。

在图2所示的示例中，应用的状态图包括两个分开的组件状态图200和250。状态图200示出应用的前台组件的说明性生命周期，状态图250示出应用的后台组件的说明性生命周期。

在说明性生命周期200中，前台组件可以处于如下三个不同状态中的一个状态：激活状态205、挂起状态210和非运行状态215。在激活状态205中，前台组件驻留于存储器中或者激活的分页文件中，并且正在由操作系统调度用于执行。在挂起状态210中，前台组件仍驻留于存储器中或者激活的分页文件中，但不再由操作系统调度用于执行。在非运行状态215中，前台组件不再驻留于存储器中，也不再驻留于任何激活的分页文件中。

另一方面，在图2所示的说明性生命周期250中，后台组件可以处于如下两个不同状态中的一个状态：运行状态255和非运行状态260。在运行状态255中，后台组件驻留于存储器或者分页文件中，并且正在由操作系统调度用于执行。在非运行状态260中，后台组件可以不再驻留于存储器中，也不再驻留于任何分页文件中。备选地，后台组件可以在主控环境（例如，容器）中执行，并且当后台组件移动到非运行状态260时，可以对主控环境进行高速缓冲。

因而，在该示例中，包括前台组件和后台组件二者的作为整体的应用可以具有六个不同状态：<前台激活，后台运行>、<前台挂起，后台运行>、<前台非运行，后台运行>、<前台激活，后台非运行>、<前台挂起，后台非运行>以及<前台非运行，后台非运行>。随着前台组件和后台组件移动通过它们相应的生命周期，作为整体的应用可以移动通过这六种状态，这在下面更详细地进行描述。在最后的状态<前台非运行，后台非运行>中，可以认为应用被终止，因为应用既不在前台中也不在后台中是正在运行的。

如上述，由于前台组件和后台组件在逻辑上解耦合，所以操作系统能够将一个组件从一种状态移动到另一种状态，而不管其它组件的状态如何并且也不会影响其它组件。例如，在一些实施例中，前台组件可以从激活状态移动到挂起状态，或者反之亦然，而不管后台组件的状态如何并且也不会影响后台组件的状态。作为更具体的示例，当前台组件从激活状态205移动到挂起状态210时，取决于后台组件处于运行状态255还是非运行状态260，作为整体的应用可以从<前台激活，后台运行>移动到<前台挂起，后台运行>，或者从<前台激活，后台非运行>移动到<前台挂起，后台非运行>。

应理解到的是，尽管前台组件和后台组件可以按照逻辑上解耦合的方式实现，但是操作系统可以（但不是必须）使用有关前台组件的执行的信息来管理后台组件的执行，或者反之亦然。例如，在一些实施例中，仅当前台组件挂起或者非运行时，操作系统可以调度后台组件用于执行。总之，逻辑上解耦合前台组件和后台组件可以赋予操作系统选项，以创建组件的执行之间的依赖关系或者不创建这种依赖关系。

现在转向图2所示的说明性生命周期200，操作系统可以运用任何适当的规则集合来确定何时将前台组件从一个状态移动到另一状态。这样的规则可以被设计为防止没有正在受用户关注的前台组件消耗诸如电池功率、处理器周期和存储器之类的资源。实施这些规则可以提高电池寿命和/或正在受用户关注的前台组件的响应度。在一个示例中，操作系统可以将没有正在受用户关注的前台组件从挂起状态移动到非允许状态，以回收存储器资源。

在一些实施例中，前台组件可以初始地处于非运行状态，并且操作系统可以响应于用户动作（例如，用户在对应于应用的图标或者图块上点击）启动前台组件。启动前台组件可以涉及：将前台组件和前台组件可以访问的任何辅助组件加载到存储器中，初始化前台组件，和/或分配合适的资源。如果应用的后台组件已经在启动前台组件时运行并且前台组件被加载到与后台组件相同的进程中，则一些辅助组件也许已被加载并且一些资源也许已被分配。否则，可以执行整个发起。在任一个事件中，前台组件都可以在激活状态205中启动，并且可以由操作系统调度用于执行。

在一些实施例中，一旦前台组件从存储装置中被加载，操作系统就可以通过调用前台组件提供的API函数执行前台组件的进入点函数来初始化前台组件。更具体而言，在图1至图2所示的示例中，操作系统可以调用由前台组件实现的所谓的“启动”方法。

当用户正在主动与前台组件交互时，操作系统可以将前台组件维持在激活状态205中，以避免干扰用户的体验。用户可以按照多种不同的方式（例如通过经由用户接口向前台组件提供输入）主动地与前台组件交互。出于确定前台组件是否要保持在激活状态的目的，如果前台组件正在呈现输出（例如，播放音频和/或视频）或者正在完成用户请求的任务（例如，在网络连接上发送数据，写入文件，打印，等等），也可以认为用户正在主动与前台组件交互。

在一些实施例中，当用户不再主动与前台组件交互时，操作系统可以将前台组件从激活状态205移动到挂起状态210。这例如发生在用户将焦点切换到不同应用的窗口时，用户将前台组件的窗口最小化时，用户在某阈值时间段内未向前台组件提供任何输入时，等等。备选地或者附加地，当前台组件不再执行可以被认为是前台活动的任何活动时，操作系统可以将前台组件从激活状态205移动到挂起状态210。可以被认为是前台活动的活动的示例包括但不限于音频回放、设备同步等。

在将前台组件从激活状态205移动到挂起状态210之前，操作系统可以通知前台组件将要挂起前台组件，所以前台组件可以相应地诸如通过保存状态和释放分配的资源来做好准备。例如，操作系统可以通过调用前台组件提供的应用编程接口（API）函数来通知前台组件。在更具体的示例中，如图1和图2所示，操作系统可以调用前台组件实现的所谓的“静止（Quiesce）”方法，这可以使得前台组件保存状态并释放资源（例如，文件、网络连接等）。在一些实现中，静止方法可以包括操作系统代码来明确地阻止调用静止方法的线程（即，前台组件的线程）被调度用于执行。除了作为整体挂起（例如，禁止调度）整个前台组件之外，这是可以完成的。前台组件可以保持被阻止直到操作系统将前台组件向后移动到激活状态205。

在一些实施例中，当用户开始再次与前台组件交互时，操作系统可以将前台组件从挂起状态210向回移动到激活状态205，例如当通过将焦点切换回到前台组件的窗口时，将前台组件的窗口从最小化状态复原时，开始向前台组件提供输入时，等等。为此，操作系统可以简单地调度前台组件用于执行。在一些实施例中，操作系统可以附加地调用前台组件提供的API函数，以帮助前台组件恢复之前的状态。更具体而言，在图1和图2所示的示例中，操作系统可以调用前台组件实现的所谓的“重新开始（Resume）”方法，这可以使得前台组件检索保存的状态并且请求合适的资源（例如，文件、网络连接等）。

在一些其它实施例中，操作系统可以通过将前台组件从存储器中去除来将前台组件从挂起状态210移动到非运行状态215。这样做可以例如用于减少存储器的使用或者允许更新前台组件的可执行代码。如果在操作系统将前台组件移动到非运行状态215时应用没有正在后台中运行，则应用可以变为完全终止。否则，后台组件可以继续运行，而不管前台组件如何改变状态。

如果当前台组件已经移动到非运行状态215时用户开始再次与前台组件交互，则操作系统可以再次启动前台组件，这可以类似于上面所讨论的初始地启动前台组件。

应理解到的是，操作系统可以选择用于确定何时将前台组件从激活状态205移动到挂起状态210以及何时将前台组件从挂起状态210移动到非运行状态215的任何适当的规则集合和技术。这些规则可以反映在与挂起前台组件相关联的预期成本与预期利益之间的期望平衡以及在与从存储器移除前台组件相关联的预期成本与预期利益之间的期望平衡。例如，尽管挂起前台组件可以带来资源的一些节省，但前台组件会引起附加的处理开支用于准备挂起和从挂起重新开始。此外，当前台组件开始从挂起重新开始并尝试重新得到资源（例如，重新打开文件，重新建立网络连接，等等）时用户可能体验迟缓。类似地，尽管从存储器移除前台组件可以减少存储器使用，但前台组件会引起附加处理开支用于重新启动，并且当前台组件正在被重新加载和重新初始化时用户会体验迟缓。

转到图2所示的说明性生命周期250，后台组件可以初始地处于非运行状态260。在一些实施例中，操作系统可以响应于检测到一个或更多个事件的出现而启动后台组件。如下面结合图5至图7更具体讨论的那样，在一些说明性实施例中，可以考虑两种类型的事件（即，触发器和条件）来确定何时启动后台组件。

启动后台组件可以涉及：向存储器中加载后台组件以及后台组件可以访问的任何辅助组件，初始化后台组件，以及/或者分配合适的资源。如果在启动后台组件时该应用的前台组件已经正在运行并且后台组件加载到与前台组件相同的进程中，则一些辅助组件也许已被加载并且一些资源也许已被分配。否则，可以执行完全发起。在任一个事件中，后台组件都可以移动到运行状态255。

在一些实施例中，一旦将后台组件从存储装置加载，操作系统就可以通过调用后台组件提供的API函数来执行后台组件的进入点函数，从而初始化后台组件。在更具体的示例中，如图1至图2所示，操作系统可以调用后台组件实现的所谓的“启动”方法。

在一些实施例中，在后台组件启动之后，操作系统可以监视后台组件的进展。一些后台组件（例如，图1所示的工作项110A、110B、110C、……）可以分别对应于分立的后台任务（例如，从服务器下载内容块，检查软件更新的可用性，例行病毒扫描，等等）。如此，并不希望这些后台组件无限期地运行。如果后台组件在运行后某阈值时间段后还没有足够的进展，则操作系统可以停止执行后台组件，由此将后台组件移动到非运行状态260。

操作系统可以使用任何已知的用于监视计算任务的进展的技术来监视后台组件的进展。备选地或者附加地，应用可以为操作系统提供一个或更多个工具用于监视进展。例如，后台组件可以实现“检查进展”接口，操作系统可以调用该接口来获得进展信息（例如，任务完成的百分比和/或后台组件正在等待来自另一组件的响应还是正在等待一些资源变为可用）。可以在与应用相关联的规范（诸如图1所示的规范120）中指明该接口。

在一些实施例中，操作系统可以通知后台组件将要停止后台组件，所以后台组件可以诸如通过保存状态和释放分配的资源来相应地做好准备。这例如可以通过调用后台组件提供的API函数来完成。更具体而言，在图1至图2所示的示例中，操作系统可以调用后台组件实现的所谓的“取消”方法，之后在操作系统将后台组件移动到非运行状态260之前后台组件可以被赋予某少量时间（例如，几秒钟）。

如果后台组件继续按照足够速率进展，则操作系统可以允许后台组件运行以便完成。在该情况下，操作系统也可以例如通过将后台组件从存储器移除来将后台组件移动到非运行状态260。

如果在操作系统将后台组件移动到非运行状态215时应用没有正在前台中运行，则应用可以变为完全终止。否则，前台组件可以继续运行（例如，处于激活状态205或者挂起状态210），而不管后台组件如何改变状态。

尽管在图2中示出并且在上面描述了应用组件生命周期的具体示例，但应理解到的是，提供这些示例仅用于说明性目的。本公开内容的各方面并不限于任何特定的生命周期的定义，也不限于任何特定的管理生命周期的方式。例如，前台组件可以移动通过与图2所示不同的状态集合，并且操作系统可以运用不同的策略来确定何时将前台组件从一个状态移动到另一个状态，并且针对后台组件也类似。作为另一示例，操作系统可以加载同一环境（例如，软件容器）中的相同后台组件或不同后台组件的一个或更多个实例，并且可以仅当这些实例中任一个都不运行时从存储器移除该环境。作为又一示例，操作系统可以保持后台组件被无限期地加载以便提高效率。

如上所述，在一些实施例中，如果前台组件和后台组件能够在任一种方式中执行，则操作系统可以选择在相同进程或者在分开的进程中加载应用的前台组件和后台组件。在一个示例中，操作系统可以默认地在分开的进程中加载前台组件和后台组件，除非用户的应用另外指明。在另一示例中，操作系统可以与对应的前台组件分开地加载应用提供的后台组件，但可以将操作系统提供的后台组件与后台组件正在为其工作的应用共同定位。也可以施加其它适当规则，因为本公开内容的各方面并不限于这种方式。

图3A示出其中操作系统305在进程320中向存储器300加载前台组件310并且在分开的进程325中向存储器300加载后台组件315的示例。以此方式将后台工作与前台工作隔离可以便于资源管理。例如，在一些实施例中，操作系统可以在受控执行环境（例如，本领域已知的沙盒）中运行进程325，该受控执行环境被构造为允许在其中运行的进程仅访问指定资源。以此方式，操作系统可以向受控执行环境分配某指明数量的资源（例如，某指明百分比的CPU时间、存储器等）以确保后台组件315不消耗多余指明数量的资源。在一些实现中，受控执行环境可以被指定用于运行后台组件，使得其它应用的后台组件也可以在沙盒中运行并且受约束于相同的资源限制。

在分开的进程中将后台工作与前台工作隔离也可以有助于减少存储器占用面积，因为操作系统可以避免当应用仅在执行后台工作时加载仅与用户接口（UI）功能性有关的可执行代码（例如，库）。例如，在其中将前台工作和后台工作实现为分开组件的实施例中，UI有关功能性可以仅存在于前台组件中，而这不需要在主控后台组件的进程中加载。

图3B示出其中操作系统350在相同进程370中将前台组件360和后台组件365加载到存储器350中的示例。以此方式共同定位前台工作和后台工作可以允许前台组件360和后台组件365共享启动成本。因此，如果频繁地运行组件之一，例如，如果一个或更多个用户频繁地与应用交互，或者如果应用频繁地执行后台工作，则共同定位这些组件可以是有利的。

在图3B所示的示例中，前台组件360和后台组件365由操作系统355分别作为分开的线程（线程380和385）启动。以此方式，操作系统355仍然能够分开地管理前台组件360和后台组件365的执行。例如，操作系统可以阻止执行线程380（并且因此阻止执行前台组件360），同时允许执行线程385（并且因此允许执行后台组件365），并且反之亦然。

因而，在一些实施例中，操作系统可以适于基于在容易实现的资源管理与降低的启动成本之间的期望折衷来决定是共同定位前台组件和后台组件还是将前台组件和后台组件分开。也可以考虑其它考虑（例如，诸如存储器和/或处理器使用之类的动态操作条件、激活进程的数目等），因为本公开内容的各方面并不限于任何特定的用于共同定位或分开前台组件和后台组件的原因。在一个示例中，在其中可以通过在后台组件执行的同时保持前台组件的一些或者所有线程可运行来防止死锁的实现中，在决定是共同定位前台组件和后台组件还是将前台组件和后台组件分开时可以考虑存储器和/或存储器周期的消耗。在另一示例中，例如可以通过分开有问题的后台组件以减少与其它前台组件和/或后台组件的干扰来考虑软件可靠性。

图4示出适于分开地管理后台工作和前台工作的操作系统400的示例。在该示例中，操作系统400实现用于后台组件的代理执行模型，其中每个应用向操作系统400注册旨在于在后台中运行的一个或更多个应用组件，并且操作系统400最终控制何时执行每个后台组件、何地执行每个后台组件以及/或者每个后台组件执行多久。以此方式，操作系统400可以有效地控制后台组件的资源消耗。

在图4所示的示例中，操作系统400使用代理基础架构（BI）405和多个代理实现代理执行模型。在该示例中，利用代理对操作系统400进行预先编程，每个代理被配置用于管理相应类型的资源和/或处理相应类型的事件。例如，操作系统400可以包括所示出的时间代理415A、网络连接代理415B、远程唤醒代理415C以及系统事件代理415D。例如通过允许第三方提供适于管理新类型的资源和/或处理新类型的事件的新代理（例如，可以提供位置代理使得后台工作的执行可以依赖于地理位置），这种构架可以是可容易扩展的。然而，应理解到的是，代理执行模型不需要使用具有代理基础架构和多个代理的构架。而在备选实施例中，代理基础架构和各个代理的功能性可以通过单个操作系统组件或者操作系统外部的一个或多个组件来提供。

如下面结合图8至图9更具体讨论的那样，代理基础架构405可以负责管理诸如工作项之类的后台组件的执行。例如，在一些实施例中，代理基础架构405可以提供接口（例如，图4所示的“注册”接口）以供应用用来注册后台组件用于代理执行。注册后台组件可以包括从应用接收后台组件的标识以及关于何时运行后台组件的指示（例如，通过指明一个或更多个触发器和/或条件）。例如，应用可以提供标识实现后台组件的软件对象的对象标识符，并且可以标识响应于其而将要执行后台组件的事件。

在一些实施例中，无论何时检测到对应事件的出现，代理基础架构405都可以运行后台组件。备选地，代理基础架构405可以根据合适的资源管理策略实施附加的约束和/或限制。例如，附加的约束和/或限制可以反映被设计用于防止单个应用消耗太多资源和/或防止已经安装但还没有投入使用的应用消耗任何资源的策略。在一个实施例中，可以基于用户使用每个应用的程度来向不同应用分配资源。例如，分配给应用的资源数量可以与作为所有应用的使用百分比的该应用的使用率成比例。这种策略在其中用户安装大量（例如，数百个）应用但仅频繁地使用少量（例如，10、15或20个）应用的常见场景中可能是期望的。

在一些其它实施例中，代理基础架构405可以监视后台组件在执行期间的进展和/或资源消耗。这可以使用用于监视与软件组件相关联的进展和/或资源消耗的任何已知技术来完成。备选地或者附加地，代理基础架构可以调用后台组件提供的接口用于报告进展和/或资源消耗。代理基础架构405可以从诸如图1所示的规范120之类的应用规范中发现这样的接口。

如果后台组件没有以足够的速率进展，或者如果后台组件消耗太多资源，则代理基础架构405可以停止后台组件的执行。同样，用于停止后台组件的决策可以基于任何合适的资源管理策略。

在又一些其它实施例中，代理基础架构405可以负责向前台组件报告后台工作的进展。这可以帮助避免在后台组件和前台组件之间的直接通信，如上面所解释的，这可以便于前台组件和后台组件之间的逻辑解耦合。

在一个示例中，当后台组件成功完成时，代理基础架构405可以通知前台组件，使得前台组件可以执行任何适当处理。例如，当在后台中下载完成时，代理基础架构405可以通知对应的前台组件，这又可以通知用户新内容可用。在另一示例中，当后台组件由于不充足的进展或者过多的资源消耗而停止时，代理基础架构405可以通知对应的前台组件。前台组件尽管不是必须但可以向用户报告失败，用户可以选择重新启动后台组件，使其豁免于后台组件所违背的资源管理策略。然而，应理解到的是，在生成通知时前台组件可以不是激活的。在这样的场景中，当前台组件在未来变为激活时（例如，当用户在对应于前台组件的图块或图标上点击时），代理基础架构405可以通知前台组件。备选地，代理基础架构405可以例如通过通知用户后台任务的成功或失败来自己操控通知。

参照图4，在一些实施例中，应用可以指明所谓的“代理事件”作为响应于其而将要执行后台组件的事件。代理事件可以是代理组件通过信号发送的事件，该代理组件诸如时间代理415A、网络连接代理415B、远程唤醒代理415C、系统事件代理415D或某其它代理。每个这样的代理可以适于在一些指明的情形下通过信号发送事件。例如，时间代理415A可以适于在绝对时间、规则间隔或者在与系统操作有关的特定“方便”时间（例如，用于执行任选活动的维护时间）通过信号发送事件，网络连接代理415B可以适于当数据在网络套接字上可用时通过信号发送事件，远程唤醒代理415C可以适于转发来自一个或更多个云服务器的事件，并且系统事件代理415D可以适于通过信号发送诸如用户登录或注销之类的事件。

在一些实现中，代理可以提供接口（例如，图4所示的“请求”接口），通过该接口应用可以请求代理在应用指明的特定情形下通过信号发送代理事件。以此方式，应用可以通知操作系统想要何时运行后台组件。例如，如下面结合图5至图6更具体讨论的那样，代理可以允许应用请求在已经起动一个或更多个“触发器”时通过信号发送的代理事件。附加地，除了触发器的起动之外，应用可以指明在通过信号发送代理事件之前将要满足的一个或更多个“条件”。

类似于代理基础架构405，在一些实施例中，代理可以例如经由一个或更多个约束和/或限制来实施一个或更多个适当资源管理策略。例如，在一些实例中，即使当已经起动触发器并且满足所有条件时，代理也可以不通过信号发送代理事件，因为通过信号发送代理事件可能违背某资源管理策略。作为更具体的示例，时间代理415A可以限制代理事件每天的重复发生次数，使得请求该代理事件的应用在后台中每天不执行多于该次数。

尽管上面讨论了代理的若干示例，但应理解到的是，这些代理仅是说明性的。在各种实施例中，操作系统可以包括适于实施适当资源管理策略的代理的任意适当组合。诸如通过指明在固定时间量下可以由应用消耗的固定资源量，一些策略本质上可以是静态的。其它策略可以是动态的，并且可以基于操作条件（例如，系统是否正在依靠电池运行，CPU和/或存储器使用是否在持续时间段上保持为高，等等）对消耗施加限制。又一些策略可以组合静态和动态的方面。

再次返回图4所示的示例，操作系统400附加地包括多个后台组件，诸如工作项410A、410B、410C、……。类似于图1所示的工作项110A-110C，工作项410A-410C可以在后台中执行以完成应用的工作，并且可以由操作系统400按照与应用提供的后台组件相同的方式进行管理。例如，操作系统400可以实施与针对工作项110A-110C相同的针对工作项410A-410C的资源管理策略。然而，在备选实施例中，操作系统400可以信任工作项410A-410C，而不是工作项110A-110C，因为工作项410A-410C是操作系统的一部分，而工作项110A-110C包含应用提供的代码。因此，操作系统400可以放宽针对工作项410A-410C实施的策略，因为信任工作项410A-410C。例如，操作系统400可以在与前台组件分开的沙盒中加载工作项110A-110C，但可以在与相应前台组件相同的进程中加载工作项410A-410C。

同样，应理解到的是，本公开内容的各方面并不限于使用来自任何特定源的后台组件。在各种实施例中，后台组件可以由操作系统开发者、应用开发者和/或任何其它第三方软件提供者编写。

图5示出根据一些实施例的响应于对部署代理事件的请求而可以由代理组件执行的说明性进程500，图6示出可以由代理组件结合进程500使用的说明性数据结构600。例如，进程500可以由图4所示的代理415A-415D之一响应于应用调用“请求”接口来执行。

在动作505处，代理组件可以接收对代理事件的请求。在各种实施例中，该请求可以包括代理可以用来决定何时通过信号发送所请求的代理事件的信息项的任意组合。例如，代理的API可以指示期望信息的特定项，以允许代理实施一个或更多个资源管理策略。这种信息项的示例包括但不限于请求者（例如，应用）的标识、响应于其而将要通过信号发送所请求的代理事件的一个或更多个触发器、当通过信号发送所请求的代理事件时将要满足的一个或更多个条件、所请求的代理事件的预期目的的指示（例如，使得操作系统执行所选的后台组件）以及任何其它适当的信息项。

在动作510，代理组件可以向所请求的代理事件指派代理事件ID。该代理事件ID对于针对代理事件的每个请求可以是唯一的。例如，如果两个应用均经由代理的API的不同调用请求代理事件，则即使潜在的触发器相同，代理也可以指派不同的代理事件ID。以此方式，当潜在的触发器起动时代理可以通过信号发送两个不同的代理事件，每个代理事件承载不同的代理事件ID。

尽管不要求，但唯一的代理事件ID可以是有利的，因为即使触发器相同，不同的应用也可以指明用于代理事件的不同条件。此外，由代理实施的一个或更多个资源管理策略可以取决于特定应用不同地施加。因而，可以使用唯一的代理事件ID以确保施加合适的条件集合（不管是由对应的应用还是由操作系统施加）来控制代理事件的信号发送。

在动作515处，代理可以标识响应于其而将通过信号发送所请求的代理事件的一个或更多个触发器。触发器可以是代理被编程用于检测的任意事件。在一个示例中，触发器可以是用户有关的事件，诸如用户登录或注销、用户变为激活（例如，通过提供诸如打字、移动鼠标、讲话等之类的任何输入）、用户变为非激活（例如，通过在至少阈值时间段内不提供任何输入）、用户启动用户会话、用户请求下载、用户初始化打印作业、等等。在另一示例中，触发器可以为系统有关的事件，诸如定时器的到期、消息或通知的到达（例如，SMS消息或运营商消息通知）、网络状态的变化、网络信道重置、因特网变得可用或者不可用、软件更新的完成、等等。在又一示例中，触发器可以为应用有关的事件，诸如应用请求立即通过信号发送代理事件以使得操作系统立刻启动后台组件。在又一示例中，触发器可以为由操作系统组件（例如，代理）通过组合来自不同源的一个或更多个事件、一个或更多个系统条件以及/或者一个或更多个系统策略的知识而创建的综合事件。综合事件的具体示例可以为“维护时间”，这可以指示被指定用于维护的操作时段的开始。

尽管应用可以指明一个触发器用于所请求的代理事件，但在一些情况下可以指明多个触发器。例如，代理可以将这些触发器视为备选，使得假如满足任意和所有指明的条件，则任一个触发器的起动都可以引起所请求的代理事件的信号发送。备选地，代理可以将一些或者所有触发器视为结合体，或者可以允许应用指明触发器的任何适当逻辑组合。在又一些其它实施例中，可以提供多个代理，每个代理响应于单个触发器，并且该多个代理可以共同实现多个触发器的组合。

在动作520处，代理可以与在动作510处指派的代理时间ID相关联地存储在动作515处标识的一个或更多个触发器。触发器可以按照任意适当方式存储。在一些实施例中，每个触发器可以存储为触发器配置和触发器类型。作为另一示例，代理可以在图6所示的说明性数据结构600中存储触发器和代理事件ID。在该实施例中，数据结构600可以包括多个条目，每个条目对应于所请求的代理事件并且至少具有三个字段：用于存储代理事件ID的字段605，用于存储触发器的字段610，以及用于存储条件的字段615。例如，在第一说明性条目中，代理事件ID“BE₁”与多个备选触发器“E_1,1”、“E_1,2”、……以及单个条件“C_1,1”相关联。尽管未示出，但数据结构600中的条目可以具有附加的字段，例如以存储可以允许代理实施一个或更多个资源管理策略的其它信息项。

返回图5，在动作525处，代理可以确定是否指明当通过信号发送所请求的代理事件时将要满足的一个或更多个条件。如果指明一个或更多个条件，则代理可以继续进行以在动作530处识别该条件。否则，代理可以跳过动作530和535并且直接进行到动作540。

如上所述，可以由请求代理事件的应用指明条件，例如，以通知操作系统一组情形，在该组情形下相关联的后台组件有可能执行有用工作。例如，用于从因特网下载内容的后台组件可以仅能够在至因特网的连接可用时执行有用工作。相应地，应用可以请求仅当因特网可用时通过信号发送代理事件。

条件的其它示例包括但不限于用户有关的条件（例如，用户处于激活或者非激活）、系统有关的条件（例如，网络可用/不可用）、应用有关的条件（例如，应用已经由用户在过去不久（例如，如由某阈值时间量确定的那样）主动使用，应用没有超过由操作系统授权的特定资源分配，等等）等。

应用可以指明任何数量的条件，因为本公开内容的各方面并不限于针对代理事件指明的任何特定数量的条件。例如，应用可以指明一个或更多个条件，或者根本不指明条件。代理可以将条件视为结合体，使得即使对应的触发器已经起动，也不通过信号发送所请求的代理事件，除非满足所有指明的条件。备选地，代理可以将条件视为备选，使得当对应触发器起动时，如果满足指明条件中的任一个条件，则通过信号发送所请求的代理事件。在一些其它实施例中，代理可以允许应用指明条件的任何适当逻辑组合。

备选地或者附加地，除了请求代理事件的应用之外，操作系统或应用（例如，小应用程序（applet））也可以指明将与代理事件相关联的一个或更多个条件。例如，在一些实施例中，代理可以实现用于操作系统或应用的接口，以便例如通过提供在动作510处指派的代理事件ID调用从而指明和/或修改与代理事件相关联的条件。

如果在动作525和530处识别一个或更多个条件，则代理在动作535处可以与在动作510处指派的代理事件ID相关联地存储所识别的条件。例如，代理可以将条件存储在图6所示并且在上面讨论的说明性数据结构600中。

在动作540处，代理可以将在动作510处指派的代理事件ID返回给请求代理事件的应用，使得应用可以调用另一操作系统功能性以将代理事件与期望的后台组件相关联。如结合图9更具体讨论的那样，在一些实施例中，应用可以向代理基础架构（或者任何其它适当的操作系统组件）注册后台组件用于执行，这可以响应于代理通过信号发送由代理事件ID识别的代理事件来执行后台组件。

在动作545处，代理可以向代理基础架构（或信号发送的代理事件的任何其它预期接收者）指明与所请求的代理事件相关联的任何附加约束。例如，在一些实施例中，代理可以是用于管理特定类型的资源的专用组件，并且可以向代理基础架构传送在操控与特定类型的资源有关的代理事件时将应用的任何专用策略。该信息可以按照任何适当方式传送，例如使用在动作510处指派的代理事件ID经由在代理与代理基础架构之间的直接通信，或者通过向应用提供与在动作510处指派的代理事件ID一同提交给代理基础架构的信息。

可以由代理指明的适当约束的示例包括但不限于，请求代理基础架构在响应于所请求的代理事件而执行一个或更多个后台组件之前和/或之后通知代理：与所请求的代理事件相关联的任何后台组件从代理基础架构的节流规则的豁免、在通过信号发送所请求的代理事件之后将要执行和/或完成一个或者更多个后台组件的期限；在同一进程中运行与来自该代理的代理事件相关联的所有后台组件并且仅作为最后手段来终止该进程；使与来自该代理的代理事件相关联的后台组件串行化；使信号发送的代理事件在系统重启过程中持续以及/或者在系统重启之后通知代理持续的通过信号发送的代理事件；等等。

尽管上面结合图5讨论了触发器、条件和约束的具体示例，但应理解到的是，本公开内容的各方面并不限于由应用和/或操作系统指明的触发器、条件和/或约束的任意特定组合。在一些实施例中，触发器、条件和/或约束可以表示为将由操作系统组件（例如，代理）解译以确定何时执行后台工作项的通用程序。此外，尽管描述了其中代理基础架构和各个代理构成两级结构的说明性实施例，但其它实施例可以包括代理的多级分层结构，其中在一级处的代理可以组合来自较低级处的一个或更多个其它代理的事件。

图7示出根据一些实施例的可以由代理组件执行以确定何时通过信号发送代理事件的说明性进程700。例如，进程700可以通过图4所示的代理415A-415D之一执行。

在动作705处，代理可以检测触发器的起动。如上所述，这可以包括从操作系统接收指示刚刚发生过的某些事的事件，诸如用户登录或注销、网络变得可用或不可用、定时器到期等。

响应于检测到触发器起动，代理可以在动作707处识别将通过信号发送的一个或更多个相关联的代理事件。这可以例如通过访问诸如图6所示那样的数据结构来完成。例如，代理可以识别数据结构600中在“触发器”字段610中存储有已起动触发器的一个或更多个条目。如果识别多个这样的条目，则代理可以逐一处理这些条目。

对于匹配已起动触发器的每个条目，代理可以在动作710处确定是否针对对应的代理事件指明任何条件，并且如果是，则确定是否满足所有这样的条件。在一些实施例中，这可以通过检查图6所示的对应“条件”字段615以及评估所有存储的条件来完成。在备选实施例中，代理可以针对每个存储的条件维持表明当前是否满足所存储的条件的布尔变量以及用于评估该条件的任意辅助变量。代理可以响应于辅助变量的变化来连续地更新布尔变量。以此方式，代理可以在动作710处简单地检查布尔变量，而不必再次评估该条件。

如果满足所有相关联的条件，或者如果没有条件存储在字段615中，则代理可以进行动作715。否则，代理可以在动作720处锁存触发器并且继续监视相关联的条件。在其中代理针对每个存储的条件维持布尔变量的实施例中，监视这些条件可以仅包括连续地更新布尔变量。如果并且当在动作725处针对相关联的条件中的一个或更多个条件检测到变化时，代理可以返回至动作710以检查是否满足所有相关联的条件。代理可以无限期地围绕动作710、720和725循环，除非有期限与锁存的触发器相关联，在这种情况下当期限到期时代理可以丢弃锁存的触发器。

如果在某点所有相关联的条件都变得满足，则代理可以在动作715处检查对于代理事件是否可应用任何代理限制，并且如果是，则检查是否满足可应用的代理限制。如上所述，作为控制应用的资源消耗的方式，代理可以实施一个或更多个资源管理策略，并且即使在已经起动触发器并且满足所有应用指明的条件之后，也可以抑制通过信号发送代理事件。代理限制可以是用于实施这些资源管理策略的机制。在一个示例中，可以对单个应用可以如何频繁地使用由代理管理的资源施以限制（形式为例如，每天或者某其它适当时间段的次数，或者已经由来自应用的后台活动消耗多少管理的资源，或者在该时间段内系统作为整体已经消耗多少被管理的资源）。也可以指明其它类型的代理限制，因为本公开内容的各方面并不限于任何特定类型的代理限制。

如果满足所有可应用的代理限制，则代理可以在动作720处通过信号发送代理事件，否则代理可以简单地丢弃所起动的触发器。在一些实施例中，代理可以请求操作系统标记代理事件没有被通过信号发送，因为没有满足特定条件和/或限制。操作系统又可以通知请求过代理事件的应用（例如，经由诸如图1所示前台组件105的“BG状态”接口之类的API函数），尽管并不要求这样的通知。

尽管在上面结合图5至图7描述了代理和代理功能性的具体示例，但应理解到的是，本公开内容的各方面并不限于具有代理基础架构和多个代理的构架的使用，也不限于在代理基础架构和各个代理之间责任的任何特定划分。例如，在备选实施例中，可以通过代理基础架构实现这里描述的代理功能性的任意适当子集。在一个示例中，代理基础架构可以跟踪代理事件与请求代理事件的应用之间的关联性，使得应用和/或代理可以从代理基础架构获得该信息。这可以作为保持这种信息的方式来完成。在另一示例中，可以对代理基础架构进行编程以锁存触发器和/或监视相关联的条件以便确定何时通过信号发送代理事件。以此方式，应用能够请求针对其由不同代理实现一些触发器和/或条件的代理事件，因为代理基础架构能够管理来自多个单个代理的状态信息。此外，在其中代理基础架构操控条件的监视的实现中可以便于模块化开发，因为各个代理不再需要“明白”或处理条件。

图8A示出了根据一些实施例的可以通过代理基础架构（BI）或者某其它适当操作系统组件执行以将后台组件与代理事件相关联的说明性进程800。图8B示出了可以结合进程800使用的说明性数据结构850。由进程800创建的关联性可以允许操作系统响应于通过信号发送的代理事件来加载和执行后台组件。在一个示例中，进程800可以由图4所示的代理基础架构405执行。然而，本公开内容的各方面并不限于使任何特定的操作系统组件来执行关联进程。在一些备选实施例中，负责通过信号发送代理事件的代理可以将后台组件与代理事件相关联，例如，作为用于响应于来自应用的请求来建立代理事件的进程的一部分。

在动作805处，BI可以接收对于将诸如工作项之类的后台组件与代理事件相关联的请求。该请求可以从任何适当实体接收，因为本公开内容的各方面并不限于此。例如，在一些实施例中，应用可以提交这样的请求以便执行后台组件来完成应用的后台工作。在一些其它实施例中，例如当应用请求来自代理的代理事件时或者当安装或更新应用时，负责通过信号发送代理事件的代理可以代表应用而提交这样的请求。

在动作810处，BI可以例如在图8B所示的说明性数据结构850中与代理事件ID相关联地存储后台组件ID。在该实施例中，数据结构850可以包括多个条目，每个条目对应于代理事件并且具有至少两个字段：用于存储代理事件ID的字段855和用于存储后台组件ID的字段860。例如，在第一说明性条目中，代理事件ID“BE₁”与后台组件ID“ObjectActivationClass₁”相关联，这可以识别实现后台组件的软件对象。尽管未示出，但数据结构850中的条目可以具有附加字段，例如用以存储指示可以从中加载后台组件的存储位置的信息和/或可以允许BI实施一个或更多个在管理后台组件时的资源管理策略的信息。在一个示例中，BI可以存储请求执行后台组件的应用的标识，使得当管理后台组件时BI可以实施可应用于应用的策略。在另一示例中，例如，BI可以存储由负责通过信号发送代理事件的代理指明的约束，如上面结合图5的动作545讨论的那样。

图9示出了根据一些实施例的可以由代理基础架构（BI）组件或者某其它适当操作系统组件执行以确定何时执行后台组件以及如何管理后台组件的执行的说明性进程900。例如，进程900可以由图4所示的BI组件405执行。

在动作905处，BI可以检测由代理通过信号发送的代理事件。响应于检测到通过信号发送的代理事件，BI在动作910处可以识别将要执行的一个或更多个相关联的后台组件。这可以例如通过访问诸如图8B所示那样的数据结构来完成。例如，BI可以识别数据结构850中在“代理事件ID”字段855中存储通过信号发送的代理事件的一个或更多个条目。如果识别多个这样的条目，BI可以逐一地处理这些条目。

针对匹配通过信号发送的代理事件的每个条目，BI可以在动作915处检查是否可应用和满足任何约束和/或限制。如上面结合图5的动作545讨论的那样，约束可以是由代理传送给BI以帮助BI管理与通过信号发送的代理事件相关联的资源的专用资源管理规则。另一方面，限制可以捕获由BI实施的任意资源管理策略。这些策略尽管不是必须但可以与各个代理实施的那些策略重叠。在一些实现中，BI可以为通用操作系统组件（与可以特别适于管理具体类型的资源的代理相比）并且能够施加与资源管理的多个方面有关的总体限制。

在一个示例中，BI可以对可以为后台工作执行分配多少处理器时间来施加限制，例如，形式为每天或某其它适当时间段的处理器时间百分比或者特定处理器时间量。该限制可以始终施加或者仅在特定情形下（诸如当系统依靠电池运行时）施加。在另一示例中，基于应用与用户相处的“面对时间”多少，即，相对于其它应用而言用户多么频繁地使用该应用（例如，形式为用户与应用交互所花费的实际时间的百分比或者由应用的前台组件使用的处理器时间的百分比），BI可以向该应用分配后台执行预算的百分比。在又一示例中，如果用户在长时间内（例如，在诸如一个月、两个月、三个月等的所选阈值时间长度上）还没有运行任何相关联的前台组件，则BI可以防止运行后台组件。

如果满足所有可应用的约束和BI限制，则BI可以进行到动作920以加载和执行后台组件。否则，BI可以进行到动作935，以向对应的前台组件报告失败。在一些实施例中，该报告可以识别失败的一个或更多个原因，所以前台组件可以采取合适动作，诸如促使用户批准对于违背的约束或BI限制的豁免。

如果BI在动作915处确定满足所有可应用的静态约束和BI限制并且在动作920处启动后台组件，则BI可以在动作925处监视在后台组件执行的同时是否满足所有可应用的动态约束和BI限制。动态BI限制的示例包括但不限于，对后台组件相对于其它后台组件可以使用多少处理器时间（即，形式为针对后台执行分配的处理器时间预算的百分比）以及后台组件将朝向完成进展的最小速率的限制。

如果在执行期间违背任何动态约束或BI限制，则可以在动作930处停止后台组件，并且BI可以继续到动作935以报告完成后台组件的执行的失败。同样，在一些实施例中，该报告可以识别失败的原因，所以前台组件可以采取合适的动作。如果在执行期间未违背动态约束或BI限制，则后台组件可以完成并且BI可以继续到动作935以报告后台组件的成功完成。然而，应理解到的是，这里描述的用于管理后台组件的各种技术可以用来管理不具有前台组件的应用，诸如在任意类型的计算设备上运行的后台服务。

应理解到的是，在一些实施例中，可以通过操作系统来施加上面结合图4至图9描述的各种代理执行模型，以管理后台工作的执行，而不是前台工作的执行，由此导致前台工作和后台工作的区别管理。然而，在备选实施例中，也可以使用代理执行来管理前台工作，例如用以控制资源消耗。例如，可以由响应于用户输入而通过信号发送的代理事件引起前台工作的执行。然而，在这样的实施例中，用户可以感知由在代理执行模型中应用的资源管理机制的一个或更多个层而引起的更多迟缓。因而，在决定是否针对前台工作使用代理执行时，可以在保留资源和维持激活的前台组件的响应度之间进行折衷。

图10示意性地示出其上可以实现本公开内容的各种创新方面的说明性计算机1000。例如，计算机1000可以是其上可以实现这里描述的任意特征的移动设备。

如这里所使用的，“移动设备”可以是足够小以使得可以由用户携带（例如，在用户的手中握持）的任何计算设备。移动设备的示例包括但不限于移动电话、寻呼机、便携式媒体播放器、电子书阅读器、手持游戏机、个人数字助理（PDA）和平板电脑。在一些情况下，移动设备的重量最多可以为一磅、一磅半或两磅，并且/或者移动设备的最大尺寸最大可以是6英寸、9英寸或1英尺。附加地，移动设备可以包括使得用户能够在各种位置使用设备的特征。例如，移动设备可以包括功率存储装置（例如，电池）使得它可以在某时段内被使用，而无需插到电源插座中。作为另一示例，移动设备可以包括被配置用于提供网络连接的无线网络接口，而无需实际地连接到网络连接点。

在图10所示的示例中，计算机1000包括处理器或处理单元1001以及可以包括易失性和/或非易失性存储器的存储器1002。除了系统存储器1002之外，计算机1000也可以包括存储装置1005（例如，一个或更多个硬盘驱动器）。存储器1002可以存储一个或更多个指令以对处理单元1001进行编程以执行这里描述的功能中的任意功能。存储器1002也可以存储一个或更多个应用程序和/或应用编程接口（API）函数。

计算机1000可以具有一个或更多个输入设备和/或输出设备，诸如图10所示的设备1006和1007。这些设备可被用来尤其是提供用户接口。可以用来提供用户接口的输出设备的示例包括用于输出的视觉呈现的打印机或显示器屏幕以及用于输出的音频呈现的扬声器或其它声音生成设备。可以用于用户接口的输入设备的示例包括键盘和诸如鼠标、触摸板和数字面板之类的指示设备。作为另一示例，计算机可以通过语音识别或其它音频格式接收输入信息。

如图10所示，计算机1000也可以包括一个或更多个网络接口（例如，网络接口1010）以经由各种网络（例如，网络1020）实现通信。网络的示例包括局域网或广域网，诸如企业网络或因特网。这样的网络可以基于任何适当技术，并且可以根据任何适当协议进行操作并且可以包括无线网络、有线网络或光纤网络。

虽然已经如此描述了本发明的至少一个实施例的若干方面，但将理解到的是，各种变更、修改和改进对于本领域技术人员而言将是容易想到的。

这样的变更、修改和改进被预期作为本公开内容的一部分，并且预期落入本发明的精神和范围内。此外，虽然表明了本发明的优势，但应理解到的是，不是本发明的每个实施例都将包括每个描述的优势。一些实施例可以不实现这里以及在一些情况中描述为有利的任何特征。因此，前述描述和附图仅是通过示例的方式给出的。

本发明的上述实施例可以按照多种方式中的任意方式实现。例如，可以使用硬件、软件或其组合实现实施例。当在软件中实现时，可以在任何适当处理器或处理器集合上执行软件代码，不管软件代码提供在单个计算机中还是分布在多个计算机上。这样的处理器可以实现为集成电路，其中在集成电路组件中具有一个或更多个处理器。但是，可以使用任何适当格式的电路系统实现处理器。

此外，应理解到的是，计算机可以按照大量形式中的任意形式实施，诸如机架安装式计算机、桌面型计算机、膝上型计算机或平板电脑。附加地，计算机可以在通常不认为是计算机但具有适当处理能力的设备中实施，这样的设备包括个人数字助理（PDA）、智能电话、收银机、自动提款机（ATM）或任何其它适当的便携式或固定电子设备。

同样，这里概述的各种方法或进程可以编码为软件，该软件可以在采用各种操作系统或平台中的任一种操作系统或平台的一个或更多个处理器上执行。附加地，这种软件可以使用大量适当编程语言和/或编程或脚本工具中的任一种编写，并且可以编译为在构架或虚拟机上执行的中间编码或可执行机器语言编码。

在这方面，本发明可以实施为编码有一个或更多个程序的计算机可读存储介质（或多个计算机可读介质）（例如，计算机存储器、一个或更多个软盘、压缩盘（CD）、光盘、数字视频盘（DVD）、磁带、快闪存储器、现场可编程门阵列或其它半导体器件中的电路配置、或者其它有形计算机存储介质），该一个或更多个程序当在一个或更多个计算机或其它处理器上执行时执行实现上面讨论的本发明的各种实施例的方法。如从前述示例中明白的那样，计算机可读存储介质可以将信息保持足够时间以按照非暂时性方式提供计算机可执行指令。这样的计算机可读存储介质是可移动的，从而可以将存储在其上的程序加载到一个或更多个不同的计算机或其它处理器上来实现如上所述本发明的各个方面。如这里所使用的，术语“计算机可读存储介质”只涵盖可以被视为制品（即，制造的物品）或机器的计算机可读介质。备选地或附加地，本发明可以实施为除了计算机可读存储介质之外的诸如传播信号之类的计算机可读介质。

这里在通用意义上使用术语“程序”或“软件”来指代可以用来对计算机或其它处理器进行编程以实现如上所述本发明的各个方面的任何类型的计算机代码或计算机可执行指令集合。附加地，应理解到，根据本实施例的一个方面，当执行时实现本发明方法的一个或更多个计算机程序不需要驻留在单个计算机或处理器上，而可以按照模块化方式分布在多个不同的计算机或处理器之中来实现本发明的各个方面。

计算机可执行指令可以为许多形式，诸如由一个或更多个计算机或其它设备执行的程序模块。通常，程序模块包括执行特定任务或实现特定抽象数据类型的例行程序、程序、对象、组件、数据结构等。典型地，程序模块的功能性可以在各种实施例中根据期望进行组合或分布。

同样，数据结构可以按照任何适当形式存储在计算机可读介质中。为图示简便起见，可以将数据结构示出为具有通过数据结构中的位置相关的字段。这种关系类似地可以通过利用传递字段之间关系的计算机可读介质中的位置来为字段指派存储装置而实现。然而，可以使用任何适当机制来建立数据结构的字段中的信息之间的关系，包括通过建立数据元素之间关系的指针、标签或其它机制的使用。

本发明的各个方面可以单独地、组合地或者按照未在前面描述的实施例中具体讨论的各种布置来使用，并且因此并不限于将其应用于前述描述中阐述或者附图中图示的组件的细节和布置。例如，在一个实施例中描述的方面可以按照任何方式与在其它实施例中描述的方面组合。

同样，本发明可以实施为已经为其提供示例的方法。可以按照任何适当方式来对实现为该方法一部分的动作进行排序。因此，即使在图示实施例中示出为顺序动作，也可以构造如下实施例，其中按照与所图示不同的顺序执行动作，这也可以包括同时执行一些动作。

在权利要求中使用诸如“第一”、“第二”、“第三”等的序数词来修饰权利要求要素，其本身并不暗示任何优先级、先后次序或一个权利要求要素相对于另一个权利要求要素的顺序或者其中执行方法动作的时间顺序，而是仅用作标注以将具有特定名称的一个权利要求要素与具有相同名称（但使用序数词）的另一要素区分开从而区分权利要求要素。

同样，这里使用的用语和术语用于描述的目的，不应被视为限制性的。这里“包括”、“包含”或者“具有”、“含有”、“涉及”及其变形的使用意味着涵盖之后列出的项和其等同方案以及附加项。

Claims

1.一种控制在被执行时消耗资源的后台组件进行的资源消耗的方法，所述方法包括：

检测触发器的发生；

基于包括与一个或多个注册的触发器对应的一个或多个条目的数据结构识别与所述触发器相关联的代理事件；

确定是否满足针对所述代理事件指明的一个或多个条件；

响应于确定满足所述一个或多个条件，确定是否满足可应用于所述代理事件的一个或多个代理限制；以及

响应于确定满足所述一个或多个代理限制，通过信号发送所述代理事件，其中所述后台组件响应于所述信号发送而被执行。

2.根据权利要求1所述的方法，包括：

识别应用的前台组件；以及

识别所述后台组件，所述后台组件与所述应用相关联并且不同于所述前台组件。

3.根据权利要求2所述的方法，包括：

响应于用户动作加载所述前台组件。

4.根据权利要求2所述的方法，包括：

在受控执行环境中加载所述后台组件，由此将所述后台组件与所述前台组件隔离。

5.根据权利要求1所述的方法，所述方法的至少部分由操作系统执行。

6.根据权利要求1所述的方法，所述触发器包括有关网络活动的事件、有关用户活动的事件、调度事件或有关外围设备的事件中的至少一个。

7.根据权利要求1所述的方法，所述后台组件包括动态链接库（DLL）。