CN112604300A - 更新包生成方法及装置 - Google Patents

Abstract

本申请提供更新包生成方法及装置，其中所述更新包生成方法包括：获取待更新数据和历史更新包信息；根据所述历史更新包信息确定目标更新包容量；根据所述目标更新包容量对所述待更新数据进行切割，获得至少一组待打包数据；对所述至少一组待打包数据执行打包处理，生成每组待打包数据对应的更新包。通过本申请实施例提供的更新包生成方法，可以根据实际需求控制更新包容量的大小，将下载量与更新包大小进行关联预测并对应起来，有效的根据历史下载量推断用户可以接收的单次更新包大小，提升了用户体验，当某一次更新内容较多时，可以通过多次更新的方式实现全部内容的更新，有效保证了用户的下载量，提高了更新率。

Description

更新包生成方法及装置

技术领域

本申请涉及计算机技术领域，特别涉及一种更新包生成方法及装置、计算设备和计算机可读存储介质。

背景技术

随着计算机技术的发展，游戏、应用等软件也得到了快速发展，有些手机APP、游戏、电脑软件更新也越来越频繁。

软件在发布更新的时候，通常是由开发工程人员将更新的内容打包为一个更新包发布到相应位置，由用户自行下载到客户端进行更新使用，当对更新内容生成相应的更新包后，才会知道本次更新的更新包的容量，而用户有时会对更新包的容量比较敏感，当更新包容量较大时，有些用户基于成本、时间的考虑可能会拒绝下载更新包，较大的更新包会极大影响用户更新软件的积极性，影响用户的使用软件的用户体验。

发明内容

有鉴于此，本申请实施例提供了一种更新包生成方法及装置、计算设备和计算机可读存储介质，以解决现有技术中存在的技术缺陷。

根据本申请实施例的第一方面，提供了一种更新包生成方法，包括：

获取待更新数据和历史更新包信息；

根据所述历史更新包信息确定目标更新包容量和所述待更新数据对应的预计更新容量；

根据所述目标更新包容量和所述预计更新容量对所述待更新数据进行切割，获得至少一组待打包数据；

对所述至少一组待打包数据执行打包处理，生成每组待打包数据对应的更新包。

可选的，获取历史更新包信息，包括：

获取多个历史更新包信息。

可选的，所述历史更新包信息包括历史更新包对应的历史更新包容量和历史更新包下载量；

根据所述历史更新包信息确定目标更新包容量，包括：

根据所述多个历史更新包对应的历史更新包容量和历史更新包下载量确定目标更新包容量。

可选的，根据所述多个历史更新包对应的历史更新包容量和历史更新包下载量确定目标更新包容量，包括：

根据所述多个历史更新包下载量确定目标历史更新包；

根据所述目标历史更新包对应的历史更新包容量确定目标更新包容量。

可选的，获取多个历史更新包信息，包括：

获取预设时间区间内的多个历史更新包信息；或

获取预设数量的多个历史更新包信息。

可选的，所述待更新数据包括多个待更新子数据；

根据所述历史更新包信息确定所述待更新数据对应的预计更新容量，包括：

在所述历史更新包信息中确定每个所述待更新子数据对应的历史更新信息；

根据每个所述待更新子数据对应的历史更新信息确定每个所述待更新子数据对应的子数据预计更新容量；

根据每个所述待更新子数据对应的子数据预计更新容量确定所述待更新数据对应的预计更新容量。

可选的，根据每个所述待更新子数据对应的历史更新信息确定每个所述待更新子数据对应的子数据预计更新容量，包括：

获取每个所述待更新子数据对应的子数据类型和子数据更新类型；

根据每个所述待更新子数据对应的子数据类型和子数据更新类型在所述历史更新信息中确定每个所述待更新子数据对应的历史更新容量；

将每个所述待更新子数据对应的历史更新容量作为每个所述待更新子数据对应的子数据预计更新容量。

可选的，根据所述目标更新包容量和所述预计更新容量对所述待更新数据进行切割，获得至少一组待打包数据，包括：

根据所述目标更新包容量和每个所述待更新子数据对应的子数据预计更新容量对所述待更新数据进行切割。

根据本申请实施例的第二方面，提供了一种更新包生成装置，包括：

获取模块，被配置为获取待更新数据和历史更新包信息；

确定模块，被配置为根据所述历史更新包信息确定目标更新包容量和所述待更新数据对应的预计更新容量；

切割模块，被配置为根据所述目标更新包容量和所述预计更新容量对所述待更新数据进行切割，获得至少一组待打包数据；

生成模块，被配置为对所述至少一组待打包数据执行打包处理，生成每组待打包数据对应的更新包。

可选的，所述获取模块，进一步被配置为获取多个历史更新包信息。

可选的，所述历史更新包信息包括历史更新包对应的历史更新包容量和历史更新包下载量；

