CN113296808A - 应用程序的下载控制方法和服务器 - Google Patents

Abstract

本申请公开了一种应用程序的下载控制方法和服务器，属于电子设备技术领域。该应用程序的下载控制方法包括：接收第一电子设备发送的应用程序的版本更新请求；响应于版本更新请求，在应用程序存在更新版本的情况下，确定下载更新版本所需的目标流量；在目标流量小于或等于预设时间段内允许使用流量的情况下，向第一电子设备推送更新版本。

Description

应用程序的下载控制方法和服务器

技术领域

本申请属于电子设备技术领域，具体涉及一种应用程序的下载控制方法和服务器。

背景技术

在用户的电子设备更新升级应用程序(Application，APP)的时候，APP的提供者需要支付内容分发网络(Content Delivery Network，CDN)厂商相应的CDN费用。相关技术中，CDN厂商采用的都是日峰值月平均的算法进行计费，也就是取当月每天的峰值CDN流量进行平均，计算出总流量然后乘以单价进行计费。

如果每个用户感知到有新版本APP发布之后立马进行更新升级，那么瞬间就会出现一个CDN流量的波峰，而在没有版本更新的时间段内CDN流量就非常低，甚至接近于零。在上述计费模式下，APP的提供者就需要支付昂贵的CDN费用。

发明内容

本申请实施例的目的是提供一种应用程序的下载控制方法和服务器，能够解决相关技术中在进行软件更新升级时APP的提供者需要支付昂贵的CDN费用的问题。

第一方面，本申请实施例提供了一种应用程序的下载控制方法，该下载控制方法包括：

接收第一电子设备发送的应用程序的版本更新请求；

响应于版本更新请求，在应用程序存在更新版本的情况下，确定下载更新版本所需的目标流量；

在目标流量小于或等于预设时间段内允许使用流量的情况下，向第一电子设备推送更新版本。

第二方面，本申请实施例提供了一种服务器，该服务器包括：

接收模块，用于接收第一电子设备发送的应用程序的版本更新请求；

获取模块，用于响应于版本更新请求，在应用程序存在更新版本的情况下，确定下载更新版本所需的目标流量；

推送模块，用于在目标流量小于或等于预设时间段内允许使用流量的情况下，向第一电子设备推送更新版本。

第三方面，本申请实施例提供了一种电子设备，该电子设备包括处理器、存储器及存储在存储器上并可在处理器上运行的程序或指令，程序或指令被处理器执行时实现如第一方面的下载控制方法的步骤。

第四方面，本申请实施例提供了一种可读存储介质，可读存储介质上存储程序或指令，程序或指令被处理器执行时实现如第一方面的下载控制方法的步骤。

第五方面，本申请实施例提供了一种芯片，芯片包括处理器和通信接口，通信接口和处理器耦合，处理器用于运行程序或指令，实现如第一方面的下载控制方法。

在本申请实施例中，第二电子设备(例如服务器)在接收到第一电子设备发送的应用程序的版本更新请求时，确定第一电子设备需要进行应用程序版本更新。在此情况下判断该应用程序是否有更新版本，如果存在更新版本，则需要判断第一电子设备下载该更新版本的目标流量是否超过预设时间段内的允许使用流量。如果目标流量超过预设时间段内的允许使用流量，则向第一电子设备反馈没有更新版本的信息；如果目标流量未超过预设时间段内的允许使用流量，则向第一电子设备推送更新版本，以使第一电子设备下载更新版本，从而对应用程序进行版本更新。通过上述方式，采用削峰填谷的思想，控制在预设时间段内只能允许不超过流量控制设定值(即允许使用流量)的更新版本进行下载，从而控制单位时间内CDN流量，避免CDN流量波形出现尖峰的情况，把原来的忽高忽低的CDN流量波形变得平稳，当把日峰值降低之后，根据计费规则，CDN的费用也就随之降低，相应节省的带宽流量也可以给其他用户使用，充分达到省流降费的目的。

附图说明

图1是本申请实施例的应用程序的下载控制方法的流程示意图之一；

图2是本申请实施例的应用程序的下载控制方法的流程示意图之二；

图3是本申请实施例的两倍的配置速率问题的示意图；

图4是本申请实施例的窗口移动的示意图；

图5是本申请实施例的配置一定时间段内的总使用流量的交互示意图；

图6是本申请实施例的服务器的示意框图；

图7是本申请实施例的电子设备的示意框图之一；

图8是本申请实施例的电子设备的示意框图之二。

具体实施方式

下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚地描述，显然，所描述的实施例是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员获得的所有其他实施例，都属于本申请保护的范围。

本申请的说明书和权利要求书中的术语“第一”、“第二”等是用于区别类似的对象，而不用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便本申请的实施例能够以除了在这里图示或描述的那些以外的顺序实施。此外，说明书以及权利要求中“和/或”表示所连接对象的至少其中之一，字符“/”，一般表示前后关联对象是一种“或”的关系。

