CN107667343B - 用于加载按需加载资源的系统和方法 - Google Patents

Abstract

本发明公开了用于构建软件应用程序的计算机实现的方法。该方法包括：生成多个应用程序资源；创建多个标签；在多个应用程序资源中的每一者上应用标签之一；通过标签对应用程序资源进行分组以形成至少两个资产包，两个资产包各自能够通过资产包中的所有应用程序资源共享的至少一个标签来标识；以及创建包括资产包中的每一者的位置和资产包要被下载的顺序的资产包清单。

Description

用于加载按需加载资源的系统和方法

相关申请的交叉引用

本专利申请要求2015年6月5日提交的美国临时专利申请62/171,894、2015年9月22日提交的美国专利申请14/861,405和2015年9月22日提交的美国专利申请14/861,885的权益，上述美国(临时)专利申请中的每个美国(临时)专利申请据此全文以引用方式并入本文以用于所有目的。

技术领域

本公开整体涉及构建软件应用程序，更具体地是以按需加载资源构建、部署、运行和更新软件应用程序的系统和方法，按需加载资源可从应用程序的主应用程序和其他资源解耦合，使得这些按需加载资源可在不干扰应用程序操作的情况下根据需要而动态地被请求和清除。

背景技术

计算设备，尤其是小型移动设备可具有有限量的资源，诸如用于存储应用程序和数据的盘空间。每次在计算设备上安装应用程序，就减少可供其它用途使用的存储空间。传统地，每个应用程序被打包在可被下载和安装在客户端设备上的单个应用包中。该单个应用包可包括其代码和数据的大部分(如果不是全部的话)，虽然在应用程序使用时在给定时间它们并非全部都被需要。代码和数据中的一些可能从不被使用，但只要应用程序存在于客户端设备上，它们仍然会占据设备上存储空间。这会是对客户端设备上宝贵存储空间的低效使用，并且限制了能安装在设备上的应用程序的数量。假定应用程序(甚至那些被设计用于在移动设备上运行的应用程序)的尺寸相当大，则希望设计和构造应用程序以在应用程序被安装在设备上时使盘空间的浪费最小化，而不对其可用性产生不利的影响。

发明内容

本公开的一个方面整体涉及构建和部署软件应用程序的系统和方法，所述软件应用程序使与应用程序相关联的各种应用程序资源(即，按需加载资源)能独立封装，这进而允许它们在不干扰应用程序的使用的情况下根据需要而从客户端设备独立地安装和卸载。安装和卸载过程可在后台进行，并且对于用户是透明的。这允许应用程序(尤其是那些具有相对大量内容的应用程序)在客户端设备上驻留和操作，而不消耗显著量的存储空间。继而，这可为设备提供灵活性，使得其可更好地容纳其它应用程序和数据。这样，这相比于通常要求完整下载和安装其所有文件的传统应用程序可提供显著的优点，传统应用程序的所有文件不管实际是否被需要都不得不被保持在客户端设备上。

相反，以按需加载资源构建的应用程序可以只需要设备上一小部分存储空间来操作，而不牺牲与应用程序有关的任何用户体验。未初始安装的按需加载资源可在后来的时候被请求，优选在其被应用程序需要之前被请求。类似地，已安装在设备上的这些按需加载资源中的一些可在不再被需要时和/或在盘空间不足时被移除。基本上，与应用程序相关联的各种应用程序资源可基于应用程序的需要而在设备上轮换，以实现设备有限量的盘空间的最佳利用。

本公开的另一方面整体涉及基于应用程序/客户端设备的需要(或预期需要)自动地请求和/或移除按需加载资源。对于以按需加载资源构建的应用程序，可能重要的是能够预测何时可能将需要特定按需加载资源。这允许其在被应用程序要求之前被取回，从而不需要让用户等待直到资源被下载。这也可防止发生潜在的运行时错误。可能同要重要的是要知道在存储空间变得紧张时哪些按需加载资源可被清除。在这个方面，一些实施方案公开了预先确定或动态地确定用于请求按需加载资源的标准的方法。其它实施方案公开了对于在被请求时进行移除来对已经在设备上的按需加载资源进行标识和/或划分优先次序的方法。

本公开的另外方面整体涉及被设计用于以按需加载资源构建应用程序和有利于这些应用程序在客户端设备上的操作的应用程序接口(API)和其它软件开发工具。

附图说明

图1是根据本公开一实施方案示出一种具有按需加载资源的应用程序的构成的框图。

图2根据本公开一实施方案示出一种以按需加载资源构造应用程序的方法的示例性步骤。

图3根据本公开一实施方案示出一种客户端设备的示例性模块及其在管理设备上一个或多个应用程序的应用程序资源中的交互。

图4根据本公开一实施方案示出在客户端设备上以按需加载资源设置和运行应用程序的示例性步骤。

图5根据本公开一实施方案示出将应用程序资源从客户端设备清除的示例性步骤。

图6根据本公开一实施方案示出以按需加载资源将应用程序更新到新版本的示例性步骤。

图7是示出可在本公开的一些实施方案中使用的一种示例性API架构的框图。

图8是根据本公开实施方案示出系统的部件之间的示例性交互的框图。

具体实施方式

在以下对示例性实施方案的描述中将引用附图，在附图中以例示的方式示出了可被实施的特定实施方案。应当理解，在不脱离各种实施方案的范围的情况下，可使用其他实施方案并且可进行结构性变更。

如本文所用，术语“设备”和“客户端设备”可互换使用，用于指代任何能够运行一个或多个软件应用程序的电子设备。此类设备可包括但不限于个人计算机(PC)、Mac、台式和膝上型PC、平板PC、智能电话和其它类型的蜂窝电话、可穿戴设备、机顶盒、智能电视、数字媒体播放器、和车载娱乐系统。如本文所用，术语“存储空间”、“盘空间”和“存储介质”可互换使用，用于指代客户端设备上任何类型的存储装置。存储空间可为内部的(例如存储器、硬盘驱动器、闪存驱动器、和缓存存储)，也可以是外部的(例如，云存储)。术语“软件应用程序”、“应用程序”和“应用”可互换使用，用于指代任何能在设备上安装和执行的计算机程序。

术语“应用程序资源”(或“资源”)可指代与应用程序相关联的任何数据(或内容)。在一个实施方案中，应用程序资源可以不包括用于运行应用程序的软件代码(或程序)。软件代码或程序可包括例如可执行文件、函数和库。应用程序资源的示例可包括但不限于图像、文本、音频、和视频文件(即，任何非软件代码的文件)。在另一个实施方案中，应用程序资源也可包括用于运行应用程序的软件代码的至少一些。术语“资产包”可指代共享至少一个公共特性的一个或多个应用程序资源的集合。术语“应用起始包”可指代在客户端设备上第一次开始应用程序所需要的代码和可选的多个应用程序资源的包。为了执行应用程序的最基本功能，诸如启动应用程序和显示应用程序的默认屏幕，需要应用起始包中的代码和资源。

