一种文件下载方法、装置、终端、源服务器及介质

技术领域

本发明实施例涉及计算机技术领域，尤其涉及一种文件下载方法、装置、终端、源服务器及介质。

背景技术

移动应用平台MCube的客户端侧容器架构可以划分为引擎层、视图层、事件层以及模板层这四层，其中的模板层是MCube动态化的整体架构的基础，而模板相关的文件下载是整个模板管理板块的核心。

在实现本发明的过程中，发明人发现现有技术中存在以下技术问题：当前采用的文件下载方案的下载成功率不高，有待改进。

发明内容

本发明实施例提供了一种文件下载方法、装置、终端、源服务器及介质，以提升文件下载的成功率。

根据本发明的一方面，提供了一种文件下载方法，可以包括：

获取文件下载请求，将文件下载请求发送给源服务端，并接收源服务端针对文件下载请求返回的下载信息；

基于预先配置的打包下载流程以及下载信息下载文件包，其中，文件包由源服务端对与文件下载请求对应的至少一个文件打包得到；

根据下载得到的文件包得到至少一个文件。

根据本发明的另一方面，提供了一种文件下载方法，可以包括：

接收客户端发送的文件下载请求，并确定与文件下载请求对应的请求文件；

在存在通过打包请求文件中的至少一个文件得到的文件包的情况下，将可用于下载文件包的下载信息返回给客户端，以使客户端基于预先配置的打包下载流程以及下载信息下载文件包，并根据下载得到的文件包得到至少一个文件。

根据本发明的另一方面，提供了一种文件下载装置，可以包括：

下载信息接收模块，用于获取文件下载请求，并将文件下载请求发送给源服务端，并接收源服务端针对文件下载请求返回的下载信息；

文件包下载模块，用于基于预先配置的打包下载流程及下载信息下载文件包，其中，文件包由源服务端对与文件下载请求对应的至少一个文件打包得到；

文件得到模块，用于根据下载得到的文件包得到至少一个文件。

根据本发明的另一方面，提供了一种文件下载装置，可以包括：

请求文件确定模块，用于接收客户端发送的文件下载请求，并确定与文件下载请求对应的请求文件；

下载信息返回模块，用于在存在通过打包请求文件中的至少一个文件得到的文件包的情况下，将可用于下载文件包的下载信息返回给客户端，以使客户端基于预先配置的打包下载流程以及下载信息下载文件包，并根据下载得到的文件包得到至少一个文件。

根据本发明的另一方面，提供了一种终端，可以包括：

至少一个处理器；以及

与至少一个处理器通信连接的存储器；其中，

存储器存储有可被至少一个处理器执行的计算机程序，计算机程序被至少一个处理器执行，以使至少一个处理器执行时实现本发明任意实施例所提供的可应用于客户端的文件下载方法。

根据本发明的另一方面，提供了一种源服务器，可以包括：

至少一个处理器；以及

与至少一个处理器通信连接的存储器；其中，

存储器存储有可被至少一个处理器执行的计算机程序，计算机程序被至少一个处理器执行，以使至少一个处理器执行时实现本发明任意实施例所提供的可应用于源服务端的文件下载方法。

根据本发明的另一方面，提供了一种计算机可读存储介质，其上存储有计算机指令，该计算机指令用于使处理器执行时实现本发明任意实施例所提供的文件下载方法。

本发明实施例的技术方案，客户端通过获取文件下载请求，并将文件下载请求发送给源服务端，然后接收源服务端针对文件下载请求返回的下载信息，该下载信息可用于下载源服务端针对与文件下载请求对应的至少一个文件打包得到的文件包；进而，客户端基于预先配置的打包下载流程以及下载信息下载文件包，然后根据下载得到的文件包得到至少一个文件，从而实现文件下载。上述技术方案，有效提升了文件下载的成功率。

应当理解，本部分所描述的内容并非旨在标识本发明的实施例的关键或是重要特征，也不用于限制本发明的范围。本发明的其它特征将通过以下的说明书而变得容易理解。

附图说明

为了更清楚地说明本发明实施例中的技术方案，下面将对实施例描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1是根据本发明实施例提供的一种文件下载方法的流程图；

图2是根据本发明实施例提供的另一种文件下载方法的流程图；

图3是根据本发明实施例提供的另一种文件下载方法的流程图；

图4是根据本发明实施例提供的另一种文件下载方法中的网络下载架构的示意图；

图5是根据本发明实施例提供的另一种文件下载方法中的打包下载架构的示意图；

图6是根据本发明实施例提供的另一种文件下载方法中可选示例的流程图；

图7是根据本发明实施例提供的一种文件下载装置的结构框图；

图8是根据本发明实施例提供的另一种文件下载装置的结构框图；

图9是实现本发明实施例的文件下载方法的终端或源服务器的结构示意图。

具体实施方式

为了使本技术领域的人员更好地理解本发明方案，下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分的实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都应当属于本发明保护的范围。

需要说明的是，本发明的说明书和权利要求书及上述附图中的术语“第一”、“第二”等是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的本发明的实施例能够以除了在这里图示或描述的那些以外的顺序实施。“目标”、“原始”等的情况类似，在此不再赘述。此外，术语“包括”和“具有”以及他们的任何变形，意图在于覆盖不排他的包含，例如，包含了一系列步骤或单元的过程、方法、系统、产品或设备不必限于清楚地列出的那些步骤或单元，而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或单元。

图1是本发明实施例中所提供的一种文件下载方法的流程图。本实施例可适用于打包下载文件的情况。该方法可以由本发明实施例提供的文件下载装置来执行，该装置可以由软件和/或硬件的方式实现，该装置可以集成在终端上。

参见图1，本发明实施例的方法具体包括如下步骤：