下面结合附图，通过具体的实施例及其应用场景对本申请实施例提供的应用程序的下载控制方法、服务器、电子设备和可读存储介质进行详细地说明。

本申请实施例提供了一种应用程序的下载控制方法，如图1所示，该下载控制方法包括：

步骤102，接收第一电子设备发送的应用程序的版本更新请求；

步骤104，响应于版本更新请求，在应用程序存在更新版本的情况下，确定下载更新版本所需的目标流量；

步骤106，在目标流量小于或等于预设时间段内允许使用流量的情况下，向第一电子设备推送更新版本。

其中，第一电子设备可以为手机、平板电脑、笔记本电脑、掌上电脑、车载电子设备、可穿戴设备等设备。

在该实施例中，第二电子设备(例如服务器)在接收到第一电子设备发送的应用程序的版本更新请求时，确定第一电子设备需要进行应用程序版本更新。在此情况下判断该应用程序是否有更新版本，如果存在更新版本，则需要判断第一电子设备下载该更新版本所需的目标流量是否超过预设时间段(例如当前时间段)内的允许使用流量。如果目标流量超过预设时间段内的允许使用流量，则向第一电子设备反馈没有更新版本的信息；如果目标流量未超过预设时间段内的允许使用流量，则向第一电子设备推送更新版本，以使第一电子设备下载更新版本，从而对应用程序进行版本更新。

通过上述方式，采用削峰填谷的思想，控制在预设时间段内只能允许不超过流量控制设定值(即允许使用流量)的更新版本进行下载，从而控制单位时间内CDN流量，避免CDN流量波形出现尖峰的情况，把原来的忽高忽低的CDN流量波形变得平稳，当把日峰值降低之后，根据计费规则，CDN的费用也就随之降低，相应节省的带宽流量也可以给其他用户使用，充分达到省流降费的目的。

需要说明的是，对于第一电子设备的应用程序出现了漏洞问题，需要及时进行修复的情况下，需要能控制该APP的特定版本不进行流量控制，及时地让用户进行程序升级，不进行流量管控。具体地，版本更新请求中携带有应用程序的当前版本号，根据当前版本号确定应用程序需要进行版本升级还是需要进行版本修复，进而在进行版本升级时进行流量管控，在进行版本修复时不进行流量管控。

进一步地，在本申请的一个实施例中，在确定下载更新版本所需的目标流量之后，还包括：根据预设时间段内总使用流量和已使用流量，确定预设时间段内允许使用流量。

在该实施例中，限定了一种确定预设时间段内的允许使用流量的方式。

首先，确定预设时间段内的总使用流量。具体地，CDN带宽越大，APP升级的速度就会越快，根据CDN费用计算规则，即日峰值月平均，那么花费的成本也就越高。则需要在时间和成本两个维度做出一个折中，确定一定时间段内到底要使用多大的带宽(即总使用流量)，例如计算出每秒钟允许总共下载多少流量(Mbps)。假设现在计算的结果是5000Mbps，那么一秒钟总共允许下载5000M。按照1Mb等于1个令牌来计算，则每秒钟有5000个令牌。当然，如果想进行更细粒度的控制，也可以按照1Kb或1b等于1个令牌来进行计算。

在确定出每秒钟5000个令牌后，需要在***里面每秒钟发放5000个令牌以备用，在当前时间(比如2021年3月26日19:46:48)发放5000个令牌，在下一秒(2021年3月26日19:46:49)再次发放5000个令牌。

因为在一定时间段内可能会下载多个应用程序，所以在当前需要下载的应用程序之前，可能已经使用了一部分流量用于下载了其他应用程序。因此，需要进一步地确定在预设时间段内的已使用流量。通过计算总使用流量与已使用流量的差，得到预设时间段内的允许使用流量。

在该实施例中，本申请实施例的应用程序的下载控制方法的一种可实施过程如图2所示，包括：

步骤202，客户端的APP每间隔一段时间发起版本更新请求；

步骤204，服务端检测是否有该APP的更新版本，如果没有，则进入步骤206，如果有，则进入步骤208；

步骤206，向客户端反馈没有更新版本的信息；

步骤208，判断当前时间段内的令牌是否足够进行更新版本下载，如果足够，则进入步骤210，如果不足够，则进入步骤206；

步骤210，更新当前已消耗令牌的数量；

步骤212，向客户端反馈更新版本的下载地址；

步骤214，客户端下载更新版本，并进行APP的版本更新。

在该实施例中，客户端(即第一电子设备)的APP需要设置一个定时器，定时地像服务端(即服务器)发送版本更新请求，比如间隔1分钟请求一次，在该请求中需要携带APP的当前版本号。服务端接收到版本更新请求之后，根据其中携带的当前版本号与最新的版本号进行比对，判断客户端的APP是否需要更新。如果不需要更新则返回没有更新版本的信息；如果需要更新，则获取当前待下载的APP更新版本的大小，然后向上取整，比如更新版本的大小为17.5M，那么取18M，根据1M＝1令牌，确定本次下载需要18个令牌。

