CN117055937A - 一种应用程序的更新方法、装置、电子设备及存储介质 - Google Patents

Abstract

本申请适用于数据处理技术领域，提供了一种应用程序的更新方法、装置、电子设备及存储介质，方法包括：响应于终端发起的关于应用程序的更新请求，确定安装于所述终端的所述应用程序的第一应用版本；基于所述应用程序当前的第二应用版本与所述第一应用版本的版本偏差，从云端存储的所述应用程序的更新数据库中提取所述版本偏差对应的增量更新文件；基于所述增量更新文件更新所述应用程序至所述第二应用版本。采用上述方法无需获取整个更新数据包，而是根据版本偏差的情况，获取与之对应的增量更新文件即可，大大减少了重复内容的下载过程，提高了应用更新的效率。

Description

一种应用程序的更新方法、装置、电子设备及存储介质

技术领域

本申请属于数据处理技术领域，尤其涉及一种应用程序的更新方法、装置、电子设备及存储介质。

背景技术

随着电子化进程的不断推进，越来越多服务可以通过安装于终端内的应用程序实现，大大提高了用户的操作效率。为了满足用户日益变化的服务需求，安装于终端内的应用程序的更新速度也随之增加。因此，如何能够有效地对终端内的应用程序进行更新，则直接影响用户的使用体验。

现有的应用程序的管理技术，在对应用程序进行更新时，一般需要通过管理应用下载应用程序的整个更新数据包，并通过该更新数据包对应用程序进行更新，并且需要应用程序处于关闭的情况下才能够完成更新操作，下载更新数据包所需的时间较长，降低了更新效率，影响了用户操作的流畅性。

发明内容

本申请实施例提供了一种应用程序的更新方法、装置、电子设备及存储介质，可以解决现有的应用程序的管理技术，在对应用程序进行更新时，一般需要通过管理应用下载应用程序的整个更新数据包，并通过该更新数据包对应用程序进行更新，并且需要应用程序处于关闭的情况下才能够完成更新操作，下载更新数据包所需的时间较长，更新效率低的问题。

第一方面，本申请实施例提供了一种应用程序的更新方法，包括：

响应于终端发起的关于应用程序的更新请求，确定安装于所述终端的所述应用程序的第一应用版本；所述更新请求是在所述应用程序处于预设状态时生成的；所述预设状态包括应用程序运行状态；

基于所述应用程序当前的第二应用版本与所述第一应用版本的版本偏差，从云端存储的所述应用程序的更新数据库中提取所述版本偏差对应的增量更新文件；

基于所述增量更新文件更新所述应用程序至所述第二应用版本。

在第一方面的一种可能的实现方式中，所述基于所述应用程序当前的第二应用版本与所述第一应用版本的版本偏差，从云端存储的所述应用程序的更新数据库中提取所述版本偏差对应的增量更新文件，包括：

获取所述应用程序的全量更新数据包；

根据所述第一应用版本的已有程序包与所述全量更新数据包，确定所述增量更新文件；

将所有所述增量更新文件进行封装，生成所述应用程序的增量更新数据包；

所述基于所述增量更新文件更新所述应用程序至所述第二应用版本，包括：

通过所述增量更新数据包更新所述应用程序至所述第二应用版本。

在第一方面的一种可能的实现方式中，所述更新方法应用于服务器；

在所述基于所述应用程序当前的第二应用版本与所述第一应用版本的版本偏差，从云端存储的所述应用程序的更新数据库中提取所述版本偏差对应的增量更新文件之前，还包括：

确定所述应用程序已发布的所有第三应用版本；每个所述第三应用版本关联有对应的应用更新内容；

基于所述应用更新内容，分别确定从第三应用版本更新至所述第二应用版本时需要更新的应用对象；所述应用对象包括所述应用程序内显示的对象；

根据从所述第三应用版本至所述第二应用版本之间的多个中间更新数据包，分别确定各个应用对象的更新代码内容；每个所述更新代码内容关联中间版本的版本编号；所述中间版本为所述第三应用版本至所述第二应用版本的版本；

基于所述版本编号，将所有所述更新代码内容导入对象更新模拟程序，生成从所述第三应用版本更新至所述第二应用版本过程中所述应用对象的目标更新代码；

根据所述第三应用版本对应的所有所述应用对象的目标更新代码，生成从所述第三应用版本更新至所述第二应用版本的候选增量文件；

基于所有所述候选增量文件对应的所述第三应用版本，生成所述应用程序的版本更新索引；所述版本更新索引用于基于所述第一应用版本搜索所述增量更新文件；所述版本更新索引记录有从所述第三应用版本更新至所述第二应用版本过程中需要更新的所有所述应用对象。

在第一方面的一种可能的实现方式中，在所述基于所有所述候选增量文件对应的所述第三应用版本，生成所述应用程序的版本更新索引之后，还包括：

若接收到将所述应用程序更新至第四应用版本的新增版本数据包，则确定所述第四应用版本与所述第二应用版本之间存在更新的更新应用对象；

基于所述新增版本数据包与所述第二应用版本的应用数据包，得到各个所述更新应用对象的新增更新代码；

通过所述版本更新索引，确定包含任一所述更新应用对象的所有第三应用版本；

基于所述新增更新代码，对包含任一所述更新应用对象的所述第三应用版本的所述候选增量文件进行更新，得到适配所述第四应用版本的更新增量文件；

基于所有所述更新增量文件更新所述版本更新索引，以使所述版本更新索引适用于所述第四应用版本。

在第一方面的一种可能的实现方式中，所述更新请求携带有所述终端的更新模式；

所述基于所述应用程序当前的第二应用版本与所述第一应用版本的版本偏差，从云端存储的所述应用程序的更新数据库中提取所述版本偏差对应的增量更新文件，包括：

若所述更新模式为第一更新模式，则根据所述版本更新索引，确定所述第一应用版本对应的所有第一应用对象；所述第一更新模式为所述终端的存储占用率小于预设的占用比例时的更新模式；

基于所有所述第一应用对象的所述目标更新代码，生成所述第一应用版本的所述增量更新文件；