S110、获取文件下载请求，将文件下载请求发送给源服务端，并接收该源服务端针对文件下载请求返回的下载信息。

其中，文件下载请求可以用于请求下载某些文件(这里称为请求文件)，该请求文件可以是已知的，例如文件A、文件B和文件C；也可以是某个范围内的文件，例如XX模块下的文件，这时XX模块是已知的，但是XX模块下的文件是未知的，即在下载得到XX模块下的文件前，并不知道XX模块下具体有哪些文件。在实际应用中，可选的，该文件下载请求可以是在存在文件下载需求的情况下，自动生成的请求；也可以是由其余客户端或是服务端发送过来的请求；等等，在此未做具体限定。将该文件下载请求发送给源服务端。

源服务端可以根据接收到的文件下载请求确定客户端需下载的文件(为了简化表述，下文可通过D表示该需下载的文件)，例如根据从文件下载请求中得到的文件标识直接确定D；再如从文件下载请求中获取模块标识，然后根据预先设置的模块文件对应关系确定该模块标识所表征的模块下的文件，该模块下的文件即为D；等等。源服务端在确定出D后，进一步，可以针对文件下载请求(或是说是D)生成下载信息，并将下载信息返回给客户端。

S120、基于预先配置的打包下载流程以及下载信息下载文件包，其中，该文件包由源服务端对与文件下载请求对应的至少一个文件打包得到。

其中，客户端接收到的下载信息可用于表征D，在实际应用中，可选的，该下载信息可以直接体现出D的相关信息，例如文件名称和文件下载地址等；在存在通过打包D中的至少一个文件得到的文件包的情况下，该下载信息可以体现出该文件包的相关信息，例如文件包名称和文件包下载地址等，从而间接体现出D的相关信息，这时说明源服务端支持打包下载文件。可以理解的是，上述文件包可以由源服务端预先根据打包策略打包得到；也可以由源服务端在接收到文件下载请求后，根据该文件下载请求所请求的D打包得到；等等。

打包下载流程可以理解为预先配置的用于打包下载文件的流程，如判断待下载的文件包是否命中缓存、下载文件包、校验已下载的文件包的完整性以及解压已下载的文件包等，在此未做具体限定。

在根据下载信息确定源服务端支持打包下载文件的情况下，可以基于打包下载流程以及下载信息下载文件包，例如从部署有源服务端的源服务器上下载文件包，或是从缓存有文件包的缓存服务器上下载，等等，在此未做具体限定。可以理解的是，这里的文件包下载步骤可以理解为广义的下载步骤，即其并不单指下载文件包这一个步骤，而是可以是涵盖打包下载流程中的各个步骤。

S130、根据下载得到的文件包得到至少一个文件。

其中，由于文件包由源服务端通过对至少一个文件进行打包得到，该至少一个文件可以理解为D中的至少部分文件，因此在下载得到文件包的情况下，可以从文件包中得到该至少一个文件，由此实现了打包下载文件的效果。

在此基础上，可选的，在该至少一个文件属于D中的部分文件的情况下，针对D中除了该至少一个文件之外的差分文件，可以基于预先配置的单个下载流程下载差分文件，也可以请求源服务端为差分文件进行打包，从而通过打包下载流程下载差分文件对应的文件包，等等，在此未做具体限定。

可以理解的是，上述方案通过打包下载方式实现文件下载，至少具有如下效果：1)在文件包下载成功的情况下，文件包中的各个文件也下载成功，相较于逐个下载各个文件的方案，其有效提升了文件下载的成功率；2)减少了下载次数，所需下载的至少一个文件可通过一次下载得到；3)针对在文件下载过程中存在网络排队现象的情况，通过一次网络排队即可实现至少一个文件的下载，从而提升了网络使用率以及文件下载效率；4)降低了下载线程的压力，解决了单个下载文件时存在的频繁零碎下载的问题。

本发明实施例的技术方案，客户端通过获取文件下载请求，并将文件下载请求发送给源服务端，然后接收源服务端针对文件下载请求返回的下载信息，该下载信息可用于下载源服务端针对与文件下载请求对应的至少一个文件打包得到的文件包；进而，客户端基于预先配置的打包下载流程以及下载信息下载文件包，然后根据下载得到的文件包得到至少一个文件，从而实现文件下载。上述技术方案，有效提升了文件下载的成功率。

一种可选的技术方案，下载信息至少包括目标下载方式，基于预先配置的打包下载流程以及下载信息下载文件包，包括：在根据目标下载方式确定打包下载文件的情况下，基于预先配置的打包下载流程以及下载信息下载文件包。在此基础上，可选的，上述文件下载方法，还包括：在根据目标下载方式确定单个下载文件的情况下，基于预先配置的单个下载流程以及下载信息下载至少一个文件。

其中，目标下载方式可用于指示文件下载方式，例如可以是打包下载文件或单个下载文件。在根据目标下载方式确定打包下载文件的情况下，可以基于打包下载流程以及下载信息下载文件包，进而从得到的文件包中得到至少一个文件，由此实现了这些文件的有效下载。在此基础上，可选的，在根据目标下载方式确定单个下载文件的情况下，可基于预先配置的单个下载流程以及下载信息下载至少一个文件，即依次下载至少一个文件中的各个文件，由此实现了这些文件的有效下载。可以理解为是，可能在如下情况下涉及到通过单个下载文件来实现文件下载，客户端请求通过单个下载文件这种方式进行文件下载，或是，服务端未针对至少一个文件打包得到文件包，等等，在此未做具体限定。

