CN102880505A

CN102880505A - 用于后台工作执行的事件聚合

Info

Publication number: CN102880505A
Application number: CN2012103174538A
Authority: CN
Inventors: J.A.小施瓦茨; A.U.基尚; R.K.涅夫斯; D.B.普罗伯特; H.普拉帕卡; A.F.格夫劳特
Original assignee: Microsoft Corp
Current assignee: Microsoft Technology Licensing LLC
Priority date: 2011-09-01
Filing date: 2012-08-31
Publication date: 2013-01-16
Anticipated expiration: 2032-08-31
Also published as: WO2013032504A1; EP2751674B1; EP2751674A1; EP2751674A4; US20130061251A1; ES2736252T3; US9063775B2; CN102880505B

Abstract

用于单独地管理后台工作和前台工作的系统、方法和设备。在某些实施例中，操作系统可识别相同应用或不同应用的至少一个前台组件和至少一个后台组件，且可不同地管理这些组件的执行。例如，操作系统可接收响应于至少一个事件来执行应用的至少一个后台组件的请求。响应于检测到至少一个事件的发生，该操作系统可确定是否满足了由该应用所设置的至少一个第一条件且是否满足了由操作系统设置的至少一个第二条件，且可在发生了至少一个事件之后确定满足了至少一个第一条件和第二条件来执行至少一个后台组件。

Description

用于后台工作执行的事件聚合

背景技术

常规操作系统实施几种不同执行模式来管理应用的前台工作和后台工作。可认为是前台工作的处理任务的例子包括(但不限于)响应于用户输入来呈现图形用户界面和与用户交互有关的任何其它类型的工作。可认为是后台工作的处理任务的例子包括(但不限于)下载和安装软件更新，与服务器同步和可不涉及到用户注意力的任何其它类型的工作。

在第一模型中，可允许任意数量的应用来在后台和前台这两者中并发执行并竞争资源，诸如处理器周期和存储器。这个模型通常实施于台式机和膝上型计算机上。

在第二模式中，所有应用被阻止执行，除了“活动”应用之外，“活动”应用即用户主动与之交互的应用。这种模型通常实施于移动设备上，其中在任何特定时间，用户通常与在全屏上显示的单个应用交互。

在第三模型中，针对相同应用的前台工作和后台工作被对待为互斥的，使得在前台中执行的应用并不安排同时做任何后台工作，且反之亦然。

在第四模型中，应用可单独地实例化（instantiated）用于前台工作和后台工作，且两个实例并发执行并竞争资源。

发明内容

前文为本发明的非限制性总结，本发明由所附权利要求限定。

发明人已经认识且意识到从现有操作系统执行模型中出现的若干缺点，且已经开发了新的执行模型，新的执行模型提供诸如改进的电池寿命和用户体验之类的优点。

在某些实施例中，操作系统可单独地加载相同应用或不同应用的前台工作和后台工作，且在做出安排决策时可不同地对待前台工作和后台工作。例如，应用组件可被指定为前台组件或后台组件，使得操作系统可基于组件的指定而向组件应用不同的策略。策略可被设计为在向用户提供丰富的多任务体验的同时促进资源的高效使用。

在一些另外的实施例中，操作系统可基于应用所提供的、规定预期执行后台工作的特定情况的信息来确定何时执行后台工作。但是，操作系统可尽力试图不考虑应用的规定以防止后台工作消耗太多功率和/或影响活动的应用的响应性。

在一实施例中，提供了一种供在至少一个计算机上执行的操作系统使用的方法。该方法包括以下动作：识别应用的至少一个后台组件；确定是否满足了至少一个条件；以及仅在确定出满足了至少一个条件时执行至少一个后台组件。

在另一实施例中，提供至少一个计算机可读介质，其上至少编码：实施应用的至少一个前台组件的至少一个第一条计算机可执行代码；规范（specification），其识别用于执行应用的后台工作的至少一个第二条计算机可执行代码；以及用于向操作系统规定在开始后台工作之前要满足的至少一个条件的至少一个第二条可执行代码。

在又一实施例中，提供一种计算机实施的方法，其包括动作：在操作系统处接收响应于至少一个事件执行应用的至少一个后台组件的请求；响应于检测到所述至少一个事件的发生来由操作系统确定是否满足了由应用设置的至少一个第一条件且确定是否满足由操作系统设置的至少一个第二条件；以及在发生了至少一个事件之后确定了满足了至少一个第一条件和第二条件时执行至少一个后台组件。

应了解前述概念和下文更详细地讨论的附加概念的所有组合(假设这样的概念并非相互不一致)被预期为本文所公开的发明主题的部分。特别地，在本公开的尾部出现的要求保护的主题的所有组合被预期是本文所公开的发明主题的部分。

附图说明

附图未必按照比例绘制。

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

图2示出了根据某些实施例用于具有能并发执行的前台组件和后台组件的应用的说明性状态图。

图3A示出了根据某些实施例操作系统在单独进程（process）中加载前台组件和后台组件的例子。

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

图4示出了根据某些实施例适于单独地管理后台工作和前台工作的操作系统的例子。

图5为根据某些实施例可由代理（broker）组件响应于安排代理事件的请求而进行的说明性过程的流程图。

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

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

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

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

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

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

具体实施方式

例如，允许任何数量的应用并发执行的第一执行模型可导致竞争诸如处理器周期和存储器的资源的太多的进程。而这可能在资源受限的环境中导致迟缓的性能，诸如在具有有限处理速度和存储器的移动设备上。如果移动设备靠电池电力运行，那么不加区别地执行进程也可导致缩短的电池寿命。

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

第三执行模型，即以互斥方式执行同一应用的前台工作与后台工作，可同样排除所希望的多任务处理情形，诸如用户一边等待网络下载完成一边经由网络浏览器来阅读一个网页。

