CN105453042A

CN105453042A - 针对服务连接应用而预取内容

Info

Publication number: CN105453042A
Application number: CN201380077386.XA
Authority: CN
Inventors: M.梅里; M.伊根; J.埃尔德里奇; M.克拉尔; L.奥斯特曼; C.米勒; S.萨达; Z.布朗; A.基尚
Original assignee: Microsoft Technology Licensing LLC
Current assignee: Microsoft Technology Licensing LLC
Priority date: 2013-06-12
Filing date: 2013-09-20
Publication date: 2016-03-30
Anticipated expiration: 2033-09-20
Also published as: EP3008592A1; CN105453042B; WO2014200527A1; US20140373032A1; EP3008592B1

Abstract

公开了用于在计算机系统中针对终止或挂起并可以由计算机系统预启动的应用而预取数据的系统和方法。应用可以采用在计算机系统远程处并可从第三方内容资源可得的数据。用于预取这样的远程数据的方法包括：将应用的集合与这样的数据和/或其位置相关联；确定预取条件集合，确定可以预取哪些应用，以及如果预取条件满足所期望的预取策略则预取数据。可以使用预测模块或技术来识别可以预启动的那些应用。本系统可以包括预取成功模块，其能够度量针对当前预取的成功数据并且将这样的成功数据与应用相关联以改进未来的预取。

Description

针对服务连接应用而预取内容

背景技术

随着应用越来越多连接至互联网服务，这些应用倾向于从这些服务要求更多数据。可能期望使得这些应用尽可能快地获得该数据。

服务集成对于应用开发者展现了机遇和挑战。一方面，服务集成允许应用紧跟最新内容，但是其对于应用开发者提出了获得该内容的挑战。通常，下载内容是简单的事情；然而，这种代价高的网络操作通常发生在应用启动处。这导致了以下用户感知：应用不是最新的——例如当它们起动时它们必须命中网络以获得内容并且用户必须等待。

这倾向于导致整体较差的用户体验，尤其是当用户第一次启动他们的应用时。可能期望通过在应用需要应用内容之前取得所述应用内容到设备而改进整体应用体验。

发明内容

以下展示了本发明的简化概述以便于提供对本文描述的一些方面的基本理解。本概要并非是所要求保护的主题的详尽概述。其意在既不标识所要求保护的主题的关键或必要元素，也不勾画主题创新的范围。其目的仅在于以简化形式展示所要求保护的主题的一些概念作为稍后展示的更详细描述的前叙。

公开了针对计算机系统中被终止或挂起并且可以由计算机系统重新启动的应用预取数据的系统和方法。应用可以采用在计算机系统远程处并且从第三方内容源可得的数据。用于预取这样的远程数据的方法包括：将应用的集合与这样的数据和/或其位置相关联；确定预取条件的集合，确定可以预取哪些应用，以及如果预取条件满足所期望的预取策略则预取数据。可以使用预测模块或技术来识别可以预启动的那些应用。本系统可以包括：预取成功模块，其能够度量用于当前预取的成功数据并且将这样的成功数据与应用相关联以改进未来的预取。

在一个实施例中，公开了一种针对应用预取数据的方法，包括：将应用的集合与数据的集合相关联，所述数据能够从内容源的集合检索；确定预取条件的集合，所述预取条件包括组中一项，所述组包括：系统源可用性，对于应用是否可以被预启动的预测性度量，与针对预取的用户设置有关的数据，与针对给定应用的之前预取是否成功有关的数据；确定可以预取哪些应用；以及如果所述条件的集合满足给定策略，则执行从所述内容源预取数据。在预取之后，可以存储数据并且使所述数据可用于应用。

在另一实施例中，公开了一种用于针对应用预取数据的系统，包括：API的集合，每个这样的API与应用相关联并且每个所述API能够存储将要针对所述应用而预取的数据；预取发起器策略模块，所述预取发起器策略模块能够依赖于预取条件的集合而发起预取进程；预取进程模块，所述预取进程模块能够针对由所述预取发起器策略模块识别的应用从远程内容源预取数据；以及计算机存储装置，所述计算机存储装置能够存储来自所述远程内容源的所述预取的数据，以使得可以使所述预取的数据可用于所述应用。

当结合本申请内展示的附图来阅读时，在以下详细描述中展示了本系统的其他特征和方面。

附图说明

在附图的参考图中图示了示范性实施例。意图在于，本文公开的实施例和图应该被视作是说明性的而不是限制性的。

图1描绘了如根据本申请原理的本系统可以驻留在的示范性环境的一个实施例。

图2示出了如根据本申请的原理而做出的本系统的一个实施例。

图3以流程图示出了在本系统的操作的一个实施例。

图4和图5描绘了预测器模块及其在用于预启动的应用上的操作的一个实施例。

图6描绘了可以与本申请的预取操作协作使用的一个自适应预测器。

图7描绘了可以与本申请的预取操作协作使用的一个切换率预测器。

具体实施方式

如本文利用的，术语“部件”、“系统”、“接口”、“控制器”等等意在指代计算机相关的实体，或者硬件、软件（例如在执行中的）和/或固件。例如，这些术语的任意术语可以是运行在处理器上的进程、处理器、对象、可执行文件、程序和/或计算机。作为例证说明，运行在服务器上的应用和服务器均可以是部件和/或控制器。一个或多个部件/控制器可以驻留在进程内，并且部件/控制器可以本地化在一个计算机上和/或分布在两个或多个计算机之间。

参照附图描述所要求保护的主题，其中同样的附图标记用于自始至终地指代同样的元素。在以下描述中，出于说明的目的，阐述许多具体细节以便于提供对题述创新的全面理解。然而可以显然的是，可以在没有这些具体细节的情况下实践所要求保护的主题。在其他实例中，以方框图形式示出了公知的结构和设备以便于促进描述题述创新。

预取服务连接应用的概述

本申请的许多实施例实现本系统、方法和/或技术针对服务支持应用来预取数据以实现改进的用户体验。在许多实施例中，本系统允许典型地可以（例如使用标准的HTTP或其他协议）从服务器获取数据的任何应用能够利用这种预取。在一个实施例中，可能期望的是，需要取得内容的应用在向用户显示任何有用内容之前就这么做。在一些实施例中，本系统可以在某些应用类别之间分辨出更典型地落入该类别中的应用。例如对于这样的应用的仅几个类别，以下是象征性的列表：

1.娱乐

2.新闻和天气

3.购物

4.体育

5.旅游。

在这些类别中的应用可以代表典型应用商店中超过25％的应用。因为这些应用的许多应用在销售时被预装在计算机系统中，所以几乎所有用户都可能具有可以得益于本申请的技术的一个或多个应用。对于仅仅一个示例，考虑典型的新闻应用。新闻应用按照其定义面对获得内容——即，最新的新闻——并且当应用被启动时将其显示给用户的问题。当新闻阅读器应用起动时，其获取最新的新闻并且然后向用户显示文章。