另一种可选的技术方案，下载信息包括文件包的文件包信息；基于预先配置的打包下载流程以及下载信息下载文件包，包括：获取已下载过的历史包的历史包信息，对比历史包信息与文件包信息，并在根据得到的对比结果确定具有文件包信息的文件包未下载过的情况下，基于文件包信息下载文件包；上述文件下载方法，还包括：将文件包信息进行存储。

其中，在实际应用中，可能存在客户端所请求下载的文件在先前已下载的情况，例如客户端在请求下载XX模块下的全部文件时，该全部文件中的部分文件有可能在先前已下载完毕。因此，为了避免出现文件重复下载的情况下，考虑到先前下载过的历史文件包的历史包信息已存储，因此在获取到文件包的文件包信息的情况下，可将历史包信息与文件包信息进行对比。在文件包信息与历史包信息中的部分或是全部重合的情况下，这说明待下载的文件包在先前已下载过，无需重复下载；类似的，在文件包信息与历史包信息完全未重合的情况下，这说明待下载的文件包在先前未下载过，那么可基于文件包信息下载该文件包。在此基础上，为了避免后续重复(即冗余)下载该文件包，可以将该文件包的文件包信息进行存储，此时存储下来的文件包信息即为历史包信息。上述技术方案，提升了文件包下载的有效性，从而提升了文件下载的有效性；另外，其与打包下载方式结合，只需判断文件包是否命中缓存，无需判断文件包中的各个文件是否命中缓存，由此保证了所需的至少一个文件的快速下载；而且，在文件包缓存命中的情况下，文件包中的各个文件也缓存命中，相较于逐个判断各个文件是否缓存命中的方案，其增加了缓存命中率。

另一种可选的技术方案，基于预先配置的打包下载流程以及下载信息下载文件包，包括：基于下载信息下载文件包，对下载完成的文件包的完整性进行校验；根据下载得到的文件包得到至少一个文件，可包括：在根据得到的校验结果确定文件包完整的情况下，从下载完整的文件包中得到至少一个文件。

其中，考虑到下载得到的文件包不一定完整，非完整的文件包会直接影响到其内的至少一个文件的完整性，从而导致文件下载失败。因此，为保证文件下载的成功率，可以对下载完成的文件包的完整性进行校验，例如通过对文件包的消息摘要算法第五版(Message Digest Algorithm MD5，md5)值或是长度值进行校验来确定文件包的完整性。在此基础上，在通过校验确定文件包完整的情况下，可以从该文件包中得到至少一个文件，由此保证了下载得到的至少一个文件的完整性。可以理解的是，由于本发明实施例通过下载文件包来下载文件，这意味着只需对文件包的完整性进行校验，无需对文件包中的各个文件的完整性分别进行校验，由此减少了校验次数，从而节省了校验资源。

在此基础上，可选的，基于下载信息下载文件包，并对下载完成的文件包的完整性进行校验，可以包括：调用线程池中的下载线程，基于下载信息下载文件包；调用线程池中的校验线程，校验下载完成的文件包的完整性。其中，在需要下载多个文件包的情况下，考虑到如果将文件包的下载操作和校验操作均置于同一线程上执行，那么在对某个文件包执行校验操作时，无法对另一个文件包执行下载操作，该另一个文件包只能处于等待下载的状态。因此，为了提高文件包的下载效率，可以预先设置包含至少两条线程的线程池，然后将该至少两条线程中的至少一条线程作为下载线程以及至少一条线程作为校验线程。在此基础上，通过调用下载线程下载文件包，并且通过校验线程校验文件包的完整性，由此提高了网络线程的使用率，从而保证了文件包的下载效率。

另一种可选的技术方案，文件包的数量包括至少两个，下载信息至少包括至少两个文件包的下载优先级；基于预先配置的打包下载流程以及下载信息下载文件包，包括：根据下载优先级从至少两个文件包中确定当前待下载的当前包，并根据下载信息中与当前包对应的当前包信息，下载当前包；在至少两个文件包中存在未下载过的文件包的情况下，重复执行根据下载优先级从至少两个文件包中确定当前待下载的当前包的步骤。

其中，考虑到在复杂的业务场景下，后来需要下载的文件包M的重要性有可能高于先前需要下载的文件包N的重要性，但是N的下载任务排在了M的下载任务的前面，这就可能导致M的下载任务受到阻塞。因此，为了避免出现上述情况，让重要性更高的文件包快速得以下载，源服务端可以针对各文件包分别设置相应的下载优先级，并将其作为下载信息的一部分反馈给客户端。

这样一来，客户端在需要下载至少两个文件包的情况下，其可以根据它们的下载优先级从它们中确定当前待下载的当前包，然后根据下载信息中与当前包对应的当前包信息下载当前包。进而，在至少两个文件包中存在未下载过的文件包的情况下，可以重复执行上述步骤，直至基于下载优先级依次下载完成各个文件包。上述技术方案，可以优先下载更为重要的文件包，从而保证了该文件包中的各个较为重要的文件的快速下载。

在实际应用中，可选的，上述下载优先级可以通过各个文件包的下载信息在结果列表中的位置确定，例如，源服务端将N的下载信息置于结果列表1的首位返回给客户端，然后源服务端将N的下载信息移动到结果列表1的次位，并且将M的下载信息置于结果列表1的首位，将由此得到的结果列表2返回给客户端。假设客户端在接收到结果列表2时还未处理结果列表1，那么其可以优先处理结果列表2。在此基础上，由于结果列表2中排在首位的是M的下载信息，这说明M的下载优先级最高，因此此时可以优先下载M。

图2是本发明实施例中提供的另一种文件下载方法的流程图。本实施例以上述各技术方案为基础进行优化。在本实施例中，可选的，上述文件下载方法，还包括：在文件包下载失败的情况下，根据预先配置的重试下载流程，对文件包进行重试下载。其中，与上述各实施例相同或是相应的术语的解释在此不再赘述。

