CN104838360A - 基于配额的资源管理 - Google Patents

Abstract

此处描述了基于配额的资源管理创新。例如，基于配额的资源管理作为计算设备的应用层框架和/或操作系统的一部分实现。通过基于配额的资源管理，在计算设备的资源设计期间建立预算。每种工作负荷类型主要从操作系统实施的预算中专用于该工作负荷类型的资源中提取。这有助于针对被允许运行的那些工作负荷提供可接受的性能，同时防止移动计算设备的资源在工作负荷当中太分散，从而显得过于薄弱。也可帮助在不同的工作负荷类型当中维护良好的整体平衡。

Description

基于配额的资源管理

背景技术

智能电话或其它移动计算设备具有有限的资源，但是被期望并发地运行多种类型的软件。除了操作系统的软件进程之外，移动计算设备还被期望同时运行多种应用组合，例如，路线规划地图导航应用、Web浏览器、文本消息传送应用、语音通信应用、音频播放应用、电子邮件阅读器、日历应用、警报时钟应用和/或游戏的不同组合。

应用或系统进程可被视为移动计算设备的工作负荷。在资源有限的情况下，移动计算设备决定如何将诸如处理器使用和内存之类的资源分配给不同的工作负荷。在执行此操作时，移动计算设备可能具有相互矛盾的目标——既要运行尽可能多的工作负荷，又要为每个工作负荷提供足够的资源。例如，当用户在前台主动使用不同的应用的同时，移动计算设备可能尝试在后台运行路线规划地图导航应用，这要求移动计算设备分配足够的资源，以便每个应用具有可接受的性能。如果没有足够的资源被分配给工作负荷，则用户可注意到该工作负荷的性能降级。

在某些早期的移动计算设备中，应用作者或用户本质上可以自由地使用设备资源，几乎不受任何限制。结果，行为失当的应用或启动太多并行工作负荷的用户可能导致移动计算设备的性能劣化到不可接受的程度。对于前台中的应用而言，尤其可能注意到这一现象。如果操作系统在工作负荷之间粗略地等分资源，则操作系统一般跟踪工作负荷，并且确保每个工作负荷获取一定的处理器资源和一定的内存。当没有足够的资源时，应用性能通常会降低。有些应用可能运行良好，但是其它应用可能运行缓慢，或者未按照预期运行，或者完全运行失败。此问题对于具有更少资源的低端设备而言尤其严重。

发明内容

总而言之，详细的描述涉及基于配额的资源管理创新。例如，基于配额的资源管理作为移动计算设备的应用层框架和/或操作系统的一部分实现。通过基于配额的资源管理，在移动计算设备的资源设计期间建立预算，其中每种工作负荷类型主要从操作系统实施的预算中专用于该工作负荷类型的资源中提取。被管理的资源通常包括处理器和/或内存资源，但是也可包括相机、音频扬声器、麦克风、媒体管线的其它部分、近场通信（“NFC”） 传感器或其它任何系统级资源。这有助于针对被允许运行的那些工作负荷提供可接受的性能，同时防止移动计算设备的资源在工作负荷当中太分散，从而显得过于薄弱。

基于配额的资源管理也可帮助在不同的工作负荷类型当中维护良好的整体平衡。例如，可将较多的资源分配给与用户直接交互的前台任务，而将较少的资源分配给后台任务。在实例实现中，这允许当用户在前台中与另一应用交互时，计算设备顺利地运行后台任务（例如，在后台中同步电子邮件，以不易察觉的方式下载文件等）。同时，基于配额的资源管理提供与用户的优先级密切相关的体验。例如，在用户打游戏的同时，不会因为正在进行电子邮件同步而影响游戏的速度，而且电子邮件同步仍可继续，以便当游戏结束时，电子邮件也更新完毕。

根据此处描述的创新的一方面，资源管理器接收对要从多个资源池中的一个应用的资源集的请求（例如，从任务管理器接收请求）。每个池与不同的工作负荷类型关联。所述池至少部分地在所述不同的工作负荷类型当中分别指定所述计算设备的资源预算。所述计算设备上的数据存储装置可存储定义所述不同的工作负荷类型的池的池信息。例如，对于多个池中的每个，所述数据存储装置包括针对所述池的处理器使用限制和内存限制。

池类型（及其关联的工作负荷类型）取决于实现。例如，所述多个池包括与系统工作负荷类型关联的第一池、与前台工作负荷类型关联的第二池、与后台用户体验（“UX”）工作负荷类型关联的第三池、与后台处理工作负荷类型关联的第四池。所述多个池可进一步包括每个都与特定应用类（例如，网络语音电话业务（“VoIP”）、路线规划（“TBT”导航）的工作负荷类型关联的一个或多个池，和/或每个都与应用的非激活状态（例如，对应于正在暂停、已暂停或已停止的应用）的工作负荷类型关联的一个或多个池。

所请求的资源集可具有从多个资源集类型中选择的资源集类型。一般而言，资源集类型信息指定资源集类型的特征。例如，对于多个资源集类型中的每个，资源集类型信息指定(a)一个或多个资源配额，每个资源配额包括资源类型的量值，(b)池标识符，其指示所述池中的一个,以及(c)一个或多个优先级值，每个优先级值指示所指示的池内的所述资源集类型的优先级。所述计算设备上的数据存储装置可存储所述资源集类型信息。

所述资源管理器至少部分地基于所述预算评价所述请求，并且发送对所述请求的回复。例如，为了评价所述请求，所述资源管理器可基于所请求的资源集的资源集类型的池标识符选择池，然后判定所选择的池内是否具有足够的资源可用。为了判定是否具有足够的资源可用，所述资源管理器可考虑所选择的池中当前可用的资源，以及所请求的资源集的所述资源集类型的（多个）资源配额。如果没有足够的资源可用，则所述资源管理器可判定从所选择的池中应用的上一资源集是否具有比所请求的资源集的资源集类型低的优先级，如果是，则请求释放所述上一资源集。

根据此处描述的创新的另一方面，任务管理器从与多个资源池关联的多个资源集类型中选择资源集类型，其中所述池中的每个与不同的工作负荷类型关联。所述池至少部分地在所述不同的工作负荷类型当中指定所述计算设备的资源预算。所述任务管理器发送对所选择的资源集类型的资源集的请求，并且接收对所述请求的回复。资源集类型信息（如上所述）可指定资源集类型的特征。

在某些实现中，所述任务管理器接收执行任务的请求（从客户机接收），然后作为响应，选择资源集类型，并向资源管理器发送对资源集的请求。根据对所述资源集请求的回复，所述任务管理器可采取不同的动作。例如，如果所述回复是接受，则所述任务管理器可启动任务并将所述资源集应用于所述任务。或者，如果所述回复是拒绝，则所述任务管理器可将对所述资源集的请求放入队列以做后续处理（例如，重复向所述资源管理器进行请求）。或者，如果所述回复是所述资源集的请求暂挂的指示，则在有释放资源的通知时，所述任务管理器可启动所述任务并将所述资源集应用于所述任务。在任一情况下，操作系统都可根据所选择的资源集类型实施所述任务的资源预算。

根据此处描述的创新的另一方面，移动计算设备包括处理器和存储适应所述移动计算设备的资源的预算信息的存储器。具体而言，所述预算信息包括多个资源池的池信息以及多个资源集类型的资源集类型信息。所述多个池中的每个与不同的工作负荷类型关联，其中所述多个池至少部分地在所述不同的工作负荷类型当中分别指定所述移动计算设备的资源预算。对于所述池中的每个，所述池信息包括(a)与所述池关联的所述不同的工作负荷类型的内存限制，以及(b)与所述池关联的所述不同的工作负荷类型的处理器使用限制。对于所述多个资源集类型中的每个，所述资源集类型信息包括(a)一个或多个资源配额，(b)池标识符，其指示所述多个池中的一个，以及(c)一个或多个优先级值。

根据参考附图做出的以下详细描述，本发明的上述及其它目标、特征和优点将变得更加显而易见。

附图说明

图1和2是分别从任务管理器和资源管理器的角度示出基于配额的资源管理的一般技术的流程图。

图3是示出基于配额的资源管理的一般软件架构的图表。

图4a和4b是分别示出池信息实例和资源集类型信息实例的表。

图5是示出实例实现中基于配额的资源管理的软件架构的图表。

图6a-6l示出实例实现中基于配额的资源管理的类型值和接口的伪代码列表。

图7是示出实例实现中的资源集类型信息的实例表。

图8是示出实例实现中的池信息的实例表。

图9和14是分别示出实例实现中的资源集和外部资源的状态的状态转换的状态表。

图10a、10b和16是示出实例实现中的资源获取实例的序列表，图11-13、15和17是示出实例实现中基于配额的资源管理的各方面的伪代码列表。

