CN113924548A - 特征文件批的自动水合 - Google Patents

Abstract

计算设备通过预先将针对多批特征文件的有效载荷写入本地存储并且然后在相关联的特征被调用时自动下载针对个体多批特征文件的有效载荷来节省存储空间。在各种实施例中，包括频繁使用特征和不频繁使用特征两者的操作系统(OS)在计算设备上执行。针对OS的频繁使用特征的多批特征文件可以在计算设备上水合，而针对OS的不频繁使用特征的多批特征文件可以在计算设备上保持脱水。当不频繁使用特征被请求时，计算设备自动下载对应一批特征文件。然后，计算设备可以通过实现不频繁使用特征来满足请求。因此，除非被调用，否则预定多批特征文件保持在计算设备处立即可访问而不消耗存储空间。

Description

特征文件批的自动水合

背景技术

计算设备通常配置有软件组件，该软件组件供应对远超过常规使用的特征的大量特征的访问。在最大化计算设备的多功能性方面，供应对实际很少使用的特征的访问是有益的。例如，典型的操作系统(OS)可能包括数百或甚至数千个可能很少或甚至从未被任何给定用户使用的特征。将OS完全安装到计算设备上可以提供最大的多功能性，因为事先知道将使用哪些特征是不切实际的——更不用说何时使用了。不幸的是，在本地存储实现常规使用的特征和很少使用的特征两者所需要的所有特征文件会消耗大量的驱动器空间。这在具有低存储容量的计算设备中尤其麻烦。

一些技术通过移除很少使用特征文件来减少计算设备上的总体软件占用空间。这样的技术使用户能够手动选择要移除以释放存储空间的特征文件。然而，即使对于经验丰富的用户，这些技术也很麻烦并且容易出错的，因为随着时间的推移，很多OS特征和应用都是递增被开发的，并且包括对大量特征文件的依赖。出于这个原因，用户可能不完全了解运行某些应用需要哪些特征文件，并且可能会标记以移除实现期望功能所需要的特征文件——无意中使期望功能无法运行。因此，虽然希望防止很少使用特征文件消耗存储空间，但是常规设备不能在实现这一点的同时在这些特征文件被调用时提供对这些特征文件的可访问性。

正是针对这些和其他考虑因素，提出了本文中做出的公开。

发明内容

本文中所描述的技术使计算设备能够通过预先将针对预定多批特征文件的有效载荷写入本地存储并且然后在相关联的特征被调用时自动下载针对个体多批特征文件的有效载荷来节省存储空间。示例性实施例包括初始配置具有处于水合(hydrate)状态的一些多批特征文件和处于脱水状态的其他多批特征文件的计算设备。出于说明的目的，假定操作系统(OS)在计算设备上执行并且OS包括很多特征——其中一些特征频繁被使用，一些特征很少被使用。与OS的频繁使用特征相关联的多批特征文件可以在计算设备上被水合。相反，与操作系统的很少使用特征相关联的其他多批特征文件可以在计算设备上保持脱水(dehydrate)。在经由请求来调用很少使用特征的情况下，计算设备可以自动下载和本地存储与这个很少使用特征相关联的特定一批特征文件。然后，一旦特定一批特征文件被写入本地存储器，计算设备就可以通过实现很少使用特征来满足请求。以这种方式，除非被调用，否则预定多批特征文件保持在计算设备处立即可访问而不消耗计算设备上的存储空间。

作为特定但非限制性的示例，计算设备可以执行包括传统应用(例如，微软Internet Explorer)的OS，该传统应用在OS上已经被新的默认应用(例如，微软Edge)取代。计算设备的原始设备制造商(OEM)可以确定，虽然从资源使用的角度来看，除非需要，本地存储针对传统应用的有效载荷是需要的，但从多功能性的角度来看，传统应用的持续可用性是合乎需要的(例如，某些用户可能更偏好传统应用而不是新的默认应用)。基于这些相互竞争的考虑因素，OEM最初可以利用预定一批特征文件来配置计算设备，这些特征文件启用在脱水状态中的传统应用的实现。这可以包括将个体占位符文件写入计算设备以代替该预定一批特征文件的每个实际特征文件。例如，假定预定一批特征文件包括三个个体特征文件，这些特征文件各自与传统应用特定地关联(例如，ie.dll、ie.exe和ie.xxx)。在该示例中，计算设备最初可以被配置具有三个占位符文件，并且每个个体占位符文件可以包括指示地址的元数据，从该地址可以下载针对对应特征文件的有效载荷。

由于占位符文件的存在，从计算设备的用户和甚至在计算设备上运行的其他应用的角度来看，传统应用可能看起来是本地可获得的。例如，针对传统应用的图标可以出现在操作系统的应用菜单中。然而，当用户(或另一应用)生成针对传统应用的请求时，计算设备可以快速确定其当前处于脱水状态。然后，基于该确定，计算设备可以通过执行中间步骤(即，在接收请求与服务于请求之间的步骤)以完全下载和水合预定一批特征文件来响应。在完成这个中间步骤之后，计算设备然后可以满足请求，就好像在最初接收到请求时预定一批特征文件被水合一样。以这种方式，某些OS特征可以脱水以减少OS占用空间，而不会影响用户和应用与OS交互的方式。

在示例性实施例中，计算设备具有存储介质，该存储介质包括以水合状态存储的一些多批特征文件和以脱水状态存储的其他多批特征文件。如本文中使用的，术语“水合状态”在用于描述个体特征文件和/或一批特征文件的状态时是指其中个体特征文件和/或一批特征文件的有效载荷被本地存储在计算设备的存储介质上的状态。例如，如果针对特定特征的特定一批特征文件以水合状态存储在计算设备上，则对于该特定特征所独有的所有二进制文件以及特定特征的有效载荷的任何其他部分(例如，权限、注册表设置等)实际上被写入存储介质并且占用存储介质上的空间(例如，字节)。相比之下，术语“脱水状态”在用于描述个体特征文件和/或一批特征文件的状态时，是指其中个体特征文件和/或一批特征文件的有效载荷没有被本地存储在计算设备的存储介质上的状态。例如，如果针对特定特征的特定一批特征文件以脱水状态被存储在计算设备上，则对于该特定特征所独有的二进制文件和/或特定特征的有效载荷的其他部分不会被写入存储介质并且不占用存储介质上的空间。

应当理解，以脱水状态存储个体特征文件或其多批文件的主要好处是节省磁盘空间。以有效载荷大小为1.93GB的Windows混合现实特征(例如，CAB文件名称：微软-视窗-全息-桌面-FOD-包～31bf3856ad364e35～amd64～～.cab)为例。如本文所述，以脱水状态存储该特定特征将有效地将OS的存储占用空间减少1.93GB-减去代替有效载荷而存储的任何元数据和/或占位符文件的大小。还应当理解，如果使计算设备能够实现特定特征的(多个)特征文件被脱水，则这些(多个)特征文件将需要通过从有效的安装源下载这些(多个)特征文件和/或其有效载荷来被水合。

关于根据需要将个体多批特征文件自动水合到本地驱动器上，计算设备可以接收访问当前脱水的特征文件的请求——但是当水合时可用于实现期望特征的方面时。换而言之，实际上可用于实现期望特征的特征文件的有效载荷部分当前并未存储在计算设备的本地存储介质上。请求访问的特征文件(本文中也称为“所请求的特征文件”)可以被包括在包括一个或多个其他特征文件的一批特征文件中。作为具体示例，所请求的特征文件可以是名为“feature_name.exe”的特征文件，它与名为“feature_name.dll”的另一特征文件一起批处理。

在接收到请求时，计算设备可以取回与所请求的特征文件相关联地被写入到存储介质的至少一些元数据。例如，在一些实施例中，占位符文件可以被写入存储介质以代替与脱水特征相关联的实际特征文件。占位符文件可以包括指示可以从其下载特征文件的地址的元数据。在一些实施例中，占位符文件还指示特征文件的特征提供方。简单地说，个体占位符文件可以指向它们用作其占位符的实际特征文件。