术语“按需加载资源”可以指代能在不干扰应用程序运行的情况下被动态地请求和清除的一个或多个应用程序资源。这些按需加载资源可包括不包括在应用起始包中的资源(例如能在应用正在运行时通过应用的请求而被下载的资产包中的资源)。除此之外或另选地，它们可包括作为应用起始包的一部分但在不再被需要时能被清除的资源。除此之外或另选地，它们可包括被选择用于在初始应用和按需加载资源(ODR)安装之后安装、但在应用被启动之前仍还未被安装的资产包中的资源。按需加载资源可包括数据和/或代码。按需加载资源在应用程序被编译时可被分组到一个或多个资产包中，但与应用起始包分开存储，因此可以不是在应用程序第一次被请求时对客户端设备的初始下载的一部分。相反，具有按需加载资源的资产包可在应用程序安装之后根据需要而单独地被请求。一旦被安装了，它们就可整合到应用程序中并执行其预期功能。当它们不再被应用程序需要和/或客户端设备上的空间不足时，按需加载资源可在不干扰应用程序运行的情况下按预定次序(例如基于用于确定什么最不可能被需要的试探法的次序)单独地从设备清除。在一些具体实施中，特定按需加载资源被清除，其他按需加载资源不被清除。

术语“服务器”或“远程服务器”可互换使用，用于一般性地指代可从中获取包括其应用起始包、资产包、和/或其他资源的应用程序的一个或多个计算机。服务器可经由任意类型的已知网络连接到一个或多个客户端设备。

本公开的一个方面整体涉及构建和部署软件应用程序的系统和方法，所述软件应用程序使与应用程序相关联的各种应用程序资源(即，按需加载资源)能独立封装，这进而允许它们在不干扰应用程序的使用的情况下从客户端设备独立地安装和卸载。安装和卸载过程可在后台进行，并且对于用户是透明的。这允许应用程序(尤其是那些具有相对大量内容的应用程序)在客户端设备上驻留和操作，而不消耗显著量的存储空间。继而，这可为设备提供灵活性，使得其可更好地容纳其它应用程序和数据。这样，这相比于通常要求完整下载和安装其所有文件的传统应用程序可提供显著的优点，传统应用程序的所有文件不管实际是否被需要都不得不被保持在客户端设备上。

相反，以按需加载资源构建的应用程序可以只需要设备上一小部分存储空间来操作，而不牺牲与应用程序有关的任何用户体验。未初始安装的按需加载资源可在后来的时候被请求，优选在其被应用程序需要之前被请求。类似地，已安装在设备上的这些按需加载资源中的一些可在不再被需要时和/或在盘空间不足时被移除。基本上，与应用程序相关联的各种应用程序资源可基于应用程序的需要而在设备上轮换，以实现设备有限量的盘空间的最佳利用。另外，因为在应用程序可被使用之前并不需要下载整个应用程序，所以开始下载应用程序与能够启动应用程序之间的时间可显著地缩短。

本公开的另一方面整体涉及基于应用程序/客户端设备的需要(或预期需要)自动地请求和/或移除按需加载资源。对于以按需加载资源构建的应用程序，可能重要的是能够预测何时可能将需要特定按需加载资源。这允许其在被应用程序要求之前被取回，从而不需要让用户等待直到资源被下载。这也可防止发生潜在的运行时错误。可能同要重要的是要知道在存储空间变得紧张时哪些按需加载资源可被清除。在这个方面，一些实施方案公开了预先确定或动态地确定用于请求按需加载资源的标准的方法。其它实施方案公开了对于在被请求时进行移除来对已经在设备上的按需加载资源进行标识和/或划分优先次序的方法。

本公开的另外方面整体涉及被设计用于以按需加载资源构建应用程序和有利于这些应用程序在客户端设备上的操作的应用程序接口(API)和其它软件开发工具。

以下段落讨论以按需加载资源构建和部署软件应用程序的各种实施方案。不是将与应用程序相关联的所有资源(例如数据、内容和/或代码)都包括在单个应用程序包中，相反，一个实施方案中的一种示例性应用程序可以其被分组到多个资产包中的应用程序资源来构建，所有这些资产包在编译时可以是应用程序的一部分，但可供与应用程序的其他部分分开地单独下载。

如上所述，应用程序资源可包括与应用程序相关联的任何数据(也被称为内容)和/或代码。在一个实施方案中，每个数据(或内容)文件可对应于一个应用程序资源。在另一个实施方案中，多个文件诸如同一目录中的文件可构成一个应用程序资源。应用程序资源中的一些可被表征为按需加载资源，在应用程序操作期间，按需加载资源只在特定阶段才被需要。对于启动应用程序而言，通常不需要按需加载资源。应用程序资源一般可与一个特定应用程序相关联，但它们可被多个应用程序共享。

图1根据本公开一实施方案示出一种具有按需加载资源的应用程序的示例性结构。应用程序100可包括多个文件102,104,106,110,112,116,118,120,124。这些文件可为不同类型的。它们中的一些可为代码，其他可包括数据(例如图像、视频、文本文件、音乐和声音效果)。在该示例中，每个数据文件可对应于一个应用程序资源。可利用API和提供给开发方的其他软件开发工具(在下文中详细讨论)来构建应用程序100。所述工具之一可允许应用程序的开发方定义多个标签。标签可以开发方期望的任何方式任意地标识。可为应用程序创建任意数量的标签。优选地，每个标签(或标签组合)可用于通过一个公共特性将一组应用程序资源关联。换句话讲，这组标签中每个标签(或标签组合)的值可对应于分配给多个应用程序资源的逻辑分组的标识符。

例如，图1的应用程序100可为要求玩家完成一个等级之后才能进入下一等级的多等级视频游戏。可为游戏中每个等级创建标签，以指定该等级中所需要的应用程序资源。例如，文件102,104和106可以是渲染等级1的虚拟环境所需要的图像文件。这些文件可以是等级1中要求的应用程序资源。因此，它们可被施加以“等级1”标签。类似地，文件110和112可被施加以“等级2”标签，文件116,118,120和122可被施加以“等级3”标签。其他资源可为独立于等级的，但具有一些其他可标识特性并可相应地标记。应当理解，同一标签可被应用于不同应用程序资源，并且每个应用程序资源可与不止一个标签相关联。例如，这些图像之一可在等级1和等级2二者中出现，因此可被标记有“等级1”和“等级2”二者。这可避免为不同等级复制相同应用程序资源。

在应用程序资源(或文件)被标记之后，共享公共标签的那些可被置于一个资产包中。例如，如图1所示，资产包108可包括文件102,104和106，它们构成在游戏的等级1中需要的应用程序资源的集合。资产包114可包括文件110,112，两个“等级2”应用程序资源。类似地，资产包124可包括文件116,118,120,122，游戏中的“等级3”资源。资产包108,114和124中的一者或多者中的应用程序资源可为按需加载资源，其中的一些(例如资产包114和124)可以不是在客户端设备第一次请求应用程序时的初始下载包(应用起始包)的一部分。

此外，也可以有基础资源包130，其包括每次启动游戏时为了执行游戏中的基本功能而需要的应用程序资源132,134,136。例如，基础资源包130可包括例如游戏开机场景、游戏的各种菜单和选项设置、用户可选择和控制的至少一个角色、和不管用户在游戏中的进度而在整个游戏中使用的任何其他资源。也就是说，这些资源132,134,136不特定于游戏中的任何等级。此外，游戏也可包括作为用于启动游戏和在游戏中执行各种操作的软件代码(例如可执行代码)的文件142,144,146。这些文件可被包括在应用起始包中(并且不包括在资产包中)。在其它实施方案中，共享多个标签的应用程序资源类似地可以与只共享一个标签的资源类似的方式形成资产包。