当前，应用激活可以典型地被分解成两个阶段。阶段一抢先直至应用向用户展示任何用户界面（例如飞溅屏幕解除），并且包括在启动和准备应用进程时由OS进行的许多“设置”。阶段二在解除飞溅屏幕之后到来，并且应用代码接管并且设置其画布以向用户显示信息。

关于服务连接应用，通常阶段二包括：从服务检索信息，准备该信息以用于显示以及最终显示该信息。在这样的情况下，用户可能在应用从其服务获取数据时面对指示等待时段的图标——例如“旋转的多纳圈”或其他进度指示器。获得内容所花费的（或者另外，在应用正在获得内容以向用户显示的状态下所花费的）时间量可以取决于许多变量，例如网络连接性、网络速度、服务器的可用性以及要下载和解析的内容的量。

在从从外部资源下载内容的服务连接应用收集采样数据时，发明人已经注意到几个感兴趣的统计量：

1.由服务连接应用下载的大部分内容是图像内容；

2.在忽略视频下载（例如从Hulu或SportsIllustrated或其他流处理视频应用和/或类似物）之后，图像内容表示了全部内容的近似75％；以及

3.大多数这样的所下载的图像内容的大小在100kB以下。

示范性环境

在本申请的若干实施例中，存在本文展示的、允许与计算机系统远程处的内容源服务连接的应用根据需要预取这样的内容的实施例和方法。

图1是预取服务连接应用可以驻留在的示范性环境的一个实施例。如图1中可见，本系统的实施例可以安装在计算机系统102内。合适的计算机系统可以包括任意数目的系统，例如PC/台式机102a、膝上型电脑102b、平板电脑102c、或任何智能设备、智能电话。可以足够的是，系统具有充足的处理和存储能力以运行本发明的系统。

计算机系统102可以进一步包括控制器104，控制器104可以进而具有一个或多个处理器（例如CPU和/或GPU）以及计算机存储器，如本领域已知的。计算机系统102可以进一步具有操作系统106，操作系统106安装在存储器中并且工作以控制可以由计算机系统的用户激活的各种应用的寿命周期。

本申请的一个实施例可以具有已安装的预取模块108，其可以与操作系统106协同工作以实现本系统的方法和技术以及它们各种实施例，如本文描述的。

如以下更详细描述的，应用1（110a）至应用M（110m）可以驻留在计算机系统中，并且可以处于任何给定的进程状态——例如运行、非运行、挂起等等。这些应用可以服务连接至数个内容源（例如112a至112n）——也许通过任何已知协议经由互联网112（或经由已知的任何其他网络和/或远程访问协议）。

在本系统的其他实施例中（并且如以下更详细讨论的），可以与任何特定计算机系统远程地安装（整体或部分地）预取。预取模块可以经由客户端-服务器模型（或任何其他合适的模型）而对于计算机系统可访问。

一个实施例

在一个实施例中，系统可以为应用提供机制以指示这些应用所需的内容的集合。在一些实施例中，存在应用可以指示这种内容的多种方式。例如，应用可以：

（1）经由统一资源标识符（URIs）直接地指示内容；和/或

（2）响应于对web服务做出的请求而指示内容。

在另一实施例中，来自以上（1）和（2）的内容的组合可以是可能的——例如，考虑将内容和源二者混合，或者在客户端上提供关于操作系统如何解释在（2）中返回的内容的额外信息。此外，可以可能的是，可以经由应用注册在安装时刻指示内容，或者通过调用操作系统部件在运行时刻指示内容。

一旦获得了该信息，本系统的一个实施例可以为OS提供机制以获得如应用所指示的内容。期望的是，针对内容的预取而提供的这种机制自动可用于应用。

在另一实施例中，本系统可以为应用提供透明的回退机制以用于未预取的内容——以使得应用可能无法区分预取的内容与非预取的内容之间的差别。

在又一实施例中，可能期望的是，本系统提供这样的机制以通过监视系统资源（例如CPU利用、GPU利用、存储器利用、I/O利用、电池充电状态）、度量预取操作对给定应用的益处和/或尊重用户设置来确保预取不会负面地影响用户体验。这些系统资源可以形成条件的集合——例如阈值测试等等——以确定预取是否（例如总的来说）对于用户体验有益。对于仅仅一个示例，如果某些系统资源在阈值水平以下，则预取操作可能负面地影响本用户体验——并且预取可以不发生。

在一些实施例中，本系统可以确定需要预取的应用可以被用户激活和/或发起的可能性的度量。如果给定的应用可能被激活（例如被一些预测模块和/或方法），则本系统可以用可用系统资源的量抵消——例如应用激活的高可能性。在一个实施例中，系统资源和激活的预测性度量可以动态地改变要确定的预取的条件。例如，应用激活的高可能性可以降低具有某种量或水平的系统资源的条件。

此外，本系统可以为应用开发者提供机制以验证针对他们的应用的预取的最优机能。

图2描绘了在示范性环境（200）中的系统和方法的一个可能实施例——如根据本申请的原理做出的。

如从以上图1注意到的，应用可以经由互联网或其他网络（经由任何已知的协议）而服务连接至内容源（例如第三方服务114）。本系统可以被表示为用于这样的服务的客户端。

在一个实施例中，本系统可以包括一个或多个以下模块：

1.预取发起器进程（202），负责起动预取操作；

2.预取操作/进程（206），在执行预取操作的应用（诸如应用容器——或某类似种类的应用情境）的情境中运行；和/或

3.应用运行时间（客户端）API（212），用于检索所预取的内容。

在一些实施例中，预取发起器进程可以进一步包括预测和/或预测器模块，如本文进一步讨论的。可以可能的是，使预测模块与计算机系统分离地驻留——例如在服务器上，并且预测模块可用作基于云和/或基于服务器的应用。在任一情况下，可能期望从用户的群体聚集预测结果并且跨数个用户而共享预测结果。

这些应用运行时间API（212）为应用提供机制以指示需要被预取的内容的集合。在一些实施例中，可以存在API的分立集合（例如，在预取操作/进程206与高速缓存208之间），应用可以使用所述API的分立集合来检索所预取的内容。

在一个实施例中，客户端API可以由应用和预取服务（其可以在后台运行）采用以设置或者检索预取URI的列表。后台任务可以与第三方内容提供者通信以获得在给定URI处的资源，并且可以收集反馈并且将该反馈通信至预取服务以演进预取模块。客户端API可以与可以基于应用的应用容器而划分的耐久URI存储库交互。后台任务和应用代码均可以经由HTTP客户端API与内容高速缓存直接或间接地交互。

如图2中所示，这些模块中的若干个可以驻留在当前由用户采用的本地（或计算机）系统内的应用容器中。此外，若干模块可以驻留在计算机系统中并且与操作系统协作地工作。

将认识到的是，本系统可以被不同地架构（其中不同的模块驻留在计算机系统的不同部分中或者在计算机系统远程处），并且本申请的范围涵盖了这样的不同实施例和架构。

