资源预加载方法、资源预加载装置、存储介质及电子设备

技术领域

本公开的实施方式涉及计算机技术领域，更具体地，本公开的实施方式涉及资源预加载方法、资源预加载装置、计算机可读存储介质及电子设备。

背景技术

本部分旨在为权利要求中陈述的本公开的实施方式提供背景或上下文，此处的描述不因为包括在本部分中就承认是现有技术。

现有的App(Application，应用程序)一般需要开发人员手动配置预加载资源(例如：使用频率较高的资源，或者，影响页面打开速度的资源)，以使APP对上述预加载资源进行预先缓存。

发明内容

然而，现有的方案只能预加载开发人员根据主观判断设定好的资源，而无法根据客观的判断来确定加载哪些资源，或者，无法根据不同的业务场景调整需要预加载的资源。

为此，非常需要一种资源预加载方法，可以在降低人力成本的前提下，提升预加载资源的命中率。

在本上下文中，本公开的实施方式期望提供一种资源预加载方法、资源预加载装置、计算机可读存储介质及电子设备。

根据本公开实施方式的第一方面，提供一种资源预加载方法，包括：应用程序启动之后，拦截所述应用程序发出的资源加载请求；利用所述资源加载请求所请求的资源信息对所述应用程序内植入的预加载模型进行优化训练，以更新所述预加载模型；通过所述更新后的预加载模型预测得到第一预加载资源，并对所述第一预加载资源进行预加载。

在本公开的示例性实施例中，在应用程序启动之后，所述方法还包括：检测是否接收到针对资源预加载功能的开启操作；若接收到所述开启操作，拦截所述应用程序发出的资源加载请求；对所述资源加载请求所请求的资源信息进行业务场景划分，得到不同业务场景下所请求的资源信息；利用所述不同业务场景下所请求的资源信息对所述预加载模型进行优化训练，以更新所述预加载模型。

在本公开的示例性实施例中，在拦截所述应用程序发出的资源加载请求之前，所述方法还包括：通过所述预加载模型预测得到第二预加载资源，并对所述第二预加载资源进行预加载。

在本公开的示例性实施例中，在拦截所述应用程序发出的资源加载请求之后，所述方法还包括：将所述资源加载请求所请求的资源与所述第二预加载资源进行比对，以确定所述资源是否包含于所述第二预加载资源中；若所述资源包含于所述第二预加载资源中，则记录所述资源的请求次数；若所述资源未包含于所述第二预加载资源中，则记录所述资源的索引信息、数据量和/或下载耗时。

在本公开的示例性实施例中，所述对所述第一预加载资源进行预加载，包括：向服务端发送鉴权请求，所述鉴权请求用于请求所述服务端进行鉴权验证；在接收到针对所述鉴权请求的鉴权通过消息时，从所述服务端缓存所述第一预加载资源，以实现对所述第一预加载资源的预加载。

在本公开的示例性实施例中，所述从所述服务端缓存所述第一预加载资源，以实现对所述第一预加载资源的预加载，包括：利用进程空闲时段从所述服务端缓存所述第一预加载资源，以实现对所述第一预加载资源的预加载；所述进程空闲时间为进程占用率低于预设占用率阈值的时段。

在本公开的示例性实施例中，在对所述第一预加载资源进行预加载之后，所述方法还包括：统计所述更新后的预加载模型的命中率；所述命中率用于表征预设时长内所述第一预加载资源的请求次数占所述资源加载请求总数的比例；将每次更新后的预加载模型及其命中率上报至服务端；以使所述服务端每隔预设时间周期从上报的多个模型中筛选出最优模型，并利用所述最优模型替换所述更新后的预加载模型；其中，所述最优模型为命中率最高的更新后的预加载模型。

根据本公开实施方式第二方面，提供一种资源预加载装置，包括：请求拦截模块，用于在应用程序启动之后，拦截所述应用程序发出的资源加载请求；优化训练模块，用于利用所述资源加载请求所请求的资源信息对所述应用程序内植入的预加载模型进行优化训练，以更新所述预加载模型；资源预加载模块，用于通过所述更新后的预加载模型预测得到第一预加载资源，并对所述第一预加载资源进行预加载。