所述确定模块，进一步被配置为根据所述多个历史更新包对应的历史更新包容量和历史更新包下载量确定目标更新包容量。

可选的，所述确定模块，进一步被配置为：

根据所述多个历史更新包下载量确定目标历史更新包；

根据所述目标历史更新包对应的历史更新包容量确定目标更新包容量。

可选的，所述获取模块，进一步被配置为：

获取预设时间区间内的多个历史更新包信息；或

获取预设数量的多个历史更新包信息。

可选的，所述待更新数据包括多个待更新子数据；

所述确定模块，进一步被配置为：

在所述历史更新包信息中确定每个所述待更新子数据对应的历史更新信息；

根据每个所述待更新子数据对应的历史更新信息确定每个所述待更新子数据对应的子数据预计更新容量；

根据每个所述待更新子数据对应的子数据预计更新容量确定所述待更新数据对应的预计更新容量。

可选的，所述确定模块，进一步被配置为：

获取每个所述待更新子数据对应的子数据类型和子数据更新类型；

根据每个所述待更新子数据对应的子数据类型和子数据更新类型在所述历史更新信息中确定每个所述待更新子数据对应的历史更新容量；

将每个所述待更新子数据对应的历史更新容量作为每个所述待更新子数据对应的子数据预计更新容量。

所述切割模块，进一步被配置为：

根据所述目标更新包容量和每个所述待更新子数据对应的子数据预计更新容量对所述待更新数据进行切割。

根据本申请实施例的第三方面，提供了一种计算设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机指令，所述处理器执行所述指令时实现所述更新包生成方法的步骤。

根据本申请实施例的第四方面，提供了一种计算机可读存储介质，其存储有计算机指令，该指令被处理器执行时实现所述更新包生成方法的步骤。

本申请实施例提供的更新包生成方法，包括获取待更新数据和历史更新包信息；根据所述历史更新包信息确定目标更新包容量；根据所述目标更新包容量对所述待更新数据进行切割，获得至少一组待打包数据；对所述至少一组待打包数据执行打包处理，生成每组待打包数据对应的更新包，通过本申请实施例提供的更新包生成方法，可以根据实际需求控制更新包容量的大小，将下载量与更新包大小进行关联预测并对应起来，有效的根据历史下载量推断用户可以接收的单次更新包大小，提升了用户体验，当某一次更新内容较多时，可以通过多次更新的方式实现全部内容的更新，有效保证了用户的下载量，提高了更新率。

附图说明

图1是本申请实施例提供的计算设备的结构框图；

图2是本申请实施例提供的更新包生成方法的流程图；

图3是本申请实施例提供的以生成游戏更新包为例的更新包生成方法的示意图；

图4是本申请实施例提供的更新包生成装置的结构示意图。

具体实施方式

在下面的描述中阐述了很多具体细节以便于充分理解本申请。但是本申请能够以很多不同于在此描述的其它方式来实施，本领域技术人员可以在不违背本申请内涵的情况下做类似推广，因此本申请不受下面公开的具体实施的限制。

在本申请一个或多个实施例中使用的术语是仅仅出于描述特定实施例的目的，而非旨在限制本申请一个或多个实施例。在本申请一个或多个实施例和所附权利要求书中所使用的单数形式的“一种”、“所述”和“该”也旨在包括多数形式，除非上下文清楚地表示其他含义。还应当理解，本申请一个或多个实施例中使用的术语“和/或”是指并包含一个或多个相关联的列出项目的任何或所有可能组合。

应当理解，尽管在本申请一个或多个实施例中可能采用术语第一、第二等来描述各种信息，但这些信息不应限于这些术语。这些术语仅用来将同一类型的信息彼此区分开。例如，在不脱离本申请一个或多个实施例范围的情况下，第一也可以被称为第二，类似地，第二也可以被称为第一。取决于语境，如在此所使用的词语“如果”可以被解释成为“在……时”或“当……时”或“响应于确定”。

在本申请中，提供了一种更新包生成方法及装置、计算设备和计算机可读存储介质，在下面的实施例中逐一进行详细说明。

图1示出了根据本申请一实施例的计算设备100的结构框图。该计算设备100的部件包括但不限于存储器110和处理器120。处理器120与存储器110通过总线130相连接，数据库150用于保存数据。

计算设备100还包括接入设备140，接入设备140使得计算设备100能够经由一个或多个网络160通信。这些网络的示例包括公用交换电话网(PSTN)、局域网(LAN)、广域网(WAN)、个域网(PAN)或诸如因特网的通信网络的组合。接入设备140可以包括有线或无线的任何类型的网络接口(例如，网络接口卡(NIC))中的一个或多个，诸如IEEE802.11无线局域网(WLAN)无线接口、全球微波互联接入(Wi-MAX)接口、以太网接口、通用串行总线(USB)接口、蜂窝网络接口、蓝牙接口、近场通信(NFC)接口，等等。