虽然单独实例化的第四执行模型可允许操作系统并发执行同一应用的后台工作和前台工作，但仍存在多种可能的缺陷。例如，可能要太多地依赖应用开发人员写出以与前台-后台区别一致的方式表现的代码。即使应用并不暴露呼叫参数来允许操作系统指示应用是否实例化用于前台工作或后台工作，开发人员也有可能无意中忽略在应用被实例化用于前台工作时防止后台工作执行的程序逻辑，或反之亦然。这可能会破坏操作系统有效地控制后台工作的资源消耗的能力，因为操作系统可能难以确定声称的前台实例是否仅执行前台工作(例如，响应于经由用户界面接收的输入)且不执行任何不必要的或低效的后台工作(例如，与服务器周期性地同步)。

单独实例化（instantiation）方案也可给应用开发人员带来处置与并发执行有关的复杂性的负担。例如，当同一应用的前台实例和后台实例并发执行时，两个实例可在不同的情境中执行且可不共享状态。因此，这两个实例能仅通过由操作系统明确地提供的机制（mechanism）来通信，这可能使得程度代码复杂。发明人已经认识到且意识到当想要后台工作与前台工作之间的这样的去耦时，也可需要给予开发人员不支持多个实例在不同情境中并发执行的选项。

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

在一个方面，用于前台工作和后台工作的应用逻辑可以一定方式去耦以便允许操作系统单独地加载前台工作和后台工作，且在做出安排决定时不同地对待前台工作和后台工作。

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

例如，可针对后台组件实施一个或多个资源管理策略。这些策略可被设计成基于后台组件所用的资源来限制何时执行后台组件。实施这样的策略可帮助保存能量和/或保留充分的资源用于活动的应用(即，用户主动地与之交互的应用)。这样的策略可(尽管不需要)通过在受控制的执行环境中执行后台组件来实施，受控制的执行环境例如本领域中已知的沙箱（sandbox），从而隔离后台组件与前台组件。

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

在某些实施例中，前台组件和后台组件可在能彼此独立地执行的单独可执行代码片段中提供。在一些另外的实施例中，前台组件和后台组件可具有不同入口点，使得操作系统可将前台组件和后台组件加载于相同的进程中但在不同的线程中，从而允许前台组件和后台组件以共享状态一起执行。以此方式，操作系统仍能区分与后台工作相关联的执行线程和与前台工作相关联的执行线程，而不需要应用处置在不同进程中并发执行的各种复杂性。

如果应用确实支持并发执行，则操作系统能选择将前台组件和后台组件加载于相同进程或单独进程中。在这些选项之间做选择时可考虑多种因素。例如，如上文所讨论的那样，分开后台工作与前台工作可允许操作系统在经受某种资源限制的指定环境(例如，构建成主管（host）后台组件的沙箱)中运行后台工作。而且，分开后台工作与前台工作可减小存储器占用，因为当应用仅执行后台工作时无需加载仅与用户界面(UI)功能有关的可执行代码(例如库)。另一方面，如果应用频繁执行后台工作或者如果一个或多个用户频繁地与应用交互，则可有利地将前台工作与后台工作共置于同一进程中以便在前台组件与后台组件之间共享进程启动成本。但是，操作系统也能通过在单独的环境(例如软件容器)中执行后台工作且高速缓存该环境来降低进程启动成本。

在又一方面，操作系统可基于应用所提供的、规定预期执行后台工作所处的特定情形的信息来确定何时执行后台工作。例如，在某些实施例中，操作系统可响应于一个或多个规定的事件(也被称作“触发”)来安排仅后台工作执行。触发的例子包括但不限于与网络活动有关的事件(例如，从网络到达的包)、与用户活动有关的事件(例如，用户登陆或退出)、预定的事件（例如定时器到期）、与外围设备(例如，打印机通知)有关的事件等。

在一些另外的实施例中，关于何时执行后台工作，操作系统可不考虑（override）应用规范。例如，操作系统可充当“代理”，其过滤预期触发后台工作的事件。在这样的“代理的执行”模型中，应用可向操作系统注册一个或多个触发以使得后台组件执行，例如以进行后台工作的某单元(也被称作“后台任务”或“工作项目”)。并非让这种触发直接造成后台组件的执行，操作系统可引入做出决策的附加层。例如，当应用指定的触发激发时，操作系统可决定是否发信号通知所谓的“代理事件”，而这又会造成后台组件执行。以此方式，操作系统可最终决定何时执行后台组件。例如，电子邮件客户端可注册周期性(例如，每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状态”接口)来这样做。这样的报告机制可允许前台组件和后台组件一起工作来向用户提供单个统一的体验。作为具体例子，当后台组件从服务器下载电子书时，当用户启动前台组件时，下载进展（progress）可经由相对应的前台组件而传送给用户。

去耦的另一说明性方案是避免对共享数据直接操作，这可降低数据损坏的可能性。例如，在一个实施例中，前台组件和后台组件可使用针对某些或所有数据通信的持久存储来降低数据损坏的可能性。在某些另外的实施例中，前台组件和后台组件可对共享对象操作，诸如图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，前台组件驻存在存储器中或者活动的分页文件（paging file）中且由操作系统安排来执行。在暂停状态210，前台组件仍驻存在存储器中或者活动的分页文件中且不再由操作系统安排来执行。在非运行状态215，前台组件不再驻存在存储器中，也不在任何活动的分页文件中。

另一方面，在图2中所示的说明性生命周期250中，后台组件可处于两种不同状态之一：运行状态255和非运行状态260。在运行状态255，后台组件驻存在存储器中或者分页文件中且由操作系统安排来执行。在非运行状态260中，后台组件不再驻存在存储器中，也不在任何分页文件中。可替换地，后台组件可在宿主环境(例如，容器)中执行且当后台组件移到非运行状态260时，宿主环境可被高速缓存。