根据本公开实施方式的第三方面，提供一种计算机可读存储介质，其上存储有计算机程序，所述计算机程序被处理器执行时实现上述第一方面所述的资源预加载方法。

根据本公开实施方式的第四方面，提供一种电子设备，包括：处理器；以及存储器，用于存储所述处理器的可执行指令；其中，所述处理器配置为经由执行所述可执行指令来执行上述第一方面所述的资源预加载方法。

根据本公开实施方式的资源预加载方法、资源预加载装置、计算机可读存储介质及电子设备，一方面，本公开解决了相关技术中基于开发人员主观配置预加载资源所导致的一些经常使用的资源未被配置为预加载资源的情况，或者，某些已经下线的业务相关的资源被配置为预加载资源的情况，提升预加载资源与用户实际应用场景的贴合度。另一方面，本公开能够在无需人力干预的前提下，实现在本地对预加载模型进行持续性的自动优化，相比传统的服务端计算最优模型的方案而言，更加高效，节约了人力成本。再一方面，在预测出与用户实际应用场景的贴合度更高的预加载资源之后，本公开能够在后续用户请求时，快速加载相关资源，提升资源加载速度，优化用户体验。

附图说明

通过参考附图阅读下文的详细描述，本公开示例性实施方式的上述以及其他目的、特征和优点将变得易于理解。在附图中，以示例性而非限制性的方式示出了本公开的若干实施方式，其中：

图1示出了本公开实施例中一种资源预加载方法的流程示意图；

图2示出了本公开实施例中另一种资源预加载方法的流程示意图；

图3示出公开实施例中如何利用最优模型替换更新后的预加载模型的流程示意图；

图4示出本公开实施例中资源预加载方法的整体流程图；

图5示出了根据本公开实施方式的资源预加载装置的示意图；以及

图6示出了根据本公开实施方式的电子设备的结构图。

在附图中，相同或对应的标号表示相同或对应的部分。

具体实施方式

下面将参考若干示例性实施方式来描述本公开的原理和精神。应当理解，给出这些实施方式仅仅是为了使本领域技术人员能够更好地理解进而实现本公开，而并非以任何方式限制本公开的范围。相反，提供这些实施方式是为了使本公开更加透彻和完整，并且能够将本公开的范围完整地传达给本领域的技术人员。

本领域技术人员知道，本公开的实施方式可以实现为一种系统、装置、设备、方法或计算机程序产品。因此，本公开可以具体实现为以下形式，即：完全的硬件、完全的软件(包括固件、驻留软件、微代码等)，或者硬件和软件结合的形式。

根据本公开的实施方式，提供一种资源预加载方法、资源预加载装置、计算机可读存储介质及电子设备。

在本文中，附图中的任何元素数量均用于示例而非限制，以及任何命名都仅用于区分，而不具有任何限制含义。

下面参考本公开的若干代表性实施方式，详细阐述本公开的原理和精神。

本发明人发现，现有的App只能预加载开发人员根据主观判断设定好的资源。该方案具有以下缺陷：

第一，由于预加载的文件是通过开发人员的主观判断来配置的，可能存在一些经常使用的资源未被配置为预加载资源的情况，或者，某些已经下线的业务相关的资源被配置为预加载资源的情况；

第二，无法根据不同的业务场景调整需要预加载的资源；

第三，APP使用过程中会访问很多资源，包括图片、离线包和业务文档等文件，直接对配置好的预加载资源进行预先缓存的方式，会非常消耗手机性能，并且，占用大部分带宽；

第四，手动配置预加载资源的方式低效且容易出错，且无法持续跟踪优化；

第五，无法反复学习校准，给出最优方案。

鉴于上述内容，本公开的基本思想在于：提供一种资源预加载方法、资源预加载装置、计算机可读存储介质及电子设备，一方面，本公开解决了相关技术中基于开发人员主观配置预加载资源所导致的一些经常使用的资源未被配置为预加载资源的情况，或者，某些已经下线的业务相关的资源被配置为预加载资源的情况，提升预加载资源与用户实际应用场景的贴合度。另一方面，本公开能够在无需人力干预的前提下，实现在本地对预加载模型进行持续性的自动优化，相比传统的服务端计算最优模型的方案而言，更加高效，节约了人力成本。再一方面，在预测出与用户实际应用场景的贴合度更高的预加载资源之后，本公开能够在后续用户请求时，快速加载相关资源，提升资源加载速度，优化用户体验。