虽然图1中的资产包被图示为只包括一些示例性应用程序资源，但应该理解，每个资产包可包括任意数量的应用程序资源。此外，应用程序可包括任意数量的资产包。资产包中的每一者可由应用程序在该资产包中的资源被需求时单独地请求。这就允许在应用程序初始安装之后根据需要下载和安装(或清除)资产包。

图2根据本公开一实施方案示出一种以按需加载资源构造应用程序的方法中的示例性步骤。首先，开发方可创建一起构成应用程序的应用程序资源和代码的库(步骤201)。然后，开发方可定义一组标签并将其应用于各种应用程序资源(步骤202)。在应用程序资源被标记之后，开发方可构建资产包(步骤203)。每个资产包可包括共享至少一个公共标签(或标签组合)的一个或多个应用程序资源。这允许每个资产包由与资产包中应用程序资源相关联的公共标签(或标签组合)来标识。换句话讲，标签(或标签组合)可被用作为资产包的标识符。这也可使应用程序能够请求与特定标签(或标签组合)相关联的资产包。在一个实施方案中，每个应用程序资源可落在正好一个资产包中。定义标签、将其应用于各种应用程序资源、和构建资产包的步骤中的一者或多者可利用任何合适的软件/应用程序开发工具诸如Xcode来实施。

一旦资产包被构建，资产包中的应用程序资源就可以是在被要求时应用程序能访问的格式。如图1所示，资产包可具有不同尺寸(即，对于资产包的尺寸或者应用程序资源被构造的方式，没有任何限制)。在其它实施方案中，可要求每个资产包具有特定尺寸限制。这些限制可帮助预测对于将资产包从服务器传输到客户端设备的网络带宽要求以及客户端设备上用于存储这些资产包的盘空间的量。

再次参见图2，在资产包被构建时也可创建两个列表，按需加载资源列表和资产包清单(步骤204)。在该实施方案中，这两个列表被创建作为属性列表文件(例如具有文件扩展名.plist的p-list文件)。然而，应当理解，它们可以为任何适当的文件格式。按需加载资源列表可提供各种应用程序资源对其相应资产包的映射。因为应用程序资源中的每一者已经被标记，所以按需加载资源列表也可标识与资产包中的每一者相关联的标签(或标签组合)。服务器在接收到作为对于按需加载资源的请求的一部分的一个或多个标签时可使用按需加载资源列表来标识资产包。例如，按需加载资源列表可在接收到来自客户端设备的具有“等级2”标签的请求时标识等级2资产包。

资产包清单可指示网络上可下载每个所请求资产包的地址。在一个实施方案中，资产包清单中的地址可包括指定资产包位置的统一资源定位符(URL)的列表。在其它实施方案中，资产包清单中指定的位置可包括例如IP地址、服务器地址、域名、目录名等等。实质上，资产包清单可充当应用程序与其资产包之间的联系。另外，资产包清单也可包括指定与每个资产包相关联的各种属性的元数据。例如，元数据可包括资产包的尺寸和应用程序要对其进行取操作的优选次序。除此之外或另选地，元数据可指示在下载特定资产包之前要满足的条件(例如，资产包的下载次序为首先是等级1、然后是等级2、之后是等级3)。如下文详细讨论，资产包清单也可包括可用于核验资产包版本以及确定是否要下载新版本的内容散列。在一个实施方案中，资产包清单不被包括在应用程序的初始下载中，必须单独请求并定期刷新以确保应用程序有资格获取其正请求的资产包以及正确的资产包被发布给应用程序。在应用程序被托管在应用商店中时，优选要求资产包清单与应用起始包分开下载。在另一个实施方案中，虽然资产包清单不被包括在应用程序中，但资产包清单的URL可被插入在作为应用起始包一部分的安装程序清单中。这个URL可支持应用程序连同预取的按需加载资源的初始安装。这个实施方案在资产包清单被托管在持续集成服务器或内部企业服务器上时可以是优选的。在另一个实施方案中，资产包清单可嵌入在ODR应用程序中并被下载到客户端设备。当随机web服务器托管资产包时，资产包清单也可嵌入在应用程序中。在另一个实施方案中，资产包清单的模板(而不是具有URL的完整资产包清单)可嵌入在应用程序中。如果实际URL(或按需加载资源的其他类型的地址)在应用程序第一次被下载时还未完成，则这种构造可以是优选的。后来在URL完成时可更新模板。

虽然图2示出生成按需加载资源列表和资产包清单的步骤(步骤204)在生成资产包的步骤(步骤203)之后，但应当理解，这些步骤可同时进行，其中在资产包正被构建时，列表被生成。在一个实施方案中，步骤201-204可在集成开发环境(IDE)诸如Apple的Xcode中执行。

在资产包、按需加载资源列表、和资产包清单被创建之后，它们可与应用程序的其余部分(例如应用起始包)一起被置于服务器上的归档中，并且可使应用程序可供用于下载(步骤205)。

在一个实施方案中，当应用程序和相关联的资产包从服务器到达时，它们可各自被签名以代码签名。如果一个资产包的代码签名与应用程序的其余部分的签名不匹配，则可确定该资产包已经被篡改并且需要替换。除此之外或另选地，如果应用程序正在应用商店中被提供，则资产包和应用程序的其余部分可被签名以应用商店签名，这可指示应用程序由应用商店提供，而不是例如由开发方直接提供。

如上所述，传统应用程序通常在包括其应用程序资源(例如代码和数据)的大部分(如果不是全部的话)的单个包中被下载。单个应用起始包可被解包以将应用程序安装在客户端设备上。安装过程通常涉及将应用程序资源从应用包复制到客户端设备的存储空间上。在成功安装之后，应用程序可被启动以执行其设计功能。通常，并非所有应用程序资源在应用程序运行时的所有时间都被使用。然而，只要应用程序未从设备删除，它们就会占据客户端设备上存储空间的一部分。大的应用程序可占用客户端设备上存储空间的显著部分，尤其是对于空间量有限的设备而言。当传统应用程序被卸载以释放盘空间时，整个应用程序必须被清除。

相反，在本公开的实施方案中，应用程序资源可被分组到多个资产包中，如上所述。资产包中的一者或多者可被包括在应用起始包中。当客户端设备第一次请求应用程序时，应用起始包可被发送给客户端设备，而包括按需加载资源的其他资产包可保留在服务器上。优选地，应用起始包只包括初始运行应用程序所需要的软件代码和应用程序资源。例如，重新参考图1，视频游戏应用程序100的应用起始包140可以只包括文件142,144,146、基础资源包130、和等级1包108，它们构成在客户端设备上开始游戏所需要的全部。在一个实施方案中，应用程序的开发方可基于标签来选择要包括在应用起始包中的应用程序资源(例如，在上面的示例中，选择标记为“等级1”的所有应用程序资源)。因为其他按需加载资源(例如等级2和3包中的那些)可被排除在应用起始包140之外，所以与整个应用程序在单个包中被下载相比，应用程序初始可在客户端设备上占用少得多的空间。

在游戏100被安装之后以及随着用户进展通过游戏的等级1，运行后续等级所需要的资产包可被请求和安装在客户端设备上。请求和安装资产包的各种条件可例如基于资产包如何和/或何时被使用来设置。此外，等级1资产包可能在用户完成游戏中的等级1之后不再被需要，因此在必要时可以从客户端设备移除。在下面的段落中参考图3和4描述一种动态地更新客户端设备上资产包(即按需加载资源)的示例性方法。