图18是其中可实现此处描述的至少某些创新的一般移动计算设备的图表。

具体实施方式

此处描述基于配额的资源管理的创新。对于基于配额的资源管理，建立诸如智能电话之类的计算设备的资源预算。在操作期间，工作负荷主要使用预算定义的资源，并且由操作系统实施预算。

一般而言，对于基于配额的资源管理，计算设备的资源（例如处理器和/或内存资源，但是也可能包括相机、音频扬声器、麦克风、媒体管线的其它部分、NFC传感器或其它任何系统级资源）被分为多个池。一个池可专用于一种工作负荷类型。例如，一个池包括用于前台用户体验的资源（例如，计算设备用户界面（“UI”）在前台中的应用），另一池包括用于系统进程的资源，而又一池包括用于后台中路线规划（“TBT”）导航的资源等等。通过此方式，计算设备的资源针对不同的工作负荷类型被做出预算，这样可在不同的工作负荷类型当中维持良好的整体平衡。例如，可将较多的资源分配给前台任务，而将较少的资源分配给后台任务，以便允许当用户在前台中与另一应用交互的同时，计算设备可顺利地运行后台任务。同时，基于配额的资源管理可提供与用户的优先级密切相关的体验。

一般而言，资源集是指一组资源，客户机可请求该组资源来使用工作负荷。资源可以是一个或多个处理器、内存、相机、用于音频输出的扬声器、用于音频捕捉的麦克风、近距离传感器（例如，用于NFC）、计算设备中的其它传感器或其它任何组件或服务，尤其是指多个任务或应用进行争用以获取资源的组件。资源集可指示允许工作负荷使用的不同资源类型的量、资源来自哪个池、工作负荷/资源集类型的优先级，以及有关工作负荷对资源的访问的其它信息。计算设备的基于配额的资源管理可基于在池中指定的预算和所请求的资源集指示要启动的工作负荷。在一般的使用状况下，直到并且除非计算设备具有可用于工作负荷的资源，否则该工作负荷不能被启动，这样有助于避免出现计算设备的资源在多个工作负荷当中太分散，从而显得过于薄弱的情况。操作系统基于已被应用于工作负荷的资源集实施有关资源使用的规则。

数据存储装置（例如计算设备的设置和信息的寄存器或其它存储库）可存储有关池和资源集类型的信息。通过此方式，可声明性地定义计算设备的预算。从资源管理代码中提取预算信息（例如，池信息和资源集类型信息）的值可提供管理和更新值的简单方式。数据存储装置中的预算信息的值可在不更改代码的情况下更新或以其它方式修改。同时，在至少某些情况下，相同的代码可针对不同的计算设备类重复使用，只是针对各个设备类适配不同的预算信息值。

在此处描述的某些实例中，基于配额的资源管理的各种操作由计算设备应用层框架的任务管理器和资源管理器执行。当客户机（例如，运行任务、进程或其它任何代码片段）在用户执行动作之后或基于其它原因希望执行新任务时，客户机向任务管理器提交适合于该任务类型的请求。任务管理器向资源管理器请求适合于被请求的任务类型的资源集。

资源管理器检查相应的池以查看该池是否具有足够的资源来提供给所请求的资源集。如果该池具有足够的资源，则允许请求。如果该池不具有足够的资源，则资源管理器可查看从同一池提供的具有较低优先级的上一资源集。如果所请求的资源位于低优先级资源集中，则可要求对应于这些较低优先级资源集的工作负荷释放它们的资源。这样，较高优先级工作负荷可以停止较低优先级工作负荷的执行。由于该释放操作可能占用一些时间（并非同步），因此，可能告知客户机资源正处于暂挂状态，并且稍后在资源变得可用时被通知。如果所请求的资源集的资源由相同或较高优先级的资源集持有，则可通过类似的方式告知客户机对资源集的请求正被暂挂，客户机需要等待，直到资源被自愿地释放。这样，如果任务管理器无法获取资源集，则任务管理器可以通过不同的方式处理状况，例如通过使来自客户机的调用失效，或者将请求放入队列并在资源集变得可用时立即满足该请求。

一旦资源集被成功地获取，任务管理器便可启动任务并将资源集应用于该任务。“应用”操作实施资源集定义的限制。例如，任务被限于资源集中定义的内存数量，并且超过该限制的任何内存分配请求都会失败。或者，任务具有来自资源集的处理器配额（例如，20%），一旦任务使用完20%的处理器周期（在某一时间间隔内，例如600ms），任务便不会再运行，直到下一时间间隔到来（假设另一任务、进程等也要使用处理器）。（在某些实现中，任务的处理器配额可被设定为“软限制”，以便在系统具有未使用的处理周期时允许该任务继续运行）。这些处理器和内存限制由操作系统的内核实施。这样，任务管理器/资源管理器根据基于配额的资源管理的预算信息和规则应用资源集，而内核根据内核和所应用的资源集的规则提供处理器限制、内存限制、其它资源限制等的较低级别实施。

在某些实现中，对于特定任务，还可以请求并非来自固定大小池的特殊资源集，因此“超过预算”。这对于立即运行的任务有用。即使超过预算，这些资源集仍有用，因为它们像其它任何资源集一样对任务施以限制（例如，处理器和内存配额）。这样，可允许短期工作负荷或使用较少资源的工作负荷“超预算”地运行，但是它们的资源受到约束。

一般而言，此处描述的技术和工具可通过移动计算设备或其它计算设备实现。有形的计算机可读介质（例如，计算机程序产品、计算机存储装置或其它计算机可读存储器）可存储计算机可执行指令，这些计算机可执行指令用于对处理器进行编程，从而使其执行此处描述的一种或多种技术。各种技术和工具可以组合地或独立地使用。不同的实施例实现此处描述的技术和工具的一种或多种。此处描述的某些技术和工具解决了背景技术部分中描述的一个或多个问题，但此处描述的技术和工具并不需要解决这些问题。

I. 基于配额的资源管理的实例技术

图1从计算设备的任务管理器的角度示出基于配额的资源管理的一般技术（100）。图2是从计算设备的资源管理器的角度示出对应的基于配额的资源管理的一般技术（200）。任务管理器和资源管理器可被实现为与计算设备的操作系统交互的应用层框架的一部分。备选地，任务管理器和/或资源管理器可被实现为操作系统的一部分。或者，任务管理器和/或资源管理器可被实现为另一软件层的一部分。诸如移动计算设备之类的计算设备可执行技术（100）和/或技术（200）。

参考图1，最初，任务管理器从与多个资源池关联的多个资源集类型中选择（110）资源集类型，其中池中的每个与不同的工作负荷类型关联。总之，这些池至少部分地在不同的工作负荷类型当中分别指定计算设备的资源预算。池的类型（及其关联的工作负荷类型）取决于实现。在某些实现中，池包括与系统工作负荷类型关联的池、与前台工作负荷类型关联的池、与后台用户体验（“UX”）工作负荷类型关联的池、以及与后台处理工作负荷类型关联的池。池可进一步包括分别与特定应用类（例如，VoIP、TBT导航）的工作负荷类型关联的一个或多个池，和/或分别与应用的非激活状态（例如，对应于正在暂停、已暂停或已停止的应用）的工作负荷类型关联的一个或多个池。图4a示出与一类计算设备的工作负荷类型关联的池的简化实例。图8示出实例实现中与工作负荷类型关联的池。备选地，池包括其它和/或额外的池类型。

计算设备上的数据存储装置可存储定义不同的工作负荷类型的池的池信息。例如，对于多个池中的每个池，数据存储装置包括该池的处理器使用限制和内存限制。数据存储装置还可存储资源集类型的资源集类型信息。例如，对于多个资源集类型中的每个，资源集类型信息指定(a)一个或多个资源配额，每个资源配额包括资源类型（例如，处理器或内存）的量值，(b)池标识符，其指示多个资源池中的一个,以及(c)一个或多个优先级值，每个优先级值指示所指示的池内的资源集类型的优先级（例如，处理器优先级、内存优先级和/或整体优先级）。图4b示出一类计算设备的资源集类型信息的简化实例。图7示出实例实现中的资源集类型的值。备选地，这资源集类型包括其它和/或额外的资源集类型。

返回图1，任务管理器发送（120）对所选择的资源集类型的资源集的请求。任务管理器可响应于从客户机接收执行任务的请求而执行选择（110）和发送（120）。