若所述更新模式为第二更新模式，则获取安装于所述终端的所述应用程序的多个历史使用记录；所述第二更新模式为所述终端的存储占用率大于或等于所述占用比例时的更新模式；

基于所述多个历史使用记录中的操作对象，计算所述应用程序内各个应用对象的更新权重指标；

基于所述更新权重指标从所有所述应用对象中，选取第二应用对象；

基于所有所述第二应用对象的所述目标更新代码，生成所述第一应用版本的所述增量更新文件。

在第一方面的一种可能的实现方式中，所述基于所述多个历史使用记录中的操作对象，计算所述应用程序内各个应用对象的更新权重指标，包括：

根据所述存储占用率，确定所述终端对应的存储空间的预设加权系数；

基于所述历史使用记录中对应的操作时长以及所述操作对象关联的所述应用对象，计算每个所述应用对象的使用权重值；

根据每个所述应用对象的所述目标更新代码以及所述预设加权系数，分别计算各个所述应用对象的容量权重值；

获取所述终端中安装的应用列表，基于所述应用列表中与所述应用程序存在功能关联的其他应用的使用频率，计算每个所述应用对象的功能替代权重值；

基于所述功能替代权重值、所述使用权重值以及所述容量权重值，计算所述应用对象的所述更新权重指标。

在第一方面的一种可能的实现方式中，所述基于所述增量更新文件更新所述应用程序至所述第二应用版本，包括：

若终端处于前台运行所述应用程序的第一运行状态，则基于所述增量更新文件在第一图层上生成更新对象；所述第一图层在所述应用程序的操作界面的第二图层上；

在所述更新对象渲染完成的情况下，移除所述操作界面中所述更新对象对应的应用对象，并将所述更新对象添加到所述第二图层中的所述操作界面。

第二方面，本申请实施例提供了一种应用程序的更新装置，包括：

更新请求响应单元，用于响应于终端发起的关于应用程序的更新请求，确定安装于所述终端的所述应用程序的第一应用版本；所述更新请求是在所述应用程序处于预设状态时生成的；所述预设状态包括应用程序运行状态；

更新文件确定单元，用于基于所述应用程序当前的第二应用版本与所述第一应用版本的版本偏差，从云端存储的所述应用程序的更新数据库中提取所述版本偏差对应的增量更新文件；

应用更新单元，用于基于所述增量更新文件更新所述应用程序至所述第二应用版本。

第三方面，本申请实施例提供了一种电子设备，包括存储器、处理器以及存储在所述存储器中并可在所述处理器上运行的计算机程序，所述处理器执行所述计算机程序时实现如上述第一方面任一项所述的方法。

第四方面，本申请实施例提供了一种计算机可读存储介质，所述计算机可读存储介质存储有计算机程序，所述计算机程序被处理器执行时实现如上述第一方面任一项所述的方法。

第五方面，本申请实施例提供了一种计算机程序产品，当计算机程序产品在服务器上运行时，使得服务器执行上述第一方面中任一项所述的方法。

本申请实施例与现有技术相比存在的有益效果是：通过在需要对应用程序进行更新时，确定应用程序的第一应用版本，并通过比对当前最新发布的第二应用版本与第一应用版本之间的版本偏差，从云端获取对应的增量更新文件，无需下载整个应用程序的更新数据包，并通过增量更新文件对上述应用程序进行版本更新，以使终端本地安装的应用程序更新至云端发布的第二应用版本，实现了对应用程序进行更新的目的。与现有的应用程序管理技术相比，本申请实施例中的应用程序在需要进行更新时，可以无需获取整个更新数据包，而是根据版本偏差的情况，获取与之对应的增量更新文件即可，大大减少了重复内容的下载过程，提高了应用更新的效率，并且发起应用程序更新的过程可以在应用程序运行的过程中发起，也能够进一步提高了应用程序的更新及时性。

附图说明

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

图1是本申请实施例提供的一种应用程序的更新方法的实现示意图；

图2是本申请一实施例提供的原有的应用程序的更新过程与本申请提供的应用程序的更新过程的对比示意图；

图3是本申请第二实施例提供的一种应用程序的更新方法在S102和S103的具体实现流程图；

图4是本申请第三实施例提供的一种应用程序的更新方法在S102之前的具体实现流程图；

图5是本申请第四实施例提供的一种应用程序的更新方法S406之后的具体实现流程图；

图6是本申请第四实施例提供的一种应用程序的更新方法S102的具体实现流程图；

图7是本申请第五实施例提供的一种应用程序的更新方法S103的具体实现流程图；

图8是本申请实施例提供的应用程序的更新装置的结构示意图；

图9是本申请实施例提供的电子设备的结构示意图。

具体实施方式

以下描述中，为了说明而不是为了限定，提出了诸如特定系统结构、技术之类的具体细节，以便透彻理解本申请实施例。然而，本领域的技术人员应当清楚，在没有这些具体细节的其它实施例中也可以实现本申请。在其它情况中，省略对众所周知的系统、装置、电路以及方法的详细说明，以免不必要的细节妨碍本申请的描述。

应当理解，当在本申请说明书和所附权利要求书中使用时，术语“包括”指示所描述特征、整体、步骤、操作、元素和/或组件的存在，但并不排除一个或多个其它特征、整体、步骤、操作、元素、组件和/或其集合的存在或添加。

另外，在本申请说明书和所附权利要求书的描述中，术语“第一”、“第二”、“第三”等仅用于区分描述，而不能理解为指示或暗示相对重要性。

本申请实施例提供的应用程序的更新方法可以应用于服务器、智能手机、平板电脑、笔记本电脑、超级移动个人计算机(ultra-mobile personal computer，UMPC)、上网本等能够实现对应用程序进行更新的电子设备上。本申请实施例对电子设备的具体类型不作任何限制。其中，该电子设备可以为安装有应用程序的终端，如智能手机、平板电脑、智能手表等终端，在该情况下，电子设备可以从云端服务器处下载应用程序对应的增量更新文件，并通过增量更新文件对本地安装的应用程序进行更新。