在介绍了本公开的基本原理之后，下面具体介绍本公开的各种非限制性实施方式。

需要注意的是，下述应用场景仅是为了便于理解本公开的精神和原理而示出，本公开的实施方式在此方面不受任何限制。相反，本公开的实施方式可以应用于适用的任何场景。

本公开的实施方式能够自动生成最优的预加载模型，具体的，可以在应用程序中预先植入简易的预加载模型，通过该简易的预加载模型可以执行初始的资源预加载。在应用程序启动之后，可以通过资源拦截器拦截应用程序发出的资源加载请求，并记录资源加载请求所请求的资源信息，定期或不定期利用上述资源信息对预加载模型进行优化训练，以不断更新上述预加载模型，使得通过更新后的预加载模型所加载的第一预加载资源能够更加符合业务需求。

本公开的示例性实施方式首先提供一种资源预加载方法，图1示出了本公开实施例中一种资源预加载方法的流程示意图，可以包括以下步骤S110至S130：

在步骤S110中，在应用程序启动之后，拦截应用程序发出的资源加载请求。

本步骤中，在应用程序启动之后，用户可以在应用程序上进行交互操作。鉴于不同的交互操作需要展示不同的结果或反馈不同的文件，因而，应用程序需要根据不同的交互操作向服务端请求不同的资源。在请求资源时，应用程序需要向服务端发送资源加载请求，此时，可以通过资源拦截器拦截应用程序发出的资源加载请求，并记录每个资源加载请求所请求的资源信息。

其中，应用程序指为完成某项或多项特定工作的计算机程序，它运行在用户模式，可以和用户进行交互，具有可视的用户界面，一般需要与服务端互相配合运行。常见的应用主要分两类，一类是预装的系统应用，比如短信、照片、备忘录、Safari等；还有一类是第三方应用，比如资讯类APP、购物类APP、社交类APP等等。

上述资源可以包括H5(H5是指第5代HTML，也指用H5语言制作的一切数字产品，是超文本标记语言的英文缩写)页面中的JS(JavaScript)、CSS(Cascading Style Sheets，层叠样式表)、HTML(HyperText Mark-up Language，超文本标记语言)、JPG(指JPEG格式，Joint Photographic Experts Group，联合图像专家组)、PNG(Portable NetworkGraphics，便携式网络图形)等或应用程序中直接打开的PDF(Portable Document Format，可携带文件格式)、png、plist(属性表文件)、xml(EXtensible Markup Language，可扩展标记语言)等文件，可以根据实际情况自行设定，本公开对此不作特殊限定。

资源信息可以包括资源名称、索引信息(索引相当于书本中的目录，通过索引能够快速查找并读取到想要的文件内容)、数据量(即资源占用的容量大小)、下载耗时(即下载该资源所需的时长)等，可以根据实际情况自行设定，本公开对此不作特殊限定。

在步骤S120中，利用资源加载请求所请求的资源信息对应用程序内植入的预加载模型进行优化训练，以更新预加载模型。

本步骤中，可以在间隔预设时间段之后(或当上述资源信息累计到一定数据量时)，利用上述资源加载请求所请求的资源信息对应用程序内植入的预加载模型进行优化训练，以更新该预加载模型。

上述预加载模型可以是相关开发人员基于自身经验预先编写的简易模型，利用该预加载模型可以实现资源预加载功能(即预先下载部分资源，在用户请求这些资源的时候可以直接从缓存中调取并加载，免去了这些资源的下载时间)，但功能有待进一步完善。

具体的，可以将上述资源信息作为训练集，使用TensorFlow平台对上述预加载模型进行优化训练，直至上述预加载模型的损失函数趋于收敛，得到更新后的预加载模型。