因此，在此例子中，包括前台组件和后台组件的整个应用可具有六个不同的状态：<前台活动，后台运行>，<前台暂停，后台运行>，<前台非运行，后台运行>，<前台活动，后台非运行>，<前台暂停，后台非运行>和<前台非运行，后台非运行>。在前台组件和后台组件移动经过其相应生命周期时，应用整体上可移动经过这六个状态，这在下文中更详细地描述。在最后的状态中，<前台非运行，后台非运行>，应用可被认为终止，因为应用既不在前台中运行也不在后台中运行。

如上文所提到的那样，由于前台组件和后台组件在逻辑上去耦，操作系统可能将一个组件从一个状态移到另一个状态，无论另一组件的状态如何且不会影响到另一组件。例如，在某些实施例中，前台组件可从活动状态移到暂停状态或者从暂停状态移到活动状态，而无论后台组件的状态如何且不会影响后台组件的状态。作为更具体的例子，当前台组件从活动状态205移到暂停状态210时，应用整体上可从<前台活动，后台运行>移到<前台暂停，后台运行>或者从<前台活动，后台非运行>移到<前台暂停，后台非运行>，这取决于后台组件是处于运行状态255还是非运行状态260。

应意识到，虽然前台组件和后台组件可以以逻辑上去耦的方式来实施，操作系统可(尽管不需要)使用关于前台组件的执行的信息来管理后台组件的执行，或反之亦然。例如，在一些实施例中，操作系统可仅在前台组件暂停或不运行时安排后台组件执行。总之，使得前台组件与后台组件在逻辑上去耦可给予操作系统在组件的执行之间创建依赖性或不创建依赖性的选项。

现转至图2中所示的说明性生命周期200，操作系统可采用任何合适规则组来确定何时将前台组件从一个状态移到另一状态。这样的规则可被设计成防止未得到用户关注的前台组件消耗诸如电池电力、处理器周期和存储器之类的资源。实施这些规则可改进电池寿命和/或得到用户关注的前台组件的响应性。在一个例子中，操作系统可将未得到用户关注的前台组件从暂停状态移到非运行状态以收回存储器资源。

在一些实施例中，前台组件可最初处于非运行状态且操作系统可响应于用户动作(例如，用户点击对应于该应用的图标或图片)来起动前台组件。起动前台组件可涉及将前台组件和前台组件可访问的任何辅助组件加载到存储器中、初始化前台组件和/或分配适当资源。如果应用的后台组件已经在起动前台组件时运行且前台组件加载到与后台组件相同的进程中，则某些辅助组件可已经加载且某些资源可已经分配。否则，可执行完全启动。在任一事件中，前台组件可在活动状态205中起动，且可由操作系统安排来执行。

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

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

在一些实施例中，当用户不再与该前台组件主动交互时，操作系统可将前台组件从活动状态205移到暂停状态210。这例如在用户将注意力切换到不同应用的窗口、最小化前台组件的窗口、在某阈值时段内未向该前台组件提供任何输入等时发生。可替换地或作为补充，当前台组件不再执行可认为是前台活动的任何活动时，操作系统可将该前台组件从活动状态205移到暂停状态210。可认为是前台活动的活动的例子包括(但不限于)音频播放、设备同步等。

在将前台组件从活动状态205移到暂停状态210之前，操作系统可向前台组件告知前台组件将要暂停，所以前台组件可相应地做出准备，例如通过保存状态和释放分配的资源。例如，操作系统可通过调用前台组件所提供的应用编程接口(API)函数来告知前台组件。在如图1和图2中所示的一个更具体的例子中，操作系统可调用前台组件实现的所谓“静默”方法，其可使前台组件保存状态和释放资源(例如，文件、网络连接等)。在某些实施方式中，静默方法可包括操作系统代码以明确地阻止调用静默方法的线程(即，前台组件的线程)被安排执行。可作为使得整个前台组件整体上暂停(例如，禁止对其做出安排)的补充来这样做。前台组件可保持阻止直到操作系统将前台组件移回到活动状态205。

在一些实施例中，当用户例如通过将关注切回到前台组件的窗口、将前台组件的窗口从最小化状态恢复、开始向前台组件提供输入等开始再次与前台组件交互时，操作系统可将前台组件从暂停状态210移回到活动状态205。这样一来，操作系统可简单地安排该前台组件执行。在一些实施例中，操作系统可附加地调用前台组件提供的API函数以辅助该前台组件恢复先前状态。更具体而言，在图1和图2中所示的例子中，操作系统可调用由该前台组件实现的“重新开始”方法，其可使前台组件取回所保存的状态并请求适当资源(例如，文件、网络连接等)。

在一些另外的实施例中，操作系统可通过将前台组件从存储器移除来将前台组件从暂停状态210移到非运行状态215。这样做可例如减小存储器使用或者允许更新该前台组件的可执行代码。如果在操作系统将该前台组件移到非运行状态215时该应用并不运行在后台中，应用可变得完全终止。否则，后台组件可继续运行，而不论前台组件改变状态。

如果在前台组件已移到非运行状态215时用户开始再次与前台组件交互，则操作系统可再次起动该前台组件，这可类似于最初起动该前台组件，如上文所讨论的那样。

应意识到，操作系统可选择任何合适的规则组和技术来确定何时将前台组件从活动状态205移到暂停状态210和何时将前台组件从暂停状态210移到非运行状态215。这些规则可反映出与暂停前台组件相关联的预期益处和预期成本之间所希望的平衡，和与将前台组件从存储器移除相关联的预期益处与预期成本之间的所希望的平衡。例如，虽然暂停前台组件可导致某些资源节省，可由前台组件准备暂停和从暂停重新开始造成附加的处理开销。而且，当前台组件首先从暂停重新开始且试图重新获得资源(例如，重新打开文件，再建立网络连接等)时用户可体验到迟缓（sluggishness）。同样，虽然从存储器移除前台组件可减少存储器使用，但前台组件的重新起动可以造成附加的处理开销，并且在前台组件重新加载或重新初始化时用户可以体验到迟缓。