计算设备然后可以使用元数据来生成下载请求，该下载请求与所请求的特征文件相关联。在一些实施例中，计算设备可以向同步引擎提供元数据以标识所请求的特征文件并且指示可以从其获取所请求的特征文件的适当特征提供方。基于元数据，同步引擎然后可以生成下载请求并且将其发送到适当的特征提供方。在一些实现中，下载请求包括针对已经请求访问的所请求的特征文件的标识，但未明确指示来自该批特征文件的其他特征文件。即，下载请求可以限于(多个)所请求的特征文件。继续上面的具体示例，在接收到访问“feature_name.exe”文件的请求时，同步引擎可以仅生成针对该特定请求的特征文件的下载请求，然后将该下载请求传输到适当特征提供方。

在本实现的服务器侧，在接收到下载请求时，特征提供方可以标识所请求的特征文件所属的整个预定义的、一批特征文件。然后，不是仅仅返回所请求的特征文件，而是特征提供方可以返回包括整个预定义、一批特征文件的下载包。例如，如果下载请求标识“feature_name.exe”文件，则特征提供方不仅可以取回“feature_name.exe”文件，还可以取回“feature_name.dll”文件和/或针对当前在计算设备上被脱水的特征的有效载荷的任何部分。在标识整个预定义、一批特征文件之后，特征提供方可以通过向计算设备提供包括来自整个预定义、一批特征文件的所有特征文件的下载包来响应于下载请求。

回到该实现的客户端侧，计算设备接收包括来自整个预定义、一批特征文件的所有特征文件的下载包。然后，计算设备读取下载包以将所包括的特征文件中的每个特征文件写入存储介质(例如，硬盘、固态硬盘或任何其他合适的易失性或非易失性存储介质)上，以便将这些特征文件从脱水状态转换为水合状态。因此，基于请求仅访问特征的单个特征文件(例如，“feature_name.exe”文件)的初始请求，计算设备和特征提供方一起工作以通过将针对特征的整个有效载荷写入本地存储介质来完全水合整批特征文件(甚至那些尚未请求的)。然后，一旦整批特征文件被完全水合(或当该批特征文件被主动水合时)，计算设备通过使用其最近下载的有效载荷来供应对所请求的特征文件的访问来服务于请求。

通过阅读以下详细描述和检查相关附图，这些和各种其他特征将是很清楚的。提供本“发明内容”以便以简化的形式介绍在下面的“具体实施方式”中进一步描述的概念的选择。本“发明内容”不旨在标识要求保护的主题的关键特征或基本特征，也不旨在将本“发明内容”用于限制所要求保护的主题的范围。此外，所要求保护的主题不限于解决在本公开的任何部分中指出的任何或所有缺点的实现。

附图说明

参考附图描述“具体实施方式”。在图中，附图标记的(多个)最左边的数字表示附图标记第一次出现的图。不同图中相同的附图标记表示相似或相同的项。对多个项中的单个项进行的引用可以使用具有括号内的另一数字(和/或不具有括号的字母)的附图标记来引用每个单个项。对项的一般引用可以使用特定引用编号，而不是字母顺序。

图1示出了示例性系统，该系统用于使计算设备能够在本地驱动器上以脱水状态存储预定多批特征文件，同时在计算设备处保留预定多批特征文件的按需可访问性。

图2A示出了示例性数据流场景，其中计算设备对当前以处于脱水状态存储在本地驱动器上的所请求的特征文件执行打开请求。

图2B示出了示例性数据流场景，其中计算设备通过向适当的特征提供方传输下载请求来响应于读取和/或写入请求。

图2C示出了示例性数据流场景，其中计算设备在下载和水合所请求的特征文件之后响应于图2B的读取和/或写入请求。

图3是用于在计算设备处由软件组件调用时、将个体特征文件或多批特征文件动态水合到计算设备的本地驱动器上的示例方法的流程图。

图4是监测与个体特征文件或多批特征文件相关联的属性，以在自动脱水参数被满足时动态脱水个体特征文件或多批特征文件的流程图。

图5是用于基于从发送下载请求的计算设备的状态来生成过度包括(overinclusive)下载请求的下载包的流程图。

具体实施方式

下面的“具体实施方式”描述了使计算设备能够通过预先将针对预定多批特征文件的有效载荷写入本地存储并且然后在相关联的特征被调用时自动下载针对个体多批特征文件的有效载荷来节省存储空间的技术。一般而言，计算设备最初可以被配置具有处于水合状态的一些多批特征文件和处于脱水状态的其他多批特征文件。作为特定示例，在计算设备上运行的操作系统(OS)可以包括一些频繁被使用的特征和很少被使用的其他特征。为了节省存储空间，可以对各种特征的相对使用频率进行加权，作为用于选择一些多批特征文件用于以水合状态存储在计算设备上以及选择其他多批特征文件以保持脱水状态的因素。例如，启用频繁使用特征的实现的多批特征文件可以被完全水合，而启用很少使用特征的实现的其他多批特征文件可以保持脱水。然后，当接收到请求访问个体脱水特征文件的请求时，计算设备可以从适当特征提供方自动取回与该脱水特征文件相关联的一批特定特征文件。在从适当特征提供方接收到特定一批特征文件后，计算设备可以通过提供对现在被水合但是在最初接收到请求时之前被脱水的特征的完全访问来满足请求。以这种方式，预定多批特征文件保持在计算设备处立即可访问，而不会永久消耗计算设备上的大量存储空间。即，这种预定多批特征文件仅在请求中实际被调用时消耗大量存储空间——否则仅作为不占用大量存储空间的元数据而被存储。

如本文中使用的，术语“水合”在被用于描述个体特征文件的状态时指示该个体特征文件的有效载荷被本地存储在计算设备上。相反，术语“脱水”在被用于描述个体特征文件的状态时指示该个体特征文件的有效载荷没有被本地存储在计算设备上。如下文更详细描述的，在一些实施例中，占位符文件被个体地存储以用于脱水特征文件以代替这些特征文件的完整版本(即，有效载荷和所有)。示例性的这样的占位符文件可以包括元数据，该元数据指示可以容易地从其获取对应特征文件的特征提供方和/或可以容易地从其获取对应特征文件的地址。元数据还可以指示与所请求的特征文件相关联的有效载荷当前是否被写入本地驱动器。

如本文中使用的，术语“特征”是指可以由计算设备通过使用一个或多个个体特征文件和/或多批特征文件来执行的特定计算功能。针对个体多批特征文件的有效载荷可以被下载和写入计算设备的本地存储，以使该计算设备能够支持附加特征，诸如例如附加硬件用例或附加软件用例。作为特定示例，计算设备可以配备有适合于执行面部识别技术的相机，并且一批特征文件可以包括使计算设备能够经由相机来实现这种技术的软件代码。因此，一批特征文件可以包括可用于实现期望功能的驱动程序和/或任何其他合适类型的计算机可读指令。示例性特征包括但不限于经由可以能够在微软WINDOWS 10操作系统上使用的按需特征(通常称为“FOD”)从计算设备添加或删除的各种计算功能。

如本文中使用的，术语“特征文件”是指个体地和/或与一个或多个其他计算文件结合可使用以使功能性计算设备(例如，执行典型操作系统的通用计算机)能够实现本文中所限定的“特征”的任何计算文件。例如，使通用计算机能够执行面部识别特征的一组计算文件或一批计算文件中的个体计算文件可以恰当地称为特征文件。