在本申请的一个实施例中，计算设备100的上述部件以及图1中未示出的其他部件也可以彼此相连接，例如通过总线。应当理解，图1所示的计算设备结构框图仅仅是出于示例的目的，而不是对本申请范围的限制。本领域技术人员可以根据需要，增添或替换其他部件。

计算设备100可以是任何类型的静止或移动计算设备，包括移动计算机或移动计算设备(例如，平板计算机、个人数字助理、膝上型计算机、笔记本计算机、上网本等)、移动电话(例如，智能手机)、可佩戴的计算设备(例如，智能手表、智能眼镜等)或其他类型的移动设备，或者诸如台式计算机或PC的静止计算设备。计算设备100还可以是移动式或静止式的服务器。

其中，处理器120可以执行图2所示更新包生成方法中的步骤。图2示出了根据本申请一实施例的更新包生成方法的流程图，包括步骤202至步骤208。

步骤202：获取待更新数据和历史更新包信息。

随着计算机技术的快速发展，越来越多的应用程序被开发出来，方便我们的日常生活，比如支付软件、出行软件、购物软件、游戏软件等等，尤其是在智能手机日益普及之后，针对手机上的应用程序(APP)也越来越多，而且APP发布之后也不是一成不变的，开发者还会经常针对APP发布更新，发布新功能，修补旧版本的漏洞，进一步提升用户体验。

当用户在户外无法连接到局域网时，就需要通过蜂窝数据更新APP，当APP的更新包太大时，用户基于时间和费用的考虑，可能就选择不更新APP，因此无法将APP更新到最新版本，进而也无法获得更好的使用体验，因此，本申请提出一种更新包生成方法，可以控制更新包容量，解决用户因为更新包容量过大而不想下载更新包的问题。

因此，待更新数据即为开发人员希望发布更新时对APP的所有的修改数据，可以包括代码、图片、语音、文本等等数据信息，本申请对待更新数据的类型不做限制，一个APP会经历多次更新，历史更新包信息即在过去的时间里，每次更新对应的更新包信息，历史更新包信息包括但不限于更新包大小、更新包对应的下载量、更新包中的更新数据类型等等。如某一次更新中，更新包A大小为70M，下载量为5000，更新包A包括背景图片、语音、代码，其中，背景图片对应的容量为30M，语音对应的容量为30M，代码对应的容量为10M等等。

可选的，获取历史更新包信息，包括：

获取多个历史更新包信息。

具体的，获取多个历史更新包信息，包括：

获取预设时间区间内的多个历史更新包信息；或获取预设数量的多个历史更新包信息。

在实际应用中，会获取多个历史更新包信息，便于根据多个历史更新包信息在后续的过程中统计更新包的历史更新包信息，方便开发人员可以根据历史更新包信息进行后续处理。

获取多个历史更新包信息的方式也有很多，既可以获取预设时间区间内的多个历史更新包信息，也可以获取预设数量的多个历史更新包信息。在实际应用中，有的APP更新比较频繁，可能每天都会有更新，因此，可以选择在过去的10天、20天或其他预设天数的多个历史更新包信息进行后续处理，而有的APP的更新频率会比较低或发布的时间比较短，还可以获取预设数量的历史更新包信息进行后续处理，获取多个历史更新包信息的具体方式以实际应用为准，在本申请中此不做限制。

在本申请提供的一具体实施方式中，以更新APP1为例，获取APP1对应的待更新数据A，待更新数据A的容量为300M，同时获取APP1的5个历史更新包信息，5个历史更新信息包分别为B、C、D、E和F。

步骤204：根据所述历史更新包信息确定目标更新包容量和所述待更新数据对应的预计更新容量。

在实际应用中，所述历史更新包信息包括历史更新包对应的历史更新包容量和历史更新包下载量，比如某个历史更新包对应的更新包容量为100M，其对应的历史更新包下载量为5000，即表示历史更新包的大小有100M，该历史更新包有5000个用户进行了下载更新；又比如某个历史更新包对应的更新包容量为50M，其对应的历史更新包下载量为8000，即标识该历史更新包的大小有50M，有8000个用户进行了下载更新。当更新包的容量越大，用户下载需要的时间和流量就会相应的增多，很多用户基于时间、成本的考虑，可能在更新包容量较大的时候选择不更新，进而无法获得最新APP服务。因此可以根据历史更新包信息确定一个较为优选的更新包容量。在实际应用中，根据所述历史更新包信息确定目标更新包容量，包括：

根据所述多个历史更新包对应的历史更新包容量和历史更新包下载量确定目标更新包容量。

具体的，根据所述多个历史更新包对应的历史更新包容量和历史更新包下载量确定目标更新包容量，包括：