转至图2中所示的说明性生命周期250，后台组件可最初处于非运行状态260。操作系统可在某些实施例中响应于检测到一个或多个事件的发生来起动该后台组件。如在下文中结合图5至图7更详细地讨论的那样，在一些说明性实施例中，在确定何时起动后台组件时可考虑两种类型的事件(即，触发和条件)。

起动后台组件可涉及将后台组件和后台组件可访问的任何辅助组件加载到存储器中、初始化后台组件和/或分配适当的资源。如果应用的前台组件已经在起动后台组件时运行且后台组件加载到与前台组件相同的进程中，则某些辅助组件可已经被加载且某些资源可已经被分配。否则，可执行完全启动。在任一事件中，后台组件可移到运行状态255。

一旦后台组件从存储装置（storage）加载，操作系统就可通过调用后台组件所提供的API函数来执行后台组件的入口点功能以初始化后台组件。在如图1至图2所示的更特定的例子中，操作系统可调用由后台组件实施的所谓的“起动(Start)”方法。

在一些实施例中，操作系统可在起动了后台组件之后监视该后台组件的进展。某些后台组件(例如，图1所示的工作项目110A、110B、110C……)每一个可对应于离散的后台任务(例如，从服务器下载一条内容，检查软件更新的可用性，例程病毒扫描等)。照此，这些后台组件不预期无限期地执行。如果后台组件在运行了某阈值时段后并未做出充分进展，则操作系统可停止该后台组件执行，从而将后台组件移到非运行状态260。

操作系统可使用监视计算任务进展的任何已知的技术来监视后台组件的进展。可替换地或作为补充，应用可提供一个或多个工具供操作系统用于监视进展。例如，后台组件可实现操作系统可调用的“检查进展”接口以得到进展信息(例如，任务完成的百分比和/或后台组件是否等待来自另一组件的响应或者等待某些资源变得可用)。此接口可在与应用相关联的规范中规定，诸如图1中所示的规范120。

在一些实施例中，操作系统可向该后台组件告知该后台组件将要停止，因此后台组件能相应地做出准备，例如通过保存状态和释放分配的资源。这可例如通过调用后台组件所提供的API函数来进行。更具体而言，在图1至图2所示的例子中，操作系统可调用后台组件实现的所谓的“取消”方法，之后，在操作系统将后台组件移到非运行状态260之前，可给予后台组件某小的时间量(例如，数秒)。

如果后台组件继续以充分速率取得进展，则操作系统可允许后台组件运行完成。在那种情况下，操作系统也可将后台组件移到非运行状态260，例如通过将后台组件从存储器去除。

如果在操作系统将该后台组件移到非运行状态215时该应用并不在前台中运行，则应用可变得完全终止。否则，前台组件可继续运行(例如，在活动状态205或者在暂停状态210)，而不考虑后台组件改变状态。

虽然在图2中示出且在上文中描述了应用组件生命周期的详细例子，应了解提供这些例子只是出于说明目的。本公开的各方面并不限于生命周期的任何限定，也不限于管理生命周期的任何特定方式。例如，前台组件可从图2中所示的那些状态来移动经过不同的状态集合，且操作系统可采用不同的策略来确定何时将前台组件从一个状态移到另一个状态且对于后台组件也类似。作为另一例子，操作系统可将相同后台组件或不同后台组件的一个或多个实例加载到相同的环境(例如，软件容器)中，且仅当这些实例中并无实例运行时可将该环境从存储器移除。作为又一例子，操作系统可保持后台组件无限期地加载以提高效率。

如上文所讨论的那样，在某些实施例中，如果前台组件和后台组件能以任一方式来执行，则操作系统可选择将应用的前台组件和后台组件加载到相同的进程或单独的进程中。在一个例子中，操作系统可默认将前台组件和后台组件加载到单独的进程中，除非应用或用户做出其它规定。在另一例子中，操作系统可加载由应用单独于相对应的前台组件所提供的后台组件，但是可将操作系统提供的后台组件与后台组件针对其而工作的应用共置。也可采用其它合适规则，因为本公开的各方面并不以此方式受限制。

图3A示出了其中操作系统305将在进程320中的前台组件310和在单独进程325中的后台组件315加载到存储器300内的例子。以此方式隔离后台工作与前台工作可方便资源管理。例如，在某些实施例中，操作系统可在受控制的执行环境(例如，如本领域中已知的沙箱)中运行该进程325，受控制的环境被构造为允许进程在其中运行以仅存取指定的资源。以此方式，操作系统可将某些规定量的资源(例如，某些规定的CPU时间、存储器的百分比等)分配给受控制的执行环境以确保后台组件315不消耗多于规定量的资源。受控制的执行环境可在某些实施方式中被指定用于运行后台组件使得其它应用的后台组件也可在沙箱中运行且受到相同的资源限制。

在单独的进程中隔离后台工作与前台工作也可帮助减少存储器占用，因为当应用仅执行后台工作时，操作系统可避免加载仅与用户界面(UI)功能有关的可执行代码(例如，库)。例如，在其中前台工作与后台工作被实施为单独组件的实施例中，UI相关的功能可仅存在于前台组件中，其无需加载于主管（host）后台组件的进程中。

图3B示出了其中操作系统355将同一进程370中的前台组件360和后台组件356加载到存储器350内的例子。以此方式共置前台工作和后台工作可允许前台组件360和后台组件365共担启动成本。因此，如果组件之一频繁运行，例如，如果一个或多个用户频繁地与该应用交互，或者如果该应用频繁地执行后台工作，那么将这些组件共置可以是有益的。

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