参见图2，本实施例的方法具体可以包括如下步骤：

S210、获取文件下载请求，将文件下载请求发送给源服务端，并接收该源服务端针对文件下载请求返回的下载信息。

S220、基于预先配置的打包下载流程以及下载信息下载文件包，其中，该文件包由源服务端对与文件下载请求对应的至少一个文件打包得到。

S230、在文件包下载成功的情况下，根据下载得到的文件包得到至少一个文件。

其中，在文件包下载成功的情况下，可以直接从成功下载的文件包中得到所需下载的至少一个文件。

S240、在文件包下载失败的情况下，根据预先配置的重试下载流程，对该文件包进行重试下载。

其中，由于客户端通过网络下载文件包，因此文件包下载失败是不可避免的事情。为了保证文件包的有效下载，在文件包下载失败的情况下，可以根据预先配置的重试下载流程，对文件包进行重试下载，即再次下载该下载失败的文件包。在此基础上，可选的，可基于如下几种方式中的任意一种实现文件包的重试下载：确定用于下载文件包的下载网络的网络类型，并在根据网络类型确定重试下载文件包的情况下，对文件包进行重试下载，例如在无线网络下、数据网络的负载低或是数据网络的信号强等的情况下，重试下载文件包，由此解决了因为无网而导致文件包下载失败的问题；或是，获取预先配置的重试下载周期，并基于重试下载周期，对文件包进行重试下载，这可以减轻下载线程和下载网络的负担，将下载任务周期打匀后下载，其提升了下载成功率；或是，对文件包进行重试下载，即在文件包下载失败后直接尝试再次下载，这种针对下载网络抖动情况可以保证文件包的有效下载；等等，在此未做具体限定。

本发明实施例的技术方案，在文件包下载失败的情况下，通过预先配置的重试下载流程对文件包进行重试下载，实现了各种情况下的文件包的有效下载。

在上述任一技术方案的基础上，一种可选的技术方案，上述文件下载方法，还包括：对已下载得到的至少一个文件进行缓存；响应于文件删除任务，删除已缓存文件中的失效文件，其中，已缓存文件包括至少一个文件。在此基础上，可选的，响应于文件删除任务之前，上述的文件下载方法，还可包括：在检测到客户端启动事件的情况下，激活文件删除任务；或是，基于预先配置的文件删除周期，激活文件删除任务；或是，在客户端负载处于预设空闲状态的情况下，激活文件删除任务；相应的，响应于文件删除任务，包括：响应于已激活的文件删除任务。

其中，由于在后续流程中需要应用已下载得到的至少一个文件，因此可以将该已下载得到的至少一个文件进行缓存。在此基础上，考虑到客户端的磁盘内存的存储空间有限，为了避免无效文件对于存储空间的占用，可以在检测到已被激活的文件删除任务的情况下，删除已缓存文件中的失效文件，该已下载得到的至少一个文件即为该已缓存文件中的部分或是全部。实际应用中，可选的，可以在启动客户端或是在客户端负载处于预设空闲状态的情况下激活文件删除任务；可以基于预先配置的文件删除周期激活文件删除任务，从而周期性删除失效文件；还可以定向激活文件删除任务，即将满足一定条件的失效文件进行删除；等等，在此未做具体限定。上述技术方案，可避免存储空间的浪费。

图3是本发明实施例中所提供的一种文件下载方法的流程图。本实施例可适用于打包下载文件的情况。该方法可以由本发明实施例提供的文件下载装置来执行，该装置可以由软件和/或硬件的方式实现，该装置可以集成在源服务端。

参见图3，本实施例的方法具体可以包括如下步骤：

S310、接收客户端发送的文件下载请求，确定与文件下载请求对应的请求文件。

其中，请求文件可以是文件下载请求所请求下载的文件，其的数量可以是一个或是多个，在此未做具体限定。

S320、在存在通过打包请求文件中的至少一个文件得到的文件包的情况下，将可用于下载文件包的下载信息返回给客户端，以使客户端基于预先配置的打包下载流程以及下载信息下载文件包，并根据下载得到的文件包得到至少一个文件。

其中，在源服务端已对请求文件中的至少一个文件进行打包得到文件包的情况下，将可用于下载该文件包的下载信息返回给客户端，以使客户端基于接收到的下载信息打包下载文件。需要说明的是，可选的，该至少一个文件可以是请求文件中的部分或是全部，在该至少一个文件是请求文件中的部分的情况下，上述的下载信息也可用于下载请求文件中的除该至少一个文件之外的差分文件，这与实际应用场景有关，在此未做具体限定。

本发明实施例的技术方案，源服务端通过接收客户端发送的文件下载请求，并确定与文件下载请求对应的请求文件；进而，在存在通过打包请求文件中的至少一个文件得到的文件包的情况下，将可用于下载文件包的下载信息返回给客户端，以使客户端基于预先配置的打包下载流程以及下载信息下载文件包，并根据下载得到的文件包得到至少一个文件，从而实现了文件下载。上述技术方案，有效提升了文件下载的成功率。

一种可选的技术方案，文件下载请求中携带请求下载方式，在存在通过打包请求文件中的至少一个文件得到的文件包的情况下，将可用于下载文件包的下载信息返回给客户端，包括：在请求下载方式是打包下载文件，并且存在通过打包请求文件中的至少一个文件得到的文件包的情况下，将可用于下载文件包的下载信息返回客户端。其中，请求下载方式可以用于表示客户端请求下载文件的方式，例如可以是打包下载文件或单个下载文件。因此，可以在客户端请求打包下载文件并且存在文件包(即服务端支持打包下载文件)的情况，将用于下载文件包的下载信息返回客户端，从而满足客户端的下载需求。