现在转向图1，示出了示例性系统100，系统100用于使计算设备106能够在本地驱动器124上以脱水状态存储预定多批特征文件，同时在计算设备106处保留预定多批特征文件的按需可访问性。在所示示例中，与标题为“Feature_Name1”的特征相对应的第一批特征文件以水合状态存储，使得该第一批内的每个个体特征文件的有效载荷被存储在计算设备106的本地驱动器124上。个体特征文件的相应有效载荷可以包括例如二进制文件、权限、注册表设置和可用于实现特定特征的其他数据。同样，在所示示例中，与标题为“Feature_Name2”的特征相对应的第二批特征文件以脱水状态被存储，使得占位符文件被存储以代替该批特征文件的实际特征文件。在一些实施例中，占位符文件被存储在计算设备106的本地目录126内，其存储路径与实际特征文件在被水合(例如，其中有效载荷被写入本地存储)到计算设备106上时将被存储的路径相同。以这种方式，导致在特定文件路径处调用实际特征文件的用户与计算设备106的交互将打开实际特征文件(如果存在)或相应占位符(如果被调用的特征文件没有被水合到计算设备106上)。占位符文件不包括相关联的实际特征文件的有效载荷，而是包括指示对应实际特征文件(例如，具有对应有效载荷的完整特征文件)的属性的元数据。与任何特定特征文件相关联的元数据可以指示特征提供方，可以从该特征提供方获取包括对应有效载荷的特定特征文件。如下文更详细描述的，当特定一批特征文件处于脱水状态时，当与来自该批特征文件中的占位符文件相关联的单个特征文件被请求时，计算设备106可以使用来自该特定批中的占位符文件的元数据来按需取回针对该特定批的所有实际特征文件。

为了充分传达本文中所描述的概念和技术优点，针对实际特征文件的相应有效载荷和针对占位符文件的元数据来规定数据大小可能是有益的。因此，如所图示的，第二批文件包括被名为“Feature_Name2.exe”和“Feature_Name2.dll”的两个实际特征文件，具有有效载荷分别为91MB和15MB(示出在特征提供方102(1)的云数据层中)。如进一步所示，与这两个实际文件相对应的两个占位符文件各自仅为1KB(示出在本地驱动器124上的本地数据层中)。因此，在这些特定但非限制性的情况下，与以水合状态被存储时的106MB本地存储空间相比，第二批特征文件在以脱水状态被存储时将仅消耗2KB的本地存储空间。

如图所示，计算设备106可以包括被安装在本地驱动器124上的操作系统(OS)108。为了促进计算设备106的操作，可用于实现OS 108的各种“核心”和/或频繁使用特征的至少一些多批特征文件可以在计算设备106上完全水合。为了减少计算设备106上消耗的存储空间的总量，可用于实现OS 108的其他特征的至少一些多批其他特征文件在计算设备106上保持脱水，除非如下所述调用。OS 108可以是用于管理计算机硬件和/或软件资源以及用于向各种(多个)应用110提供服务的任何合适的系统软件。示例性OS 108可以包括但不限于各种版本的微软WINDOWS(例如，WINDOWS 8.1或10、WINDOWS嵌入式标准7等)和/或各种版本的macOS(例如，macOS SIERRA、macOS X等)和/或各种版本的谷歌浏览器OS。

计算设备106还可以包括安装在本地驱动器124上的应用110。在一些实施例中，可用于实现应用110的各种特征的至少一些多批特征文件可以以脱水状态被存储在本地驱动器124上。特别地，应当理解，本文中所描述的技术可用于减少OS 108和/或应用110的软件占用空间。软件占用空间的这种减少是通过选择性地存储可用于以脱水状态实现OS 108和/或应用110的选择特征的个体多批特征文件来实现的。根据本文中所描述的技术来配置计算设备106使用户和/或软件组件能够发出针对脱水特征文件的请求(例如，调用)并且使这些请求得到服务，就像脱水特征文件在生成请求时完全被水合一样。这是通过在接收到请求时立即将所请求的特征文件进行自动水合(以及在一些实施例中的其他通常成批的特征文件)来实现的。然后，在对所请求的特征文件进行水合的这个中间步骤之后，计算设备106然后可以通过供应对新水合的特征文件的有效载荷的访问来响应于请求。即，计算设备106在有效载荷本地不可获得时接收请求并且稍微延迟对请求的响应，直到在将有效载荷下载和/或写入本地驱动器124之后。

在一些实现中，计算设备106可以利用同步引擎112用于在发出寻求访问当前在计算设备106上脱水的特征文件的请求时取回下载包。例如，当OS 108接收到标识当前脱水的特定特征文件的请求时，OS 108可以取回存储在针对特定特征文件的占位符文件中的元数据。OS 108然后可以向同步引擎112提供元数据以使下载请求128被传输到与特定特征文件相关联的特征提供方102(1)。如上所述，存储在占位符文件中的元数据可以包括可以从其获取所请求的特征文件的特征提供方(众多潜在的特征提供方)的标识。如本文中使用的，术语“元数据”具体指的是提供关于对应特征文件的信息并且更具体地关于计算设备106如何获取与对应特征文件相关联的有效载荷的信息的数据集。在一些实施例中，元数据还可以指示所请求的特征文件的有效载荷当前是否被写入计算设备的本地驱动器。换而言之，元数据可以包括特定所请求的特征文件当前是否在计算设备处被水合的指示。

下载请求128可以包括已经被请求访问的所请求的特征文件的标识。在一些实例中，下载请求128可以省略其他特征文件的任何特定标识——诸如通常与所请求的特征文件一起被批处理的那些特征文件。例如，可以基于用户输入运行命令以通过访问相关联的可执行文件(例如，“.exe”)来启动当前脱水的特征和/或应用来生成请求。在这个示例中，运行命令可以专门引用名为“Feature_Name2.exe”的文件，而不引用名为“Feature_Name2.dll”的相关文件。因此，该运行命令可以使OS 108生成访问名为“Feature_Name2.exe”的文件的请求。响应于该请求，同步引擎112可以仅针对该特定请求的特征文件生成下载请求128，但是不请求名为“Feature_Name2.dll”的相关文件——即使这些文件通常是批处理的。同步引擎112可能无法标识下载请求128中的所有这些共同批处理的特征文件的一个原因是，计算设备106的各种组件可能缺乏关于哪些文件被一起批处理的可见性。例如，OS 106可以被设计为简单地在逐文件的基础上满足请求，并且所请求的特征文件可以省略关于与它们可以具有的其他文件的任何关系的指示。示例性同步引擎112包括但不限于由DROPBOX开发的同步API、由谷歌开发的备份和同步、以及用于’微软WINDOWS 10的ONEDRIVE通用WINDOWS平台(UWP)APP。因此，可以理解，同步引擎112可以是OS 108的本机组件，或者可以是与OS 108分开下载并且被安装到客户端设备106上的附加组件。

在接收到下载请求128时，第一特征提供方102(1)可以标识所请求的特征文件所属的完整预定义的、一批特征文件。例如，如图所示，第一特征提供方102(1)可以确定所请求的特征文件(例如，名为“Feature_Name2.exe”的文件)属于名为“File Batch：Feature_Name2”的一批特征文件。然后，不是仅仅返回所请求的特征文件，而是第一特征提供方102(1)可以返回包括全部标识的一批特征文件的下载包130。因此，在所图示的示例中，响应于下载请求128标识名为“Feature_Name2.exe”的单个文件，第一特征提供方102(1)返回所请求的“Feature_Name2.exe”文件和“Feature_Name2.dll”文件两者、以及通常被批处理的任何其他特征文件。在一些实施例中，第一特征提供方102(1)可以以压缩存档文件的形式返回下载包130以提高整批特征文件在计算设备106上变得水合的速度。由于虽然实现期望特征，但是计算设备106可能会请求访问该批特征文件中的其他特征文件，所以将下载包130作为压缩存档文件夹来递送也减少了原本在计算设备106请求时个体地递送每个特征文件将消耗的总网络带宽。

在接收到下载包130时，计算设备106可以将个体特征文件中的每个个体特征文件写入本地驱动器124(例如，硬盘、固态硬盘驱动器或任何其他合适的易失性或非易失性存储介质)上，以便将个体特征文件从脱水状态转换为水合状态。在一些实施例中，一旦整批特征文件被完全水合(或当该批特征文件被主动水合时)，计算设备106通过使用其新下载的有效载荷来供应对所请求的特征文件的访问来服务于请求。备选地，计算设备106可以通过甚至在有效载荷被写入本地驱动器124之前供应对所请求的特征文件的新下载的有效载荷的访问来服务于请求。例如，可以通过将有效载荷从下载包直接加载到计算设备106的存储器或高速缓存中来服务于请求。