图3根据本公开一实施方案示出一种客户端设备的示例性模块及其在管理设备上一个或多个应用程序的应用程序资源中的交互。特别地，客户端设备300可包括作为设备的操作系统(OS)的一部分的按需加载资源守护进程(ODR)302。ODR 302可被编程为处理跨客户端设备上多个应用程序的应用程序资源管理的所有方面。特别地，ODR 302可监视应用程序的使用和设备上的可用存储空间，以及根据需要而取和清除按需加载资源。作为守护进程，ODR 302通常可在后台执行其任务，而不直接受进行交互的用户控制。

如图3所示，ODR 302可与客户端设备上的应用程序304通信。虽然在图3中只示出了一个应用程序304，但应当理解，ODR 302可与多个应用程序交互并且对于每个应用程序执行相同功能。在该实施方案中，应用程序304可以是以按需加载资源构建的应用程序，从而只有一些资源是初始下载的部分并驻留在客户端设备300上。其余按需加载资源可保存在存储于远程服务器306上的一个或多个资产包中。

客户端设备300的存储介质308中的一个区域可被指定作为用于设备300上各种应用程序304的应用程序资源的存储区域。这个指定存储区域308可以能被ODR 302访问以更新其中的应用程序资源集合。任选地，客户端设备300也可包括存储空间监视模块(或缓存删除模块)310，其可被配置为监视客户端设备300上的可用存储空间(包括用于应用程序资源的指定存储区域308)以及在检测到存储空间不足时与ODR 302通信。

应当理解，客户端设备300可包括为清楚起见而未在图3中示出的其他硬件和软件模块。例如，客户端设备300可包括处理器，用于在设备300上运行应用程序和其他程序。也可包括附加存储空间、用于通过一个或多个网络与其他设备(例如服务器306)通信的网络模块、输入/输出(I/O)设备诸如显示器、触摸屏和其他传感器。

图4根据本公开一实施方案示出在客户端设备上以按需加载资源设置和运行应用程序的示例性步骤。当用户请求从应用商店下载应用程序304时，应用程序304的应用起始包可从远程服务器306发送给客户端设备300(步骤401)。以图1的视频游戏为例，应用起始包可以只包括软件代码、基础资源包，并且任选地包括“等级1”资产包。任选地，可包括认证步骤，用于核验用户被授权下载应用程序。如果例如应用程序是访问权限限于公司中特定人员的企业ODR应用程序，则可包括这个认证步骤。应用程序可被安装在设备上，来自应用起始包的资源(包括作为初始下载的一部分的任何资产包)可保存在客户端设备300的本地存储区域308中(步骤402)。一旦应用程序被成功安装，用户就能启动应用程序(游戏)并利用客户端设备上本地可用的资源来开始玩游戏的等级1。假设游戏被设计成使得用户必须完成一个等级之后才能进入下一等级，在游戏的初始阶段期间，等级2-N所需要的应用程序资源可保留在服务器306上。应用程序304可监视用户在游戏中的进度(步骤403)。当例如应用程序304确定用户就要完成等级1时，其可确定下一等级(例如等级2)是否已经被下载并且是本地可用的。如果不是，对下一等级的请求可被发送给ODR 302(步骤404)。另选地，对于资源的请求可以用户一开始等级1就被发送，或者在检测到任何其他预定触发事件时(例如在用户进展到游戏中的预定点之后)被发送。

当ODR 302接收到来自应用程序304的请求时，其可首先确定应用程序的资产包清单是否可用(步骤405)。资产包清单可包含关于资产包可被请求的次序和资产包在网络上的位置的信息。如果没有资产包清单可用，则ODR 302可向服务器请求资产包清单(步骤406)。一些应用程序(例如付费应用)可要求服务器核验请求资产包清单的实体(例如用户或客户端设备)是该应用程序的经授权拥有者并因此有资格接收用于该应用程序的资产包清单(步骤407)。这个核验可利用任何适当的方法诸如在用户的购买历史中查找该应用程序来执行。对于某些应用程序(例如免费应用程序)，这个核验步骤可被跳过，或者始终生成肯定响应。

服务器然后可将资产包清单发送给客户端300上的ODR 302(步骤408)。ODR可使用资产包清单来标识接下来要下载哪个(哪些)资产包以及其在网络上的地址(URL)(步骤409)。对于资产包的请求然后可被制定并发送给该地址(步骤410)。在一个实施方案中，该请求可包括标识被请求的按需加载资源(及其相应资产包)的一个或多个标签(例如等级2)。

有附加安全性措施可被结合在资产包清单中以确保资产包被经授权实体(例如已购买该应用程序的用户)请求。在一些实施方案中，资产包清单中的每个URL可具有过期时间(例如12小时)。因此，即使与未经授权实体共享资产包清单，URL也将只对于有限时间段有效。为此，如果资产包清单的本地副本已过期，则可以要求甚至经授权实体在向服务器请求新的资产包之前刷新资产包清单。

除此之外或另选地，资产包清单可包括至少一个用于验证来自ODR 302的资产包请求的“时间炸弹”URL。这个“时间炸弹”可以是通过以时间戳和只有服务器知道的私密密钥对URL的部分进行散列而创建的安全性密钥。当对于资产包的请求被发送给服务器时，请求可包括结合有时间戳的URL。当服务器接收到请求时，可确定请求中的URL和时间戳是否能与服务器的私密密钥散列生成正确的安全性密钥。如果正确的安全性密钥被生成，则服务器可发布所请求的资产包。否则，请求可被拒绝。

重新参考图4，在对于资产包的请求被确证之后，服务器可将资产包传送给客户端设备300上进行请求的ODR 302(步骤411)。资产包可被存储在客户端设备的指定存储空间308中(步骤412)。与此同时或在此之后，ODR 302可向应用程序304通知新的资产包的到达，并且应用程序304可被授予对其进行访问的权利(步骤413)。应用程序然后可在程序需要用于等级1的应用程序资源时(例如当用户完成等级1并开始等级2时)加载资产包(例如等级2包)(步骤414)。

只要应用程序在运行并且基于应用程序的状态(例如用户进度)需要新的资产包，就可重复步骤403-414。如果客户端设备上的资产包清单还未过期，则可跳过这些步骤中的一些(例如步骤406-408)。在优选实施方案中，ODR 302可基于例如应用程序的运行状态、使用模式数据、和/或网络强度来预测对按需加载资源的需求，并在应用程序304实际需要之前自动地预取包含这些资源的资产包。取决于客户端设备的平台(例如设备的类型)，ODR302可被编程为在预取资产包方面较激进或较不激进。如果设备是存储空间相对大和/或对网络的接入差的设备，则ODR可在加载资产包方面较激进，使得在设备失去其对网络的连接并且不能下载附加资源时，应用程序不会发生故障。相反，存储区域相对小但网络连接快且稳定的设备的ODR在预取按需加载资源方面可以较不激进。相反，此类设备的ODR会在资源变得被需求时进行更频繁的请求。

下载按需加载资源的这整个过程可在后台执行，而不需要任何用户输入。可使按需加载资源透明地可供应用程序使用，就好像其从初始安装就已经是应用程序的一部分。实际上，用户会不知道应用程序的部分是在运行时从服务器动态地下载的。

如上所述，通过将与应用程序相关联的应用程序资源分组到资产包中，为了应用程序正常运行，并非所有应用程序资源都必须始终驻留在客户端设备上。因此，即使相对大的应用程序也能被安装在客户端设备上，而不占用大量存储空间。这继而可释放存储空间用于其它应用程序和数据。

