配置文件的推送方法、装置、服务器及存储介质与流程

本申请涉及计算机技术领域，更具体地，涉及一种配置文件的推送方法、装置、服务器及存储介质。

背景技术：

在终端设备的应用程序的使用中，通常将应用程序的使用频繁的方法或代码作为热点代码，并预先对热点代码编译为二进制机器码，编译得到的二进制机器码可以用于在下次运行应用程序时直接由处理器执行，从而提升应用程序的运行速度。一些厂商通过对应用的热点代码进行搜集，并推送给用户的终端设备，但对于厂商的服务器而言，需要搜集和维护的热点代码数量较大。

技术实现要素：

鉴于上述问题，本申请提出了一种配置文件的推送方法、装置、服务器及存储介质。

第一方面，本申请实施例提供了一种配置文件的推送方法，应用于服务器，所述方法包括：接收终端设备发送的获取请求，所述获取请求用于获取第一目标应用的热点代码；响应所述获取请求，获取所述第一目标应用所属的应用类别；获取所述应用类别的多个应用中的第二目标应用对应的配置文件，所述第二目标应用为所述多个应用中当前存在配置文件的应用，所述配置文件至少包括热点代码；将所述第二目标应用对应的配置文件推送至所述终端设备，所述配置文件用于所述终端设备对所述热点代码进行预编译，获得编译文件。

第二方面，本申请实施例提供了一种配置文件的推送装置，应用于服务器，所述装置包括：请求接收模块、请求响应模块、文件获取模块以及文件推送模块，其中，所述请求接收模块用于接收终端设备发送的获取请求，所述获取请求用于获取第一目标应用的热点代码；所述请求响应模块用于响应所述获取请求，获取所述第一目标应用所属的应用类别；所述文件获取模块用于获取所述应用类别的多个应用中的第二目标应用对应的配置文件，所述第二目标应用为所述多个应用中当前存在配置文件的应用，所述配置文件至少包括热点代码；所述文件推送模块用于将所述第二目标应用对应的配置文件推送至所述终端设备，所述配置文件用于所述终端设备对所述热点代码进行预编译，获得编译文件。

第三方面，本申请实施例提供了一种服务器，包括：一个或多个处理器；存储器；一个或多个应用程序，其中所述一个或多个应用程序被存储在所述存储器中并被配置为由所述一个或多个处理器执行，所述一个或多个程序配置用于执行上述第一方面提供的配置文件的推送方法。

第四方面，本申请实施例提供了一种计算机可读取存储介质，所述计算机可读取存储介质中存储有程序代码，所述程序代码可被处理器调用执行上述第一方面提供的配置文件的推送方法。

本申请提供的方案，通过接收终端设备发送的获取请求，该获取请求用于获取第一目标应用的热点代码，响应获取请求，获取第一目标应用所属的应用类别，然后从应用类别的多个应用中获取第二目标应用对应的配置文件，该第二目标应用为多个应用中当前存在配置文件的应用，配置文件至少包括热点代码，再将第二目标应用对应的配置文件推送至终端设备，配置文件用于终端设备对热点代码进行预编译，获得编译文件，从而可以实现向终端设备推送属于同一类别的应用的热点代码的配置文件，减少服务器搜集和存储的配置文件的数量，进而减少服务器的负担。

附图说明

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

图1示出了本申请实施例提供的应用场景的一种示意图。

图2示出了本申请实施例提供的应用场景的另一种示意图。

图3示出了根据本申请一个实施例的配置文件的推送方法流程图。

图4示出了根据本申请另一个实施例的配置文件的推送方法流程图。

图5示出了根据本申请又一个实施例的配置文件的推送方法流程图。

图6示出了根据本申请再一个实施例的配置文件的推送方法流程图。

图7示出了根据本申请一个实施例的配置文件的推送装置的一种框图。

图8是本申请实施例的用于执行根据本申请实施例的配置文件的推送方法的服务器的框图。

图9是本申请实施例的用于保存或者携带实现根据本申请实施例的配置文件的推送方法的程序代码的存储单元。

具体实施方式

为了使本技术领域的人员更好地理解本申请方案，下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述。

安卓(android)有两种虚拟机执行环境：dalvik虚拟机和art虚拟机。在dalvik虚拟机的执行环境下，应用每次运行的时候，字节码都需要通过即时编译器(justintimecompilation，jit编译器)转换为机器码，才能被设备运行，这样会拖慢应用的执行效率。在android4.4版本时，art虚拟机开始替代dalvik虚拟机，在最开始的art虚拟机中，应用在第一次安装的时候，系统会通过一个名称为dex2oat的工具将apk中的dex文件编译成包含本地机器码的oat文件存放下来。这样做之后，在程序执行的时候，就可以直接使用已经编译好的机器码以加快效率，这种预先编译机器码的机制叫做运行前编译(aheadoftime，aot)。aot的缺点是应用安装和系统升级之后的应用优化过程比较耗时(需要重新将dex字节码编译成本地机器码)，且优化后的文件会占用额外的存储空间。