图3是用于本申请系统的高等级流程图（300）的一个实施例。本发明的系统可以开始于302。作为初始化的一部分，本系统可以接收（在304处）与可能需要来自第三方源的内容的应用有关的数据和/或元数据——以使得本系统可以将应用识别为用于预取的潜在候选。本系统可以将该数据和/或元数据与给定的应用相关联和/或注册到给定的应用。在一些实施例中（如本文讨论的），关联性可以给出需要针对给定应用而预取的数据的地址或其他位置标记（例如URL）。

在306处，本系统可以（以期望的时间间隔——或在任何其他合适的基础上）检查系统和/或用户条件以了解是否应该执行预取。如以下将更详细讨论的，这样的条件可以包括：系统资源是否处于其中执行预取可以不影响当前用户体验（例如通过减慢对于当前运行的应用等等的系统响应）的点；是否可能存在可以由用户激活的应用并且预取第三方内容将客观地改进用户体验。在一些实施例中，可能期望预测哪些应用可以被激活——以及在计算机系统上可用的情况下，哪些应用将被预启动。预启动模块可以用于识别和/或预测哪些应用可以有可能从非运行或挂起状态被激活。

如果不满足条件，则系统可以操作测试这样的条件的连续循环，并且在可以满足这样的条件的情况下和/或当可以满足这样的条件时进行。

如果满足充分条件，则本系统可以进行至步骤310。本系统在该点处可能希望在所有可能候选之中确定哪些应用将被排队用于预取。本系统可以根据由本系统所确定的一个或若干预取条件而确定和/或排序用于预取的应用的列表。对于仅一个示例，应用可以按照它们的预启动或启动的可能性而被排序，按照它们对于可用系统资源的影响而被排序，按照用户偏好而被排序，按照预取的之前成功而被排序，和/或以上因素的任意组合等等。

一旦已经识别了用于预取的一个或多个应用，本系统可以在312处执行实际的预取。在一个实施例中，这样的预取可以在本系统的后台进行——其可以对于用户透明地进行；并且因此，改进了计算机系统的用户体验。在其他实施例中，这样的预取可以在前台或可能的其他进程状态中进行。将认识到的是，这些特定步骤的次序可以互换以实现相同、相似和/或可替换的实施例。例如，本系统可以确定预取条件，确定可以预取哪个应用，并且然后可以在针对应用预取任何数据之前对照数个策略、规则和/或启发法来测试预取条件。本申请的范围涵盖所有这样的实施例。

一旦完成，本系统可以可选地执行数据收集步骤（在314处）以度量预取的成功。成功数据可以反映相同数据中的一些作为预取条件。例如，成功数据可以包括：当前预取对系统资源的影响，被预取的应用是否实际被启动，预取的资源是否实际可用和/或被应用利用等等。依赖于成功数据，然后可以可能动态地改变针对预取的策略中的一些——例如，可以利用预取条件的。这可以导致对本系统的改进。

如所述，预取进程可以在数个模式下操作：（1）其中预取进程获得由对API的调用指示的URI的列表并且针对列表中的每个URI执行预取；（2）其中预取进程能够按照对预取请求的响应来行动并且依赖于对于预取请求的响应，获取可以被重试或者可以被重定向至另一URI；（3）其中预取进程可以获得URI，所述URI指向合式的URI列表；和/或（4）其中应用指示操作系统如何解释从服务返回的特定于应用的数据以确定预取URI的集合。可以通过对URI做出请求而获得该列表，并且一旦成功响应就验证列表格式。一旦被验证，列表中指示的URI就自身被获取。同样，预取进程可以能够按照对预取请求的响应来行动并且可以被恰当地重试或者重定向至另一URI。在一些实施例中，可以可能使得服务向目标指示新数据是可用的。在这种情况下，本系统可以实现基于“推送”的模型。这可以在一些情况下绕过针对新内容进行轮询的步骤——因为先验知晓了新内容是可用的。

在成功检索到由预取URI指示的资源时，可以将内容存储在由应用可访问的高速缓存中。高速缓存的寿命可以由OS管理并且可以保持任意长的时间。

预取进程可以额外地提供每个操作的详细日志记录以及所述操作的成功/失败以使得开发者能够诊断在预取操作中的故障。

如果由预取发起器进程指示，预取进程可以计算之前预取的益处。可以通过分析之前预取的内容并且确定该内容是否被应用访问而计算得分。如果内容被访问，这可以指示好的得分。如果内容未被访问，其可以指示坏的得分。然后可以将针对预取操作的得分报告回预取发起器进程。如果系统指示发生缺乏资源条件，预取进程终止。

在运行时间，应用可以对在特定URI处的资源做出请求。该请求可以首先查阅本地高速缓存，并且如果对于所请求的资源在高速缓存中存在有效条目，可以从高速缓存提供资源。如果内容并未存在于高速缓存中，则使用所提供的URI从服务请求内容。典型地，这些请求将是经由HTTPAPI做出的HTTP请求。如果预取器已经预取了所请求的资源，并且该资源在高速缓存中仍然有效，则请求可以来自高速缓存，这倾向于比从远程服务器传递内容更快。当应用从高速缓存检索资源时，追踪该检索以使能计算在预取进程中的益处得分。

本文描述了关于这些各种步骤和技术的额外细节。将认识到的是，用于服务连接应用的预取的其他实现方式是可能的，并且本申请的范围涵盖了那些可替换的实现方式和/或实施例。可以足够的是，本系统识别可以受益于预取的应用，识别针对这样的预取的适当机会和/或条件，并且当这样的机会和/或条件出现时允许针对预取的合适候选预取这样的第三方内容。

客户端API

此外，可能期望提供API以使得应用开发者能够指示要针对应用预取哪个内容。如之前所述，存在实现这一点的数个机制。例如，可以经由URI列表直接指定内容并且将其存储在计算机系统中（或计算机系统远程处）的可选的URI存储库214中。可替换地，可以响应于由应用代码210对web服务做出的请求而指定内容。

此外，针对客户端API的这些多个操作模式可以相互协同使用。在一个模式中，开发者可以调用API并且提供要预取的URI的列表。开发者可以在他们的应用的运行时间期间的任意点更新该列表。在另一模式中，开发者可以调用API以提供单个URI，其指向服务器宿管的要预取的合式的URI列表。可以在预取操作的时刻解析该列表以使得在预取之前获得列表的最新版本。

特别地，由应用提供的URI可以是HTTPURI。一旦调用了这些API的任一个，应用被视作是可预取的。可以由预取发起器发起针对应用的预取操作。

以下是客户端API的一个可能实施例：

此外，可能期望添加检索关于对该API的上次预取操作的信息的能力。对于所提供的信息的一个示例可以是上次预取时间以及获得了多少内容，以及所有尝试的状态。

