CN116800733B - 一种差分包的下载方法及服务器 - Google Patents

一种差分包的下载方法及服务器 Download PDF

Info

Publication number
CN116800733B
CN116800733B CN202311045987.4A CN202311045987A CN116800733B CN 116800733 B CN116800733 B CN 116800733B CN 202311045987 A CN202311045987 A CN 202311045987A CN 116800733 B CN116800733 B CN 116800733B
Authority
CN
China
Prior art keywords
server
differential packet
record
records
differential
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
CN202311045987.4A
Other languages
English (en)
Other versions
CN116800733A (zh
Inventor
李前国
杨颂
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Honor Device Co Ltd
Original Assignee
Honor Device Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Honor Device Co Ltd filed Critical Honor Device Co Ltd
Priority to CN202311045987.4A priority Critical patent/CN116800733B/zh
Publication of CN116800733A publication Critical patent/CN116800733A/zh
Application granted granted Critical
Publication of CN116800733B publication Critical patent/CN116800733B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/01Protocols
    • H04L67/06Protocols specially adapted for file transfer, e.g. file transfer protocol [FTP]
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00Arrangements for software engineering
    • G06F8/60Software deployment
    • G06F8/65Updates
    • G06F8/658Incremental updates; Differential updates
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/01Protocols
    • H04L67/10Protocols in which an application is distributed across nodes in the network
    • H04L67/1097Protocols in which an application is distributed across nodes in the network for distributed storage of data in networks, e.g. transport arrangements for network file system [NFS], storage area networks [SAN] or network attached storage [NAS]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/34Network arrangements or protocols for supporting network services or applications involving the movement of software or configuration parameters 
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04MTELEPHONIC COMMUNICATION
    • H04M1/00Substation equipment, e.g. for use by subscribers
    • H04M1/72Mobile telephones; Cordless telephones, i.e. devices for establishing wireless links to base stations without route selection
    • H04M1/724User interfaces specially adapted for cordless or mobile telephones
    • H04M1/72403User interfaces specially adapted for cordless or mobile telephones with means for local support of applications that increase the functionality
    • H04M1/72406User interfaces specially adapted for cordless or mobile telephones with means for local support of applications that increase the functionality by software upgrading or downloading

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Software Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Human Computer Interaction (AREA)
  • Computer Security & Cryptography (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Information Transfer Between Computers (AREA)

Abstract

本申请实施例涉及计算机技术领域,尤其涉及一种差分包的下载方法及服务器,能够节省服务器中差分包的储存空间。该方法应用于服务器,该方法包括:接收第一电子设备的第一查询请求,第一查询请求用于请求下载第一APP的第一差分包;若服务器未生成第一差分包,生成第一记录;第一记录用于记录第一查询请求所请求的第一差分包;获取第一时间段内生成的第一记录的数量;第一时间段包括服务器接收到第一查询请求的当前时刻前的预设时长;或第一时间段包括第一时刻到服务器接收到第一查询请求的当前时刻之间的时间段;或第一时间段为预设时间段;若第一记录的数量大于第一阈值,生成第一记录所记录的第一差分包,并在第二下载地址存储第一差分包。

Description

一种差分包的下载方法及服务器
技术领域
本申请实施例涉及计算机技术领域,尤其涉及一种差分包的下载方法及服务器。
背景技术
电子设备可以从服务器获取软件更新包,来升级电子设备中应用程序(APP)的版本。目前,为了减少软件更新包的传输对网络带宽的占用,节省电子设备下载软件更新包的下载时间及下载流量,APP的版本更新都是采用增量升级的方式。其中,增量升级是指利用差分包升级应用程序,该差分包也可以称为增量包。差分包主要包括电子设备中的低版本安装包与服务器中高版本安装包之间的差异数据。
服务器存储有APP的最新版本的安装包、历史版本的安装包及已生成的差分包。示例性的,响应于接收到电子设备的查询请求,若服务器未存储有该查询请求所请求的差分包,服务器可以根据查询请求生成差分包。之后,服务器可以存储该差分包并将差分包的下载路径发送给电子设备。电子设备可以通过下载路径获取差分包,并使用差分包进行升级。
由于APP的种类不断增加,APP升级速度逐渐提升,APP的版本也越来越多;并且不同用户的升级习惯及升级频率也不同,导致差分包的数量越来越多,差分包对服务器存储空间的占用也急剧增加。
发明内容
本申请实施例提供一种差分包的下载方法及服务器,用于节省服务器中差分包的存储空间。
为达到上述目的,本申请的实施例采用如下技术方案:
第一方面,提供一种差分包的下载方法。该方法应用于服务器,该方法包括:服务器接收来自第一电子设备的第一查询请求,第一查询请求用于请求下载第一APP的第一差分包;若服务器已生成第一差分包,则向第一电子设备指示第一差分包的第一下载地址;若服务器未生成第一差分包,则生成第一记录;其中,第一记录用于记录第一查询请求所请求的第一差分包;服务器获取第一时间段内由服务器生成的第一记录的数量;其中,第一时间段包括服务器接收到第一查询请求的当前时刻前的预设时长;或者,第一时间段包括第一时刻到服务器接收到第一查询请求的当前时刻之间的时间段;或者,第一时间段为预设时间段;若第一记录的数量大于第一阈值,则生成第一记录所记录的第一差分包,并在第二下载地址存储第一差分包。
本申请中,服务器在接收到电子设备发送的第一查询请求之后,若服务器已生成该第一查询请求所请求的第一差分包,服务器可以向电子设备指示该第一差分包的第一下载地址,电子设备可以通过第一下载地址下载第一差分包。若服务器未生成有该第一差分包,服务器可以生成第一记录,第一记录用于记录第一查询请求所请求的第一差分包。服务器可以获取在接收到查询请求的当前时刻之前预设时长(第一时间段)内,服务器生成第一记录的数量,或者,服务器可以获取第一时刻至接收到查询请求的当前时刻(第一时间段)内,服务器生成第一记录的数量,或者服务器可以获取预设时间段(第一时间段)内,服务器生成第一记录的数量。之后,服务器可以判断第一时间段内服务器生成第一记录的数量是否大于第一阈值。若第一时间段内服务器生成第一记录的数量大于第一阈值,说明第一时间段内请求下载第一差分包的第一查询请求的数量大于第一阈值,也能说明第一时间段内请求下载第一差分包的电子设备的数量较多。此时,服务器可以生成第一记录所记录的第一差分包,进而满足大多数用户的下载需求。即本申请中,服务器可以根据用户对第一差分包的需求程度,生成需求程度高的第一差分包,满足大部分用户的需求的同时节省存储第一差分包的空间。
在第一方面的一种可能的实现方式中,第一时间段包括当前时刻前的预设时长;或者,第一时间段包括第一时刻到当前时刻之间的时间段。即服务器可以在接收到第一查询请求时,获取第一时间段内第一记录的数量,及时生成第一记录所记录的第一差分包。
具体的,若第一记录的数量大于第一阈值,则服务器生成第一记录所记录的第一差分包,之后,服务器还可以向第一电子设备指示第一差分包的第二下载地址。本申请中,若服务器未生成有第一差分包,服务器可以获取在接收到查询请求的当前时刻前的预设时长(第一时间段)内,或者服务器可以获取第一时刻至接收到查询请求的当前时刻(第一时间段)内,服务器生成第一记录的数量。并在第一记录的数量大于第一阈值时,生成第一记录所记录的第一差分包。之后,服务器可以向电子设备指示第一差分包的第二下载地址。电子设备可以通过第二下载地址下载第一差分包。如此,服务器可以在接收到第一查询请求之后,且服务器未生成有第一差分包时。服务器可以及时获取第一时间段内生成第一记录的数量,并且在第一记录的数量大于第一阈值时,及时生成第一差分包。
在第一方面的一种可能的实现方式中,第一时间段为预设时间段。服务器可以在接收到第一查询请求之后,先向第一电子设备指示全量包的第三下载地址。之后,获取预设时间段内生成第一记录的数量,进而,根据第一记录的生成数量生成第一记录所记录的第一差分包。之后,响应于第二电子设备的第二查询请求,该第二查询请求也请求获取第一差分包时,服务器可以直接向第二电子设备指示第一差分包的第二下载地址。
具体的,若服务器未生成第一差分包,则向第一电子设备指示第一APP的全量包的第三下载地址。接收来自第二电子设备的第二查询请求,第二查询请求用于请求下载第一APP的第一差分包。服务器已生成第一差分包,向第二电子设备指示第一差分包的第二下载地址。
在第一方面的一种可能的实现方式中,若第一记录的生成数量大于第一阈值,服务器可以先将该第一记录标记为待生成差分包的记录。服务器接收到第三电子设备发送的第三查询请求,该第三查询请求请求获取第一差分包时,服务器再生成第一记录所记录的差分包。
具体的,若第一记录的数量大于第一阈值,则标记第一记录为待生成差分包的记录。接收来自第三电子设备发送的第三查询请求,第三查询请求用于请求下载第一APP的第一差分包。服务器未生成第一差分包,但第一记录标记为待生成差分包的记录,则生成第一记录所记录的第一差分包,并在第二下载地址存储第一差分包。
在第一方面的一种可能的实现方式中,若第一时间段内第一记录的生成数量小于第一阈值,服务器可以根据M个第一时间段内每个第一时间段内第一记录的生成数量,进一步评估是否生成第一记录所记录的第一差分包。
具体的,若第一记录的数量小于第一阈值,则获取M个第一时间段内每个第一时间段内生成的第一记录的数量。其中,M个第一时间段具有相同的时长。若M个第一时间段内至少有m个第一时间段内第一记录的数量均大于第二阈值,则生成第一记录所记录的第一差分包,并在第四下载地址存储第一差分包。其中,M、m为大于1的整数,第一阈值大于第二阈值。
在第一方面的一种可能的实现方式中,若第一时间段内第一记录的生成数量小于第一阈值,服务器可以根据M个第一时间段内每个第一时间段内第一记录的第一置信度,进一步评估是否生成第一记录所记录的第一差分包。
具体的,若第一记录的数量小于第一阈值,则获取M个第一时间段内每个第一时间段内生成的第一记录的数量。其中,M个第一时间段具有相同的时长。若M个第一时间段内第一记录的第一置信度大于预设置信度,则生成第一记录所记录的第一差分包,并在第四下载地址存储第一差分包。第一置信度=m/M。m为M个第一时间段中生成第一记录的数量大于第二阈值的第一时间段的数量。其中,M、m为大于1的整数。
在第一方面的一种可能的实现方式中,服务器还可以根据一段时间内的第一查询请求,删除下载频率较低的第一差分包,进一步节省服务器存储第一差分包的存储空间。本申请中,若服务器已生成第一差分包,则生成第二记录,第二记录用于记录第一查询请求所请求的第一差分包。获取N个第一时间段内每个第一时间段内生成的第二记录的数量,其中,N个第一时间段具有相同的时长。若N个第一时间段内至少有n个第一时间段内第二记录的数量均小于第三阈值,则删除第二记录所记录的第一差分包,其中N、n为大于1的整数。
在第一方面的一种可能的实现方式中,服务器可以根据N个第一时间段内每个第一时间段内第二记录的第二置信度,进一步评估是否删除成第二记录所记录的第一差分包。
具体的,若服务器已生成第一差分包,则生成第二记录,第二记录用于记录第一查询请求所请求的第一差分包。;获取N个第一时间段内每个第一时间段内生成的第二记录的数量。其中,N个第一时间段具有相同的时长。若N个第一时间段内第二记录的第二置信度大于第二预设置信度,删除第二记录所记录的第一差分包。其中,第二置信度=n/N,n为N个第一时间段中生成第二记录的数量小于第三阈值的第一时间段的数量。其中N、n为大于1的整数
第二方面,提供一种服务器,服务器包括:存储器、通信模块和一个或多个处理器;存储器、通信模块与处理器耦合;其中,通信模块用于与电子设备交互,存储器用于存储计算机程序代码,计算机程序代码包括计算机指令;当计算机指令被处理器执行时,使得服务器执行如下步骤:接收来自第一电子设备的第一查询请求,第一查询请求用于请求下载第一APP的第一差分包;若服务器已生成第一差分包,则向第一电子设备指示第一差分包的第一下载地址;若服务器未生成第一差分包,则生成第一记录;其中,第一记录第一查询请求所请求的第一差分包;服务器获取第一时间段内由服务器生成的第一记录的数量;其中,第一时间段包括服务器接收到第一查询请求的当前时刻前的预设时长;或者,第一时间段包括第一时刻到服务器接收到第一查询请求的当前时刻之间的时间段;或者,第一时间段为预设时间段;若第一记录的数量大于第一阈值,则生成第一记录所记录的第一差分包,并在第二下载地址存储第一差分包。
结合第二方面,在一种可能的设计方式中,第一时间段包括当前时刻前的预设时长;或者,第一时间段包括第一时刻到当前时刻之间的时间段;当上述计算机指令被处理器执行时,使得电子设备还执行以下步骤:在若第一记录的数量大于第一阈值,则生成第一记录所记录的第一差分包之后,向第一电子设备指示第一差分包的第二下载地址。
结合第二方面,在一种可能的设计方式中,第一时间段为预设时间段;当上述计算机指令被处理器执行时,使得电子设备还执行以下步骤:若服务器未生成第一差分包,则向第一电子设备指示第一APP的全量包的第三下载地址;接收来自第二电子设备的第二查询请求,第二查询请求用于请求下载第一APP的第一差分包;服务器已生成第一差分包,向第二电子设备指示第一差分包的第二下载地址。
结合第二方面,在一种可能的设计方式中,当上述计算机指令被处理器执行时,使得电子设备还执行以下步骤:若第一记录的数量大于第一阈值,则标记第一记录为待生成差分包的记录;接收来自第三电子设备发送的第三查询请求,第三查询请求用于请求下载第一APP的第一差分包;服务器未生成第一差分包,但第一记录标记为待生成差分包的记录,则生成第一记录所记录的第一差分包,并在第二下载地址存储第一差分包。
结合第二方面,在一种可能的设计方式中,当上述计算机指令被处理器执行时,使得电子设备还执行以下步骤:若第一记录的数量小于第一阈值,则获取M个第一时间段内每个第一时间段内生成的第一记录的数量,其中,M个第一时间段具有相同的时长;若M个第一时间段内至少有m个第一时间段内第一记录的数量均大于第二阈值,则生成第一记录所记录的第一差分包,并在第四下载地址存储第一差分包,其中,M、m为大于1的整数,第一阈值大于第二阈值。
结合第二方面,在一种可能的设计方式中,当上述计算机指令被处理器执行时,使得电子设备还执行以下步骤:若第一记录的数量小于第一阈值,则获取M个第一时间段内每个第一时间段内生成的第一记录的数量,其中,M个第一时间段具有相同的时长;若M个第一时间段内第一记录的第一置信度大于预设置信度,则生成第一记录所记录的第一差分包,并在第四下载地址存储第一差分包,第一置信度=m/M,m为M个第一时间段中生成第一记录的数量大于第二阈值的第一时间段的数量。
结合第二方面,在一种可能的设计方式中,当上述计算机指令被处理器执行时,使得电子设备还执行以下步骤:若服务器已生成第一差分包,则生成第二记录,第二记录用于记录第一查询请求所请求的第一差分包;获取N个第一时间段内每个第一时间段内生成的第二记录的数量,其中,N个第一时间段具有相同的时长;若N个第一时间段内至少有n个第一时间段内第二记录的数量均小于第三阈值,则删除第二记录所记录的第一差分包,其中N、n为大于1的整数。
结合第二方面,在一种可能的设计方式中,当上述计算机指令被处理器执行时,使得电子设备还执行以下步骤:若服务器已生成第一差分包,则生成第二记录,第二记录用于记录第一查询请求所请求的第一差分包;获取N个第一时间段内每个第一时间段内生成的第二记录的数量,其中,N个第一时间段具有相同的时长;若N个第一时间段内第二记录的第二置信度大于第二预设置信度,删除第二记录所记录的第一差分包,其中,第二置信度=n/N,n为N个第一时间段中生成第二记录的数量小于第三阈值的第一时间段的数量。
第三方面,本申请提供一种芯片系统,该芯片系统可以应用于包括存储器的服务器。该芯片系统包括一个或多个接口电路和一个或多个处理器。该接口电路和处理器通过线路互联。该接口电路用于从上述存储器接收信号,并向处理器发送该信号,该信号包括存储器中存储的计算机指令。当处理器执行该计算机指令时,服务器执行如第一方面及其任一种可能的设计方式的方法。
第四方面,本申请提供一种计算机可读存储介质,该计算机可读存储介质包括计算机指令。当计算机指令在服务器上运行时,使得该服务器执行如第一方面及其任一种可能的设计方式的方法。
第五方面,本申请提供一种计算机程序产品,当计算机程序产品在计算机上运行时,使得计算机执行如第一方面及其任一种可能的设计方式的方法。
可以理解地,上述第二方面的服务器、第三方面的芯片系统,第四方面的计算机可读存储介质,第五方面的计算机程序产品所能达到的有益效果,可参考如第一方面及其任一种可能的设计方式中的有益效果,此处不再赘述。
附图说明
图1为相关技术提供的一种更新包下载系统的架构示意图;
图2为相关技术提供的一种差分包下载系统的架构示意图;
图3为相关技术提供的一种差分包的下载方法的流程示意图;
图4为本申请实施例提供的一种差分包的下载方法的流程示意图;
图5为本申请实施例提供的另一种差分包的下载方法的流程示意图;
图6为本申请实施例提供的另一种差分包的下载方法的流程示意图;
图7为本申请实施例提供的一种服务器生成差分包的流程示意图;
图8为本申请实施例提供的另一种差分包的下载方法的流程示意图;
图9为本申请实施例提供的一种手机与服务器内部模块交互示意图;
图10为本申请实施例提供的一种服务器的结构示意图。
具体实施方式
电子设备可以从服务器获取软件更新包,来升级电子设备中应用程序(APP)的版本。电子设备中的APP可以包括电子设备自带的系统APP、以及用户自行下载到电子设中的第三方APP,系统APP可以包括联系人APP、以及设置APP等;第三方APP可以包括:社交类APP、银行类APP、视频类APP等。
图1为相关技术中一种更新包下载系统的架构示意图。该更新包下载系统可以包括位于云侧的服务器、电子设备例如手机、以及内容分发网络服务器(Content DeliveryNetwork,CDN)。其中,云侧的服务器可以与多个CDN服务器连接。多个CDN服务器可以是部署在互联网多个节点上的服务器,其主要作用是在用户访问网站时,根据用户的地理位置和网络状况,自动选择距离用户最近的服务器节点,从而实现快速的内容分发和访问加速。
图1中的手机可以接收用户的第一操作,第一操作用于触发手机向服务器发送查询请求。第一操作例如可以是用户在应用市场APP,点击第一APP的更新按钮。如图1所示,手机显示第一界面,该第一界面可以是应用市场APP的应用更新界面。该第一界面显示多个APP的图标、以及APP的名称、当前版本及待升级版本、以及待升级版本的大小。示例性的,开发者将APP的最新安装包上传至服务器之后,服务器可以向手机推送更新消息,更新消息包括最新版本及最新版本的大小。手机响应于接受到该更新消息生成更新提示,该更新提示可以显示在第一界面中。
应理解,手机也可以自动向服务器发送查询请求。例如,当用户设置手机在连接wifi后自动更新APP时,手机可以在连接Wi-Fi后,自动向服务器发送查询请求。或者,当用户设置手机在固定时刻自动更新APP时,手机可以在固定时刻自动向服务器发送查询请求。
查询请求可以用于查询服务器是否已生成有第一APP的差分包。查询请求例如可以包括第一APP的名称、第一APP的当前版本、第一APP的待升级版本。如图1中,查询请求可以是APP1、V8.8、V8.9。
常规的升级方式可以包括增量升级及全量升级。如图1中,位于云侧的服务器可以将全量包或者差分包存储在各个CDN服务器中。手机可以向位于云侧的服务器发送查询请求。服务器可以向手机发送全量包的下载地址。该下载地址对应一台CDN服务器。手机在接收到上述下载地址之后,手机就可以从该下载地址对应的CDN服务器中下载完整的新版本的安装包(APK),然后用新版本的安装包,覆盖升级电子设备中低版本的安装包。这样的升级方式可以称为全量升级。例如,待升级的APP的当前版本为V1.0,电子设备从CDN服务器获取到V3.0版本的安装包,电子设备用V3.0版本的安装包升级该APP。
手机也可以向位于云侧的服务器发送查询请求,请求获取差分包。响应于接收到查询请求,服务器可以向手机发送差分包的下载地址。该下载地址对应一台CDN服务器。手机在接收到上述下载地址之后,手机就可以从该下载地址对应的CDN服务器中下载新版本的安装包与电子设备中低版本的安装包间的差分包,然后用该差分包再升级APP。这样的升级方式可以称为增量升级。其中,差分包也可以称为增量包。差分包主要包括低版本安装包与高版本之间的差异数据,差分包的大小一般小于完整的安装包,所以利用差分包升级能够节省电子设备下载时间及下载流量。例如,待升级的APP的当前版本为V1.0,电子设备从CDN服务器获取差分包D13,该差分包D13以包括V1.0版本与V3.0版本之间的差异数据。电子设备将差分包D13与APP的当前版本V1.0结合,就可以得到V3.0版本的安装包。
随着技术的发展,电子设备中APP的数量不断增加,APP的版本也在不断更新,服务器生成的差分包的数量越来越多,差分包所占的存储空间也越来越大。
例如,假设第一APP的apk的大小为100M,假设差分包的大小为apk的50%,一个差分包的大小为50M。假设服务器中第一APP的版本为V4.0,开发人员上传了最新版本V7.0的apk之后,服务器基于最新版本并向后回溯一定数量的版本,生成差分包。
以回溯3个版本为例。服务器会生成版本V6.0与版本V7.0间的差分包D67、版本V5.0与版本V7.0间的差分包D57、版本V4.0与版本V7.0间的差分包D47。每个差分包的大小可以是50M。这样针对一次安装包更新,服务器需要生成3*50M=150M的差分包,服务器需要150M的存储空间存储这些差分包。
以回溯5个版本为例。服务器会生成版本V6.0与版本V7.0间的差分包D67、版本V5.0与版本V7.0间的差分包D57、版本V4.0与版本V7.0间的差分包D47、版本V3.0与版本V7.0间的差分包D37、版本V2.0与版本V7.0间的差分包D27、版本V1.0与版本V7.0间的差分包D17。这样针对一次安装包更新,服务器需要生成5*50M=250M的差分包,服务器需要250M的存储空间存储这些差分包。
并且服务器在生成差分包时,会在差分包中集成渠道相关的信息,随着渠道的多样化,服务器生成差分包的数量也急剧增加。
渠道可以理解为用户下载差分包的路线或路径。例如,渠道可以是应用商店、网页等。通过渠道下载的差分包可以称为渠道差分包。渠道差分包内一般会包括渠道标识,也就是说,服务器在生成差分包时还要生成不同渠道的差分包。
继续以前文中的例子为例。
若考虑两个渠道,回溯3个版本。服务器会生成渠道A的差分包D67-A、差分包D57-A、差分包D47-A,以及渠道B的差分包D67-B、差分包D57-B、差分包D47-B。这样针对一次安装包更新,服务器需要生成2*3*50M=300M的差分包,服务器需要300M的存储空间存储这些差分包。
若考虑三个渠道,回溯5个版本。服务器会生成渠道A的差分包D67-A、差分包D57-A、差分包D47-A、差分包D37-A、差分包D27-A、差分包D17-A,以及渠道B的差分包D67-B、差分包D57-B、差分包D47-B、差分包D37-B、差分包D27-B、差分包D17-B,以及渠道C的差分包D67-C、差分包D57-C、差分包D47-C、差分包D37-C、差分包D27-C、差分包D17-C。这样针对一次安装包更新,服务器需要生成5*5*50M=750M的差分包,服务器需要750M的存储空间存储这些差分包。
假设服务器中有100万个APP,每天有10%的APP更新,即开发人员会上传其中10%的APP的最新安装包,若考虑三个渠道,回溯5个版本,则每天需要生成大小为100*10000*10%*750=7.5*107M的差分包。可见,随着APP版本量及渠道的增加,差分包所占的存储空间急剧增加。
下面结合图2介绍相关技术提供的一种下载差分包的方法。
如图2所示,位于云侧的服务器可以包括资源服务模块、差分服务模块、分发服务模块,位于云侧的服务器可以连接数据库或者部署有数据库。图2中,通常,开发者将APP的最新安装包上传至服务器中的资源服务模块之后,运营人员可以审核开发者上传的APP的最新安装包。在审核通过之后,运营人员可以触发资源服务模块将APP的最新安装包的信息同步给差分服务模块,同时在数据库中保存最新安装包的信息。最新安装包的信息例如可以包括安装包的版本、大小等信息。差分服务模块可以根据APP的最新安装包的信息与存储在数据库中APP的历史版本信息,生成各个历史版本与最新版本间的差分包。在一些实施例中,差分服务还可以生成最新版本的全量包的校验码。服务器可以将生成的多个差分包存储在多个CDN服务器中。终端例如手机可以包括接收模块、查询模块、下载模块、合成模块、安装更新模块、以及增量计算模块。上述模块相互交互,使得手机可以从服务器中下载差分包,并使用差分包进行增量更新。
具体的,接收模块接收用户的第一操作,第一操作用于触发手机向服务器发送查询请求。该第一操作,例如可以是用户点击图1中第一界面上APP1的升级按钮。查询模块向服务器发送查询请求。响应于接收到查询请求,服务器中的分发服务模块可以获取查询请求所请求的差分包的下载地址及相关信息,并向手机发送该下载地址。响应于接收到该下载地址,下载模块可以向下载地址对应的第一CND服务器发送下载请求。响应于接收到下载请求,第一CND服务器向手机发送差分包。在差分包下载完成之后,下载模块可以触发增量计算模块计算差分包的大小,确定所下载的差分包的大小是否正确。在确定下载的差分包的大小是正确的之后,触发合成模块将差分包与手机中的当前版本的安装包合成,得到待升级版本的安装包。安装更新模块可以对待升级版本的安装包进行校验,并在校验合格之后,升级第一APP。在一些实施例中,若增量计算模块确定下载的差分包的大小不正确的之后,可以触发查询模块再次向服务器发送查询请求。
进一步的,服务器可以在接收到电子设备的查询请求之后,再去生成差分包,降低差分包的数量进而降低差分包所占的空间,如图3所示。图3示出的是服务器根据电子设备的查询请求生成差分包的过程。
在S301,手机向服务器发送查询请求。
在S302,响应于接收到该查询请求,服务器识别是否已生成查询请求所请求的差分包。
服务器识别生成有所请求的差分包,服务器可以执行图3中的S303。
在S303,服务器识别生成有所请求的差分包,服务器向手机发送差分包下载地址。
在S304,响应于接收到差分包下载地址,手机向该下载地址对应的CDN服务器发送下载请求。该下载请求请求下载存储在该CDN服务器中的第一APP的差分包。
在S305,CDN服务器向手机发送第一APP的差分包。
在S306,响应于接收到第一APP的差分包,手机升级第一APP。
服务器识别未生成有查询请求所请求的差分包,服务器可以执行图3中的S307。
在S307,服务器识别服务器没有生成有查询请求所请求的差分包,服务器向手机发送第一APP的待升级版本的全量包的下载地址。
服务器还会向手机发送全量包的大小,以及生成所请求的差分包的预计时间即差分总时间。
在S308,手机基于手机的网速,计算下载全量包的时间。若下载全量包的时间小于差分总时间,手机可以执行S309。若下载全量包的时间大于差分总时间,手机可以执行S3012。
在S309,若下载全量包的时间小于差分总时间,则手机可以向全量包下载地址对应的CDN服务器发送下载请求,请求下载第一APP的全量包。
在S3010(图中未示出),响应于接收到下载请求,CDN服务器向手机发送全量包。
在S3011(图中未示出),响应于接收到全量包,手机使用全量包升级第一APP。
在S3012,若下载全量包的时间大于差分总时间,则手机可以向服务器发送下载第一APP的差分包的下载请求。
在S3013,响应于该请求,服务器生成第一APP的差分包,并将差分包存储在CDN服务器上。
在S3014,服务器向手机发送该差分包下载地址。
在S3015,响应于接收到该下载地址,手机向CDN服务器发送下载请求,请求下载第一APP的差分包。
在S3016,响应于接收到下载请求,CDN服务器向手机发送第一APP的差分包。
在S3017,响应于接收到第一APP的差分包,手机使用第一APP的差分包升级第一APP。
具体的,手机可以将差分包与第一APP未升级前的原APK结合,得到全量包。手机对生成的全量包进行校验SHA256,若校验通过,则安装该全量包。
图3中,这两台CDN服务器可以是同一台CND服务器或者是两台不同的CDN服务器。
这样,服务器就可以按照用户升级需求生成差分包,降低差分包的数据。但是由于电子设备的用户众多,且用户的升级习惯及升级频率不同,电子设备中APP的当前版本众多,服务器还需要生成众多版本对应的差分包,存在差分包数量多,占用存储空间大的问题。
为此,本申请实施例提供一种差分包的下载方法及服务器。该方法应用于服务器。服务器可以根据用户的需求程度,生成需求程度高的差分包。
服务器在收到一个查询请求后,若服务器没有生成查询请求所请求的差分包,服务器会生成该查询请求对应的第一记录,服务器还会获取第一记录在第一时间段内(如第一时刻至当前时刻或者当前时刻之前的预设时长内)的生成数量。若第一记录在第一时间段的生成数量超过第一阈值,服务器生成第一记录所记录的第一差分包。第一记录在第一时间段内的生成数量,相当于第一记录所记录的查询请求在第一时间段内的请求数量。在请求数量超过第一阈值时,即用户需求量大时,才生成差分包。这样,能够根据用户的需求,生成用户需求量大的差分包,能够节省差分包的存储空间。
示例性的,如图4所示,在S3013响应于该请求,服务器生成第一APP的差分包,并将差分包存储在CDN服务器上,具体可以包括S401及S402。
在S401,响应于接收到该下载请求,服务器评估生成该下载请求所请求的差分包的必要性。
例如,服务器会生成该下载请求对应的第一记录,并获取第一记录在第一时间段内(例如第一时刻至当前时刻)的生成数量。若第一记录在第一时间段的生成数量超过第一阈值,服务器确定有必要生成该下载请求所请求的差分包。若第一记录在第一时间段的生成数量不超过第一阈值,服务器确定没有必要生成该下载请求所请求的差分包。
在S402,若服务器评估有必要生成该下载请求所请求的差分包,则服务器生成第一APP的差分包并将差分包存储在CDN服务器上。
下面结合附图,以电子设备是手机为例,介绍本申请实施例提供的一种差分包的下载方法。图5为本申请实施例提供的一种差分包的下载方法的流程示意图。
在S501,手机向服务器发送第一查询请求。
如图1所示,手机可以显示第一界面,接收用户对第一APP的更新按钮的点击操作。响应于接收到第一点击操作,手机向服务器发送第一查询请求。或者,手机可以自动向服务器发送第一查询请求,详细请参见前文。
第一查询请求用于请求获取第一APP的第一差分包。该第一查询请求可以包括第一APP的名称、以及第一APP的当前版本。在一些实施例中,第一查询请求还可以包括第一APP的待升级版本。在一些实施例中,第一查询请求若未携带第一APP的待升级版本,服务器默认将服务器中已有的第一APP的最新版本作为第一APP的待升级版本。
在一些实施例中,第一APP的当前版本及待升级版本中还可以包括渠道标识,渠道标识指示第一APP的差分包由该标识所标记的渠道下载得来。
在S502,响应于接收到第一查询请求,服务器基于第一APP的当前版本及待升级版本,查询是否已生成有第一APP的第一差分包。
第一差分包用于将第一APP由当前版本升级为待升级版本。
服务器可以将已生成的APP的差分包的相关信息存储在数据库中,服务器可以从数据库中查询是否已经生成第一APP的第一差分包。例如,数据库中可以存储有APP的最新版本信息、历史版本信息、已生成的差分包信息、已生成的差分包的下载地址、最新版本及历史版本的全量包即全量安装包的信息。
作为一个示例,数据库可以以如表1的方式存储上述信息。表1包括服务器已生成的差分包的差分标识。例如,差分标识D13指示该差分包为版本V1.0至版本V3.0间的差分包。差分标识D23-A指示该差分包为版本V2.0-A至版本V3.0-A间的差分包,其中,A为渠道标识,该渠道标识指示该差分包只能通过渠道A下载。
表1
服务器可以根据第一APP的名称在数据库中查找第一APP,之后,服务器可以根据第一APP的当前版本及待升级版本查询是否已生成有差分包。
服务器识别生成有所请求的差分包,服务器可以执行图5中S503。
在S503,若服务器已生成有第一查询请求所请求的第一差分包,服务器向手机指示第一差分包的第一下载地址。
若服务器识别已生成有第一差分包,服务器可以向手机指示第一差分包的第一下载地址。例如,服务器可以向手机发送第一差分包的第一下载地址。
第一下载地址可以包括其对应的CDN服务器的IP地址,第一差分包在该CDN服务器中的目录以及第一差分包的名称。第一下载地址例如可以是:192.168.0.5/data/share/APP1_1.0_3.0._B.diff。其中,192.168.0.5为CDN服务器的IP地址,data/share为该CDN服务器中第一差分包所在的目录,APP1_1.0_3.0._B.diff为第一差分包的名称。
例如,第一查询请求可以包括:第一APP的名称(APP1),当前版本(V1.0),由于第一查询请求未携带第一APP的待升级版本,服务器默认将APP1升级为最新版本,服务器基于APP1的当前版本(V1.0)及最新版本(V3.0),查询是否已生成差分包D13。服务器查询到已生成有差分包D13,服务器将差分包D13的下载地址(地址1)返回给手机。
在S504,响应于接收到第一下载地址,手机向第一下载地址对应的CDN服务器发送下载请求。
该下载请求请求获取存储在该CDN服务器中的第一差分包。
在S505,响应于接收到下载请求,第一下载地址对应的CDN服务器向手机发送第一差分包。
在S506,响应于接收到第一差分包,手机使用第一差分包升级第一APP。
服务器识别未生成有所请求的差分包,服务器可以执行图5中S507。
在S507,若服务器未生成有第一查询请求所请求的第一差分包,服务器根据第一查询请求生成第一记录。
第一记录用于记录第一查询请求。具体的,第一记录可以记录第一查询请求所请求的第一差分包的信息。例如,第一记录可以包括:第一APP的名称,第一APP的当前版本、第一APP的待升级版本。又例如,第一记录可以包括:第一APP的名称、第一差分包的差分标识。其中,差分包标识例如可以是D13,该标识指示该所标记的差分包由版本V1.0及版本V3.0生成,该差分包包括版本V1.0与版本V3.0之间的差异数据。
第一记录还可以包括第一标识,第一标识用于指示服务器未生成有第一记录所记录的第一差分包。例如,第一标识可以是N。如前文中的示例,第一记录例如可以是:APP2、当前版本V1.0、待升级版本V4.0、N。
示例性的,第一查询请求可以包括:第一APP的名称(APP2)、当前版本(V3.0),由于第一查询请求未携带第一APP的待升级版本,服务器默认最新版本(V5.0)为待升级版本。服务器查询到未生成有差分包D35,服务器可以生成第一记录,该第一记录例如可以是:APP2,当前版本V3.0,待升级版本V5.0,N。
又例如,第一查询请求可以包括:第一APP的名称(APP1)、当前版本(V1.0-A),由于第一查询请求未携带第一APP的待升级版本,服务器默认最新版本为待升级版本。服务器查询到未生成有差分包D13-A(包括A渠道信息),服务器可以生成第一记录,该第一记录例如可以是:APP1、差分标识D13-A,N。
服务器可以保存第一记录。作为一个示例,服务器可以使用数据表保存第一记录。例如,服务器可以以表2的方式存储第一记录。
服务器不仅会存储生成的第一记录,还会存储一段时间内生成第一记录的数量,例如,服务器从第一时刻开始,在保存第一记录时同时保存由第一时刻至当前保存时刻生成第一记录的数量。其中,一段时间内第一记录的生成数量即为一段时间内生成的第一记录的数量。
例如,第一时刻可以是凌晨00:00,服务器在上午08:00初次接收到第一查询请求:第一APP的名称(APP2)、当前版本(V3.0),服务器生成第一记录:APP2,当前版本V3.0,待升级版本V5.0,N。服务器保存该第一记录,并记录生成该第一记录的数量为1。服务器在上午09:00再次收到该第一查询请求,服务器再次生成第一请求,服务器在已保存有的多条第一记录中查询到已经保存有该第一记录,服务器读取生成该第一记录的数量。服务器将生成数量加一,得到新的生成数量,并保存新的生成数量。这样,服务器在接收到一个第一查询请求之后,就可以生成与该第一查询请求对应的第一记录,并在保存该第一记录时,更新该第一记录的生成数量。由于生成第一记录的数量可以相当于第一查询请求的请求数量,如此,服务器可以记录不同的第一查询请求,以及同一个第一查询请求的请求数量。
表2
在S508,服务器获取第一时间段内生成的第一记录的数量。
其中,上述第一时间段可以包括当前时刻前的预设时长。例如,假设预设时长为12小时,当前时刻为19:05;那么上述第一时间段则可以为由7:05-19:05这段时间。
或者,第一时间段可以为由第一时刻至当前时刻这段时间。例如,第一时刻可以是凌晨00:00,当前时刻是12:00,则服务器可以获取凌晨00:00-12:00时间段内,服务器生成第一记录的数量。又例如,第一时刻是3月1号中午12:00,当前时刻可以是3月2号上午9:00,则服务器可以获取3月1号中午12:00-3月2号上午9:00时间段内,服务器生成第一记录的数量。一般为了及时满足用户的下载需求,第一时刻与当前时刻间的时长一般可以是24个小时、或者12个小时、或者8个小时、或者4个小时。
在S509,服务器判断第一记录的数量是否大于第一阈值。
其中,第一记录的数量相当于在上述第一时间段内请求生成第一差分包的用户数量。在第一时间段内生成的第一记录的数量大于第一阈值,表示在该第一时间段内请求生成第一差分包的用户较多。也表明大量用户存在使用上述第一差分包更新第一APP的需求。在这种情况下,服务器可以生成第一记录所记录的第一差分包。也就是说,在S509之后,若第一记录的数量大于第一阈值,则服务器可以执行S5010。
若第一记录的数量小于或等于第一阈值,则表示该第一时间段内请求生成第一差分包的用户不多,也表明只有少量用户存在使用上述第一差分包更新第一APP的需求。在这种情况下,服务器不需要生成第一差分包。也就是说,在S509之后,若第一记录的数量小于或等于第一阈值,则服务器可以执行S5015。在一些实施例中,若第一记录的数量大于或等于第一阈值,服务器可以生成第一差分包。若第一记录的数量小于第一阈值,服务器不生成第一差分包。
在S5010,若第一记录的数量大于第一阈值,服务器生成第一记录所记录的第一差分包,并在第二下载地址存储第一差分包。
第一时间段内服务器生成第一记录的数量可以反映服务器接收第一记录所记录的第一查询请求的数量,即可以反映手机向服务器发送该第一查询请求的数量,也能反映出用户对该第一查询请求所请求的第一差分包的需求程度。服务器可以获取一段时间内生成第一记录的数量,若生成该第一记录的数量高,则服务器生成该第一记录所记录的第一差分包。
第一时间段内服务器生成第一记录的数量超过第一阈值,说明服务器接收到请求获取第一记录所记录的第一差分包的第一查询请求的数量超过第一阈值。也能说明用户对第一APP的第一差分包的需求量很高,有必要生成该第一差分包。例如,第一阈值为3000次/天,表2中第一行中的第一记录1,当天生成数量为5000次,超过第一阈值。说明服务器接收到5000第一查询请求,这5000次第一查询请求都请求将APP1由V2.0升级为V3.0。由于该第一记录当天生成数量超过第一阈值,服务器立马会生成差分包D23,满足用户较高的升级需求。同时,下次在接收到第一查询请求,若请求获取APP1的差分包D23时,服务器可以直接返回D23的下载地址。在生成第一记录1所记录的第一APP的第一差分包之后,服务器可以第一记录1中的第一标识N,更新为第二标识Y。第二标识Y指示服务器已生成有所标记的第一记录1所记录的第一差分包。
可选的,服务器在生成第一差分包之后,可以向手机指示第一差分包的第二下载地址,手机可以通过第二下载地址下载第一差分包,并使用第一差分包升级第一APP。如,图5中的S5011-S5014所示。
在S5011,服务器向手机发送该第一差分包的第二下载地址。
第二下载地址与第一下载地址类似,此处暂不赘述。
在S5012,响应于接收到第一下载地址,手机向第二下载地址对应的CDN服务器发送下载请求。
该下载请求请求获取存储在该CDN服务器上的第一差分包。
在S5013,响应于接收到下载请求,第二下载地址对应的CDN服务器向手机发送第一差分包。
在S5014,响应于接收到第一差分包,手机使用第一差分包升级第一APP。
可选的,在S5015,若服务器判断第一记录的数量小于第一阈值,服务器不会生成第一记录所记录的第一差分包,但是,服务器可以向手机指示全量包的第三下载地址。其中,第三下载地址为第一查询请求所请求的第一APP的待升级版本的安装包的存储地址。手机可以通第三下载地址下载第一APP的全量包,使用第一APP的全量包升级第一APP。如,图5中的S5015-S5018所示。
在S5015,若第一记录的数量小于第一阈值,服务器指示手机第一APP的全量包的第三下载地址。
在S5016,响应于接收到第三下载地址,手机向第三下载地址对应的CDN服务器发送下载请求。
该下载请求请求并获取存储在该CDN服务器上的第一APP的待升级版本的全量包。
在S5017,响应于接收到下载请求,第三下载地址对应的CDN服务器向手机发送第一APP的待升级版本的全量包。
在S5018,响应于接收到第一APP的待升级版本的全量包,手机使用全量包升级第一APP。
若第一时间段内服务器生成第一记录的数量未超过第一阈值,说明第一时间段内用户对该第一记录所记录的第一差分包的需求量不是很高,为了节省存储空间,可以先不生成这类第一记录的差分包。当接收到这类第一记录对应的第一查询请求时,可以先返回全量包。例如,表2中的第一记录2,服务器生成该第一记录2的数量不超过第一阈值,说明该第一记录2记录的第一APP的第一差分包的需求量不高,服务器可以不用立马就生成该第一差分包。
第三下载地址可以包括其对应的CDN服务器的IP地址,待升级版本的全量包在该CDN服务器中的目录以及待升级版本的全量包的名称。第三下载地址例如可以是:192.168.0.5/data/share/APP1_1.0_.apk。其中,192.168.0.5为CDN服务器的IP地址,data/share为该CDN服务器中待升级版本的全量包所在的目录,APP1_1.0_.apk为待升级版本的全量包的名称。
可选的,若服务器未生成第一差分包,服务器也可以向手机指示全量包的第三下载地址。其中,第三下载地址为第一查询请求所请求的第一APP的待升级版本的安装包的存储地址。手机可以通第三下载地址下载第一APP的全量包,使用第一APP的全量包升级第一APP。之后,服务器可以在预设时刻获取预设时间段内生成的第一记录的数量,并在第一记录的数量大于第一阈值时,生成第一记录所记录的第一差分包。服务器接收到手机二的第二查询请求,该第二查询请求请求获取第一APP的第一差分包。由于服务器已经生成有第一APP的第一差分包,服务可以直接向手机二指示第一差分包的第二下载地址。例如,服务器向手机二发送第二下载地址,手机二可以通过第二下载地址下载第一差分包,之后,手机二可以使用第一差分包升级第一APP。
综上,服务器可以在存储第一记录时,读取由第一时刻至当前时刻生成第一记录的数量,并自动生成数量大于第一阈值的第一记录所记录的第一差分包。例如,服务器在存储第一记录时,首先会在如表2所示的数据表中查询是否已存储有该第一记录。若数据表中没有存储该第一记录,服务器将该第一记录存储在数据表中,并将数据表中该第一记录的生成数量的值设置为1。若数据表已存储中该第一记录,服务器可以读取生成该第一记录的数量,并将该数量与第一阈值作比较。或者,服务器可以将读取到的生成第一记录的数量加一,得到新的数量,再将新的数量与第一阈值做比较。
服务器不仅可以在存储第一记录时,读取第一时刻至当前时刻生成第一记录的数量。服务器还可以在固定的时刻读取生成第一记录的数量。例如,以第一时刻是每天凌晨00:00点为例,服务器可以在每天中午12:00点,读取由每天凌晨00:00点-每天中午12:00点,生成第一记录的数量。服务器也可以在每天晚上23:00点,读取由每天凌晨00:00点-晚上23:00点生成第一记录的数量。或者,服务器可以每隔固定时长,读取生成第一记录的数量。例如,服务器可以每隔一个小时,查询一次由每天凌晨00:00点至当前时刻生成第一记录的数量。
如此,在第一时刻至第二时刻的第一时间段内,服务器在每一次接收到第一查询请求之后,若服务器没有存储有第一查询请求所请求的第一差分包,服务器都可以生成第一记录,并在保存该第一记录的时候获取由第一时刻至当前时刻,生成第一记录的数量,并在识别到数量大于第一阈值时,生成第一记录所记录的第一差分包。其中,第二时刻为晚于第一时刻的时刻,第一时刻至第二时刻构成一个第一时间段。当前时刻是第一时间段内,任意一个时刻。例如,第一时刻是早上06:00点,第二时刻是下午24:00,早上06:00点-下午24:00点为第一时间段。在第一时间段内,服务器都可以生成第一记录,并在保存该第一记录的时获取第一时刻至当前时刻第一记录的生成数量。或者,服务器可以在这一时间段内任意预设时刻,获取第一时刻至当前时刻第一记录的生成数量。
也就是说,在第一时间段内,服务器接收手机的第一查询请求,可以触发服务器执行如图5所示的方法。如此,服务器在接收到第一查询请求之后,就可以获取该请求的数量,并在请求数量满足预设条件时,及时生成第一差分包,及时满足用户的需求。
或者,服务器还可以在接收到手机的第一查询请求之后,若服务器未生成有第一记录所请求的第一差分包时,服务器可以只记录该第一查询请求。之后,在第一时间内的预设时刻,获取预设时间段内生成第一记录的数量,进而评估是否生成第一记录所记录的第一差分包。例如第一时间段凌晨00:00点-晚上23:00点,服务器可以在这一时间段内任意预设时刻,获取第一记录至当前预设时刻的生成数量,并评估是否生成第一记录所记录的第一差分包。
或者,服务器可以第一时间段外的预设时刻,基于第一时刻至第二时刻第一记录的生成数量评估是否生成第一记录所记录的第一差分包。例如第一时间段凌晨00:00点-晚上23:00点(预设时间段),服务器可以第二天早上08:00点,获取第一记录至当前时刻的生成数量,并评估是否生成第一记录所记录的第一差分包。
可见,本申请实施例提供的一种差分包的下载方法,服务器接收手机的第一查询请求,若服务器没有生成有该第一查询请求所请求的第一差分包,服务器可以生成第一记录,第一记录用于记录该第一查询请求。服务器也可以读取第一时间段内(例如,第一时刻至当前时刻)生成第一记录的数量,当第一时间段内生成第一记录的数量,超过第一阈值时,服务器生成第一记录所记录的第一差分包。第一记录在第一时间段内的生成数量,相当于第一记录所记录的第一查询请求在第一时间段内的请求数量。在请求数量超过第一阈值时,即用户需求量大时,才生成差分包。这样,能够根据用户的需求,生成需求量大的差分包,能够节省差分包的存储空间。
服务器在生成第一记录所记录的第一差分包之后,服务器还可以将第一记录中的第一标识由N改为第二标识Y。第二标识Y表示服务器已生成有第一记录所记录的第一差分包。示例性的,更新后的第一记录可以如表3所示。
表3
服务器可以针对多个第一时间段内第一记录的生成数量,执行如图5所示的方法,按需生成每个第一时间段内需求程度高的第一记录所记录第一差分包。其中,多个第一时间段与第一时间段的时长可以是相同的。示例性的,早上06:00点-下午24:00点为第一时间段,第二天早上06:00点-下午24:00点为第二个第一时间段、第三天天早上06:00点-下午24:00点为第三个第一时间段。或者,早上06:00点-中午12:00点为第一时间段、中午12:00-下午18:00点为第二个第一时间段、下午18:00-凌晨24:00点为第三个第一时间段等。
服务器针对具体一个第一时间段内第一记录的生成数量,执行如图5所示的方法时,若第一时间段内生成第一记录的数量小于第一阈值,服务器可以根据多个第一时间段内每个第一时间段生成第一记录的数量,来确定是否生成该第一记录所记录的第一差分包。例如,服务器识别到第一记录在第五天早上06:00点-下午24:00点的第一时间段内的生成数量小于第一阈值,之后,服务器可以获取第一天早上06:00点-下午24:00点、第二天早上06:00点-下午24:00点、第三天早上06:00点-下午24:00点、第四天早上06:00点-下午24:00点、这四个第一时间段内,生成第一记录数量,基于生成第一记录的数量,进一步确定是否要生成第一记录所记录的第一差分包。
也就是说,若在第一时间段内,第一记录的生成数量未超过第一阈值,服务器可以进一步评估生成该第一记录对应的差分包的必要性。具体的,服务器可获取M个第一时间段内第一记录的生成数量,若M个第一时间段内中至少有m个第一时间段内第一记录的生成数量均大于第二阈值,服务器生成该第一记录所记录的第一差分包。第一阈值大于第二阈值,例如,第一阈值为5000次/天,第二阈值为1000次/天。其中,M、m为大于1的整数。例如M=5,m=3,则5个第一时间段内中至少有3个第一时间段内第一记录的是生成数量大于1000次/天时,服务器才生成该第一记录所记录的第一差分包。
第一时间段内第一记录的生成数量超过第一阈值,说明生成第一记录所记录第一差分包的需求很大,需要尽快满足用户的需求尽快生成第一差分包。第一时间段内第一记录的生成数量未超过第一阈值,说明短时间内生成第一记录所记录的第一差分包的需求不大。可以根据第一记录的历史生成数量,进一步评估生成该第一记录所记录的第一差分包的必要性。
服务器可以将每个第一时间段内的生成数量小于第一阈值的第一记录,加入待评估记录集中。服务器可以使用数据表存储这些第一记录,该数据表例如可以如表4所示。表4保存的是多个第一时间段内,生成数量小于第一阈值的第一记录。例如,表4中第四列保存的是在day1,由服务器生成的生成数量小于第一阈值的第一记录。具体的包括第一记录1、第一记录2、第一记录3。
表4
针对第一时间段生成数量小于第一阈值的第一记录,服务器可以向后统计在一个周期内,该第一记录在一个周期内的历史生成数量,根据历史生成数量确定是否生成该第二记录所记录的第一差分包。示例性的,如图6所示,图6为本申请实施例提供的另一种差分包的下载方法的流程示意图。
在S601,若第一记录的生成数量小于第一阈值,服务器读获取M个第一时间段中每个第一时间段内生成的第一记录的数量。
M个第一时间段构成一个第一周期。例如,第一时间段为一天,第一周期可以是5天或10天。第一时间段为一周,第一周期可以是2周或3周或5周等。第一周期可以包括当前第一时间段及当前第一时间段往前的M-1个第一时间段。或者,第一周期可包括当前第一时间段往前的M个第一时间段。
以第一时间段是一天为例,假设今天为25号,第一周期可以包括21号-25号,或者第一周期可包括20号-24号。
在S602,若M个第一时间段内至少有m个第一时间段内生成的第一记录的数量均大于第二阈值,服务器则生成第一记录所记录的第一差分包,并在第四下载地址存储该第一差分包。
服务器可以先读取M个第一时间段内中每个第一时间段内生成第一记录的数量,以第一周期包括当天以及当天之前的4天,总共5天为例。针对第一记录1,服务器可读取21号-24号生成第一记录1的数量。例如,生成第一记录1的数量依次为1000次/天、0次/天、2000次/天、3500次/天。服务器可以根据21号-24号、以当前第一时间段(25号)的生成第一记录的数量确定是否生成第一记录所记录的第一差分包。
表5
具体的,服务器可以依次将每个第一时间段内生成第一记录的数量与第二阈值做比较,并记录生成第一记录的数量大于第二阈值的第一时间段的数量。如表5中,第一周期内,生成第一记录1的数量大于第二阈值的第一时间段的数量是4。
服务器可以根据第一周期内,生成第一记录的数量大于第二阈值的第一时间段的数量判断是否生成对应的差分包。具体的,第一周期内,生成第一记录的数量大于第二阈值的第一时间段的数量大于m,服务器可以生成第一记录所记录的第一差分包。第一周期内,生成第一记录的数量大于第二阈值的第一时间段的数量小于m,不生成第一记录所记录的第一差分包。
例如,m=4。服务器可以生成表5中的第二记录1、第二记录2及第二记录4所记录的第一差分包。由于在第一周期内,生成第一记录3的数量大于第二阈值的第一时间段的数量为1,小于4,服务器可以先不生成APP5的差分包D35。在第一周期内,生成第一记录5的数量大于第二阈值的第一时间段的数量为2,小于4,服务器可先不生成APP7的差分包D26。
服务器还可以计算第一记录的第一置信度。第一置信度可以为第一周期中生成第一记录的数量大于第二阈值的第一时间段的数量除以第一周期所包括的第一时间段的数量。
示例性的,第一置信度=第一周期内生成的第一记录的数量大于第二阈值的天数/第一周期所包括的总天数。
第一记录的第一置信度大于第一预设置信度,则生成该第一记录所记录的第一差分包。第一记录的第一置信度小于第一预设置信度,则不生成该第一记录所记录的第一差分包。如表5中,第一记录1-第一记录5的第一置信度依次为4/5、4/5、3/5、5/5、2/5。第一预设置信度可以是4/5。如此,服务器可以生成第一记录1、第一记录2、第一记录4所记录的第一差分包,不生成第一记录3、第一记录5所记录的第一差分包。
在一些实施例中,若M个第一时间段内生成第一记录的数量大于第二阈值的第一时间段段的数量小于m,服务器可以先不生成该第一记录所记录的第一差分包。服务器可以向手机指示第一APP待升级版本的全量包的下载地址。手机可以通过该下载地址下载第一APP待升级版本的全量包,并使用全量包升级第一APP。
在S603,服务器向手机发送第四下载地址。
在S604,响应于接收到第四下载地址,手机向与第四下载地址对应的CDN服务器发送下载请求。
在S605,响应于接收到该下载请求,与第四下载地址对应的CDN服务器向手机发送第一差分包。
在S606,响应于接收到第一差分包,手机使用第一差分包升级第一APP。
也就是说,服务器接收手机的第一查询请求,可以触发服务器执行如图5所示的方法。如此,服务器在接收到第一查询请求之后,就可以获取该请求的数量,并在请求数量小于第一阈值时,进一步根据第一周期内第一记录的生成数量,生成满足预设条件的第一记录。如此,能够及时满足用户的需求。
或者,服务器还可以在接收到手机的第一查询请求之后,若服务器未生成有第一记录所请求的第一差分包时,服务器可以只记录该第一查询请求。之后,服务器可以在固定时刻,基于第一时刻至该固定时刻(预设时间段)生成第一记录的数量评估是否生成第一记录所记录的第一差分包,并在第一记录的生成数量小于第一阈值时,进一步根据第一周期内生成第一记录的数量,生成满足预设条件的第一记录。
或者,服务器还可以在预设时刻,针对预设时间段内生成数量小于第一阈值的第一记录,获取第一周期内第一记录的生成数量,并根据生成数量生成满足预设条件的第一记录。该预设时刻可以是当前第一时间段内的任意时刻,或者当前第一时间段外的任意时刻。
示例性的,如图7所示,服务器可以在当天,将当天生成数量大于第一阈值的第一记录标记为待生成差分包的记录,并将该第一记录保存在待生成记录集中。针对当天生成数量小于第一阈值的第一记录,将该第一记录加入待评估记录集中。进一步的,针对待评估记录集中的第一记录,获取M天该第一记录的生成数量。若M天中至少有m天第一记录的生成数量大于第二阈值,则将该第一记录标记为待生成差分包的记录,并将该第一记录保存在待生成记录集中。之后,服务器接收手机三的第三查询请求,若第三查询请求请求获取待生成记录集中第一记录所记录的第一差分包,服务器就可以生成该第一记录所记录的第一差分包,并将第一差分包存储在第二下载地址。之后,服务器可以向手机三发送第二下载地址。手机三可以通过第二下载地址下载第一差分包,并升级第一APP。
前文介绍了服务器根据第一查询请求对应的第一记录生成第一差分包的方法,进一步的,服务器还可以根据第一查询请求删除使用频率较低的第一差分包,进一步节省存储空间。若服务器生成有第一APP的第一差分包,服务器也可以记录该第一查询请求,根据该第一查询请求生成第二记录。服务器可以根据第二记录确定是否删除该第一查询请求对应的第一差分包。具体如图8所示,在S502之后,服务器可以执行S801。
在S801,若服务器已生成第一查询请求所请求的第一差分包,服务器生成第二记录。
若服务器已生成有第一查询请求所请求的差分包,服务器可以生成第二记录。第二记录用于记录第一查询请求,具体的,第二记录可以记录第一查询请求所请求的第一APP的第一差分包信息。例如,第二记录可以包括:第一APP的名称,第一APP的当前版本、第一APP的待升级版本。又例如,第二记录可以包括:第一APP的名称、第一差分包的差分标识。
第二记录还可以包括第二标识,第二标识用于指示服务器生成有第二记录所记录的第一差分包。例如,第二记录例如可以是:APP2、当前版本V2.0、待升级版本V5.0、Y。或者,第二记录可以是APP2、D25、Y。
在S802,服务器获取的N个第一时间段内每个第一时间段内生成的第二记录的数量。
N个第一时间段构成一个第二周期。例如,第一时间段为一天,第二周期可以是5天或10天。第一时间段为一周,第二周期可以是2周或3周或5周等。第二周期可以包括当前第一时间段及当前第一时间段往前的N-1个第一时间段。或者,第二周期可包括当前第一时间段往前的N个第一时间段。
以第一时间段是一天为例,假设今天为25号,第一周期可以包括21号-25号,或者第一周期可包括20号-24号。
服务器可以保存第二周期内N个第一时间段内生成的第二记录,例如服务器可以使用数据表保存第二记录。作为一个示例,服务器可以以表6的方式存储第二记录。服务器不仅会存储生成的第二记录,还会记录一段时间内服务器生成的多条第二记录中每条第二记录的生成数量。
表6
服务器可以先读取N个第一时间段内中每个第一时间段内生成第二记录的数量,以第一周期包括5天为例,针对第一记录1,服务器可读取1号-4号生成的第一记录1的数量。例如,第一记录1的生成数量依次为1500次/天、500次/天、800次/天。服务器可以根据1号-4号、以当前第一时间段(5号)的第二记录的生成数量确定是否删除第二记录所记录的第一差分包。
具体的,服务器可以依次将每个第一时间段内第二记录的生成数量与第三阈值做比较,并记录第一记录的生成数量小于第三阈值的第一时间段的数量。其中,第三阈值例如可以是300次/天
在S803,若N个第一时间段内至少有n个第一时间段内第二记录的数量均小于第三阈值,则删除第二记录所记录的第一差分包。
服务器可以根据第二周期内,第二记录的生成数量小于第三阈值的第一时间段的数量判断是否删除对应的差分包。第一周期内,第二记录的生成数量小于第三阈值的第一时间段的数量大于n,服务器可以删除第二记录所记录的第一差分包。第一周期内,第二记录的生成数量小于第三阈值的第一时间段的数量小于n,不删除第二记录所记录的第一差分包。
例如n=3,表6中,由于在第二周期内,第二记录1的生成数量小于第三阈值的第一时间段的数量为0,小于3,服务器可先不删除APP1的差分包D12。由于在第二周期内,第二记录7的生成数量小于第三阈值的第一时间段的数量为5,大于3,服务器删除APP7的差分包D26。
服务器可以计算第二记录的第二置信度。第二置信度可以为第二周期中第二记录的生成数量小于第三阈值的第一时间段的数量除以第二周期所包括的第一时间段的数量。
示例性的,第二置信度=第二周期内,第二记录的生成数量小于第三阈值的天数/第二周期内的总天数。如表6中,第二记录1-第二记录5的第二置信度依次为:0、3/5、2/5、0、4/5。
之后,服务器可以将第一周期内第二记录的第二置信度与预设第二置信度做比较,预设第二置信度可以是3/5。
若第一周期内第二记录的置信度小于预设第二置信度,服务器不删除该第二记录所记录的差分包。如服务器表6中不删除第二记录1、第二记录3、第二记录4所记录的差分包。若第一周期内第二记录的置信度大于预设第二置信度,服务器删除该第二记录所记录的差分包。如服务器删除第二记录2、第二记录5所记录的差分包。
进一步的,服务器可以根据服务器记录的查询记录(包括第一记录、第二记录、)以及用户下载差分包的统计数据,计算出前文中的第一阈值、第二阈值、以及第一预设置信度。
示例性的,可以将服务器处理查询请求的过程看做二分类模型,可以采用混淆矩阵计算,第一阈值、第二阈值、以及第一预设置信度。例如可以获取用户的查询请求,并在一段时间之后,获取用户下载差分包的数据。
例如,服务器接收到100万的查询请求中,由60万个下载数据下载了查询请求请求获取的差分包,且服务器生成有查询请求请求获取的差分包,这类查询请求可以为正例(TP)。TP可以表示服务器评估需要生成查询请求对应的差分包,服务器生成了这些差分包且用户下载了该差分包。
服务器已生成有其中10万的查询请求请求获取的差分包,服务器将差分包的下载地址返回给手机之后,用户没有通过下载地址下载了差分包,这类查询请求可以为假正例(FP)。FP可以表示服务器评估需要生成查询请求对应的差分包,服务器生成了这些差分包但是用户并没有下载这些差分包。
服务器未生成有其中15万的查询请求请求获取的差分包,用户也没有下载该差分包,这类查询请求可以为负例(TN)。TN可以表示服务器评估不需要生成查询请求对应的差分包,服务没有生成这些差分包且用户没有下载了该差分包。
有15万载数据下载了查询请求请求获取的差分包,但是服务器未生成有查询请求请求获取的差分包,这类查询请求可以为假负例(FN)。FN可以表示服务器评估不需要生成查询请求对应的差分包,但用户却下载了该差分包。例如,服务器第一天接收到查询请求,服务器评估不需要生成其对应的差分包。在评估一段时间后,服务器最终生成了该查询请求对应的差分包,因此,会有假负例存在的情况。
服务器基于一下公式分别计算第一阈值、第二阈值、以及第一预设置信度。
第一阈值=100*(TP/(TP+FN)=100*60/(60+15)=85.7万。
第二阈值=100*(1-TP/(TP+FN))=100*(1-60/(60+15))=14.3万。
第一预设置信度=TP/(TP+FP)=60/(60+15)=80%。
服务器可以包括分发服务模块、差分服务模块、评估模块。下面结合图9对各个模块进行介绍。
在S901,手机向服务器发送第一查询请求。
在S902,响应于手机发送的第一查询请求的触发,分发服务模块可以查询服务器是否已经生成有第一查询请求所请求的第一APP的第一差分包
在S903,若查询到服务器已生成有第一APP的第一差分包,分发服务模块可以触发服务器向手机发送第一差分包的下载地址。
在S904,若查询到服务器未生成有第一APP的第一差分包,分发服务模块可以触发服务器向手机发送第一APP的全量包的下载地址。同时,服务模块可以触发评估模块,评估是否有必要生成该第一查询请求所请求的第一差分包。
在S905,评估模块首先可以生成第一查询请求对应的第一记录并保存。
在S906,评估模块获取第一时间段内生成第一记录的数量。
在S907,若评估模块识别到该生成第一记录的数量大于第一阈值,评估模块将该第一记录保存在待生成记录集中。例如,评估模块可以将该第一记录标记为待生成差分包的记录。待生成差分包的记录构成一个待生成记录集。
在S908,差分服务模块从待生成记录集中获取第一记录,并生成第一记录所记录的第一差分包。例如,差分服务模块可以定期从待生成记录集中获取第一记录,并生成该第一记录所记录的第一差分包。又例如,分发服务模块可以响应于手机发送的第三查询请求的触发,若第三查询请求请求获取待生成记录集中第一记录所记录的第一差分包,分发服务模块可以触发差分服务模块从待生成记录集中获取第一记录,并生成第一记录所记录的第一差分包。可选的,差分服务模块在生成第一差分包之后,可以将第一差分包存储在第二下载地址。
在S909,若评估模块识别到该第一记录的生成数量小于第一阈值,评估模块将该第一记录保存待评估记录集中。
评估模块可以根据一个时间周期内该第一记录的生成数量,以进一步评估是否生成该第一记录所记录的第一差分包。也就是说,响应于接收到手机发送的查询请求,服务器中的上述模块可以相互交互,完成S901-S909所示的方法流程。
评估模块可以在固定的时刻,定期评估待评估记录集中的第一记录,以确定是否生成第一记录所记录的第一差分包。
在S9010,针对待评估记录集中的第一记录,评估模块获取M个第一时间段内各个第一时间段生成第一记录的数量。
在S9011,若M个第一时间段内至少有m个第一时间段内所述第一记录的数量均大于第二阈值,评估模块将该第一记录保存在待生成记录集中。
在S9012,差分服务模块可以定期从待生成记录集中获取第一记录,并生成第一记录所记录的第一差分包。
本申请实施例提供的方法可以应用于具备数据处理能力的第一电子设备。上述第一电子可以是位于云侧的服务器。该服务器可以是数据采集服务器、大数据平台或数据处理服务器,也可以是集成有数据采集服务器、大数据平台或数据处理服务器的设备。下面对服务器进行具体说明。可以理解的是,本申请实施例示意的结构并不构成对服务器的具体限定。在另一些实施例中,服务器可以包括比图10中更多或更少的部件,或者组合某些部件,或者拆分某些部件,或者不同的部件布置。图10所示的部件可以以硬件,软件或软件和硬件的组合实现。
如图10所示,服务器1000可以包括处理器1001、存储器1002及通信模块1003。处理器1001可用于读取和执行计算机可读指令。具体地,处理器1001可以包括控制器、运算器和寄存器。其中,控制器主要负责指令译码,并为指令对应的操作发出控制信号。运算器主要负责保存指令执行过程中临时存放的寄存器操作数和中间操作结果等。寄存器是有限存贮容量的高速存贮部件,可用来暂存指令、数据和地址。
具体实现中,处理器1001的硬件架构可以是专用集成电路(applicationspecific Integrated circuit,ASIC)架构、无内锁流水线微处理器 (micro processorwithout interlocked piped stages, MIPS)架构、ARM(advanced risc machines)架构或者网络处理器(net processor,NP)架构等等。
存储器1002与处理器1001耦合,用于存储各种软件程序和/或多组指令。本申请实施例中,电子设备的数据存储方法除了可以集成在服务器的一个处理器中实现以外,也可以以程序代码的形式存储于服务器的存储器中,由服务器的一个处理器调用服务器的存储器中存储的代码,执行以上方法。
具体实现中,存储器1002可包括高速随机存取的存储器,并且也可包括非易失性存储器,例如一个或多个磁盘存储设备、闪存设备或其他非易失性固态存储设备。存储器1002可以存储操作系统,例如uCOS,VxWorks、RTLinux等嵌入式操作系统。
通信模块1003可用于通过网络建立服务器与其它通信终端之间的通信连接,并用于通过网络收发数据。例如,通信模块1003可以接收手机发送的查询请求。通信模块1003还可以向手机发送差分包或全量包的下载地址。
本申请实施例提供一种服务器,该服务器包括:存储器、通信模块、一个或多个处理器。该存储器用于存储计算机程序代码。通信模块与处理器耦合,用于与电子设备交互。该计算机程序代码包括计算机指令。当处理器执行计算机指令时,服务器可执行上述方法实施例中手机执行的各个功能或者步骤。该服务器的结构可以参考图10所示的服务器1000的结构。
本申请实施例还提供一种计算机存储介质,该计算机存储介质包括计算机指令,当计算机指令在上述服务器(如图10所示的服务器1000)上运行时,使得该服务器执行上述方法实施例中的各个功能或者步骤。
本申请实施例还提供一种计算机程序产品,当计算机程序产品在计算机上运行时,使得计算机执行上述方法实施例中的各个功能或者步骤。
本申请实施例还提供一种芯片系统,该芯片系统包括至少一个处理器和至少一个接口电路。处理器和接口电路可通过线路互联。例如,接口电路可用于从其它装置(例如电子设备的存储器)接收信号。又例如,接口电路可用于向其它装置(例如处理器)发送信号。示例性的,接口电路可读取存储器中存储的指令,并将该指令发送给处理器。当指令被处理器执行时,可使得电子设备执行上述实施例中的各个步骤。当然,该芯片系统还可以包含其他分立器件,本申请实施例对此不作具体限定。
通过以上实施方式的描述,所属领域的技术人员可以清楚地了解到,为描述的方便和简洁,仅以上述各功能模块的划分进行举例说明,实际应用中,可以根据需要而将上述功能分配由不同的功能模块完成,即将装置的内部结构划分成不同的功能模块,以完成以上描述的全部或者部分功能。
在本申请所提供的几个实施例中,应该理解到,所揭露的装置和方法,可以通过其它的方式实现。例如,以上所描述的装置实施例仅仅是示意性的,例如,模块或单元的划分,仅仅为一种逻辑功能划分,实际实现时可以有另外的划分方式,例如多个单元或组件可以结合或者可以集成到另一个装置,或一些特征可以忽略,或不执行。另一点,所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口,装置或单元的间接耦合或通信连接,可以是电性,机械或其它的形式。
作为分离部件说明的单元可以是或者也可以不是物理上分开的,作为单元显示的部件可以是一个物理单元或多个物理单元,即可以位于一个地方,或者也可以分布到多个不同地方。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。
另外,在本申请各个实施例中的各功能单元可以集成在一个处理单元中,也可以是各个单元单独物理存在,也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现,也可以采用软件功能单元的形式实现。
集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时,可以存储在一个可读取存储介质中。基于这样的理解,本申请实施例的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出来,该软件产品存储在一个存储介质中,包括若干指令用以使得一个设备(可以是单片机,芯片等)或处理器(processor)执行本申请各个实施例方法的全部或部分步骤。而前述的存储介质包括:U盘、移动硬盘、只读存储器(read only memory,ROM)、随机存取存储器(random access memory,RAM)、磁碟或者光盘等各种可以存储程序代码的介质。
以上内容,仅为本申请的具体实施方式,但本申请的保护范围并不局限于此,任何在本申请揭露的技术范围内的变化或替换,都应涵盖在本申请的保护范围之内。因此,本申请的保护范围应以权利要求的保护范围为准。

Claims (10)

1.一种差分包的下载方法,其特征在于,应用于服务器,所述方法包括:
接收来自第一电子设备的第一查询请求,所述第一查询请求用于请求下载第一APP的第一差分包;
若所述服务器已生成所述第一差分包,则向所述第一电子设备指示所述第一差分包的第一下载地址;
若所述服务器未生成所述第一差分包,则生成第一记录;其中,所述第一记录用于记录所述第一查询请求所请求的第一差分包;
获取第一时间段内生成的第一记录的数量;其中,所述第一时间段包括所述服务器接收到所述第一查询请求的当前时刻前的预设时长;或者,所述第一时间段包括第一时刻到所述服务器接收到所述第一查询请求的当前时刻之间的时间段;或者,所述第一时间段为预设时间段;
若所述第一记录的数量大于第一阈值,则生成所述第一记录所记录的第一差分包,并在第二下载地址存储所述第一差分包。
2.根据权利要求1所述的方法,其特征在于,所述第一时间段包括所述当前时刻前的预设时长;或者,所述第一时间段包括所述第一时刻到所述当前时刻之间的时间段;
在所述若所述第一记录的数量大于第一阈值,则生成所述第一记录所记录的第一差分包之后,所述方法还包括:
向所述第一电子设备指示所述第一差分包的所述第二下载地址。
3.根据权利要求1所述的方法,其特征在于,所述第一时间段为所述预设时间段;所述方法还包括:
若所述服务器未生成所述第一差分包,则向所述第一电子设备指示所述第一APP的全量包的第三下载地址;
接收来自第二电子设备的第二查询请求,所述第二查询请求用于请求下载所述第一APP的所述第一差分包;
所述服务器已生成所述第一差分包,向所述第二电子设备指示所述第一差分包的所述第二下载地址。
4.根据权利要求1所述的方法,其特征在于,所述若所述第一记录的数量大于第一阈值,则生成所述第一记录所记录的第一差分包,并在第二下载地址存储所述第一差分包,包括:
若所述第一记录的数量大于第一阈值,则标记所述第一记录为待生成差分包的记录;
接收来自第三电子设备发送的第三查询请求,所述第三查询请求用于请求下载所述第一APP的所述第一差分包;
所述服务器未生成所述第一差分包,但所述第一记录标记为所述待生成差分包的记录,则生成所述第一记录所记录的第一差分包,并在第二下载地址存储所述第一差分包。
5.根据权利要求1-4中任一项所述的方法,其特征在于,所述方法还包括:
若所述第一记录的数量小于所述第一阈值,则获取M个第一时间段内每个第一时间段内生成的第一记录的数量,其中,所述M个第一时间段具有相同的时长;
若所述M个第一时间段内至少有m个第一时间段内所述第一记录的数量均大于第二阈值,则生成所述第一记录所记录的第一差分包,并在第四下载地址存储所述第一差分包,其中,M、m为大于1的整数,所述第一阈值大于所述第二阈值。
6.根据权利要求1-4中任一项所述的方法,其特征在于,所述方法还包括:
若所述第一记录的数量小于所述第一阈值,则获取M个第一时间段内每个第一时间段内生成的第一记录的数量,其中,所述M个第一时间段具有相同的时长;
若所述M个第一时间段内所述第一记录的第一置信度大于第一预设置信度,则生成所述第一记录所记录的第一差分包,并在第四下载地址存储所述第一差分包,所述第一置信度=m/M,m为所述M个第一时间段中生成第一记录的数量大于第二阈值的第一时间段的数量,其中,M、m为大于1的整数。
7.根据权利要求1-4任一项所述的方法,其特征在于,所述方法还包括:
若所述服务器已生成所述第一差分包,则生成第二记录,所述第二记录用于记录所述第一查询请求所请求的第一差分包;
获取N个所述第一时间段内每个第一时间段内生成的第二记录的数量,其中,所述N个第一时间段具有相同的时长;
若N个第一时间段内至少有n个第一时间段内所述第二记录的数量均小于第三阈值,则删除所述第二记录所记录的第一差分包,其中,N、n为大于1的整数。
8.根据权利要求1-4任一项所述的方法,其特征在于,所述方法还包括:
若所述服务器已生成所述第一差分包,则生成第二记录,所述第二记录用于记录所述第一查询请求所请求的第一差分包;
获取N个所述第一时间段内每个第一时间段内生成的第二记录的数量,其中,所述N个第一时间段具有相同的时长;
若所述N个第一时间段内所述第二记录的第二置信度大于第二预设置信度,删除所述第二记录所记录的第一差分包,其中,所述第二置信度=n/N,n为所述N个第一时间段中生成第二记录的数量小于第三阈值的第一时间段的数量,其中,N、n为大于1的整数。
9.一种服务器,其特征在于,所述服务器包括:存储器、通信模块和一个或多个处理器;所述存储器、所述通信模块与所述处理器耦合;其中,所述通信模块用于与电子设备交互,所述存储器用于存储计算机程序代码,所述计算机程序代码包括计算机指令;当所述计算机指令被所述处理器执行时,使得所述服务器执行如权利要求1-8中任一项所述的方法。
10.一种计算机可读存储介质,其特征在于,包括计算机指令,当所述计算机指令在电子设备上运行时,使得所述电子设备执行如权利要求1-8中任一项所述的方法。
CN202311045987.4A 2023-08-18 2023-08-18 一种差分包的下载方法及服务器 Active CN116800733B (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202311045987.4A CN116800733B (zh) 2023-08-18 2023-08-18 一种差分包的下载方法及服务器

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202311045987.4A CN116800733B (zh) 2023-08-18 2023-08-18 一种差分包的下载方法及服务器

Publications (2)

Publication Number Publication Date
CN116800733A CN116800733A (zh) 2023-09-22
CN116800733B true CN116800733B (zh) 2023-11-17

Family

ID=88049939

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202311045987.4A Active CN116800733B (zh) 2023-08-18 2023-08-18 一种差分包的下载方法及服务器

Country Status (1)

Country Link
CN (1) CN116800733B (zh)

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN104331428A (zh) * 2014-10-20 2015-02-04 暨南大学 一种小文件和大文件的存储及访问方法
CN107203395A (zh) * 2017-05-19 2017-09-26 北京京东尚科信息技术有限公司 资源升级方法、装置及计算机可读存储介质和电子设备

Family Cites Families (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20150169619A1 (en) * 2013-12-06 2015-06-18 Zaius, Inc. System and method for creating storage containers in a data storage system
US10331662B2 (en) * 2016-05-18 2019-06-25 International Business Machines Corporation Dynamic column synopsis for analytical databases

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN104331428A (zh) * 2014-10-20 2015-02-04 暨南大学 一种小文件和大文件的存储及访问方法
CN107203395A (zh) * 2017-05-19 2017-09-26 北京京东尚科信息技术有限公司 资源升级方法、装置及计算机可读存储介质和电子设备

Also Published As

Publication number Publication date
CN116800733A (zh) 2023-09-22

Similar Documents

Publication Publication Date Title
WO2019120037A1 (zh) 模型构建方法、网络资源预加载方法、装置、介质及终端
CN107872523B (zh) 网络数据的加载方法、装置、存储介质及移动终端
CN101385017B (zh) 部分项改变跟踪和同步
CN111586126B (zh) 小程序预下载方法、装置、设备及存储介质
CN101425922B (zh) 跟踪和定位web服务更新过程中的改变的方法和装置
CN108540509B (zh) 一种终端浏览器的处理方法、装置及服务器、智能终端
KR100983240B1 (ko) 무선단말기에 어플리케이션을 용이하게 설치하는 방법 및 그 시스템
CN103294610A (zh) 可重复使用的内容可寻址存储
CN116774949B (zh) 一种资源包的存储方法及服务器
US10242102B2 (en) Network crawling prioritization
CN110968331A (zh) 应用程序运行的方法和装置
JP2009259124A (ja) アプリケーション更新情報提供システム、及びアプリケーション更新情報提供方法
CN114327710B (zh) 一种函数管理方法、管理装置、终端设备及可读存储介质
CN111866129B (zh) 基于云平台的服务可用性指标的确定方法及装置、介质
CN116800733B (zh) 一种差分包的下载方法及服务器
CN111125257B (zh) 词典更新方法、装置、设备和存储介质
KR20140148302A (ko) 복수의 앱스토어 서버 간의 앱 정보 연동장치 및 앱 정보 연동방법
CN103631621A (zh) 一种信息提示方法及装置
CN111880996B (zh) 一种裸机数据采集方法、装置、设备及可读存储介质
CN111198853A (zh) 数据处理方法、装置、电子设备及计算机可读存储介质
KR100699779B1 (ko) 사용자 단말기의 바탕화면에 설치된 아이콘을 갱신하는방법 및 그 시스템
CN111367634A (zh) 信息处理方法、信息处理装置及终端设备
CN112464049A (zh) 号码详单下载方法、装置和设备
CN112887349A (zh) 分发文件的方法和装置
JP2002251309A (ja) 共有ファイル管理システム

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
GR01 Patent grant
GR01 Patent grant