其中，TensorFlow是一个基于数据流编程(dataflow programming)的符号数学系统，被广泛应用于各类机器学习(machine learning)算法的编程实现。TensorFlow拥有一个全面而灵活的生态系统，其中包含各种工具、库和社区资源，可助力研究人员推动先进机器学习技术的发展，并使开发者能够轻松地构建和部署由机器学习提供支持的应用。

可选的，还可以从上述训练集中筛选出多个不同维度的资源，例如：请求次数大于预设请求次数阈值的资源、资源大小小于预设数据量阈值的资源、资源下载耗时小于预设时长的资源，进而，通过上述多个不同维度的资源所对应的资源信息来对上述预加载模型进行优化训练，直至上述预加载模型的损失函数趋于收敛，得到更新后的预加载模型。从而，该更新后的预加载模型在后续的预测过程中可以预测得到一些用户请求频繁、占用数据量较小并且下载省时的预加载文件，从而，解决相关技术中仅将开发人员定义的指定资源进行预加载，而没有考虑到这些资源的占用数据量、下载耗时等多方面因素，所导致的消耗终端性能，导致大量带宽占用的技术问题，实现在提升资源加载速度的同时，降低终端的带宽占用。

在得到更新后的预加载模型之后，可以进入步骤S130中，通过更新后的预加载模型预测得到第一预加载资源，并对所述第一预加载资源进行预加载。

本步骤中，可以利用更新后的预加载模型预判出第一预加载资源，在预判出第一预加载资源之后，可以向服务端发送鉴权请求，该鉴权请求用于请求服务端进行鉴权验证，在接收到针对鉴权请求的鉴权通过消息时，可以利用进程空闲时段(即进程占用率低于预设占用率阈值的时段)从服务端从缓存上述第一预加载资源，以实现对第一预加载资源的预加载，从而实现利用上述更新后的预加载模型预先加载更加贴合用户需求的资源。

图2示出了本公开实施例中另一种资源预加载方法的流程示意图，包含步骤S201-步骤S204：

在步骤S201中，在应用程序启动之后，检测是否接收到针对资源预加载功能的开启操作。

本步骤中，示例性的，可以在应用程序中预先配置一资源预加载功能的配置开关，进而，在应用程序启动之后，可以在界面上展示上述配置开关，该配置开关的作用在于启用上述资源预加载功能。进而，用户可以针对上述配置开关进行触控操作，例如：点击操作、滑动操作等，若用户通过上述配置开关开启了资源预加载功能，则可以执行以下步骤S202-步骤S205，否则，不开启上述资源预加载功能。

通过设置该资源预加载功能的配置开关，使得用户能够自身需求配置是否开启资源预加载功能，并且，便于比对开启该资源预加载功能前后的资源请求速度，以及，确定资源预加载功能是否有效。

在步骤S202中，若接收到开启操作，拦截应用程序发出的资源加载请求。

本步骤中，若接收到用户针对上述配置开关的开启操作，资源拦截器可以拦截应用程序发出的资源加载请求。

在步骤S203中，对资源加载请求所请求的资源信息进行业务场景划分，得到不同业务场景下所请求的资源信息。

本步骤中，在拦截到资源加载请求之后，可以对资源加载请求所请求的资源信息进行业务场景划分，得到不同业务场景下所请求的资源信息，进而，可以将不同业务场景下所请求的资源信息进行分类存放。

其中，业务场景，是商家和消费者，是企业和客户，是平台商和供应商之间的连接器。这种连接器在时间和空间两个维度上进行延伸，包含了人、事、物和相关要素的集合。

示例性的，不同业务场景下所请求的资源信息可以是：双十一大促期间不同手机型号的用户所请求的资源信息；六一八大促活动期间不同用户标识的用户所请求的资源信息。具体的业务场景类型可以根据实际情况自行设定，本公开对此不作特殊限定。

在步骤S204中，利用不同业务场景下所请求的资源信息对预加载模型进行优化训练，以更新预加载模型。

本步骤中，可以利用不同业务场景下所请求的资源信息对应用程序内植入的预加载模型进行优化训练，以更新上述预加载模型。

参照上述步骤的相关解释，可以将上述不同业务场景下所请求的资源信息作为训练集，使用TensorFlow平台对上述预加载模型进行优化训练，直至上述预加载模型的损失函数趋于收敛，得到更新后的预加载模型。