作为可替换情况，本系统可以提供URL的XML纲要化列表。可能期望的是，获取该URL返回类型应用/xml的将要预取的内容URL的良好格式化的XML列表。以下是XML纲要的一个可能实施例：

预取发起器进程

在许多实施例中，预取发起器进程可以追踪选取到预取中的应用并且做出预取哪些应用的判定。

如本文许多实施例中讨论的，本系统可以确定数个预取条件——例如可能与是否应该发生预取的判定密切相关的那些条件。例如，本系统可以正在监视：系统资源可用性，对于给定的应用是否可以被预启动和/或可能被用户激活的预测性度量，以及关于针对给定应用的过去预取是否可以已经成功的数据。

这些条件可以用于制订和/或通告数个预取策略规则，所述数个预取策略规则可以确定——例如考虑到这些条件（可能作为阈值测试和/或某种启发法）——是否实际预取数据。存在许多不同的判定策略，预取发起器可以实现所述判定策略以便于判定预取哪个应用。这些策略在一些实施例中可以被实现为规则和/或启发法的集合：

1.系统和用户策略：如果用户已经授权准许在给定系统状态下的预取并且如果满足网络、电池和CPU资源的系统指标——例如如果某种系统资源可用性超过期望的阈值量，则可以执行预取。

2.之前预取益处：可以针对已经在过去预取中展现益处的应用来优先化预取。预取进程负责计算该益处得分并且将其提供回发起器进程。可以使好的得分优先于坏的得分。

3.应用使用：可以对于操作系统预启动的应用执行预取。预启动模块可以实现数个预启动策略——包括简单预启动、侵略性预启动和预测性预启动。在一个实施例中，系统可以确定对于以下的预测性度量：给定的应用是否可能被用户激活；并且因此，将是用于被预启动的候选。在另一实施例中，可以可能预取而不预启动。其他规则可以关于用户是否可能使用特定应用而指导系统。

针对预取发起器进程模块的第一实施例将使得用户和/或系统识别可以受益于预取的那些应用。在这样的情况下，系统可以根据一些简单规则和/或启发法而执行预取。例如，可以根据应用的给定状态（例如挂起或非运行）而执行预取。此外，可以仅当某一等级系统资源（例如处理、通信和存储器的阈值量）可用时执行预取。还可以对预取进程施加沙盒化（sandboxing）策略以进一步约束其对设备的影响（例如低的CPU、I/O和存储器优先级）。这种规则/启发法可以倾向于保持计算机系统的用户体验在预取时间期间不受影响。

针对预取发起器模块的第二实施例可以是基于对于预取某些应用的过去益处。本系统可以维持关于哪些应用过去曾被预取并随后被用户激活的统计量。针对预取应用的测量或估算的节省时间（对比当应用未被预取时）可以形成用于预取应用的规则集合。例如，如果预取任何给定应用的益处在益处超过阈值，则可以预取应用——当在给定状态下时和/或根据系统资源。

在一个这样的实施例中，预取发起器进程可以确定是否要针对过去预取尝试而计算益处得分。这是通过追踪上次预取的时间和上次应用启动的时间而判定的。如果在从上次预取开始的时间段中已经启动了应用，则预取发起器进程将请求预取进程计算益处得分。该得分由预取发起器进程存储并且用于判定未来的预取操作。

针对预取发起器模块的第三实施例可以基于操作系统是否已经识别了用于预启动的某些应用。这样的预启动（以及它何时以及对哪些应用发生）可以在规则和/或启发法的集合之下执行。在一些实现方式中，针对预启动的规则可以是简单的、侵略性的和/或基于何时可以激活应用的预测。

可选的预启动

如所讨论的，针对预取的一个实施例可以并入可以驻留在计算机系统中的任何系统预启动策略。如这里所公开的，存在要实行的数个预测和预启动模块和/或技术。

系统400包括可以驻留在操作系统中、运行在计算机系统（例如智能电话、智能设备、平板电脑、膝上型电脑、台式机等等）内的处理器上的数个（可能可选的）模块。在可替换的实施例中，这些模块中的一些（或所有）可以驻留在远离操作系统处——但是与计算机系统的操作系统通信。应当认识到的是，本系统有数个可能的实现方式，并且本申请的范围涵盖了所有这些可能实现方式和/或实施例。

预启动服务模块402包括处理模块的集合——例如预测引擎404、资源监视器406、预启动策略408和预启动队列410。预测引擎404可以包括规则和/或启发法的集合，其可以辅助本系统评估由计算机系统的用户要求和/或期望运行的特定应用的概率，如本文详细所述。资源监视器406可以评估计算机系统的资源的利用——例如用于潜在预启动应用的当前可用处理和/或存储器资源。预启动策略408可以向本系统通告对于本系统何时期望地预启动一个或多个应用的规则和/或启发法。预启动队列410可以访问关于已经预启动和/或期望预启动的应用的数据和/或元数据的集合。

将认识到的是，这些模块的一个或多个出于本申请的目的可以是可选的。可以足够的是，本系统能够确定哪些应用是用于预启动的“好”候选——例如是否因为被用户选择的概率，因为用于预启动应用的可用资源，因为规则和/或启发法已经选择了特定应用以用于预启动——或者以上因素的任意组合。

可以经由例如允许其他模块访问本系统的外部接口和/或API412的集合而访问这些模块。例如，服务机构414可以向系统402发送标识了已经预启动的应用的信号。进程寿命管理器（PLM）416可以请求用于可能应用的预测数据以考虑预启动。预启动API418可以从系统402接收信号以预启动特定应用。在一个实施例中，PLM可以负责判定对于任何应用的当前应用执行状态——以及判定哪些应用应该保留在存储器中（挂起）对终止。

图5描绘了如在应用的生命周期期间本系统可以实现的针对应用的一个状态图500。通常，运行和/或可用于计算机系统的应用可以包括多个状态——例如非运行502、运行504和/或挂起506。如可见，如果应用处于非运行状态502，则应用可以以数个不同方式被引入运行状态504。例如，应用可以由用户启动。在另一示例中，应用可以由本系统预启动，依赖于数据/元数据——和/或对本系统的规则/启发法的满足，所述规则/启发法确定是否应该预启动给定的应用。

将认识到的是，出于本申请的目的，合适的“用户”可以是计算机系统的人类用户——或者其可以是可能期望执行/挂起/终止讨论中的应用的另一应用。本申请的范围涵盖所有这样的形形色色的“用户”。

当应用处于运行状态504时，则该应用可以由计算机系统的合适用户置于挂起状态506中。此外，运行的应用可以由计算机系统的合适用户终止。这些转变可以整体或部分地由本系统实现。如果应用处于挂起状态506，则讨论中的应用可以由合适的用户恢复——或者可以例如由PLM和/或服务模块终止。

如可见，本系统可以允许在后台预启动所终止的应用（例如处于非运行状态502）。在一个实施例中，这种预启动的所终止应用可以转变为挂起状态506并且准备好恢复——作为至运行状态504的路径。