在一些实现中，计算设备106还包括更新服务114，更新服务114被配置为自动更新各种组件，诸如例如OS108和/或应用110。例如，在OS 108和/或应用110的新版本变得从对应提供方处可获得时，更新服务114可以下载安装文件(例如，具有“.cab”扩展名的压缩文件)，然后在适当调度的时间(例如，在非高峰使用期间)安装已经下载的安装文件。在一些实施例中，更新服务114还被配置为当对脱水特征的更新变得从特征提供方102可获得时，自动更新与特定脱水特征相对应的元数据。例如，更新服务114可以周期性地针对当前在计算设备106上脱水的各种特征与(多个)特征提供方102通信，以确定特征文件的(多个)新版本何时变得可获得。然后，当特征文件的(多个)新版本变得可可获得时，更新服务114可以更新存储在针对特征文件的占位符中的元数据，使得“所更新的”元数据现在指示如何获取所更新的特征文件及其所更新的有效载荷。例如，元数据可以是未注明日期的，使得元数据中指示在哪里下载特征文件的先前版本的先前地址被新地址覆盖，该新地址指示在哪里下载特征文件的新版本。

如进一步所示，计算设备106包括中央处理单元(“CPU”)116，CPU 116经由总线(图1中未示出)连接到各种组件，诸如本地驱动器124、存储器118、输入/输出(I/O)控制器120和/或网络接口122。可以理解，本文中所描述的系统组件(例如，(多个)应用110、OS 108和/或同步引擎112)可以在加载到CPU 116中并且被执行时将CPU 116和整个计算设备106从通用计算系统转换成专用计算系统，该专用计算系统被定制以促进本文中呈现的功能。CPU116可以由任何数目的晶体管或其他分立电路元件构成，该晶体管或其他分立电路元件可以个体或共同地呈现任何数目的状态。更具体地，CPU 116可以响应于本文中所公开的软件模块内包含的可执行指令而作为有限状态机来操作。这些计算机可执行指令可以通过指定CPU 116如何在状态之间转变来转换CPU 116，从而转换构成CPU 116的晶体管或其他分立硬件元件。

本地驱动器124和相关联的计算机可读介质针对计算设备106提供非易失性存储。虽然本文中包含的计算机可读介质的描述指的是大容量存储设备，诸如固态驱动器和/或硬盘，但是本领域技术人员应当理解，计算机可读介质可以是可以由诸如例如系统100的计算架构访问的任何可用的计算机存储介质或通信介质。通信介质包括计算机可读指令、数据结构、程序模块、和/或诸如载波或其他传输机制等调制数据信号中的其他数据，并且包括任何递送介质。术语“调制数据信号”是指其特性中的一个或多个特性以某种方式改变或设置以便在信号中对信息进行编码的信号。作为示例而非限制，通信介质包括诸如有线网络或直接有线连接等有线介质、以及诸如声学、RF、红外线和其他无线介质的无线介质。任何上述各项的组合也被包括在计算机可读介质的范围内。

作为示例而非限制，计算机存储介质可以包括以任何方法或技术实现的用于存储诸如计算机可读指令、数据结构、程序模块或其他数据等信息的易失性和非易失性的可移动和不可移动介质。例如，计算机存储介质包括但不限于RAM、ROM、EPROM、EEPROM、闪存或其他固态存储技术、CD-ROM、数字多功能磁盘(“DVD”)、HD-DVD、BLU-RAY、或其他光存储、盒式磁带、磁带、磁盘存储或其他磁存储设备、或者可以用于存储期望信息并且可以由计算设备106访问的任何其他介质。出于权利要求的目的，短语“计算机存储介质”、“计算机可读存储介质”及其变体本身不包括波、信号和/或其他暂态和/或无形的通信介质。

I/O控制器120可以接收和处理来自多个其他设备的输入，包括键盘、鼠标或电子笔(图1中未示出)。类似地，I/O控制器120可以向显示屏(例如，用于显示本文中所描述的文件浏览器GUI)、打印机或其他类型的输出设备(也在图1中未示出)提供输出。网络接口122可以使得计算设备106能够连接到一个或多个网络104，诸如局域网(LAN)、广域网(WAN)、无线局域网(WLAN)、或用于在计算设备106与(多个)特征提供方102之间传递信息的任何其他合适的网络。

现在转向图2A，示出了示例性数据流场景200，其中计算设备106执行打开请求208，当前以脱水状态存储在本地驱动器124上的所请求的特征。如图所示，计算设备106可以接收基于用户220与输入设备218(例如，键盘、鼠标、触摸屏、麦克风或任何其他合适的输入组件)交互而生成的用户活动216。用户220可以经由输入设备218来执行用户活动216，以请求访问OS 108的各种特征204——不管这些特征当前是否在计算设备106上被水合。如图所示，OS 108包括可用于访问第一特征204(1)至第N特征204(N)中的每个特征的特征接口202。在各种实施例中，特征接口202可以表示可用于调用子例程集的一个或多个应用程序编程接口(API)，该子例程集可用于实现OS 108的期望功能。

在各种实施例中，特征接口202可以由计算设备106以一致的方式针对个体特征204向用户220表示(例如，以图形方式显示)，而不管这些个体特征当前是否在计算设备106上被水合。例如，特征接口202中的一个特定特征接口可以被设计为向用户220展示按钮，该按钮可选择以使计算设备106实现特定功能(例如，将消息主体从当前方言翻译成期望方言)。即使当执行特定功能的底层特征204在计算设备106上脱水时，特征接口202也可以使该按钮被暴露给用户220。即，该按钮被暴露给用户220和/或由用户220可选择，即使实际使计算设备106能够执行特定功能的特征文件206的有效载荷不存在于本地驱动器124中。

为了图2A的目的，计算设备106的状态使得特征接口202暴露第一特征204(1)、第二特征204(2)和第N特征204(N)的表示。计算设备106的状态还被实现为使得第一特征204(1)和第N特征204(N)在计算设备106上完全水合。例如，如图所示，启用第一特征204(1)和第N特征204(N)的实现的多个特征文件206被示出为被写入(多个)本地驱动器124。具体地，名为“Feature_Name1.exe”、“Feature_NameN.exe”、“Feature_Name1.dll”和“Feature_NameN.dll”的特征文件中的每个特征文件被示出为将它们的有效载荷完全写入本地驱动器124。特征文件206中的个体特征文件206可以包括各种属性，诸如文件名、文件路径、有效载荷大小、元数据大小和/或自动脱水参数。出于本讨论的目的，在从标记为206的黑色特征文件框向下延伸的表格中针对这些属性中的每个属性规定了值。这些值仅用于传达本公开的各方面，而不旨在以任何方式进行限制。

在所示示例中，第一特征204(1)的水合状态导致消耗33MB的存储空间来存储名为“Feature_Name1.exe”的特征文件，并且还消耗附加的12MB存储空间来存储名为“Feature_Name1.dll”的特征文件。如进一步所示，消耗一些附加的41MB的存储以保持第N特征204(N)的水合状态。与第一特征和第N特征相反，第二特征204(2)在图2A所示的计算设备106的状态下被脱水。即，唯一对应于第二特征204(2)的个体特征文件206被示为处于脱水状态，使得这些特征文件的有效载荷没有被本地存储在(多个)本地驱动器124上。因此，如图所示，即使使用一批两个特征文件来实现第二特征204(2)，这两个特征文件一起需要分配106MB的本地驱动器空间才能在计算设备106上完全水合，但是这些特征文件以脱水状态被本地存储，这省略了实际有效载荷，但是包括元数据，元数据具有在请求时可用于获取有效载荷的信息。这些脱水特征文件可以用作水合特征文件(例如，包括有效载荷)的占位符，并且元数据可以指示可以容易地从其获取对应水合特征文件的特征提供方和/或可以容易地从其获取对应水合特征文件的地址。在所示实施例中，完全水合的特征文件由特征提供方102存储为唯一对应于第二特征204(2)的文件批的部分。