另一可选的技术方案，上述文件下载方法，还包括：响应于文件打包指令，对至少一个文件进行打包，得到文件包，并将文件包缓存至第一缓存服务器；下载信息包括第一缓存服务器的第一地址信息，以使客户端基于预先配置的打包下载流程以及下载信息下载文件包，包括：以使客户端基于预先配置的打包下载流程，从第一地址信息对应的第一缓存服务器上下载文件包。

其中，文件打包指令可以用于指示对至少一个文件进行打包的指令。实际应用中，可选的，源服务端可以通过多种策略确定多个文件中需要打包的文件，例如在新增或是变更的文件的数量达到预设数量阈值的情况下，对该新增或是变更的文件进行打包，由此可以实现增量下载，增加了扩展性应对变化；再如在新增一个模块的情况下，对该模块下的部分或是全部文件进行打包，示例性的，将该模块下具有共性的文件打包至一个文件包中；再如根据网络情况确定将多少个文件打包至一个文件包中；等等，在此未做具体限定。

将打包得到的文件包缓存至第一缓存服务器，该第一缓存服务器可以理解为分布在内容分发网络(Content Delivery Network，CDN)上的缓存服务器。这样一来，源服务端可以将该第一缓存服务器的第一地址信息作为下载信息的一部分，返回给客户端，以使客户端从该第一缓存服务器上快速下载到文件包，从而可以避免大量回源情况的产生(即回到源服务器上下载文件包)。

在此基础上，可选的，上述文件下载方法，还可包括：在客户端未从第一缓存服务器上成功下载文件包的情况下，针对缓存有文件包的第二缓存服务器，将第二缓存服务器的第二地址信息发送给客户端，以使客户端从第二地址信息对应的第二缓存服务器上下载文件包。其中，为了保证文件包的成功下载，在确定客户端未能从第一缓存服务器上下载到文件包的情况下，可以将同样缓存有文件包的第二缓存服务器的第二地址信息发送给客户端，以使客户端从第二缓存服务器上下载到文件包，其中的第二缓存服务器可以理解为分布在另一CND上的缓存服务器，即该第二缓存服务器与第一缓存服务器分布在不同的CDN。上述技术方案，通过切换CDN来保证客户端成功下载到文件包，从而可以避免出现因为CDN挂掉而导致文件包下载失败的情况。

为了从整体上更好地理解上述的各个技术方案，下面结合具体示例，对其进行示例性说明。示例性的，基于图4所示的网络下载架构实现文件下载过程，接下来自底向上对该网络下载架构进行详细说明。

最底层是各种滤波(filter)，例如网络滤波(DYNetFilter)用于校验网络请求(即文件下载请求)是否合法，经过DYNetFilter拦截后依然满足请求条件的网络请求可用于请求下载文件；Md5滤波(DYMd5Filter)用于校验下载文件/文件包的Md5值是否合法，长度滤波(DYLengthFilter)用于校验下载文件/文件包的长度是否为所需的长度，经过DYMd5Filter和DYLengthFilter拦截后依然满足条件的文件/文件包即为所需的文件/文件包。

中间层的角色为具体工作的类，例如网络任务(DYNetTask)、网络处理(DYNetProcessoir)和网络工作(DYNetWorker)，其中DYNetWorker是外围，DYNetTask和DYNetProcessoir均跑在DYNetWorker的里面，它们类似于类和对象，或是线程池和线程的关系。具体的，DYNetTask通过调用DYSingleFileFetcher或DYModuleFetcher承载各个下载任务，DYNetProcessoir通过调用DYMd5Filter或DYLengthFilter处理下载下来的文件/文件包，DYNetWorker用于消费这些下载任务。

最上层为主要使用的功能，单个下载(DYSingleFileFetcher)负责下载单个文件，而打包下载(DYModuleFetcher)负责下载整个模块下的全部文件，其中在DYModuleFetcher中使用DYSingleFileFetcher进行文件下载。网络管理(DYNetManager)是整个网络下载架构的一个总控角色，可通过其使用合适的功能(例如DYSingleFileFetcher或是DYNetManager)工作，也可以实现不同的方法(例如应用线程池或是单个线程)增强网络下载架构的能力，主要起到一个连接与调度的作用，最终业务使用方可以根据不同的场景在DYNetManger中调用不同的方法以达到相应的业务目的。

上述提出的统一的网络下载架构至少具有如下优点：首先通过DYNetTask和DYNetWorker的配置，完成了对网络使用线程的管理；其次，通过对不同角色功能的拆分，可实现功能相似的抽象达到最大限度的代码复用(例如基于同一套代码实现单个文件和文件包的MD5校验)；最后，架构条理比较清晰，方便问题排查。

接下来对图5所示的打包下载架构进行详细说明，其主要涉及如下内容：

更新机制：用于更新客户端和服务端上文件/文件包的更新，具体的，为了避免文件包的冗余下载，在文件包下载成功并且处理完成后，对文件包的文件包信息进行信息持久化；在下载的文件包中未能覆盖所需的全部文件的情况下，仅下载差分文件，从而及时保证下载的文件为最新；服务端在接收到文件变更或者文件新增的通知后，及时将有变更或是新增的文件更新到CDN上，以使客户端在缺少对应的文件时及时从CDN上下载，从而避免出现大量回源情况(即回到源服务器下载文件)；变更的文件的数量达到预设数量阈值的情况下，将这些文件打包为一个新的文件包，从而方便客户端批量下载这些文件。