在一个实施例中，可以对于通过预启动而激活的应用使能节流（throttling）。如果应用之前被用户终止，可以通过预启动将应用激活至其初始状态，并且在一个场景中，当激活应用时可以暂时出现飞溅屏幕。如果应用由PLM终止，可以通过预启动将应用激活至其上次保存的状态，其中恢复返回栈位置。如果应用已经处于挂起状态，预启动可以忽略它。

预测引擎的实施例

对于合适的预测引擎，存在许多不同的可能实施例。例如，以下是出于本申请目的的可能预测器的集合：

（1）最常用预测器

该预测器可以对于前20个最频繁激活的应用返回概率1.0，并且对于所有其他的返回概率0.0。

（2）最多使用预测器

该预测器可以返回（应用的总使用时间）/（所有应用的总使用时间）的概率。

（3）空预测器

该预测器总是返回概率0.0。在这种情况下，本系统不会使用分派给应用的任何预测值；但是虽然如此可以对于应用的预启动施加所期望的规则和/或启发法。

（4）自适应预测器

该预测器可以通过考虑当前前台应用、上一个前台应用以及当前应用已经使用多久而识别类似于当前情形的过去情形。一旦其已经识别了这些情形，预测器可以返回情形的百分比，其导致在预测窗口内发生的所询问事件。

参照图6，自适应预测器可以作用于称作“案例”的应用使用时段的分组。如图6中所示，创建案例的一个方式可以通过将（例如3个或任意所期望数目的）相邻的应用使用时段分成组而实现。将认识到的是，也能够使用其他分组来创建案例，诸如当前应用切换、之前应用切换、以及在应用切换之后落入预测窗口内的任何时段。

为了确定在下一个预测窗口中切换至“应用X”的概率，预测器可以在所有案例之上迭代并且基于它们的性质而对于它们中的每一个分类。一旦分类了案例，本系统可以调节案例所匹配的每个类的计数。每个类可以具有正案例的计数和总案例的计数。如果在案例内切换至应用X，则案例是“正”的。

一旦分类了这样的案例并且更新了计数，本系统可以确定哪些类与当前情形匹配并且向所述类指派权重。这些权重可以是静态的，或者可以依赖于诸如类中总案例的数目以及当前情形是否与所述类相匹配之类的因素——例如指派权重（诸如0.4、0.4和0.2）。一旦指派了权重，可以可能通过对于针对每个分类的（正案例）/（总案例）求加权和来计算最终概率。

预测引擎模块可以接收给定应用的生命周期的活动数据（例如应用被用户激活的次数、激活的日时间、激活的时间长度等等）。应用的这些使用可以形成应用的使用的“案例”的集合。可以对每个案例评估所计算、预测和/或估算的未来和/或潜在激活的概率。

自适应预测可以开始，并且如果由预测引擎所考虑的应用之前从未被见到过，则应用需要被预启动的概率可以是给定的初始值——例如零，并且进程可以结束。

否则，之前见到过和/或考虑过应用。这种出现可以被设置为该应用的最新近案例。自适应预测可以对该当前案例分类并且更新针对该案例的计数。引擎可以考虑是否在该时刻存在待考虑的任何其他额外的案例，并确如果是，则引擎可以适当地地递增当前案例。当已经考虑了所有当前案例时，引擎可以对当前情形分类。

当已经如此分类和/或处理了数据时，引擎然后可以基于所期望的规则和启发法来计算潜在激活的概率。这样的规则和/或启发法可以包括：应用运行的时间量的时间加权平均，应用被激活和/或运行的日时间等等。

图6描绘了可以由自适应预测模块维持的数据/元数据的一个示范性集合。该数据/元数据可以酌情被存储在计算机系统内或者计算机系统外。如可见，该示例考虑了在期望的时间段的历程上四个应用（也即A、B、C和D）的数据。将认识到的是，时间段可以根据本系统的需要而改变——例如天、周等。

在该示例中，从时刻＝00:00直至14:20（示例的当前时间），存在由本系统所考虑的数个案例（案例1,…..,案例9）。这些案例可以代表重叠时间段（例如案例1和案例2等）——或者它们可以根据需要而是非重叠的。每个案例可以依某个信号——例如应用的激活和/或使用（例如将应用从挂起移至运行）而开始。在该示例中，可以看到，案例4是当前情形，以及案例1-3表示历史条目。案例5至案例9将要由自适应预测引擎处理。

当处理这些案例时，每个案例可以被分类到任意数目的类中。每个类可以被预定义为用户的用例和/或模型（例如其可以依赖于用户是否在工作、用户参加什么活动等而改变）。自适应预测引擎可以继续处理这些案例——例如以针对预测窗口（其被示为在当前时间之后的期望的时间段）提供预测。

该分类数据可以用于执行对于可能权重的概率计算。如可见，最终概率可以被计算和/或估算为可能属于期望的预测窗口。

一旦设置了这些概率，它们可以由本系统的其他模块利用——例如预启动策略——作为规则和/或启发法的一部分以确定是否预启动给定应用。

（5）切换率预测器

在该实施例中，可以可能基于个体和/或群体数据而提供模型，其使用像应用中的切换频率和时间这样的可能普遍属性来做出其预测。

参照图7，一个率预测器可以作用于应用切换上。这样的率预测器可以在历史中所有应用切换上迭代并且维持各种各样的信息——例如率计数和持续时间。率计数和持续时间可以被划分成类，例如可能对于不同日时间保持分立的计数和持续时间。

在一个实施例中，对于每个应用切换，预测器可以首先衰减所有计数和持续时间。这可以通过基于自上次应用切换以来的时间施加指数衰减而完成；然而存在其他可能的衰减函数。

一旦已施加了衰减，本系统可以对应用切换分类并且递增对应的率计数。本系统可以然后对紧挨在应用切换之前的时间分类，可能在不同类之间分割时间段并且添加时间至对应的持续时间。例如，如果类是午前和午后，当前时间是12:30并且上次应用切换在11:00处，本系统可以增加1小时至午前并且增加30分钟至午后。

一旦本系统已经处理了应用切换，本系统可以对当前情形分类。本系统可以随后向每个类指派权重并且计算——例如对于每个分类的（率计数）/（持续时间）的加权和。这为本系统给出了最终率，其可以然后转换为概率。

图7描绘了关于四个应用（A、B、C和D）的数据的一个示范性集合，其示出了随时间在各种应用之间的切换。例如，考虑图7中标注为“应用A”的率曲线。其开始于时刻00:00处的率计数1——因为在该时刻应用A被激活并运行。该曲线的斜率小于1——表明随时间施加衰减率。这样的衰减率可以依赖于启发法（例如在针对应用的切换之间时间越长，应用对于用户而言越不受“欢迎”）。将认识到的是——即便衰减率被示为线性下降，可以存在更复杂的衰减率和/或函数以反映不同的模型和/或启发法。

