资源的预下载方法、装置、电子设备及存储介质与流程

1.本技术涉及通信技术领域，具体而言，本技术涉及一种资源的预下载方法、装置、电子设备、计算机可读存储介质及计算机程序产品。


背景技术：

2.在应用程序发布新版本前，提前下载新版本的相关资源至终端，称之为预下载。通过预下载，能够在允许加载该资源的时间点，直接加载该提前下载好的资源进行应用程序的版本更新，相比在新版本发布后用户启动应用程序后才开始下载新版本的相关资源，可避免用户感知更新版本的等待时间。
3.相关技术中，预下载应用程序的资源，可以由该应用程序自身执行，也可以由用于应用分发的应用程序——例如应用商店执行，相关技术常出现因为预下载流程中断而重新下载资源的情况，影响用户体验。


技术实现要素：

4.本技术实施例提供了一种资源的预下载方法、装置、电子设备、计算机可读存储介质及计算机程序产品，可以解决现有技术的上述问题。所述技术方案如下：根据本技术实施例的一个方面，提供了一种资源的预下载方法，该方法包括：确定第二应用程序暂停下载所述资源，确定第一文件集合以及所述第二应用程序对所述第一文件集合中各第一文件的下载记录，所述第一文件为所述资源中除第二文件集合以外的文件，所述第二文件集合中的第二文件为用于加载所述资源的资源加载程序已下载的文件；对于每个第一文件，确定所述第一应用程序对所述第一文件的下载记录，根据所述第一应用程序和所述第二应用程序各自对所述第一文件的下载记录，确定并执行所述第一文件的处理策略；其中，当所述第一应用程序为所述资源加载程序时，所述第二应用程序为用于应用分发的应用分发程序；当所述第一应用程序为所述应用分发程序时，所述第二应用程序为所述资源加载程序。
5.根据本技术实施例的另一个方面，提供了一种资源的预下载装置，应用于第一应用程序，所述资源包括至少一个文件，该装置包括：文件确定模块，用于确定第二应用程序暂停下载所述资源，确定第一文件集合以及所述第二应用程序对所述第一文件集合中各第一文件的下载记录，所述第一文件为所述资源中除第二文件集合以外的文件，所述第二文件集合中的第二文件为用于加载所述资源的资源加载程序已下载的文件；策略执行模块，用于对于每个第一文件，确定所述第一应用程序对所述第一文件的下载记录，根据所述第一应用程序和所述第二应用程序各自对所述第一文件的下载记录，确定并执行所述第一文件的处理策略；
其中，当所述第一应用程序为所述资源加载程序时，所述第二应用程序为用于应用分发的应用分发程序；当所述第一应用程序为所述应用分发程序时，所述第二应用程序为所述资源加载程序。
6.根据本技术实施例的另一个方面，提供了一种电子设备，该电子设备包括：存储器、处理器及存储在存储器上的计算机程序，处理器执行所述计算机程序以实现上述方法的步骤。
7.根据本技术实施例的再一个方面，提供了一种计算机可读存储介质，其上存储有计算机程序，计算机程序被处理器执行时实现上述方法的步骤。
8.根据本技术实施例的一个方面，提供了一种计算机程序产品，包括计算机程序，计算机程序被处理器执行时实现上述方法的步骤。
9.本技术实施例提供的技术方案带来的有益效果是：本技术实施例的资源预下载方法由第一应用程序执行，第一应用程序既可以应用于资源加载程序，也可以应用于应用分发程序，可随时进行下载主体的切换，通过确定第二应用程序暂停下载资源并确定第一文件集合和第二应用程序对第一文件集合中各第一文件的下载记录，实现了第一应用程序和第二应用程序进行下载记录交互的目的，并且基于两个应用程序各自对第一文件的下载记录确定第一文件的处理策略，可避免不同的下载主体重复下载未下载或正在下载的文件，节省时间成本，也降低了下载的流量，降低下载带来的cdn带宽成本。
附图说明
10.为了更清楚地说明本技术实施例中的技术方案，下面将对本技术实施例描述中所需要使用的附图作简单地介绍。
11.图1为本技术实施例提供的资源的预下载系统的系统架构示意图；图2a为本技术实施例提供的一种资源的预下载方法的流程示意图；图2b为本技术实施例提供的一种资源加载程序作为下载主体执行的资源预下载方法的交互示意图；图2c为本技术实施例提供的一种应用分发程序作为下载主体执行的资源预下载方法的交互示意图；图3为本技术实施例提供的3种合并方式的示意图；图4为本技术实施例提供的一种资源加载程序作为下载主体执行的资源预下载方法的交互示意图；图5为本技术实施例提供的一种应用分发程序作为下载主体执行的资源预下载方法的交互示意图；图6为本技术实施例提供的一种应用于游戏资源的预下载场景下的交互示意图；图7为本技术实施例提供的一种资源的预下载装置的结构示意图；图8为本技术实施例提供的一种电子设备的结构示意图。
具体实施方式
12.下面结合本技术中的附图描述本技术的实施例。应理解，下面结合附图所阐述的
实施方式，是用于解释本技术实施例的技术方案的示例性描述，对本技术实施例的技术方案不构成限制。
13.本技术领域技术人员可以理解，除非特意声明，这里使用的单数形式
ꢀ“
一”、“一个”和“该”也可包括复数形式。应该进一步理解的是，本技术实施例所使用的术语“包括”以及“包含”是指相应特征可以实现为所呈现的特征、信息、数据、步骤、操作、元件和/或组件，但不排除实现为本技术领域所支持其他特征、信息、数据、步骤、操作、元件、组件和/或它们的组合等。应该理解，当我们称一个元件被“连接”或“耦接”到另一元件时，该一个元件可以直接连接或耦接到另一元件，也可以指该一个元件和另一元件通过中间元件建立连接关系。此外，这里使用的“连接”或
ꢀ“
耦接”可以包括无线连接或无线耦接。这里使用的术语“和/或”指示该术语所限定的项目中的至少一个，例如“a和/或b”可以实现为“a”，或者实现为“b”，或者实现为“a和b”。
14.为使本技术的目的、技术方案和优点更加清楚，下面将结合附图对本技术实施方式作进一步地详细描述。
15.首先对本技术涉及的几个名词进行介绍和解释：预下载：在应用程序发布新版本前，提前下载新版本的相关资源至终端，称之为预下载。通过预下载，能够在允许加载该资源的时间点，直接加载该提前下载好的资源进行应用程序的版本更新，相比在新版本发布后用户启动应用程序后才开始下载新版本的相关资源，可避免用户感知更新版本的等待时间。
16.渠道预下载：应用程序的厂商通过应用分发程序（即用于应用分发的程序）——例如应用商店，在应用程序的新版本发布前，对新版本的资源提前进行下载的行为，其下载的文件存储在应用分发程序的私有目录，也可以是外置存储的公有目录。
17.游戏内：指游戏应用程序的进程运行中，包括以下情形：1、游戏应用在终端的主界面运行；2、关闭游戏应用界面，但并未杀掉游戏进程。总之，运行在游戏进程的逻辑代码称为游戏内场景。
18.断点续传：指的是在下载或上传时，将下载或上传任务（一个文件或一个压缩包）划分为几个部分，每一个部分采用一个线程进行上传或下载，各线程可以并行执行，也可以依次执行，如果碰到网络故障，可以从已经上传或下载的部分开始继续上传下载未完成的部分，而没有必要从头开始上传下载，从而节省时间，提高速度。
19.文件合并：指2个或2个以上的文件，基于基本的文件操作包括：文件拼接、文件覆盖、文件裁剪等，而形成一个新的完整的文件的过程。在文件合并的过程中，主要涉及到待合并文件，和该文件本应处于完整文件的位置信息。在本技术实施例中，主要讨论的是2个文件间的合并，举例说明：比如文件1，开始位置为0，结束位置为100，代表着文件1处于完整文件的0至100字节的数据位置；文件2，开始位置为101，结束位置为200，代表文件2处于完整文件的101至200字节的数据位置。当执行文件合并时，根据2个文件的位置信息，将文件2拼接在文件1之后，形成一个的开始位置为0，结束位置为200的完整文件。
20.contentprovider共享数据更新通知机制：支持在多个应用中存储和读取数据。该机制建立在统一资源标识符（uniform resource identifier，uri）的基础之上，通过uri来把通知的发送者和接收者关联在一起的，该机制的通知注册中心是由contentservice服务
来扮演的，负责接收数据更新通知的类必须要继承contentobserver类。本技术提供的资源的预下载方法、装置、电子设备、计算机可读存储介质以及计算机程序产品，旨在解决现有技术的如上技术问题，使得用于加载所述资源的资源加载程序以及用于应用分发的应用分发程序都能够有机会进行资源的预下载，并且基于两个应用程序各自对第一文件的下载状态和下载进度进确定第一文件的处理策略，可避免不同的下载主体重复下载未下载或正在下载的文件，节省时间成本，也降低了下载的流量，降低下载带来的cdn带宽成本，并且本技术的资源加载程序仅在下载完去资源全部的文件且全部文件都通过校验的情况下才会加载资源，避免了相关技术应用分发程序在没有下载完全部文件时用户启动资源加载程序时，因为应用分发程序下载的文件不完整而导致交易不通过而重新文件的问题。
21.下面通过对几个示例性实施方式的描述，对本技术实施例的技术方案以及本技术的技术方案产生的技术效果进行说明。需要指出的是，下述实施方式之间可以相互参考、借鉴或结合，对于不同实施方式中相同的术语、相似的特征以及相似的实施步骤等，不再重复描述。
22.下面说明本技术实施例提供的资源的预下载系统。参见图1，图1是本技术实施例提供的资源的预下载系统的架构示意图，为实现支撑一个示例性应用，终端(示例性示出了终端400-1和终端400-2)通过网络300连接服务器200，网络300可以是广域网或者局域网，又或者是二者的组合，使用无线或有线链路实现数据传输。
23.终端(如终端400-1和终端400-2)，安装和运行有应用程序的客户端，用于在应用程序运行过程中，接收到服务器下发的更新通知，从服务器预下载应用程序对应的资源，并存储到本地存储空间(如移动终端的sd卡)。
24.终端(如终端400-1和终端400-2)中的应用程序至少有两个，一个用于加载该资源的应用程序（后续实施例简称为资源加载程序），另一个是用于应用分发的应用程序（后续实施例简称为应用分发程序），本技术实施例的应用分发程序，可以通俗地理解为应用商店，即用于下载、更新应用程序的程序。
25.本技术实施例的资源加载程序和应用分发程序均支持对资源进行预下载，将进行预下载的下载主体称之为第一应用程序，则另一个应用程序称之为第二应用程序，第一应用程序确定第二应用程序暂停下载资源，还确定第一文件集合以及第二应用程序对第一文件集合中各第一文件的下载记录，第一文件为资源中除第二文件集合以外的文件，第二文件集合中的第二文件为用于加载资源的资源加载程序已下载的文件；对于每个第一文件，确定第一应用程序对第一文件的下载记录，根据第一应用程序和第二应用程序各自对第一文件的下载记录，确定并执行第一文件的处理策略。
26.服务器200，用于在应用程序运行过程中，接收开发端上传的资源加载程序的资源，向安装有该应用程序的终端下发更新通知，以通知各终端该应用程序存在更新资源；同时，还用于接收下载主体发送的针对应用程序的资源的下载请求，将资源发送至发送下载请求的终端(如终端400-1和终端400-2)。
27.在一些实施例中，服务器200可以是独立的物理服务器，也可以是多个物理服务器构成的服务器集群或者分布式系统，还可以是提供云服务、云数据库、云计算、云函数、云存储、网络服务、云通信、中间件服务、域名服务、安全服务、内容分发网络(cdn，
contentdelivery network)、以及大数据和人工智能平台等基础云计算服务的云服务器。终端400可以是智能手机、平板电脑、笔记本电脑、台式计算机、智能音箱、智能手表等，但并不局限于此。终端以及服务器可以通过有线或无线通信方式进行直接或间接地连接，本技术实施例中不做限制。
28.本技术实施例可以借助于云技术(cloud technology)实现，云技术是指在广域网或局域网内将硬件、软件、网络等系列资源统一起来，实现数据的计算、储存、处理和共享的一种托管技术。
29.云技术是基于云计算商业模式应用的网络技术、信息技术、整合技术、管理平台技术、以及应用技术等的总称，可以组成资源池，按需所用，灵活便利。云计算技术将变成重要支撑。技术网络系统的后台服务需要大量的计算、存储资源。伴随着互联网行业的高度发展和应用，将来每个物品都有可能存在自己的识别标志，都需要传输到后台系统进行逻辑处理，不同程度级别的数据将会分开处理，各类行业数据皆需要强大的系统后盾支撑，可以通过云计算来实现。
30.本技术实施例中提供了一种资源的预下载方法，本技术实施例的预下载方法应用于第一应用程序，第一应用程序可以是资源加载程序，也可以是应用分发程序。以资源加载程序为游戏应用程序为例，该资源可以是游戏资源，可以理解的是，根据资源加载程序的应用类型的不同，该资源的类型也可以不同，本技术实施例除了游戏领域的资源，该资源还可以ui、动画或者业务文件等各个方面的文件。
31.如图2a所示，该资源的预下载方法包括以下步骤：s2011、确定第二应用程序暂停下载资源，确定第一文件集合以及第二应用程序对第一文件集合中各第一文件的下载记录。
32.本技术实施例的第一文件是指资源中除第二文件之外的文件，其中，第二文件是指资源加载程序已下载的文件，也就是说，无论本技术的执行主体是资源加载程序，还是应用分发程序，都需要确定资源加载程序已下载的第二文件，然后将资源的第二文件之外的文件作为第一文件。可以理解的是，本技术实施例的第一文件集合和第二文件集合中文件的数量之和为资源的所有文件的数量之和。
33.本技术实施例的下载记录可以包括下载状态和下载进度中的至少一种，其中，下载状态可以包括已下载、未下载以及下载中三种类型。
34.在一些实施例中，下载进度即文件下载的进度，下载进度的值的取值范围为0-100%，当下载进度为0时，表示未下载，当下载进度为100%时，表示已下载，当下载进度为0-100%之间的任意数时，表示下载中。也即，本技术实施例一个文件的下载记录可以仅包括下载进度。
35.在另一些实施例中，下载进度可以指下载状态为下载中时文件下载的进度，也即一个文件只有开始下载才会有下载进度，当一个文件未下载时，下载进度是0，可以视为没有下载进度。当文件的下载记录仅包括下载进度时，如果一个文件没有下载记录，或者下载记录为空，则表示该文件未开始下载。
36.应当理解的是，本技术实施例的已下载是指已下载一个文件的全部内容，例如，一个文件的大小为3000个字节，只有下载完全部的3000字节，才称之为为已下载该文件，当已开始下载一个文件，但没有下载一个文件的全部内容时，称之为下载中。当未开始下载文件
时，则该文件的下载状态称之为未下载，本技术一个文件在一个时刻的下载状态可以是未下载、下载中或者已下载。也就是说，本技术的第一文件，是指资源中资源加载程序未下载或者下载中的文件。
37.应当理解的是，当下载主体不同时，下载主体将下载的文件存储的位置也存在差异，比如下载主体为资源加载程序时，资源加载程序会将文件下载到自身的私有目录，也可能是某一公有目录（第一公有目录），当下载主体为应用分发程序时，应用分发程序会将文件下载到自身的私有目录，也可能是某一公有目录（第一公有目录），一般情况下，不同下载主体的私有目录是不同的，指定的公有目录也是存在差异的。
38.所以，如果本技术的下载主体也即第一应用程序是资源加载程序，那么资源加载程序根据自身已下载哪些文件，结合该资源需要下载的所有文件的文件信息，即可确定第一文件。
39.如果本技术的下载主体也即第一应用程序是应用分发程序，那么应用分发程序还需要向资源加载程序请求获得第二文件的文件信息或者第一文件信息。例如，在一些实施例中，资源加载程序可以向应用分发程序发送第二文件的文件信息，应用分发程序获得该资源需要下载的所有文件的文件信息，通过排除法确定第一文件；在另一些实施例中，资源加载程序可以先确定第一文件，然后直接告知应用分发程序。
40.本技术实施例之所以要确定第一文件，是因为最终资源都要存储在资源加载应用的预设存储位置并由资源加载程序加载该资源，所以是否需要下载文件，都要以资源加载应用是否已下载文件为依据。需要注意的是，当一个文件由应用分发程序下载，还需要将该文件移动至资源加载程序的预设存储位置，在移动到预设存储位置后，视为资源加载程序已下载该文件。也就意味着，本技术实施例无论下载主体为资源加载程序还是应用分发程序，都会跳过对资源加载程序已下载的文件的处理，从而提高资源的整体下载效率。例如，当第一应用程序为应用分发程序时，确定第一文件集合并对第一文件集合中的第一文件进行处理，也就意味着跳过了对第二文件的处理。
41.本技术实施例在确定第一文件集合时，还需要确定第二应用程序已经暂停下载资源，以保证一个时刻仅有一个下载主体，若第一应用程序确定第一文件集合前获知第二应用程序仍在下载资源，则会指示第二应用程序暂态下载资源，表示下载主体此时已切换为第一应用程序，由第一应用程序继续下载资源应用程序尚未下载完的文件，避免两个应用程序因同时下载文件导致的流量和终端存储空间的浪费，并且，确定第二应用程序暂停下载资源，也便于第一应用程序准确地确定下载断点，以进行断点续传。
42.在一些实施例中，第一应用程序可以向第二应用程序发送资源下载状态查询请求，资源下载状态查询请求用于请求查询第二应用程序是否正在下载资源，第二应用程序响应于资源下载状态查询请求，向第一应用程序返回用于表征第二应用程序是否正在下载资源的状态码，其中第一状态码用于表征第二应用程序正在下载资源，第二状态码用于表征第二应用程序未下载资源。
43.在一些实施例中，第一应用程序可以通过contenprovider机制向第二应用程序发送资源下载状态查询请求。
44.在一些实施例中，第一应用程序可以通过服务（service）组件查询第二应用程序是否正在下载资源。服务（service）是android系统中的重要组件之一。服务主要用于两个
目的：后台运行和跨进程访问。通过启动一个服务，可以在不显示界面的前提下在后台运行指定的任务，这样可以不影响终端执行其他任务。
45.具体地，本技术实施例的第一应用程序可以通过服务（service）组件查询第二应用程序是否正在下载资源，可以包括以下步骤：第二应用程序创建service组件；第二应用程序在service组件的onbind方法返回一个可通信的ibinder对象，该ibinder对象中包括第二应用程序是否正在下载资源的信息；第一应用程序在绑定service组件后，在onserviceconnected方法中获得该ibinder对象，调用该ibinder对象，确定第二应用程序是否正在下载资源。
46.s2012、对于每个第一文件，确定第一应用程序对第一文件的下载记录，根据第一应用程序和第二应用程序各自对第一文件的下载记录，确定并执行第一文件的处理策略。
47.对于每个第一文件，由于本技术的第一应用程序既可以是资源加载程序，也可以是应用分发程序，当第一应用程序为资源加载程序时，显然，该第一应用程序对于第一文件的下载状态只能是下载中或者未下载，而第二应用程序对于第一文件的下载状态可能是已下载、下载中或者未下载。
48.例如，某天的第一时刻应用分发程序开始下载资源，到第二时刻时，已下载3个文件：文件1、文件2和文件3，下载中的文件有2个：文件4和文件5，未下载的文件有1个：文件6，到第三时刻时资源加载程序启动，并开始执行本技术的预下载方法，此时资源加载程序尚未下载任何一个文件，其指示应用分发程序停止下载资源，然后确定每个文件（因为所有文件都是第一文件）的下载状态，就会发现第一文件的下载状态有的是已下载、有的是下载中，有的则是未下载。
49.当第一应用程序为应用分发程序时，第二应用程序为资源加载程序，显然，第二应用程序对第一文件的下载状态可能是下载中，也可能是未下载，而第一应用程序对第一文件的下载状态，可能是未下载、也可能是下载中，但不会是已下载，这是因为所有的文件都会汇总到资源加载程序的预设存储位置，由于应用分发程序先要确定资源加载程序已下载哪些文件，所以只要是资源加载程序尚未下载完成的文件，应用分发程序也必然没有下载完成。
50.本技术实施例对于每个第一文件，根据自身（也即第一应用程序）以及第二应用程序各自对第一文件的下载记录确定第一文件的处理策略，能够避免因为两个应用程序缺少交互而导致重复下载第一文件的问题。应当理解的是，本技术的重复下载既包括下载第二应用程序已下载的第一文件的情形，也包括在第二应用程序下载第一文件的一部分时，下载第一文件中第二应用程序已下载的部分的情形。
51.本技术实施例可以预先获得资源中各文件的下载地址，从而在处理策略为对文件进行下载时，基于文件的下载地址进行下载。
52.本技术实施例的下载主体无论是资源加载程序，还是应用分发程序，都支持单线程或者多线程下载。在多线程下载模式下，需要对文件进行随机读写，多个线程同时往文件写数据时，每个线程写入字节数据到文件的范围是根据一定规则均分文件长度后确定的。
53.在一些实施例中，在每个线程下载文件过程中，还需要记录文件的下载进度到磁盘。下载进度的主要内容包括：
开始项：当前线程写入的起始字节位置；预计结束项：当前线程下载完成的字节位置；实际结束项：当前线程实际下载的字节的结束位置。
54.可以理解的是，下载进度的实际结束项是随着下载步骤的进行，实时更新的。
55.需要说明的是，本技术实施例的预下载方法由于既可以应用于资源加载程序，也可以应用于应用分发程序，也就意味着存在一些特殊的情况，某个文件首先由资源加载程序进行下载，下载了一部分后，又由应用分发程序进行下载，又下载一部分后，又切换为资源加载程序进行下载等等类似的切换下载主体的操作，但无论一个时刻的下载主体是哪个应用程序，都适用于本技术实施例的预下载方法，本技术可实现任意时刻切换下载主体且不会重复下载文件的效果。
56.本技术实施例在执行第一文件的处理策略时，需要实时更新第一文件的下载记录，从而为切换下载主体时，新的下载主体能够根据前一个下载主体对第一文件的下载记录确定新的处理策略。
57.请参见图2b，其示例性地示出了本技术实施例在第一应用程序为资源加载程序时的预下载方法的交互示意图，如图所示，包括：s2021、确定资源的所有文件的文件信息以及第二文件集合的文件信息；s2022、根据资源的所有文件的文件信息以及第二文件集合的文件信息，确定第一文件集合的文件信息；s2023、根据第一文件集合的文件信息，指示第二应用程序——应用分发程序暂停下载资源并返回应用分发程序对第一文件集合中各第一文件的下载记录；s2024、确定资源加载程序自身对第一文件集合中各第一文件的下载记录；s2025、对于每个第一文件，确定第一应用程序对第一文件的下载记录，根据第一应用程序和第二应用程序各自对第一文件的下载记录，确定并执行第一文件的处理策略。
58.需要说明的是，本技术实施例的下载主体为资源加载程序，首先通过确定资源的所有文件的文件信息以及已下载的文件（第二文件集合）的文件信息，确定第一文件集合的文件信息，向第二应用程序指示暂停下载资源并返回第一文件集合中各第一文件的下载记录，再结合自身对各第一文件的下载记录，确定并执行第一文件的处理策略。本技术实施例的步骤s2021~s2023的先后顺序不作具体限定。
59.需要说明的是，上述的步骤s2023之前还可以包括第一应用程序查询第二应用程序是否正在下载资源的步骤，若第二应用程序正在下载资源，则执行步骤s2031，若第二应用程序没有下载加载资源，则仅需要指示第二应用程序返回第一文件集合中各第一文件的下载记录。
60.请参见图2c，其示例性地示出了本技术实施例在第一应用程序为应用分发程序时的预下载方法的交互示意图，如图所示，包括：s2031、指示第二应用程序——资源加载程序暂停下载资源，并返回第一文件集合中各第一文件的下载记录；s2032、确定应用分发程序自身对各第一文件的下载记录；s2033、对于每个第一文件，确定第一应用程序对第一文件的下载记录，根据第一应用程序和第二应用程序各自对第一文件的下载记录，确定并执行第一文件的处理策略。
61.本技术实施例的步骤s2031~s2033的先后顺序不作具体限定。
62.需要说明的是，上述的步骤s2031之前还可以包括第一应用程序查询第二应用程序是否正在下载资源的步骤，若第二应用程序正在下载资源，则执行步骤s2031，若第二应用程序没有下载加载资源，则仅需要指示第二应用程序返回第一文件集合中各第一文件的下载记录。
63.在一些实施例中步骤s2031也可以是：指示资源加载程序暂停下载资源，并返回第二文件集合的文件信息；确定资源的所有文件的文件信息；根据所有文件的文件信息以及第二文件集合的文件信息，确定第一文件集合的文件信息；指示资源加载程序返回第一文件集合中各第一文件的下载记录。需要说明的是，在上述图2b和2c对应的实施例中，下载主体还可以在执行第一文件的处理策略前，例如，在一些实施例中，文件信息中包括文件的文件标识和下载地址。从而下载主体在获得文件信息时获知文件的下载地址。
64.在上述各实施例的基础上，作为一种可选实施例，下载记录包括下载状态，由上述实施例可知，本技术实施例的下载状态包括已下载、未下载以及下载中三种情形，具体的定义可以参考上述实施例，例如步骤s2011、s2012等的记载，本技术实施例不再赘述。
65.根据第一应用程序和第二应用程序各自对第一文件的下载记录，确定第一文件的处理策略，包括：根据第一应用程序和第二应用程序对第一文件的下载状态均为未下载，确定第一文件的处理策略为下载第一文件。
66.对于两个应用程序均未开始下载的第一文件，则第一应用程序对该第一文件的处理策略为下载该第一文件。在执行处理策略时，第一应用程序在该第一文件的下载记录中记录下载状态为下载中，并且实时更新该第一文件的下载进度。
67.需要注意的是，无论下载主体也即第一应用程序，是资源加载程序还是应用分发程序，只要确定两个程序都没有下载某一第一文件，那么都会直接下载该第一文件，并更新该第一文件的下载记录，以供后续切换下载主体时，能够通过下载记录确定该第一文件的下载状态和下载进度，以确定处理策略。
68.本技术实施例的第一应用程序在下载第一文件时，将下载的第一文件实时存储在第一应用程序自身预设的存储位置，该预设的存储位置可以是第一应用程序的私有目录，也可以是预设的公有目录。
69.需要注意的是，第一应用程序在下载第一文件时，会实时更新第一文件的下载进度，并且当下载进度达到100%，即确定已下载了第一文件的全部内容时，那么还需要将第一文件的下载状态由下载中更新为已下载。
70.在上述各实施例的基础上，作为一种可选实施例，下载记录包括下载状态和下载进度中的至少一种。由上述实施例可知，本技术实施例的下载状态包括已下载、未下载以及下载中三种情形，具体的定义可以参考上述实施例，例如步骤s2011、s2012等的记载，本技术实施例不再赘述。
71.根据第一应用程序和第二应用程序各自对第一文件的下载记录，确定第一文件的
处理策略，包括：根据第一应用程序对第一文件的下载状态为下载中，且第二应用程序对第一文件的下载状态为未下载，确定第一文件的处理策略为根据第一应用程序对第一文件的下载进度继续下载第一文件。
72.也就是说，无论第一应用程序为资源加载程序还是应用分发程序，当确定自身对第一文件的下载状态为下载中，但第二应用并未开始下载该第一文件，则继续根据自身对第一文件的下载进度下载第一文件。
73.例如，某第一文件的总字节数为100，第一应用程序下载第一文件的下载进度为0-40%，即已下载了第1-40个字节，而第二应用程序并未下载该第一文件，则第一应用程序从第41个字节开始继续下载该第一文件。
74.需要注意的是，第一应用程序在继续下载第一文件时，会实时更新第一文件的下载进度，并且当下载进度达到100%，即确定已下载了第一文件的全部内容时，还需要将第一文件的下载状态由下载中更新为已下载。
75.在上述各实施例的基础上，作为一种可选实施例，本技术实施例确定第二应用程序暂停下载资源，确定第一文件集合以及第二应用程序对第一文件集合中各第一文件的下载记录，之前还包括：获得资源的配置信息，配置信息包括资源中各文件的文件标识。
76.当第一应用程序为资源加载程序时，可以通过向资源加载程序对应的服务器获得资源的配置信息。
77.当第一应用程序为应用分发程序时，可以通过向应用分发程序对应的服务器获得资源的配置信息。
78.应当理解的是，资源的开发者创建好资源后，会将资源上传至资源加载程序对应的服务器以及应用分发程序对应的服务器。
79.在一些实施例中，配置信息包括了资源中各文件的文件标识和下载地址。
80.在一些实施例中，文件标识可以包括文件名、文件的信息摘要等。
81.在一些实施例中，文件的信息摘要可以通过md5信息摘要算法（md5 message-digest algorithm）确定。
82.本技术实施例确定第二应用程序对第一文件集合中各第一文件的下载记录，包括：利用contentprovider机制，根据各第一文件的文件标识，向第二应用程序确定第二应用程序对相应标识的第一文件的下载记录。
83.需要说明的是，第一应用程序和第二应用程序的通信由于处于不同进程，所以属于进程间通信的范围，通信所采取的方式是contentprovider机制，它可以由资源加载程序发起向应用分发信息获取文件记录，也可以由应用分发信息发起向资源加载程序获取文件记录。
84.具体地，第二应用程序可提供一些第一文件的下载记录，第一应用程序需要获得这些第一文件的下载记录，首先，创建一个sqlite数据库，将第一文件的下载记录存入该数据库中。
85.之后，创建一个provider类，该provider类继承contentprovider。
86.本技术实施例可以实现contentprovider的六个抽象方法。在oncreate方法中，用于创建一个contentprovider，在这里对数据库进行初始化操作，而gettype方法中用来返回uri请求所对应的mime类型，而后剩下的四个方法中也就是对应的crud操作，也就是数据的增删改查功能。进一步地，还需要在androidmanifest中注册上述contentprovider，注册过程涉及创建contentprovider的三种属性：authorities:这个属性是contentprovider的唯一标识，通过这个属性外部应用才能访问contentprovider，也就是说authorities是唯一的。而且这个authorities也是uri里面的authorities；export:设为true的时候表示当前contentprovider可以被其它应用使用。任何应用可以使用provider通过uri来获得它，也可以通过相应的权限来使用provider。设为false的时候表示当前contentprovider不能被其它应用使用；permission: 为contentprovider设置权限从而避免任何应用都能访问contentprovider。接下来设置第二应用程序的权限，对于这个应用程序只在创建一个空白的activity启动即可，在这个activity里面不需要做任何的操作。
87.第一应用程序获取contentprovider中数据的流程如下：创建一个与第一文件关联的实体类；基于contentprovider编辑数据的方法，在activity中使用这些方法即可。
88.在上述各实施例的基础上，作为一种可选实施例，下载主体也即第一应用程序为资源加载程序；下载记录包括下载状态和下载进度中的至少一种；根据第一应用程序和第二应用程序各自对第一文件的下载记录，确定第一文件的处理策略，包括：根据第一应用程序和第二应用程序对第一文件的下载状态均为下载中，确定第一文件的处理策略为：根据第一应用程序和第二应用程序各自对第一文件的下载进度，对第一应用程序和第二应用程序各自对第一文件下载的部分进行合并，获得并保存第一文件的下载部分的合并结果；继续下载第一文件中下载部分的合并结果之外的部分。
89.需要说明的是，当第一应用程序和第二应用程序对于一个第一文件的下载状态均为下载中时，则需要考虑两个应用程序对该第一文件的下载进度，基于两个应用程序对该第一文件的下载进度，对两个应用程序各自对对第一文件下载的部分进行合并，从而获得第一文件的下载部分的合并结果。
90.在一些实施例中，第一应用程序对第一文件下载的部分进行合并时，首先将第二应用程序下载的部分移动至第一应用程序的预设存储位置，使得第二应用程序的预设存储位置不存在该第一文件下载的部分，然后第一应用程序将自身下载的部分和移动的第二应用程序下载的部分进行合并，合并的具体方式包括拼接、覆盖和裁剪，请参见图3，其示例性地示出了本技术实施例提供的3种合并方式的示意图，如图所示：
拼接是最容易理解的一种合并方式，即一个应用程序下载的部分的末尾字段的下一个字段即为另一个应用程序下单部分的起始字段，例如，某第一文件的总字节数为100，第一应用程序下载第一文件的下载进度为0-30%，即下载了第1-30个字节，如图中的文件1，第二应用程序下载该第一文件的下载进度为30-60%，即下载到第31-60个字节，如图中的文件2那么就将两个下载的部分进行合并，获得的合并结果为第一文件的0-60%的部分，也即第一文件的第1-60个字节，如图中的文件3，第一应用程序继续从第61个字节开始下载。
91.覆盖，即一个应用程序下载的部分全部包含了另一个应用程序下载的部分，则将一个应用程序下载的部分覆盖另一个应用程序下载的部分，例如，某第一文件的总字节数为100，第一应用程序下载第一文件的下载进度为0-60%，即下载了第1-60个字节，如图中的文件4，第二应用程序下载该第一文件的下载进度为0-30%，即下载到第1-30个字节，如图中的文件5，那么就将第一应用程序下载的部分：第1-60个字节覆盖第二应用程序下载的部分：第1-30个字节，图3中文件5的进度由于完全被文件4覆盖，所以文件5的全部区域增设了填充斜线，获得的合并结果为第一文件的0-60%的部分，也即第一文件的第1-60个字节，如图中的文件6，第一应用程序继续从第61个字节开始下载。
92.裁剪，即一个应用程序下载的部分和另一个应用程序下载的部分存在局部的重合，则需要先确定两个应用程序各自没有重合的部分，然后再与重合的部分按照字节的顺序进行拼接，例如，某第一文件的总字节数为100，第一应用程序下载第一文件的下载进度为0-40%，即下载了第1-40个字节，如图中的文件7，第二应用程序下载该第一文件的下载进度为30-60%，即下载到第30-60个字节，如图中的文件8，可确定局部重合的内容为第30-40个字节，非重合的部分为第1-29个字节以及第41-60个字节，图3中针对文件7和文件8重合的内容，在文件8上增设了填充斜线，按照字节的顺序，将文件8中第30-40的字节删除，然后将文件7和文件8的剩余内容：第41-60字节进行拼接，得到第1-60个字节，即图中的文件9，第一应用程序继续从第61个字节开始下载。
93.需要注意的是，第一应用程序在继续下载第一文件时，会实时更新第一文件的下载进度，并且当下载进度达到100%，即确定已下载了第一文件的全部内容时，那么还需要将第一文件的下载状态由下载中更新为已下载。
94.在上述各实施例的基础上，作为一种可选实施例，本技术实施例出于方便理解的目的，将第一应用程序对第一文件下载的部分简称为第一部分，将第二应用程序对第一文件下载的部分简称为第二部分。
95.根据第一应用程序和第二应用程序各自对第一文件的下载进度，对第一应用程序和第二应用程序各自对第一文件下载的部分进行合并，获得并保存第一文件的合并部分，包括：a）若第一部分和第二部分不存在重合的内容，则根据第一应用程序和第二应用程序各自对第一文件的下载进度，将第一部分和第二部分进行拼接，获得并保存第一文件的下载部分的合并结果；b）若第一部分和第二部分存在重合的内容，则删除第一部分和第二部分中的一个部分的重合的内容，得到一个部分的剩余内容；根据第一应用程序和第二应用程序各自对第一文件的下载进度，将一个部分的剩余内容与另一个部分进行拼接，获得并保存第一文件的下载部分的合并结果。
96.应当理解的是，上述a方式即为拼接方式，b方式即为覆盖或者裁剪方式。
97.在上述各实施例的基础上，作为一种可选实施例，第一应用程序为资源加载程序；下载记录包括下载状态；根据第一应用程序和第二应用程序各自对第一文件的下载记录，确定第一文件的处理策略，包括：根据第一应用程序对第一文件的下载状态为未下载，第二应用程序对第一文件的下载状态为已下载，确定第一文件的处理策略为：将第一文件已下载的第一文件移动至第一应用程序的预设存储位置。
98.当下载主体也即第一应用程序为资源加载程序时，如果一个第一文件资源加载程序没有下载，而应用分发程序已下载，则资源加载程序不需要重新下载该第一文件，而是将应用分发程序下载的该第一文件移动至第一应用程序的预设存储位置，本技术实施例避免了文件的重复下载，提升了资源加载程序获得资源的文件的效率。
99.在上述各实施例的基础上，作为一种可选实施例，第一应用程序为资源加载程序；下载记录包括下载状态和下载进度；根据第一应用程序和第二应用程序各自对第一文件的下载记录，确定第一文件的处理策略，包括：根据第一应用程序对第一文件的下载状态为未下载，第二应用程序对第一文件的下载状态为下载中，确定第一文件的处理策略为：将第二应用程序下载的第一文件的部分移动至第一应用程序的预设存储位置；根据第二应用程序对第一文件的下载进度继续下载第一文件。
100.当下载主体也即第一应用程序为资源加载程序时，如果一个第一文件资源加载程序没有下载，而应用分发程序已下载了一部分，则资源加载程序不需要重头下载该第一文件，而是将应用分发程序对该第一文件下载的部分移动至第一应用程序的预设存储位置，然后再基于应用分发程序对第一文件的下载进度继续下载第一文件。本技术实施例避免了文件的重复下载，提升了资源加载程序获得资源的文件的效率。
101.应当理解的是，当资源加载程序继续下载第一文件时，会将下载的内容下载在预设存储位置，具体地，资源加载程序会根据第一文件占用的存储空间的大小，确定预设存储位置的存储区间，比如该第一文件的存储区间为第10000-12000字节位，当把应用分发程序下载的部分存入该存储区间后占用了第10000-11000字节为，那么将把该第一文件继续下载的内容从11001字节开始存储，直至存储至第12000字节位。
102.在上述各实施例的基础上，作为一种可选实施例，确定至少一个第一文件，包括：根据各文件的下载记录，确定第二文件集合；从配置信息中根据第二文件集合中各第二文件的文件标识，确定第一文件集合。
103.在一些实施例中，当第一应用程序为资源加载程序时，资源加载程序确定第一文件集合并不需要和应用分发程序进行交互，只需要从自身用于存储第二文件集合的预设存储位置，根据各文件的下载记录，确定已下载的各个第二文件的文件标识，然后通过排除法，从配置信息中将第二文件以外的文件均作为第一文件。
104.在另一些实施例中，本技术实施例的资源加载程序在下载文件时会更新文件的下载记录，而下载记录中包括下载状态，资源加载程序也可以根据各文件的下载状态为已下
载，直接确定第二文件集合。
105.在上述各实施例的基础上，作为一种可选实施例，当第一应用程序为资源加载程序时，确定并执行第一文件的处理策略，之后还包括：对已下载的第一文件进行完整性和准确性校验；若校验通过，则保留第一文件；若校验不通过，则删除第一文件并重新下载第一文件。
106.本技术的资源加载程序在每下载完一个第一文件后，都会对第一文件进行完整性和准确性校验，完整性校验即校验该第一文件是否下载的是完整内容，准确性校验，则是校验该第一文件的数据是否规范，并对错误的信息进行相应的逻辑处理，例如，非空判断、值是否在枚举/数据字典范围内、数据是否满足相关的正则表达式规则等等。
107.如果第一文件通过完整性和准确性校验，那么将保留该第一文件，将该第一文件的下载状态更新为已下载，并在下载完资源的所有文件后，加载资源。如果第一文件没有通过完整性和准确性校验中的任意一种校验，则删除该第一文件，并重新下载该第一文件，在重新下载该第一文件时，将该第一文件的下载状态更新为下载中，并更新下载进度。
108.在相关技术中，应用分发程序下载资源时，如果资源尚未下载完用户就开启资源加载程序，会因为应用分发程序下载的资源不完整而导致校验不通过，进而应用分发程序重新下载文件，造成了流量的浪费，为了解决该问题，本技术的资源加载程序只有在确定已下载资源的全部文件，且全部文件均校验通过，则加载资源。
109.在上述各实施例的基础上，作为一种可选实施例，当下载主体为资源加载程序时，具体由资源加载程序中的目标sdk执行。
110.需要说明的是，本技术实施例的目标sdk是资源加载程序内置的一种sdk。当资源加载程序启动时，资源加载程序初始化目标sdk，目标sdk向资源加载程序的服务器拉取资源的配置信息。
111.在一些实施例中，目标sdk只有在满足以下任一个条件时，才确定指示第二应用程序暂停下载资源，确定第一文件集合以及第二应用程序对第一文件集合中各第一文件的下载记录。本技术实施例的条件包括：条件1：第一应用程序调用目标sdk；条件2：第二应用程序调用目标sdk；条件3：目标sdk感知到第一应用程序处于对所在的终端负荷小于预设阈值的运行状态。
112.从上述三种条件可以看出，当目标sdk被第一应用程序或者第二应用程序调用时，开始指示第二应用程序暂停下载资源，确定第一文件集合以及第二应用程序对第一文件集合中各第一文件的下载记录，此外，目标sdk也可以感知资源加载程序运行时终端的负荷，根据负荷大小自主开始指示第二应用程序暂停下载资源，确定第一文件集合以及第二应用程序对第一文件集合中各第一文件的下载记录。
113.在一些实施例中，本技术实施例的资源加载程序调用目标sdk的时机可以是资源加载程序的主进程检测到当前程序运行的场景为非核心场景或者对终端性能、带宽流量要求不高的场景，以资源加载程序为游戏类应用程序为例，当资源加载程序当前运行的场景为游戏大厅、游戏商店等静态虚拟物体较多的场景时，则确定处于非核心场景，也是对终端
性能、带宽流量要求不高的场景。
114.在一些实施例中，资源加载程序内置了服务接口，供其他进程进行绑定通信，当资源加载程序在终端没有运行，或者终端负荷较小时，其他进程，比如第二应用程序就可以通过绑定服务接口，调用目标sdk。
115.需要注意的是，在一些实施例中，目标sdk可以感知第一应用程序当前运行的场景或者感知终端的负荷，当感知到第一应用程序处于对所在的终端负荷小于预设阈值的运行状态，则确定第二应用程序暂停下载资源，确定第一文件集合以及第二应用程序对第一文件集合中各第一文件的下载记录。
116.在一些实施例中，目标sdk感知到第一应用程序处于对所在的终端负荷小于预设阈值的运行状态时，开始下载资源，当感知到第一应用程序不再处于对所在的终端负荷小于预设阈值的运行状态时，则自动暂停下载资源，从而降低终端负荷的峰值。
117.请参见图4，其示例性地示出了本技术实施例的第一应用程序为资源加载程序时的交互示意图，如图所示，该交互流程包括：s401、用户在终端上点击资源加载程序的图标，打开资源加载程序，资源加载程序在初始化阶段，初始化目标sdk。在初始化过程中，目标sdk向资源加载程序的服务器拉取资源的配置信息，配置信息包括资源的各个文件的标识和下载地址；s402、资源加载程序的服务器向目标sdk返回资源的配置信息；s403、目标sdk启动预下载，目标sdk会过滤资源加载程序的私有目录中已经存在的下载完成的文件（也即第二文件），只下载未开始下载或者下载了一部分的文件（即第一文件）。
118.s404、通过contentprovider机制，向应用分发程序获取第一文件的下载记录，对于每个第一文件，根据应用分发程序和资源加载程序对该第一文件的下载记录，可以分为如下几个情况：情况一：应用分发程序未下载该第一文件：目标sdk直接开启该第一文件的下载进程，或者，如果目标sdk已经将该第一文件下载了一部分，此时开启断点续传，根据该第一文件的下载进度继续下载后续内容。
119.情况二：应用分发程序已经下载该第一文件，目标sdk通过contentprovider机制，将文件搬迁到资源加载程序的私有目录，并在校验通过后保留。
120.情况三：应用分发程序已下载该第一文件的一部分，目标sdk通过contentprovider机制，将应用分发程序已下载该第一文件的一部分，搬迁到资源加载程序的私有目录，同时也获知应用分发程序对该第一文件的下载进度。此时，目标sdk根据资源加载程序是否开始预下载该第一文件，分如下情况讨论：情况一、资源加载程序已经开始预下载该第一文件：根据资源加载程序和应用分发程序对该第一文件的下载进度进行文件合并，合并完成后，在新文件的最新断点处继续下载。
121.情况二、资源加载程序还未开始预下载该文件：直接在应用分发程序的下载进度的基础上进行断点续传，继续下载断点后的字节数据并写入到文件中。
122.在上述各实施例的基础上，当下载主体也即第一应用程序为应用分发程序时，根据第一应用程序和第二应用程序各自对第一文件的下载记录，确定第一文件的处理策略，
包括：根据第二应用程序对第一文件的下载状态均为下载中，确定第一文件的处理策略为：若第一应用程序对第一文件的下载进度不大于第二应用程序对第一文件的下载进度，则删除第一应用程序对第一文件下载的部分，根据第二应用程序对第一文件的下载进度继续下载第一文件；若第一应用程序对第一文件的下载进度大于第二应用程序对第一文件的下载进度，根据第一应用程序对第一文件的下载进度继续下载第一文件。
123.当下载主体为应用分发程序时，如果对于一个第一文件，两个应用都下载了该第一文件的部分，则通过比对两个应用程序对该第一文件的下载进度的大小，来确定该第一文件的处理策略。
124.例如，若某第一文件的总字节数据大小为200字节且资源加载程序下载进度为第1-140字节的数据，如果应用分发程序下载的进度小于140字节，比如为第1-100字节，那么应用分发程序就删除自己下载的该第一文件的部分，然后从第141字节开始继续下载；如果应用分发程序下载的进度大于140字节，比如为第1-150字节，那么应用分发程序就删除自己下载的该第一文件的部分，然后从第151字节开始继续下载。
125.需要注意的是，第一应用程序在下载第一文件时，会实时更新第一文件的下载进度，并且当下载进度达到100%，即确定已下载了第一文件的全部内容时，那么还需要将第一文件的下载状态由下载中更新为已下载。
126.在上述各实施例的基础上，当下载主体也即第一应用程序为应用分发程序时，确定第一文件集合以及第二应用程序对第一文件集合中各第一文件的下载记录，包括：利用contentprovider机制，向第二应用程序发送查询请求，查询请求包括资源的至少一个文件的文件标识，查询请求用于请求相应文件标识的文件的下载记录；根据第二应用程序返回的相应文件标识的文件的下载记录，确定第一文件集合以及第二应用程序对第一文件集合中各第一文件的下载记录。
127.本技术实施例的应用分发程序，由于预先获得了资源的配置信息，所以利用contentprovider机制向第二应用程序——资源加载程序发送查询请求，查询请求包括资源的至少一个文件的文件标识，查询请求用于请求资源加载程序返回相应文件标识的文件的下载记录，由于下载记录中包括了资源加载程序对各文件的下载状态，所以基于资源加载程序返回的相应文件标识的文件的下载记录，就可以知道哪些文件是资源加载程序已下载的，哪些是资源加载程序下载中或者未下载的，从而确定第一文件集合及第二应用程序对第一文件集合中各第一文件的下载记录。
128.请参见图5，其示例性地示出了本技术实施例的第一应用程序为应用分发程序时的交互示意图，如图所示，该交互流程包括：s501、资源开发人员将资源的配置信息上传至应用分发程序的服务器；s502、应用分发程序感知到终端负荷小于预设阈值时，应用分发程序向应用分发程序的服务器获取配置信息；s503、应用分发程序遍历配置信息，向资源加载程序的目标sdk查询每个文件的下载记录，假设当前遍历到的这个文件为文件a（文件列表中其他文件也都如文件a的说明处
理a）。根据目标sdk返回的文件a的不同下载状态，可以分为以下3种情况来讨论：a.文件a已经在资源加载程序中下载完成：应用分发程序直接跳过此文件的预下载；b.文件a在资源加载程序中并未开启下载：应用分发程序直接开启对文件a的下载，此时的下载可以是应用分发程序对文件a断点续传，即继续下载应用分发程序上次没有下载完成的文件a。
129.c.文件a在资源加载程序中下载到一部分：应用分发程序根据返回的文件下载记录，开启断点续传，下载断点后的文件内容，进一步包括两种情况：c1.若第一应用程序对第一文件的下载进度不大于第二应用程序对第一文件的下载进度，则删除第一应用程序对第一文件下载的部分，根据第二应用程序对第一文件的下载进度继续下载该第一文件；c2.若第一应用程序对第一文件的下载进度大于第二应用程序对第一文件的下载进度，根据第一应用程序对第一文件的下载进度继续下载第一文件。
130.需要说明的是，本技术实施例应用分发程序能够感知终端的运行负荷，从而在感知到终端的运行负荷小于预设阈值时，开始作为第一应用程序执行资源的预下载方法。
131.在一些实施例中，考虑到资源最终都由资源加载程序所使用（即加载），当应用分发程序感知到第一应用程序正在下载资源时，即使感知到终端的运行负荷小于预设阈值，也不会指示第一应用程序暂停下载资源，而是等待第一应用程序自主暂停下载资源后，才会开启足矣的预下载流程，这种方式能够减少资源加载程序移动文件的工作量，从而提升资源的预下载效率。
132.请参见图6，其示例性地示出了本技术应用于游戏资源的预下载场景的架构示意图，也即，本技术实施例的资源为游戏资源，资源加载程序为一款游戏应用程序，在一些实施例中，资源加载程序也可以兼具运行游戏功能的非游戏类应用程序，例如聊天类应用程序、音视频播放类应用程序、新闻资讯类应用程序、浏览器类应用程序等等。
133.本技术实施例的系统架构涉及游戏性能改进（game performance amelioration，gpa）平台601，gpa平台601聚焦对游戏的性能优化工作，通过跟各个终端制造商合作，建立统一的性能优化方案。gpa通过对游戏场景的深入分析，上层和各游戏统一对接，底层和不同的厂商进行对接，进而实现了统一的游戏性能解决方案。
134.在本技术实施例中，gpa平台601能够根据玩家对画质、帧率提出的更高要求，定期或不定期地更新游戏的资源，以满足玩家对性能体验的诉求。gpa平台601在研发出游戏的新的资源后，将资源分别发放至游戏服务器603和商店服务器604。游戏服务器603是用于向游戏程序6021提供服务的服务器，具体的服务可以包括游戏版本更新、网络接入、游戏数据加载等等。商店服务器604供终端使用者下载、更新应用程序，更新应用程序包括了更新应用程序（例如游戏程序6021）的资源，在一些实施例中，通过商店服务器604更新游戏的资源还可以向玩家提供个性化的奖励。
135.玩家使用的终端602至少装载了该游戏程序6021的客户端和应用分发程序6022——应用商店的客户端。在本技术实施例中，为了描述方便，该资源示例性地包括2个文件：文件1和文件2，首个下载主体为游戏程序，则整体的预下载流程可以包括：游戏程序6021从游戏服务器603获得资源的配置信息，配置信息包括文件1和文件
2的文件标识以及在资源数据库604的下载地址；游戏程序6021确定文件1和文件2为第一文件，确定应用分发程序6022暂停下载资源并确定应用分发程序6022对第一文件集合中各第一文件的下载记录，显然，此时应用分发程序也没有下载这两个文件；游戏程序6021开始同时下载文件1和文件2，创建文件1和文件2的下载记录，随着下载文件1和文件2的进行，实时更新文件1和文件2的下载进度；游戏程序6021由于被用户关闭，停止下载文件1和文件2，在停止下载文件1时的下载进度为50%，而文件2的下载进度为30%；过了一段时间后，应用分发程序6022启动预下载流程，应用分发程序6022从商店服务器604获得资源的配置信息，配置信息包括文件1和文件2的文件标识以及下载地址；应用分发程序6022指示游戏程序6021暂停下载资源，并确定游戏程序6021尚未下载完成任何一个文件，应用分发程序6022对于文件1，从下载进度50%开始继续下载，对于文件1，从下载进度30%开始继续下载；应用分发程序6022由于某些原因停止下载文件1和文件2，在停止下载文件1时的下载进度为70%，而文件2的下载进度为100%；过了一段时间后，游戏程序6021启动预下载流程，游戏程序6021指示应用分发程序6022暂停下载资源对于文件1，先将应用分发程序6022对文件1下载的部分移动至预设存储位置，然后和自身对文件1下载的部分进行合并，获得下载进度为70%的文件，然后从下载进度70%开始继续下载，游戏程序6021对于文件2，直接将文件2移动至预设存储位置；过了一段时间后，应用分发程序6022再次切换为下载主体，指示游戏程序6021暂停下载资源对于文件1，此时游戏程序6021下载文件1的进度为90%，应用分发程序从90%开始继续下载至完成；过了一段时间后，游戏程序6021又切换为下载主体，将应用分发程序下载的第一文件的部分：进度由90%-100%的数据内容移动到自身预设的存储位置，然后将上一次下载的第一文件的部分进行合并，获得完整的第一文件，游戏程序对第一文件和第二文件进行校验，当校验通过后，加载游戏资源，使玩家能够及时体验到游戏的新版本。
136.游戏程序6021在玩家游玩新版本的游戏时，实时采集终端的运行数据，例如帧率、cpu占有率、游戏时长等等，在空闲时将运行数据反馈至gpa平台601，供gpa平台601的运营人员根据负荷信息进一步优化游戏程序6021。
137.本技术实施例提供了一种资源的预下载装置，该装置应用于第一应用程序，资源包括至少一个文件，如图7所示，该资源的预下载装置可以包括：文件确定模块701以及策略执行模块702，其中，文件确定模块701，用于确定第二应用程序暂停下载资源，确定第一文件集合以及第二应用程序对第一文件集合中各第一文件的下载记录，第一文件为资源中除第二文件集合以外的文件，第二文件集合中的第二文件为用于加载资源的资源加载程序已下载的文件；策略执行模块702，用于对于每个第一文件，确定第一应用程序对第一文件的下载记录，根据第一应用程序和第二应用程序各自对第一文件的下载记录，确定并执行第一文件的处理策略；
其中，当第一应用程序为资源加载程序时，第二应用程序为用于应用分发的应用分发程序；当第一应用程序为应用分发程序时，第二应用程序为资源加载程序。
138.本技术实施例的装置可执行本技术实施例所提供的方法，其实现原理相类似，本技术各实施例的装置中的各模块所执行的动作是与本技术各实施例的方法中的步骤相对应的，对于装置的各模块的详细功能描述具体可以参见前文中所示的对应方法中的描述，此处不再赘述。
139.本技术实施例中提供了一种电子设备，包括存储器、处理器及存储在存储器上的计算机程序，该处理器执行上述计算机程序以实现资源的预下载方法的步骤，与相关技术相比，本技术实施例的资源预下载方法由第一应用程序执行，第一应用程序既可以应用于资源加载程序，也可以应用于应用分发程序，可随时进行下载主体的切换，通过确定第二应用程序暂停下载资源并确定第一文件集合和第二应用程序对第一文件集合中各第一文件的下载记录，实现了第一应用程序和第二应用程序进行下载记录交互的目的，并且基于两个应用程序各自对第一文件的下载记录确定第一文件的处理策略，可避免不同的下载主体重复下载未下载或正在下载的文件，节省时间成本，也降低了下载的流量，降低下载带来的cdn带宽成本。在一个可选实施例中提供了一种电子设备，如图8所示，图8所示的电子设备4000包括：处理器4001和存储器4003。其中，处理器4001和存储器4003相连，如通过总线4002相连。可选地，电子设备4000还可以包括收发器4004，收发器4004可以用于该电子设备与其他电子设备之间的数据交互，如数据的发送和/或数据的接收等。需要说明的是，实际应用中收发器4004不限于一个，该电子设备4000的结构并不构成对本技术实施例的限定。
140.处理器4001可以是cpu（central processing unit，中央处理器），通用处理器，dsp（digital signal processor，数据信号处理器），asic（application specific integrated circuit，专用集成电路），fpga（field programmable gate array，现场可编程门阵列）或者其他可编程逻辑器件、晶体管逻辑器件、硬件部件或者其任意组合。其可以实现或执行结合本技术公开内容所描述的各种示例性的逻辑方框，模块和电路。处理器4001也可以是实现计算功能的组合，例如包含一个或多个微处理器组合，dsp和微处理器的组合等。
141.总线4002可包括一通路，在上述组件之间传送信息。总线4002可以是pci（peripheral component interconnect，外设部件互连标准）总线或eisa（extended industry standard architecture，扩展工业标准结构）总线等。总线4002可以分为地址总线、数据总线、控制总线等。为便于表示，图8中仅用一条粗线表示，但并不表示仅有一根总线或一种类型的总线。
142.存储器4003可以是rom（read only memory，只读存储器）或可存储静态信息和指令的其他类型的静态存储设备，ram（random access memory，随机存取存储器）或者可存储信息和指令的其他类型的动态存储设备，也可以是eeprom（electrically erasable programmable read only memory，电可擦可编程只读存储器）、cd-rom（compact disc read only memory，只读光盘）或其他光盘存储、光碟存储（包括压缩光碟、激光碟、光碟、数字通用光碟、蓝光光碟等）、磁盘存储介质、其他磁存储设备、或者能够用于携带或存储计算机程序并能够由计算机读取的任何其他介质，在此不做限定。
143.存储器4003用于存储执行本技术实施例的计算机程序，并由处理器4001来控制执行。处理器4001用于执行存储器4003中存储的计算机程序，以实现前述方法实施例所示的步骤。
144.本技术实施例提供了一种计算机可读存储介质，该计算机可读存储介质上存储有计算机程序，计算机程序被处理器执行时可实现前述方法实施例的步骤及相应内容。
145.本技术实施例还提供了一种计算机程序产品，包括计算机程序，计算机程序被处理器执行时可实现前述方法实施例的步骤及相应内容。
146.本技术的说明书和权利要求书及上述附图中的术语“第一”、“第二”、“第三”、“第四”、“1”、“2”等（如果存在）是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的本技术的实施例能够以除图示或文字描述以外的顺序实施。
147.应该理解的是，虽然本技术实施例的流程图中通过箭头指示各个操作步骤，但是这些步骤的实施顺序并不受限于箭头所指示的顺序。除非本文中有明确的说明，否则在本技术实施例的一些实施场景中，各流程图中的实施步骤可以按照需求以其他的顺序执行。此外，各流程图中的部分或全部步骤基于实际的实施场景，可以包括多个子步骤或者多个阶段。这些子步骤或者阶段中的部分或全部可以在同一时刻被执行，这些子步骤或者阶段中的每个子步骤或者阶段也可以分别在不同的时刻被执行。在执行时刻不同的场景下，这些子步骤或者阶段的执行顺序可以根据需求灵活配置，本技术实施例对此不限制。
148.以上仅是本技术部分实施场景的可选实施方式，应当指出，对于本技术领域的普通技术人员来说，在不脱离本技术的方案技术构思的前提下，采用基于本技术技术思想的其他类似实施手段，同样属于本技术实施例的保护范畴。