由于单纯的使用jit和aot都会对性能带来一定影响，为了更好的加快编译效率，提升用户体验，因此后来对其做了相应的调整，在art虚拟机的环境上，由原来的aot变为解释器(interpreter)+jit+aot混合编译，并引入了pgo机制，具体如下：应用在安装期间,系统不会对.dex文件进行aot编译；应用程序运行时，没有被热点识别过的代码(coldcode)会先通过java解析器被直接执行，在执行过程中当虚拟机发现某个方法或者代码块运行特别频繁时会将其认定为热点代码(hotcode)，经过jit编译后存储在缓存中，这样在下次启动应用时如果遇到这些代码，会优先从缓存中执行编译后的代码，另外，系统也会生成profile(配置)文件来记录热点函数的信息；除了jit编译之外，当设备空闲且处于充电状态时，aot编译器也会利用profile文件重新编译应用生成.oat文件，使得这些热点代码下次启动后不再需要在运行时进行jit优化。

利用pgo机制，一个应用中需要编译的代码只会是程序中最经常执行的那一部分java字节码，而不会是整个程序中的代码。这样的做法可以在较大限度地提升了程序的运行性能的同时，又尽量减少对应用安装速度和额外的空间占用的影响，减轻了单个jit或aot编译所可能带来的弊端。

在解释器+jit+aot混合编译的方案中，每当用户安装应用并初次使用时，该应用都是未经过优化的，只有在用户使用该应用一段时间后，系统才可以生成符合用户使用习惯的profile文件，从而优化应用，提升速度，这使得在首次使用应用时，应用的运行效率并未得到提升。另外，应用的profile文件只能针对当前版本的应用进行优化，如果应用的版本升级，那么就需要系统重新收集应用的profile文件来优化程序，如果应用升级的频率较快，那么这个应用实际上被优化的时间也会大大减少，因此这个优化机制对系统流畅性的提升较难达到理想水平。

因此，一些厂商从用户设备上收集应用的热点代码的profile文件并上传到云端，然后会对该应用的热点代码做整合，并生成一份通用的profile文件。每当有用户从应用商店下载应用时，会将该profile文件推送给用户，在安装过程中就会对应用进行编译。采用这种方法，用户在安装完应用后并初次使用时，便能体验到经过优化后的应用。

发明人经过研究发现，在厂商收集热点代码的profile文件的方案中，需要针对每个应用，从而大量用户的终端设备搜集热点代码的profile文件，这给服务器带来了巨大的负担。

针对上述问题，发明人提出了本申请实施例提供的配置文件的推送方法、装置、服务器及存储介质，通过在接收到终端设备发送的用于获取第一目标应用的热点代码的获取请求时，将与第一目标应用属于同个类别的第二目标应用的配置文件，该配置文件至少包括热点代码，然后将配置文件推送至终端设备，使终端设备可以对热点代码进行预编译，以获得用于运行第一目标应用时直接使用的编译文件，从而减少服务器搜集和存储的配置文件的数量，进而减少服务器的负担。其中，具体的配置文件的推送方法在后续的实施例中进行详细的说明。

下面对本申请实施例提供的应用场景进行介绍。

在一些实施方式中，请参阅图1，图1示出了本申请实施例提供的应用场景的一种示意图，该应用场景包括配置文件的推送系统10，该配置文件的推送系统10包括：终端设备100以及第一服务器200。其中，终端设备100与第一服务器200通过网络进行通信。终端设备100可以与第一服务器200进行数据交互，以从第一服务器200获取应用程序的安装包、编译文件等。

在另一些实施方式中，请参阅图2，图2示出了本申请实施例提供的应用场景的另一种示意图，配置文件的推送系统10也可以包括：终端设备100、第一服务器200以及第二服务器300。其中，终端设备100与第一服务器200之间进行数据交互，第一服务器200与第二服务器300之间也可以进行数据交互。第一服务器200可以用于处理终端设备100的请求，第二服务器300可以用于存储和管理应用程序的配置文件、安装包等文件，当终端设备100从第一服务器200获取应用程序的文件时，第一服务器200可以从第二服务器300获取应用程序的文件，并将应用程序的文件发送至终端设备100。另外，第一服务器200或者第二服务器300还可以对应用进行分类，以便针对同一类别的应用，将已有的配置文件进行推送。