在时刻07:49，再次激活应用A并且率计数从其所在处提升。针对应用A的最终值可以是2或更小，依赖于所施加的衰减率。类似的提升对于应用A发生在时刻10:46和13:48处——并且此后施加衰减率。

同类的描述可以以类似的形式应用于每个应用B、C和D。这些率曲线然后可以由预启动模块根据一些规则和/或启发法而施加——例如切换率在某个阈值之上的某些应用可以被预启动。

在合适的预测模块的另一实施例中，本系统可以尝试确定在给定时间窗口内启动应用的概率。启动预测模型可以被实现为可以为应用切换提供预测信息的API。

在该实施例中，预测模块可以尝试考虑过去用户行为以预测未来行为。概念上基于人们（和用户）是“信守常规者”的事实，可以针对预测时间T尝试以下预测：

1.给定当前应用（N）和之前应用（N-1）的情况下，检查历史以确定在给定（N,N-1）对的情况下启动的下一个应用的频率。概率预期看到：应用的期望阈值数目的案例在(N,N-1)对之后被启动。如果找到期望阈值或者更大的案例，则对概率加权。如果小于期望阈值，则可以发生以下：

2.检查检查当前应用（N）并且检查历史以确定图式是否显现。同样，系统对于N找寻期望阈值数目的案例和/或相同图式的出现，需要N+1。如果未找到，则可以发生以下：

3.以相同方式检查之前应用（N-1），以确定对于在应用N-1的时间T内开始的应用，图式是否显现。同样，系统对于期望阈值数目的出现进行测试。

在一些实施例中，该预测模型可以使用以下输入：

1.前台切换——这告知应用何时在前台对后台。本系统可以具有知晓经典桌面何时出现的能力。

2.如通过典型提供而提供的用户离开。

3.如当日订阅事件一样可用的登出。

4.应用安装/卸载。

预启动策略的实施例

在许多实施例中，预启动策略模块可以确定各种各样的动作——例如（1）什么触发了运行预测；（2）确定应该通过预启动激活的应用；和/或（3）预启动如何随着改变计算机系统的电力状态和系统资源使用而表现。

存在数个可用于本系统的潜在预启动策略。对于仅两个示例，本系统可以采用：（1）简单的预启动策略和（2）侵略性的预启动策略。

对于简单的预启动策略，可能期望预启动在预启动预测窗口内被启动的概率在期望概率阈值和/或条（bar）以上的所有应用。可能期望预启动尽可能多的应用使得可以适合存储器而不触发PLM策略以及期望以降低的量级的概率来执行预启动。

对于更侵略性的预启动策略，可能期望选择性预启动满足期望概率阈值/条的应用——例如预期其并未尝试避免触发PLM。在一个这样的情况下，预启动策略模块可以启动这样的应用直至存储器满。

在许多实施例中，预测引擎和预启动策略模块可以不总是运行并且可以控制它们自己的时间表。在一个实施例中，这些模块可以以期望的间隔而运行。例如，如果计算机系统不处于连接待机状态，预测引擎模块可以以固定间隔（例如以15分钟间隔等等）运行。该间隔可以改变或减少，如果预测不被视作是廉价进程的话。

预取进程模块

一旦确定了预取哪个应用（例如通过本文讨论的各种实施例中的任意一个），预取进程负责执行对内容的实际预取。

在一个实施例中，预取服务可以如下操作：

1.在某个规律的时间间隔下，预取服务可以首先检查网络和电力条件以及用户设置以确定是否应该执行任何预取。

2.如果是，预取服务可以通过使用如本文详述的规则和/或启发法——并且可能结合任何可用的预期模块而确定应该预取哪些应用。

3.对于将执行预取的每个应用，预取服务可以安排后台任务，以便既度量对于应用的上次预取的成功，又执行预取。

追踪参与的应用

在一个实施例中，可能期望的是，预取服务知晓应用是否参与预取进程。在一个实现方式中，预取服务可以维持应当针对预取而考虑的应用的参与列表。

选择预取应用

为了辅助预取进程，可以针对使用预取的每个应用通过预取服务来追踪以下信息：

1.上次切换时间——上次切换至（启动或恢复）应用时的时间戳。

2.上次预取时间——对应用的上次预取完成时的时间戳。

3.预取益处历史——针对应用而“成功”预取的每个最后益处得分历史大小的得分列表，其度量了按照已知的对资源的高速缓存命中和错过的数目而计算的执行预取应用的益处。应该注意的是，对于要计算并包括在历史中的预取的益处，所述预取可以在后续预取之前在用户启动应用之后。

对于每个规律的心跳轮询心跳，预取服务可以如下确定预取哪些应用：

1.对于使用特征的每个应用检索上次切换时间和上次预取时间。

2.对于在过去的上个获取窗口（例如6小时）内尚未切换到或预取但是在上个上次用户应用运行窗口（例如72小时）内已经（被用户）启动的每个应用，检索预取益处历史。

3.进一步过滤应用列表以潜在地基于启动预测模型而预取。

4.对于每个应用基于其预取益处历史而计算平均预取益处得分。按照平均益处得分将应用归类。

5.用于执行预取的应用的数目可以使用由后台任务基础结构提供的条件而基于电力和网络状态。

6.首先针对尚未具有任何预取益处历史得分的许多应用启动预取后台任务（例如以随机次序或任何合适的顺序），直至达到步骤5中确定的极限。

7.如果尚未达到步骤5中确定的极限，则针对尽可能多的应用按照所计算的平均预取益处得分的次序来启动预取后台任务，直至达到所述极限。

为了辅助以上处理，可以由本系统考虑以下配置参数：

1.益处得分历史大小——之前“成功”预取的数目，应该对所述之前“成功”预取追踪预取益处得分以在未来预取判定中作为因素；

2.上次获取窗口——自从上次切换到应用或针对应用进行预取以便使应用是用于预取的候选以来，以分钟为单位的最小时间；

3.上次用户应用运行窗口——自从上次使用应用以来，以小时为单位的最大时间；

4.预取中等成本——当后台任务的成本为中等时对其执行预取的应用的最大数目。例如，在电池使用的情况下，成本可以当设备被活跃地使用并且在DC电力上时被视作“中等”；当在AC电力上时被视作“低”；并且当在DC电力上待机时被视作“高”。

5.预取低成本——当后台工作的成本低时对其执行预取的应用的最大数目。

应用更新对高速缓存命中率的影响

如果开发者对于提示应该为他们的应用预取哪些URI而做好工作，则针对应用的预取益处得分可能低，并且本系统可以停止执行针对该应用的预取。为了给开发者纠正这个的机会，可以在应用被更新时针对应用清除所存储的预取益处历史。这可以倾向于确保本系统在已经执行更新之后、在针对差的成功率而再处罚应用之前，至少一次针对应用而预取。

尽管在应用更新时重设预取益处历史的目的是对于具有差得分的应用给予第二次机会，这也可以影响具有好得分的应用。这可以是可接受的，因为之前具有好得分的应用也可以得到至少一个机会来在尚未更新的任何应用前面执行预取。