进一步地，判断当前时间(比如2021年3月26日19:46:48)下发的5000个令牌中还剩下多少能够使用的，然后判断剩余的令牌减去18是否大于零，如果小于零，表示令牌以超出，不能进行下载，则流程结束。否则从剩余的令牌数量中减去18，向客户端反馈更新版本的下载地址。客户端收到下载地址后，发起下载更新版本，然后进行安装，到此APP更新完成。

通过上述方式，采用削峰填谷的思想，控制一定时间段内可供下载的流量大小，从而降低需支付的CDN费用。

进一步地，在本申请的一个实施例中，确定预设时间段内允许使用流量，包括：在应用程序的数量包括多个的情况下，按照版本更新请求的接收时刻的先后顺序，确定应用程序对应的预设时间段内允许使用流量。

在该实施例中，在实际使用中一个第一电子设备可能同时下载更新多个应用程序，多个第一电子设备也会同时更新一个应用程序，情况会更复杂，所以需要进行并发控制。具体地，根据版本更新请求的先后顺序进行排队处理，防止允许使用流量计算错误。例如，先接收到的版本更新请求对应的应用程序大小是15M，后接收到的版本更新请求对应的应用程序大小是18M，那么扣减的时候，需要先扣除15个令牌，再扣除18个令牌，以得到后接收到的版本更新请求对应的应用程序的允许使用流量。

通过上述方式，提高了对下载应用程序的允许使用流量的计算的准确性，从而确保对是否下载该应用程序的判断的准确性，以达到省流降费的目的。

进一步地，在本申请的一个实施例中，在接收第一电子设备发送的应用程序的版本更新请求之前，还包括：将预设时间段划分为预设数量的子时间段，并根据预设时间段内总使用流量，对每个子时间段设置对应的子流量；在确定下载更新版本所需的目标流量之后，还包括：确定版本更新请求的接收时间所对应的第一子时间段，第一子时间段为预设数量的子时间段中的一个；在第一子时间段为预设时间段的第一个子时间段的情况下，将第一子时间段对应的子允许使用流量，作为预设时间段内允许使用流量；在第一子时间段为预设时间段的第N个子时间段的情况下，将第二子时间段对应的子允许使用流量，累计至第一子时间段，并将第一子时间段对应的子允许使用流量，作为预设时间段内允许使用流量；其中，N为大于1的正整数，第二子时间段为预设时间段中第一子时间段前的N-1个子时间段，第一子时间段的子允许使用流量为第一子时间段的子流量中未被使用的流量，第二子时间段的子允许使用流量为第二子时间段的子流量中未被使用的流量。

在该实施例中，限定了另一种确定预设时间段内的允许使用流量的方式。

需要说明的是，上述实施例中限定的是每秒钟生成多少个令牌，前一秒和后一秒之间没任何的关系，把这种控制方式称之为固定窗口令牌生成策略。假如当前令牌的生成规则设置为1秒钟1000个令牌，如图3所示，在第1秒的最后100ms以及第2秒的最开始100ms，第一电子设备请求更新的APP都使用了1000个令牌，那么就会出现在这个200ms周期中需要下载2000个令牌对应的CDN流量。因为存在网络通信延迟，这就会导致在第2秒存在两倍的配置速率问题，也就是把第1秒和第2秒的流量全部用在了第2秒里面。或者，在第1秒的最后100ms以及倒数第二个100ms，第一电子设备请求更新的APP都使用了100个令牌，那么就会出现在这个200ms周期中需要下载200个令牌对应的CDN流量。因为存在网络通信延迟，这就会导致在第1秒的最后100ms存在两倍的配置速率问题，也就是把倒数第二个100ms和最后100ms的流量全部用在了最后100ms里面。

本申请实施例中利用滑动窗口令牌生成策略控制CDN带宽，实现对令牌动态生成服务的改进，以解决上述问题。

具体地，将预设时间段划分为预设数量的子时间段，并根据预设时间段内的总使用流量，对每个子时间段设置对应的子流量。例如，将原来的一个窗口(即预设时间段)分为若干个等份的小窗口(即子时间段)，每个小窗口对应不同的时间点，且拥有独立的计数器，每个小窗口均对应设置一定数量的令牌。当版本更新请求的接收时间点大于当前窗口的最大时间点时，则将窗口向前平移一个小窗口(将第一个小窗口的数据舍弃，第二个小窗口变成第一个小窗口，当前版本更新请求放在最后一个小窗口)。值得注意的是，整个窗口的所有请求数相加不能大于配置的每秒钟生成的令牌总数。

进一步地，确定版本更新请求的接收时间所对应的第一子时间段，在第一子时间段为预设时间段的第一个子时间段的情况下，将第一子时间段的子允许使用流量，作为预设时间段内的允许使用流量。需要说明的是，第一子时间段的子允许使用流量为第一子时间段的子流量中未被使用的流量，如果第一子时间段未被使用，则第一子时间段的全部的子流量即为第一子时间段的子允许使用流量。