当然，配置文件的推送系统10中也还可以包括其他的服务器。例如，配置文件的推送系统10还可以包括第三服务器，第三服务器可以用于从用户的终端设备收集应用程序的配置文件，并将收集的配置文件传输至第二服务器200进行整理和存储等；又例如，配置文件的推送系统10也还可以包括第四服务器，第四服务器可以用于存储和管理应用程序的安装包等，该情况下，可以由第二服务器200存储和管理应用程序的配置文件，实现应用程序的安装包与配置文件的单独进行管理和存储。

在一些实施方式中，上述的终端设备100可以为智能手机、平板电脑、电子书、智能手表等设备；第一服务器200、第二服务器300等服务器可以为传统服务器，也可以为云服务器，在此不做限定。

下面对本申请实施例提供的配置文件的推送方法进行详细介绍。

请参阅图3，图3示出了本申请一个实施例提供的配置文件的推送方法的流程示意图。该配置文件的推送方法可以应用于上述配置文件的推送系统中的服务器。下面将以服务器为例，说明本实施例的具体流程。下面将针对图3所示的流程进行详细的阐述，所述配置文件的推送方法具体可以包括以下步骤：

步骤s110：接收终端设备发送的获取请求，所述获取请求用于获取第一目标应用的热点代码。

在本申请实施例中，获取请求可以由终端设备生成，该获取请求用于获取第一目标应用的相应文件。在一些方式中，获取请求可以至少用于获取第一目标应用的热点代码。其中，该应用可以是终端设备未安装过的应用，也可以为终端设备此前已安装而未对热点代码进行过编译的应用，在此不做限定。

作为一种实施方式，终端设备可以根据用户的用户操作，生成上述获取请求，再发送至服务器，从而服务器接收到获取请求，例如，终端设备检测到在软件商店的界面中对第一目标应用的热点代码的获取操作，进而生成获取该第一目标应用的热点代码的获取请求。作为另一种实施方式，也可以是在第一目标应用安装完成后，未被使用之前，终端设备主动生成用于获取该第一目标应用的热点代码的获取请求后，再发送至服务器，从而服务器接收到获取请求。作为再一种实施方式，也可以是终端设备在下载应用时生成同时用于获取安装包和热点代码的获取请求，并发送至服务器，从而服务器接收到获取请求。

步骤s120：响应所述获取请求，获取所述第一目标应用所属的应用类别。

在本申请实施例中，服务器在接收到获取请求后，可以确定第一目标应用所属的应用类别。其中，服务器可以预先对多个应用进行分类，将特征相同的应用分类到同一应用类别。对于同一应用类别的应用，应用之间的功能热点类型是相似的，因此可以考虑将同一应用类别中的一个应用的热点代码推送至该应用类别中的另一应用。例如，对于购物类型的应用，功能模块(例如购物车、订单查询等)也有很多相似之处，其实现的代码也基本相同，因此可以用相同的热点代码进行推送。

在一些实施方式中，服务器对多个应用进行分类的方法可以利用机器学习的方法进行分类，例如采用k-means聚类方法、dbscan聚类方法等，具体进行分类的方法可以不作为限定。被服务器分类的多个应用可以为软件商城中存在的应用，也可以为市面上存在的应用，具体可以不作为限定。

步骤s130：获取所述应用类别的多个应用中的第二目标应用对应的配置文件，所述第二目标应用为所述多个应用中当前存在配置文件的应用，所述配置文件至少包括热点代码。

在本申请实施例中，服务器在确定出第一目标应用所属的应用类别之后，则可以从该应用类别对应的多个应用中，获取存在配置文件的应用，并可以从这些应用中，确定任一应用作为第二目标应用，并获取第二目标应用对应的配置文件。其中，配置文件中包括其对应的应用的热点代码，也就是上述的记录应用的热点代码的profile文件。

在一些实施方式中，当配置文件存储于该服务器时，该服务器可以直接从本地读取第二目标应用的配置文件；当配置文件存储于其他服务器，例如用于存储配置文件的云端等，也可以从其他服务器获取第二目标应用的配置文件。

步骤s140：将所述第二目标应用对应的配置文件推送至所述终端设备，所述配置文件用于所述终端设备对所述热点代码进行预编译，获得编译文件。

在本申请实施例中，服务器在获取到第二目标应用对应的配置文件之后，则可以将第二目标应用对应的配置文件推送至上述终端设备，以便发送获取请求的终端设备能够获取到第二目标应用对应的配置文件。服务器发送至终端设备的配置文件，配置文件中包括有热点代码，配置文件可以指示终端设备对热点代码进行预编译，并将预编译得到的编译文件进行存储。由于推送给终端设备的配置文件为与第一目标应用属于同一应用类别的第二目标应用的配置文件，因此终端设备根据配置文件对热点代码进行预编译，获得的编译文件，当终端设备在运行第一目标应用时，可以直接执行编译文件中的二进制的机器代码，提升运行第一目标应用的效率。

