发明内容
本公开实施例至少提供一种软件开发工具包修复方法、终端、服务器、设备以及存储介质。
本公开实施例提供了一种软件开发工具包修复方法,应用于终端,所述终端中包括有多个软件开发工具包SDK,至少部分所述SDK的版本号不同,所述方法包括:
获取服务器针对所述多个SDK中每一个SDK生成的修复补丁和管理类信息,所述管理类信息为所述服务器根据SDK的标识信息和对应的修复方法确定的;
基于所述终端中的、每个SDK的本地补丁和获取到的多个修复补丁和多个管理类信息,确定针对每个SDK的最新补丁;
将确定出的、针对每个SDK的最新补丁进行解密和解压操作,获得每个最新补丁对应的可执行文件;
将确定出的多个可执行文件融合,得到针对所述多个SDK的融合补丁包;
使用所述融合补丁包对所述多个SDK进行修复。
一种可选的实施方式中,所述基于所述终端中的、每个SDK的本地补丁和所述多个修复补丁,确定针对每个SDK的最新补丁,包括:
针对每个修复补丁,基于该修复补丁的管理类信息中记载的、该修复补丁所属SDK的标识信息,确定与该修复补丁对应的、所述终端中存储的本地补丁;
检测该修复补丁和对应的本地补丁是否一致;
若该修复补丁和对应的本地补丁不一致,确定该修复补丁为对应的SDK的最新补丁;
若该修复补丁和对应的本地补丁一致,确定与该修复补丁对应的本地补丁为对应的SDK的最新补丁。
一种可选的实施方式中,在所述若该修复补丁和对应的本地补丁不一致,确定该修复补丁为对应的SDK的最新补丁之后,所述方法包括:
将与该修复补丁对应的本地补丁删除。
一种可选的实施方式中,通过以下步骤检测该修复补丁和对应的本地补丁是否一致:
分别计算该修复补丁的摘要算法值和对应的本地补丁的摘要算法值;
若该修复补丁的摘要算法值和对应的本地补丁的摘要算法值一致,确定该修复补丁和对应的本地补丁一致。
一种可选的实施方式中,所述将确定出的多个可执行文件融合,得到针对所述多个SDK的融合补丁包,包括:
将确定出的多个可执行文件按照解压解密之后的文件排列顺序重新命名;
按照重新命后的可执行文件融合成所述多个SDK的融合补丁包。
一种可选的实施方式中,在所述使用所述融合补丁包对所述多个SDK进行修复之前,所述方法包括:
确定在本次修复之前的上一次修复时,加载历史补丁包所产生的历史补丁信息;
清除所述历史补丁信息。
一种可选的实施方式中,使用所述融合补丁包对所述多个SDK进行修复,包括:
加载所述融合补丁包,并记录加载所述融合补丁包时产生有效补丁信息。
一种可选的实施方式中,所述多个SDK包括主SDK和根据所述终端需要实现的功能接入的功能SDK,接入的所述功能SDK依赖于所述主SDK存在。
本公开实施例提供了一种软件开发工具包修复方法,应用于服务器,所述方法包括:
针对多个SDK中每个SDK生成对应的修复补丁,其中,至少部分所述SDK的版本号不同;
根据每个SDK的标识信息和对应的修复方法,确定每个修复补丁的管理类信息;
在接收到终端的补丁请求后,将生成的多个修复补丁和每个修复补丁对应的管理类信息发送至所述终端,用于供所述终端基于所述终端中每个SDK的本地补丁以及获取到的多个修复补丁和多个管理类信息确定针对每个SDK的最新补丁,以及通过多个最新补丁对应的多个可执行文件融合得到的融合补丁包对所述终端中的多个SDK进行修复。
本公开实施例还提供一种终端,所述终端中包括有多个软件开发工具包SDK,至少部分所述SDK的版本号不同,所述终端包括:
获取模块,用于获取服务器针对所述多个SDK中每一个SDK生成的修复补丁和管理类信息,所述管理类信息为所述服务器根据SDK的标识信息和对应的修复方法确定的;
第一确定模块,用于基于所述终端中的、每个SDK的本地补丁和获取到的多个修复补丁和多个管理类信息,确定针对每个SDK的最新补丁;
第二确定模块,用于将确定出的、针对每个SDK的最新补丁进行解密和解压操作,获得每个最新补丁对应的可执行文件;
融合模块,用于将确定出的多个可执行文件融合,得到针对所述多个SDK的融合补丁包;
修复模块,用于使用所述融合补丁包对所述多个SDK进行修复。
一种可选的实施方式中,所述第一确定模块具体用于:
针对每个修复补丁,基于该修复补丁的管理类信息中记载的、该修复补丁所属SDK的标识信息,确定与该修复补丁对应的、所述终端中存储的本地补丁;
检测该修复补丁和对应的本地补丁是否一致;
若该修复补丁和对应的本地补丁不一致,确定该修复补丁为对应的SDK的最新补丁;
若该修复补丁和对应的本地补丁一致,确定与该修复补丁对应的本地补丁为对应的SDK的最新补丁。
一种可选的实施方式中,所述第一确定模块还用于:
将与该修复补丁对应的本地补丁删除。
一种可选的实施方式中,所述第一确定模块用于通过以下步骤检测该修复补丁和对应的本地补丁是否一致:
分别计算该修复补丁的摘要算法值和对应的本地补丁的摘要算法值;
若该修复补丁的摘要算法值和对应的本地补丁的摘要算法值一致,确定该修复补丁和对应的本地补丁一致。
一种可选的实施方式中,所述融合模块具体用于:
将确定出的多个可执行文件按照解压解密之后的文件排列顺序重新命名;
按照重新命后的可执行文件融合成所述多个SDK的融合补丁包。
一种可选的实施方式中,所述终端还包括清除模块,所述清除模块用于:
确定在本次修复之前的上一次修复时,加载历史补丁包所产生的历史补丁信息;
清除所述历史补丁信息。
一种可选的实施方式中,所述修复模块具体用于:
加载所述融合补丁包,并记录加载所述融合补丁包时产生有效补丁信息。
本公开实施例还提供一种服务器,所述服务器包括:
生成模块,用于针对多个SDK中每个SDK生成对应的修复补丁,其中,至少部分所述SDK的版本号不同;
信息确定模块,用于根据每个SDK的标识信息和对应的修复方法,确定每个修复补丁的管理类信息;
发送模块,用于在接收到终端的补丁请求后,将生成的多个修复补丁和每个修复补丁对应的管理类信息发送至所述终端,用于供所述终端基于所述终端中每个SDK的本地补丁以及获取到的多个修复补丁和多个管理类信息确定针对每个SDK的最新补丁,以及通过多个最新补丁对应的多个可执行文件融合得到的融合补丁包对所述终端中的多个SDK进行修复。
本公开实施例还提供一种电子设备,包括:处理器、存储器和总线,所述存储器存储有所述处理器可执行的机器可读指令,当电子设备运行时,所述处理器与所述存储器之间通过总线通信,所述机器可读指令被所述处理器执行时执行上述的软件开发工具包修复方法中的步骤。
本公开实施例还提供一种计算机存储介质,该计算机存储介质上存储有计算机程序,该计算机程序被处理器运行时执行上述的软件开发工具包修复方法中的步骤。
本公开实施例提供的软件开发工具包修复方法、终端、服务器、设备以及存储介质,服务器通过针对多个SDK中每个SDK生成对应的修复补丁,根据每个SDK的标识信息和对应的修复方法,确定每个修复补丁的管理类信息,在接收到终端的补丁请求后,将生成的多个修复补丁和每个修复补丁对应的管理类信息发送至终端,终端通过获取服务器针对多个软件开发工具包SDK中每一个SDK生成的修复补丁,基于所述终端中的、每个SDK的本地补丁和所述多个修复补丁,确定针对每个SDK的最新补丁,将确定出的、针对每个SDK的最新补丁进行融合,得到针对所述多个SDK的融合补丁包,使用所述融合补丁包对所述多个SDK进行修复。
这样,可以在服务器侧针对各版本的SDK单独生成补丁,以保证SDK的独立性,并将SDK的标识作为独立信息带到生成的管理类信息中,有利于后续补丁合并操作的顺利进行,对于不同版本、并且有关联的多个SDK可以通过一次性下发即可下发全部SDK的补丁,在终端侧将独立的补丁进行融合之后再对各SDK进行修复,使得接入各SDK的不同应用都可以接收到相应的补丁,以对包括全部SDK的中台工具进行整体修复,不仅可以大大降低热修复工作量和资源消耗量,还可以有效顾及各SDK之间的独立性、关联性和依赖性,大大避免因为各SDK之间的关联性导致的修复失败,有利于提高热修复的成功率。
为使本公开的上述目的、特征和优点能更明显易懂,下文特举较佳实施例,并配合所附附图,作详细说明如下。
具体实施方式
为使本公开实施例的目的、技术方案和优点更加清楚,下面将结合本公开实施例中附图,对本公开实施例中的技术方案进行清楚、完整地描述,显然,所描述的实施例仅仅是本公开一部分实施例,而不是全部的实施例。通常在此处附图中描述和示出的本公开实施例的组件可以以各种不同的配置来布置和设计。因此,以下对在附图中提供的本公开的实施例的详细描述并非旨在限制要求保护的本公开的范围,而是仅仅表示本公开的选定实施例。基于本公开的实施例,本领域技术人员在没有做出创造性劳动的前提下所获得的所有其他实施例,都属于本公开保护的范围。
应注意到:相似的标号和字母在下面的附图中表示类似项,因此,一旦某一项在一个附图中被定义,则在随后的附图中不需要对其进行进一步定义和解释。
本文中术语“和/或”,仅仅是描述一种关联关系,表示可以存在三种关系,例如,A和/或B,可以表示:单独存在A,同时存在A和B,单独存在B这三种情况。另外,本文中术语“至少一种”表示多种中的任意一种或多种中的至少两种的任意组合,例如,包括A、B、C中的至少一种,可以表示包括从A、B和C构成的集合中选择的任意一个或多个元素。
经研究发现,目前,市面上针对APP级别的热修复方案趋近成熟,然而对软件开发工具包(Software Development Kit,SDK)级别的热修复方案比较少,尤其是针对中台类工具而言,例如游戏中台,需要根据不同的游戏接入需求来提供不同功能,因此需要提供相互独立的、但是有依赖关系的多个SDK,在进行了SDK组件化之后,这些SDK大多有各自独立的工具版本,可以被接入方按照一定的规则重新组合接入。
现在对于中台类工具的热修复,大多是对各SDK单独进行修复,或者将不同SDK进行组合当成整体以进行修复,而随着SDK数量的增多,组合数量呈指数级增长,导致热修复工作量大,资源消耗严重,难以估计各SDK相互之间的依赖性和关联性。
基于上述研究,本公开提供了一种软件开发工具包修复方法,可以在服务器侧针对各版本的SDK单独生成补丁,以保证SDK的独立性,并将SDK的标识作为独立信息带到生成的管理类信息中,有利于后续补丁合并操作的顺利进行,对于不同版本、并且有关联的多个SDK可以通过一次性下发即可下发全部SDK的补丁,在终端侧将独立的补丁进行融合之后再对各SDK进行修复,使得接入各SDK的不同应用都可以接收到相应的补丁,以对包括全部SDK的中台工具进行整体修复,不仅可以大大降低热修复工作量和资源消耗量,还可以有效顾及各SDK之间的独立性、关联性和依赖性,大大避免因为各SDK之间的关联性导致的修复失败,有利于提高热修复的成功率。
为便于对本实施例进行理解,首先对本公开实施例所公开的一种工具包修复方法进行详细介绍,本公开实施例所提供的工具包修复方法的执行主体一般为具有一定计算能力的计算机设备,该计算机设备例如包括:终端设备或服务器或其它处理设备,终端设备可以为用户设备(User Equipment,UE)、移动设备、用户终端、终端、蜂窝电话、无绳电话、个人数字助理(Personal Digital Assistant,PDA)、手持设备、计算设备、车载设备、可穿戴设备等。在一些可能的实现方式中,该工具包修复方法可以通过处理器调用存储器中存储的计算机可读指令的方式来实现。
请参阅图1,图1为本公开实施例的应用场景示意图。如图1中所示,当下随着互联网技术的发展下,各种终端已经走进了人们的生活,例如各种移动终端、可穿戴的智能终端、固定终端等,人们在使用各种终端时,大多需要安装、升级各种功能应用和工具应用等,通过,开发者会在后台服务器侧开发用户需求的各种应用文件和对应用进行升级、修复的补丁文件,并将开发的应用文件和补丁文件等上传到用于管理应用的应用平台,例如各应用商店等,用户可以从应用平台中下载应用文件和补丁文件等,以安装应用,以及对应用进行修复等动作。
请参阅图2,图2为本公开实施例提供的一种软件开发工具包修复方法的流程图。本公开实施例提供的软件开发工具包修复方法,可以应用于如图1中所示的服务器,如图2所示,所述方法包括:
S201:针对多个SDK中每个SDK生成对应的修复补丁,其中,至少部分所述SDK的版本号不同。
该步骤中,终端中可以安装有目标应用,所述目标应用包括多个软件开发工具包SDK,进一步的,所述多个SDK可以包括主SDK和根据所述终端需要实现的功能接入的功能SDK,所述多个SDK中至少部分所述SDK的版本号不同,在所述目标应用需要版本升级或者需要修复,尤其是所述多个SDK中的至少部分SDK需要修复或者升级时,可以针对每个SDK生成对应的修复补丁。
其中,针对每个SDK生成对应的修复补丁,即针对每个SDK单独生成一个修复补丁。
进一步的,在部分SDK无需修复时,其对应生成的修复补丁可以是上次进行修复时的补丁。
S202:根据每个SDK的标识信息和对应的修复方法,确定每个修复补丁的管理类信息。
该步骤中,在根据每个SDK的标识信息和对应的修复方法,例如SDK名称、SDK中的待修复方法(旧的存在问题的旧方法)以及对应的修复方法(新的可以对就旧方法进行修复的新方法),确定每个修复补丁的管理类信息。
其中,每一个修复补丁的管理类信息可以是通过Java源码来记录的。
S203:在接收到终端的补丁请求后,将生成的多个修复补丁和每个修复补丁对应的管理类信息发送至所述终端,用于供所述终端基于所述终端中每个SDK的本地补丁以及获取到的多个修复补丁和多个管理类信息确定针对每个SDK的最新补丁,以及通过多个最新补丁对应的多个可执行文件融合得到的融合补丁包对所述终端中的多个SDK进行修复。
该步骤中,在接收到终端发送的用于下载补丁的补丁请求之后,响应于所述补丁请求,将生成的多个修复补丁和每个修复补丁对应的管理类信息打包发送至所述终端。
其中,在服务器侧,对于每个SDK而言,在其发生变化后,每次均可以生成一个对应的修复补丁,随着时间的积累和版本的更迭等,每个SDK可能会有多个修复补丁,因此,为了便于管理,可以为每次生成的修复补丁按照生成时间配置不同的优先级,修复补丁的生成时间越接近当前的服务器时钟时间,则修复补丁的优先级越高,相应的,在下发补丁,即需要将补丁发送给终端或者上传至管理平台的时候,对比SDK的所有修复补丁的优先级,确定优先级最高的修复补丁为要发送给终端或者上传到管理平台的修复补丁。
具体的,在接收到终端的补丁请求后,可以将确定出的优先级最高的修复补丁以及每个修复补丁对应的管理类信息发送至所述终端,即在当前SDK有多个修复补丁时,选择优先级最高的补丁发送给终端。
将修复补丁和修复补丁对应的管理类信息一同发送,可以保证补丁与补丁管理类的对应性,便于后续使用。
本公开实施例提供的软件开发工具包修复方法,通过针对多个SDK中每个SDK生成对应的修复补丁,根据每个SDK的标识信息和对应的修复方法,确定每个修复补丁的管理类信息,在接收到终端的补丁请求后,将生成的多个修复补丁和每个修复补丁对应的管理类信息发送至所述终端。
这样,在服务器侧可以针对各版本的SDK单独生成补丁,以保证SDK的独立性,并将SDK的标识作为独立信息带到生成的管理类信息中,有利于后续补丁合并操作的顺利进行,对于不同版本、并且有关联的多个SDK可以通过一次性下发即可下发全部SDK的补丁。
请同时参阅图3,图3为本公开实施例提供的一种软件开发工具包修复方法的流程图。本公开实施例提供的软件开发工具包修复方法,应用于如图1中所示的终端,所述终端中包括有多个软件开发工具包SDK,至少部分所述SDK的版本号不同,如图3中所示,所述方法包括:
S301:获取服务器针对所述多个SDK中每一个SDK生成的修复补丁和管理类信息,所述管理类信息为所述服务器根据SDK的标识信息和对应的修复方法确定的。
其中,获取的多个修复补丁,如图1中所示,可以从应用平台中获取,但并不局限于此,在其他实时方式中,也可以是直接从服务器处获取。
其中,所述多个SDK可以是组成中台类工具的多个SDK,其可以包括主SDK,和接入主SDK的、根据所述终端需要实现的功能接入的多个功能SDK,接入的功能SDK依赖于主SDK,此外,多个功能SDK之间也可以存在依赖关系。
其中,所述修复补丁的文件类型可以是jar文件。
其中,获取的修复补丁,可以是将接收的服务器发送的打包文件,其中包括有各SDK的修复补丁。
其中,为了保证补丁与补丁管理类的对应性,以及此处的便利性,在获取修复补丁时,即可一并获取修复补丁对应的管理类信息,即在接收的打包的文件中可以包括记载有管理类信息的文件。
S302:基于所述终端中的、每个SDK的本地补丁和获取到的多个修复补丁和多个管理类信息,确定针对每个SDK的最新补丁。
该步骤中,在获取到多个修复补丁之后,可以通过将所述多个修复补丁与所述终端中的、每个SDK的本地补丁进行对比等方式,即将每个SDK对应的修复补丁和本地补丁进行比对,根据修复补丁与本地补丁的对比结果,确定出各SDK的最新补丁。
其中,所述终端中的、每个SDK的本地补丁和所述多个修复补丁以及确定的最新补丁的文件类型都是jar文件。
其中,确定每个SDK的最新补丁,可以是在接收到服务器发送的文件后,例如接收到服务器发送的文件包之后,通过文件包中的管理类信息与本地补丁进行比对,以确定最新补丁。
相应的,在一些具体的实施方式中,对于确定针对每个SDK的最新补丁,可以通过以下步骤:
针对每个修复补丁,基于该修复补丁的管理类信息中记载的、该修复补丁所属SDK的标识信息,确定与该修复补丁对应的、所述终端中存储的本地补丁;检测该修复补丁和对应的本地补丁是否一致;若该修复补丁和对应的本地补丁不一致,确定该修复补丁为对应的SDK的最新补丁;若该修复补丁和对应的本地补丁一致,确定与该修复补丁对应的本地补丁为对应的SDK的最新补丁。
这里,在需要确定各SDK的最新补丁时,可以从收到的文件中,提取出每个修复补丁的管理类信息,针对每个修复补丁,可以根据该修复补丁的管理类信息中记载的、该修复补丁所属SDK的标识信息,确定出该修复补丁所属的SDK,进而可以确定出所属的SDK在终端中存储的本地补丁,然后可以对该修复补丁和本地补丁进行比对,以检测该修复补丁和对应的本地补丁是否一致,若该修复补丁和对应的本地补丁不一致,则认为该修复补丁为对应的SDK的最新补丁,若该修复补丁和对应的本地补丁一致,则可以认为与该修复补丁对应的本地补丁已经是SDK的最新补丁。
具体的,在对该修复补丁和对应的本地补丁进行比对时,可以通过以下步骤检测该修复补丁和对应的本地补丁是否一致:
分别计算该修复补丁的摘要算法值和对应的本地补丁的摘要算法值;若该修复补丁的摘要算法值和对应的本地补丁的摘要算法值一致,确定该修复补丁和对应的本地补丁一致。
该步骤中,在检测修复补丁和对应的本地补丁是否一致时,可以分别计算出该修复补丁的摘要算法值和对应的本地补丁的摘要算法值,然后通过对比该修复补丁的摘要算法值和对应的本地补丁的摘要算法值的大小,检测该修复补丁和对应的本地补丁是否一致,如果该修复补丁的摘要算法值和对应的本地补丁的摘要算法值大小相等,则可以确定该修复补丁和对应的本地补丁一致。
其中,该修复补丁的摘要算法值和对应的本地补丁的摘要算法值可以是修复补丁的MD5值和对应的本地补丁的MD5值。
进一步的,在确定出该修复补丁与对应的本地补丁不一致的时候,可以认为本地补丁是旧版本的补丁,需要进行修复,为避免本地补丁对修复过程产生影响,以及减少终端的内存占用量等,在所述若该修复补丁和对应的本地补丁不一致,确定该修复补丁为对应的SDK的最新补丁之后,所述方法包括:
将与该修复补丁对应的本地补丁删除。
这样,在修复补丁和对应的本地补丁不一致,确定修复补丁为对应的SDK的最新补丁的情况下,即可以将与修复补丁对应的本地补丁删除,以避免在使用补丁时造成的影响。
S303:将确定出的、针对每个SDK的最新补丁进行解密和解压操作,获得每个最新补丁对应的可执行文件。
该步骤中,在确定出每个SDK的最新补丁,即保留下的本地补丁和新下载的修复补丁,可以对最新补丁全部进行解密和解压处理,从而得到补丁所在的可执行文件。
其中,可执行文件的类型为dex文件。
S304:将确定出的多个可执行文件进行融合,得到针对所述多个SDK的融合补丁包。
该步骤中,在得到补丁所在的可执行文件之后,可以将多个可执行文件进行融合,得到融合补丁包,进一步的,可以将所有的可执行文件(修复文件和本地文件)删除,以防止解密后的补丁代码泄漏。
其中,所述多个SDK的融合补丁包的文件类型是jar文件。
S305:使用所述融合补丁包对所述多个SDK进行修复。
该步骤中,可以将得到的所述融合补丁包用类加载器进行加载,使所述融合补丁包生效,以完成对所述多个SDK的修复。
其中,得到针对所述多个SDK的融合补丁包之后,在加载融合补丁包时,可以根据终端的状态决定加载方式,例如可以检测终端的系统版本是否足够,以终端的系统为安卓系统为例,需要检测终端的安卓系统是否是5.0以下版本,若是的话,需要将多个SDK的融合补丁包中的每个独立的可执行文件都添加到类加载器的路径下,以保证合成后所有补丁都会被加载运行。
本公开实施例提供的软件开发工具包修复方法,通过获取服务器针对所述多个SDK中每一个SDK生成的修复补丁;基于所述终端中的、每个SDK的本地补丁和所述多个修复补丁,确定针对每个SDK的最新补丁;将确定出的、针对每个SDK的最新补丁进行解密和解压操作,获得每个最新补丁对应的可执行文件;将确定出的多个可执行文件融合,得到针对所述多个SDK的融合补丁包;使用所述融合补丁包对所述多个SDK进行修复。
这样,在终端侧将独立的补丁进行融合之后再对各SDK进行修复,使得接入各SDK的不同应用都可以接收到相应的补丁,以对包括全部SDK的中台工具进行整体修复,不仅可以大大降低热修复工作量和资源消耗量,还可以有效顾及各SDK之间的独立性、关联性和依赖性,大大避免因为各SDK之间的关联性导致的修复失败,有利于提高热修复的成功率。
请参阅图4,图4为本公开实施例提供的另一种软件开发工具包修复方法的流程图。本公开实施例提供的软件开发工具包修复方法,应用于如图1中所示的终端,所述终端中包括有多个软件开发工具包SDK,至少部分所述SDK的版本号不同,如图4中所示,所述方法包括:
S401:获取服务器针对所述多个SDK中每一个SDK生成的修复补丁和管理类信息,所述管理类信息为所述服务器根据SDK的标识信息和对应的修复方法确定的。
S402:基于所述终端中的、每个SDK的本地补丁和获取到的多个修复补丁和多个管理类信息,确定针对每个SDK的最新补丁。
S403:将确定出的、针对每个SDK的最新补丁进行解密和解压操作,获得每个最新补丁对应的可执行文件。
S404:将确定出的多个可执行文件融合,得到针对所述多个SDK的融合补丁包。
S405:确定在本次修复之前的上一次修复时,加载历史补丁包所产生的历史补丁信息。
该步骤中,在使用所述融合补丁包对所述多个SDK进行修复之前,需要确定出在本次修复之前的上一次修复所产生的产物,即上一次加载融合补丁包所产生的历史补丁信息。
S406:清除所述历史补丁信息。
该步骤中,清除所述历史补丁信息,即清除上一次加载融合补丁包所生成的产物,以免影响本次融合补丁的加载修复。
其中,只有在所述终端中的、每个SDK的本地补丁和所述多个修复补丁之间存在至少部分对应补丁不一致的前提下,才会进行清除所述历史补丁的信息,即在终端的本地补丁有更新的前提下,才会清除所述历史补丁信息,若终端的本地补丁无更新,则无需清除所述历史补丁信息。
S407:使用所述融合补丁包对所述多个SDK进行修复。
其中,步骤S401至步骤S404和步骤S407的描述,可以参照步骤S301至步骤S305的描述,并且可以达到相同的技术效果和解决相同的技术问题,在此不做赘述。
接下来,结合具体实施方式进一步对本实施例进行说明。
一种可选的实施方式中,步骤S404包括:
将确定出的多个可执行文件按照解压解密之后的文件排列顺序重新命名;按照重新命后的可执行文件融合成所述多个SDK的融合补丁包。
该步骤中,在解密和解压得到每个最新补丁的可执行文件之后,可以识别每个可执行文件再解压和解密之后的排序顺序,然后可以按照每个可执行文件排序顺序对其重新命名,进而将重新命名的多个可执行文件融合成所述融合补丁包。
一种可选的实施方式中,步骤S405包括:
加载所述融合补丁包,并记录加载所述融合补丁包时产生有效补丁信息。
进一步的,可以在记录加载所述融合补丁包时产生有效补丁信息之后,根据记录的有效补丁信息,判断出未生效的补丁,将未生效补丁的管理类信息,发送给服务器,请求重新下载修复补丁。
本公开实施例提供的软件开发工具包修复方法,通过获取服务器针对所述多个SDK中每一个SDK生成的修复补丁;基于所述终端中的、每个SDK的本地补丁和所述多个修复补丁,确定针对每个SDK的最新补丁;将确定出的、针对每个SDK的最新补丁进行解密和解压操作,获得每个最新补丁对应的可执行文件;将确定出的多个可执行文件融合,得到针对所述多个SDK的融合补丁包;确定在本次修复之前的上一次修复时,加载历史补丁包所产生的历史补丁信息;清除所述历史补丁信息;使用所述融合补丁包对所述多个SDK进行修复。
这样,在终端侧将独立的补丁进行融合之后再对各SDK进行修复,使得接入各SDK的不同应用都可以接收到相应的补丁,以对包括全部SDK的中台工具进行整体修复,不仅可以大大降低热修复工作量和资源消耗量,还可以有效顾及各SDK之间的独立性、关联性和依赖性,大大避免因为各SDK之间的关联性导致的修复失败,有利于提高热修复的成功率,在进行修复之前,删除了以前修复生成的产物,清除了对本次修复的影响,进一步提高热修复的效率与成功率。
本领域技术人员可以理解,在具体实施方式的上述方法中,各步骤的撰写顺序并不意味着严格的执行顺序而对实施过程构成任何限定,各步骤的具体执行顺序应当以其功能和可能的内在逻辑确定。
基于同一发明构思,本公开实施例中还提供了分别与软件开发工具包修复方法对应的服务器和终端,由于本公开实施例中的服务器和终端解决问题的原理与本公开实施例上述工具包修复方法相似,因此装置的实施可以参见方法的实施,重复之处不再赘述。
请参阅图5,图5为本公开实施例提供的一种服务器的示意图。本公开实施例提供的服务器500,包括:
生成模块510,用于针对多个SDK中每个SDK生成对应的修复补丁,其中,至少部分所述SDK的版本号不同;
信息确定模块520,用于根据每个SDK的标识信息和对应的修复方法,确定每个修复补丁的管理类信息;
发送模块530,用于在接收到终端的补丁请求后,将生成的多个修复补丁和每个修复补丁对应的管理类信息发送至所述终端,用于供所述终端基于所述终端中每个SDK的本地补丁以及获取到的多个修复补丁和多个管理类信息确定针对每个SDK的最新补丁,以及通过多个最新补丁对应的多个可执行文件融合得到的融合补丁包对所述终端中的多个SDK进行修复。
关于装置中的各模块的处理流程、以及各模块之间的交互流程的描述可以参照上述方法实施例中的相关说明,这里不再详述。
本公开实施例提供的服务器,可以针对各版本的SDK单独生成补丁,以保证SDK的独立性,并将SDK的标识作为独立信息带到生成的管理类信息中,有利于后续补丁合并操作的顺利进行,对于不同版本、并且有关联的多个SDK可以通过一次性下发即可下发全部SDK的补丁。
请参阅图6至图7,图6为本公开实施例提供的一种终端的示意图之一,图7为本公开实施例提供的一种终端的示意图之二。所述终端中包括有多个软件开发工具包SDK,至少部分所述SDK的版本号不同,如图6中所示,本公开实施例提供的终端600,包括:
获取模块610,用于获取服务器针对所述多个SDK中每一个SDK生成的修复补丁和管理类信息,所述管理类信息为所述服务器根据SDK的标识信息和对应的修复方法确定的。
第一确定模块620,用于基于所述终端中的、每个SDK的本地补丁和获取到的多个修复补丁和多个管理信息,确定针对每个SDK的最新补丁。
第二确定模块630,用于将确定出的、针对每个SDK的最新补丁进行解密和解压操作,获得每个最新补丁对应的可执行文件.
融合模块640,用于将确定出的多个可执行文件融合,得到针对所述多个SDK的融合补丁包;
修复模块650,用于使用所述融合补丁包对所述多个SDK进行修复。
一种可选的实施方式中,所述第一确定模块620具体用于:
针对每个修复补丁,基于该修复补丁的管理类信息中记载的、该修复补丁所属SDK的标识信息,确定与该修复补丁对应的、所述终端中存储的本地补丁;
检测该修复补丁和对应的本地补丁是否一致;
若该修复补丁和对应的本地补丁不一致,确定该修复补丁为对应的SDK的最新补丁;
若该修复补丁和对应的本地补丁一致,确定与该修复补丁对应的本地补丁为对应的SDK的最新补丁。
一种可选的实施方式中,所述第一确定模块620还用于:
将与该修复补丁对应的本地补丁删除。
一种可选的实施方式中,所述第一确定模块620用于通过以下步骤检测该修复补丁和对应的本地补丁是否一致:
分别计算该修复补丁的摘要算法值和对应的本地补丁的摘要算法值;
若该修复补丁的摘要算法值和对应的本地补丁的摘要算法值一致,确定该修复补丁和对应的本地补丁一致。
一种可选的实施方式中,所述融合模块640具体用于:
将确定出的多个可执行文件按照解压解密之后的文件排列顺序重新命名;
按照重新命后的可执行文件融合成所述多个SDK的融合补丁包。
一种可选的实施方式中,所述终端还包括清除模块660,所述清除模块660用于:
确定在本次修复之前的上一次修复时,加载历史补丁包所产生的历史补丁信息;
清除所述历史补丁信息。
一种可选的实施方式中,所述修复模块650具体用于:
加载所述融合补丁包,并记录加载所述融合补丁包时产生有效补丁信息。
本公开实施例提供的终端,可以将接收到的独立的补丁进行融合之后再对各SDK进行修复,使得接入各SDK的不同应用都可以接收到相应的补丁,以对包括全部SDK的中台工具进行整体修复,不仅可以大大降低热修复工作量和资源消耗量,还可以有效顾及各SDK之间的独立性、关联性和依赖性,大大避免因为各SDK之间的关联性导致的修复失败,有利于提高热修复的成功率。
基于同一技术构思,本申请实施例还提供了一种电子设备。本公开实施例还提供了一种电子设备800,如图8所示,为本公开实施例提供的电子设备800结构示意图,包括:
处理器810、存储器820、和总线830;存储器820用于存储执行指令,包括内存821和外部存储器822;这里的内存821也称内存储器,用于暂时存放处理器810中的运算数据,以及与硬盘等外部存储器822交换的数据,处理器810通过内存821与外部存储器822进行数据交换,当所述电子设备800运行时,所述处理器810与所述存储器820之间通过总线830通信,使得所述处理器810可以执行上述图2或者图3与图4所示的的软件开发工具包修复方法的步骤。
本公开实施例还提供一种计算机存储介质,该计算机存储介质上存储有计算机程序,该计算机程序被处理器运行时执行上述图2或者图3与图4所示的软件开发工具包修复方法的步骤。其中,该存储介质可以是易失性或非易失的计算机取存储介质。
本公开实施例还提供一种计算机程序产品,该计算机程序产品承载有程序代码,所述程序代码包括的指令可用于执行上述方法实施例中所述的软件开发工具包修复方法的步骤,具体可参见上述方法实施例,在此不再赘述。
其中,上述计算机程序产品可以具体通过硬件、软件或其结合的方式实现。在一个可选实施例中,所述计算机程序产品具体体现为计算机存储介质,在另一个可选实施例中,计算机程序产品具体体现为软件产品,例如软件开发包(Software Development Kit,SDK)等等。
所属领域的技术人员可以清楚地了解到,为描述的方便和简洁,上述描述的存储介质、装置和设备的具体工作过程,可以参考前述方法实施例中的对应过程,在此不再赘述。在本公开所提供的几个实施例中,应该理解到,所揭露的存储介质、设备、装置和方法,可以通过其它的方式实现。以上所描述的装置实施例仅仅是示意性的,例如,所述单元的划分,仅仅为一种逻辑功能划分,实际实现时可以有另外的划分方式,又例如,多个单元或组件可以结合或者可以集成到另一个装置,或一些特征可以忽略,或不执行。另一点,所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些通信接口,装置或单元的间接耦合或通信连接,可以是电性,机械或其它的形式。
所述作为分离部件说明的单元可以是或者也可以不是物理上分开的,作为单元显示的部件可以是或者也可以不是物理单元,即可以位于一个地方,或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。
另外,在本公开各个实施例中的各功能单元可以集成在一个处理单元中,也可以是各个单元单独物理存在,也可以两个或两个以上单元集成在一个单元中。
所述功能如果以软件功能单元的形式实现并作为独立的产品销售或使用时,可以存储在一个处理器可执行的非易失的计算机取存储介质中。基于这样的理解,本公开的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的部分可以以软件产品的形式体现出来,该计算机软件产品存储在一个存储介质中,包括若干指令用以使得一台计算机设备(可以是个人计算机,服务器,或者网络设备等)执行本公开各个实施例所述方法的全部或部分步骤。而前述的存储介质包括:U盘、移动硬盘、只读存储器(Read-OnlyMemory,ROM)、随机存取存储器(Random Access Memory,RAM)、磁碟或者光盘等各种可以存储程序代码的介质。
最后应说明的是:以上所述实施例,仅为本公开的具体实施方式,用以说明本公开的技术方案,而非对其限制,本公开的保护范围并不局限于此,尽管参照前述实施例对本公开进行了详细的说明,本领域的普通技术人员应当理解:任何熟悉本技术领域的技术人员在本公开揭露的技术范围内,其依然可以对前述实施例所记载的技术方案进行修改或可轻易想到变化,或者对其中部分技术特征进行等同替换;而这些修改、变化或者替换,并不使相应技术方案的本质脱离本公开实施例技术方案的精神和范围,都应涵盖在本公开的保护范围之内。因此,本公开的保护范围应所述以权利要求的保护范围为准。