在第一子时间段为预设时间段的第N个子时间段的情况下，将预设时间段中位于第一子时间段前的N-1个子时间段对应的子允许使用流量，累计至第一子时间段，需要说明的是，N-1个子时间段对应的子允许使用流量，即为N-1个子时间段中每个子时间段对应的子流量中未被使用的部分。

此时第一子时间段对应的子允许使用流量包括第一子时间段本身的子允许使用流量，还包括第一子时间段前的N-1个子时间段对应的子允许使用流量。将此时第一子时间段对应的子允许使用流量，作为预设时间段内的允许使用流量。

如图4所示，把一秒钟的窗口划分为6个小窗口，每个窗口占据1/6秒，当用户请求超过了第一个1/6秒之后，就会把小窗口向前滑动。值得注意的是，需要控制图4中每次滑动之后，1秒的窗口内令牌的大小不能超过每秒钟生成的令牌总数。

小窗口的时间跨度可以任意设定，在1毫秒至1000毫秒之间都是可以的。

以小窗口的大小设置为1毫秒来进行举例。假如现在令牌的生成规则设置为1秒钟1000个令牌，那么对应一个小窗口就是1个令牌，如果当前用户请求下载18M的应用程序，就需要18个令牌。如果当前小窗口里面累计的令牌数只有1个，那么就获取不到足够的令牌，下载失败。

如果下一个用户是在第18个小个窗口的时间点进行请求，小窗口向前滑动17次，则第18个小窗口累计到了18个令牌，则刚好满足用户对令牌的需要，就允许下载，并减去相应的令牌数，接着下一个小窗口的累计令牌也就从1开始。如果当前小窗口累计了18个令牌，而用户请求下载15M的应用程序，则允许用户下载，并扣减15个令牌，并把多余的令牌传递给下一个小窗口，则下一个小窗口累计的令牌数是4(3+1，3是上个小窗口遗留的，1是这个小窗口本身的)。需要注意的是，下一个小窗口累计的令牌数不能超过1秒钟的令牌总数，也就是不能超过1000个令牌，如果超过了则直接清零。

本申请实施例，通过滑动窗口的思想来改进允许使用流量的生成，将流量均累计至版本更新请求的接收时间所对应的子时间段，能够计时地提供给更新版本下载所使用，解决可能出现的某一秒内的两倍配置速率问题。

进一步地，在本申请的一个实施例中，该应用程序的下载控制方法还包括：根据第一电子设备在预设时间段内的历史下载次数，确定预设时间段内总使用流量；其中，预设时间段与预设时间段相对应，历史下载次数越多，总使用流量越大。

在该实施例中，预设时间段内的总使用流量可以为一个固定值，例如，根据一天需要的CDN总量除以24×3600，计算出每秒钟的总使用流量，这种实施方式一旦设置了一定时间段内的总使用流量，就不再改变。但是，这种实施方式无法做到精细化控制，实际应用中，下载次数可能在每天的不同时间段有所不同，例如用户下载的高峰期可能在19:00至24：00，其他时间都是下载低峰期。再如，在节假日的情况下，用户下载的次数也会比平时要高。因此，本申请实施例提出了根据历史下载次数，动态调整一定时间段内的总使用流量的功能。

具体地，需要一个配置服务，能根据特定的时间间隔来配置一定时间段内的总使用流量。

需要说明的是，配置人员可以根据业务的发展情况随时调整一个大周期内的一定时间段的总使用流量的大小。示例性地，根据一小时的粒度进行每秒钟的总使用流量的设置，也即在这一个小时内，每秒钟都下发相同的总使用流量。例如，00:00至01:00的下载量小，则限制这一个小时内每秒下发500个令牌(即每秒钟的总使用流量)，而20:00至21:00的下载量大，那么调大令牌数，限制这一个小时内每秒下发1500个令牌(即每秒钟的总使用流量)。

如果还想进行更细粒度的控制，可以支持到分钟级别的粒度。也可以结合实际情况进行优化，比如按3小时或4小时的粒度进行控制，优化配置的工作量。

根据配置人员在配置服务配置的规则，实时地生成每秒钟的令牌数，供APP更新服务使用。如图5所示，配置人员配置每个时段的令牌数的大小至配置服务。令牌动态生成服务获取配置数据，生成每秒钟令牌数。客户端(即第一电子设备)发送版本更新请求至APP更新服务。APP更新服务向令牌动态生成服务请求预设时间段的令牌大小，判断令牌数是否允许下载，并更新消耗的令牌数。在允许下载时，APP更新服务向客户端返回APP的下载地址，客户端进行下载安装。

其中，配置服务、令牌动态生成服务和APP更新服务为服务端(即服务器)。

通过上述方式，通过新增配置服务和令牌动态生成服务，能更细粒度地控制CDN的带宽使用，可以根据不同的时段来调整总使用流量，以达到灵活控制一定时间段内的总使用流量的目的。