在一种可能的实现方式中，上述电子设备还可以为响应更新请求的云端服务器，即应用程序对应的服务端，在该情况下，需要对应用程序的终端可以与云端服务器建立通信连接，并通过该通信连接向云端服务器发送更新请求，云端服务器可以将增量更新文件反馈给终端，终端在接收到增量更新文件后对本地的应用程序进行版本更新。

请参阅图1，图1示出了本申请实施例提供的一种应用程序的更新方法的实现示意图，该方法包括如下步骤：

在S101中，响应于终端发起的关于应用程序的更新请求，确定安装于所述终端的所述应用程序的第一应用版本；所述更新请求是在所述应用程序处于预设状态时生成的；所述预设状态包括应用程序运行状态。

在本实施例中，终端安装有一个或多个应用程序，若检测到本地安装的应用程序存在新发布的版本，即本地的应用程序的第一应用版本与云端服务器发布的第二应用版本之间存在版本差异，则判定该应用程序需要进行版本更新，则终端会生成该应用程序的更新请求。

在一种可能的实现方式中，终端可以设置有版本偏差阈值，若第一应用版本与第二应用版本之间的版本偏差小于上述的版本偏差阈值，则识别应用程序不升级也不会影响用户的正常功能使用，此时可以继续以第一应用版本的应用程序运行；反之，若上述两者之间的版本偏差大于或等于上述的版本偏差阈值，则可能会存在部分功能无法使用的情况，此时，终端会生成该应用程序的更新请求，以对该应用程序进行更新。

在本实施例中，终端在运行应用程序时，可以向应用程序对应的云端服务器发送一个版本查询请求，接收云端服务器反馈的当前发布的最新版本的第二应用版本，并将第一应用版本与第二应用版本进行比对，若两者存在差异，则生成上述的更新请求，并将携带有第一应用版本的更新请求发送给应用程序对应的云端服务器。

在本实施例中，该应用程序的热更新过程支持应用程序运行过程中对程序进行更新，因此，上述发起更新请求时，终端内运行的应用程序所处的预设状态包括应用程序运行状态。其中，上述预设状态还包括应用程序处于后台运行的状态，以及应用程序处于关闭状态，终端可以安装有程序管理应用，如应用商城、应用商店等，终端可以通过上述应用检测安装于本地的应用程序是否需要进行更新，若需要则可以向应用程序对应的云端服务器发送上述的更新请求。

需要说明的是，若上述S101的执行主体的电子设备为安装有应用程序的终端，则该终端接收到应用程序发起的更新请求后，确定该应用程序的第一应用版本，并将第一应用版本封装于更新请求中，并发送给云端服务器；若上述的电子设备为云端服务器，则云端服务器可以对更新请求进行解析，以提取该更新请求中携带有的第一应用版本。

在S102中，基于所述应用程序当前的第二应用版本与所述第一应用版本的版本偏差，从云端存储的所述应用程序的更新数据库中提取所述版本偏差对应的增量更新文件。

在本实施例中，电子设备在确定了安装于终端上的应用程序的第一应用版本后，会确定第一应用版本与应用程序当前发布的第二应用版本之间的版本偏差，示例性地，第一应用版本的版本编号为：Ver1.1.005，第二应用版本的版本编号为：Ver1.1.010，则表示上述两个版本之间相差了五个版本，电子设备可以根据上述两个应用版本之间的版本偏差，确定两个版本间对应的更新内容，并基于两个版本间的更新内容，生成对应的增量更新文件。

在本实施例中，电子设备可以于用于存储应用程序的更新数据包的云端服务器相连，根据第一应用版本与第二应用版本，从云端服务器存储的所有版本的更新数据中，提取与上述两个版本的版本偏差对应的增量更新文件。

若该电子设备为安装有应用程序的终端，则可以从云端服务器处下载对应的增量更新文件；可选地，终端可以从云端服务器处下载关于第二应用版本的整体更新文件，并通过于本地存储的第一应用版本的数据包进行对比，从而确定出两个版本之间的增量更新文件。

若该电子设备为云端服务器，则云端服务器可以从数据库中提取第二应用版本的整体更新文件以及第一应用版本的整体更新文件，通过对比两个版本的整体更新文件，从而确定存在更新的内容，继而得到对应的增量更新文件，并将增量更新文件反馈给终端。

在S103中，基于所述增量更新文件更新所述应用程序至所述第二应用版本。

在本实施例中，终端在获取得到用于更新应用程序的增量更新文件后，可以运行该增量更新文件，从而实现对应用程序进行更新的目的，无需重新下载应用程序整个更新数据包，继而提高了更新效率。

其中，终端在获取得到增量更新文件后，若该增量更新文件支持热更新模式，且终端当前正在运行上述应用程序，则可以通过热更新的方式对正在运行的应用程序进行更新，例如，更新内容均为index.jsbundle、图片资源、json配置文件等类型文件，则终端可以通过运行上述增量更新文件对上述更新内容进行替换，从而能够实现对应用程序的热更新的目的。

示例性地，图2示出了本申请一实施例提供的原有的应用程序的更新过程与本申请提供的应用程序的更新过程(即优化的更新过程)的对比示意图。参见图2所示，对于终端内原生的应用程序，该类型应用程序的更新是采用下载整个应用程序数据包(即全量更新书包)，并需要关闭应用程序后进行更新的；而对于本申请提供的热更新过程，可以下载增量更新文件，根据增量更新文件对应用程序进行热更新。

以上可以看出，本申请实施例提供的一种应用程序的更新方法通过在需要对应用程序进行更新时，确定应用程序的第一应用版本，并通过比对当前最新发布的第二应用版本与第一应用版本之间的版本偏差，从云端获取对应的增量更新文件，无需下载整个应用程序的更新数据包，并通过增量更新文件对上述应用程序进行版本更新，以使终端本地安装的应用程序更新至云端发布的第二应用版本，实现了对应用程序进行更新的目的。与现有的应用程序管理技术相比，本申请实施例中的应用程序在需要进行更新时，可以无需获取整个更新数据包，而是根据版本偏差的情况，获取与之对应的增量更新文件即可，大大减少了重复内容的下载过程，提高了应用更新的效率，并且发起应用程序更新的过程可以在应用程序运行的过程中发起，也能够进一步提高了应用程序的更新及时性。