根据所述多个历史更新包下载量确定目标历史更新包；

根据所述目标历史更新包对应的历史更新包容量确定目标更新包容量。

每个历史更新包对应有历史更新包容量和历史更新包下载量，为了能使得有更多的用户参与到更新中来，因此，优选的期望下载量越多越好，但是现实情况是，发布的更新包的容量越小的时候对应的下载量越多，但更新包的容量太小又无法有效的将更新的内容发布出去，因此需要在更新包的容量和下载量之间取得一个平衡，即能保证更新包容量尽可能大，有能保证有更多的用户进行下载，因此首选要根据历史更新包对应的下载量确定目标历史更新包，目标历史更新包即为在过去的多次更新中，既能保证更新包容量尽量大，又能保证用户的下载数的历史更新包。

根据多个历史更新包下载量确定目标历史更新包的方式有很多，可以将历史更新包根据历史更新包下载量从高到低进行排序，获取排名靠前的预设数量的历史更新包，并确定历史更新包容量最大的历史更新包为目标历史更新包。比如根据历史更新包下载量从高到低进行排序，选取前50个历史更新包中历史更新包容量最大的历史更新包为目标历史更新包。

根据多个历史更新包下载量确定目标历史更新包还可以根据历史更新包的更新包容量从低到高进行排序，计算相邻两个历史更新包之间下载量的差值，当差值第一次超过预设阈值的情况下，确定对应的两个历史更新包中更新包容量较小的历史更新包为目标历史更新包，比如根据历史更新包容量从低到高进行排序，并依次计算相邻两个更新包容量对应的下载量的差值，如第一个更新包容量下载量和第二个更新包下载量的差值为50，预设阈值为500，则计算第二个更新包下载量和第三个更新包下载量的差值，经计算是80，小于预设阈值，则继续计算第三个更新包下载量和第四个更新包下载量的差值，依次类推，直至出现第n个更新包下载量和第n+1个更新包下载量为600，大于预设阈值，则确定第n个更新包为目标历史更新包。

在确定目标历史更新包后，即可将目标历史更新包对应的历史更新包容量作为目标更新包容量，目标更新包容量即在之后生成更新包时，一个更新包的最大容量。

在本申请提供的一具体实施方式中，沿用上例，根据多个历史更新包信息确定目标历史更新包为D，目标历史更新包D对应的历史更新容量为80M，则可以确定目标更新包容量为80M，即一个更新包的最大容量为80M。

在实际应用中，所述待更新数据包括多个待更新子数据；根据所述历史更新包信息确定所述待更新数据对应的预计更新容量，包括：

在所述历史更新包信息中确定每个所述待更新子数据对应的历史更新信息；

根据每个所述待更新子数据对应的历史更新信息确定每个所述待更新子数据对应的子数据预计更新容量；

根据每个所述待更新子数据对应的子数据预计更新容量确定所述待更新数据对应的预计更新容量。

待更新数据通常是整个APP所有的更新数据，但是在实际应用中，对一个APP进行更新可能会是不同的模块、功能都会有更新，每个模块或功能之间是相互独立，互不影响的，比如在一次更新中，更新了模块1和模块2，模块1和模块2可以在一个更新包中进行更新，也可以分为两个更新包中分两次更新，待更新数据被打包为更新包后，数据会有压缩，数据包的大小可能会有相应的减少，比如一次待更新数据的大小为100M，在经过打包生成对应的更新包后，更新包的大小可能只有80M，因此还可以根据历史更新包信息来确定待更新数据对应的预计更新容量。

具体的，在历史更新包信息中还包括每个更新子数据的历史信息，比如一个背景图片，更新数据大小为5M，制作成更新包之后的大小为3M，当再有背景图片需要更新时，则可以根据历史记录确定背景图片的预计更新容量的大小为3M。

在实际应用中，确定每个待更新子数据的历史更新信息，根据每个待更新子数据的历史更新信息即可确定待更新子数据的子数据预计更新容量，依然以背景图片为例，在历史更新信息中有3次更新，其中，在第一次更新中占用的更新包大小为4M，在第二次更新中占用的更新包大小为5M，在第三次更新中占用的更新包大小为4M，通过计算平均值的方式，可以确定背景图片对应的历史更新信息为4.3M，因此可以确定在当前次的待更新数据为背景图片的情况下，背景图片对应的子数据预计更新容量为4.3M。

通过上述方法可以确定每个待更新子数据对应的子数据预计更新容量，将待更新数据中每个待更新子数据对应的子数据预计更新容量相加，即可确定待更新数据对应的预计更新容量。

具体的，根据每个所述待更新子数据对应的历史更新信息确定每个所述待更新子数据对应的子数据预计更新容量，包括：

获取每个所述待更新子数据对应的子数据类型和子数据更新类型；