本申请实施例还提供了一种服务器，如图6所示，该服务器600包括：

接收模块602，用于接收第一电子设备发送的应用程序的版本更新请求；

获取模块604，用于响应于版本更新请求，在应用程序存在更新版本的情况下，确定下载更新版本所需的目标流量；

推送模块606，用于在目标流量小于或等于预设时间段内允许使用流量的情况下，向第一电子设备推送更新版本。

在该实施例中，服务器在接收到第一电子设备发送的应用程序的版本更新请求时，确定第一电子设备需要进行应用程序版本更新。在此情况下判断该应用程序是否有更新版本，如果存在更新版本，则需要判断第一电子设备下载该更新版本的目标流量是否超过预设时间段内的允许使用流量。如果目标流量超过预设时间段内的允许使用流量，则向第一电子设备反馈没有更新版本的信息；如果目标流量未超过预设时间段内的允许使用流量，则向第一电子设备推送更新版本，以使第一电子设备下载更新版本，从而对应用程序进行版本更新。

通过上述方式，采用削峰填谷的思想，控制在预设时间段内只能允许不超过流量控制设定值(即允许使用流量)的更新版本进行下载，从而控制单位时间内CDN流量，避免CDN流量波形出现尖峰的情况，把原来的忽高忽低的CDN流量波形变得平稳，当把日峰值降低之后，根据计费规则，CDN的费用也就随之降低，相应节省的带宽流量也可以给其他用户使用，充分达到省流降费的目的。

进一步地，在本申请的一个实施例中，该服务器600还包括：第一确定模块，用于根据预设时间段内总使用流量和已使用流量，确定预设时间段内允许使用流量。

进一步地，在本申请的一个实施例中，第一确定模块，具体用于在应用程序的数量包括多个的情况下，按照版本更新请求的接收时刻的先后顺序，确定应用程序对应的预设时间段内允许使用流量。

进一步地，在本申请的一个实施例中，该服务器600还包括：划分模块，用于将预设时间段划分为预设数量的子时间段，并根据预设时间段内总使用流量，对每个子时间段设置对应的子流量；第二确定模块，用于：确定版本更新请求的接收时间所对应的第一子时间段，第一子时间段为预设数量的子时间段中的一个；在第一子时间段为预设时间段的第一个子时间段的情况下，将第一子时间段对应的子允许使用流量，作为预设时间段内允许使用流量；在第一子时间段为预设时间段的第N个子时间段的情况下，将第二子时间段对应的子允许使用流量，累计至第一子时间段，并将第一子时间段对应的子允许使用流量，作为预设时间段内允许使用流量；其中，N为大于1的正整数，第二子时间段为预设时间段中第一子时间段前的N-1个子时间段，第一子时间段的子允许使用流量为第一子时间段的子流量中未被使用的流量，第二子时间段的子允许使用流量为第二子时间段的子流量中未被使用的流量。

进一步地，在本申请的一个实施例中，该服务器600还包括：第三确定模块，用于根据第一电子设备在预设时间段内的历史下载次数，确定预设时间段内总使用流量；其中，预设时间段与预设时间段相对应，历史下载次数越多，总使用流量越大。

本申请实施例中的第一电子设备可以是装置，也可以是终端中的部件、集成电路或芯片。该第一电子设备可以是移动电子设备，也可以为非移动电子设备。示例性的，移动电子设备可以为手机、平板电脑、笔记本电脑、掌上电脑、车载电子设备、可穿戴设备、超级移动个人计算机(Ultra-Mobile Personal Computer，UMPC)、上网本或者个人数字助理(Personal Digital Assistant，PDA)等，非移动电子设备可以为网络附属存储器(NetworkAttached Storage，NAS)、个人计算机(Personal Computer，PC)、电视机(Television，TV)、柜员机或者自助机等，本申请实施例不作具体限定。

本申请实施例中的第一电子设备可以为具有操作***的装置。该操作***可以为安卓(Android)操作***，可以为ios操作***，还可以为其他可能的操作***，本申请实施例不作具体限定。

本申请实施例提供的服务器600能够实现图1至图5的方法实施例中实现的各个过程，为避免重复，这里不再赘述。

可选的，如图7所示，本申请实施例还提供一种电子设备700，该电子设备700为上述实施例中的服务器，该电子设备700包括处理器702，存储器704，存储在存储器704上并可在处理器702上运行的程序或指令，该程序或指令被处理器702执行时实现上述应用程序的下载控制方法实施例的各个过程，且能达到相同的技术效果，为避免重复，这里不再赘述。

需要注意的是，本申请实施例中的电子设备包括上述的移动电子设备和非移动电子设备。

图8为实现本申请实施例的一种电子设备的硬件结构示意图。

该电子设备800包括但不限于：射频单元802、网络模块804、音频输出单元806、输入单元808、传感器810、显示单元812、用户输入单元814、接口单元816、存储器818、以及处理器820等部件。