可选的，还可以从上述训练集中筛选出不同业务场景下所对应的多个不同维度的资源，例如：A业务场景下请求次数大于预设请求次数阈值的资源、A业务场景下资源大小小于预设数据量阈值的资源、A业务场景下资源下载耗时小于预设时长的资源，进而，通过上述不同业务场景下的多个不同维度的资源所对应的资源信息来对上述预加载模型进行优化训练，直至上述预加载模型的损失函数趋于收敛，得到更新后的预加载模型。从而，该更新后的预加载模型在后续的预测过程中可以预测得到在不用业务场景下，用户请求频繁、占用数据量较小并且下载省时的预加载文件，从而，解决相关技术中仅将开发人员定义的指定资源进行预加载，而没有考虑到这些资源的占用数据量、下载耗时等多方面因素，所导致的消耗终端性能，导致大量带宽占用的技术问题，实现在提升不同业务场景下的资源加载速度的同时，降低终端的带宽占用。

在上述步骤S204之后，可以通过更新后的预加载模型预判出不同业务场景下所需的预加载资源，在预判出预加载资源之后，可以向服务端发送鉴权请求，该鉴权请求用于请求服务端进行鉴权验证，在接收到针对鉴权请求的鉴权通过消息时，可以利用进程空闲时段(即进程占用率低于预设占用率阈值的时段)从服务端从缓存上述预加载资源，并将不同业务场景下的预加载资源进行分类存放(便于后续根据业务场景进行快速调用)，以对不同业务场景下所需的预加载资源进行预加载。

可选的，在上述步骤S110或步骤S202中，在拦截应用程序发出的资源加载请求之前，还可以利用上述预加载模型预测得到第二预加载资源，并对第二预加载资源进行预加载。具体的，可以在进程空闲时段，通过植入的预加载模型生成可执行的javascript代码，通过JSC Worker(简称JSC Worker,是不需要依赖webview执行javascript脚本的执行器，然后支持多线程同时执行多个JS脚本的容器，也叫JSC Worker池)执行第二预加载资源的预获取过程，并将获取到的第二预加载资源保存至缓存中。

进而，在后续拦截到应用程序发出的资源加载请求之后，可以将资源加载请求所请求的资源与缓存中的上述第二预加载资源进行比对，以确定上述资源是否包含于第二预加载资源中。示例性的，可以将上述资源的索引与缓存中的上述第二预加载资源的索引进行比对，以确定出上述资源是否包含于第二预加载资源中。若上述资源包含于上述第二预加载资源中，则可以在本地数据库中记录资源的请求次数，例如，令其请求次数加一。若上述资源未包含于上述第二预加载资源中，则可以在本地数据库中记录上述资源的索引信息、资源大小、资源下载耗时等信息。

进一步的，可以利用上述资源信息或不同业务场景下所请求的资源信息对预加载模型进行优化训练，以更新预加载模型。在后续训练得到更新后的预加载模型之后，可以利用更新后的预加载模型再次预测得到预加载资源，并对预加载资源进行预加载，以实现对上述第二预加载资源的更新。

需要说明的是，随着拦截到的资源加载请求的不断增加，资源加载请求所请求的资源信息也会不断增加，从而，本公开可以定期(例如：每隔10天)或不定期(例如：当记录的资源信息的数据量每增加100MB(计算机中的一种储存单位，读作“兆”)时)利用上述资源信息对上述预加载模型(或者更新后的预加载模型)进行优化训练，从而实现模型的不断更新。

在每次更新之后，可以通过更新后的预加载模型对第一预加载资源进行预加载。在完成更新后的预设时长内，可以统计该更新后的预加载模型的命中率，进而，将更新后的预加载模型机器命中率上报至服务端，以使服务端从多次上报的模型中选取最优模型，并利用最优模型替换更新后的预加载模型。具体的，参考图3，图3示出公开实施例中如何利用最优模型替换更新后的预加载模型的流程示意图，包含步骤S301-步骤S303：

在步骤S301中，统计更新后的预加载模型的命中率。