本申请实施例提供的配置文件的推送方法，通过接收终端设备发送的获取请求，该获取请求用于获取第一目标应用的热点代码，响应获取请求，获取第一目标应用所属的应用类别，然后获取应用类别的多个应用中获取第二目标应用对应的配置文件，该第二目标应用为多个应用中当前存在配置文件的任一应用，配置文件至少包括热点代码，再将第二目标应用对应的配置文件推送至终端设备，配置文件用于终端设备对热点代码进行预编译，获得编译文件，从而可以实现向终端设备推送属于同一类别的应用的热点代码的配置文件，因此，对于同一个应用类别中的多个应用，服务器仅需搜集和存储其中一个应用的配置文件，即可对用户推送该应用类别中其他应用的配置文件，减少服务器搜集和存储的配置文件的数量，进而减少服务器的负担。

请参阅图4，图4示出了本申请另一个实施例提供的配置文件的推送方法的流程示意图。该配置文件的推送方法可以应用于上述配置文件的推送系统中的服务器。下面将针对图4所示的流程进行详细的阐述，所述配置文件的推送方法具体可以包括以下步骤：

步骤s210：获取多个应用中每个应用的特征。

在本申请实施例中，服务器可以预先对多个应用进行分类。具体地，服务器可以预先获取多个应用中每个应用的特征，以便根据应用的特征，对多个应用进行聚类。其中，应用的特征可以包括应用的功能、使用方法、适用年龄、应用的热度、应用的类型等，具体的特征可以不作为限定。

步骤s220：根据所述每个应用的特征，对所述多个应用进行聚类，获得多个应用类别。

在本申请实施例中，服务器在获取每个应用的特征之后，则可以根据每个应用的特征，对多个应用进行聚类，从而得到一个或多个应用类别。其中，服务器根据应用的特征对多个应用进行聚类的方法，可以是利用神经网络进行聚类，也可以采用k-means聚类方法进行聚类，dbscan聚类方法等，具体进行聚类的方法可以不作为限定。

在一些实施方式中，服务器根据每个应用的特征，对多个应用进行聚类，可以包括：根据每个应用的特征，建立每个应用的应用画像；根据应用画像，对多个应用进行聚类，获得多个应用类别。可以理解的，应用画像由于根据应用的特征进行建立，因此可以反映应用的特点，从而服务器可以根据应用的应用画像，对应用进行聚类。通过建立应用的应用画像，而对应用进行聚类，可以便于聚类时的计算和处理，例如，可以直接将应用画像量化成向量，然后对向量进行聚类，得到聚类结果，减少了对每个应用的多个特征进行处理时的难度。

步骤s230：接收终端设备发送的获取请求，所述获取请求用于获取第一目标应用的热点代码。

步骤s240：响应所述获取请求，获取所述第一目标应用所属的应用类别。

步骤s250：获取所述应用类别的多个应用中的第二目标应用对应的配置文件，所述第二目标应用为所述多个应用中当前存在配置文件的应用，所述配置文件至少包括热点代码。

步骤s260：将所述第二目标应用对应的配置文件推送至所述终端设备，所述配置文件用于所述终端设备对所述热点代码进行预编译，获得编译文件。

在本申请实施例中，步骤s230至步骤s260可以参阅前述实施例的内容，在此不再赘述。

步骤s270：接收所述终端设备发送的新的配置文件，将所述新的配置文件作为第一配置文件，并将推送至所述终端设备的配置文件作为第二配置文件。

在一些实施方式中，在将第二目标应用的配置文件推送给终端设备后使得终端设备对配置文件中的热点代码进行编译后，供第一目标应用运行时直接执行编译后的机器代码。而由于可能存在应用分类时不准确的问题，可能导致根据第二目标应用的配置文件进行编译的文件，第一目标应用并不能使用或者不能全部使用，因此会记录到大量的新的热点代码，终端设备可以将包括新的热点代码的配置文件，发送至服务器，从而服务器可以接收到新的配置文件。

步骤s280：根据所述第一配置文件以及所述第二配置文件，对所述第一目标应用所属的应用类别进行校正。

在本申请实施例中，当服务器接收到新的配置文件(即第一配置文件)时，则可以根据第一配置文件以及第二配置文件，对第一目标应用所属的应用类别进行校正，以校正对多个应用进行分类时的错误。