重试下载策略：一、将客户端的网络类型作为是否重试下载的依据，适用于处理因为手机无网而下载失败的情况；二、直接尝试再次下载，其针对网络抖动情况可以保证文件包的下载；三、周期重试下载，这可以减轻网络线程和手机网络的负担，将下载任务周期打匀后下载，提升下载成功率；四、切换CDN重试下载，这可以处理因为CDN挂掉而导致下载失败的情况，通过尝试使用不同的CDN以规避单一CDN源的下载失败。

删除策略：一、App启动删除，启动后激活文件删除任务；二、轮询删除，周期性尝试删除失效文件；三、空闲删除，等到客户端负载降低，空闲时激活文件删除任务；四、定向删除，将一定条件下的文件直接删除。

降级策略：针对业务需要及时下载某个模块下的文件或者整体模块不可用的情况，可采用如下的降级策略：一、SDK整体降级，整体不会尝试下载文件；二、模块降级，对应的模块下的全部文件/文件包不会下载；三、文件包降级，针对性的降级某文件包的下载。

接下来对图6所示的打包下载流程进行详细说明。具体的，

首先，客户端向服务端发起携带有特定标签(用于表示请求下载方式)的文件下载请求，服务端根据接收到的文件下载请求确定打包下载文件或是单个下载文件，然后根据确定结果将对应的产物信息(例如文件包信息或文件信息)放到结果列表中，并将结果列表返回给客户端。在实际应用中，可选的，结果列表可以通过Jason结构进行表示，该Jason结构中包括字段1和字段2，字段1下存储有文件包信息，即字段1表示打包下载文件，而字段2下存储有文件信息，即字段2表示单个下载文件。换言之，客户端根据接收到的Jason结构即可确定目标下载方式是打包下载文件还是单个下载文件。

客户端处理结果列表，如果确定单个下载文件，则根据结果列表循环下载各个文件；如果确定打包下载文件，则根据各个文件包的下载优先级进行顺序下载。在下载某个文件包之前，从本地的持久化信息中提取已经下载的历史包的历史包信息，并将该历史包信息与该文件包的文件包信息进行匹配。如果经匹配确定该文件包已经下载过，则跳过该文件包，继续寻找未下载的文件包；否则，下载该文件包，并在下载完成后校验其的完整性，从而在保证文件包的完整前提下解压到目标文件夹并记录解压成功的文件包的文件包信息。在下载文件包校验不通过的情况下，上报失败信息，并触发重试下载策略，从而保证文件包的有效下载。在文件包解压失败的情况下，上报失败原因，如果是存储空间不足，则触发删除策略，从而保证文件包的有效解压。

图7为本发明实施例中提供的文件下载装置的结构框图，该装置用于执行上述任意实施例所提供的文件下载方法。该装置与上述各实施例的文件下载方法属于同一个发明构思，在文件下载装置的实施例中未详尽描述的细节内容，可以参考上述文件下载方法的实施例。参见图7，该装置具体可以包括：下载信息接收模块410、文件包下载模块420和文件得到模块430。

其中，下载信息接收模块410，用于获取文件下载请求，将文件下载请求发送给源服务端，并接收源服务端针对文件下载请求返回的下载信息；

文件包下载模块420，用于基于预先配置的打包下载流程及下载信息下载文件包，其中，文件包由源服务端对与文件下载请求对应的至少一个文件打包得到；

文件得到模块430，用于根据下载得到的文件包得到至少一个文件。

可选的，下载信息至少包括目标下载方式，文件包下载模块420，可包括：

文件包第一下载单元，用于在根据目标下载方式确定打包下载文件的情况下，基于预先配置的打包下载流程以及下载信息下载文件包。

在此基础上，可选的，上述文件下载装置，还可包括：

文件下载模块，用于根据目标下载方式确定单个下载文件的情况下，基于预先配置的单个下载流程以及下载信息下载至少一个文件。

可选的，下载信息包括文件包的文件包信息，文件包下载模块420，包括：

文件包第二下载单元，用于获取已下载过的历史包的历史包信息，对比历史包信息与文件包信息，并在根据得到的对比结果确定具有文件包信息的文件包未下载过的情况下，基于文件包信息下载文件包；

上述文件下载装置，还可包括：

文件包信息存储模块，用于将文件包信息进行存储。

可选的，文件包下载模块420，包括：

文件包校验单元，用于基于下载信息下载文件包，并对下载完成的文件包的完整性进行校验；

文件得到模块430，具体用于：

在根据得到的校验结果确定文件包完整的情况下，从下载完整的文件包中得到至少一个文件。

在此基础上，可选的，文件包校验单元，具体用于：

调用线程池中的下载线程，基于下载信息下载文件包；

调用线程池中的校验线程，校验下载完成的文件包的完整性。

可选的，文件包的数量包括至少两个，下载信息至少包括至少两个文件包的下载优先级，文件包下载模块420，包括：

当前包下载单元，用于根据下载优先级从至少两个文件包中确定当前待下载的当前包，并根据下载信息中与当前包对应的当前包信息，下载当前包；

重复执行单元，用于在至少两个文件包中存在未下载过的文件包的情况下，重复执行根据下载优先级从至少两个文件包中确定当前待下载的当前包的步骤。

可选的，上述文件下载装置，还可包括：

文件包重试下载模块，用于在文件包下载失败的情况下，根据预先配置的重试下载流程，对文件包进行重试下载。

可选的，在上述装置的基础上，文件包重试下载模块，可以包括：

文件包第一重试下载单元，用于确定用于下载文件包的下载网络的网络类型，并在根据网络类型确定重试下载文件包的情况下，对文件包进行重试下载；或是，

文件包第二重试下载单元，用于获取预先配置的重试下载周期，并基于重试下载周期，对文件包进行重试下载；或是，

文件包第三重试下载单元，用于对文件包进行重试下载。

可选的，上述文件下载装置，还可包括：

文件缓存模块，用于对已下载得到的至少一个文件进行缓存；