图3示出了本申请第二实施例提供的一种应用程序的更新方法在S102和S103的具体实现流程图。参见图3，相对于图1所述实施例，本实施例提供的一种应用程序的更新方法中的电子设备为安装有应用程序的终端，上述更新方法中的S102包括：S1021～S1023，S103包括S1031，具体详述如下：

进一步地，所述基于所述应用程序当前的第二应用版本与所述第一应用版本的版本偏差，从云端存储的所述应用程序的更新数据库中提取所述版本偏差对应的增量更新文件，包括：

在S1021中，获取所述应用程序的全量更新数据包。

在本实施例中，终端在需要对应用程序进行热更新的过程中，可以向云端服务器发送携带有应用程序的程序标识的更新请求，云端服务器在接收到上述更新请求后，可以将第二应用版本对应的全量更新数据包发送给终端。

在一种可能的实现方式中，终端可以将第二应用版本的版本标号的更新请求发送给云端服务器，云端服务器在接收到更新请求的程序标识后，可以将第二应用版本的全量更新数据包的文件索引发送给终端，以便终端基于文件索引比对出存在更新的增量文件，由于索引相对于整个更新数据包而言，数据量较少，能够减少所需传输的数据量。

在S1022中，根据所述第一应用版本的已有程序包与所述全量更新数据包，确定所述增量更新文件。

在S1023中，将所有所述增量更新文件进行封装，生成所述应用程序的增量更新数据包。

在本实施例中，终端可以从本地获取第一应用版本的已有程序包，并对已有程序包进行解压，以确定第一文件列表；对应地，还可以对第二应用版本的全量更新数据包进行解压，以确定第二文件列表，若上述反馈的是文件索引，则可以根据文件索引同样确定得到第二文件列表。

在本实施例中，电子设备可以创建三个类型的文件夹，分别为全量文件夹、当前需求文件夹以及增量资源文件夹，电子设备可以通过对比第一文件列表以及第二文件列表中各个文件的内容以及修改时间，确定出第一应用版本与第二应用版本之间存在偏差的文件内容，以确定全量程序文件以及增量更新文件两个类型的，并根据文件的属性不同，从而将其存储于对应的文件夹内，得到全量更新数据包以及增量更新数据包。

具体地，确定两个文件列表内存在偏差的文件内容的方式可以为：使用python的hashlib模块，实现对传入的文件构造一个hashlib的对象并update对指定串进行加密后，从hexdigest获得串码的方法实现了文件的差异对比：文件的差异区分算法是实现增量更新的保障，通过遍历服务器和最新需求的全部资源文件，实现新旧两个文件差异部分的比对并输出比对后的新差异文件。

进一步地，所述基于所述增量更新文件更新所述应用程序至所述第二应用版本，包括：

在S1031中，通过所述增量更新数据包更新所述应用程序至所述第二应用版本。

在本实施例中，终端在确定存在偏差的文件内容后，可以将增量更新文件替换第一应用版本内的第一文件列表内对应已有文件，并添加存在新增的增量更新文件至已有程序包中，从而实现了对应用程序的热更新的目的。

在本申请实施例中，通过比对存在差异的文件，从而将存在更新的增量更新文件生成对应的增量更新数据包，从而能够实现对应用程序的热更新的目的，提高了更新效率。

图4示出了本申请第三实施例提供的一种应用程序的更新方法在S102之前的具体实现流程图。参见图4，相对于图1所述实施例，本实施例提供的一种应用程序的更新方法中的电子设备为应用程序的服务器，上述更新方法在S102之前，还包括：S401～S406，具体详述如下：

在S401中，确定所述应用程序已发布的所有第三应用版本；每个所述第三应用版本关联有对应的应用更新内容。

在本实施例中，服务器可以存储有应用程序所有已发布的第三应用版本的程序数据包，由于不同终端内安装的应用程序可以为任一已发布的第三应用版本，为了能够快速确定发起更新请求对应的增量更新文件，服务器可以构建对应的版本更新索引表，以确定各个已发布的第三应用版本与当前的第二应用版本之间的版本偏差。

在本实施例中，应用程序在发布一个程序版本时，往往会通过生成对应的更新内容列表，以描述本次版本更新过程中，对于应用程序内的哪些内容进行更新，如对某一图像或某一功能进行更新，将所有应用对象的更新信息进行封装，则得到该第三应用版本对应的应用更新内容。

在S402中，基于所述应用更新内容，分别确定从第三应用版本更新至所述第二应用版本时需要更新的应用对象；所述应用对象包括所述应用程序内显示的对象。

在本实施例中，服务器在确定了每个发布的第三应用版本对应的更新内容后，可以确定从任一第三应用版本至第二应用版本之间存在的中间版本，并基于上述第三应用版本与所有中间版本对应的应用更新内容，确定所有需要进行更新的应用对象。上述应用对象包括应用程序内显示的对象，如图像、控件、菜单栏等。可选地，上述应用对象还包括应用程序的程序功能、可跳转的链接以及菜单栏等。

示例性地，第三应用版本为Ver.1.1.002，而第二应用版本为Ver.1.1.010，则上述两个应用版本之间存在8个中间版本，服务器会确定上述8个中间版本的应用更新内容，确定每一个应用更新内容中所需更新的应用对象，将所有应用对象进行聚类整合，从而确定出从第三应用版本更新至第二应用版本所需更新的所有应用对象。

需要说明的是，上述对应用对象进行聚类整合具体为：对于在多个不同中间版本存在更新的应用对象识别为同一应用对象，并确定该应用对象在不同中间版本之间的对象更新内容。

在S403中，根据从所述第三应用版本至所述第二应用版本之间的多个中间更新数据包，分别确定各个应用对象的更新代码内容；每个所述更新代码内容关联中间版本的版本编号；所述中间版本为所述第三应用版本至所述第二应用版本的版本。

在本实施例中，服务器在确定了存在更新的应用对象后，可以从多个中间版本对应的中间更新数据包中，确定上述应用对象关联的更新代码内容，其中，不同的应用对象可以对应一个或多个更新文件，将所有更新文件中与该应用对象相关的代码进行提取，从而得到每个中间版本对应的更新代码内容，每个更新代码内容关联有一个中间版本的版本编号。