本领域技术人员可以理解，电子设备800还可以包括给各个部件供电的电源(比如电池)，电源可以通过电源管理***与处理器820逻辑相连，从而通过电源管理***实现管理充电、放电、以及功耗管理等功能。图8中示出的电子设备结构并不构成对电子设备的限定，电子设备可以包括比图示更多或更少的部件，或者组合某些部件，或者不同的部件布置，在此不再赘述。

在本申请实施例中，该电子设备800为上述实施例中的服务器，其中，射频单元802，用于接收第一电子设备发送的应用程序的版本更新请求；处理器820，用于响应于版本更新请求，在应用程序存在更新版本的情况下，确定下载更新版本所需的目标流量；射频单元802，还用于在目标流量小于或等于预设时间段内允许使用流量的情况下，向第一电子设备推送更新版本。

在该实施例中，第二电子设备在接收到第一电子设备发送的应用程序的版本更新请求时，确定第一电子设备需要进行应用程序版本更新。在此情况下判断该应用程序是否有更新版本，如果存在更新版本，则需要判断第一电子设备下载该更新版本的目标流量是否超过预设时间段内的允许使用流量。如果目标流量超过预设时间段内的允许使用流量，则向第一电子设备反馈没有更新版本的信息；如果目标流量未超过预设时间段内的允许使用流量，则向第一电子设备推送更新版本，以使第一电子设备下载更新版本，从而对应用程序进行版本更新。

通过上述方式，采用削峰填谷的思想，控制在预设时间段内只能允许不超过流量控制设定值(即允许使用流量)的更新版本进行下载，从而控制单位时间内CDN流量，避免CDN流量波形出现尖峰的情况，把原来的忽高忽低的CDN流量波形变得平稳，当把日峰值降低之后，根据计费规则，CDN的费用也就随之降低，相应节省的带宽流量也可以给其他用户使用，充分达到省流降费的目的。

进一步地，处理器820，还用于根据预设时间段内总使用流量和已使用流量，确定预设时间段内允许使用流量。

进一步地，在本申请的一个实施例中，处理器820，具体用于在应用程序的数量包括多个的情况下，按照版本更新请求的接收时刻的先后顺序，确定应用程序对应的预设时间段内允许使用流量。

进一步地，在本申请的一个实施例中，处理器820，还用于：将预设时间段划分为预设数量的子时间段，并根据预设时间段内总使用流量，对每个子时间段设置对应的子流量；确定版本更新请求的接收时间所对应的第一子时间段，第一子时间段为预设数量的子时间段中的一个；在第一子时间段为预设时间段的第一个子时间段的情况下，将第一子时间段对应的子允许使用流量，作为预设时间段内允许使用流量；在第一子时间段为预设时间段的第N个子时间段的情况下，将第二子时间段对应的子允许使用流量，累计至第一子时间段，并将第一子时间段对应的子允许使用流量，作为预设时间段内允许使用流量；其中，N为大于1的正整数，第二子时间段为预设时间段中第一子时间段前的N-1个子时间段，第一子时间段的子允许使用流量为第一子时间段的子流量中未被使用的流量，第二子时间段的子允许使用流量为第二子时间段的子流量中未被使用的流量。

进一步地，在本申请的一个实施例中，处理器820，还用于根据第一电子设备在预设时间段内的历史下载次数，确定预设时间段内总使用流量；其中，预设时间段与预设时间段相对应，历史下载次数越多，总使用流量越大。

应理解的是，本申请实施例中，射频单元802可用于收发信息或收发通话过程中的信号，具体的，接收基站的下行数据或向基站发送上行数据。射频单元802包括但不限于天线、至少一个放大器、收发信机、耦合器、低噪声放大器、双工器等。

网络模块804为用户提供了无线的宽带互联网访问，如帮助用户收发电子邮件、浏览网页和访问流式媒体等。

音频输出单元806可以将射频单元802或网络模块804接收的或者在存储器818中存储的音频数据转换成音频信号并且输出为声音。而且，音频输出单元806还可以提供与电子设备800执行的特定功能相关的音频输出(例如，呼叫信号接收声音、消息接收声音等等)。音频输出单元806包括扬声器、蜂鸣器以及受话器等。

输入单元808用于接收音频或视频信号。输入单元808可以包括图形处理器(Graphics Processing Unit，GPU)8082和麦克风8084，图形处理器8082对在视频捕获模式或图像捕获模式中由图像捕获装置(如摄像头)获得的静态图片或视频的图像数据进行处理。处理后的图像帧可以显示在显示单元812上，或者存储在存储器818(或其它存储介质)中，或者经由射频单元802或网络模块804发送。麦克风8084可以接收声音，并且能够将声音处理为音频数据，处理后的音频数据可以在电话通话模式的情况下转换为可经由射频单元802发送到移动通信基站的格式输出。