失效文件删除模块，用于响应于文件删除任务，删除已缓存文件中的失效文件，其中，已缓存文件包括至少一个文件。

在此基础上，可选的，上述文件下载装置，还可包括：

文件删除任务第一激活模块，用于响应于文件删除任务前，在检测到客户端启动事件的情况下，激活文件删除任务；或是，

文件删除任务第二激活模块，用于基于预先配置的文件删除周期，激活文件删除任务；或是，

文件删除任务第三激活模块，用于在客户端负载处于预设空闲状态的情况下，激活文件删除任务；

失效文件删除模块，包括：

文件删除任务响应单元，用于响应于已激活的文件删除任务。

本发明实施例所提供的文件下载装置，客户端通过下载信息接收模块获取文件下载请求，并将文件下载请求发送给源服务端，然后接收源服务端针对文件下载请求返回的下载信息，该下载信息可用于下载源服务端针对与文件下载请求对应的至少一个文件打包得到的文件包；进而，客户端文件包下载模块和文件得到模块相互配合，基于预先配置的打包下载流程及下载信息下载文件包，然后根据下载得到的文件包得到至少一个文件，从而实现文件下载。上述装置，有效提升了文件下载的成功率。

本发明实施例所提供的文件下载装置可执行本发明任意实施例所提供的文件下载方法，具备执行方法相应的功能模块和有益效果。

值得注意的是，上述文件下载装置的实施例中，所包括的各个单元和模块只是按照功能逻辑进行划分的，但并不局限于上述的划分，只要能够实现相应的功能即可；另外，各功能单元的具体名称也只是为了便于相互区分，并不用于限制本发明的保护范围。

图8为本发明实施例中提供的文件下载装置的结构框图，该装置用于执行上述任意实施例所提供的文件下载方法。该装置与上述各实施例的文件下载方法属于同一个发明构思，在文件下载装置的实施例中未详尽描述的细节内容，可以参考上述文件下载方法的实施例。参见图8，该装置具体可以包括：请求文件确定模块510和下载信息返回模块520。

其中，请求文件确定模块510，用于接收客户端发送的文件下载请求，并确定与文件下载请求对应的请求文件；

下载信息返回模块520，用于在存在通过打包请求文件中的至少一个文件得到的文件包的情况下，将可用于下载文件包的下载信息返回给客户端，以使客户端基于预先配置的打包下载流程以及下载信息下载文件包，并根据下载得到的文件包得到至少一个文件。

可选的，文件下载请求中携带请求下载方式，下载信息返回模块520，可包括：

下载信息返回单元，用于在请求下载方式是打包下载文件，并且存在通过打包请求文件中的至少一个文件得到的文件包的情况下，将可用于下载文件包的下载信息返回客户端。

可选的，上述文件下载装置，还可包括：

文件包缓存模块，用于响应于文件打包指令，对至少一个文件进行打包，得到文件包，并将文件包缓存至第一缓存服务器；

下载信息包括第一缓存服务器的第一地址信息，下载信息返回模块520，包括：

文件包第三下载单元，用于以使客户端基于预先配置的打包下载流程，从第一地址信息对应的第一缓存服务器上下载文件包。

在此基础上，可选的，上述文件下载装置，还可包括：

第二地址信息发送模块，用于客户端未从第一缓存服务器上成功下载文件包的情况下，针对缓存有文件包的第二缓存服务器，将第二缓存服务器的第二地址信息发送给客户端，以使客户端从第二地址信息对应的第二缓存服务器上下载文件包。

本发明实施例提供的文件下载装置，源服务端通过请求文件确定模块接收客户端发送的文件下载请求，并确定与文件下载请求对应的请求文件；进而，通过下载信息返回模块在存在通过打包请求文件中的至少一个文件得到的文件包的情况下，将可用于下载文件包的下载信息返回给客户端，以使客户端基于预先配置的打包下载流程以及下载信息下载文件包，并根据下载得到的文件包得到至少一个文件，从而实现了文件下载。上述装置，有效提升了文件下载的成功率。

本发明实施例所提供的文件下载装置可执行本发明任意实施例所提供的文件下载方法，具备执行方法相应的功能模块和有益效果。

值得注意的是，上述文件下载装置的实施例中，所包括的各个单元和模块只是按照功能逻辑进行划分的，但并不局限于上述的划分，只要能够实现相应的功能即可；另外，各功能单元的具体名称也只是为了便于相互区分，并不用于限制本发明的保护范围。

图9示出了可以用来实施本发明的实施例的终端或是源服务器(后文统称为电子设备)10的结构示意图。电子设备旨在表示各种形式的数字计算机，诸如，膝上型计算机、台式计算机、工作台、个人数字助理、服务器、刀片式服务器、大型计算机、和其它适合的计算机。电子设备还可以表示各种形式的移动装置，诸如，个人数字处理、蜂窝电话、智能电话、可穿戴设备(如头盔、眼镜、手表等)和其它类似的计算装置。本文所示的部件、它们的连接和关系、以及它们的功能仅仅作为示例，并且不意在限制本文中描述的和/或者要求的本发明的实现。

如图9所示，电子设备10包括至少一个处理器11，以及与至少一个处理器11通信连接的存储器，如只读存储器(ROM)12、随机访问存储器(RAM)13等，其中，存储器存储有可被至少一个处理器执行的计算机程序，处理器11可以根据存储在只读存储器(ROM)12中的计算机程序或从存储单元18加载到随机访问存储器(RAM)13中的计算机程序，来执行各种适当的动作和处理。在RAM 13中，还可存储电子设备10操作所需的各种程序和数据。处理器11、ROM 12以及RAM 13通过总线14彼此相连。输入/输出(I/O)接口15也连接至总线14。