在S404中，基于所述版本编号，将所有所述更新代码内容导入对象更新模拟程序，生成从所述第三应用版本更新至所述第二应用版本过程中所述应用对象的目标更新代码。

在本实施例中，由于同一应用对象可能会在多个不同版本间进行不同程度的更新，为了能够提高后续目标更新代码的准确性，服务器会依据版本编号的次序，将该应用对象在不同中间版本的更新代码内容一次导入到对象更新模拟程序，以模拟该应用对象在中间版本变更的过程中其对应的时序更新情况，从而能够得到从第三应用版本更新至第二应用版本过程中该应用对象对应的目标更新代码。

示例性地，某一应用对象包含8个中间版本，如Ver.1.1.003～Ver.1.1.010，则服务器会先导入该应用对象在Ver.1.1.003更新代码内容至上述的对象更新模拟程序，从而能将上述应用对象从Ver.1.1.002，更新至Ver.1.1.003；继而再导入应用对象在Ver.1.1.004更新代码内容至上述的对象更新模拟程序，以此类推，直到将应用对象能够更新至第二应用版本，即Ver.1.1.010，从而通过上述对象更新模拟程序，能够生成从第三应用版本直接更新至第二应用版本对应的目标更新代码。

在S405中，根据所述第三应用版本对应的所有所述应用对象的目标更新代码，生成从所述第三应用版本更新至所述第二应用版本的候选增量文件。

在本实施例中，服务器在确定了第三应用版本中各个应用对象对应的目标更新代码后，可以对所有应用对象的目标更新代码进行封装，从而得到从第三应用版本更新至第二应用版本对应的候选增量文件，从而无需经过多个版本的迭代，能够直接从第三应用版本更新至第二应用版本，与此同时，也能够减少整个增量文件中两个版本之间的存在无需更新的内容，减少了增量文件的文件数据量。

在S406中，基于所有所述候选增量文件对应的所述第三应用版本，生成所述应用程序的版本更新索引；所述版本更新索引用于基于所述第一应用版本搜索所述增量更新文件；所述版本更新索引记录有从所述第三应用版本更新至所述第二应用版本过程中需要更新的所有所述应用对象。

在本实施例中，服务器在确定了各个已发布的第三应用版本对应的候选增联文件后，可以生成对应的版本更新索引表。示例性地，表1示出了本申请一实施例提供的版本更新索引表的示意图。参见表1所示，该索引表中记录有当前发布的版本编号，已经发布的历史版本的版本编号，每个历史版本可以关联有对应的增量更新文件，并记录该增联更新文件具体的更新内容，以便后续在进行更新时能够通过该版本更新索引，查询第一应用版本对应的增量更新文件，无需再次进行文件解析以及内容比对，提高了更新的效率。

表1

图5示出了本申请第四实施例提供的一种应用程序的更新方法S406之后的具体实现流程图。参见图5，相对于图4所述实施例，本实施例提供的一种应用程序的更新方法中在S406之后包括：S501～S505，具体详述如下：

在S501中，若接收到将所述应用程序更新至第四应用版本的新增版本数据包，则确定所述第四应用版本与所述第二应用版本之间存在更新的更新应用对象。

在本实施例中，服务器在生成上述版本更新索引后，若该应用程序发布新的应用版本，即上述第四应用版本，则服务器需要对上述的版本更新索引进行调整，以便在接收到更新请求后，可以基于上述版本更新索引，将安装于终端的应用程序更新至第四应用版本。其中，服务器会对上述第四应用版本的新增版本数据包进行解析，以确定其对应的文件列表，将第四应用版本的文件列表与第二应用版本的程序数据包解析得到的文件列表进行比对，确定存在更新的内容，以确定本次更新涉及的应用对象，即上述的更新应用对象。

在S502中，基于所述新增版本数据包与所述第二应用版本的应用数据包，得到各个所述更新应用对象的新增更新代码。

在本实施例中，服务器在确定两个版本之间的更新应用对象后，可以从新增版本数据包中提取与上述更新应用对象关联的第一更新代码，以及从第二应用版本中与对应的第二更新代码，通过上述两个更新代码的内容，生成该更新应用对象的新增更新代码，以便确定如何将该更新应用对象从第二应用版本的显示状态更新至第四应用版本对应的显示状态。

在S503中，通过所述版本更新索引，确定包含任一所述更新应用对象的所有第三应用版本。

在本实施例中，上述服务器的版本更新索引中，记录了从各个已发布的第三应用版本更新至第二应用版本时，所涉及更新的应用对象。若上述第三应用版本中涉及更新的应用对象中，存在上述更新应用对象，则表示需要对该第三应用版本中对应的应用对象进行调整，以使其代码内容能够与当前最新发布的版本一致；若某一第三应用版本中涉及的所有更新的应用对象，均不涉及上述更新应用对象，则表示为本次新增的内容，可以直接将该更新应用对象对应的代码文件添加至该第三应用版本中对应的增量更新数据包即可，无需重新确定增量更新文件。

在S504中，基于所述新增更新代码，对包含任一所述更新应用对象的所述第三应用版本的所述候选增量文件进行更新，得到适配所述第四应用版本的更新增量文件。

在本实施例中，服务器在确定了涉及更新应用对象的所有第三应用版本后，可以新增更新代码对第三应用版本对应的候选增量文件中与更新应用对象的代码内容进行更新，从而能够得到从第三应用版本更新至第四应用版本的更新增量文件，实现了在出现新版本时的及时更新。

在S505中，基于所有所述更新增量文件更新所述版本更新索引，以使所述版本更新索引适用于所述第四应用版本。

在本实施例中，服务器在确定了存在更新增量文本后，会将版本更新索引中的当前版本更新为第四应用版本，并根据更新增量文本中包含的更新应用对象，调整版本更新索引表中记录的更新的应用对象，实现对索引表的版本更新。

需要说明的是，由于存在新发布的第四应用版本，因此，上述版本更新索引中，会记录有从第二应用版本更新至第四应用版本的索引，并确定与之对应的增量更新文件。