本步骤中，在得到更新后的预加载模型并利用该更新后的预加载模型对第一预加载资源进行预加载之后，可以统计该更新后的预加载模型的命中率。具体的，可以统计预设时长(例如：3天，可以根据实际情况自行设定，本公开对此不作特殊限定)内的资源加载请求总数(例如：100)，以及，统计该预设时长内上述第一预加载资源的请求次数(例如：80)，进而，将第一预加载资源的请求次数占资源加载请求总数的比例80％确定为上述更新后的预加载模型的命中率。

在步骤S302中，将每次更新后的预加载模型及其命中率上报至服务端。

本步骤中，可以将每次更新后的预加载模型及其命中率上报至服务端。

在步骤S303中，以使服务端每隔预设时间周期从上报的多个模型中筛选出最优模型，并利用最优模型替换更新后的预加载模型。

本步骤中，服务端在接收到上报的预加载模型及其命中率之后，可以每隔预设时间周期(例如：2个月，可以根据实际情况自行设定，本公开对此不作特殊限定)从上报的多个模型中筛选出命中率最高的最优模型，并利用最优模型替换更新后的预加载模型。

通过利用最优模型替换更新后的预加载模型，使得后续可以直接在最优模型的基础上进行模型更新，从而，加快模型的更新效率，便于快速得到命中率最高的预加载模型。

示例性的，以下以打开H5页面的应用场景为例对本公开的实施方式进行举例说明：

第一，检测用户是否开启资源预加载功能；

第二，若检测到用户开启了资源预加载功能，可以调用应用程序内植入的预加载模型，利用该预加载模型预判用户打开页面所需要的第二预加载资源，例如：html、js、css、png、jpg等文件，进而，在进程空闲时段可以预先下载这些第二预加载资源，并将其放在缓存中，在后续用户打开活动页面的时候，由于上述第二预加载资源已经提前下载好了，则可以直接读取缓存，实现活动页面的快速加载；

第三，将资源拦截器所拦截到的资源信息(不同业务场景下所对应的资源信息)作为训练集，通过tensorflow机器学习平台对上述预加载模型进行优化训练，待训练完成之后，导出SavedModel模型(tensorflow导出保存之后即称为SavedModel模型)，将SavedModel模型和鉴权过程合成为更新后的预加载模型，进而，可以利用更新后的预加载模型再次预判预加载资源，并利用这些预加载资源更新已经缓存的预加载资源；

第四，终端设备将每次更新后的预加载模型上传至服务端，以使服务端从中筛选出最优算法下发到各个终端设备中。

参考图4，图4示出本公开实施例中资源预加载方法的整体流程图，包含步骤S401-步骤S407：

在步骤S401中，开始；

在步骤S402中，APP启动时检测配置开关是否打开；

若未打开配置开关，则跳转至步骤S407中，结束；

若打开了配置开关，则进入步骤S403中，进程空闲时利用预加载模型生成JS预加载代码，通过JSC worker池分配的JSC worker预取文件并存入缓存中；

在步骤S404中，利用资源拦截器拦截资源加载请求，将资源加载请求所请求的资源信息与缓存中的预取文件进行比对，根据比对结果将资源信息写入本地数据库(即若比对出资源已经被缓存，则更新其请求次数；若未缓存，则记录资源名称、索引信息、资源大小、资源下载耗时等)；

在步骤S405中，利用资源信息对预加载模型进行定期优化，以更新预加载模型；

在步骤S406中，将每次更新后的预加载模型及其命中率上报至服务端，以使服务端从中筛选出最优模型，并下发最优模型。

基于以上技术方案，本公开至少具有以下技术效果：

1、数据客观化，可以更加客观的根据资源的访问频率和命中率来作为算法数据参考；

2、方案智能化：通过算法的不断学习逐步校准，自动生成最优方案，更加高效，节约人力成本；

3、场景定制化：可以根据场景做针对性的预取优化；

4、维度多样化：把算法下发给不同维度的设备进行学习，计算出来的方案更具代表性；

5、节约成本：直接下发自定义js优化算法，在本地不断学习校准，计算出最优方案，相比传统的由服务端来确定最优算法的方案而言，节省了流量和数据库等开销。