参考图2，资源管理器接收（210）对将从多个资源池中的一个应用的资源集的请求。资源管理器至少部分地基于预算评价（220）请求。例如，资源管理器从多个池中选择适合于所请求的资源集的池（例如，基于所请求的资源集的资源集类型的池标识符）。资源管理器还判定所选择的池内是否具有足够的资源可用（例如，基于所选择的池中当前可用的资源和所请求的资源集的（多个）资源配额）。如果所选择的池内没有足够的资源可用，则资源管理器可判定从所选择的池中应用的上一资源集是否具有比所请求的资源集低的优先级，如果是，则请求释放上一资源集。

资源管理器发送（230）对请求的回复。任务管理器接收（130）对资源集的请求的回复，并且处理该回复。例如，如果回复是接受，则任务管理器可启动所请求的任务并将资源集应用于任务。或者，如果回复是拒绝，则任务管理器可将对资源集的请求放入队列以做后续处理。或者，如果回复是有关对资源集的请求是暂挂资源释放的指示，则任务管理器可释放资源的通知时，启动任务并将资源集应用于任务。在任务被启动，并且资源集被应用于任务之后，操作系统根据所选择的资源集类型实施任务的资源预算。

图10a、10b和16示出实例实现中获取资源集的资源的调用序列的实例。调用序列使用图6a—6l中所示的接口、方法、数据类型等。部分地，这些实例包括实现图1和2所示的一般技术（100、200）的详细方式。备选地，技术（100、200）通过另一方式实现，例如，使用具有不同定义的接口、方法和/或数据类型，和/或使用不同的调用序列。

在图1和2的上下文中，并且如本文的其它部分所用，术语“发送”和“接收”不暗示对计算设备内的通信方式和机制的任何限制。“发送”和“接收”操作可通过方法调用和同步返回、经由回调接口的方法调用和异步返回、消息通道或计算设备内的其它任何通信形式来实现。从“发送者”到“接收者”而被传递的请求内容、回复或其它消息可通过一个或多个代码中间层直接被传递或处理，其中可能包括更改消息的类型、结构、字段等，或者将消息转换为另一消息形式的处理。

II. 实例软件架构

图3示出基于配额的资源管理的一般软件架构（300）。软件架构（300）可在智能电话、手持式游戏设备、其它移动计算设备或其它计算设备上实现。软件架构（300）包括一个或多个主进程（310）、带有任务管理器（351、352、353）和资源管理器（340）的应用平台服务（300）、系统资源管理器（370）和数据存储装置（320）。在此处描述的多个实例中，软件架构（300）针对被编入池（从中提取资源的资源集）预算的资源处理各种类型的任务、工作负荷和宿主。

任务、工作负荷和宿主。

一般而言，任务是应用功能的逻辑单元。应用可包括一个或多个任务。任务实例是被执行的任务。前台任务实例是能够显示UI的任务实例，后台任务实例（或后台代理）是不能显示UI的任务。在某些地方，任务实例被称为运行中的任务，已启动的任务或简称为任务。

宿主（或称为主进程）（例如图3中的主进程（310））是包含应用的一个或多个任务实例的进程。UI宿主是仅包含显示UI的任务实例的主进程。后台宿主包含后台代理。系统进程是主进程之外的任何进程。

一般而言，工作负荷是一组通过协作来提供功能的进程。工作负荷类型的数量、工作负荷类型的定义和不同的工作负荷类型的状况（例如，工作负荷中允许的宿主类型、工作负荷中允许的宿主计数）取决于实现。工作负荷一般可被识别为工作负荷A、工作负荷B、工作负荷C等。或者，工作负荷可通过指示处理类型的标签识别；例如，工作负荷可以是系统工作负荷、前台UI工作负荷、后台UX工作负荷、后台处理工作负荷或其它工作负荷。

系统工作负荷包括系统进程。例如，移动计算设备可包括含有所有系统进程的单个系统工作负荷。系统工作负荷提供以下功能：例如系统提供的前台UI特征——锁屏、应用栏、管理来电呼叫、警报、提醒等。系统工作负荷也可提供以下功能：系统资源的音频播放、电子邮件同步、下载/安装更新和应用等。在某些实现中，系统工作负荷中的系统进程可代表其它工作负荷中的主进程工作（例如，当另一工作负荷中的主进程中的任务实例调用系统进程的服务库时）。

前台UI工作负荷包括提供基于UI的可视UX的主进程。UI工作负荷可以包含前台UI当前显示的活跃UI宿主。或者，UI工作负荷可以包含另一会话的非活跃UI宿主，或者当系统工作负荷正在提供前台UI（例如，针对锁屏）。

后台UX工作负荷包括提供不可视UX的主进程（后台宿主），例如通过第三方应用实现的后台音频播放、来自TBT地图导航应用的音频方向播放，或在切换到另一应用（例如，电子邮件阅读器）的同时使用DLNA向外部显示器提供视频。

后台处理工作负荷包括执行后台处理的主进程（后台宿主），例如代表一个或多个应用将用户位置更新到服务器，在屏幕关闭时下载媒体等。后台处理工作负荷不直接提供部分UX。

备选地，基于配额的资源管理使用其它和/或额外的工作负荷类型。类似的，不同的实现可具有不同的规则，这些规则涉及工作负荷中允许的宿主的数量、给定应用的任务之间允许的与工作负荷的关系等。在任一情况下，任务管理器（351、352、353）和资源管理器（340）进行组合来提供基于配额的资源管理。

池、资源集类型和数据存储装置

一类计算设备的预算可基于该类计算设备的资源，在设计期间建立。不同的计算设备类通常具有不同的预算。例如，具有更多内存、更快处理器等的高端设备的预算被期望不同于低端设备的预算。在任一情况下，预算可至少部分地通过池和资源集类型指定。

池是移动计算设备的一组资源。移动计算设备的至少某些资源被分为多个池。一个池可专用于一个工作负荷类型，以便针对各个工作负荷设定资源预算。通过此方式，计算设备的资源可针对各种工作负荷类型进行预算。除了在有限的情况下（在下面描述）和其它有限的例外中，在池之间共享资源之外，池设定用于关联的工作负荷的资源的上限。例如，移动计算设备的处理器使用和内存针对工作负荷A、工作负荷B、工作负荷C等，在多个池之间进行分割。资源的有些部分可被保留，并且不能被分配给任何池，以便用于“超预算”处理。其它资源（例如网络连接带宽、相机）可独立于多个池，或作为池的一部分进行管理。

配额（或资源配额）是资源类型和配额大小或量的组合。例如，配额可以是内存限制，例如10 MB或40 MB的“提交内存”，通过该提交内存将内存分配给任务。或者，配额可以是处理器使用限制，该限制可表示为一段时间间隔内的处理器使用百分比（例如，20%、40%）。该时间间隔既可是固定间隔，也可是可变间隔，在这种情况下，处理器使用限制可同时影响整体处理器使用率和处理器的延迟或响应性。

资源集是一组资源，当客户机（主进程、其它代码等）请求在工作负荷中运行任务时，可使用该组资源。资源可以是一个或多个处理器、内存、相机、网络连接、用于音频输出的扬声器、用于音频捕捉的麦克风、近距离传感器、计算设备中的其它传感器或其它任何组件或服务。资源集具有资源集类型。资源集类型可包括一个或多个资源配额（例如，处理器使用限制和内存限制）、从中应用资源的池的池标示符、一个或多个优先级值和/或其它信息。因此，资源集类型可定义允许任务使用的每种资源类型的量、资源所来自的池、有关任务对资源的访问的优先级信息和其它信息。

一般而言，数据存储装置（320）是有关池、资源集类型和其它预算信息的设置的存储库。例如，在某些实现中，数据存储装置可以是寄存器，其中声明性地定义池和资源集类型。备选地，数据存储装置（320）是有关设备的设置和信息的某一其它类型的存储库。数据存储装置（320）可包括位于一个位置处的单个数据存储库，或位于不同位置的多个数据存储库。在此处描述的多个实例中，数据存储装置（320）存储多个资源池的池信息以及多个资源集类型的资源集类型信息。对于池中的每个，池信息包括(a)与给定池关联的工作负荷类型的内存限制，和/或(b)与给定池关联的工作负荷类型的处理器使用限制。对于多个资源集类型的中每个，资源集类型信息包括(a)一个或多个资源配额，每个资源配额包括资源类型的量值，(b)池标识符，其指示多个池中的一个，和/或(c)一个或多个优先级值，每个优先级值指示所指示的池内的资源集类型的优先级。

图4a示出一类移动计算设备的池信息的简化实例（400）。池信息制定四个池A、B、C和D，这些池分别与四种不同的工作负荷类型关联。对于四个池A、B、C和D中的每个，指示处理器限制和内存限制。内存限制是与移动计算设备上的可用系统内存一致的“提交内存”限制。池信息还包括“超预算”处理的列表，这些超预算处理被期望迅速完成，和/或使用较少的资源。在任一情况下，超预算处理都具有与其关联的资源配额，以防止超预算处理使用过度的资源。不同类的移动设备可具有不同的池信息。