根据每个所述待更新子数据对应的子数据类型和子数据更新类型在所述历史更新信息中确定每个所述待更新子数据对应的历史更新容量；

将每个所述待更新子数据对应的历史更新容量作为每个所述待更新子数据对应的子数据预计更新容量。

在实际应用中，每个待更新数据的更新类型还分为更新和新增，当更新类型为更新的情况下，是替换原有数据，在实际应用中，有时不同的子数据类型之间还是相互关联的，比如游戏场景中头像资源包括头像和头像框，其中，头像框的大小为2M，头像的大小为3M，则头像资源大小为5M，当对头像框进行更新时，更新的数据量为2M，但是因为头像和头像框是关联资源，则需要对头像资源整体进行更新。当更新类型为新增的情况下，则新增的数据容量即为增加的容量。

以游戏中的头像资源为例，在历史更新容量中，当子数据更新类型为更新时，历史更新容量的大小为5M，则确定头像资源在更新类型的情况下的子数据预计更新容量大小为5M；当子数据更新类型为新增时，历史更新容量的大小为8M，则确定头像资源在新增类型的情况下的子数据预计更新容量大小为8M。

步骤206：根据所述目标更新包容量和所述预计更新容量对所述待更新数据进行切割，获得至少一组待打包数据。

在确定目标更新包容量和预计更新容量的情况下，即可对待更新数据进行切割(即分组)，获得至少一组待打包数据。待打包数据即为经过分组切割之后的待更新数据。

可选的，根据所述目标更新包容量和所述预计更新容量对所述待更新数据进行切割，获得至少一组待打包数据，包括：

根据所述目标更新包容量和每个所述待更新子数据对应的子数据预计更新容量对所述待更新数据进行切割。

在本申请提供的一具体实施方式中，根据待更新子数据对应的子数据预计更新容量去配合目标更新包容量，比如待更新子数据一共有5个，其中，待更新子数据对应的子数据预计更新容量分别为(待更新子数据1-50M、待更新子数据2-20M、待更新子数据3-50M、待更新子数据4-30M、待更新子数据5:-40M)，而目标更新包容量为100M，则以100M为标准，将待更新子数据1和待更新子数据3作为第一组待打包数据，第一组待打包数据对应的预计更新容量为100M；将待更新子数据2、待更新子数据4和待更新子数据5作为第二组待打包数据，第二组待打包数据对应的预计更新容量为90M。

步骤208：对所述至少一组待打包数据执行打包处理，生成每组待打包数据对应的更新包。

在获得至少一组待打包数据之后，即可对每组待打包数据进行打包处理，生成每组待打包数据对应的更新包，比如一共获得三组待打包数据，则对第一组待打包数据执行打包处理，生成第一更新包；对第二组待打包数据执行打包处理，生成第二更新包；对第三组待打包数据执行打包处理，生成第三更新包。

至此更新包的生成操作已经完成，在后续的过程中，可以将更新包分别进行发布，比如将三组更新包分为三天发布，当用户一次更新300M的更新包不太容易接受时，反而会对更新三次，每次更新100M的更新包的接收程度更高。从而提高用户更新的积极性，提升了用户体验，有效保证了用户的下载量，提高了更新率。

本申请实施例提供的更新包生成方法，包括获取待更新数据和历史更新包信息；根据所述历史更新包信息确定目标更新包容量；根据所述目标更新包容量对所述待更新数据进行切割，获得至少一组待打包数据；对所述至少一组待打包数据执行打包处理，生成每组待打包数据对应的更新包，通过本申请实施例提供的更新包生成方法，可以根据实际需求控制更新包容量的大小，将下载量与更新包大小进行关联预测并对应起来，有效的根据历史下载量推断用户可以接收的单次更新包大小，提升了用户体验，当某一次更新内容较多时，可以通过多次更新的方式实现全部内容的更新，有效保证了用户的下载量，提高了更新率。

图3示出了本申请一实施例的更新包生成方法，该更新包生成方法以生成游戏更新包为例进行描述，包括步骤302至步骤316。

步骤302：获取待更新游戏数据和多个历史游戏更新包信息，其中，所述待更新游戏数据包括多个待更新子游戏数据，所述历史游戏更新包信息包括历史游戏更新包对应的历史游戏更新包容量和历史游戏更新包下载量。

在本申请提供的具体实施例中，获取游戏一次更新的待更新游戏数据D和10个历史游戏更新包信息，待更新游戏数据中包括多个不同的功能相互独立的待更新子游戏数据(D1，D2，D3……Dn)，历史游戏更新包信息包括每次游戏更新包容量和对应的下载量。

步骤304：在所述历史游戏更新包信息中确定每个所述待更新子游戏数据对应的历史更新信息。