电子设备800还包括至少一种传感器810，比如指纹传感器、压力传感器、虹膜传感器、分子传感器、陀螺仪、气压计、湿度计、温度计、红外线传感器、光传感器、运动传感器以及其他传感器。

显示单元812用于显示由用户输入的信息或提供给用户的信息。显示单元812可包括显示面板8122，可以采用液晶显示器、有机发光二极管等形式来配置显示面板8122。

用户输入单元814可用于接收输入的数字或字符信息，以及产生与电子设备的用户设置以及功能控制有关的键信号输入。具体地，用户输入单元814包括触控面板8142以及其他输入设备8144。触控面板8142也称为触摸屏，可收集用户在其上或附近的触摸操作。触控面板8142可包括触摸检测装置和触摸控制器两个部分。其中，触摸检测装置检测用户的触摸方位，并检测触摸操作带来的信号，将信号传送给触摸控制器；触摸控制器从触摸检测装置上接收触摸信息，并将它转换成触点坐标，再送给处理器820，接收处理器820发来的命令并加以执行。其他输入设备8144可以包括但不限于物理键盘、功能键(比如音量控制按键、开关按键等)、轨迹球、鼠标、操作杆，在此不再赘述。

进一步的，触控面板8142可覆盖在显示面板8122上，当触控面板8142检测到在其上或附近的触摸操作后，传送给处理器820以确定触摸事件的类型，随后处理器820根据触摸事件的类型在显示面板8122上提供相应的视觉输出。触控面板8142与显示面板8122可作为两个独立的部件，也可以集成为一个部件。

接口单元816为外部装置与电子设备800连接的接口。例如，外部装置可以包括有线或无线头戴式耳机端口、外部电源(或电池充电器)端口、有线或无线数据端口、存储卡端口、用于连接具有识别模块的装置的端口、音频输入/输出(I/O)端口、视频I/O端口、耳机端口等等。接口单元816可以用于接收来自外部装置的输入(例如，数据信息、电力等等)并且将接收到的输入传输到电子设备800内的一个或多个元件或者可以用于在电子设备800和外部装置之间传输数据。

存储器818可用于存储软件程序以及各种数据。存储器818可主要包括存储程序区和存储数据区，其中，存储程序区可存储操作***、至少一个功能所需的应用程序(比如声音播放功能、图像播放功能等)等；存储数据区可存储根据移动终端的使用所创建的数据(比如音频数据、电话本等)等。此外，存储器818可以包括高速随机存取存储器，还可以包括非易失性存储器，例如至少一个磁盘存储器件、闪存器件、或其他易失性固态存储器件。

处理器820通过运行或执行存储在存储器818内的软件程序和/或模块，以及调用存储在存储器818内的数据，执行电子设备800的各种功能和处理数据，从而对电子设备800进行整体监控。处理器820可包括一个或多个处理单元；优选的，处理器820可集成应用处理器和调制解调处理器，其中，应用处理器主要处理操作***、用户界面和应用程序等，调制解调处理器主要处理无线通信。

本申请实施例还提供一种可读存储介质，可读存储介质上存储有程序或指令，该程序或指令被处理器执行时实现上述应用程序下载控制实施例的各个过程，且能达到相同的技术效果，为避免重复，这里不再赘述。

其中，处理器为上述实施例中的电子设备中的处理器。可读存储介质，包括计算机可读存储介质，如计算机只读存储器(Read-Only Memory，ROM)、随机存取存储器(RandomAccess Memory，RAM)、磁碟或者光盘等。

本申请实施例另提供了一种芯片，芯片包括处理器和通信接口，通信接口和处理器耦合，处理器用于运行程序或指令，实现上述应用程序下载控制实施例的各个过程，且能达到相同的技术效果，为避免重复，这里不再赘述。

应理解，本申请实施例提到的芯片还可以称为***级芯片、***芯片、芯片***或片上***芯片等。

需要说明的是，在本文中，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者装置不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者装置所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括该要素的过程、方法、物品或者装置中还存在另外的相同要素。此外，需要指出的是，本申请实施方式中的方法和装置的范围不限按示出或讨论的顺序来执行功能，还可包括根据所涉及的功能按基本同时的方式或按相反的顺序来执行功能，例如，可以按不同于所描述的次序来执行所描述的方法，并且还可以添加、省去、或组合各种步骤。另外，参照某些示例所描述的特征可在其他示例中被组合。

通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到上述实施例方法可借助软件加必需的通用硬件平台的方式来实现，当然也可以通过硬件，但很多情况下前者是更佳的实施方式。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分可以以计算机软件产品的形式体现出来，该计算机软件产品存储在一个存储介质(如ROM/RAM、磁碟、光盘)中，包括若干指令用以使得一台终端(可以是手机，计算机，服务器，或者网络设备等)执行本申请各个实施例所述的方法。

上面结合附图对本申请的实施例进行了描述，但是本申请并不局限于上述的具体实施方式，上述的具体实施方式仅仅是示意性的，而不是限制性的，本领域的普通技术人员在本申请的启示下，在不脱离本申请宗旨和权利要求所保护的范围情况下，还可做出很多形式，均属于本申请的保护之内。