因此，在某些实施例中，操作系统可适于基于在易于实施的资源管理与降低的启动成本之间的所需权衡来决定共置还是分开前台组件和后台组件。其它考虑(例如，动态操作条件，例如存储器和/或处理器使用，活动进程的数量等)也可考虑在内，因为本公开的各方面并不限于共置或分开前台组件和后台组件的任何特定原因。在一个例子中，在决定在实施方式（在该实施方式中，可以通过在后台组件执行时保持前台组件中的某些或全部线程可运行来防止死锁）中共置还是分开前台组件和后台组件时可考虑存储器和/或处理器周期的消耗。在另一例子中，可以例如通过分开有程序缺陷的（buggy）后台组件来减少对其它前台组件和/或后台组件的干扰来考虑软件可靠性。

图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或某些其它代理之类的代理组件用信号通知的事件。每个这样的代理可适于在某些规定的情况下用信号通知事件。例如，时间代理415可适于在绝对时间、定期间隔（regular interval）或在与系统操作有关的某些“方便”时间(例如，用于执行任选活动的保持时间)用信号通知事件，当数据在网络套接字(network socket)上可用时，网络连接代理415B可适于用信号通知事件，远程唤醒代理415C可适于转发从一个或多个云服务器到达的事件，且系统事件代理415D可适于用信号通知诸如用户登陆或退出的事件。

在一些实施方式中，代理可提供接口(例如，图4所示的“请求”接口)，应用可通过该接口来请求代理在应用规定的某些情形下用信号通知代理事件。以此方式，应用可告知该操作系统计划何时运行后台组件。例如，如在下文中结合图5至图6更详细地讨论的，代理可允许应用在激发了一个或多个“触发”时请求用信号通知代理事件。此外，除了激发触发之外，应用还可规定在用信号通知代理事件之前要满足的一个或多个“条件”。

类似于代理基础结构405，代理在某些实施例中可例如经由一个或多个约束和/或限制实施一个或多个适当的资源管理策略。例如，在某些实例中，代理可不用信号通知代理事件，即使在激发了触发且满足了所有条件时，因为用信号通知代理事件可违反某些资源管理策略。作为更具体的例子，时间代理415A可限制每天代理事件的复发次数，从而请求代理事件的应用不在后台中每天执行超过该次数。

虽然在上文中讨论了代理的若干例子，应意识到这些代理只是说明性的。在各种实施例中，操作系统可包括适于实施合适资源管理策略的代理的任何合适的组合。这些策略中的某些可在性质上为静态的，例如通过规定在固定时间量应用可消耗的固定资源量。其它策略可为动态的且可基于操作条件对消耗施加限制(例如，系统是否靠电池来运行，CPU和/或存储器使用是否保持为高持续了一段时间等)。另外的策略可组合静态与动态方面。

再次返回至图4所示的例子，操作系统400附加地包括多个后台组件，例如工作项目410A，410B，410C…… 类似于图1所示的工作项目110A-C，工作项目410A-C可在后台中执行以为应用工作，且可由操作系统400以与应用提供的后台组件相同的方式管理。例如，操作系统400可对于工作项目410A-C实施与对于工作项目110A-C所实施的相同的资源管理策略。但是，在可替换实施例中，操作系统400可信任工作项目410A-C，但并不信任工作项目110A-C，因为工作项目410A-C 为操作系统400的部分，而工作项目110A-C包含应用提供的代码。因此，操作系统400可放松对工作项目410A-C实施的策略，因为工作项目410A-C是被信任的。例如，操作系统400可将工作项目110A-C加载到与前台组件分开的沙箱内，而可将工作项目410A-C加载到与相应前台组件相同的进程中。

同样，应意识到本公开的各方面不限于使用来自任何特定源的后台组件。后台组件在各种实施例中可由操作系统开发人员、应用开发人员和/或任何其它第三方软件提供商写出。

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

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

在动作510，代理组件可向所请求的代理事件分配代理事件ID。此代理事件ID可对于代理事件的每个请求是唯一的。例如，如果两个应用每个经由代理的API的不同调用而请求代理事件，那么代理可分配不同的代理事件ID，即使下面的触发是相同的。以此方式，当下面的触发激发时，代理可用信号通知两个不同的代理事件，每个代理事件具有不同的代理事件ID。

尽管并未要求，唯一的代理事件ID可为有益的，因为不同的应用可为代理事件规定不同的条件，即使触发是相同的。而且，可取决于特定应用而不同地采用由代理实施的一个或多个资源管理策略。因此，唯一的代理事件ID可用于确保适当的条件集合(无论是由相对应的应用施加还是由操作系统施加)被应用于控制用信号通知代理事件。

在动作515，代理可识别将响应之而用信号通知所请求的代理事件的一个或多个触发。触发可为代理被编程来检测的任何事件。在一例子中，触发可为用户相关的事件，诸如用户登录或退出、用户变得活动(例如，通过提供诸如键入、移动鼠标、讲话等任何输入)、用户变得不活动(例如，通过未在至少阈值时段提供任何输入)、用户开始用户会话、用户请求下载、用户初始化打印工作等。在另一例子中，触发可为与系统相关的事件，诸如定时器到期、消息或通知(例如，SMS消息或操作者消息通知)到达、网络状态的变化、网络信道复位、因特网变得可用或不可用、完成软件更新等。在又一例子中，触发可为与应用相关的事件，诸如应用请求立即用信号通知代理事件以使得操作系统立刻起动后台组件。在另一例子中，触发可为由操作系统组件(例如，代理)通过组合来自不同源的一个或多个事件的知识，一个或多个系统条件和/或一个或多个系统策略来创建的合成事件。这样的合成事件的具体例子可为“维持时间”，其可指示被指定用于维持的操作时段的开始。