关于图2A所示的特定数据流场景200，与特征接口202相关联地接收的用户活动216导致计算设备106的各种组件与特征提供方102之间的一系列交互。例如，如图所示，用户活动216导致打开请求208从OS 108被传输到过滤驱动程序209。为了本讨论的目的，假定打开请求208正在请求与名为“Feature_Name2.exe”的特征文件相关联的数据。过滤驱动程序209可以是文件系统驱动程序，诸如例如通常与微软的OneDrive一起部署的“cldflt.sys”驱动程序。如上所述，特征文件206包括完全水合的特征文件和脱水的特征文件(例如，占位符文件)两者。过滤驱动程序209协助处理访问存储在本地驱动器124中的各种特征文件的请求。例如，如图所示，当用户执行导致生成与特定特征文件相关联的打开请求208的某种计算动作时，过滤驱动程序209将打开请求208传递到本地驱动器124。在一些实施例中，打开请求208可以包括标记与所请求的文件相关联的元数据212的一个或多个字段的重解析点。重解析点可以向过滤驱动程序212通知元数据的哪个字段指示所请求的特征文件的水合状态。例如，过滤驱动程序209可以基于打开请求208向本地驱动器124查询与所请求的特征文件相关联的数据。如果针对所请求的特征文件的有效载荷被本地存储在本地驱动器124上，则过滤驱动程序209可以简单地照常服务于打开请求208。相反，如果过滤驱动程序209查询本地驱动器124并且确定所请求的特征文件被脱水使得有效载荷无法从本地驱动器124可获得，则过滤驱动程序209可以获取与脱水文件相关联地被存储的元数据212并且将该元数据212存储在高速缓存210中。

现在转向图2B，示出了示例性数据流场景225，其中计算设备通过将下载请求128传输到适当特征提供方来响应于有效载荷访问请求211。如图所示，在过滤驱动程序209已经响应于打开请求208而高速缓存元数据212之后，OS 108然后将有效载荷访问请求传输到过滤驱动程序209。示例性有效载荷访问请求211可以是与所请求的特征文件相关联的读取请求(例如，OS可以请求读取针对所请求的特征文件的有效载荷的某个部分)。作为另一示例，有效载荷访问请求211可以是与所请求的特征文件相关联的写入请求(例如，OS可以请求将数据写入针对所请求的特征文件的有效载荷的某个部分)。

响应于有效载荷访问请求211，同步引擎112然后可以基于元数据212来生成下载请求128。在一些实施例中，元数据212可以包括可以从其获取所请求的特征文件的地址。附加地或备选地，元数据212可以指示可以从其获取所请求的特征文件的适当特征提供方。例如，如上所述，请求208正在请求访问名为“Feature_Name2.exe”的特征文件。因此，下载请求128可以包括图2A所示的特定特征提供方102的标识符，因为该特定特征提供方102可以提供对标题为“Feature_Name2”的文件批213的访问。在一些实施例中，响应于在导致元数据212的高速缓存的初始打开请求208之后接收的第一有效载荷访问请求211，下载请求128被传输到特征提供方102。应当理解，这样的实施例可以减少不必要的网络业务，因为在各种情况下，可以接收打开请求208，该打开请求208仅请求与文件属性相关联的数据，而没有发出对实际访问有效载荷的任何后续请求。因此，一些实施例可以在接收到对应打开请求时避免对特征文件进行水合，而是等待直到接收到有效载荷访问请求。

现在转向图2C，示出了示例性数据流场景250，其中计算设备106在通过获取对应有效载荷并且将其写入本地驱动器124而中间下载并且水合所请求的特征文件之后来响应于图2B的有效载荷访问请求211。如图所示，计算设备106从特征提供方102接收下载包130。响应于下载请求128，下载包130被提供。此外，下载包130可以包括所请求的特征文件所属的整批文件。例如，在本示例中，假定下载请求128将“Feature_Name2.exe”标识为在请求208中立即被请求的特定文件。在这些情况下，特征提供方102可以将名为“Feature_Name2.exe”的文件标识为标题为“Feature_Name2”的文件批213的部分。然后，不是仅仅返回所请求的特征文件，特征提供方102可以返回下载包130内的整个文件批213。在当前情况下，由于下载请求128标识“Feature_Name2.exe”文件，则特征提供方102不仅可以取回“Feature_Name2.exe”文件，而且可以取回“Feature_Name2.dll”文件和/或针对当前在计算设备上脱水的第二特征204(2)的有效载荷的任何部分。然后，特征提供方102通过提供包括来自整个预定义、一批特征文件206的所有特征文件的下载包130来响应于针对单个文件的下载请求128。在所示实施例中，下载包130包括第1至第N有效载荷252。

在接收到下载包130时，同步引擎112将文件批213内的针对个体特征文件的有效载荷写入本地驱动器124。例如，计算设备106和/或同步引擎112可以解压缩下载包130并且将所包括的特征文件中的每个特征文件写入本地驱动器124(例如，硬盘、固态硬盘驱动器或任何其他合适的易失性或非易失性存储介质)上，以便将这些特征文件从脱水状态转换到水合状态。因此，基于请求仅访问文件批213的单个特征文件(例如，“Feature_Name2.exe”文件)的初始请求208，诸如过滤驱动程序209、同步引擎112和特征提供方102的各种系统组件一起工作以通过下载并且然后本地存储它们的所有对应有效载荷来完全水合整批特征文件(甚至那些还没有被请求的特征文件)。然后，一旦整个特征文件批213被完全水合(或当该批特征文件被主动水合时)，计算设备106通过向OS提供响应254来服务于请求208——其中响应254提供对新下载到计算设备并且被写入其本地驱动器124的有效载荷252的访问。

在一些实施例中，针对所请求的特征文件的整个有效载荷可以响应于任何有效载荷访问请求的初始接收而被完全水合。以这种方式，只要针对特定特征文件请求有效载荷的任何部分，整个有效载荷就变得完全水合并且从本地驱动器可获得。在其他实施例中，针对所请求的特征文件的有效载荷的特定部分可以随着接收到大量增加的有效载荷访问请求而逐渐地被水合到本地驱动器上。例如，可以接收请求访问针对所请求的特征文件的有效载荷的特定部分的第一有效载荷访问请求。该第一有效载荷访问请求可以触发接近所请求的部分的有效载荷的一个或多个其他部分的水合。例如，如果所请求的特征文件是地图文件，该地图文件限定了三维第一人称视角视频游戏的地图中的各个房间，则针对限定特定房间的有效载荷的部分的有效载荷访问请求可以触发限定相邻房间的有效载荷的其他部分的水合。以这种方式，如果玩家从特定房间走到任何其他相邻房间，则绘制相应相邻房间所需要的数据被完全水合并且准备好从本地驱动器使用。

如图2A至图2B所示，在一些实施例中，即使对于完全水合的特征文件，可用于标识和联系可以从其获取个体特征文件206的适当特征提供方102的元数据212也被存储在本地驱动器124上。以这种方式，可以简单地通过从本地驱动器124中删除相关联的有效载荷来将个体特征文件206从水合状态转换为脱水状态。以这种方式，脱水个体特征文件不需要计算设备106与特征提供方102通信来获取和存储元数据212。相反，在一些实施例中，元数据212可以永久被存储在计算设备106上，使得在有效载荷252被破坏或删除(无意或有意)的情况下，计算设备106保留使过滤驱动程序209和同步引擎112一起工作以获取和完全水合任何期望特征文件206的能力。