在一些实施方式中，根据第一配置文件以及第二配置文件，对第一目标应用所属的应用类别进行校正，可以包括：比较所述第一配置文件中的热点代码与所述第二配置文件中的热点代码的差异，获得差异结果；根据所述差异结果，对所述第一目标应用所属的应用类别进行校正。

其中，服务器对第一配置文件中的热点代码以及第二配置文件中的热点代码进行差异比较之后，可以是比较不同的热点代码，以及不同的热点代码所占的比例。服务器在获得到差异比较的差异结果之后，可以根据差异结果，确定第一目标应用所属的应用类别是否准确，如果不准确，则可以采用其他聚类方法，再进行聚类，以克服聚类不准确的问题；也可以根据第一目标应用的特征，计算第一目标应用与其他应用类别中应用的相似度，将相似度大于一定阈值的应用所属的应用类别，作为第一目标应用所属的应用类别；服务器也可以计算第一目标应用对应的特征向量与各个聚类中心之间的距离，然后将距离最近的聚类中心所对应的应用类别，作为第一目标应用所属的应用类别。当然，具体对聚类进行校正的方式可以不作为限定。通过以上校正，可以使得后续其他终端设备获取第一目标应用的配置文件时，能够获取到准确的配置文件，提升推送的准确度。

本申请实施例提供的配置文件的推送方法，通过获取多个应用中每个应用的特征，根据应用的特征，对多个应用进行分类，得到多个应用类别，以便服务器能够根据多个应用类别，进行配置文件的推送。另外，根据终端设备发送的新的配置文件，进行应用分类的校正，可以提升推送的准确度。

请参阅图5，图5示出了本申请又一个实施例提供的配置文件的推送方法的流程示意图。该配置文件的推送方法可以应用于上述配置文件的推送系统中的服务器。下面将针对图5所示的流程进行详细的阐述，所述配置文件的推送方法具体可以包括以下步骤：

步骤s310：获取多个应用中每个应用的特征。

步骤s320：根据所述每个应用的特征，对所述多个应用进行聚类，获得多个应用类别。

步骤s330：接收终端设备发送的获取请求，所述获取请求用于获取第一目标应用的热点代码。

步骤s340：响应所述获取请求，获取所述第一目标应用所属的应用类别。

步骤s350：获取所述应用类别的多个应用中的第二目标应用对应的配置文件，所述第二目标应用为所述多个应用中当前存在配置文件的应用，所述配置文件至少包括热点代码。

在本申请实施例中，步骤s310至步骤s350可以参阅前述实施例的内容，在此不再赘述。

在本申请实施例中，服务器还可以预先获取第二目标应用的配置文件，该配置文件的推送方法还可以包括：接收其他终端发送的第二目标应用的配置文件，并将配置文件进行存储。可以理解的，服务器可以从其他终端搜集第二目标应用的配置文件，并将第二目标应用的配置文件进行存储，以便将该配置文件推送至中的设备，供第二目标应用所属应用类别中其他应用使用。其中，该服务器可以为用于处理上述获取请求的服务器，也可以为用于存储配置文件的其他服务器，在此不做限定，

在一些实施方式中，由于一个应用类别中通常存在多个应用，并且服务器可能搜集到同一个应用类别中至少两个应用的配置文件，因此服务器还可以对不同应用的配置文件进行整合，并将整合后的配置文件作为至少两个应用的配置文件。其中，对不同应用的配置文件进行整合，可以是对配置文件中的热点代码求并集，并重新生成包括该并集的配置文件。当然，具体进行整合的方式可以不作为限定，对同一应用类别中至少两个应用的配置文件进行整合，可以后续用于推送的配置文件更加全面和准确。

步骤s360：将所述第二目标应用对应的配置文件推送至所述终端设备，所述配置文件用于所述终端设备对所述热点代码进行预编译，获得编译文件。

在本申请实施例中，步骤s360可以参阅前述实施例的内容，在此不再赘述。

步骤s370：接收所述终端设备发送的第一运行时长，所述第一运行时长为所述终端设备根据所述编译文件，对所述第一目标应用进行运行时的运行时长。

在本申请实施例中，服务器可以获取按照传统的方式(即自行记录热点代码进行预编译的方式)获得的第一目标应用的热点代码，作为目标热点代码。也可以根据终端设备利用以上编译文件，在运行第一目标应用的目标热点代码时，记录的运行时长，以及终端设备对目标热点代码进行预编译，根据该方式下预编译的编译文件，在运行第一目标应用的目标热点代码时，记录的运行时长，确定对应用的分类是否准确。具体地，服务器可以接收终端设备发送的第一运行时长，该第一运行时长为终端设备根据编译文件，对第一目标应用的目标热点代码进行运行时，记录的运行时长。