虽然应用可规定请求的代理事件的一个触发，在某些实例中可规定多个触发。例如，代理可将触发对待为选项(alternatives)，使得倘若满足了任何和所有规定的条件，任一触发的激发可造成用信号通知所请求的代理事件。可替换地，代理可将某些或所有触发对待为合取项(conjuncts)，或者可允许应用规定触发的任何合适逻辑组合。在另外的一些实施例中，可提供多个代理，每个代理对于单个触发做出响应，且可一起实施多个触发的组合。

在动作520，代理可与在动作510分配的代理事件ID相关联地存储在动作515识别的一个或多个触发。触发可以以任何合适方式存储。在一些实施例中，每个触发可存储为触发配置和触发类型。作为另一例子，代理可在图6所示的说明性数据结构600中存储触发和代理事件ID。在此实施例中，数据结构600可包括多个实体，每个实体对应于所请求的代理事件且具有至少三个字段（field）：用于存储代理事件ID的字段605，用于存储触发的字段610和用于存储条件的字段615。例如，在第一说明性条目中，代理事件ID“BE₁”与多个可替换触发“E_1,1”、“E_1,2”……和单个条件“C_1,1”相关联。尽管未图示，数据结构600中的条目可具有附加字段，例如以存储可允许代理实施一个或多个资源管理策略的其它信息项。

返回至图5，在动作525，代理可确定是否规定了在用信号通知所请求的代理事件时要满足的一个或多个条件。如果规定了一个或多个条件，那么代理可继续在动作530识别条件。否则，代理可跳过动作530和535且直接前进到动作540。

如上文所述的那样，可由请求代理事件的应用来规定条件，例如以告知操作系统相关联的后台组件可能执行有用工作的一组情况。例如，用于从因特网下载内容的后台组件可以仅能够在到因特网的连接可用时执行有用工作。因此，应用可请求仅在因特网可用时用信号通知代理事件。

条件的其它例子包括(但不限于)与用户有关的条件(例如，用户为活动的或不活动的)，与系统有关的条件(例如，网络可用/不可用)，与应用有关的条件(例如，应用最近已经在例如由某阈值时间量确定的过去被用户主动地使用，应用未超过操作系统所准予的特定资源分配等)等等。

应用可规定任何数量的条件，因为本公开的各方面不限于对于代理事件所规定的任何特定数量的条件。例如，应用可规定一个或多个条件或者可不规定任何条件。代理可将条件对待为合取项，使得除非满足了所有规定的条件，否则不用信号通知所请求的代理事件，即使激发了相对应的触发。可替换地，代理将这些条件对待为选项，使得如果在激发相对应的触发时满足了所规定的条件中的任一条件，则可用信号通知所请求的代理事件。在一些另外的实施例中，代理可允许应用规定条件的任何合适的逻辑组合。

可替换地或附加地，操作系统或不同于请求代理事件的应用的应用(例如，小应用程序)也可规定一个或多个将与代理事件相关联的条件。例如，在一些实施例中，代理可实现操作系统或应用调用的接口以规定和/或修改与代理事件相关联的条件，例如通过提供在动作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-D之一来执行。

在动作705，代理可检测到触发激发。如上文所讨论的那样，这可包括从操作系统接收指示刚发生的某事的事件，诸如用户登录或退出，网络变得可用或不可用，定时器到期等。

响应于检测到触发器激发，代理可在动作707识别要用信号通知的一个或多个相关联的代理事件。这可例如通过存取诸如图6所示那样的数据结构来进行。例如，代理可识别在数据结构600中具有存储于“触发”字段610中的激发的触发的一个或多个条目。如果识别了多个这样的条目，代理可逐一处理条目。

对于匹配激发的触发的每个条目，代理可在动作710确定是否对于相对应的代理事件规定了任何条件，且若如此，确定是否满足了所有这样的条件。在一些实施例中，这可通过检查如图6所示的相对应“条件（一个或多个）”字段615且评估所有存储的条件来进行。在可替换实施例中，代理可对于每个存储的条件保持指示当前是否满足了所存储的条件的布尔变量和用于评估条件的任何辅助变量。代理可例如响应于在辅助变量中的变化来连续地更新布尔变量。以此方式，代理可简单地在动作710检查布尔变量，而无须再次评估条件。

如果满足了所有相关联的条件，或者如果无条件存储于字段615中，则代理可继续到动作715。否则，代理可在动作720锁存触发器并继续监视相关联的条件。在其中代理为每个存储的条件保持布尔变量的实施例中，监视条件可简单地包括继续更新布尔变量。如果且当在动作725对于相关联的条件中的一个或多个检测到变化时，代理可返回到动作710以检查是否满足了所有相关联的条件。代理可无限期地循环动作710、720和725，除非到了与锁存的触发相关联的预定期限，在此情况下，当预定期限到期时，代理可丢弃所锁存的触发。

如果在某点全部相关联的条件变得满足，代理可在动作715检查任何代理限制是否适用于代理事件且若如此，检查是否满足了适用的代理限制。如上文所讨论的那样，代理可实施一个或多个资源管理策略且可避免用信号通知代理事件，即使在激发了触发且满足了所有应用规定的条件时，作为控制应用的资源消耗的方式。代理限制可为用于实施这些资源管理策略的机制。在一个例子中，可对于单个应用使用代理所管理的资源的的频率施加限制(例如，在每天或某些其它合适的时段的次数或者在该时段内已经由自该应用或整个系统的后台活动消耗了多少管理的资源)。也可规定其它类型的代理限制，因为本公开的各方面并不限制任何特定类型的代理限制。

如果满足了所有适用的代理限制，则代理可在动作720用信号通知代理事件，否则代理可简单地丢弃所激发的触发。在某些实施例中，代理可请求操作系统标记因为并未满足某些条件和/或限制而未用信号通知代理事件。操作系统又可通知该应用所请求的代理事件(例如经由API函数，诸如在图1所示的前台组件105的“BG状态”接口)，尽管这样的通知并非必需的。