在一些实施例中，特征文件206中的个体特征文件206包括指示一个或多个条件的自动脱水参数，在该条件下计算设备106将从针对任何特定特征文件206的有效载荷252中解除分配本地驱动器124的存储容量。在一些实例中，针对有效载荷252解除分配存储容量可以包括：从本地驱动器124实际删除有效载荷。在一些实例中，针对有效载荷252解除存储容量可以包括：允许计算设备106覆盖当前用于存储有效载荷252的存储容量。如图所示，例如，特征文件206可以与限制个体文件被脱水的自动脱水参数相关联，备选地，设置不活动时间段，在该不活动时间段之后，个体文件将被脱水。例如，与第一特征204(1)相关联的特征文件206具有限制这些特征文件206被脱水的自动脱水参数“否”。这样的参数可以适用于将在计算设备106上永久保持水合的“核心”OS特征或其任何其他特征或其特征文件。作为另一示例，与第二特征204(2)和第N特征204(N)相关联的特征文件206各自具有对应的自动脱水参数，该参数设置不活动时间段，在该不活动时间段之后，这些特征文件将在计算设备106上被脱水。在图2A至图2B所示的特定但非限制性示例中，标题为“Feature_Name2.exe”的特征文件在5天没有被访问的情况下将被自动脱水。这样的参数可以适用于与很少使用特征相对应的特征文件，使得这些特征文件在被调用时被自动水合并且然后如果在针对规定时间段内(例如，在本示例中为5天)未使用则被自动脱水。

图3是用于在计算设备处由软件组件调用时、将个体特征文件或多批特征文件动态水合到计算设备的本地驱动器上的示例方法300的流程图。本领域普通技术人员应当理解，本文中公开的方法的操作不必然以任何特定顺序呈现，并且以(多个)备选顺序执行一些或所有操作是可能的并且是被考虑的。为便于描述和说明，已经按演示顺序呈现了这些操作。在不脱离所附权利要求的范围的情况下，可以添加、省略、一起执行和/或同时执行操作。

在框301处，示例方法300开始。

在框303处，系统(例如，计算设备106)接收访问可用于实现软件组件的特征的特征文件的请求。例如，如关于图1至图2B所述，操作系统(OS)108可以在计算设备106上执行以管理计算机硬件和/或软件资源。OS 108还可以向在计算设备106上安装和/或执行的各种应用110提供服务。在一些实施例中，可以与OS 108和/或应用110的特征接口202相关联地生成请求。特征接口202可以由计算设备106以一致的方式针对个体特征204向用户220表示(例如，显示)，而不管这些个体特征当前是否在计算设备106上被水合。例如，特征接口202中的特定特征接口可以被设计为向用户220展示按钮，该按钮可选择以使计算设备106实现特定功能(例如，将消息主体翻译成期望方言)——即使当执行特定功能的底层特征204在计算设备106上被脱水时。即，该按钮被暴露给用户220和/或由用户220可选择，即使实际使计算设备106能够执行特定功能的特征文件206的有效载荷不存在于本地驱动器124中。

在框305处，系统可以确定所请求的特征文件当前是否被水合到计算设备106的本地驱动器124上。例如，如上所述，在接收到针对特定特征文件的请求208时，系统(或其组件)可以对本地驱动器124上的特定特征文件执行水合检查210。作为特定但非限制性示例，计算设备106上的过滤驱动程序209可以向本地驱动器124查询所请求的特征文件并且确定对应有效载荷是否可获得。

如果系统确定所请求的特征文件被水合到计算设备106上，则示例性方法300可以进行到框307，在框307处，系统通过供应对所请求的特征文件的有效载荷的访问来服务于请求。例如，如图2B所示，过滤驱动程序209可以利用响应254来响应于请求208，响应254包括特征文件的任何请求的有效载荷。应当理解，由于有效载荷已经存在于计算设备106上，因此可以立即服务于请求，而无需对所请求的特征文件进行水合的中间步骤。一旦请求被服务，示例方法300在框309处结束。

相反，如果系统确定所请求的特征文件没有被水合到计算设备106上，则示例性方法300可以从框305进行到框311，在框311处，从本地驱动器124中取回与所请求的特征文件相关联的元数据。如上所述，元数据212可以包括可以从其获取所请求的特征文件的地址和/或可以从其获取所请求的特征文件的适当特征提供方102的指示。

在框313处，系统可以将下载请求128传输到与元数据212相对应的特征提供方102。例如，系统可以部署同步引擎112以基于元数据来生成下载请求。同步引擎112可以将下载请求传输到特征提供方以获取所请求的特征文件和/或所请求的特征文件所属的整批特征文件。

在框315处，系统从特征提供方102接收下载包130。下载包130至少包括与所请求的特征文件相对应的有效载荷。在一些实施例中，下载包130仅包括在框303处请求的特征文件的有效载荷。在一些实施例中，下载包130包括整批特征文件——其中至少一些特征文件在框303处未被请求.

在框317处，系统通过将在框303处所请求的针对该特定特征文件的有效载荷写入本地驱动器124来至少对该特定特征文件进行水合。在一些实施例中，下载包130包括针对所请求的特征文件所属的整批特征文件的有效载荷。然后，在对下载请求中所提供的至少所请求的特征文件(和任何其他特征文件)进行水合之后，示例性方法300从框317进行到框307，在框307处，系统通过供应对所请求的特征文件的有效载荷的访问来服务于请求——自从在框303处最初接收到请求以来，该所请求的特征文件已经被水合到计算设备上。例如，如图2B所示，过滤驱动程序209可以利用响应254来响应于请求208，响应254包括特征文件的任何所请求的有效载荷。一旦请求被服务，示例方法300在框309处结束。

现在转向图4，示出了用于监测与个体特征文件或多批特征文件相关联的属性，以在自动脱水参数被满足时动态脱水个体特征文件或多批特征文件的流程图400。

在框401处，示例方法400开始。

在框403处，系统(例如，计算设备106)标识具有被写入本地驱动器的有效载荷的多个多批特征文件。由于有效载荷被存储在本地，多个多批特征文件可能会占用本地驱动器上的大量存储空间。然而，如上所述，与其他个体多批特征文件相比，使任何个体特征一批文件在设备上保持水合的重要性可能会有所不同。例如，第一批特征文件可能启用操作系统(OS)的常用功能的实现。相比之下，第二批特征文件可能启用OS的很少使用功能的实现。在该示例中，可以理解，与本地存储针对第二批特征文件的(多个)有效载荷的重要性相比，本地存储针对第一批特征文件的(多个)有效载荷的重要性可以相对较高。

在框405处，系统可以确定与多个多批特征文件相关联的自动脱水参数。如上所述，自动脱水参数可以规定不活动时间段，在该不活动时间段之后，个体特征文件或多批特征文件将从计算设备106上的本地驱动器被脱水。例如，与特定特征文件关联地所规定的自动脱水参数5天数可能导致在指定的自动脱水参数满足之后从本地驱动器中删除针对该特定特征文件的有效载荷。

在框407处，系统监测与多个多批特征文件相关联的属性。系统可以监测的示例性属性包括但不限于：指示在计算设备处使用个体特征文件的频率的使用频率属性、指示自个体特征文件被使用以来已经经过的时间段的最后使用属性等。作为特定示例，系统可以监测如在各种版本的微软WINDOWS操作系统中可获得的“已访问”属性。

在框409处，响应于在框407处所监测的针对一批个体特征文件的属性满足自动脱水参数的条件，系统从个体一批特征文件中解除分配存储容量。作为具体示例，如果自动脱水参数规定5天的不活动作为导致特定特征文件或一批特征文件被脱水的条件，则响应于自上次访问特定特征文件以来已经经过5天，系统可以解除分配针对特定特征文件或一批特征文件的存储容量。一旦针对(多个)特征文件的存储容量被脱水，则示例方法400在框411处结束。当然，在方法400完成之后，可以根据本文中所描述的技术按需对(多个)特征文件进行再水合。例如，在方法400完成之后的某个时间，可以发出对(多个)新脱水的特征文件的请求。这样的请求可以触发方法300被执行以再水合(多个)先前脱水的特征文件。

现在转向图5，示出了用于基于从发送下载请求的计算设备的状态来生成过度包括下载请求的下载包的流程图500。换而言之，可以编译响应于特定请求而生成的特定下载包，以使包括比特定请求中所要求的更多的数据(例如，更多的特征文件和/或其有效载荷)。