技术特征：
1.一种资源的预下载方法，其特征在于，应用于第一应用程序，所述资源包括至少一个文件，所述方法包括：确定第二应用程序暂停下载所述资源，确定第一文件集合以及所述第二应用程序对所述第一文件集合中各第一文件的下载记录，所述第一文件为所述资源中除第二文件集合以外的文件，所述第二文件集合中的第二文件为用于加载所述资源的资源加载程序已下载的文件；对于每个第一文件，确定所述第一应用程序对所述第一文件的下载记录，根据所述第一应用程序和所述第二应用程序各自对所述第一文件的下载记录，确定并执行所述第一文件的处理策略；其中，当所述第一应用程序为所述资源加载程序时，所述第二应用程序为用于应用分发的应用分发程序；当所述第一应用程序为所述应用分发程序时，所述第二应用程序为所述资源加载程序。2.根据权利要求1所述的方法，其特征在于，所述下载记录包括下载状态；根据所述第一应用程序和所述第二应用程序各自对所述第一文件的下载记录，确定所述第一文件的处理策略，包括：根据所述第一应用程序和第二应用程序对所述第一文件的下载状态均为未下载，确定所述第一文件的处理策略为下载所述第一文件。3.根据权利要求1所述的方法，其特征在于，所述下载记录包括下载状态和下载进度中的至少一种；所述根据所述第一应用程序和所述第二应用程序各自对所述第一文件的下载记录，确定所述第一文件的处理策略，包括：根据所述第一应用程序对所述第一文件的下载状态为下载中，且所述第二应用程序对所述第一文件的下载状态为未下载，确定所述第一文件的处理策略为根据所述第一应用程序对所述第一文件的下载进度继续下载所述第一文件。4.根据权利要求1-3任意一项所述的方法，其特征在于，所述确定第二应用程序暂停下载所述资源，确定第一文件集合以及所述第二应用程序对所述第一文件集合中各第一文件的下载记录，之前还包括：获得所述资源的配置信息，所述配置信息包括所述资源中各文件的文件标识；所述确定所述第二应用程序对所述第一文件集合中各第一文件的下载记录，包括：利用contentprovider机制，根据各第一文件的文件标识，向所述第二应用程序确定所述第二应用程序对相应标识的第一文件的下载记录。5.根据权利要求4所述的方法，其特征在于，所述第一应用程序为所述资源加载程序；所述下载记录包括下载状态和下载进度中的至少一种；根据所述第一应用程序和所述第二应用程序各自对所述第一文件的下载记录，确定所述第一文件的处理策略，包括：根据所述第一应用程序和第二应用程序对所述第一文件的下载状态均为下载中，确定所述第一文件的处理策略为：根据所述第一应用程序和第二应用程序各自对所述第一文件的下载进度，对所述第一应用程序和所述第二应用程序各自对所述第一文件下载的部分进行合并，获得并保存所述
第一文件的下载部分的合并结果；继续下载所述第一文件中下载部分的合并结果之外的部分。6.根据权利要求5所述的方法，其特征在于，所述根据所述第一应用程序和第二应用程序各自对所述第一文件的下载进度，对所述第一应用程序和所述第二应用程序各自对所述第一文件下载的部分进行合并，获得并保存所述第一文件的合并部分，包括：若第一部分和第二部分不存在重合的内容，则根据所述第一应用程序和第二应用程序各自对所述第一文件的下载进度，将第一部分和第二部分进行拼接，获得并保存所述第一文件的下载部分的合并结果；若所述第一部分和第二部分存在重合的内容，则删除所述第一部分和所述第二部分中的一个部分的重合的内容，得到所述一个部分的剩余内容；根据所述第一应用程序和第二应用程序各自对所述第一文件的下载进度，将所述一个部分的剩余内容与另一个部分进行拼接，获得并保存所述第一文件的下载部分的合并结果；其中，所述第一部分为第一应用程序对所述第一文件下载的部分，所述第二部分为第二应用程序对所述第一文件下载的部分。7.根据权利要求4所述的方法，其特征在于，所述第一应用程序为所述资源加载程序；所述下载记录包括下载状态；根据所述第一应用程序和所述第二应用程序各自对所述第一文件的下载记录，确定所述第一文件的处理策略，包括：根据所述第一应用程序对所述第一文件的下载状态为未下载，所述第二应用程序对所述第一文件的下载状态为已下载，确定所述第一文件的处理策略为：将所述第一文件已下载的所述第一文件移动至所述第一应用程序的预设存储位置。8.根据权利要求4所述的方法，其特征在于，所述第一应用程序为所述资源加载程序；所述下载记录包括下载状态和下载进度；根据所述第一应用程序和所述第二应用程序各自对所述第一文件的下载记录，确定所述第一文件的处理策略，包括：根据所述第一应用程序对所述第一文件的下载状态为未下载，所述第二应用程序对所述第一文件的下载状态为下载中，确定所述第一文件的处理策略为：将所述第二应用程序下载的所述第一文件的部分移动至所述第一应用程序的预设存储位置；根据所述第二应用程序对所述第一文件的下载进度继续下载所述第一文件。9.根据权利要求4所述的方法，其特征在于，所述第一应用程序为所述资源加载程序；所述确定第一文件集合，包括：根据各文件的下载记录，确定所述第二文件集合；从所述配置信息中根据所述第二文件集合中各第二文件的文件标识，确定所述第一文件集合。10.根据权利要求4所述的方法，其特征在于，所述第一应用程序为所述资源加载程序；所述确定并执行所述第一文件的处理策略，之后还包括：对已下载的所述第一文件进行完整性和准确性校验；
若校验通过，则保留所述第一文件；若校验不通过，则删除所述第一文件并重新下载所述第一文件。11.根据权利要求10所述的方法，其特征在于，还包括：若确定已下载所述资源的全部文件，且全部文件均校验通过，则加载所述资源。12.根据权利要求5-11任意一项所述的方法，其特征在于，所述方法由所述资源加载程序中的目标sdk执行；所述确定第二应用程序暂停下载所述资源，确定第一文件集合以及所述第二应用程序对所述第一文件集合中各第一文件的下载记录，之前还包括确定满足以下至少一个条件：所述第一应用程序调用所述目标sdk；所述第二应用程序调用所述目标sdk；所述目标sdk感知到所述第一应用程序处于对所在的终端负荷小于预设阈值的运行状态。13.根据权利要求4所述的方法，其特征在于，所述第一应用程序为所述应用分发程序；所述下载记录包括下载状态和下载进度中的至少一种；根据所述第一应用程序和所述第二应用程序各自对所述第一文件的下载记录，确定所述第一文件的处理策略，包括：根据所述第二应用程序对所述第一文件的下载状态均为下载中，确定所述第一文件的处理策略为：若所述第一应用程序对所述第一文件的下载进度不大于所述第二应用程序对所述第一文件的下载进度，则删除第一应用程序对所述第一文件下载的部分，根据所述第二应用程序对所述第一文件的下载进度继续下载该第一文件；若所述第一应用程序对所述第一文件的下载进度大于所述第二应用程序对所述第一文件的下载进度，根据所述第一应用程序对所述第一文件的下载进度继续下载所述第一文件。14.根据权利要求13所述的方法，其特征在于，所述确定第一文件集合以及所述第二应用程序对所述第一文件集合中各第一文件的下载记录，包括：利用contentprovider机制向所述第二应用程序发送查询请求，所述查询请求包括所述资源的至少一个文件的文件标识，所述查询请求用于请求相应文件标识的文件的下载记录；根据所述第二应用程序返回的相应文件标识的文件的下载记录，确定第一文件集合以及所述第二应用程序对所述第一文件集合中各第一文件的下载记录。15.一种资源的预下载装置，其特征在于，应用于第一应用程序，所述资源包括至少一个文件，所述装置包括：文件确定模块，用于确定第二应用程序暂停下载所述资源，确定第一文件集合以及所述第二应用程序对所述第一文件集合中各第一文件的下载记录，所述第一文件为所述资源中除第二文件集合以外的文件，所述第二文件集合中的第二文件为用于加载所述资源的资源加载程序已下载的文件；策略执行模块，用于对于每个第一文件，确定所述第一应用程序对所述第一文件的下载记录，根据所述第一应用程序和所述第二应用程序各自对所述第一文件的下载记录，确
定并执行所述第一文件的处理策略；其中，当所述第一应用程序为所述资源加载程序时，所述第二应用程序为用于应用分发的应用分发程序；当所述第一应用程序为所述应用分发程序时，所述第二应用程序为所述资源加载程序。16.一种电子设备，包括存储器、处理器及存储在存储器上的计算机程序，其特征在于，所述处理器执行所述计算机程序以实现权利要求1-14任一项所述方法的步骤。17.一种计算机可读存储介质，其上存储有计算机程序，其特征在于，所述计算机程序被处理器执行时实现权利要求1-14任一项所述方法的步骤。

技术总结
本申请实施例提供了一种资源的预下载方法、装置、电子设备及计算机可读存储介质，涉及通信技术领域。该方法包括：确定第二应用程序暂停下载资源，确定第一文件集合以及第二应用程序对第一文件集合中各第一文件的下载记录，第一文件为资源中除第二文件集合以外的文件，第二文件集合中的第二文件为用于加载资源的资源加载程序已下载的文件；对于每个第一文件，确定第一应用程序对第一文件的下载记录，根据第一应用程序和第二应用程序各自对第一文件的下载记录，确定并执行第一文件的处理策略。本申请实施例节省时间成本，也降低了下载的流量，降低下载带来的CDN带宽成本。降低下载带来的CDN带宽成本。降低下载带来的CDN带宽成本。


技术研发人员：蔡文杰 洪楷 徐士立 赵佳宁 刘专
受保护的技术使用者：腾讯科技（深圳）有限公司
技术研发日：2023.06.02
技术公布日：2023/7/12