与应用程序相关联的按需加载资源不仅可以在应用程序对其进行请求时单独地从服务器获取，而且相同的按需加载资源在应用程序对于不久的将来或将来长期不再需要其时可在不影响应用程序的其余部分的情况下被清除。在一些实施方案中，应用程序一旦不再对按需加载资源有需求，按需加载资源就可被清除。在其它实施方案中，即使在应用程序不再利用按需加载资源时，按需加载资源也可保留在设备上。其可以只响应于设备上存储空间不足才被清除。在另外一些实施方案中，即使按需加载资源可能对于应用程序仍然是有用的，按需加载资源也可被清除。用于清除资源的标准和优先顺序可由开发方在构建应用程序时设置。

图5根据本公开一实施方案示出将应用程序资源从客户端设备清除的示例性步骤。图3的存储空间监视模块(缓存删除模块)310可监视客户端设备上的空间使用(步骤501)。当例如由于用户试图下载新应用程序或内容到设备300而检测到空间不足时，可发送请求给ODR 302，请求释放一些空间用于新应用程序/内容(步骤502)。在一些实施方案中，ODR 302可在未被通知可用空间不足的情况下自己引发空间清理过程。作为响应，ODR 302可审视存储在指定存储空间308中的资产包并确定哪个资产包包含可能将不被相应应用程序使用并因此可从设备300清除的资源(步骤503)。对于哪些资源是能清除的以及可对其进行清除的次序，可设置各种标准，如以下段落详细所述。优选地，ODR 302被编程为只要资源或包含资源的资产包仍然被至少一个应用程序请求就不试图将其从存储区域308清除。在对于哪个资产包(或应用程序)要被清除进行了选择之后，ODR 302可将其从存储区域308删除(步骤504)。

在各种实施方案中，ODR 302可被编程为基于一个或多个不同标准来选择用于清除的按需加载资源。在一个实施方案中，ODR 302可简单地清除不再被需求(例如不被任何应用程序请求)的任何或所有按需加载资源。当资产包及其应用程序资源不再被应用程序请求并且可能在不久的将来会被再次需要时，资产包/资源可被标记为可清除和/或可朝着用于清除的候选列表的顶部放置。如果资产包仍然被应用程序需要和/或预期继续至少在一定程度上被使用，则资产包可被标记为保留和/或在清除列表上排名较低。例如，如果用户已经完成了游戏中的等级1，但仍然在进行等级2，则资产包“等级2”可被标记为“保留”和/或在清除列表上排名低于资产包“等级1”。清除列表可包括与安装在客户端设备上的一个或多个应用程序相关联的资产包/资源。资产包/资源的排名可至少部分地基于应用程序的运行状态而动态地改变。

除此之外或另选地，ODR 302可基于应用程序开发方设置的偏好来进行选择。这些偏好可被存储作为与资产包清单中每个资产包相关联的元数据的一部分。例如，开发方可将与一个资产包相关联的“从不删除”标记设置为1，以指示只要应用程序未从设备上删除，这个特定资产包就应始终保留在客户端设备上。如果另一资产包的相同标记被设置为0，则该资产包可以是用于清除的候选者。又如，开发方可为应用程序中的每个资产包(或按需加载资源)设置优先数。优先数可指示应用程序的各个资产包(或资源)的优选清除顺序。当ODR302希望释放设备上的空间时，其可搜索例如具有最低优先数的资产包。

除此之外或另选地，试探法可被构建到清除(和/或下载)顺序中。特别地，可在多个客户端设备上收集应用程序的不同使用模式。基于这些使用模式，可预测资产包在应用程序运行期间在不同阶段可能被使用的顺序。使用模式也可反映例如资产包中的每一者的总体使用率。也可反映应用程序可能多频繁和/或何时要被特定用户使用。例如，如果应用程序通常只在周末被使用，则在每个周末之后如果存储空间变得紧张，其可以是可能的清除候选者。可在周末之前通过移除其他不太可能在周末被使用的应用程序/资源来将其重新安装。

又如，如果用户已经将相同应用程序下载到多个客户端设备上，则该用户在第一设备上该应用程序中的进度可被跟踪并保存在远程服务器上，使得当该用户移到第二设备上时，可在该用户开始在第二设备上使用该应用程序之前将恢复其会话所需要的应用程序资源预取到第二设备上。

再如，如果客户端设备上的应用程序被多个用户共享，则可在客户端侧基于例如用户的设备/应用程序登录来单独跟踪每个用户对该应用程序的使用。当第一用户登录到客户端设备/应用程序上时，ODR 302可基于用户先前的应用使用模式来确定在设备上是否有其将可能使用的应用程序/资产包可供使用。如果没有，则ODR可以用户一登录到设备上就向服务器请求这些应用程序/资产包。在一些实施方案中，如果在设备上没有足够的存储空间可用，则ODR可清除其他用户下载的其他应用程序/资产包。当第二用户登录到设备上时，其应用程序/资产包可自动加载到设备上，并且如果必要的话，与第一用户相关联的应用程序/资产包可被移除以释放存储空间。如果多个用户共享相同应用程序或应用程序的相同资产包，则应用程序或资产包可保留在设备上，而不管是哪个用户登录到设备上。

取决于客户端设备的平台(例如设备的类型)，ODR 302也可被编程为在清除资产包方面较激进或较不激进。如果设备是存储空间相对大和/或对网络的接入差的设备，则ODR可在清除资产包方面较不激进。相反，存储区域相对小但网络连接快且稳定的设备的ODR在清除按需加载资源方面可以较激进。

在一个实施方案中，资产包不仅可以与应用程序相关联，而且可与应用程序的特定版本相关联。通常，在已经对应用程序进行了改变时，应用程序的新版本可被推出。因为本公开实施方案中公开的应用程序的各种资源可被分组到多个资产包中，所以在应用程序的新版本推出时，对于至少一些资产包可能没有任何改变。如果新版本的改变相对小，则大多数资产包可能并不需要被刷新。只有已经被更新的那些资产包需要重新被下载以替换先前版本。在一个实施方案中，每个资产包的内容可被散列以创建内容散列，这可用于确定在资产包的新版本被发布时是否有任何内容已经被改变。如果新版本的内容散列与当前版本的内容散列保持相同，则不需要重新下载这特定资产包。如果新版本的内容散列与当前版本的内容散列不匹配，则资产包的新版本可被下载以替换当前版本。优选地，即使与资产包相关联的一些不那么重要的信息(例如时间戳、代码签名、和其他元数据)改变，内容散列也可保持相同。内容散列应该只在资产包中的实际内容(即资源)改变的情况下才改变。

图6根据本公开一实施方案示出以按需加载资源将应用程序更新到新版本的示例性步骤。首先，当客户端设备第一次从服务器接收资产包(或应用起始包)(步骤601)时，其可基于资产包(或应用包)中的实际内容(即，资源)计算和存储内容散列(步骤602)。当服务器接收应用程序的新更新时，其可为应用程序中的每个资产包/应用包重新计算内容散列(步骤603)。重新计算的内容散列可被包括在资产包清单中(步骤604)。当客户端设备请求最新资产包清单时，其也可获取所有资产包的重新计算的内容散列(步骤605)。客户端设备于是可将重新计算的内容散列与本地存储的相应内容散列进行比较，以标识已经改变的资产包(步骤606)。对于应用程序更新，客户端设备于是可以只请求那些被标识的资产包，而不是下载所有资产包(步骤607)。为了使用内容散列来核验对资产包的更新，每个资产包可包括在版本更新中可保持稳定的标识符。在一个实施方案中，与每个资产包相关联的标签(或标签组合)可被用作为该资产包的标识符。