在框501处，示例方法500开始。

在框503处，系统(例如，特征提供方102)从计算设备接收下载请求。出于本讨论的目的，从计算设备接收的下载请求标识与软件组件(诸如OS 108和/或应用110)的特征相关联的第一特征文件。然而，下载请求没有明确标识也与软件组件的特征相关联的一个或多个第二特征文件。例如，如关于图2A至图2B所述，可以针对单个特征文件(例如，“Feature_Name2.exe”文件)生成初始请求，并且由于本地驱动器中不存在针对该单个特征文件的有效载荷，计算设备106可以利用一个或多个系统组件(例如，过滤驱动程序209和/或同步引擎112)生成下载请求128，该下载请求128特别地请求从特征提供方102提供该单个特征文件。

在框505处，系统可以标识包括在下载请求内所标识的第一特征文件的一批特征文件。除了第一特征文件，所标识的一批特征文件还可以包括一个或多个第二特征文件。此外，第一特征文件和一个或多个第二特征文件都可以与软件组件的特征共同关联。继续上面关于图2A至图2B描述的示例，单个特征文件可以是名为“Feature_Name2.exe”的文件，并且一个或多个第二特征文件可以至少包括文件名“Feature_Name2.dll”——其中可执行(“.exe”)文件格式化的特征文件和动态链接库(“.dll”)格式化的特征文件可相互结合使用以实现OS和/或应用的期望特征。

在框507处，系统可以生成下载包，该下载包至少包括第一特征文件(其在下载请求内被具体标识)并且还包括与期望特征相关联的一批特征文件的一个或多个第二特征文件。在一些实施例中，可以至少部分基于在生成下载请求时计算设备的当前状态来生成下载包。例如，在某些情况下，一个或多个个体特征文件通常可以被包括在两个或更多个多批特征文件中。作为特定但非限制性示例，特定特征文件可以用作主动态链接库，该主动态链接库由在某些方面彼此相关的多个不同特征可使用。此外，包括主动态链接库的特定一批特征文件可以被完全地水合到计算设备上，而也包括主动态库链接的某个其他一批特征文件可以在计算设备上被脱水。然后，可以执行导致生成针对属于其他一批特征文件的特定脱水特征文件的请求的某个用户活动。在这些情况下，当接收到与当前在计算设备上被脱水的其他一批特征文件相关联的下载请求时，系统可以检查计算设备的当前状态以确定主动态链接库已经完全水合到计算设备上。然后，基于该确定，系统可以定制所生成的下载包，以排除主动态链接库，尽管它是与期望特征相关联的一批特征文件的组件。

在框509处，系统可以向计算设备传输下载包以启用第一特征文件与一个或多个第二特征文件能够本地水合。例如，系统可以将下载包压缩成合适的压缩格式(例如，具有“.cab”扩展名的压缩文件)，然后将下载包传输到计算设备。一旦下载包已经成功传输到计算设备，示例方法500就在框511处结束。

示例条款

鉴于以下条款，可以考虑本文中提出的公开。

示例条款A，一种用于自动水合多批特征文件的计算设备，包括：本地驱动器；一个或多个处理器；存储器，与一个或多个处理器通信，存储器上存储有计算机可读指令，计算机可读指令在由一个或多个处理器执行时使计算设备：接收访问第一特征文件的请求，第一特征文件可用于实现计算设备上的软件组件的特征；响应于接收到访问第一特征文件的请求，取回元数据，该元数据被写入计算设备的本地驱动器以指示第一特征文件的第一有效载荷是否被写入计算设备的本地驱动器；响应于元数据指示第一特征文件的第一有效载荷未被写入计算设备的本地驱动器，使下载请求被传输到与软件组件的特征相关联的特征提供方，其中软件组件的特征对应于至少包括第一特征文件和第二特征文件的一批特征文件；基于下载请求，从特征提供方接收针对一批特征文件的下载包，其中下载包包括：针对第一特征文件的第一有效载荷和针对第二特征文件的第二有效载荷；以及基于针对一批特征文件的下载包：将针对第一特征文件的第一有效载荷和针对第二特征文件的第二有效载荷写入计算设备的本地驱动器；以及通过供应对第一特征文件的第一有效载荷的访问来服务请求。

示例条款B，根据示例条款A的计算设备，其中计算机可读指令还可执行以使计算设备：响应于访问第一特征文件的请求，确定第一有效载荷是否被写入本地驱动器，其中使下载请求被传输到特征提供方是响应于确定本地驱动器中不存在第一有效载荷。

示例条款C，根据示例条款A至B中任一项所述的计算设备，其中计算机可读指令还可执行以使计算设备：

在请求被服务之后，关于一批特征文件确定一个或多个条件是否被满足；以及

响应于确定一个或多个条件已经被满足，从一批特征文件中解除分配至少一些存储容量。

示例条款D，根据示例条款A至C中任一项所述的计算设备，其中解除分配至少一些存储容量包括以下至少一项：从本地驱动器中删除第一有效载荷或第二有效载荷中的至少一项，或者允许计算设备覆盖本地驱动器上的第一有效载荷或第二有效载荷中的至少一项。

示例条款E，根据示例条款A至D中任一项所述的计算设备，其中请求基于与软件组件的特征接口相关联地被接收的用户活动来生成，并且其中用户活动导致请求被传输到过滤驱动程序，该过滤驱动程序被配置为在计算设备上执行水合检查。

示例条款F，根据示例条款A至E中任一项所述的计算设备，其中元数据指示以下地址，针对第一特征文件的第一有效载荷和针对第二特征文件的第二有效载荷能够从该地址下载。

示例条款G，根据示例条款A至F中任一项所述的计算设备，其中元数据指示与软件组件的特征相关联的特征提供方的标识。

示例条款H，根据示例条款A至G中任一项所述的计算设备，其中软件组件是在计算设备上执行的操作系统。

示例条款I，一种计算机实现的方法，包括：由计算设备接收访问第一有效载荷的请求，第一有效载荷对应于一批特征文件中的第一特征文件，该第一特征文件可用于实现计算设备上的软件组件的特征；取回元数据，该元数据与第一特征文件相关联地被存储在计算设备的存储介质上；响应于请求，向与软件组件的特征相关联的特征提供方传输下载请求，下载请求包括元数据的、用于标识第一特征文件的方面；基于下载请求，接收由特征提供方传输的下载包，下载包包括：与第一特征文件相对应的第一有效载荷和与一批特征文件中的至少一个第二特征文件相对应的至少一个第二有效载荷；以及基于下载包，通过供应对与第一特征文件相对应的第一有效载荷和与第二特征文件相对应的第二有效载荷的访问来服务请求。

示例条款J，根据示例条款I的计算机实现的方法，还包括：基于下载包，将与第一特征文件相对应的第一有效载荷和与至少一个第二特征文件相对应的至少一个第二有效载荷写入计算设备的存储介质。

示例条款K，根据示例条款I至J中任一项所述的计算机实现的方法，还包括：响应于请求，执行水合检查以确定与第一特征文件相对应的第一有效载荷是否从计算设备的存储介质可获得；以及响应于确定存储介质中不存在第一有效载荷，生成下载请求。

示例条款L，根据示例条款I至K中任一项所述的计算机实现的方法，还包括：在通过供应对第一有效载荷的访问来服务请求之后，响应于确定自第一特征文件的上次使用以来已经经过阈值时间段，从第一特征文件中解除分配至少一些存储容量。

示例条款M，根据示例条款I至L中任一项所述的计算机实现的方法，其中从第一特征文件中解除分配至少一些存储容量包括：从计算设备的存储介质中删除第一有效载荷。

示例条款N，根据示例条款I至M中任一项所述的计算机实现的方法，其中元数据指示以下中的至少一项：地址，能够从该地址下载针对第一特征文件的第一有效载荷；或者特征提供方。

示例条款O，根据示例条款I至N中任一项所述的计算机实现的方法，其中下载请求包括第一特征文件的标识并且缺少第二特征文件的标识。