在介绍了本公开示例性实施方式的资源预加载方法之后，接下来，参考图5对本公开示例性实施方式的资源预加载装置进行说明。

图5示出了配置于第一终端的资源预加载装置500，包括：

请求拦截模块510，用于在应用程序启动之后，拦截所述应用程序发出的资源加载请求；

优化训练模块520，用于利用所述资源加载请求所请求的资源信息对所述应用程序内植入的预加载模型进行优化训练，以更新所述预加载模型；

资源预加载模块530，用于通过所述更新后的预加载模型预测得到第一预加载资源，并对所述第一预加载资源进行预加载。

在本公开的示例性实施例中，在应用程序启动之后，资源预加载模块530，被配置为：

检测是否接收到针对资源预加载功能的开启操作；若接收到所述开启操作，拦截所述应用程序发出的资源加载请求；对所述资源加载请求所请求的资源信息进行业务场景划分，得到不同业务场景下所请求的资源信息；利用所述不同业务场景下所请求的资源信息对所述预加载模型进行优化训练，以更新所述预加载模型。

在本公开的示例性实施例中，在拦截所述应用程序发出的资源加载请求之前，资源预加载模块530，被配置为：

通过所述预加载模型预测得到第二预加载资源，并对所述第二预加载资源进行预加载。

在本公开的示例性实施例中，在拦截所述应用程序发出的资源加载请求之后，请求拦截模块510，被配置为：

将所述资源加载请求所请求的资源与所述第二预加载资源进行比对，以确定所述资源是否包含于所述第二预加载资源中；若所述资源包含于所述第二预加载资源中，则记录所述资源的请求次数；若所述资源未包含于所述第二预加载资源中，则记录所述资源的索引信息、数据量和/或下载耗时。

在本公开的示例性实施例中，资源预加载模块530，被配置为：

向服务端发送鉴权请求，所述鉴权请求用于请求所述服务端进行鉴权验证；在接收到针对所述鉴权请求的鉴权通过消息时，从所述服务端缓存所述第一预加载资源，以实现对所述第一预加载资源的预加载。

在本公开的示例性实施例中，资源预加载模块530，被配置为：

利用进程空闲时段从所述服务端缓存所述第一预加载资源，以实现对所述第一预加载资源的预加载；所述进程空闲时间为进程占用率低于预设占用率阈值的时段。

在本公开的示例性实施例中，在对所述第一预加载资源进行预加载之后，资源预加载模块530，被配置为：

统计所述更新后的预加载模型的命中率；所述命中率用于表征预设时长内所述第一预加载资源的请求次数占所述资源加载请求总数的比例；将每次更新后的预加载模型及其命中率上报至服务端；以使所述服务端每隔预设时间周期从上报的多个模型中筛选出最优模型，并利用所述最优模型替换所述更新后的预加载模型；其中，所述最优模型为命中率最高的更新后的预加载模型。

此外，本公开实施方式的其他具体细节在上述方法的实施方式中已经详细说明，在此不再赘述。

下面对本公开示例性实施方式的存储介质进行说明。

本示例性实施方式中，可以通过程序产品实现上述方法，如可以采用便携式紧凑盘只读存储器(CD-ROM)并包括程序代码，并可以在设备，例如个人电脑上运行。然而，本公开的程序产品不限于此，在本文件中，可读存储介质可以是任何包含或存储程序的有形介质，该程序可以被指令执行系统、装置或者器件使用或者与其结合使用。

该程序产品可以采用一个或多个可读介质的任意组合。可读介质可以是可读信号介质或者可读存储介质。可读存储介质例如可以为但不限于电、磁、光、电磁、红外线、或半导体的系统、装置或器件，或者任意以上的组合。可读存储介质的更具体的例子(非穷举的列表)包括：具有一个或多个导线的电连接、便携式盘、硬盘、随机存取存储器(RAM)、只读存储器(ROM)、可擦式可编程只读存储器(EPROM或闪存)、光纤、便携式紧凑盘只读存储器(CD-ROM)、光存储器件、磁存储器件、或者上述的任意合适的组合。