尽管结合图5至图7在上文描述了代理和代理功能的具体例子，应意识到本公开的方面不限于使用具有代理基础结构和多个代理的框架，也不限于在代理基础结构与个体代理之间的责任的任何具体划分。例如，在可替换实施例中，本文所述的代理功能的任何合适子集可由代理基础结构来实施。在一个例子中，代理基础结构可保持在代理事件与请求代理事件的应用之间的关联性，使得应用和/或代理能从代理基础结构得到该信息。这可作为持续这样的信息的方式来完成。在另一例子中，代理基础结构可被编程以锁存触发和/或监视相关联的条件来确定何时用信号通知代理事件。以此方式，应用能请求不同代理为之实施一些触发和/或条件的代理事件，因为代理基础结构能管理来自多个个体代理的状态信息。

而且，在一实施方式中可便于模块化开发，其中，代理基础结构处置条件监视，因为个别代理不再需要“理解”或应对条件。

图8A示出了根据某些实施例可由代理基础结构(BI)或某些其它合适的操作系统组件执行以使得后台组件与代理事件相关联的说明性过程800。图8B示出了能结合过程800使用的说明性数据结构850。由过程800创建的关联性可允许操作系统响应于用信号通知代理事件来加载和执行后台组件。在一例子中，过程800可由图4所示的代理基础结构405来执行。但是，本公开的各方面不限于使任何特定的操作系统组件执行关联过程。在一些可替换实施例中，负责用信号通知代理事件的代理可使后台组件与代理事件相关联，例如，作为过程的部分来响应于自应用的请求而建立代理事件。

在动作805，BI可接收使诸如工作项目的后台组件与代理事件相关联的请求。请求可接收自任何合适的实体，因为本公开的各方面不受此限制。例如，在某些实施例中，应用可提交使所执行的组件为该应用做后台工作的请求。在一些其它实施例中，负责用信号通知代理事件的代理可代表应用而提交这样的请求，例如在应用从代理请求代理事件时，或者在应用被安装或更新时。

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

图9示出了根据某些实施例可由代理基础结构(BI)组件或某些其它合适的操作系统组件执行以确定何时执行后台组件和如何来管理后台组件的执行的过程900。例如，可由图4所示的BI组件405来执行过程900。

在动作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)和平板计算机。在某些情形中，移动设备的重量可至多为1磅，1.5磅或2磅和/或移动设备的最大尺寸可至多为6英寸，9英寸或一英尺。此外，移动设备可包括允许用户在不同位置使用该设备的特点。例如，移动设备可包括功率存贮器(例如，电池)使得其可在不插入到电插座的某段持续时间使用。作为另一例子，移动设备可包括无线网络接口，无线网络接口被配置成提供网络连接而无需物理地连接到网络连接点。

在图10所示的例子中，计算机1000包括处理器或处理单元1001和存储器1002，存储器1002可包括易失性和/或非易失性存储器。计算机1000还可包括存储装置1005(例如，一个或多个盘驱动器)，作为系统存储器1002的补充。存储器1002可存储一个或多个指令来将处理单元1001编程以执行本文所述功能中的任何功能。存储器1002也可存储再多一个应用程序和/或应用编程接口(API)函数。

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

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

上文中描述了本发明的至少一个实施例的若干方面，应了解本领域技术人员将易于想到各种更改、修改和改进。

这样的更改、修改和改进预期为本公开的部分，且预期在本发明的精神和范围内。另外，尽管示出了本发明的优点，应意识到并非本发明的每一个实施例将包括每个描述的优点。某些实施例可不实施在本文中且在某些情形下被描述为有利的任何特征。因此，前文的描述和附图只是举例说明。

本发明的上文所述的实施例可以多种方式中的任何方式来实施。例如，这些实施例可使用硬件、软件或其组合来实施。当实施于软件中时，软件代码可在任何合适的处理器或处理器集上执行，无论设于单个计算机中还是分布于多个计算机之间。这样的处理器可实施为集成电路，其中一个或多个处理器在集成电路组件中。但可使用任何合适格式的电路来实现处理器。

另外，应了解计算机可实施为多种形式中的任何形式，诸如机架安装的计算机、台式计算机、膝上型计算机或平板计算机。此外，计算机可嵌入于通常不认为是计算机但具有合适处理能力的设备内，包括个人数字助理(PDA)、智能手机、收银机、自动柜员机(ATM)或任何其它合适的便携式或固定电子设备。

而且，本文所列出的各种方法或过程可编码为软件，软件可执行于采用多种操作系统或平台中任一个的一个或多个处理器上。此外，这样的软件可使用多种合适编程语言和/或编程或脚本处理工具中的任一个来写，且还可编译为在框架或虚拟机上执行的可执行机器语言代码或中间代码。

在此方面，本发明可实施为计算机可读存储介质(或多个计算机可读介质)(例如，计算机存储器，一个或多个软盘、致密盘(CD)、光盘、数字视频盘(DVD)、磁带、闪存、现场可编程门阵列中的电路配置或其它半导体器件，或其它有形计算机存储介质)，其利用一个或多个程序编码，当这些程序在一个或多个计算机或其它处理器上执行时执行实施上文所讨论的本发明的各种实施例的方法。如从前述例子显然，计算机可读存储介质可保持信息持续足以以非暂态形式提供计算机可执行指令的时间。这样的一个或多个计算机可读存储介质是可运输的，使得存储于其上的一个或多个程序可加载到一个或多个不同的计算机或其它处理器上以实施如上文所讨论的本发明的各个方面。如本文所用的术语"计算机可读存储介质”仅涵盖可认为是制件(即，制品)或机器的计算机可读介质。作为替代或作为补充，本发明可实施为除了诸如传播信号的计算机可读存储介质之外的计算机可读介质。