在本公开的另一方面中，可为应用程序的开发方提供应用程序接口(API)(或API集合)，用于以按需加载资源构建应用程序。

API是由程序代码组件或硬件组件(在下文中称为“API实现组件”)来实现的接口，其允许另一程序代码组件或硬件组件(在下文中称为“API调用组件”)访问和使用由API实现组件提供的一个或多个函数、方法、流程、数据结构、类和/或其它服务。API可定义在API调用组件和API实现组件之间传递的一个或多个参数。

API允许API调用组件的开发方(可以是第三方开发方)利用由API实现组件提供的指定特征。可以有一个API调用组件或可以有超过一个这样的组件。API可以是计算机系统或程序库提供的源代码接口，以便支持来自应用程序的服务请求。操作系统(OS)可以具有多个API，以允许运行于OS上的应用程序调用那些API中的一个或多个API，服务(例如程序库)可具有多个API，以允许使用服务的应用程序调用那些API中的一个或多个API。可按照在构建应用程序时能够解译或编译的编程语言来指定API。

在一些实施方案中，API实现组件可提供多于一个API，每个API提供由API实现组件实现的功能的不同视图，或提供访问由API实现组件实现的功能的不同方面的不同方面。例如，API实现组件的一个API可提供第一组功能，并可暴露给第三方开发方，API实现组件的另一个API可被隐藏(不暴露)并提供第一组功能的子组，并且还提供另一组功能，诸如不在第一组功能中的测试或调试功能。在其它实施方案中，API实现组件本身可经由下层API调用一个或多个其它组件，因而可以既是API调用组件又是API实现组件。

API定义在访问和使用API实现组件的指定特征时API调用组件所使用的语言和参数。例如，API调用组件通过被API暴露的一个或多个API调用或引用(例如由函数或方法调用实现)访问API实现组件的指定特征，并经由API调用或引用使用参数传递数据和控制信息。API实现组件可响应于来自API调用组件的API调用而通过API返回值。尽管API定义API调用的语法和结果(例如，如何引起API调用以及API调用能干什么)，但API可不揭示API调用如何完成由API调用指定的函数。经由调用(API调用组件)和API实现组件之间的一个或多个应用编程接口传输各种API调用。传输API调用可包括发出、发起、引用、调用、接收、返回或响应函数调用或消息；换言之，传输可通过API调用组件或API实现组件来描述动作。API的函数调用或其它引用可通过参数列表或其它结构发送或接收一个或多个参数。参数可以是常数、键、数据结构、对象、对象类、变量、数据类型、指针、数组、列表或指向函数或方法的指针或援引要经由API传递的数据或其它项目的另一种方式。

此外，数据类型或类可以由API提供并由API实现组件实现。因此，API调用组件可利用API中提供的定义声明变量、使用指向这种类型或类的指针、使用或实例化这种类型或类的恒定值。

通常，可使用API来访问由API实现组件提供的服务或数据或启动执行由API实现组件提供的操作或计算。以举例的方式，API实现组件和API调用组件各自可以是操作系统、库、设备驱动程序、API、应用程序或其它模块(应当理解，API实现组件和API调用组件可以是彼此相同或不同类型的模块)中的任一种。在一些情况下，可至少部分地在固件、微码或其它硬件逻辑中实现API实现组件。在一些实施例中，API可以允许客户端程序使用由软件开发工具包(SDK)库提供的服务。在其他实施例中，应用程序或其他客户端程序可以使用由应用程序框架提供的API。在这些实施例中，应用程序或客户端程序可以将调用并入由SDK提供和由API提供的函数或方法中，或使用SDK中定义并由API提供的数据类型或对象。在这些实施例中，应用程序框架可以为程序提供主要事件循环，该程序对框架定义的各种事件做出响应。API允许应用程序利用应用程序框架来指定事件和对事件的响应。在一些具体实施中，API调用能够向应用程序报告硬件设备的能力或状态，包括与诸如输入能力和状态、输出能力和状态、处理能力、电源状态、存储容量和状态、通信能力等方面相关的能力或状态，API可部分地由固件、微码或部分地在硬件组件上执行的其它低电平逻辑实现。

API调用组件可以是本地组件(即与API实现组件在同一数据处理系统上)或远程组件(即在不同于API实现组件的数据处理系统上)，所述组件经由网络通过API与API实现组件通信。应当理解，API实现组件也可充当API调用组件(即，它可以对不同API实现组件暴露的API进行API调用)，API调用组件也可以通过实现暴露于不同API调用组件的API来充当API实现组件。

API可允许用不同编程语言编写的多个API调用组件来与API实现组件通信(从而API可包括用于转换API实现组件和API调用组件之间调用和返回的特征)；然而，API可从具体编程语言方面实现。在一种实施方案中，API调用部件可调用来自不同提供方的API，诸如来自OS提供方的一组API和来自插件提供方的另一组API，以及来自另一提供方(例如软件库的提供方)或另一组API的创建方的另一组API。

图7是示出可在本公开的一些实施方案中使用的一种示例性API架构的框图。如图7中所示，API架构700包括实现API 720的API实现组件710(例如，操作系统、库、设备驱动程序、API、应用程序、软件或其它模块)。API 720指定可由API调用组件730使用的API实现组件的一个或多个函数、方法、类、对象、协议、数据结构、格式和/或其它特征。API 720能够指定至少一个调用约定，该调用约定指定API实现组件中的函数如何从API调用组件接收参数以及函数如何向API调用组件返回结果。API调用组件730(例如操作系统、库、设备驱动程序、API、应用程序、软件或其它模块)通过API 720进行API调用，以访问和使用由API 720指定的API实现组件710的特征。API实现组件710可以响应于API调用而通过API 720向API调用组件530返回值。

应当理解，API实现组件710可包括未通过API 720指定和对于API调用组件730不可用的附加函数、方法、类、数据结构和/或其它特征。应理解，API调用组件730可与API实现组件710在同一系统上，或者可远程定位并通过网络来使用API 720访问API实现组件710。尽管图7示出了单个API调用组件730与API 720交互，但应理解，可用与API调用组件730不同的语言(或相同的语言)编写的其它API调用组件可使用API 720。

API实现组件710、API 720和API调用组件730可以存储在机器可读介质中，其包括用于以机器(例如计算机或其他数据处理系统)可读的形式存储信息的任何机构。例如，机器可读介质包括磁盘、光盘、随机存取存储器、只读存储器、闪存设备等。

在图8(“软件栈”)中，一个示例性实施方案，应用程序可使用若干服务API调用服务A或B，以及使用若干操作系统(OS)API调用OS。服务A和B可使用若干OS API对OS进行调用。

注意，服务2具有两个API，其中一个(服务2API 1)从应用程序1接收调用并返回值，另一个(服务2API 2)从应用程序2接收调用并返回值。服务1(例如，可以是软件库)对OSAPI 1进行调用并接收从OS API 1返回的值，服务2(例如，可以是软件库)对OS API 1和OSAPI 2两者进行调用并接收从这两者返回的值。应用程序2对OS API 2进行调用并接收返回的值。

本文公开的API的一个实施方案可包括以下示例性数据结构(例如对象类)、参数和例程。应当理解，这些示例可以任何合适的编程语言诸如Objective C来实施。