图4b示出一类移动计算设备的资源集类型信息的简化实例（420）。不同类的移动设备可具有不同的资源集类型信息。对于每种资源集类型，资源集类型信息包括关联的池、适用于同一池内冲突的整体优先级、指定时间间隔内的处理器使用百分比，以及内存限制。例如，资源集类型2的资源集具有比类型4的资源集高的优先级。任务管理器（351、352、353）/资源管理器（340）可从类型4的资源集拉回资源以用于类型2的资源集。

图7和8示出实例实现中的池信息和资源集类型信息的更具体实例。备选地，池信息和/或资源集类型信息可包括其它和/或额外的字段。根据实现，池信息可包括其它和/或额外的池，资源集类型信息可包括其它和/或额外的资源集类型。通常，池信息和/或资源集类型信息在具有不同资源的不同计算设备类之间变化。

任务管理器和资源管理器

应用平台服务（330）是应用层框架或与系统资源管理器（370）交互的软件的其他层。应用平台服务（330）可包括多个任务管理器，用于处理对不同的任务类型的请求。图3示出三个任务管理器（351、352、353）。例如，第一任务管理器处理启动前台UI任务实例的请求，第二任务管理器处理启动有助于后台UX的后台任务实例的请求，第三任务管理器处理启动其它后台任务实例的请求。备选地，基于配额的资源管理包括其它和/或额外种类的任务管理器。

一般而言，当主进程（310）、代码片段或其它客户机希望执行任务（根据用户动作或根据其它原因）时，客户机针对该任务类型将请求提交给任务管理器（351、352或353）。在某些实现中，系统进程的资源不使用基于配额的资源管理进行管理。但是备选地，系统进程的资源可以与其它进程的资源一起被管理。任务管理器（351、352或353）从客户机接收执行任务（任务实例）的请求，判定该任务类型的适当资源集，并且从资源管理器（340）请求适当的资源集。

响应于来自任务管理器（351、352或353）的对资源集的请求，资源管理器（340）选择相应的池（针对工作负荷类型），并且检查该池以判定是否具有足够的资源来满足请求。如果是，则资源管理器（340）允许请求，并向任务管理器（351、352或353）发送接受信息。如果否，则资源管理器（340）可搜索所选择的池中并且具有较低优先级上次应用的（尚未被释放的）资源集。如果所选择的池中的较低优先级资源集（或多个较低优先级资源集）具有足够的资源来满足请求，则资源管理器（340）可请求释放（多个）较低优先级资源集（通过与任务管理器和/或执行管理器协作以停止使用（多个）较低优先级资源集的（多个）任务实例）。资源管理器（340）然后将适当的回复发送到任务管理器（351、352或353）。

任务管理器（351、352或353）从资源管理器（340）获取响应，并且可以对客户机做出响应。当来自资源管理器（340）的响应指示对资源集的请求已经被接受时，任务管理器（351、352或353）可（适当地）启动任务并将资源集应用于任务。这样，使用适当的工作负荷类型的池资源启动任务。根据针对实现启动任务的情况和规则，新任务实例可作为新工作负荷中的新宿主的一部分被启动，作为现有工作负荷中的新宿主的一部分被启动，或作为现有工作负荷中的现有宿主的一部分被启动。

当响应指示对资源集的请求失败时，任务管理器（351、352或353）可向客户机简单地报告该失败，或者任务管理器可重试请求，具体取决于任务管理器的实现。当响应指示对资源集的请求暂挂（等待释放资源，可能耗费任意长的时间）时，任务管理器（351、352或353）可向客户机报告此结果，并且等待资源已被释放的通知。这样，即使在已经请求释放较低优先级资源之后，客户机也可能被告知资源正被“暂挂”，并且在稍后资源变得可用时被通知。如果资源由相同或较高优先级资源集持有，则可通过类似的方式通知客户机资源正被暂挂，客户机需要等待，直到这些其它资源集被自愿地释放。

系统资源管理器（370）实施在任务实例的资源集中定义的资源限制。系统资源管理器（370）可至少部分地通过操作系统组件实现。例如，系统资源管理器（370）的某些部分可由操作系统的内核提供。在图3中，系统资源管理器（370）包括CPU调度器和内存管理器。诸如资源执行器模块（图3中未示出）之类的系统资源管理器（370）的其它部分可被实现为操作系统的一部分或应用平台服务（330）的一部分。一旦资源集被成功地获取，任务管理器（351、352或353）便可启动任务并将资源集应用于任务，此时，系统资源管理器（370）实施资源集定义的限制。例如，任务将被限于在被应用于任务的资源集中定义的提交内存量，任何超过该限制的内存分配请求都会失败。或者，当任务具有x%的处理器配额时，一旦任务在可用的时间间隔内使用完x%的处理器周期，任务便无法再运行，直到下一时间间隔到达（至少在其它任何任务、进程等寻求使用该处理器时）。资源集中的标志可指示在没有其它任务、进程等寻求使用处理器时，是否允许任务使用超过其处理器配额的资源。

对于特定任务，还可以请求不来自固定大小池的特殊“超预算”资源集。这对于立即运行的任务有用。即使超过预算，但这些资源集仍有用，因为它们像其它任何资源集一样对任务施以限制（例如，处理器和内存配额）。

图5示出作为图3的一般软件架构（300）的具体实例的软件架构（500）。架构（500）包括有关实例实现中资源管理器（340）的内部组件和组件之间的接口的细节，参考图6a-6l所示的接口、方法、数据类型等。备选地，一般软件架构（300）通过另一方式实现，例如，使用具有不同定义的内部组件、接口、方法和/或数据类型实现。图3示出软件的各层。备选地，软件架构（300）可包括更多或更少的层。例如，可将给定层分为多个层，或者将不同的层组合为单个层。参考一个层描述的功能（例如，任务管理、资源管理）在某些情况下可以被实现为另一层的一部分。这样，任务管理器和资源管理器可驻留在同一服务（例如，应用层框架或其它应用平台服务）或不同的服务中。任务管理器和/或资源管理器可被实现为操作系统或另一软件层的一部分。为了简单起见，图3未示出在典型的实现中找到的特定组件和服务，例如，调试器、封装管理器、后台通知服务、后台音频播放服务、UI导航模型、执行管理器等。

III. 应用类组合的实例方案

当管理计算设备的资源时，基于配额的资源管理可在多种方案中使用。在设计期间，方案策略针对可在计算设备上并列运行的应用类指定。所支持的方案取决于计算设备的资源。这些方案可在计算设备的数据存储装置中，通过在池信息和资源集类型信息中反映的策略进行管理。

类是具有特定资源使用模式的应用种类。例如，可以存在不同的类——前台应用、后台中的VoIP应用、后台中的TBT导航、后台中的电子钱包应用、后台中同步的媒体或文件数据、钟表桌面更新的后台处理等，用于后台中的同步、音频播放的其它类型后台处理。在许多情况下，给定的应用（例如TBT）当在前台中运行时，被视为前台应用，但是当被切换到后台时，被分类为后台应用类型，具体取决于用于后台处理的资源。如资源集类型信息中反映的那样，不同的类可受到支持或不受支持。例如，前台可具有较高资源限制（多数处理器使用、较高内存限制）和对资源的较高优先级访问权限，而数据同步应用可具有低资源限制，并且对延迟更不敏感。

方案是移动计算设备支持并行执行的一类或多类应用的组合。例如，方案可针对以下各项指定：(a)仅前台应用，(b)同时运行的前台应用和VoIP应用（或TBT应用，但不同时针对这两项），(c)同时运行的前台应用、VoIP应用和TBT导航应用，(d) 同时运行的前台应用、VoIP应用和多个数据同步应用等等。不同的计算设备类型可具有与其关联的不同方案集。例如，低端移动计算设备可支持方案(a)和(b)，而具有更多资源的高端移动计算设备支持方案(a)-(d)。这样，所支持的方案集取决于计算设备的类。

通过任务管理器和资源管理器实现的基于配额的资源管理可被用于根据针对方案应用的池和资源集类型的适用策略来管理方案。当针对执行任务的请求选择资源集类型时，任务管理器可实施方案策略。任务管理器也可通过与不同方案的策略一致的方式，协调较低优先级资源集中资源的释放，从而赞成一类应用超过从同一池获取资源的另一类应用。或者，不同的应用类可以与不同的池关联，以便为不同应用类保留资源来同时运行。类似地，当评价对资源集的请求时，资源管理器可应用方案策略。