如本文所用的术语“程序”或“软件”在一般意义上指可用于对计算机或其它处理器编程以实施如上文所讨论的本发明的各个方面的任何类型的计算机代码或计算机可执行指令的集合。此外，应了解根据此实施例的一个方面，在执行时实施本发明的方法的一个或多个计算机程序不需要驻留在单个计算机或处理器上，而是可以以模块化方式分布于多个不同的计算机或处理器之间以实施本发明的各个方面。

计算机可执行的指令可呈由一个或多个计算机或其它设备执行的许多形式，诸如程序模块。一般而言，程序模块包括例程、程序、对象、组件、数据结构等，其执行特定任务或实施特定抽象数据类型。通常，程序模块的功能可被组合或者在各种实施例中根据需要来分配。

而且，数据结构可存储在任何合适形式的计算机可读介质中。为了简化说明，数据结构可被示出为具有通过该数据结构中的位置而相关的字段。这样的关系同样可以通过对具有传达各字段之间关系的、计算机可读介质中的的位置的各字段分配存储而得到。然而，可以使用任何合适的机制来在数据结构的各字段中的信息之间建立关系，包括通过使用指针、标签或在数据元素之间建立关系的其它机制。

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

同样，本发明可被具体化为已经提供了其例子的方法。作为方法的部分而执行的动作可以任何合适方式排序。因此，可以构建实施例，其中各动作以与所例示的次序不同的次序执行，其可包括同时地执行的某些动作，即使这些动作在各说明性实施例中被示为顺序动作。

在权利要求中使用诸如“第一”、“第二”、“第三”等序数词来修饰权利要求要素本身并不意味着一个权利要求要素较之另一个权利要求要素的优先级、先后次序或顺序，或者方法的各动作被执行的时间顺序，而仅用作将具有某一名字的一个权利要求要素与(若不使用序数词)具有同一名字的另一要素区分开的标签以区分各权利要求要素。

而且，本文所用的短语和术语是出于描述目的且不应认为具有限制意义。在本文中使用“包括”、“包含”或“具有”、“含有”、“涉及”及其变型旨在包括其后列出的项目和其等效物以及附加项目。

Claims

1.一种由在至少一个计算机上执行的操作系统(400)使用的方法，所述方法包括动作：

识别应用(100)的至少一个后台组件(110A-C)；

确定是否满足了至少一个条件(615)；以及

仅在确定出满足了所述至少一个条件(615)时执行所述至少一个后台组件 (110A-C) 。

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

识别所述应用(100)的至少一个前台组件(105)；以及

与所述至少一个前台组件(105)的执行不同地管理所述后台组件(110A-C)的执行，包括执行所述至少一个前台组件(105)，而不考虑所述至少一个条件(615)。

3.根据权利要求2所述的方法，其中与所述至少一个前台组件(105)的执行不同地管理所述后台组件(110A-C)的执行的动作还包括：

确定用户是否与所述应用(100)主动地交互；

仅在确定出所述用户正与所述应用(100)主动地交互时执行所述至少一个前台组件(105)；以及

执行所述至少一个后台组件(110A-C)而不考虑所述用户是否与所述应用(100)主动地交互。

4.根据权利要求1所述的方法，其还包括动作：

仅响应于操作系统代理组件(415A-D)用信号通知的代理事件来执行所述至少一个后台组件 (110A-C)。

5.根据权利要求4所述的方法，其中，所述至少一个条件 (615) 与所述代理事件相关联，且其中所述方法还包括动作：

在所述操作系统代理组件(415A-D)处检测与所述代理事件相关联的至少一个触发(610)的发生；

响应于检测到所述至少一个触发(610)的发生，在所述操作系统代理组件 (415A-D)处确定是否满足了所述至少一个条件(615)；以及

仅当确定出满足了所述至少一个条件(615)时由所述操作系统代理组件(415A-D)用信号通知所述代理事件。

6.一种计算机实施的方法，其包括以下动作：

在操作系统(400)处接收响应于至少一个事件来执行应用(100)的至少一个后台组件(110A-C)的请求；

响应于检测到所述至少一个事件的发生来由所述操作系统(400)确定是否满足了由所述应用(100)设置的至少一个第一条件(615)且是否满足由所述操作系统(400)设置的至少一个第二条件(615)；以及

当发生了所述至少一个事件之后确定出满足了至少一个第一条件和第二条件(615)时执行所述至少一个后台组件(110A-C) 。

7.根据权利要求6所述的方法，其中，接收响应于至少一个事件来执行所述至少一个后台组件(110A-C)的请求的动作包括：

在代理基础结构组件(405)处接收响应于由操作系统代理组件(415A-D)用信号通知的代理事件而执行至少一个后台组件 (110A-C)的请求。

8.根据权利要求6所述的方法，其中，所述至少一个事件包括由操作系统代理组件 (415A-D)用信号通知的代理事件，且其中所述方法还包括以下动作：

在所述操作系统代理组件(415A-D)处接收响应于至少一个触发(610)用信号通知代理事件的请求。

9.根据权利要求8所述的方法，其中，所述至少一个条件(615)为至少一个第一条件(615)，且其中响应于至少一个触发(610)用信号通知代理事件的请求规定了在用信号通知所述代理事件之前要满足的至少一个第二条件(615)。

10.根据权利要求9所述的方法，其还包括以下动作：

由所述操作系统代理组件(415A-D)来保持用于评估所述至少一个第二条件(615)的状态信息；

由所述操作系统代理组件(415A-D)响应于确定出在激发（fire）所述至少一个触发(610)时未满足所述至少一个第二条件(615)来锁存所述至少一个触发(610)；

由所述操作系统代理组件(415A-D)响应于所保持的状态信息的变化来重新评估所述至少一个第二条件(615)以确定是否用信号通知所述代理事件。

11.一种计算机可读介质，其上存储有计算机可读指令，其中计算机可读指令当被执行时完成权利要求1-10中任一项所述的方法。