发起预取

一旦预取服务确定了用于预取的应用的列表，本系统可以启动后台任务以执行预取。除了预取之外，可以使用后台任务，因为：（1）其运行在应用安全情境中；（2）其典型地是资源高效的（例如运行在应用进程之外的小容器进程中）；（3）其遭遇低优先级存储器/CPU/I/O；和/或（4）其遭遇资源沙盒化以限制整体电池影响（例如CPU、网络）。

为了启动后台任务，可以由预取服务执行以下操作：

1.预取服务可以首先获得针对用户的令牌——或任何其他充分的数据。

2.一旦获得了令牌和/或数据，预取服务可以“扮演”用户。通过“扮演”，可以可能假设将比用户更有特权的用户情境（与如在系统情境中运行相对）。

3.当扮演用户时，预取服务可以创建“立即”后台触发事件，其可以基本上立即引发——例如使用TbCreateEvent()。该事件可以具有以下条件：

a.网络可用条件以确保网络存在

b.如果用户已经禁用了收费网络上的特征，可以设置免费网络条件以确保后台任务并未运行在收费网络上运行

c.对于最高排名的预取中等成本应用数目，可以使用中等成本触发器

d.对于在如上(c)描述的那些之后到来的下一个预取低成本应用数目，可以使用低成本触发器

4.一旦以以上条件创建了事件，服务可以复原回系统账户并且使用触发器来使用BIAssociateApplicationExtensionClass()API安排后台任务。关于后台进程是否要执行高速缓存命中率计算，服务可以通过在任务创建时将该信息传递至后台任务而向后台进程通信。

5.如果应用在后台任务开始之前被启动，则可以取消得到的工作项。

与应用容器通信

在一个实施例中，可能期望使得应用容器代码与服务通信，原因如下：

1.应用容器可以向服务通信：应用正参与预取特征；和/或

2.应用容器可以向服务通信高速缓存命中率数据。

在用于促进这种通信的一个实现方式中，可以由允许被应用容器调用的服务来实现和暴露仅内部RPC接口。在一些实施例中，RPC接口可以被设计用于处置以下场景：

1.允许客户端API指示针对应用使能了预取；

2.允许客户端API指示针对应用使能了预取；

3.向预取服务报告预取益处得分；

4.报告针对应用正在开始预取；

5.报告预取后台任务已经停止以及停止的原因；

6.允许OSAPI无条件立即开始针对应用的预取后台服务。

后台任务

在本系统的许多实施例中，可以采用后台任务以执行由URI提供的应用的实际预取。后台任务工作可以涵盖以下领域：

1.注册：这可以包括对于每个应用注册后台任务的工作，包括DEH工作和合约定义。

2.激活：这可以包括如何激活后台任务，以及如果有任何信息被传送至后台任务会怎样。

3.运行时间：这可以包括后台任务的运行时间行为，包括其如何操作以检索URI（例如内容和XML文档选项两者）。

注册

为了针对应用启动后台任务，可能期望注册后台任务。后台任务可以然后被激活（例如经由扩展模型）。在一个实施例中，可以在包部署时经由部署扩展处置器（DEH）来提供用于注册针对应用的扩展和类的一个机制。部署扩展处置器（DEH）是附接至公共接口的组件，并且在调制解调器包（例如APPX包）的部署期间被调用以扩充包部署。与引入新注册或激活机制不同，DEH可以针对包括任何网络能力的应用而注册后台任务。这可以类似于后台下载API工作的方式。可能期望从下载上传DEH注册这种后台任务。此外，针对后台任务的注册可以注册包含预取逻辑的实现方式的可激活类。

激活

后台任务可以针对由预取服务执行的合约激活而实现运行时间类。

运行时间

在一个实施例中，后台任务的运行时间可以执行对之前预取的成功的计算并且做出实际HTTP请求以检索开发者指定的内容。在一个实施例中，后台任务可以执行以下工作：

1.如果被预取服务指示为计算益处得分，后台任务可以计算益处得分并且将其通信至预取服务；

2.加载内容URI或内容源URI；

3.如果内容源来自URI，下载并解析；

4.下载可以不是已被高速缓存的资源，保持追踪哪些下载是成功的和失败的；

5.当完成了所有下载或者取消了BG任务时，向预取服务告知完成状态并且经由RPC接口存储成功下载的URI的列表。

计算预取益处得分

在一个实施例中，预取服务可以确定预取应用是否可以依靠之前已知的对于之前预取的高速缓存命中和错过率。可以对于每个应用维持该信息，并且应用对此在时间窗口内被实际启动。当由预取服务所指示时，益处得分可以如下被计算并且报告给预取服务：

1.从注册表读取对其尝试了下载的URI的列表以及下载是否成功（参见部分7.4.3.2）

2.上次益处得分＝0；

3.查询以如下而计算上次益处得分：对于对其尝试了下载的每个URI：

a.如果下载成功并且从高速缓存供应资源，上次益处得分:=上次益处得分+1

b.如果下载成功并且并未从高速缓存供应资源，上次益处得分:=上次益处得分-1

c.如果下载并未成功，上次受益得分:=上次益处得分-1

4.RPC至预取服务的报告预取益处得分方法以报告所计算的上次益处得分。

执行预取

如前所述，为了实际执行预取，后台任务可以首先检索开发者指定的URI的列表。如果获得了内容源URI，则后台任务可以获取该URI，使XML生效并且解析该XML以获得要获取的URI的列表。在另一实施例中，云服务可以向设备发送指示了新内容可用的推送通知。这可以提高与运行预取任务相关联的概率，包括使预取任务立即运行。

一旦获得了内容URI的列表，后台任务可以首先检查所请求的URI是否在高速缓存中仍然有效。可能期望这一点以避免针对成功度量破坏高速缓存命中率。如果URI在高速缓存中不是有效的，后台任务可以获取这些UIR，并且在这么做时结果可能最终处于高速缓存中。新引入的HTTP客户端APIs可以用于该目的。获取可以继续，直至预取列表耗尽或者后台进程缺失资源。

可选地，为了识别预取特征至外部站点，可以在所有请求中包括合适的报头，如果需要的话包括对于内容源XML的请求。这可以由服务器使用以改变对于预取服务的响应。例如，服务可以选择重定向至新XML列表，或者负载过轻的服务可以选择以使得对于失败实际用户请求的预取请求失败。

当做出网络请求时，后台进程可能需要处置http状态代码的集合。可以由后台服务处置以下代码。可以忽略所有其他状态代码：

1.200，304——资源可以被存储在高速缓存中；追踪如下载成功的URI；

2.301，305，307——执行对于响应的位置字段中所指示URI的请求。如果然后接收到200或304响应，资源可以被存储在高速缓存中并且应当追踪如成功下载的URI。以下的重定向可以不导致获取在URI上追索；

3.所有其他——追踪如失败的URI。

追踪预取成功率