步骤s380：接收其他终端发送的第二运行时长，所述第二运行时长为所述其他终端对所述第一目标应用对应的热点代码进行预编译后，根据预编译得到的编译文件对所述第一目标应用进行运行时的运行时长。

在本申请实施例中，服务器还可以获取终端设备采用解释器+jit+aot混合编译的方式，根据该方式获得的编译文件，对第一目标应用的以上目标热点代码运行时记录的第二运行时长。

步骤s390：比较所述第一运行时长以及所述第二运行时长，并根据比较结果对所述第一目标应用所属的应用类别进行校正。

在本申请实施例中，上述第二运行时长，由于是根据用户在使用第一目标应用时记录的热点代码进行预编译后，根据预编译的编译文件，对第一目标应用的目标热点代码进行运行，而记录的运行时长，因此第二运行时长具有较高的参考性，也就是说，第二运行时长是较为准确的。而第一运行时长，是根据第二目标应用的配置文件进行预编译后，根据预编译的编译文件，对第一目标应用的目标热点代码进行运行而记录的运行时长，由于应用分类存在误差，可能存在优化不足的问题。因此，服务器可以比较第一运行时长以及第二运行时长，如果第二运行时长小于第一运行时长，则表示当前的应用分类存在准确性不足的问题，因此可以换其他聚类方法，再进行聚类，以对第一目标应用所属的应用类别进行校正。

其中，在换其他聚类方法进行聚类后，如果第一目标应用所属的应用类别发生变化，可以将第一目标应用所属的新的应用类别中任一应用的配置文件，发送至终端设备，终端设备可以根据该配置文件进行预编译，并根据预编译得到的编译文件，运行第一目标应用的上述目标热点代码，记录得到第三运行时长，然后再比较第三运行时长以及第二运行时长，如果第三运行时长等于第二运行时长，或者第三运行时长与第二运行时长的差值小于一定阈值，则表示新的应用类别中任一应用的配置文件中的热点代码已经较为准确，因此，可以将该新的应用类别作为校正后的应用类别，用于后续对第一目标应用的配置文件的推送。

本申请实施例提供的配置文件的推送方法，通过获取多个应用中每个应用的特征，根据应用的特征，对多个应用进行分类，得到多个应用类别，以便服务器能够根据多个应用类别，进行配置文件的推送。另外，根据第一运行时长以及第二运行时长，对第一目标应用所属的应用分类的校正，第一运行时长为根据终端设备发送的通过推送的配置文件进行预编译后，记录的第一目标应用运行时的运行时长，第二运行时长为按照自行记录热点代码的方式，将自行记录的热点代码进行预编译后，记录的第二目标应用运行时的运行时长，从而可以提升推送的准确度。

请参阅图6，图6示出了本申请再一个实施例提供的配置文件的推送方法的流程示意图。该配置文件的推送方法可以应用于上述配置文件的推送系统中的服务器。下面将针对图6所示的流程进行详细的阐述，所述配置文件的推送方法具体可以包括以下步骤：

步骤s410：接收终端设备发送的获取请求，所述获取请求用于获取第一目标应用的热点代码，所述获取请求还用于获取所述第一目标应用的安装包。

在本申请实施例中，终端设备发送的获取请求，还可以用于获取第一目标应用的安装包，也就是说，该获取请求用于同时获取第一目标应用的安装包以及热点代码。

步骤s420：响应所述获取请求，获取所述第一目标应用所属的应用类别。

步骤s430：获取所述应用类别的多个应用中的第二目标应用对应的配置文件，所述第二目标应用为所述多个应用中当前存在配置文件的应用，所述配置文件至少包括热点代码。

步骤s440：将所述第二目标应用的安装包以及所述第二目标应用对应的配置文件发送至所述终端设备，所述热点代码用于指示所述终端设备在根据所述安装包对所述第一目标应用进行安装的同时，对所述热点代码进行预编译，并将预编译后获得的编译文件进行存储。

在本申请实施例中，服务器可以在向终端设备返回文件时，可以同时将第二目标应用的安装包以及第二目标应用的配置文件发送至终端设备，安装包用于终端设备对第一目标应用进行安装，而该配置文件则可以指示终端设备在对第一目标应用安装的同时，对热点代码进行编译，并将预编译后获得的编译文件进行存储，从而实现安装应用的同时，对热点代码进行了预编译，使第一目标应用在第一次运行时，即可得到运行效率的提升。

步骤s450：将所述多个应用类别以及每个应用类别中至少一个应用对应的配置文件发送至所述终端设备，所述配置文件用于所述终端设备在安装同一应用类别的应用时，对所述配置文件中的热点代码进行预编译，获得编译文件。