在本申请实施例中，通过建立版本更新索引并在存在新版本时对其进行更新，能够实现版本回溯时确定存在更新的对象，并调整相应的代码内容，提高了更新效率以及版本维护的准确性。

图6示出了本申请第四实施例提供的一种应用程序的更新方法S102的具体实现流程图。参见图6，相对于图4所述实施例，本实施例提供的一种应用程序的更新方法中S102包括：S601～S606，具体详述如下：

在S601中，若所述更新模式为第一更新模式，则根据所述版本更新索引，确定所述第一应用版本对应的所有第一应用对象；所述第一更新模式为所述终端的存储占用率小于预设的占用比例时的更新模式。

在S602中，基于所有所述第一应用对象的所述目标更新代码，生成所述第一应用版本的所述增量更新文件。

在本实施例中，服务器在向终端反馈上述增量更新文件之前，需要确定该终端的存储占用率。若该存储占用率小于预设的占用比例，则终端可以将更新模式设置为第一更新模式，并将该模式标识添加到上述的更新请求内；若该存储占用率大于或等于预设的占用比例，则终端可以将更新模式设置为第二更新模式。服务器可以通过更新请求中的更新标识，确定终端的更新模式，并执行对应的更新流程。

可选地，该存储占用率可以携带于上述的更新请求中，服务器可以通过读取上述更新请求中对应的字段，以确定该终端的存储占用率是否大于预设的占用比例。

在本实施例中，由于终端处于第一更新模式，即终端的可用存储空间较多，可以对所有涉及更新的应用对象进行更新，无需进行部分对象更新，在该情况下，服务器会根据版本更新索引，确定第一应用版本对应的第三应用版本，并确定该第三应用版本在版本更新索引中记录的所有需要更新的应用对象，即上述的第一应用对象，并基于所有第一应用对象的目标更新代码生成增量更新文件，以实现全部应用对象的更新流程。

在本实施例中，终端在接收到包含所有第一应用对象的增量更新文件后，可以对本地的程序数据包进行更新，使第一应用版本更新至第二应用版本。

在S603中，若所述更新模式为第二更新模式，则获取安装于所述终端的所述应用程序的多个历史使用记录；所述第二更新模式为所述终端的存储占用率大于或等于所述占用比例时的更新模式。

在本实施例中，由于处于第二更新模式下，终端的可存储空间较少，在该情况下，若对应用程序中的所有需要更新的应用对象进行更新，可能会进一步增加终端的存储压力，为了避免上述情况的发生，服务器根据用户的使用习惯(即通过上述的历史使用记录)，需要从所有应用对象中选取迫切需要更新的应用对象。因此，服务器可以从用户数据库中提取该终端对应的使用应用程序的历史使用记录。该历史使用记录中携带有用户使用应用程序的使用时间信息、用户发起的操作对象信息等。

在S604中，基于所述多个历史使用记录中的操作对象，计算所述应用程序内各个应用对象的更新权重指标。

在本实施例中，服务器可以分别确定每个历史使用记录中用户发起交互操作的操作对象，并根据操作对象的操作时长、操作频率等特征值，导入预设的权重指标转换算法，分别计算应用程序中每个应用对象的更新权重指标，以确定用户经常使用或频繁使用的应用对象，以便后续进行个性化的部分对象更新，提高存储利用率的同时，也可以减少对用户使用影响。

进一步地，作为本申请的另一实施例，上述S604具体可以包含以下步骤：

步骤1：根据所述存储占用率，确定所述终端对应的存储空间的预设加权系数。

在本实施例中，服务器可以根据终端的存储占用率确定其对应的加权系数，以确定所需更新的第二应用对象的数量多少。其中，若存储占用率越大，则对应的加权系数越小；反之，若存储占用率越小，则对应的加权系数越大。服务器可以存储有对应的映射关系，以确定存储占用率对应的预设加权系数。

步骤2：基于所述历史使用记录中对应的操作时长以及所述操作对象关联的所述应用对象，计算每个所述应用对象的使用权重值。

在本实施例中，服务器可以根据历史使用记录中操作对象的操作时长，以及该操作对象在应用程序中涉及的应用对象，可以计算应用程序对应的使用权重值。其中，操作时长越长，对应的使用权重值越高；反之，操作时长越短，对应的使用权重值越低。需要说明的是，由于第二应用版本中可能存在新增的应用对象以及替换的应用对象，即原本历史使用记录中的操作对象，在第二应用版本中可能不存在一致的应用对象，在该情况下，服务器可以根据操作对象的对象类型以及功能类型，从第二应用版本中确定具有相同对象类型以及功能类型的应用对象，作为其关联的应用对象。

步骤3：根据每个所述应用对象的所述目标更新代码以及所述预设加权系数，分别计算各个所述应用对象的容量权重值。

在本实施例中，由于应用对象更新后的容量情况，也会直接影响终端的实际存储压力，因此，服务器在计算上述的更新权重值时，也可以根据应用对象的目标更新代码的数据量，计算得到对应的容量权重值。需要说明的是，目标更新代码的数据量与上述的容量权重值成反比例关系，即数据量越大，对应的容量权重值越小。

步骤4：获取所述终端中安装的应用列表，基于所述应用列表中与所述应用程序存在功能关联的其他应用的使用频率，计算每个所述应用对象的功能替代权重值。

在本实施例中，服务器可以获取安装于终端内其他应用程序的使用情况，确定本次更新的应用程序中某一应用对象提供的功能是否存在功能替代的其他应用，若存在功能相同的可替代的其他应用，且其他应用的使用频率较高，则对应的应用对象的更新权重指标较低；例如，某一应用程序中存在拍照功能的应用对象，而该终端内存在用户使用频率较高的其他拍照应用，则该功能可替代性较高，对应的功能替代权重较小。

步骤5：基于所述功能替代权重值、所述使用权重值以及所述容量权重值，计算所述应用对象的所述更新权重指标。

在本实施例中，服务器可以将上述计算得到多个权重值导入预设的指标转换算法，每个权重值可以对应有预设的加权因子，对多个权重值进行加权因子的叠加计算，得到上述的更新权重指标。