示例条款P，一种系统，包括：一个或多个处理器；存储器，与一个或多个处理器通信，存储器上存储有计算机可读指令，计算机可读指令在由一个或多个处理器执行时使系统：从计算设备接收下载请求，该下载请求标识与软件组件的特征相关联的第一特征文件；基于下载请求，标识与软件组件的特征相关联的一批特征文件，其中一批特征文件包括第一特征文件和一个或多个第二特征文件；生成下载包，下载包至少包括：与第一特征文件相对应的第一有效载荷和与一个或多个第二特征文件相对应的一个或多个第二有效载荷；以及向计算设备传输下载包，以启用软件组件的特征的实现。

示例条款Q，根据示例条款P的系统，其中一批特征文件还包括第三特征文件，并且其中计算机可读指令还由一个或多个处理器可执行，以使系统：基于与第三有效载荷正在被写入计算设备上的本地存储介质相对应的计算设备的状态，来从下载包中省略与第三特征文件相对应的第三有效载荷。

示例条款R，根据示例条款P至Q中任一项所述的系统，其中软件组件是在计算设备上执行的操作系统。

示例条款S，根据示例条款P至R中任一项所述的系统，其中在下载请求中标识的第一特征文件是第一文件格式，并且其中在下载包中所提供的一个或多个第二特征文件根据一个或多个第二文件格式被格式化。

示例条款T，根据示例条款P至S中任一项所述的系统，其中标识第一特征文件的下载请求缺少一个或多个第二特征文件的标识。

结论

最后，虽然已经用特定于结构特征和/或方法动作的语言描述了各种技术，但应当理解，在所附表示中所限定的主题不必然限于所描述的特定特征或动作。相反，具体特征和动作被公开作为实现要求保护的主题的示例形式。

Claims (15)

1.一种用于自动水合多批特征文件的计算设备，包括：

本地驱动器；

一个或多个处理器；

存储器，与所述一个或多个处理器通信，所述存储器上存储有计算机可读指令，所述计算机可读指令在由所述一个或多个处理器执行时使所述计算设备：

接收访问第一特征文件的请求，所述第一特征文件可用于实现所述计算设备上的软件组件的特征；

响应于接收到访问所述第一特征文件的所述请求，取回元数据，所述元数据被写入所述计算设备的所述本地驱动器以指示所述第一特征文件的第一有效载荷是否被写入所述计算设备的所述本地驱动器；

响应于所述元数据指示所述第一特征文件的所述第一有效载荷未被写入所述计算设备的所述本地驱动器，使下载请求被传输到与所述软件组件的所述特征相关联的特征提供方，其中所述软件组件的所述特征对应于至少包括所述第一特征文件和第二特征文件的一批特征文件；

基于所述下载请求，从所述特征提供方接收针对所述一批特征文件的下载包，其中所述下载包包括：针对所述第一特征文件的第一有效载荷和针对所述第二特征文件的第二有效载荷；以及

基于针对所述一批特征文件的所述下载包：

将针对所述第一特征文件的所述第一有效载荷和针对所述第二特征文件的所述第二有效载荷写入所述计算设备的所述本地驱动器；以及

通过供应对所述第一特征文件的所述第一有效载荷的访问来服务所述请求。

2.根据权利要求1所述的计算设备，其中所述计算机可读指令还可执行以使所述计算设备：

响应于访问所述第一特征文件的所述请求，确定所述第一有效载荷是否被写入所述本地驱动器，其中使所述下载请求被传输到所述特征提供方是响应于确定所述本地驱动器中不存在所述第一有效载荷。

3.根据权利要求1所述的计算设备，其中所述计算机可读指令还可执行以使所述计算设备：

在所述请求被服务之后，关于所述一批特征文件确定一个或多个条件是否被满足；以及

响应于确定所述一个或多个条件已经被满足，从所述一批特征文件中解除分配至少一些存储容量。

4.根据权利要求3所述的计算设备，其中解除分配所述至少一些存储容量包括以下至少一项：

从所述本地驱动器中删除所述第一有效载荷或所述第二有效载荷中的至少一项，或者

允许所述计算设备覆盖所述本地驱动器上的所述第一有效载荷或所述第二有效载荷中的至少一项。

5.根据权利要求1所述的计算设备，其中所述请求基于与所述软件组件的特征接口相关联地被接收的用户活动来生成，并且其中所述用户活动导致所述请求被传输到过滤驱动程序，所述过滤驱动程序被配置为在所述计算设备上执行水合检查。

6.根据权利要求1所述的计算设备，其中所述元数据指示以下地址，针对所述第一特征文件的所述第一有效载荷和针对所述第二特征文件的所述第二有效载荷能够从所述地址下载。

7.根据权利要求1所述的计算设备，其中所述元数据指示与所述软件组件的所述特征相关联的所述特征提供方的标识。

8.根据权利要求1所述的计算设备，其中所述软件组件是在所述计算设备上执行的操作系统。

9.一种计算机实现的方法，包括：

由计算设备接收访问第一有效载荷的请求，所述第一有效载荷对应于一批特征文件中的第一特征文件，所述第一特征文件可用于实现所述计算设备上的软件组件的特征；

取回元数据，所述元数据与所述第一特征文件相关联地被存储在所述计算设备的存储介质上；

响应于所述请求，向与所述软件组件的所述特征相关联的特征提供方传输下载请求，所述下载请求包括所述元数据的、用于标识所述第一特征文件的方面；

基于所述下载请求，接收由所述特征提供方传输的下载包，所述下载包包括：与所述第一特征文件相对应的所述第一有效载荷和与所述一批特征文件中的至少一个第二特征文件相对应的至少一个第二有效载荷；以及

基于所述下载包，通过供应对与所述第一特征文件相对应的所述第一有效载荷和与所述第二特征文件相对应的所述第二有效载荷的访问来服务所述请求。

10.根据权利要求9所述的计算机实现的方法，还包括：

基于所述下载包，将与所述第一特征文件相对应的所述第一有效载荷和与所述至少一个第二特征文件相对应的所述至少一个第二有效载荷写入所述计算设备的所述存储介质。

11.根据权利要求9所述的计算机实现的方法，还包括：

响应于所述请求，执行水合检查以确定与所述第一特征文件相对应的所述第一有效载荷是否从所述计算设备的所述存储介质可获得；以及

响应于确定所述存储介质中不存在所述第一有效载荷，生成所述下载请求。

12.根据权利要求9所述的计算机实现的方法，还包括：

在通过供应对所述第一有效载荷的访问来服务所述请求之后，响应于确定自从所述第一特征文件的上次使用以来已经经过阈值时间段，从所述第一特征文件中解除分配至少一些存储容量。

13.根据权利要求12所述的计算机实现的方法，其中从所述第一特征文件中解除分配所述至少一些存储容量包括：从所述计算设备的所述存储介质中删除所述第一有效载荷。

14.一种系统，包括：

一个或多个处理器；

存储器，与所述一个或多个处理器通信，所述存储器上存储有计算机可读指令，所述计算机可读指令在由一个或多个处理器执行时使所述系统：

从计算设备接收下载请求，所述下载请求标识与软件组件的特征相关联的第一特征文件；

基于所述下载请求，标识与所述软件组件的所述特征相关联的一批特征文件，其中所述一批特征文件包括所述第一特征文件和一个或多个第二特征文件；

生成下载包，所述下载包至少包括：与所述第一特征文件相对应的第一有效载荷和与所述一个或多个第二特征文件相对应的一个或多个第二有效载荷；以及

向所述计算设备传输所述下载包，以启用所述软件组件的所述特征的实现。

15.根据权利要求14所述的系统，其中所述一批特征文件还包括第三特征文件，并且其中所述计算机可读指令还由所述一个或多个处理器可执行以使所述系统：基于与第三有效载荷正被写入所述计算设备上的本地存储介质相对应的所述计算设备的状态，来从所述下载包中省略与所述第三特征文件相对应的所述第三有效载荷。

Images