在本申请实施例中，服务器还可以将对多个应用进行分类后的多个应用类别，以及每个应用类别中至少一个应用对应的配置文件发送至终端设备，这样，终端设备后续在安装新的应用时，可以直接根据所属的应用类别，确定配置文件，并对配置文件中的热点代码进行预编译，得到编译文件，从而无需终端设备从服务器获取配置文件，而直接可以根据本地存储的配置文件，进行热点代码的预编译。

本申请实施例提供的配置文件的推送方法，通过接收终端设备发送的获取请求，该获取请求用于获取第一目标应用的热点代码以及安装包，响应获取请求，获取第一目标应用所属的应用类别，然后获取应用类别的多个应用中获取第二目标应用对应的配置文件，该第二目标应用为多个应用中当前存在配置文件的任一应用，配置文件至少包括热点代码，再将第二目标应用对应的配置文件以及安装包同时推送至终端设备，配置文件用于终端设备根据安装包对第一目标应用进行安装时，同时对热点代码进行预编译，获得编译文件，从而可以实现向终端设备推送属于同一类别的应用的热点代码的配置文件，因此，对于同一个应用类别中的多个应用，服务器仅需搜集和存储其中一个应用的配置文件，即可对用户推送该应用类别中其他应用的配置文件，减少服务器搜集和存储的配置文件的数量，进而减少服务器的负担。

请参阅图7，其示出了本申请实施例提供的一种配置文件的推送装置400的结构框图。该配置文件的推送装置400可以应用于上述配置文件的推送系统中的服务器。该配置文件的推送装置400包括：请求接收模块410、请求响应模块420、文件获取模块430以及文件推送模块440。其中，所述请求接收模块410用于接收终端设备发送的获取请求，所述获取请求用于获取第一目标应用的热点代码；所述请求响应模块420用于响应所述获取请求，获取所述第一目标应用所属的应用类别；所述文件获取模块430用于获取所述应用类别的多个应用中的第二目标应用对应的配置文件，所述第二目标应用为所述多个应用中当前存在配置文件的应用，所述配置文件至少包括热点代码；所述文件推送模块440用于将所述第二目标应用对应的配置文件推送至所述终端设备，所述配置文件用于所述终端设备对所述热点代码进行预编译，获得编译文件。

在一些实施方式中，该配置文件的推送装置400还可以包括：特征获取模块以及应用聚类模块。特征获取模块用于在所述响应所述获取请求，获取所述第一目标应用所属的应用类别之前，获取多个应用中每个应用的特征；应用聚类模块用于根据所述每个应用的特征，对所述多个应用进行聚类，获得多个应用类别。

在该实施方式下，应用聚类模块包括：画像获取单元，用于根据所述每个应用的特征，建立所述每个应用的应用画像；聚类执行单元，用于根据所述应用画像，对所述多个应用进行聚类，获得多个应用类别。

在该实施方式下，该配置文件的推送装置400还可以包括：文件接收模块，用于在将所述第二目标应用对应的热点代码推送至所述终端设备之后，接收所述终端设备发送的新的配置文件，将所述新的配置文件作为第一配置文件，并将推送至所述终端设备的配置文件作为第二配置文件；聚类校正模块，用于根据所述第一配置文件以及所述第二配置文件，对所述第一目标应用所属的应用类别进行校。

进一步的，聚类校正模块可以包括：差异比较单元，用于比较所述第一配置文件中的热点代码与所述第二配置文件中的热点代码的差异，获得差异结果；校正执行单元，用于根据所述差异结果，对所述第一目标应用所属的应用类别进行校正。

在一些实施方式中，该配置文件的推送装置400还可以包括：第一时长接收模块、第二时长接收模块以及校正模块。第一时长接收模块用于接收所述终端设备发送的第一运行时长，所述第一运行时长为所述终端设备根据所述编译文件，对所述第一目标应用进行运行时的运行时长；第二时长接收模块用于接收其他终端发送的第二运行时长，所述第二运行时长为所述其他终端对所述第一目标应用对应的热点代码进行预编译后，根据预编译得到的编译文件对所述第一目标应用进行运行时的运行时长；校正模块用于比较所述第一运行时长以及所述第二运行时长，并根据比较结果对所述第一目标应用所属的应用类别进行校正。

在一些实施方式中，该配置文件的推送装置400还可以包括：类别发送模块。类别发送模块用于将所述多个应用类别以及每个应用类别中至少一个应用对应的配置文件发送至所述终端设备，所述配置文件用于所述终端设备在安装同一应用类别的应用时，对所述配置文件中的热点代码进行预编译，获得编译文件。