例如，在低端设备上，假设TBT导航应用在前台中运行。当VoIP呼叫进来并且被应答时（启动VoIP应用），TBT地图导航被终止或被切换到后台，以便不影响性能。可通过具有不同的优先级，但是与同一池关联的资源集类型实现此操作。这与前台+VoIP方案一致（与缺失前台+VoIP+TBT方案一致）。在设计期间，可以做出一致性地管理该方案的决策。通过选择针对任务使用的资源集类型，任务管理器可实施这样的策略：即某些应用类在前台运行，但是永远不会在后台运行，而其它应用类可在前台或后台运行。

任务管理器可将等待特定资源类型的任务进行排队，从而控制被允许同时运行的应用类（或者控制给定应用类中可同时运行的实例数量）。例如，多个数据同步应用可以在高端设备上同时运行，但是在低端设备上需要序列化。这样为其它应用保留了资源，同时还有助于确保任一数据同步应用在启动时具有足够的资源来运行。在某些方案中，这样可能意味着每个类中的一个应用运行，该类中的其它应用被序列化。但是，其它方案可能允许一个类中的多个应用同时运行。

IV. 基于配额的资源管理的实例实现

图5-17示出基于配额的资源管理的实例实现的具体特征。备选地，基于配额的资源管理通过另一方式实现，例如，使用具有不同组件和/或不同组织的软件架构，使用具有不同定义的接口、方法和/或数据类型，和/或使用不同的调用序列来实现。

图5示出基于配额的资源管理的实例实现的软件架构（500）。软件架构（500）中的许多模块一般参考图3进行描述。图5示出参考图3更一般地描述的某些模块的具体实例，其中包括后台UX任务管理器（571）和前台任务管理器（572）作为任务管理器的实例，以及具有内存管理器（592）的内核（590）作为具有内存管理器的系统资源管理器的实例。图5示出两个任务管理器——后台UX任务管理器（571）和前台任务管理器（572）。架构（500）可包括其它类型的任务管理器。图5还示出额外的模块，例如执行管理器（520），以及诸如资源管理器（530）之类的某些模块的更多细节。

资源管理器（530）包括资源集管理器（550）、基资源集管理器（540）和外部资源管理器（560）。资源管理器（530）将有限的设备资源配给给应用进程，并帮助实施该配给，以便用户体验既可被预测，也可与有关哪些体验的优先级高于其它体验的策略一致。资源管理器（530）包含资源池（例如池（541））阵列。该阵列表示设备上的资源，至少是可用于资源管理器（530）的客户机的资源。资源管理器（530）使用多个池，而非一个大池，以便给定池中的资源可被标记为用于特定工作负荷类型。例如，一个池可用于前台用户体验，另一池用于没有UI的后台活动等。通过此方式，可针对各种工作负荷类型对设备上的资源做出预算。

基资源集管理器（540）针对资源集子类的通用资源集（即，基资源）处理各种操作。基资源集管理器（540）保留各种类型可用资源的列表，在被请求时发出资源（或在无法立即满足请求时，在指定优先级上创建暂挂请求），在被请求时释放资源，通知客户机释放资源（当更高优先级请求进来时），判定何时可允许暂挂请求，以及在允许暂挂请求时通知客户机。

外部资源是资源管理器（530）管理，但是不直接实施的资源。资源管理器（530）依赖于单独的进程（在图5中被示出为外部资源所有者（510）；例如，设备驱动程序）来实际做出实施和强制释放操作。例如，媒体资源（例如，相机、扬声器等）和近距离传感器是外部资源。外部资源管理器（560）判定哪个任务、进程等可访问外部资源，以及何时执行访问，但是依赖于外部资源所有者（510）来实际允许和撤回对外部资源的访问。

在实例实现中，资源集基于执行管理器（520）做出的有关进程正在执行哪种工作负荷类型（例如，后台代理、前台中的UI应用、UI应用暂停等）的决策，描述进程如何运行的规则集。资源集包括一般由基资源集管理器（540）管理的两个资源（CPU和内存）构成的集。资源集还解释多个围绕如何允许进程运行的其它策略决策。在图5中，资源集类型信息被存储在资源集策略表（551）中。例如，对于每个资源集类型，资源集策略表存储(a)进程将在什么优先级类中运行，(b)进程是否有权获取特定外部资源（例如，相机、扬声器、近距离/NFC传感器），如果是，在什么优先级上获取，(c)CPU百分比是否为硬性最大值（即使CPU未被充分使用），(d)在什么级别上，将提交内存警告发送到进程，以及(e)进程可以从前台借用多少CPU百分比（如果有）。

每个资源集类型与一个池关联，该资源集类型从该池中提取其资源。多个资源集类型可共享一个池，在这种情况下，基资源集管理器（540）实施基于优先级的共享，如上所述。

与外部资源管理器（560）不同，资源集管理器（550）在资源实施器（580）和通过工作对象API（591）访问的内核的内核工作对象（590）的帮助下，执行自己的资源集实施。资源集管理器（550）在执行管理器（520）中的各个任务管理器的帮助下，执行自己的强制释放。

实例实现中的接口和类型定义

图6a-6l是伪代码列表（600），其包括在实例实现中用于基于配额的资源管理的接口定义和类型定义。图6a示出PoolType的列表，其指示池类型。图6a-6b还示出类型ResourceInfo()的列表。图6c示出回调接口IbaseResourceInfo()的声明，该回调接口作为接口（552）由外部资源管理器（560）和资源集管理器（550）公开，用于从基资源集管理器（540）回调通知。图6c还示出基资源集的状态定义。类BaseResourceSet（在图6c和6d中声明）包括作为基资源集管理器（540）所公开的接口（542）的一部分的方法，这些方法被外部资源管理器（560）和资源集管理器（550）调用以获取资源或释放基资源集的资源。

图6e示出列举资源集类型的列表。回调接口（IresourceSetCallback）作为接口（547）由任务管理器（571、572）中的每一者公开，并且由资源集管理器（550）调用。图6e和6f包括资源集类型信息的类ResourceSetInfo的列表。图6f示出类ResourceSet的列表，该类包括“Apply”方法。

图6g示出ExternalResourceSet的列表。图6g还列举作为ExternalResourceNotification被发送给外部资源所有者（510）的通知类型。

图6h和6i（顶部）示出由资源管理器（530）（实际是指资源集管理器（550））公开的接口（553）的接口定义。接口（553）包括被调用以获取资源集（AcquireResourceSet）或释放资源集（ReleaseResourceSet）的方法。图6i-6l示出资源管理器（530）所公开的其它接口的定义，例如外部资源管理器（560）所公开的接口（561）。在图6i-6l中，具有“Rm”前缀的方法公开了具有相同名称的平RPC包装器。

实例实现中的池和资源集类型

在高级别上，资源集类型可被视为进程正在实现的方案或工作负荷类型的一部分。例如，前台资源集用于用户的前台UI应用。图7示出实例实现中的资源集类型的信息表（700）。针对不同的资源集类型示出的值是调优典型的高端计算设备所产生的实例值。对于另一类设备（例如，低端设备、中间层设备、高端设备），即使可能的资源集类型不变，值也可能有所不同。或者，在另一类设备的表中，可能的资源集类型也可能有所不同。一般而言，不同类的计算设备可针对资源集类型具有不同的值表。在图7中，系统资源集是伪代码资源集，其表示不受资源管理器（530）管理的操作系统和系统组件的资源使用情况。表（700）可从寄存器或另一数据存储装置中读取。如果表中的项缺少值，则使用默认值。表（700）体现资源集类型和资源预算的策略，而非在代码中实现这些策略。

下表示出图7的表（700）中的字段的定义。

字段	描述	默认值
			池	该资源集从中获取其资源的池。
ResourceSetTypePriority	该资源集类型在其池内的整体优先级。换言之，是指检查资源集以查看最新可用的资源是否满足其暂挂请求的顺序。当各个资源集的优先级相同，或者不严格排序时（例如，一个集具有优先级1上的资源A和优先级2上的资源B，另一集具有优先级2上的资源A和优先级1上的资源B），该字段充当决胜因素。	1
			CPU优先级	该资源集获取其CPU的优先级。较高优先级请求（位于同一池内）可使CPU资源被强制释放，这进一步导致任务管理器（571、572）终止进程。这不同于CPU（线程）优先级的内核（590）概念。	1
CPU量	保证给进程的CPU百分比。
			提交内存优先级	该资源集获取其内存的优先级。较高优先级请求（位于同一池内）可使资源被强制释放，这进一步导致任务管理器（571、572）终止进程。	1
提交内存量	进程可提交（即，分配）的最大内存量。任何超过该点的分配尝试都会失败。
			相机优先级	该进程可获取相机资源的优先级。值可以是“NotAllowed”，在这种情况下，该进程根本无法获取资源。除了NotAllowed之外，当获取资源时，该优先级可被外部资源所有者（510）传递的显式优先级覆盖。	NotAllowed