在本申请实施例中，通过获取多个维度的特征指标，确定应用程序中每个应用对象的更新权重指标，继而能够提高后续选取第二应用对象的准确性。

在S605中，基于所述更新权重指标从所有所述应用对象中，选取第二应用对象。

在本实施例中，服务器可以选取更新权重指标大于预设的权重阈值的应用对象，作为第二应用对象。

在S606中，基于所有所述第二应用对象的所述目标更新代码，生成所述第一应用版本的所述增量更新文件。

在本实施例中，服务器将第二应用对象的所有目标更新代码进行封装，得到增量更新文件，以对第一应用版本进行部分对象的更新，以使用户常用的第二应用对象与当前版本一致，实现个性化更新的目的。

在本申请实施例中，根据不同的更新模式生成对应的增量更新文件，提供了更新的准确性以及减少更新后对于终端存储资源的占用情况，提高了终端资源利用率。

图7示出了本申请第五实施例提供的一种应用程序的更新方法S103的具体实现流程图。参见图7，相对于图1-6任一项所述实施例，本实施例提供的一种应用程序的更新方法中S103包括：S701～S702，具体详述如下：

在S701中，若终端处于前台运行所述应用程序的第一运行状态，则基于所述增量更新文件在第一图层上生成更新对象；所述第一图层在所述应用程序的操作界面的第二图层上。

在S702中，在所述更新对象渲染完成的情况下，移除所述操作界面中所述更新对象对应的应用对象，并将所述更新对象添加到所述第二图层中的所述操作界面。

在本实施例中，终端更新应用程序的过程支持热更新模式，在获取得到增量更新文件时，若终端前台正在运行待更新的应用程序，即该应用程序处于上述的第一运行状态，则终端会采用热更新模式，通过运行增量更新文件，在第一图层内生成待更新的应用对象对应的更新对象，该更新对象会处于原本的操作界面的第二图层上，以对原本显示的应用对象进行遮挡。在更新对象渲染完成后，会删除第二图层中所需替换的应用对象，并将应用对象的代码更新为更新对象的目标更新代码，从而在移除原有的应用对象后，将更新对象添加到第二图层所在的操作界面中，从而实现了热更新的目的。

图8示出了本申请一实施例提供的一种应用程序的更新装置的结构框图，该评价报告的生成装置包括的各单元用于执行图1对应的实施例中生成装置实现的各步骤。具体请参阅图1与图1所对应的实施例中的相关描述。为了便于说明，仅示出了与本实施例相关的部分。

参见图8，所述一种应用程序的更新装置包括：

更新请求响应单元81，用于响应于终端发起的关于应用程序的更新请求，确定安装于所述终端的所述应用程序的第一应用版本；所述更新请求是在所述应用程序处于预设状态时生成的；所述预设状态包括应用程序运行状态；

更新文件确定单元82，用于基于所述应用程序当前的第二应用版本与所述第一应用版本的版本偏差，从云端存储的所述应用程序的更新数据库中提取所述版本偏差对应的增量更新文件；

应用更新单元83，用于基于所述增量更新文件更新所述应用程序至所述第二应用版本。

应当理解的是，图8示出的评价报告的生成装置的结构框图中，各模块用于执行图1至图7对应的实施例中的各步骤，而对于图1至图7对应的实施例中的各步骤已在上述实施例中进行详细解释，具体请参阅图1至图7以及图1至图7所对应的实施例中的相关描述，此处不再赘述。

图9是本申请另一实施例提供的一种电子设备的结构框图。如图9所示，该实施例的电子设备900包括：处理器910、存储器920以及存储在存储器920中并可在处理器910运行的计算机程序930，例如评价报告的生成方法的程序。处理器910执行计算机程序930时实现上述各个评价报告的生成方法各实施例中的步骤，例如图1所示的S101至S103。或者，处理器910执行计算机程序930时实现上述图9对应的实施例中各模块的功能，例如，图8所示的单元81至83的功能，具体请参阅图8对应的实施例中的相关描述。

示例性的，计算机程序930可以被分割成一个或多个模块，一个或者多个模块被存储在存储器920中，并由处理器910执行，以完成本申请。一个或多个模块可以是能够完成特定功能的一系列计算机程序指令段，该指令段用于描述计算机程序930在电子设备900中的执行过程。例如，计算机程序930可以被分割成各个单元模块，各模块具体功能如上。

电子设备900可包括，但不仅限于，处理器910、存储器920。本领域技术人员可以理解，图9仅仅是电子设备900的示例，并不构成对电子设备900的限定，可以包括比图示更多或更少的部件，或者组合某些部件，或者不同的部件，例如电子设备还可以包括输入输出设备、网络接入设备、总线等。

所称处理器910可以是中央处理单元，还可以是其他通用处理器、数字信号处理器、专用集成电路、现成可编程门阵列或者其他可编程逻辑器件、分立硬件组件等。通用处理器可以是微处理器或者是任何常规的处理器等。

存储器920可以是电子设备900的内部存储单元，例如电子设备900的硬盘或内存。存储器920也可以是电子设备900的外部存储设备，例如电子设备900上配备的插接式硬盘，智能存储卡，闪存卡等。进一步地，存储器920还可以既包括电子设备900的内部存储单元也包括外部存储设备。

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

Claims (10)

1.一种应用程序的更新方法，其特征在于，包括：

响应于终端发起的关于应用程序的更新请求，确定安装于所述终端的所述应用程序的第一应用版本；所述更新请求是在所述应用程序处于预设状态时生成的；所述预设状态包括应用程序运行状态；

基于所述应用程序当前的第二应用版本与所述第一应用版本的版本偏差，从云端存储的所述应用程序的更新数据库中提取所述版本偏差对应的增量更新文件；

基于所述增量更新文件更新所述应用程序至所述第二应用版本。

2.根据权利要求1所述的更新方法，其特征在于，所述基于所述应用程序当前的第二应用版本与所述第一应用版本的版本偏差，从云端存储的所述应用程序的更新数据库中提取所述版本偏差对应的增量更新文件，包括：