电子设备10中的多个部件连接至I/O接口15，包括：输入单元16，例如键盘、鼠标等；输出单元17，例如各种类型的显示器、扬声器等；存储单元18，如磁盘、光盘等；以及通信单元19，例如网卡、调制解调器、无线通信收发机等。通信单元19允许电子设备10通过诸如因特网的计算机网络和/或各种电信网络与其他设备交换信息/数据。

处理器11可以是各种具有处理和计算能力的通用和/或专用处理组件。处理器11的一些示例包括但不限于中央处理单元(CPU)、图形处理单元(GPU)、各种专用的人工智能(AI)计算芯片、各种运行机器学习模型算法的处理器、数字信号处理器(DSP)、以及任何适当的处理器、控制器、微控制器等。处理器11执行上文所描述的各个方法和处理，例如文件下载方法。

在一些实施例中，文件下载方法可被实现为计算机程序，其被有形地包含于计算机可读存储介质，例如存储单元18。在一些实施例中，计算机程序的部分或者全部可以经由ROM 12和/或通信单元19而被载入和/或安装到电子设备10上。当计算机程序加载到RAM 13并由处理器11执行时，可以执行上文描述的文件下载方法的一个或多个步骤。备选地，在其他实施例中，处理器11可通过其他任何适当的方式(例如，借助于固件)而被配置为执行文件下载方法。

本文中以上描述的系统和技术的各种实施方式可以在数字电子电路系统、集成电路系统、场可编程门阵列(FPGA)、专用集成电路(ASIC)、专用标准产品(ASSP)、芯片上系统的系统(SOC)、负载可编程逻辑设备(CPLD)、计算机硬件、固件、软件、和/或它们的组合中实现。这些各种实施方式可以包括：实施在一个或者多个计算机程序中，该一个或者多个计算机程序可在包括至少一个可编程处理器的可编程系统上执行和/或解释，该可编程处理器可以是专用或者通用可编程处理器，可以从存储系统、至少一个输入装置、以及至少一个输出装置接收数据和指令，并且将数据和指令传输至该存储系统、该至少一个输入装置、以及该至少一个输出装置。

用于实施本发明的方法的计算机程序可以采用一个或多个编程语言的任何组合来编写。这些计算机程序可以提供给通用计算机、专用计算机或是其他可编程数据处理装置的处理器，使得计算机程序当由处理器执行时使流程图和/或框图中所规定的功能/操作被实施。计算机程序可以完全在机器上执行、部分地在机器上执行，作为独立软件包部分地在机器上执行并且部分地在远程机器上执行或完全在远程机器或服务器上执行。

在本发明的上下文中，计算机可读存储介质可以是有形的介质，其可以包含或存储以供指令执行系统、装置或设备使用或与指令执行系统、装置或设备结合地使用的计算机程序。计算机可读存储介质可以包括但不限于电子的、磁性的、光学的、电磁的、红外的、或半导体系统、装置或设备，或者上述内容的任何合适组合。备选地，计算机可读存储介质可以是机器可读信号介质。机器可读存储介质的更具体示例会包括基于一个或多个线的电气连接、便携式计算机盘、硬盘、随机存取存储器(RAM)、只读存储器(ROM)、可擦除可编程只读存储器(EPROM或快闪存储器)、光纤、便捷式紧凑盘只读存储器(CD-ROM)、光学储存设备、磁储存设备、或上述内容的任何合适组合。

为了提供与用户的交互，可以在电子设备上实施此处描述的系统和技术，该电子设备具有：用于向用户显示信息的显示装置(例如，CRT(阴极射线管)或者LCD(液晶显示器)监视器)；以及键盘和指向装置(例如，鼠标或者轨迹球)，用户可以通过该键盘和该指向装置来将输入提供给电子设备。其它种类的装置还可以用于提供与用户的交互；例如，提供给用户的反馈可以是任何形式的传感反馈(例如，视觉反馈、听觉反馈、或者触觉反馈)；并且可以用任何形式(包括声输入、语音输入或者、触觉输入)来接收来自用户的输入。

可以将此处描述的系统和技术实施在包括后台部件的计算系统(例如，作为数据服务器)、或者包括中间件部件的计算系统(例如，应用服务器)、或者包括前端部件的计算系统(例如，具有图形用户界面或者网络浏览器的用户计算机，用户可以通过该图形用户界面或者该网络浏览器来与此处描述的系统和技术的实施方式交互)、或者包括这种后台部件、中间件部件、或者前端部件的任何组合的计算系统中。可以通过任何形式或者介质的数字数据通信(例如，通信网络)来将系统的部件相互连接。通信网络的示例包括：局域网(LAN)、广域网(WAN)、区块链网络和互联网。

计算系统可以包括客户端和服务器。客户端和服务器一般远离彼此并且通常通过通信网络进行交互。通过在相应的计算机上运行并且彼此具有客户端-服务器关系的计算机程序来产生客户端和服务器的关系。服务器可以是云服务器，又称为云计算服务器或云主机，是云计算服务体系中的一项主机产品，以解决了传统物理主机与VPS服务中，存在的管理难度大，业务扩展性弱的缺陷。

应该理解，可以使用上面所示的各种形式的流程，重新排序、增加或删除步骤。例如，本发明中记载的各步骤可以并行地执行也可以顺序地执行也可以不同的次序执行，只要能够实现本发明的技术方案所期望的结果，本文在此不进行限制。

上述具体实施方式，并不构成对本发明保护范围的限制。本领域技术人员应该明白的是，根据设计要求和其他因素，可以进行各种修改、组合、子组合和替代。任何在本发明的精神和原则之内所作的修改、等同替换和改进等，均应包含在本发明保护范围之内。