扬声器优先级	请参阅Camera Priority。对于每个外部资源类型，存在一个对应项。相机和扬声器仅是实例。	NotAllowed
			CPU租借	可从前台资源集或前台池中借用的CPU值的量。	0
硬性CPU限制	进程是否具有即使在空闲CPU周期可用的情况下，也被其资源集封顶的CPU使用量。该字段有利于验证进程可在最坏情况条件下成功运行。	No
			提交内存警告	资源管理器（530）向宿主发送消息，警告其正接近提交限制的级别。
可终止？	低内存句柄（531）是否被允许结束进程。	No
			优先级类	内核（590）针对CPU，也可能是I/O和物理内存赋予进程的优先级。	NORMAL_PRIORITY_CLASS

图8示出池信息的表（800）。针对不同的池示出的值是调优典型的高端计算设备所产生的实例值。对于另一类设备（例如，低端设备、中间层设备、高端设备），即使可能的池不变，值也可能有所不同。或者，在另一类设备的表中，可能的池也可能有所不同。一般而言，不同类的计算设备可针对池具有不同的值表。表（800）可从寄存器或另一数据存储装置中读取。表（800）体现池和资源预算的策略，而非在代码中实现这些策略。

在具有多个核的计算设备中，工作对象API（591）允许为进程分配单个CPU的百分比或所有CPU的百分比。默认情况下，针对所有CPU应用CPU量，这样便可利用使用多核所产生的性能和电池提升。备选地，内核（590）可允许将不同的百分比分配给不同的CPU。

通过资源集类型中的限制，已经限制了后台应用可使用的CPU百分比。但是即使在这些限制下，后台应用也可间接地干扰前台任务，例如(1)通过做出阻塞前台的I/O请求的I/O请求，或者(2)通过使用物理页，从而使前台分页。为了解决这些问题，资源管理器（530）可管理对作为资源的I/O和内存物理页的优先级访问。例如，表（700）指示每种资源集类型的优先级类。通常，后台资源集类型具有优先级类PROCESS_MODE_BACKGROUND_BEGIN。除了降低I/O优先级和分页优先级之外，它还降低CPU优先级，这是可接受的，因为其它资源集具有自己的CPU百分比限制，一旦达到这些限制，较低优先级进程（例如以PROCESS_MODE_BACKGROUND_BEGIN作为优先级的进程）便会运行。出于某种原因，如果降低的CPU优先级有问题或不理想，则资源实施器（580）可调用方法以独立于CPU优先级手动设定I/O优先级和分页优先级。表（700）然后可被更新为分别包括与这些优先级中的每个对应的列。

资源管理器（530）还具有内存垃圾回收作用。资源实施器（580）通过工作对象API（591）支持在进程的内存接近其提交限制时发送通知。资源管理器（530）侦听此通知并且可在通知中查找对应于进程ID的任务主对象。如果pTaskHost->HashRunningTask Instance()为真，则资源管理器（530）调用TaskHost::SendCommand(REDUCEMEM_HOST)。通过检查运行中的任务实例，资源管理器（530）避免停止或冻结应用。当任务宿主接收到REDUCEMEM_HOST通知时，可执行垃圾回收。为了避免大量的垃圾回收调用，资源管理器（530）可以仅在级别增加1 MB或更多时通知应用。在图7所示的表（700）中，警报级别的值位于字段CommitMemoryWarning中。

当低内存句柄（531）检测到低可用的物理内存时，它会将REDUCEMEM_HOST消息发送到所有活动的任务宿主。这样可使宿主有机会释放内存（如果它们可以这么做），最有可能经由垃圾回收实现此释放。

实例实现中获取和释放资源集的实例

图9示出资源集的状态的状态表（900）。资源集可被释放、暂挂或获取。有些状态转换与通过资源集管理器（550）所公开的接口（553）实现的调用（例如，任务管理器对图6h中定义的AcquireResourceSet方法的调用）关联。其它状态转换与发送到任务管理器的回调通知（例如，通过在图6e中定义的IresourceSetCallback接口（574）实现的通知）关联。

在图9中，为了获取用于进程的资源集，任务管理器调用pResourceManger->AcquireResourceSet(resourcesettype, pCallback, &fPending, &pResourceSet)。资源集管理器（550）查找对应的池并从该池请求资源。如果资源立即可用，则资源集管理器（550）以fPending==false（假）返回。

如果来自基资源集的资源并非立即可用，则fPending将为真，除非调用方已经指定其愿意立即放弃。如果可以从较低级别进程中强制释放不可用的资源，则基资源集管理器（540）帮助释放资源。图10a是序列表（1001），该表示出这种情况下的方法调用、返回、通知等。任务管理器调用资源集管理器（550）所公开的接口（553）的AcquireResourceSet方法，这样会调用基资源集管理器（540）所公开的接口（542）的AcquireResource方法。在这种情况下，如通过回调接口（552、574）实现的通知中所示，资源不可用（fPending=true（真））。基资源集管理器（540）还通过资源集管理器（530）所公开的回调接口（552）发送通知，以便通过上一任务管理器所公开的回调接口（574）触发通知，从而要求上一任务管理器从较低优先级资源集中释放资源。上一任务管理器与内核（590）协调以终止使用较低优先级资源集的进程。当进程终止时，通知资源管理器（530）。资源管理器（530）通知资源集管理器（550），该资源集管理器接着通过接口（542）通知基资源集管理器（540）资源集已被释放。基资源集管理器（540）针对暂挂请求分配资源集，并且通过资源集管理器（550）所公开的回调接口（552）发送“OnAcquired”通知。这样通过应用资源集的任务管理器所公开的回调接口（574）触发通知。

如果资源无法被强制释放（例如，因为它们由较高优先级进程应用），则任务管理器向资源集管理器（550）发出的调用仍将以fPending=true返回。调用方可以等待，直到在将来的某一可能的点，资源管理器（530）看到资源已变得可用。图10b是序列图表（1002），该表示出这种情况下的方法调用、返回、通知等。大多数操作与图10a中的操作相同，但是当前具有已请求的资源的进程正常终止，而非上一任务管理器请求终止。

这样，在实例实现中，进程始终具有应用于它的资源集。当进程首先被创建时，任务管理器创建处于挂起状态的进程，获取资源集，然后恢复进程，以便进程不会临时使用过量的资源。任务管理器被允许将不同的资源集应用于已经具有一个资源集的进程。在这种情况下，资源管理器将释放旧资源集。

对于处于暂停状态的应用，应用被赋予具有“暂停”类型的真实资源集。暂停的资源集类型与前台资源集类型相似，只是CPU百分比保证较小。内存的工作集和暂停的资源集类型的处理优先级不会显著降低——通常应用足够的资源以允许暂停的应用迅速完成并释放其所有内存优于在计时器到期时强制终止应用，这样会损坏应用的持续状态。

在应用丢失前台资源集，并且该应用有机会使用暂停的资源集顺利结束之后的一段时间（例如，20秒），基于配额的资源管理将释放暂停的资源集并将已暂停的资源集应用于进程。已暂停的资源集类型允许应用使用极少量的CPU处理任何离散的事件或回调。在某些实现中，已暂停的资源集类型具有软性CPU限制，以便已暂停的应用可以可能地使用系统中未使用的处理周期。备选地，已暂停的资源集类型具有硬性CPU限制，以便应用不能违反该限制。在这之后的一段时间（例如，60秒），基于配额的资源管理将释放已暂停的资源集，并应用已冻结的资源集，这样通过应用硬性CPU限制0%，有效地禁止使用CPU。某些应用可被设计为直接从暂停的资源集转移到冻结的资源集。

实例实现中的子资源集

在实例实现中，资源集可将其某些资源租借给新的子资源集，然后将这些子资源集授予不同的进程。主实例是将部分资源租借给前台代理的前台应用。另一实例是将自己的多数资源租借给其VoIP通信代理的VoIP UI应用。子资源集通过与正常资源集类似的方式创建，只是调用方手动填充至少某些ResourceSetInfo以描述子资源集的大小，例如，如图11的列表（1100）所示。

资源管理器（530）检验父资源集具有足够的资源以允许请求。如果是，则资源管理器（530）从父资源集中提取这些资源，将更小的新资源集授予该父资源集，然后创建新的子资源集并返回它。父资源集已经使用（例如，通过内存分配操作）的提交内存不能被提供给子资源集。这样，父资源集的当前使用情况可以影响AcquireResourceSet请求针对子资源集是否成功。在父资源集有机会超过其较小的限制之前，在父资源集的生命周期中提早调用AcquireResourceSet更容易成功。支持全递归。因此，调用方可以创建具有固定大小的子资源集，然后使用该子资源集创建被应用于进程的孙资源集。