在一个实施例中，可以追踪预取的成功率并且反馈至预取进程以动态地改良进程。为此，可以耐久地存储上次预取的实际URI。在一个实现方式中，可以可能在以下注册表值下设置reg值：

1.上次预取的URI——包含尝试被预取的URI的集合以及尝试是否成功。这包括对于任何3XXHTTP状态代码的重定向URI，以及可能由于其他原因已经失败的任何URI（例如503，504，408）。如果做出获取URI的尝试，其可以被放置在该列表中。

完成/中止

为了任何以下原因可以在完成之前放弃后台任务：

1.中止——由应用取消后台任务。这可以出于以下原因之一而发生：

a.任务被视作空闲任务。这意味着后台任务可以仍然在运行，但是不做任何事情——例如，并不调用close()函数的JavaScript任务。

b.后台任务使用MaintenanceTrigger并且系统转变至DC（电池电力）。

c.当任务在运行时卸载了注册后台任务的应用。

2.终止——取消后台任务，因为应用由于系统策略而将要终止。

3.登出——取消后台任务，因为用户已经登出系统。

4.服务更新——取消后台任务，因为应用被更新。

当后台任务完成或中止时，其可以引发深红色事件，指示其是完成还是中止，并且如果中止，深红色事件可以包括取消原因。

调用预取服务的报告高速缓存命中率方法以向预取服务告知之前预取益处得分以及任务不再运行的事实。可以注意的是，即使后台任务并未计算之前预取益处得分，也可以做出该调用，使得服务的上次预取时间仍然被更新。

可以注意的是，在后台任务中止的情况下，将在终止之前给定所期望的时间段——例如5秒（壁钟时间）——在其中完成以上工作。

后台进程可以很好利用用户的资源。这包括确保运行的后台任务不干扰活跃用户的体验，或者后台任务不消耗过多CPU、存储器或电池资源。因此，后台任务可以经历“缺失资源”条件，其中资源是在后台任务上由系统设置的人为限值。因为该特征正使用现有的后台任务主机基础结构，现有的资源限值可以施加到后台预取进程。

以上描述的内容包括主题创新的示例。当然，不可能出于描述所要求保护的主题的目的而描述部件或方法的每个可想到的组合，但是本领域技术人员可以认识到，主题创新的许多其他组合和排列是可能的。因此，所要求保护的主题意在包括落入随附的权利要求的精神和范围内的所有这样的改变、修改和变形。

特别地并关于由如上所述部件、设备、电路、系统等等所执行的各种功能，除非另外指示，否则用于描述这样的部件的术语（包括对于“装置”的引述）意在对应于执行所描述的部件的指定功能（例如功能性等同）的任何部件，即便并未结构上等同于执行了所要求保护的主题的本文说明的示范性特征方面中的功能的所公开结构。对此还将认识到，创新包括系统以及具有用于执行所所要求保护的主题的各种方法的动作和/或事件的计算机可执行指令的计算机可读介质。

此外，尽管可能仅关于若干实现方式之一公开了主题创新的特定特征，然而在对于任何给定的或具体的应用可能是需要和有利的时，这样的特征可以与其他实现方式的一个或多个其他特征组合。此外，就在详细描述或权利要求中使用术语“包含”和“含有”及其变形来说，这些术语意在以类似于术语“包括”的方式而是包括性的。

Claims

1.一种用于针对应用预取数据的方法，所述应用能够运行在计算机系统中，所述计算机系统包括控制器、存储器和操作系统，所述数据被存储在所述计算机系统远程处的内容源处，方法包括：

将应用的集合与数据的集合相关联，所述数据能够从内容源的集合被检索；

确定预取条件的集合，所述预取条件包括组中一项，所述组包括：系统资源可用性，应用是否可以被预启动的预测性度量，与针对预取的用户设置有关的数据，与针对给定应用的之前预取是否成功有关的数据；

确定可以预取哪些应用；以及

如果所述条件的集合满足给定策略，执行从所述内容源预取数据。

2.根据权利要求1所述的方法，其中，关联应用的集合进一步包括：

将应用与组中一项相关联，所述组包括：来自URL的集合的数据，来自URI的集合的数据，以及来自由所述应用对web服务做出的响应的数据。

3.根据权利要求1所述的方法，其中，关联应用的集合进一步包括：

向应用提供API，所述API能够向计算机系统提供与针对所述应用要预取的数据有关的数据。

4.根据权利要求1所述的方法，其中，确定预取条件的集合进一步包括：

监视所述计算机系统的系统资源；以及

进一步其中所述系统资源包括组中一项，所述组包括：CPU利用，GPU利用，存储器利用，I/O利用，和电池充电状态。

5.根据权利要求1所述的方法，其中，所述确定预取条件的集合进一步包括：

确定对预启动应用的可能性的度量。

6.根据权利要求5所述的方法，其中，所述确定对预启动应用的可能性的度量进一步包括：

预测建模以给出应用何时可以被用户激活的预测度量；以及

进一步其中所述预测建模是组中一项，所述组包括：基于应用使用的次序而建模，基于应用使用的频率而建模，基于应用使用的日时间而建模，基于应用使用的位置而建模，使用最常用应用预测器而建模，使用最多使用预测器而建模，使用空预测器而建模，用自适应预测器而建模，以及用切换率预测器而建模。

7.一种用于针对应用预取数据的系统，所述应用能够运行在计算机系统中，所述计算机系统包括控制器、存储器和操作系统，所述数据被存储在所述计算机系统远程处的内容源处，所述系统包括：

API的集合，每个所述API与应用相关联并且每个所述API能够存储针对所述应用要预取的数据；

预取发起器策略模块，所述预取发起器策略模块能够依赖于预取条件的集合而发起预取进程；

预取进程模块，所述预取进程模块能够针对由所述预取发起器策略模块识别的应用从远程内容源预取数据；以及

计算机存储装置，所述计算机存储装置能够存储从所述远程内容源所预取的数据，以使得可以使所预取的数据可用于所述应用。

8.根据权利要求7所述的系统，其中，所述预取发起器策略模块进一步包括：

预测模块，其能够给出应用何时可以被用户激活的预测度量；以及

进一步其中所述预测模块是组中一项，所述组包括：基于应用使用的次序的预测模块，基于应用使用的频率的预测模块，基于应用使用的日时间的预测模块，基于应用使用的位置的预测模块，使用最常用应用预测器的预测模块，使用最多使用预测器的预测模块，使用空预测器的预测模块，自适应预测模块，以及切换率预测模块。

9.根据权利要求7所述的系统，所述预测发起器策略模块进一步包括策略的集合，所述策略包括组中一项，所述组包括：系统资源策略规则，用户预取策略规则，预启动策略规则，以及之前预取益处规则。

10.根据权利要求7所述的系统，其中，所述系统进一步包括：

预取成功模块，所述预取成功模块能够：

度量针对当前预取的成功数据；以及

依赖于所述成功数据而改变一些策略。