Claims (10)

1.一种应用程序的下载控制方法，其特征在于，包括：

接收第一电子设备发送的应用程序的版本更新请求；

响应于所述版本更新请求，在所述应用程序存在更新版本的情况下，确定下载所述更新版本所需的目标流量；

在所述目标流量小于或等于预设时间段内允许使用流量的情况下，向所述第一电子设备推送所述更新版本。

2.根据权利要求1所述的应用程序的下载控制方法，其特征在于，在所述确定下载所述更新版本所需的目标流量之后，还包括：

根据所述预设时间段内总使用流量和已使用流量，确定所述预设时间段内允许使用流量。

3.根据权利要求2所述的应用程序的下载控制方法，其特征在于，所述确定所述预设时间段内允许使用流量，包括：

在所述应用程序的数量包括多个的情况下，按照所述版本更新请求的接收时刻的先后顺序，确定所述应用程序对应的所述预设时间段内允许使用流量。

4.根据权利要求1所述的应用程序的下载控制方法，其特征在于，在接收第一电子设备发送的应用程序的版本更新请求之前，还包括：

将所述预设时间段划分为预设数量的子时间段，并根据所述预设时间段内总使用流量，对每个所述子时间段设置对应的子流量；

在所述确定下载所述更新版本所需的目标流量之后，还包括：

确定所述版本更新请求的接收时间所对应的第一子时间段，所述第一子时间段为所述预设数量的子时间段中的一个；

在所述第一子时间段为所述预设时间段的第一个子时间段的情况下，将所述第一子时间段对应的子允许使用流量，作为所述预设时间段内允许使用流量；

在所述第一子时间段为所述预设时间段的第N个子时间段的情况下，将第二子时间段对应的子允许使用流量，累计至所述第一子时间段，并将所述第一子时间段对应的子允许使用流量，作为所述预设时间段内允许使用流量；

其中，N为大于1的正整数，所述第二子时间段为所述预设时间段中所述第一子时间段前的N-1个子时间段，所述第一子时间段的子允许使用流量为所述第一子时间段的子流量中未被使用的流量，所述第二子时间段的子允许使用流量为所述第二子时间段的子流量中未被使用的流量。

5.根据权利要求2至4中任一项所述的应用程序的下载控制方法，其特征在于，还包括：

根据所述第一电子设备在预设时间段内的历史下载次数，确定所述预设时间段内总使用流量；

其中，所述预设时间段与所述预设时间段相对应，所述历史下载次数越多，所述总使用流量越大。

6.一种服务器，其特征在于，包括：

接收模块，用于接收第一电子设备发送的应用程序的版本更新请求；

获取模块，用于响应于所述版本更新请求，在所述应用程序存在更新版本的情况下，确定下载所述更新版本所需的目标流量；

推送模块，用于在所述目标流量小于或等于预设时间段内允许使用流量的情况下，向所述第一电子设备推送所述更新版本。

7.根据权利要求6所述的服务器，其特征在于，还包括：

第一确定模块，用于根据所述预设时间段内总使用流量和已使用流量，确定所述预设时间段内允许使用流量。

8.根据权利要求7所述的服务器，其特征在于，

所述第一确定模块，具体用于在所述应用程序的数量包括多个的情况下，按照所述版本更新请求的接收时刻的先后顺序，确定所述应用程序对应的所述预设时间段内允许使用流量。

9.根据权利要求6所述的服务器，其特征在于，还包括：

划分模块，用于将所述预设时间段划分为预设数量的子时间段，并根据所述预设时间段内总使用流量，对每个所述子时间段设置对应的子流量；

第二确定模块，用于：

确定所述版本更新请求的接收时间所对应的第一子时间段，所述第一子时间段为所述预设数量的子时间段中的一个；

在所述第一子时间段为所述预设时间段的第一个子时间段的情况下，将所述第一子时间段对应的子允许使用流量，作为所述预设时间段内允许使用流量；

在所述第一子时间段为所述预设时间段的第N个子时间段的情况下，将第二子时间段对应的子允许使用流量，累计至所述第一子时间段，并将所述第一子时间段对应的子允许使用流量，作为所述预设时间段内允许使用流量；

其中，N为大于1的正整数，所述第二子时间段为所述预设时间段中所述第一子时间段前的N-1个子时间段，所述第一子时间段的子允许使用流量为所述第一子时间段的子流量中未被使用的流量，所述第二子时间段的子允许使用流量为所述第二子时间段的子流量中未被使用的流量。

10.根据权利要求7至9中任一项所述的服务器，其特征在于，还包括：

第三确定模块，用于根据所述第一电子设备在预设时间段内的历史下载次数，确定所述预设时间段内总使用流量；

其中，所述预设时间段与所述预设时间段相对应，所述历史下载次数越多，所述总使用流量越大。

Images