在这个示例性具体实施中，资源请求对象可管理实际上为应用程序的一部分但被远程存储的按需加载资源的可用性。应用程序可使用该请求来向系统通知相关联的资源何时被需要以及何时已经完成对其的使用。资源请求于是可下载任何还未缓存在设备上的资源并向应用程序通知资源何时准备就绪供使用。

可选的设置可提供关于资源的下载和清除分组的相对优先顺序的提示。分组可被标记为对于应用程序被要求。取决于平台，可阻止系统将这些资源从存储装置删除，或者其在应用程序被启动时被下载。每个资源请求只可用于访问资源一次。

每个资源请求对象可管理一组相关的按需加载资源。在应用程序被构建之前，可为每组相关资源创建标签，并将其分配给按需加载资源。资源请求可包括其管理的资源的这组标签。资源请求可以只下载还未在设备上的资源。下载的资源可以与应用起始包中的那些相同的方式来访问。对还未下载的资源的访问可与对在应用中不存在的资源的访问为相同的方式。

只要一个资源请求对象可对其进行访问，系统就不可将资源从设备上存储装置清除。访问可响应于结束访问的调用而结束，或者在资源请求对象被释放时结束。

按需加载资源在没有资源请求对象正在对其进行访问之后可被保留。随着系统要求更多存储空间，资源可被清除。被标记的资源分组可具有相对的保留优先级。系统可尝试首先清除较低优先级的资源。

被标记的资源可被设置为对于应用程序被要求。对于一些平台，这可在资源不再被访问时阻止从存储装置删除资源，包括跨应用程序启动对其保留。在其他平台上，系统可在启动应用程序之前下载资源。被标记为永久保留的资源可列入应用程序使用的总存储。

API可提供以下示例性功能。例如，可基于将指定存储在主包中的一个或多个资源的标签的名称作为输入的调用来创建对于管理标记以指定标识符的远程资源的初始化资源请求。每个标签的值可对应于分配给资源逻辑分组的标识符。可通过在调用中包括可选的“包”参数来指定用于存储所加载资源的包。可通过使用对用于存储所下载资源的包的标引来访问资源请求的配置。包可以是主包或者是在API调用中指定的包。

API也可提供配置每个资源请求的优先级的方式。系统于是可尝试为具有较高值的资源请求给予优先级。资源请求的优先级可在任何时候被改变，甚至在资源请求已开始之后。

API也可提供请求对资源请求对象所管理的资源的访问的方式。对资源的访问可以资源请求对象所管理的资源是否已经在设备上为条件。如果已经在设备上，则系统可开始访问这些资源。如果资源未在设备上，则可向服务器请求这些资源。在仍然可对资源进行访问时可阻止系统清除所述资源。

API还可提供向系统通知与资源请求对象相关联的资源不再正被访问的方式。该方法可在资源请求对象被释放时被调用。API也可提供跟踪资源请求的进展的方式。

此外，API也可提供用于配置缓存优先级(例如，对于清除资源的相对顺序)的方式。这个调用可以需要优先级参数，优先级参数可以是指定保留相应标签所指定的分组中的资源的相对优先级的数。系统可尝试首先清除所缓存的优先级较低的资源。此外，布尔值可被用于指定系统是否可清除与所指定标签相关联的资源。可使被标记为保留的资源跨应用程序启动可供使用。取决于平台，这可通过阻止系统将其清除或者通过在应用程序被启动时对其下载来进行。保留资源的一般原因之一可以是脱机使用。

此外，API可提供在资源请求系统检测到可用于被下载资源的盘空间量变得低之后发布通知的方式。在接收到该通知之后，应用程序可尝试通过例如释放不再被需要的任何按需加载资源来释放盘空间。如果应用程序在后台并且应用程序未释放足够空间，则其可被终止。

上述以按需加载资源构建、部署、运行和更新应用程序的系统和方法可以软件、固件、硬件和/或以上三者的任意组合来实施。在这些模块中的一者或多者以软件实施的实施方案中，它们可在任何非暂态计算机可读存储介质内进行存储和/或传送，以供指令执行系统、装置或设备诸如基于计算机的系统、包含处理器的系统或可从指令执行系统、装置或设备取指令并执行指令的其他系统使用或与其结合。在本文的语境中，“非暂态计算机可读存储介质”可以是可包括或存储程序以供指令执行系统、装置和设备使用或与其结合的任何介质。非暂态计算机可读存储介质可包括但不限于，电子、磁性、光学、电磁、红外或半导体系统、装置或设备、便携式计算机磁盘(磁性)、随机存取存储器(RAM)(磁性)、只读存储器(ROM)(磁性)、可擦除可编程只读存储器(EPROM)(磁性)、便携式光盘(诸如CD、CD-R、CD-RW、DVD、DVD-R或DVD-RW)、或闪存存储器(诸如紧凑型闪存卡、安全数字卡)、USB存储设备、记忆棒等。非暂态计算机可读存储介质可以是计算设备的存储介质的一部分。

应当理解，虽然以上实施方案是参照视频游戏来描述的，但任何类型的软件应用程序都可利用所公开的系统和方法来实施。

虽然参照附图对实施方案进行了全面的描述，但应注意，各种变化和修改对于本领域内的技术人员而言将变得显而易见。应当理解，此类变化和修改被认为包括在由所附权利要求所限定的各种实施方案的范围内。

Claims (20)

1.一种系统，包括：

一个或多个处理器；

存储器；和

一个或多个程序，其中所述一个或多个程序被存储在所述存储器中并被配置为由所述一个或多个处理器执行，所述一个或多个程序在被所述一个或多个处理器执行时使所述系统执行在设备上运行应用程序的方法，所述方法包括：

从网络源获取所述应用程序的应用起始包；

利用所述应用起始包来安装所述应用程序；

基于所述应用程序执行的一个或多个功能来确定所述应用程序在第一时间的第一运行状态；

响应于确定所述应用程序在所述第一时间的所述第一运行状态，请求多个按需加载资源中的在所述第一时间不在所述设备上且与所述应用程序相关联的第一按需加载资源，其中：

根据确定所述应用程序的所述第一运行状态满足第一运行状态标准，所述第一按需加载资源包括第一资源，

根据确定所述应用程序的所述第一运行状态满足不同于所述第一运行状态标准的第二运行状态标准，所述第一按需加载资源包括不同于所述第一资源的第二资源，并且

所述应用程序的所述第一运行状态与对所述设备的用于运行所述应用程序的对应于所述第一按需加载资源的一部分的用户输入无关；

从所述网络源接收所述第一按需加载资源，而不接收所述多个按需加载资源中的第二按需加载资源；以及

在所述应用程序中加载所述第一按需加载资源。

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

基于所述应用程序执行的一个或多个功能来确定所述应用程序

在所述第一时间之后的第二时间的第二运行状态；

响应于确定所述应用程序在所述第二时间的所述第二运行状态，请求所述多个按需加载资源中的所述第二按需加载资源，其中：

根据确定所述应用程序的所述第二运行状态满足第三运行状态标准，所述第二按需加载资源包括第三资源，

根据确定所述应用程序的所述运行状态满足不同于所述第三运行状态标准的第四状态标准，所述第二按需加载资源包括不同于所述第三资源的第四资源，并且

所述应用程序的所述第二运行状态与对所述设备的用于运行所述应用程序的对应于所述第二按需加载资源的一部分的用户输入无关；

