服务114)。本系统可W被表示为用于运样的服务的客户 玉山 乂而。
[0038] 在一个实施例中，本系统可W包括一个或多个W下模块： 1. 预取发起器进程(202)，负责起动预取操作； 2. 预取操作/进程(206)，在执行预取操作的应用(诸如应用容器一一或某类似种类的 应用情境)的情境中运行;和/或 3. 应用运行时间(客户端)APK212)，用于检索所预取的内容。
[0039] 在一些实施例中，预取发起器进程可W进一步包括预测和/或预测器模块，如本文 进一步讨论的。可W可能的是，使预测模块与计算机系统分离地驻留一一例如在服务器上， 并且预测模块可用作基于云和/或基于服务器的应用。在任一情况下，可能期望从用户的群 体聚集预测结果并且跨数个用户而共享预测结果。
[0040] 运些应用运行时间APK212)为应用提供机制W指示需要被预取的内容的集合。在 一些实施例中，可W存在API的分立集合(例如，在预取操作/进程206与高速缓存208之间）， 应用可W使用所述API的分立集合来检索所预取的内容。
[0041] 在一个实施例中，客户端API可W由应用和预取服务(其可W在后台运行)采用W 设置或者检索预取URI的列表。后台任务可W与第Ξ方内容提供者通信W获得在给定URI处 的资源，并且可W收集反馈并且将该反馈通信至预取服务W演进预取模块。客户端API可W 与可W基于应用的应用容器而划分的耐久URI存储库交互。后台任务和应用代码均可W经 由HTTP客户端API与内容高速缓存直接或间接地交互。
[0042] 如图2中所示，运些模块中的若干个可W驻留在当前由用户采用的本地（或计算 机)系统内的应用容器中。此外，若干模块可W驻留在计算机系统中并且与操作系统协作地 工作。
[0043] 将认识到的是，本系统可W被不同地架构（其中不同的模块驻留在计算机系统的 不同部分中或者在计算机系统远程处），并且本申请的范围涵盖了运样的不同实施例和架 构。
[0044] 图3是用于本申请系统的高等级流程图（300)的一个实施例。本发明的系统可W开 始于302。作为初始化的一部分，本系统可W接收(在304处)与可能需要来自第Ξ方源的内 容的应用有关的数据和/或元数据一一W使得本系统可W将应用识别为用于预取的潜在候 选。本系统可W将该数据和/或元数据与给定的应用相关联和/或注册到给定的应用。在一 些实施例中（如本文讨论的），关联性可W给出需要针对给定应用而预取的数据的地址或其 他位置标记(例如URL)。
[004引在306处，本系统可期望的时间间隔一一或在任何其他合适的基础上）检查 系统和/或用户条件W 了解是否应该执行预取。如W下将更详细讨论的，运样的条件可W包 括：系统资源是否处于其中执行预取可W不影响当前用户体验（例如通过减慢对于当前运 行的应用等等的系统响应)的点；是否可能存在可W由用户激活的应用并且预取第Ξ方内 容将客观地改进用户体验。在一些实施例中，可能期望预测哪些应用可W被激活一一W及 在计算机系统上可用的情况下，哪些应用将被预启动。预启动模块可W用于识别和/或预测 哪些应用可W有可能从非运行或挂起状态被激活。
[0046] 如果不满足条件，则系统可W操作测试运样的条件的连续循环，并且在可W满足 运样的条件的情况下和/或当可W满足运样的条件时进行。
[0047] 如果满足充分条件，则本系统可W进行至步骤310。本系统在该点处可能希望在所 有可能候选之中确定哪些应用将被排队用于预取。本系统可W根据由本系统所确定的一个 或若干预取条件而确定和/或排序用于预取的应用的列表。对于仅一个示例，应用可W按照 它们的预启动或启动的可能性而被排序，按照它们对于可用系统资源的影响而被排序，按 照用户偏好而被排序，按照预取的之前成功而被排序，和/或W上因素的任意组合等等。
[0048] 一旦已经识别了用于预取的一个或多个应用，本系统可W在312处执行实际的预 取。在一个实施例中，运样的预取可W在本系统的后台进行一一其可W对于用户透明地进 行;并且因此，改进了计算机系统的用户体验。在其他实施例中，运样的预取可W在前台或 可能的其他进程状态中进行。将认识到的是，运些特定步骤的次序可W互换W实现相同、相 似和/或可替换的实施例。例如，本系统可W确定预取条件，确定可W预取哪个应用，并且然 后可W在针对应用预取任何数据之前对照数个策略、规则和/或启发法来测试预取条件。本 申请的范围涵盖所有运样的实施例。
[0049] 一旦完成，本系统可W可选地执行数据收集步骤(在314处）W度量预取的成功。成 功数据可w反映相同数据中的一些作为预取条件。例如，成功数据可w包括:当前预取对系 统资源的影响，被预取的应用是否实际被启动，预取的资源是否实际可用和/或被应用利用 等等。依赖于成功数据，然后可W可能动态地改变针对预取的策略中的一些一-例如，可W 利用预取条件的。运可W导致对本系统的改进。
[0050] 如所述，预取进程可W在数个模式下操作：（1)其中预取进程获得由对API的调用 指示的URI的列表并且针对列表中的每个URI执行预取；（2)其中预取进程能够按照对预取 请求的响应来行动并且依赖于对于预取请求的响应，获取可W被重试或者可W被重定向至 另一URI; (3)其中预取进程可W获得URI，所述URI指向合式的URI列表;和/或(4)其中应用 指示操作系统如何解释从服务返回的特定于应用的数据W确定预取URI的集合。可W通过 对URI做出请求而获得该列表，并且一旦成功响应就验证列表格式。一旦被验证，列表中指 示的URI就自身被获取。同样，预取进程可W能够按照对预取请求的响应来行动并且可W被 恰当地重试或者重定向至另一URI。在一些实施例中，可W可能使得服务向目标指示新数据 是可用的。在运种情况下，本系统可W实现基于"推送"的模型。运可W在一些情况下绕过针 对新内容进行轮询的步骤一一因为先验知晓了新内容是可用的。
[0051] 在成功检索到由预取URI指示的资源时，可W将内容存储在由应用可访问的高速 缓存中。高速缓存的寿命可W由0S管理并且可W保持任意长的时间。
[0052] 预取进程可W额外地提供每个操作的详细日志记录W及所述操作的成功/失败W 使得开发者能够诊断在预取操作中的故障。
[0053] 如果由预取发起器进程指示，预取进程可W计算之前预取的益处。可W通过分析 之前预取的内容并且确定该内容是否被应用访问而计算得分。如果内容被访问，运可W指 示好的得分。如果内容未被访问，其可W指示坏的得分。然后可W将针对预取操作的得分报 告回预取发起器进程。如果系统指示发生缺乏资源条件，预取进程终止。
[0054] 在运行时间，应用可W对在特定URI处的资源做出请求。该请求可W首先查阅本地 高速缓存，并且如果对于所请求的资源在高速缓存中存在有效条目，可W从高速缓存提供 资源。如果内容并未存在于高速缓存中，则使用所提供的URI从服务请求内容。典型地，运些 请求将是经由HTTP API做出的HTTP请求。如果预取器已经预取了所请求的资源，并且该资 源在高速缓存中仍然有效，则请求可W来自高速缓存，运倾向于比从远程服务器传递内容 更快。当应用从高速缓存检索资源时，追踪该检索W使能计算在预取进程中的益处得分。
[0055] 本文描述了关于运些各种步骤和技术的额外细节。将认识到的是，用于服务连接 应用的预取的其他实现方式是可能的，并且本申请的范围涵盖了那些可替换的实现方式 和/或实施例。可W足够的是，本系统识别可W受益于预取的应用，识别针对运样的预取的 适当机会和/或条件，并且当运样的机会和/或条件出现时允许针对预取的合适候选预取运 样的第Ξ方内容。
[0056] 客户端API 此外，可能期望提供APIW使得应用开发者能够指示要针对应用预取哪个内容。如之前 所述，存在实现运一点的数个机制。例如，可W经由URI列表直接指定内容并且将其存储在 计算机系统中（或计算机系统远程处）的可选的URI存储库214中。可替换地，可W响应于由 应用代码210对web服务做出的请求而指定内容。
[0057] 此外，针对客户端API的运些多个操作模式可W相互协同使用。在一个模式中，开 发者可W调用API并且提供要预取的URI的列表。开发者可W在他们的应用的运行时间期间 的任意点更新该列表。在另一模式中，开发者可W调用API W提供单个URI，其指向服务器宿 管的要预取的合式的URI列表。可W在预取操作的时刻解析该列表W使得在预取之前获得 列表的最新版本。
[005引特别地，由应用提供的URI可W是HTTP URI。一旦调用了运些API的任一个，应用被 视作是可预取的。可W由预取发起器发起针对应用的预取操作。
[0059] W下是客户端API的一个可能实施例：
[0060] 此外，可能期望添加检索关于对该API的上次预取操作的信息的能力。对于所提供 的信息的一个示例可W是上次预取时间W及获得了多少内容，W及所有尝试的状态。
[0061] 作为可替换情况，本系统可W提供TOL的XML纲要化列表。可能期望的是，获取该 U化返回类型应用/xml的将要预取的内容U化的良好格式化的XML列表。W下是XML纲要的一 个可能实施例：
巧〇6引预取发起器进程 在许多实施例中，预取发起器进程可W追踪选取到预取中的应用并且做出预取哪些应 用的判定。
[0063] 如本文许多实施例中讨论的，本系统可W确定数个预取条件--例如可能与是否 应该发生预取的判定密切相关的那些条件。例如，本系统可W正在监视:系统资源可用性， 对于给定的应用是否可W被预启动和/或可能被用户激活的预测性度量，W及关于针对给 定应用的过去预取是否可W已经成功的数据。
[0064] 运些条件可W用于制订和/或通告数个预取策略规则，所述数个预取策略规则可 W确定一一例如考虑到运些条件(可能作为阔值测试和/或某种启发法)一一是否实际预取 数据。存在许多不同的判定策略，预取发起器可W实现所述判定策略W便于判定预取哪个 应用。运些策略在一些实施例中可W被实现为规则和/或启发法的集合： 1. 系统和用户策略:如果用户已经授权准许在给定系统状态下的预取并且如果满足 网络、电池和CPU资源的系统指标一一例如如果某种系统资源可用性超过期望的阔值量，贝U 可W执行预取。 2. 之前预取益处:可W针对已经在过去预取中展现益处的应用来优先化预取。预取进 程负责计算该益处得分并且将其提供回发起器进程。可W使好的得分优先于坏的得分。 3. 应用使用:可W对于操作系统预启动的应用执行预取。预启动模块可W实现数个预 启动策略一一包括简单预启动、侵略性预启动和预测性预启动。在一个实施例中，系统可W 确定对于W下的预测性度量:给定的应用是否可能被用户激活;并且因此，将是用于被预启 动的候选。在另一实施例中，可W可能预取而不预启动。其他规则可W关于用户是否可能使 用特定应用而指导系统。
[0065] 针对预取发起器进程模块的第一实施例将使得用户和/或系统识别可W受益于预 取的那些应用。在运样的情况下，系统可W根据一些简单规则和/或启发法而执行预取。例 如，可W根据应用的给定状态(例如挂起或非运行)而执行预取。此外，可W仅当某一等级系 统资源（例如处理、通信和存储器的阔值量)可用时执行预取。还可W对预取进程施加沙盒 化(samlboxing)策略W进一步约束其对设备的影响（例如低的C