计算机可读信号介质可以包括在基带中或者作为载波一部分传播的数据信号，其中承载了可读程序代码。这种传播的数据信号可以采用多种形式，包括但不限于电磁信号、光信号或上述的任意合适的组合。可读信号介质还可以是可读存储介质以外的任何可读介质，该可读介质可以发送、传播或者传输用于由指令执行系统、装置或者器件使用或者与其结合使用的程序。

可读介质上包含的程序代码可以用任何适当的介质传输，包括但不限于无线、有线、光缆、RE等等，或者上述的任意合适的组合。

可以以一种或多种程序设计语言的任意组合来编写用于执行本公开操作的程序代码，程序设计语言包括面向对象的程序设计语言-诸如Java、C++等，还包括常规的过程式程序设计语言-诸如"C"语言或类似的程序设计语言。程序代码可以完全地在用户计算设备上执行、部分在用户计算设备上部分在远程计算设备上执行、或者完全在远程计算设备或服务器上执行。在涉及远程计算设备的情形中，远程计算设备可以通过任意种类的网络，包括局域网(FAN)或广域网(WAN)，连接到用户计算设备，或者，可以连接到外部计算设备(例如利用因特网服务提供商来通过因特网连接)。

参考图6对本公开示例性实施方式的电子设备进行说明。

图6显示的电子设备600仅仅是一个示例，不应对本公开实施例的功能和使用范围带来任何限制。

如图6所示，电子设备600以通用计算设备的形式表现。电子设备600的组件可以包括但不限于：至少一个处理单元610、至少一个存储单元620、连接不同系统组件(包括存储单元620和处理单元610)的总线630、显示单元640。

其中，存储单元存储有程序代码，程序代码可以被处理单元610执行，使得处理单元610执行本说明书上述"示例性方法"部分中描述的根据本公开各种示例性实施方式的步骤。例如，处理单元610可以执行如图1所示的方法步骤等。

存储单元620可以包括易失性存储单元，例如随机存取存储单元(RAM)621和/或高速缓存存储单元622，还可以进一步包括只读存储单元(ROM)623。

存储单元620还可以包括具有一组(至少一个)程序模块625的程序/实用工具624，这样的程序模块625包括但不限于：操作系统、一个或者多个应用程序、其它程序模块以及程序数据，这些示例中的每一个或某种组合中可能包括网络环境的实现。

总线630可以包括数据总线、地址总线和控制总线。

电子设备600也可以与一个或多个外部设备700(例如键盘、指向设备、蓝牙设备等)通信，这种通信可以通过输入/输出(I/O)接口650进行。电子设备600还包括显示单元640，其连接到输入/输出(I/O)接口650，用于进行显示。并且，电子设备600还可以通过网络适配器660与一个或者多个网络(例如局域网(LAN)，广域网(WAN)和/或公共网络，例如因特网)通信。如图所示，网络适配器660通过总线630与电子设备600的其它模块通信。应当明白，尽管图中未示出，可以结合电子设备600使用其它硬件和/或软件模块，包括但不限于：微代码、设备驱动器、冗余处理单元、外部磁盘驱动阵列、RAID系统、磁带驱动器以及数据备份存储系统等。

应当注意，尽管在上文详细描述中提及了装置的若干模块或子模块，但是这种划分仅仅是示例性的并非强制性的。实际上，根据本公开的实施方式，上文描述的两个或更多单元/模块的特征和功能可以在一个单元/模块中具体化。反之，上文描述的一个单元/模块的特征和功能可以进一步划分为由多个单元/模块来具体化。

此外，尽管在附图中以特定顺序描述了本公开方法的操作，但是，这并非要求或者暗示必须按照该特定顺序来执行这些操作，或是必须执行全部所示的操作才能实现期望的结果。附加地或备选地，可以省略某些步骤，将多个步骤合并为一个步骤执行，和/或将一个步骤分解为多个步骤执行。

虽然已经参考若干具体实施方式描述了本公开的精神和原理，但是应该理解，本公开并不限于所公开的具体实施方式，对各方面的划分也不意味着这些方面中的特征不能组合以进行受益，这种划分仅是为了表述的方便。本公开旨在涵盖所附权利要求的精神和范围内所包括的各种修改和等同布置。