当子资源集被释放时（通过调用ReleaseResourceSet），资源被返回到其父资源集。如果父资源集已经将任何资源应用于进程，则新返回的资源此时可被（额外地）应用。通过ReleaseSet释放资源的过程是递归的，这样，子资源集便可在其父资源集被释放时也被释放。

因此，池包含可用资源，资源集包含已获取或暂挂的资源。在实现级别上，池和资源集可被实现为同一类的结构。池是正好可用的资源集。当考虑子资源集时，池与资源集之间的等价关系变得更加清楚。在这种情况下，已经被获取的父资源集充当子资源集从中提取资源的池。可用资源的池可被实现为根父资源集。释放资源集的动作表示使该资源集中的资源返回其父资源集。同样，获取资源集的动作表示从父资源集中割掉资源。

实例实现中租借的资源

在实例实现中，某些资源集被允许从前台借用CPU。被允许借用的量可在资源集类型信息中指定，例如，如图7的表（700）中的CPU租借字段中所示。当资源集被授予时，如果作为资源集的一部分的CPU的任何部分被租借，则从前台资源集中扣除该量，或者，如果没有前台资源集，则从前台池中扣除该量。租借量被记录，以便在稍后创建前台资源集时，可以从表（700）中的默认量中减去租借量。当资源集被释放时，租借量被返回到前台资源集或前台池。

如果前台资源集具有后代（子资源集），则从每个后代（包括根）借用的量与后代具有的CPU的量成正比，除以所有后代所拥有的总量。需要注意，以确保借用的总量等于租借的总量，以便防止创建或丢失幻像资源。可通过跟踪从后代借用的量并将从根借用的量设定为余额而非比例来确保上述目的。

实例实现中的外部资源

外部资源通过ResourceType识别，如图6a所示。外部资源由诸如设备驱动程序或服务之类的外部资源所有者（510）所有，但是通过与资源管理器（530）的协调来管理。外部资源所有者（510）可调入外部资源管理器（560），该管理器管理这些不同类型的可用外部资源构成的单个池。外部资源所有者（510）可通过调用RmRegisterResource方法，将其（多个）外部资源添加到池，如图12的列表（1200）所示（另请参阅6i）。或者，外部资源所有者（510）例如可通过向资源管理器（530）注册（通过对应于资源管理器（530）的注册项）诸如DLL之类的库，将其（多个）外部资源添加到池。DLL公开DLL入口点HRESULT Register（IExternalResourceRegister*pResourceRegister），其中IExternalResourceRegister包含图13的列表（1300）中定义的方法。DLL的Register()入口点调用一次或多次pResourceRegister->RmRegisterResource()。在Register返回之后，资源管理器（530）卸载DLL。

对于已被注册的外部资源，fShareable标志指示外部资源管理器（560）可以自由地无限次提供外部资源。但是对于可共享的外部资源，可通过独占模式被请求，在这种情况下，从可用池中提取外部资源，外部资源的其它现有用户搁置对资源的使用。当独占资源被释放时，其它用户脱离搁置。

资源集类型包含策略信息，此信息涉及具有该资源集的工作负荷针对每种外部资源具有什么样的权限。例如，策略信息指示工作负荷是否完全有权获取外部资源，如果是，则指示以什么样的优先级获取外部资源。在图7的表（700）中，前台资源集类型有权获取相机资源，但是后台资源集类型无权获取相机资源。

当具有外部资源的资源集被应用于进程时，会发生多种情况。如果上一资源集有权获取外部资源，而新资源集无此权限，并且进程已经获取资源，则外部资源集被强制释放。该进程的现有外部资源集通过资源集所指示的新优先级进行更新。检查暂挂外部资源的可满足性，因为优先级的变化可能使得请求能够被满足。所有者还可以通过特定的优先级请求外部资源，忽略源自资源集的任何优先级。当资源集对于特定外部资源没有影响时，例如，当外部资源不关心前台状态与后台状态，但是所有者具有某些判定优先级的其它标准时，便可通过特定的优先级请求外部资源。

外部资源被异步获取，因为需要一些时间来使上一获取者释放资源。对外部资源的请求可处于四种状态中的一种，如下表所示：

状态	描述
		已释放	资源未被获取，没有对应的句柄。
暂挂	资源未被获取，但是句柄正在等待该资源，将在该资源被获取时发送通知。
		已获取	资源被获取，表示调用方现在便可使用它。
保留	调用方可保留资源，但是不主动使用它。例如，不拆卸整个媒体栈，而是暂停播放音频。

图14示出外部资源的状态的状态图表（1400）。某些状态转换与通过外部资源管理器（560）所公开的接口（561）实现的调用（例如，来自外部资源所有者（510）的调用（请参阅图6h））关联。其它状态转换与发送到外部资源所有者（510）的通知（例如在图6g中定义的ExternalResourceNotification的值）关联。

当外部资源所有者（510）希望获取一种或多种外部资源（最有可能代表客户机应用）时，该所有者例如调用RmAcquireResources，如图15的列表（1500）所示。如果这些资源以组的形式被保留（例如，这些资源一起被使用，或者都不被使用），则一次可请求一个以上的资源。另一方面，如果外部资源可在其中一个被撤回时（例如，当进入后台时，VoIP应用撤回其视频，而保留其音频）单独使用，则所有者使用单独的请求，以便具有针对请求的每个部分的独立句柄，并且资源管理器（530）将能够单独地针对每个部分发送释放请求或保留请求。图16是序列表（1600），该表示出所有者获取当前被另一所有者（上一所有者）持有的外部资源的序列。

多种类型的事件可导致针对外部资源发送释放请求。此事件创建请求将被发送到的句柄的列表。例如，当具有较高优先级的RmAcquireResources调用进来时，释放一个或多个句柄来满足该调用。或者，当进程已更改其资源集（例如，当进程进入后台时）并且新资源集无权获取特定外部资源时，句柄列表是与该进程关联的所有句柄，这些句柄包含资源集无权获取的外部资源。或者，当进程完成（包括预期外的或异常的进程结束）时，通过执行管理器（520）调用资源管理器（530）来通知该事件，句柄列表是与该进程关联的所有句柄。对于句柄列表中的每个句柄h，资源管理器发送通知，如图17的列表（1700）所示。这样将通知外部资源所有者（510）句柄将被释放，并且该所有者调用RmReleaseResources。

外部资源所有者（510）也可通过调用HRESULT RmReleaseResources(_in ResourceHandle句柄)，自愿地释放资源。资源管理器（530）然后从其表中移除该句柄，并且评价是否可以满足任何暂挂请求。如果不被用于满足暂挂请求，资源将被释放回可用池。

如果所有者进程意外终止，则其资源被释放。为了完成此操作，ResourceHandle类型为RPC上下文句柄。如果所有者崩溃，则RPC基础结构将调用ResourceHandle_rundown()函数，并且RmReleaseResources被调用以释放资源。

V. 实例移动计算设备。

图18是示出一般移动计算设备（1800）的系统图表，该计算设备包括各种可选的硬件和软件组件，这些组件统一由（1802）示出。一般而言，移动计算设备（800）中的组件（1802）可与另一组件通信，但是为了简化说明，未示出所有连接。移动计算设备（800）可以是多种计算设备（例如，手机、智能电话、手持式计算机、个人数字助理（PDA）等）中的任一种，并且允许与诸如蜂窝网络或卫星网络之类的一个或多个移动通信网络（1804）执行双向无线通信。

移动计算设备（800）可包括控制器或其它处理器（1810）（例如，信号处理器、微处理器、ASIC或其它控制和处理逻辑电路），用于执行诸如信号编码、数据处理、输入/输出处理、电力控制和/或其它功能之类的任务。操作系统（1812）可控制组件（1802）的分配和使用，并且支持一个或多个应用（1814）。应用可包括常规移动计算应用（例如，包括电子邮件应用、地图导航工具、日历、联系人管理器、Web浏览器、消息传递应用）或其它任何计算应用。

移动计算设备（800）可包括存储器（1820）和/或其它有形的计算机可读介质。存储器（1820）可包括不可移动的存储器（1822）和/或可移动的存储器（1824）。不可移动的存储器（1822）可包括RAM、ROM、闪存或其它公知的存储技术，或者磁盘驱动器或其它公知的存储技术（例如CD或DVD）。可移动的存储器（1824）可包括在GSM通信系统中公知的闪存或用户身份模块卡，或其它公知的存储器存储技术（例如，智能卡）。存储器（1820）可被用于存储用来运行操作系统（1812）和应用（1814）的数据和/或代码。实例数据可包括经由一个或多个有线或无线的网络被发送到一个或多个网络服务器或其它移动计算设备和/或从一个或多个网络服务器或其它移动计算设备接收的网页、文本、图像、声音文件、视频数据或其它数据集。