在本申请提供的具体实施例中，在历史游戏更新包信息中，确定待更新子游戏数据D1对应的历史更新信息为H1，确定待更新子游戏数据D2对应的历史更新信息为H2，……确定待更新子游戏数据Dn对应的历史更新信息为Hn。

步骤306：根据每个所述待更新子游戏数据对应的历史更新信息确定每个所述待更新子游戏数据对应的子游戏数据预计更新容量。

在本申请提供的具体实施例中，根据历史更新信息H1更新包大小为5M，确定待更新子游戏数据D1对应的子游戏数据预计更新容量为5M；根据历史更新信息H2更新包大小为10M，确定待更新子游戏数据D2对应的子游戏数据预计更新容量为10M；……根据历史更新信息Hn更新包大小为8M，确定待更新子游戏数据Dn对应的子游戏数据预计更新容量为8M。

步骤308：根据每个所述待更新子游戏数据对应的子游戏数据预计更新容量确定所述待更新游戏数据对应的预计游戏更新容量。

在本申请提供的具体实施例中，将每个待更新子游戏数据对应的子游戏数据预计更新容量相加，便可确定所述待更新游戏数据对应的预计游戏更新容量，即待更新游戏数据D对应的预计游戏更新容量M＝D1+D2+……+Dn＝160M。

步骤310：根据所述多个历史游戏更新包下载量确定目标历史游戏更新包。

在本申请提供的具体实施例中，将10个历史游戏更新包根据游戏更新包容量从低到高进行排序，分别为{更新包2(2M-5000下载量)、更新包5(7M-4980下载量)、更新包7(20M-4800下载量)、更新包9(50M-4750下载量)、更新包1(70M-4800下载量)、更新包3(80M-4700下载量)、更新包6(100M-4800下载量)、更新包4(200M-3800下载量)、更新包10(240M-2700下载量)、更新包8(300M-1200下载量)}，以更新包2(2M-5000下载量)为例，其中，“2M”表示更新包2的游戏更新包容量，“5000下载量”表示更新包2的游戏更新包下载量。

计算排名相邻的两个历史游戏更新包的历史游戏更新包下载量之间的差值，经过计算确定更新包6与更新包4之间的更新包下载量的差值第一次出现差值较大的情况，因此，确定更新包6与更新包4之间更新包下载量更高的更新包6为目标历史游戏更新包。

步骤312：根据所述目标历史游戏更新包对应的历史游戏更新包容量确定目标游戏更新包容量。

在本申请提供的具体实施例中，确定更新包6对应的游戏更新包容量100M-为目标游戏更新包容量。

步骤314：根据所述目标游戏更新包容量和所述预计游戏更新容量对所述待更新游戏数据进行切割，获得至少一组待打包游戏数据。

在本申请提供的具体实施例中，目标游戏更新包容量为100M，预计游戏更新容量为160M，可以将待更新游戏数据D划分为两组待打包游戏数据，其中，第一组待打包游戏数据为(D1、D2、……Dm)，第二组待打包游戏数据为(Dm、……Dn)，并且每组待打包游戏数据的预计游戏更新容量均小于等于100M，比如第一组待打包游戏数据的预计游戏更新容量可以为80M，则第二组待打包游戏数据的预计游戏更新容量为80M；若第一组待打包游戏数据的预计游戏更新容量可以为90M，则第二组待打包游戏数据的预计游戏更新容量为70M；若第一组待打包游戏数据的预计游戏更新容量可以为100M，则第二组待打包游戏数据的预计游戏更新容量为60M。

步骤316：对所述至少一组待打包游戏数据执行打包处理，生成每组待打包游戏数据对应的游戏更新包。

在本申请提供的具体实施例中，分别对第一组待打包游戏数据和第二组待打包游戏数据执行打包处理，生成第一组待打包游戏数据对应的第一游戏更新包和第二组待打包游戏数据对应的第二游戏更新包。在发布更新包时，可以分两次发布更新包，即第一次发布第一游戏更新包，第二次发布第二游戏更新包。

本申请实施例提供的更新包生成方法，包括获取待更新数据和历史更新包信息；根据所述历史更新包信息确定目标更新包容量；根据所述目标更新包容量对所述待更新数据进行切割，获得至少一组待打包数据；对所述至少一组待打包数据执行打包处理，生成每组待打包数据对应的更新包，通过本申请实施例提供的更新包生成方法，可以根据实际需求控制更新包容量的大小，将下载量与更新包大小进行关联预测并对应起来，有效的根据历史下载量推断用户可以接收的单次更新包大小，提升了用户体验，当某一次更新内容较多时，可以通过多次更新的方式实现全部内容的更新，有效保证了用户的下载量，提高了更新率。

与上述方法实施例相对应，本申请还提供了更新包生成装置实施例，图4示出了本申请一个实施例的更新包生成装置的结构示意图。如图4所示，该装置包括：