在一些实施方式中，该配置文件的推送装置400还可以包括：文件存储模块。文件存储模块用于在所述获取所述应用类别的多个应用中获取第二目标应用对应的配置文件之前，接收其他终端发送的所述第二目标应用的配置文件，并将所述配置文件进行存储。

在一些实施方式中，所述获取请求还用于获取所述第一目标应用的安装包。该配置文件的推送装置400还可以包括：安装包发送模块。安装包发送模块用于将所述第二目标应用的安装包发送至所述终端设备，所述热点代码用于指示所述终端设备在根据所述安装包对所述第一目标应用进行安装的同时，对所述热点代码进行预编译，并将预编译后获得的编译文件进行存储。

所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，上述描述装置和模块的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。

在本申请所提供的几个实施例中，模块相互之间的耦合可以是电性，机械或其它形式的耦合。

另外，在本申请各个实施例中的各功能模块可以集成在一个处理模块中，也可以是各个模块单独物理存在，也可以两个或两个以上模块集成在一个模块中。上述集成的模块既可以采用硬件的形式实现，也可以采用软件功能模块的形式实现。

综上所述，本申请提供的方案，通过接收终端设备发送的获取请求，该获取请求用于获取第一目标应用的热点代码，响应获取请求，获取第一目标应用所属的应用类别，然后获取应用类别的多个应用中获取第二目标应用对应的配置文件，该第二目标应用为多个应用中当前存在配置文件的任一应用，配置文件至少包括热点代码，再将第二目标应用对应的配置文件推送至终端设备，配置文件用于终端设备对热点代码进行预编译，获得编译文件，从而可以实现向终端设备推送属于同一类别的应用的热点代码的配置文件，减少服务器搜集和存储的配置文件的数量，进而减少服务器的负担。

请参考图8，其示出了本申请实施例提供的一种服务器的结构框图。该服务器100可以是传统服务器、云服务器等能够运行应用程序的服务器。本申请中的服务器100可以包括一个或多个如下部件：处理器110、存储器120、以及一个或多个应用程序，其中一个或多个应用程序可以被存储在存储器120中并被配置为由一个或多个处理器110执行，一个或多个程序配置用于执行如前述方法实施例所描述的方法。

处理器110可以包括一个或者多个处理核。处理器110利用各种接口和线路连接整个服务器100内的各个部分，通过运行或执行存储在存储器120内的指令、程序、代码集或指令集，以及调用存储在存储器120内的数据，执行服务器100的各种功能和处理数据。可选地，处理器110可以采用数字信号处理(digitalsignalprocessing，dsp)、现场可编程门阵列(field－programmablegatearray，fpga)、可编程逻辑阵列(programmablelogicarray，pla)中的至少一种硬件形式来实现。处理器110可集成中央处理器(centralprocessingunit，cpu)、图像处理器(graphicsprocessingunit，gpu)和调制解调器等中的一种或几种的组合。其中，cpu主要处理操作系统、用户界面和应用程序等；gpu用于负责显示内容的渲染和绘制；调制解调器用于处理无线通信。可以理解的是，上述调制解调器也可以不集成到处理器110中，单独通过一块通信芯片进行实现。

存储器120可以包括随机存储器(randomaccessmemory，ram)，也可以包括只读存储器(read-onlymemory)。存储器120可用于存储指令、程序、代码、代码集或指令集。存储器120可包括存储程序区和存储数据区，其中，存储程序区可存储用于实现操作系统的指令、用于实现至少一个功能的指令(比如触控功能、声音播放功能、图像播放功能等)、用于实现下述各个方法实施例的指令等。存储数据区还可以存储服务器100在使用中所创建的数据等。

请参考图9，其示出了本申请实施例提供的一种计算机可读存储介质的结构框图。该计算机可读介质800中存储有程序代码，所述程序代码可被处理器调用执行上述方法实施例中所描述的方法。

计算机可读存储介质800可以是诸如闪存、eeprom(电可擦除可编程只读存储器)、eprom、硬盘或者rom之类的电子存储器。可选地，计算机可读存储介质800包括非易失性计算机可读介质(non-transitorycomputer-readablestoragemedium)。计算机可读存储介质800具有执行上述方法中的任何方法步骤的程序代码810的存储空间。这些程序代码可以从一个或者多个计算机程序产品中读出或者写入到这一个或者多个计算机程序产品中。程序代码810可以例如以适当形式进行压缩。

最后应说明的是：以上实施例仅用以说明本申请的技术方案，而非对其限制；尽管参照前述实施例对本申请进行了详细的说明，本领域的普通技术人员当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换；而这些修改或者替换，并不驱使相应技术方案的本质脱离本申请各实施例技术方案的精神和范围。