移动计算设备（800）可支持诸如触摸屏（1832）、麦克风（1834）、相机（1836）、物理键盘（1838）和/或轨迹球（1840）之类的一个或多个输入设备（1830），以及支持诸如扬声器（1852）和显示器（1854）之类的一个或多个输出设备（1850）。其它可能的输出设备（未示出）可包括压电的或其它触觉输出设备，或者近距离传感器。有些设备不仅仅可提供单独的输入/输出功能。例如，触摸屏（1832）和显示器（1854）可被组合为单个输入/输出设备。

触摸屏（1832）可通过不同的方式接受输入。例如，电容性触摸屏在对象（例如，指尖提供的手势输入或触摸笔）扭曲或中断跨表面运行的电流时检测到触摸输入。作为另一实例，触摸屏可使用光学传感器，在来自光学传感器的光束被中断时检测到触摸输入。不一定要与屏幕表面进行物理接触来使某些触摸屏检测到输入。

无线调制解调器（1860）可与天线（未示出）耦合，并且可支持处理器（1810）与外部设备之间的双向通信。无线调制解调器（1860）被一般性地示出，并且可包括蜂窝式调制解调器，用于与移动通信网络（1804）和/或其它基于无线电的调制解调器（例如，蓝牙或Wi-Fi）通信。无线调制解调器（1860）一般被配置为与诸如GSM网络之类的一个或多个蜂窝网络通信，从而在单个蜂窝网络内，在蜂窝网络之间，或者在移动计算设备（800）与公共交换电话网络之间实现数据和语音通信。

移动计算设备（800）可进一步包括至少一个输入/输出端口（1880）、电源（1882）、诸如全球定位系统接收器之类的卫星导航系统接收器（1884）、加速计（1886）、收发器（1888）（用于以无线的方式发送模拟或数字信号）和/或物理连接器（1890），该连接器可以是USB端口、IEEE 1394（防火墙）端口和/或RS-232端口。所示组件（1802）并非必要的或无所不包的组件，可以删除这些组件，并且可以添加其它组件。

为了进行陈述，详细描述中使用“判定”和“执行”之类的术语来描述计算环境中的计算机操作。这些术语是计算机执行的操作的高级抽象，不应该与人类执行的动作相混淆。对应于这些术语的实际计算机操作根据实现而变化。

VI. 替代选择。

此处提供的实例实现可具有多种替代选择。尽管上面描述的许多实例涉及移动计算设备，但是备选地，可针对其它类型的设备应用这些创新。

在此处描述的许多实例中，池设定被用于从该池提取资源的一个或多个关联的（多个）工作负荷的资源的上限。在其它实施例中，在有限的情形下支持池之间的资源共享，例如通过从前台资源集或前台池租借的资源以便在前台池与一个或多个其它池之间共享资源。备选地，可以从另一类型的池（即，不仅是前台池）租借资源。另外，在池内，可支持在父资源集与一个或多个子资源集之间共享资源。除了这些选项之外，可以在设定计算设备资源整体预算的池信息中调整被分配给各个池的资源。例如，池信息可被调整为重新配置基于配额的资源管理（取决于用户类型（商业用户、一般使用者等）），可在设备上安装哪些应用类等等。总之，基于配额的资源管理提供多种方式来共享资源并且跨池和/或在池内执行资源的负载平衡。

一般而言，参考流程图描述的技术可通过更改流程图中所示的各阶段的排序，通过重复或省略特定阶段来修改。作为另一实例，参考系统图表描述的系统可通过更改图表中所示的处理阶段的排序，通过重复或省略特定阶段等来修改。作为另一实例，尽管某些实现参考特定设备和资源类型进行描述，但是所描述的技术和工具也可用于其它设备和/或其它资源类型。

鉴于可应用所公开的发明原理的许多可能的实施例，应该理解，所示的实施例只是本发明的优选实施例，不应被视为限制本发明的范围。而是，本发明的范围由下面的权利要求定义。因此，我们声明，我们的发明全部落在这些权利要求的范围和精神内。

Claims (10)

1. 计算设备中的一种方法，此方法包括通过所述计算设备的资源管理器执行以下步骤：

接收对要从多个资源池中的一个应用的资源集的请求，所述多个池中的每个与不同的工作负荷类型关联，其中所述多个池至少部分地在所述不同的工作负荷类型当中分别指定所述计算设备的资源预算；

至少部分地基于所述预算评价所述请求；以及

发送对所述请求的回复。

2. 根据权利要求1所述的方法，其中所述计算设备上的数据存储装置存储分别定义所述不同的工作负荷类型的所述多个池的池信息，并且其中对于所述多个池中的每个给定池，所述数据存储装置包括针对所述给定池的处理器使用限制和内存限制。

3. 根据权利要求1所述的方法，其中所请求的资源集具有从多个资源集类型中选择的资源集类型，并且其中对于所述多个资源集类型中的每个，资源集类型信息指定：

一个或多个资源配额，每个资源配额包括资源类型的量值；

池标识符，其指示所述多个池中的一个；以及

一个或多个优先级值，每个优先级值指示所指示的池内的所述资源集类型的优先级。

4. 根据权利要求1所述的方法，其中所述评价包括：

从所述多个池中选择适合于所请求的资源集的池；

基于所选择的池内的当前可用资源和所请求的资源集的资源配额判定所请求的池内是否具有足够的资源可用；并且

如果所选择的池内没有足够的资源可用，则判定从所选择的池中应用的上一资源集是否具有比所请求的资源集低的优先级，并且如果是，则请求释放所述上一资源集。

5. 根据权利要求1所述的方法，其中多个池包括与系统工作负荷类型关联的第一池、与前台工作负荷类型关联的第二池、与后台用户体验工作负荷类型关联的第三池、与后台处理工作负荷类型关联的第四池、分别与特定应用类的工作负荷类型关联的一个或多个池，和/或分别与应用的非激活状态的工作负荷类型关联的一个或多个池。

6. 一种有形的计算机可读介质，其存储计算可执行指令以使计算设备被编程，从而执行一种方法，此方法包括通过所述计算设备的任务管理器执行以下步骤：

从与多个资源池关联的多个资源集类型中选择资源集类型，所述多个池中的每个与不同的工作负荷类型关联，其中所述多个池至少部分地在所述不同的工作负荷类型当中分别指定所述计算设备的资源预算；

发送对所选择的资源集类型的资源集的请求；以及

接收对所述资源集的请求的回复。

7. 根据权利要求6所述的计算机可读介质，其中对于所述多个资源集类型中的每个，资源集类型信息指定：

一个或多个资源配额，每个资源配额包括资源类型的量值；

池标识符，其指示所述多个资源池中的一个；以及

一个或多个优先级值，每个优先级值指示所指示的池内的所述资源集类型的优先级。

8. 根据权利要求6所述的计算机可读介质，其中所述方法进一步包括：

接收请求以执行任务，其中所述选择资源集类型和发送对所述资源集的请求响应于执行所述任务的请求；

如果对所述资源集的请求的回复是接受，则启动所述任务并将所述资源集应用于所述任务；

如果对所述资源集的请求的回复是拒绝，则将对所述资源集的请求放入队列以做后续处理；并且

如果对所述资源集的请求的回复是有关对所述资源集的请求是暂挂资源释放的指示，则在通知释放资源时，启动所述任务并将所述资源集应用于所述任务。

9. 根据权利要求6所述的计算机可读介质，其中所述方法进一步包括启动任务并将所述资源集应用于所述任务，并且其中对于所述任务，操作系统根据所选择的资源集类型实施资源预算。

10. 一种移动计算设备，其包括处理器和存储适应所述移动计算设备的资源的预算信息的存储器，所述预算信息包括：

多个资源池的池信息，所述多个池中的每个给定池与不同的工作负荷类型关联，其中所述多个池至少部分地在所述不同的工作负荷类型当中分别指定所述移动计算设备的资源预算，对于所述多个池中的每个给定池，所述池信息包括：(a)与所述给定池关联的所述不同的工作负荷类型的内存限制，以及(b)与所述给定池关联的所述不同的工作负荷类型的处理器使用限制；以及

多个资源集类型的资源集类型信息，对于所述多个资源集类型中的每个给定资源集类型，此信息包括：(a)一个或多个资源配额，所述一个或多个资源配额中的每个包括资源类型的量值；(b)池标识符，其指示所述多个池中的一个，以及(c)一个或多个优先级值，每个优先级值指示所指示的池内的所述资源集类型的优先级。