获取模块402，被配置为获取待更新数据和历史更新包信息；

确定模块404，被配置为根据所述历史更新包信息确定目标更新包容量和所述待更新数据对应的预计更新容量；

切割模块406，被配置为根据所述目标更新包容量和所述预计更新容量对所述待更新数据进行切割，获得至少一组待打包数据；

生成模块408，被配置为对所述至少一组待打包数据执行打包处理，生成每组待打包数据对应的更新包。

可选的，所述获取模块402，进一步被配置为获取多个历史更新包信息。

可选的，所述历史更新包信息包括历史更新包对应的历史更新包容量和历史更新包下载量；

所述确定模块404，进一步被配置为根据所述多个历史更新包对应的历史更新包容量和历史更新包下载量确定目标更新包容量。

可选的，所述确定模块404，进一步被配置为：

根据所述多个历史更新包下载量确定目标历史更新包；

根据所述目标历史更新包对应的历史更新包容量确定目标更新包容量。

可选的，所述获取模块402，进一步被配置为：

获取预设时间区间内的多个历史更新包信息；或

获取预设数量的多个历史更新包信息。

可选的，所述待更新数据包括多个待更新子数据；

所述确定模块404，进一步被配置为：

在所述历史更新包信息中确定每个所述待更新子数据对应的历史更新信息；

根据每个所述待更新子数据对应的历史更新信息确定每个所述待更新子数据对应的子数据预计更新容量；

根据每个所述待更新子数据对应的子数据预计更新容量确定所述待更新数据对应的预计更新容量。

可选的，所述确定模块404，进一步被配置为：

获取每个所述待更新子数据对应的子数据类型和子数据更新类型；

根据每个所述待更新子数据对应的子数据类型和子数据更新类型在所述历史更新信息中确定每个所述待更新子数据对应的历史更新容量；

将每个所述待更新子数据对应的历史更新容量作为每个所述待更新子数据对应的子数据预计更新容量。

所述切割模块406，进一步被配置为：

根据所述目标更新包容量和每个所述待更新子数据对应的子数据预计更新容量对所述待更新数据进行切割。

本申请实施例提供的更新包生成装置，包括获取待更新数据和历史更新包信息；根据所述历史更新包信息确定目标更新包容量；根据所述目标更新包容量对所述待更新数据进行切割，获得至少一组待打包数据；对所述至少一组待打包数据执行打包处理，生成每组待打包数据对应的更新包，通过本申请实施例提供的更新包生成装置，可以根据实际需求控制更新包容量的大小，将下载量与更新包大小进行关联预测并对应起来，有效的根据历史下载量推断用户可以接收的单次更新包大小，提升了用户体验，当某一次更新内容较多时，可以通过多次更新的方式实现全部内容的更新，有效保证了用户的下载量，提高了更新率。

上述为本实施例的一种更新包生成装置的示意性方案。需要说明的是，该更新包生成装置的技术方案与上述的更新包生成方法的技术方案属于同一构思，更新包生成装置的技术方案未详细描述的细节内容，均可以参见上述更新包生成方法的技术方案的描述。

本申请一实施例中还提供一种计算设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机指令，所述处理器执行所述指令时实现所述的更新包生成方法的步骤。

上述为本实施例的一种计算设备的示意性方案。需要说明的是，该计算设备的技术方案与上述的更新包生成方法的技术方案属于同一构思，计算设备的技术方案未详细描述的细节内容，均可以参见上述更新包生成方法的技术方案的描述。

本申请一实施例还提供一种计算机可读存储介质，其存储有计算机指令，该指令被处理器执行时实现如前所述更新包生成方法的步骤。

上述为本实施例的一种计算机可读存储介质的示意性方案。需要说明的是，该存储介质的技术方案与上述的更新包生成方法的技术方案属于同一构思，存储介质的技术方案未详细描述的细节内容，均可以参见上述更新包生成方法的技术方案的描述。

上述对本申请特定实施例进行了描述。其它实施例在所附权利要求书的范围内。在一些情况下，在权利要求书中记载的动作或步骤可以按照不同于实施例中的顺序来执行并且仍然可以实现期望的结果。另外，在附图中描绘的过程不一定要求示出的特定顺序或者连续顺序才能实现期望的结果。在某些实施方式中，多任务处理和并行处理也是可以的或者可能是有利的。

所述计算机指令包括计算机程序代码，所述计算机程序代码可以为源代码形式、对象代码形式、可执行文件或某些中间形式等。所述计算机可读介质可以包括：能够携带所述计算机程序代码的任何实体或装置、记录介质、U盘、移动硬盘、磁碟、光盘、计算机存储器、只读存储器(ROM，Read-Only Memory)、随机存取存储器(RAM，Random Access Memory)、电载波信号、电信信号以及软件分发介质等。需要说明的是，所述计算机可读介质包含的内容可以根据司法管辖区内立法和专利实践的要求进行适当的增减，例如在某些司法管辖区，根据立法和专利实践，计算机可读介质不包括电载波信号和电信信号。