获取所述应用程序的全量更新数据包；

根据所述第一应用版本的已有程序包与所述全量更新数据包，确定所述增量更新文件；

将所有所述增量更新文件进行封装，生成所述应用程序的增量更新数据包；

所述基于所述增量更新文件更新所述应用程序至所述第二应用版本，包括：

通过所述增量更新数据包更新所述应用程序至所述第二应用版本。

3.根据权利要求1所述的更新方法，其特征在于，所述更新方法应用于服务器；

在所述基于所述应用程序当前的第二应用版本与所述第一应用版本的版本偏差，从云端存储的所述应用程序的更新数据库中提取所述版本偏差对应的增量更新文件之前，还包括：

确定所述应用程序已发布的所有第三应用版本；每个所述第三应用版本关联有对应的应用更新内容；

基于所述应用更新内容，分别确定从第三应用版本更新至所述第二应用版本时需要更新的应用对象；所述应用对象包括所述应用程序内显示的对象；

根据从所述第三应用版本至所述第二应用版本之间的多个中间更新数据包，分别确定各个应用对象的更新代码内容；每个所述更新代码内容关联中间版本的版本编号；所述中间版本为所述第三应用版本至所述第二应用版本的版本；

基于所述版本编号，将所有所述更新代码内容导入对象更新模拟程序，生成从所述第三应用版本更新至所述第二应用版本过程中所述应用对象的目标更新代码；

根据所述第三应用版本对应的所有所述应用对象的目标更新代码，生成从所述第三应用版本更新至所述第二应用版本的候选增量文件；

基于所有所述候选增量文件对应的所述第三应用版本，生成所述应用程序的版本更新索引；所述版本更新索引用于基于所述第一应用版本搜索所述增量更新文件；所述版本更新索引记录有从所述第三应用版本更新至所述第二应用版本过程中需要更新的所有所述应用对象。

4.根据权利要求3所述的更新方法，其特征在于，在所述基于所有所述候选增量文件对应的所述第三应用版本，生成所述应用程序的版本更新索引之后，还包括：

若接收到将所述应用程序更新至第四应用版本的新增版本数据包，则确定所述第四应用版本与所述第二应用版本之间存在更新的更新应用对象；

基于所述新增版本数据包与所述第二应用版本的应用数据包，得到各个所述更新应用对象的新增更新代码；

通过所述版本更新索引，确定包含任一所述更新应用对象的所有第三应用版本；

基于所述新增更新代码，对包含任一所述更新应用对象的所述第三应用版本的所述候选增量文件进行更新，得到适配所述第四应用版本的更新增量文件；

基于所有所述更新增量文件更新所述版本更新索引，以使所述版本更新索引适用于所述第四应用版本。

5.根据权利要求3所述的更新方法，其特征在于，所述更新请求携带有所述终端的更新模式；

所述基于所述应用程序当前的第二应用版本与所述第一应用版本的版本偏差，从云端存储的所述应用程序的更新数据库中提取所述版本偏差对应的增量更新文件，包括：

若所述更新模式为第一更新模式，则根据所述版本更新索引，确定所述第一应用版本对应的所有第一应用对象；所述第一更新模式为所述终端的存储占用率小于预设的占用比例时的更新模式；

基于所有所述第一应用对象的所述目标更新代码，生成所述第一应用版本的所述增量更新文件；

若所述更新模式为第二更新模式，则获取安装于所述终端的所述应用程序的多个历史使用记录；所述第二更新模式为所述终端的存储占用率大于或等于所述占用比例时的更新模式；

基于所述多个历史使用记录中的操作对象，计算所述应用程序内各个应用对象的更新权重指标；

基于所述更新权重指标从所有所述应用对象中，选取第二应用对象；

基于所有所述第二应用对象的所述目标更新代码，生成所述第一应用版本的所述增量更新文件。

6.根据权利要求5所述的更新方法，其特征在于，所述基于所述多个历史使用记录中的操作对象，计算所述应用程序内各个应用对象的更新权重指标，包括：

根据所述存储占用率，确定所述终端对应的存储空间的预设加权系数；

基于所述历史使用记录中对应的操作时长以及所述操作对象关联的所述应用对象，计算每个所述应用对象的使用权重值；

根据每个所述应用对象的所述目标更新代码以及所述预设加权系数，分别计算各个所述应用对象的容量权重值；

获取所述终端中安装的应用列表，基于所述应用列表中与所述应用程序存在功能关联的其他应用的使用频率，计算每个所述应用对象的功能替代权重值；

基于所述功能替代权重值、所述使用权重值以及所述容量权重值，计算所述应用对象的所述更新权重指标。

7.根据权利要求1-6任一项所述的更新方法，其特征在于，所述基于所述增量更新文件更新所述应用程序至所述第二应用版本，包括：

若终端处于前台运行所述应用程序的第一运行状态，则基于所述增量更新文件在第一图层上生成更新对象；所述第一图层在所述应用程序的操作界面的第二图层上；

在所述更新对象渲染完成的情况下，移除所述操作界面中所述更新对象对应的应用对象，并将所述更新对象添加到所述第二图层中的所述操作界面。

8.一种应用程序的更新装置，其特征在于，包括：

更新请求响应单元，用于响应于终端发起的关于应用程序的更新请求，确定安装于所述终端的所述应用程序的第一应用版本；所述更新请求是在所述应用程序处于预设状态时生成的；所述预设状态包括应用程序运行状态；

更新文件确定单元，用于基于所述应用程序当前的第二应用版本与所述第一应用版本的版本偏差，从云端存储的所述应用程序的更新数据库中提取所述版本偏差对应的增量更新文件；

应用更新单元，用于基于所述增量更新文件更新所述应用程序至所述第二应用版本。

9.一种电子设备，包括存储器、处理器以及存储在所述存储器中并可在所述处理器上运行的计算机程序，其特征在于，所述处理器执行所述计算机程序时实现如权利要求1至7任一项所述的方法。

10.一种计算机可读存储介质，所述计算机可读存储介质存储有计算机程序，其特征在于，所述计算机程序被处理器执行时实现如权利要求1至7任一项所述的方法。