从所述网络源接收所述第二按需加载资源；以及

在所述应用程序中加载所述第二按需加载资源。

3.根据权利要求1所述的系统，所述方法还包括在请求所述第一按需加载资源之前检查在所述设备上所述第一按需加载资源是否可用，其中请求所述第一按需加载资源是响应于确定在所述设备上所述第一按需加载资源不可用。

4.根据权利要求1所述的系统，所述方法还包括：

确定在所述设备上资产包清单是否可用，所述资产包清单包括所述第一按需加载资源的地址；

获取所述资产包清单；以及

利用所述资产包清单中的所述地址来请求所述第一按需加载资源。

5.根据权利要求1所述的系统，所述方法还包括基于所述应用程序的所述第一运行状态确定包括所述第一按需加载资源的多个按需加载资源要被请求的顺序。

6.根据权利要求1所述的系统，所述方法还包括：

确定在所述设备上是否检测到存储空间不足；

如果在所述设备上检测到存储空间不足，确定要从所述设备清除的所述应用程序的至少一个按需加载资源；以及

在所述应用程序在所述设备上运行时，从所述设备清除所述至少一个按需加载资源。

7.根据权利要求6所述的系统，其中确定要清除的至少一个按需加载资源至少部分地基于所述应用程序的所述第一运行状态。

8.根据权利要求6所述的系统，其中确定要清除的至少一个按需加载资源至少部分地基于多个按需加载资源的预先确定清除顺序。

9.根据权利要求6所述的系统，其中确定要清除的至少一个按需加载资源至少部分地基于与所述应用程序相关联的使用模式。

10.根据权利要求1所述的系统，其中在所述应用程序在所述设备上运行时：

在所述第一时间，所述应用程序的第一组按需加载资源在所述设备上，并且

在所述第一时间之后的第二时间，所述应用程序的第二组按需加载资源在所述设备上，其中所述第一组按需加载资源包括未包括

在所述第二组按需加载资源中的按需加载资源。

11.根据权利要求1所述的系统，其中确定所述应用程序的所述第一运行状态满足所述第一运行状态标准包括在所述应用程序需要所述第一资源之前预测所述应用程序对所述第一资源的需要，并且确定所述应用程序的所述第一运行状态满足所述第二运行状态标准包括在所述应用程序需要所述第二资源之前预测所述应用程序对所述第二资源的需要。

12.一种非暂态计算机可读介质，所述计算机可读介质包含指令，所述指令在被执行时执行在设备上运行应用程序的方法，所述方法包括：

从网络源获取所述应用程序的应用起始包；

利用所述应用起始包来安装所述应用程序；

基于所述应用程序执行的一个或多个功能来确定所述应用程序在第一时间的第一运行状态；

响应于确定所述应用程序在所述第一时间的所述第一运行状态，请求多个按需加载资源中的在所述第一时间不在所述设备上且与所述应用程序相关联的第一按需加载资源，其中：

根据确定所述应用程序的所述第一运行状态满足第一运行状态标准，所述第一按需加载资源包括第一资源，

根据确定所述应用程序的所述第一运行状态满足不同于所述第一运行状态标准的第二运行状态标准，所述第一按需加载资源包括不同于所述第一资源的第二资源，并且

所述应用程序的所述第一运行状态与对所述设备的用于运行所述应用程序的对应于所述第一按需加载资源的一部分的用户输入无关；

从所述网络源接收所述第一按需加载资源，而不接收所述多个按需加载资源中的第二按需加载资源；以及

在所述应用程序中加载所述第一按需加载资源。

13.根据权利要求12所述的非暂态计算机可读介质，所述方法还包括：

基于所述应用程序执行的一个或多个功能来确定所述应用程序在所述第一时间之后的第二时间的第二运行状态；

响应于确定所述应用程序在所述第二时间的所述第二运行状态，请求所述多个按需加载资源中的所述第二按需加载资源，其中：

根据确定所述应用程序的所述第二运行状态满足第三运行状态标准，所述第二按需加载资源包括第三资源，

根据确定所述应用程序的所述第二运行状态满足不同于所述第三运行状态标准的第四运行状态标准，所述第二按需加载资源包括不同于所述第三资源的第四资源，并且

所述应用程序的所述第二运行状态与对所述设备的用于运行所述应用程序的对应于所述第二按需加载资源的一部分的用户输入无关；

从所述网络源接收所述第二按需加载资源；以及

在所述应用程序中加载所述第二按需加载资源。

14.根据权利要求12所述的非暂态计算机可读介质，所述方法还包括在请求所述第一按需加载资源之前检查在所述设备上所述第一按需加载资源是否可用，其中请求所述第一按需加载资源是响应于确定在所述设备上所述第一按需加载资源不可用。

15.根据权利要求12所述的非暂态计算机可读介质，所述方法还包括：

确定在所述设备上资产包清单是否可用，所述资产包清单包括所述第一按需加载资源的地址；

获取所述资产包清单；以及

利用所述资产包清单中的所述地址来请求所述第一按需加载资源。

16.根据权利要求12所述的非暂态计算机可读介质，所述方法还包括基于所述应用程序的所述第一运行状态确定包括所述第一按需加载资源的多个按需加载资源要被请求的顺序。

17.根据权利要求12所述的非暂态计算机可读介质，所述方法还包括：

确定在所述设备上是否检测到存储空间不足；

如果在所述设备上检测到存储空间不足，确定要从所述设备清除的所述应用程序的至少一个按需加载资源；以及

在所述应用程序在所述设备上运行时，从所述设备清除所述至少一个按需加载资源。

18.根据权利要求12所述的非暂态计算机可读介质，其中在所述应用程序在所述设备上运行时：

在所述第一时间，所述应用程序的第一组按需加载资源在所述设备上，并且

在所述第一时间之后的第二时间，所述应用程序的第二组按需加载资源在所述设备上，其中所述第一组按需加载资源包括未包括

在所述第二组按需加载资源中的按需加载资源。

19.根据权利要求12所述的非暂态计算机可读介质，其中确定所述应用程序的所述第一运行状态满足所述第一运行状态标准包括在所述应用程序需要所述第一资源之前预测所述应用程序对所述第一资源的需要，并且确定所述应用程序的所述第一运行状态满足所述第二运行状态标准包括在所述应用程序需要所述第二资源之前预测所述应用程序对所述第二资源的需要。

20.一种在设备上运行应用程序的计算机实现的方法，包括：

从网络源获取所述应用程序的应用起始包；

利用所述应用起始包来安装所述应用程序；

基于所述应用程序执行的一个或多个功能来确定所述应用程序在第一时间的第一运行状态；

响应于确定所述应用程序在所述第一时间的所述第一运行状态，请求多个按需加载资源中的在所述第一时间不在所述设备上且与所述应用程序相关联的第一按需加载资源，其中：

根据确定所述应用程序的所述第一运行状态满足第一运行状态标准，所述第一按需加载资源包括第一资源，

根据确定所述应用程序的所述第一运行状态满足不同于所述第一运行状态标准的第二运行状态标准，所述第一按需加载资源包括不同于所述第一资源的第二资源，并且

所述应用程序的所述第一运行状态与对所述设备的用于运行所述应用程序的对应于所述第一按需加载资源的一部分的用户输入无关；

从所述网络源接收所述第一按需加载资源，而不接收所述多个按需加载资源中的第二按需加载资源；以及

在所述应用程序中加载所述第一按需加载资源。

Images