需要说明的是，对于前述的各方法实施例，为了简便描述，故将其都表述为一系列的动作组合，但是本领域技术人员应该知悉，本申请并不受所描述的动作顺序的限制，因为依据本申请，某些步骤可以采用其它顺序或者同时进行。其次，本领域技术人员也应该知悉，说明书中所描述的实施例均属于优选实施例，所涉及的动作和模块并不一定都是本申请所必须的。

在上述实施例中，对各个实施例的描述都各有侧重，某个实施例中没有详述的部分，可以参见其它实施例的相关描述。

以上公开的本申请优选实施例只是用于帮助阐述本申请。可选实施例并没有详尽叙述所有的细节，也不限制该发明仅为所述的具体实施方式。显然，根据本申请的内容，可作很多的修改和变化。本申请选取并具体描述这些实施例，是为了更好地解释本申请的原理和实际应用，从而使所属技术领域技术人员能很好地理解和利用本申请。本申请仅受权利要求书及其全部范围和等效物的限制。

Claims (11)

1.一种更新包生成方法，其特征在于，包括：

获取待更新数据和历史更新包信息；

根据所述历史更新包信息确定目标更新包容量和所述待更新数据对应的预计更新容量；

根据所述目标更新包容量和所述预计更新容量对所述待更新数据进行切割，获得至少一组待打包数据；

对所述至少一组待打包数据执行打包处理，生成每组待打包数据对应的更新包。

2.如权利要求1所述的更新包生成方法，其特征在于，获取历史更新包信息，包括：

获取多个历史更新包信息。

3.如权利要求2所述的更新包生成方法，其特征在于，所述历史更新包信息包括历史更新包对应的历史更新包容量和历史更新包下载量；

根据所述历史更新包信息确定目标更新包容量，包括：

根据所述多个历史更新包对应的历史更新包容量和历史更新包下载量确定目标更新包容量。

4.如权利要求3所述的更新包生成方法，其特征在于，根据所述多个历史更新包对应的历史更新包容量和历史更新包下载量确定目标更新包容量，包括：

根据所述多个历史更新包下载量确定目标历史更新包；

根据所述目标历史更新包对应的历史更新包容量确定目标更新包容量。

5.如权利要求2所述的更新包生成方法，其特征在于，获取多个历史更新包信息，包括：

获取预设时间区间内的多个历史更新包信息；或

获取预设数量的多个历史更新包信息。

6.如权利要求2所述的更新包生成方法，其特征在于，所述待更新数据包括多个待更新子数据；

根据所述历史更新包信息确定所述待更新数据对应的预计更新容量，包括：

在所述历史更新包信息中确定每个所述待更新子数据对应的历史更新信息；

根据每个所述待更新子数据对应的历史更新信息确定每个所述待更新子数据对应的子数据预计更新容量；

根据每个所述待更新子数据对应的子数据预计更新容量确定所述待更新数据对应的预计更新容量。

7.如权利要求6所述的更新包生成方法，其特征在于，根据每个所述待更新子数据对应的历史更新信息确定每个所述待更新子数据对应的子数据预计更新容量，包括：

获取每个所述待更新子数据对应的子数据类型和子数据更新类型；

根据每个所述待更新子数据对应的子数据类型和子数据更新类型在所述历史更新信息中确定每个所述待更新子数据对应的历史更新容量；

将每个所述待更新子数据对应的历史更新容量作为每个所述待更新子数据对应的子数据预计更新容量。

8.如权利要求6所述的更新包生成方法，其特征在于，根据所述目标更新包容量和所述预计更新容量对所述待更新数据进行切割，获得至少一组待打包数据，包括：

根据所述目标更新包容量和每个所述待更新子数据对应的子数据预计更新容量对所述待更新数据进行切割。

9.一种更新包生成装置，其特征在于，包括：

获取模块，被配置为获取待更新数据和历史更新包信息；

确定模块，被配置为根据所述历史更新包信息确定目标更新包容量和所述待更新数据对应的预计更新容量；

切割模块，被配置为根据所述目标更新包容量和所述预计更新容量对所述待更新数据进行切割，获得至少一组待打包数据；

生成模块，被配置为对所述至少一组待打包数据执行打包处理，生成每组待打包数据对应的更新包。

10.一种计算设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机指令，其特征在于，所述处理器执行所述指令时实现权利要求1-8任意一项所述方法的步骤。

11.一种计算机可读存储介质，其存储有计算机指令，其特征在于，该指令被处理器执行时实现权利要求1-8任意一项所述方法的步骤。

Images