一种软件开发包更新方法及装置
技术领域
本公开涉及计算机技术领域,具体而言,涉及一种软件开发包更新方法及装置。
背景技术
热更新,是一种各大手游等众多应用程序(Application,APP)常用的更新方式。热更新就是动态下发代码,它可以使开发者在不发布新版本的情况下,修复漏洞(BUG)和发布功能,并且不需要长时间的审核等待,方便快捷。
目前,针对应用程序的热更新方案已经日趋完善,但针对软件开发包(SoftwareDevelopment Kit,SDK)的热更新方案却较少。对于软件开发包的热更新,需要使用APP的编译方法,先生成一个APP用的编译产物,再将该编译产物转换为SDK专用的补丁,过程十分繁琐,并且,不同版本的构建工具在进行APP的编译时,需要设置不同的路径位置,难以进行维护,操作量大,效率较低。
发明内容
本公开实施例至少提供一种软件开发包更新方法及装置,直接使用SDK的编译方法生成数据更新补丁,可以直接使用不同版本的构建工具,便于维护,效率较高。
第一方面,本公开实施例提供了一种软件开发包更新方法,包括:
在软件开发包的编译过程中,将第一目标依赖文件添加到第一预设目录;
对第一预设目录下的第一目标依赖文件进行插桩处理;
在所述软件开发包上线后,响应补丁生成指令,基于所述第一目标依赖文件以及第二预设目录下的第二目标依赖文件,生成所述软件开发包的数据更新补丁;所述数据更新补丁用于更新所述软件开发包。
在一种可能的实施方式中,所述第一目标依赖文件为所述软件开发包的内部依赖文件;所述第二目标依赖文件为所述软件开发包的外部依赖文件。
在一种可能的实施方式中,所述对第一预设目录下的第一目标依赖文件进行插桩处理,包括:
将所述第一预设目录添加到目标插桩插件的处理路径中,并利用目标插桩插件及自动存储管理插件,对所述第一预设目录下的第一目标依赖文件进行插桩处理。
在一种可能的实施方式中,对第一预设目录下的第一目标依赖文件进行插桩处理之后,还包括:
生成插桩管理文件;所述插桩管理文件中包含指示有软件开发包中的可更新范围的文件编号;
所述基于所述第一目标依赖文件以及第二预设目录下的第二目标依赖文件,生成所述软件开发包的数据更新补丁,包括:
响应补丁生成指令,获取所述软件开发包的更新依赖文件;
根据所述插桩管理文件中指示的文件编号,确定所述更新依赖文件是否在可更新范围内;
若所述更新依赖文件在可更新范围内,则将所述第二预设目录添加到目标编译器的处理路径中,并利用目标编译器根据所述更新依赖文件对所述第一目标依赖文件和所述第二目标依赖文件进行更新,并对更新的第一目标依赖文件和第二目标依赖文件添加更新注解;
基于带有更新注解的所述第一目标依赖文件和第二目标依赖文件,生成所述软件开发包的数据更新补丁。
在一种可能的实施方式中,所述利用目标编译器根据所述更新依赖文件对所述第一目标依赖文件和所述第二目标依赖文件进行更新,并对更新的第一目标依赖文件和第二目标依赖文件添加更新注解,包括:
利用所述目标编译器及目标编译插件,将所述第一目标依赖文件及第二目标依赖文件中需要进行更新的无源依赖文件替换为所述更新依赖文件中对应的目标无源依赖文件,并对所述第一目标依赖文件及第二目标依赖文件中的目标无源依赖文件添加更新注解;
利用所述目标编译器,将所述第一目标依赖文件及第二目标依赖文件中需要进行更新的有源依赖文件替换为所述更新依赖文件中对应的目标有源依赖文件,并对所述第一目标依赖文件及第二目标依赖文件中的目标有源依赖文件添加更新注解。
在一种可能的实施方式中,在生成所述软件开发包的数据更新补丁之后,所述方法还包括:
利用预先与客户端约定的加密方式,对所述数据更新补丁加密。
在一种可能的实施方式中,所述方法还包括:
当检测到客户端发送的更新请求时,验证所述更新请求携带的应用身份标识及软件开发包版本;
在验证通过后,将所述数据更新补丁发送至所述客户端。
第二方面,本公开实施例还提供一种软件开发包更新装置,包括:
添加模块,用于在软件开发包的编译过程中,将第一目标依赖文件添加到第一预设目录;
插桩模块,用于对第一预设目录下的第一目标依赖文件进行插桩处理;
生成模块,用于在所述软件开发包上线后,响应补丁生成指令,基于所述第一目标依赖文件、所述插桩管理文件,以及第二预设目录下的第二目标依赖文件,生成所述软件开发包的数据更新补丁;所述数据更新补丁用于更新所述软件开发包。
在一种可能的实施方式中,所述第一目标依赖文件为所述软件开发包的内部依赖文件;所述第二目标依赖文件为所述软件开发包的外部依赖文件。
在一种可能的实施方式中,所述插桩模块具体用于:
将所述第一预设目录添加到目标插桩插件的处理路径中,并利用目标插桩插件及自动存储管理插件,对所述第一预设目录下的第一目标依赖文件进行插桩处理。
在一种可能的实施方式中,所述插桩模块还用于:
生成插桩管理文件;所述插桩管理文件中包含指示有软件开发包中的可更新范围的文件编号;
生成模块具体用于:
响应补丁生成指令,获取所述软件开发包的更新依赖文件;
根据所述插桩管理文件中指示的文件编号,确定所述更新依赖文件是否在可更新范围内;
若所述更新依赖文件在可更新范围内,则将所述第二预设目录添加到目标编译器的处理路径中,并利用目标编译器根据所述更新依赖文件对所述第一目标依赖文件和所述第二目标依赖文件进行更新,并对更新的第一目标依赖文件和第二目标依赖文件添加更新注解;
基于带有更新注解的所述第一目标依赖文件和第二目标依赖文件,生成所述软件开发包的数据更新补丁。
在一种可能的实施方式中,所述生成模块在利用目标编译器根据所述更新依赖文件对所述第一目标依赖文件和所述第二目标依赖文件进行更新,并对更新的第一目标依赖文件和第二目标依赖文件添加更新注解时,具体用于:
利用所述目标编译器及目标编译插件,将所述第一目标依赖文件及第二目标依赖文件中需要进行更新的无源依赖文件替换为所述更新依赖文件中对应的目标无源依赖文件,并对所述第一目标依赖文件及第二目标依赖文件中的目标无源依赖文件添加更新注解;
利用所述目标编译器,将所述第一目标依赖文件及第二目标依赖文件中需要进行更新的有源依赖文件替换为所述更新依赖文件中对应的目标有源依赖文件,并对所述第一目标依赖文件及第二目标依赖文件中的目标有源依赖文件添加更新注解。
在一种可能的实施方式中,所述装置还包括:
加密模块,用于利用预先与客户端约定的加密方式,对所述数据更新补丁加密。
在一种可能的实施方式中,所述装置还包括发送模块,所述发送模块用于:
当检测到客户端发送的更新请求时,验证所述更新请求携带的应用身份标识及软件开发包版本;
在验证通过后,将所述数据更新补丁发送至所述客户端。
第三方面,本公开实施例还提供一种计算机设备,包括:处理器、存储器和总线,所述存储器存储有所述处理器可执行的机器可读指令,当计算机设备运行时,所述处理器与所述存储器之间通过总线通信,所述机器可读指令被所述处理器执行时执行上述第一方面,或第一方面中任一种可能的实施方式中的步骤。
第四方面,本公开实施例还提供一种计算机可读存储介质,该计算机可读存储介质上存储有计算机程序,该计算机程序被处理器运行时执行上述第一方面,或第一方面中任一种可能的实施方式中的步骤。
关于上述软件开发包更新装置、计算机设备、及计算机可读存储介质的效果描述参见上述软件开发包更新方法的说明,这里不再赘述。
本公开实施例提供的软件开发包更新的方法及装置,首先在软件开发包的编译过程中,将第一目标依赖文件添加到第一预设目录;然后,对第一预设目录下的第一目标依赖文件进行插桩处理;最后,在所述软件开发包上线后,响应补丁生成指令,基于所述第一目标依赖文件以及第二预设目录下的第二目标依赖文件,生成所述软件开发包的数据更新补丁;所述数据更新补丁用于更新所述软件开发包。本申请直接通过SDK的编译方法生成数据更新补丁,能够直接使用不同版本的构建工具,不需要针对不同版本的构建工具单独进行设置,方便维护,并且不需要将APP编译生成的产物转换为SDK的产物,方便快捷,效率较高。
为使本公开的上述目的、特征和优点能更明显易懂,下文特举较佳实施例,并配合所附附图,作详细说明如下。
附图说明
为了更清楚地说明本公开实施例的技术方案,下面将对实施例中所需要使用的附图作简单地介绍,此处的附图被并入说明书中并构成本说明书中的一部分,这些附图示出了符合本公开的实施例,并与说明书一起用于说明本公开的技术方案。应当理解,以下附图仅示出了本公开的某些实施例,因此不应被看作是对范围的限定,对于本领域普通技术人员来讲,在不付出创造性劳动的前提下,还可以根据这些附图获得其他相关的附图。
图1示出了本公开实施例所提供的一种软件开发包更新方法的流程图;
图2示出了本公开实施例所提供的软件开发包更新方法中,生成软件开发包的数据更新补丁的具体方法的流程图;
图3示出了本公开实施例所提供的一种软件开发包更新装置的示意图;
图4示出了本公开实施例所提供的另一种软件开发包更新装置的示意图;
图5示出了本公开实施例所提供的一种计算机设备的示意图。
具体实施方式
为使本公开实施例的目的、技术方案和优点更加清楚,下面将结合本公开实施例中附图,对本公开实施例中的技术方案进行清楚、完整地描述,显然,所描述的实施例仅仅是本公开一部分实施例,而不是全部的实施例。通常在此处附图中描述和示出的本公开实施例的组件可以以各种不同的配置来布置和设计。因此,以下对在附图中提供的本公开的实施例的详细描述并非旨在限制要求保护的本公开的范围,而是仅仅表示本公开的选定实施例。基于本公开的实施例,本领域技术人员在没有做出创造性劳动的前提下所获得的所有其他实施例,都属于本公开保护的范围。
经研究发现,在现有的SDK热更新方法中,不能直接采用SDK编译的方法生成SDK的数据更新补丁,需要先将SDK的编译流程转换为APP的编译流程,进行编译,在编译完成后,将APP编译得到的编译产物再转换为SDK的数据更新补丁。上述方法的操作流程复杂,需要进行多次的转换,并且,不同版本的构建工具在进行APP编译时的配置不同,针对不同版本的构建工具需要额外的适配工作,难以维护,效率较低。
基于上述研究,本公开提供了一种软件开发包更新方法,直接通过SDK的编译方法生成数据更新补丁,能够直接使用不同版本的构建工具,不需要针对不同版本的构建工具单独进行设置,方便维护,并且不需要将APP编译生成的产物转换为SDK的产物,方便快捷,效率较高。
针对以上方案所存在的缺陷,均是发明人在经过实践并仔细研究后得出的结果,因此,上述问题的发现过程以及下文中本公开针对上述问题所提出的解决方案,都应该是发明人在本公开过程中对本公开做出的贡献。
下面将结合本公开中附图,对本公开中的技术方案进行清楚、完整地描述,显然,所描述的实施例仅仅是本公开一部分实施例,而不是全部的实施例。通常在此处附图中描述和示出的本公开的组件可以以各种不同的配置来布置和设计。因此,以下对在附图中提供的本公开的实施例的详细描述并非旨在限制要求保护的本公开的范围,而是仅仅表示本公开的选定实施例。基于本公开的实施例,本领域技术人员在没有做出创造性劳动的前提下所获得的所有其他实施例,都属于本公开保护的范围。
应注意到:相似的标号和字母在下面的附图中表示类似项,因此,一旦某一项在一个附图中被定义,则在随后的附图中不需要对其进行进一步定义和解释。
为便于对本实施例进行理解,首先对本公开实施例所公开的一种软件开发包更新方法进行详细介绍,本公开实施例所提供的软件开发包更新方法的执行主体一般为具有一定计算能力的计算机设备,该计算机设备例如包括:终端设备或服务器或其它处理设备,终端设备可以为用户设备(User Equipment,UE)、移动设备、用户终端、终端、蜂窝电话、无绳电话、个人数字处理(Personal Digital Assistant,PDA)、手持设备、计算设备、车载设备、可穿戴设备等。在一些可能的实现方式中,该软件开发包更新方法可以通过处理器调用存储器中存储的计算机可读指令的方式来实现。
下面以执行主体为终端设备为例对本公开实施例提供的软件开发包更新方法加以说明。
实施例一
首先,对本公开实施例一提供的软件开发包更新方法进行整体上的介绍。本公开实施例提供的软件开发包更新方法可以包括三个步骤,分别为预处理、插桩以及补丁包生成。其中,预处理步骤可以对第一目标依赖文件进行收敛处理,将其添加到第一预设目录中,使得第一目标依赖文件能够被插桩步骤使用的插件识别并对其进行处理;插桩步骤可以对第一依赖文件进行插桩处理,使被插桩的依赖文件需要进行热修复时,实现调用数据更新补丁中的逻辑,完成更新;补丁包生成的步骤能够通过插桩步骤生成的插桩后的第一依赖文件以及插桩管理文件,生成需要进行修复的依赖文件的数据更新补丁。在数据更新补丁生成之后,可以将数据更新补丁发布至线上,使需要更新的软件开发包获取到数据更新补丁,并进行热修复。
下面,对本公开实施例一提供的软件开发包更新方法进行详细的介绍。
参见图1所示,为本公开实施例一提供的软件开发包更新方法的流程图,所述方法包括步骤S101~S103,其中:
S101、在软件开发包的编译过程中,将第一目标依赖文件添加到第一预设目录。
这里,第一目标依赖文件为SDK的内部依赖文件,可以包括APP方的基础依赖文件(通常为aar或jar的形式),以及SDK所依赖的project类依赖文件(SDK开发方的依赖文件)。将第一目标依赖文件添加到第一预设目录中的目的是为了让第一目标依赖文件能够被进行插桩的插件识别到,并对其进行插桩处理。
该步骤中,在软件开发包的编译过程中,需要将可能需要热修复的代码,即第一目标依赖文件,通过transform操作进行收敛,将其添加到第一预设目录中。下面做具体说明。
软件开发包的编译过程中,需要先生成类文件,再从类文件转换为dex文件,dex文件是安卓系统中的一种文件,该文件格式能够被安卓系统识别、加载并执行;最后再基于dex文件生成apk文件。其中,transform操作的实质是使用gradle插件中的transform api(操作class的方式),在将软件开发包编译过程的类文件转成dex文件之前,通过自定义插件,进行类文件字节码处理。
具体的,可以确定出SDK的aar类依赖文件及project类依赖文件,即第一目标依赖文件,其中,arr类依赖文件是一个安卓项目库的二进制归档文件,包含类文件,文本文档;project类依赖文件指编译过程中各个工程的依赖文件。将第一目标依赖文件通过transform操作添加进Gradle中的资源配置(SourceSet)文件中,在SourceSet文件中,指示有哪些源文件或哪些文件夹下的源文件需要被编译,哪些源文件需要被排除。这样,构建工具gradle就可以基于SourceSet文件对第一目标依赖文件添加transform操作(也即上述进行类文件字节码处理),将其收入进一个jar包中,并添加到project_only的路径(第一预设目录)中,完成收敛步骤。
S102、对第一预设目录下的第一目标依赖文件进行插桩处理。
这里,插桩处理是指在每个第一目标依赖文件的代码中插入一段代码,示例性的,可以在代码的开头中插入,该代码用于在检测到被插桩的依赖文件需要进行热修复时,调用数据更新补丁中的逻辑,完成更新。
在一种可能的实施方式中,步骤S102包括:
将所述第一预设目录添加到目标插桩插件的处理路径中,并利用目标插桩插件及自动存储管理插件,对第一预设目录下的第一目标依赖文件进行插桩处理。
该步骤中,目标插桩插件可以为robust插件。
具体的,robust插件是插桩过程的基础应用,在通过robust插件进行插桩处理时,需要对代码的字节码进行遍历处理。为了实现插桩这一过程,可以使用管理依赖文件字节码的工具,比如自动储存管理插件(Automatic Storage Management,ASM)等,能够避免找不到类文件导致的插桩失败问题。
其中,自动存储管理插件是一个Java字节码操控框架,能被用来动态生成类,或者增强类的功能。也即,ASM可以直接产生类文件,也可以在类文件被加载入Java虚拟机之前,动态改变类文件。lancet插件是一个面向Android的轻量级面向切面编程(AspectOriented Programming,AOP)框架,用于进行编译。
这里,由于robust插件原本是用于APP热更新的插件,因此需要对其进行改造,需要将robust插件的scope参数修改为project_only,project_only即第一目标依赖文件所处的第一预设目录,其中,scope参数限制robust参数的使用范围,将scope参数修改为project_only后,robust插件可以对第一目标依赖文件进行插桩处理。
这样,在将robust插件的scope参数修改为project_only之后,robust插件才能够正确的识别出第一目标依赖文件,并对其进行插桩处理。
具体的,在将robust插件的scope参数修改为project_only后,可以对第一预设目录下的基础类以外的其他依赖文件进行插桩处理,由于robust插件的运行是基于基础类依赖文件的,因此不对基础类依赖文件进行插桩。
在一种可能的实施方式中,对第一预设目录下的第一目标依赖文件进行插桩处理之后,还包括:
生成插桩管理文件;所述插桩管理文件中包含指示有软件开发包中的可更新范围的文件编号;
在插桩结束后,robust插件可以生成插桩管理文件,并将插桩管理文件上传至服务器。所述插桩管理文件可以包括所述软件开发包的混淆文件及插桩映射文件。
其中,插桩管理文件包括该SDK的混淆文件mapping,用于记录SDK的混淆规则,该文件列出了原始的类,方法和字段名与混淆后代码间的映射,基于该混淆文件,可以翻译被混淆的代码。但该混淆文件不是必须的,如果不需要混淆,可以不保留。插桩映射文件methodMap.robust,用于给已经得到插桩处理的依赖文件编号,该文件在生成数据更新补丁的时候用来区别到底哪些方法需要被修复,所以有它才能生成数据更新补丁。
S103、响应补丁生成指令,基于所述第一目标依赖文件、所述插桩管理文件,以及第二预设目录下的第二目标依赖文件,生成所述软件开发包的数据更新补丁;所述数据更新补丁用于更新所述软件开发包。
该步骤中,在检测到SDK中需要更新的依赖文件后,可以生成补丁生成指令,补丁生成指令中指示有需要更新的依赖文件,可以利用robust插件,根据补丁生成指令及插桩管理文件,从插桩后的第一目标依赖文件及第二预设目录下的第二目标依赖文件中筛选出需要更新的依赖文件,并生成数据更新补丁。
其中,第二目标依赖文件为SDK的外部依赖,第二预设目录为外部依赖储存的目录由于在project_only路径下只有第一目标依赖文件的内部依赖文件,因此需要将robust插件的referenced Input参数设置为上述第二预设目录,这样,对于外部依赖文件和内部依赖文件,都可以生成数据更新补丁。其中,referenced Input参数用于指示robust插件的参考依赖文件的路径,这样,robust插件才能够调用第二目标依赖文件。
请参阅图2,图2为本申请实施例所提供的软件开发包更新方法中,生成软件开发包的数据更新补丁的具体方法的流程图。如图2所示,步骤S103包括:
S201、响应补丁生成指令,获取所述软件开发包的更新依赖文件。
该步骤中,在检测到补丁生成指令后,可以获取用户输入的软件开发包的更新依赖文件,其中,更新依赖文件是需要进行更新的依赖文件的更新版本,该更新依赖文件可以是维护人员根据软件开发包上线后用户或运行结果的反馈开发的,具体地,维护人员根据用户或软件运行结果的反馈,确定出需要进行更新的依赖文件,并根据需要更新的内容生成更新依赖文件。
S202、根据所述插桩管理文件中指示的文件编号,确定所述更新依赖文件是否在可更新范围内。
在获取到软件开发包的更新依赖文件后,可以遍历插桩管理文件中指示的文件编号,确定更新依赖文件中的软件开发包的内部依赖文件是否在插桩管理文件指示的文件编号中出现,若出现,则可以确定更新依赖文件在可更新范围内。
S203、若所述更新依赖文件在可更新范围内,则将所述第二预设目录添加到目标编译器的处理路径中,并利用目标编译器根据所述更新依赖文件对所述第一目标依赖文件和所述第二目标依赖文件进行更新,并对更新的第一目标依赖文件和第二目标依赖文件添加更新注解。
其中,目标编译器可以是Javassist编译器(Java Programming Assistant,Java编程助手),Javassist是一个开源的分析、编辑和创建Java字节码的类库,Javassist编译器通过编辑java字节码的类库,使java程序在运行时定义一个新类,并在java虚拟机加载时修改类文件(class),可以和robust插件共同使用,上述依赖文件也属于类文件。
这里,目标编译器是基于robust插件运行的,具体的,robust插件可以调用Javassist编译器。
具体的,可以将第二预设目录添加到javassist的classpath中。这里,classpath为javassist要处理的类文件的路径。
该步骤中,在将第二预设目录添加至目标编译器的处理路径后,可以利用javassist编译器,根据更新依赖文件对第一目标依赖文件及第二目标依赖文件进行更新,并对更新的第一目标依赖文件及第二目标依赖文件添加更新注解。更新注解用于标注需要更新的依赖文件。
在一种可能的实施方式中,步骤S203可以包括:
利用所述目标编译器及目标编译插件,将所述第一目标依赖文件及第二目标依赖文件中需要进行更新的无源依赖文件替换为所述更新依赖文件中对应的目标无源依赖文件,并对所述第一目标依赖文件及第二目标依赖文件中的目标无源依赖文件添加更新注解;
利用所述目标编译器,将所述第一目标依赖文件及第二目标依赖文件中需要进行更新的有源依赖文件替换为所述更新依赖文件中对应的目标有源依赖文件,并对所述第一目标依赖文件及第二目标依赖文件中的目标有源依赖文件添加更新注解。
该步骤中,可以利用robust插件中的目标编译器及目标编译插件,将补丁生成指令中指示的需要更新的无源依赖文件,替换为更新依赖文件中对应的目标无源依赖文件,并对更新的目标有源依赖文件添加更新注解,将有更新的依赖文件标注出来;同时,可以利用robust插件中的目标编译器将补丁生成指令中指示的需要更新的有源依赖文件,替换为更新依赖文件中对应的目标有源依赖文件,并对更新的目标有源依赖文件添加更新注解。
其中,目标编译插件同样可以是由robust插件调用使用的。由于无源依赖文件是由第三方提供的,无法直接对无源依赖文件的代码进行修改,因此,需要借助目标编译插件来对其进行修改。
在一些可能的实施方式中,目标编译插件可以包括lancet插件及自动存储管理插件。
具体的,可以利用lancet插件及ASM插件为确定的目标无源更新依赖文件中,新生成的类文件添加“@Add”注解,表示该类文件是新增的,被修改的类文件添加“@Modify”注解,表示该类文件是被修改的。
S204、基于带有更新注解的所述第一目标依赖文件和第二目标依赖文件,生成所述软件开发包的数据更新补丁。
该步骤中,可以将带有更新注解的第一目标依赖文件和第二目标依赖文件打包,生成软件开发包的数据更新补丁。生成数据更新补丁之后,可以将其发送至客户端,客户端利用数据更新补丁对自身的SDK进行更新。
另外,在一些可能的实施方式中,在生成所述软件开发包的数据更新补丁之后,所述方法还包括:
利用预先与客户端约定的加密方式,对所述数据更新补丁加密。
这样,可以防止数据更新补丁被拦截或利用,增强数据更新的安全性。
再者,在一些可能的实施方式中,所述方法还包括:
当检测到客户端发送的更新请求时,验证所述更新请求携带的应用身份标识及软件开发包版本;
在验证通过后,将所述数据更新补丁发送至所述客户端。
这样,只有在应用身份标识及软件开发包版本匹配时才下发数据更新补丁,能够提高软件开发包热更新的安全性和稳定性。
本领域技术人员可以理解,在具体实施方式的上述方法中,各步骤的撰写顺序并不意味着严格的执行顺序而对实施过程构成任何限定,各步骤的具体执行顺序应当以其功能和可能的内在逻辑确定。
基于同一发明构思,本公开实施例中还提供了与软件开发包更新方法对应的软件开发包更新装置,由于本公开实施例中的装置解决问题的原理与本公开实施例上述软件开发包更新方法相似,因此装置的实施可以参见方法的实施,重复之处不再赘述。
实施例二
参照图3所示,为本公开实施例二提供的一种软件开发包更新装置的示意图,所述软件开发包更新装置300包括:
添加模块310,用于在软件开发包的编译过程中,将第一目标依赖文件添加到第一预设目录;
插桩模块320,用于对第一预设目录下的第一目标依赖文件进行插桩处理;
生成模块330,用于在软件开发包上线后,响应补丁生成指令,基于所述第一目标依赖文件以及第二预设目录下的第二目标依赖文件,生成所述软件开发包的数据更新补丁;所述数据更新补丁用于更新所述软件开发包。
在一种可能的实施方式中,所述第一目标依赖文件为所述软件开发包的内部依赖文件;所述第二目标依赖文件为所述软件开发包的外部依赖文件。
在一种可能的实施方式中,所述插桩模块320具体用于:
将所述第一预设目录添加到目标插桩插件的处理路径中,并利用目标插桩插件及自动存储管理插件,对所述第一预设目录下的第一目标依赖文件进行插桩处理。
在一种可能的实施方式中,所述插桩模块320还用于:
生成插桩管理文件;所述插桩管理文件中包含指示有软件开发包中的可更新范围的文件编号;
生成模块330具体用于:
响应补丁生成指令,获取所述软件开发包的更新依赖文件;
根据所述插桩管理文件中指示的文件编号,确定所述更新依赖文件是否在可更新范围内;
若所述更新依赖文件在可更新范围内,则将所述第二预设目录添加到目标编译器的处理路径中,并利用目标编译器根据所述更新依赖文件对所述第一目标依赖文件和所述第二目标依赖文件进行更新,并对更新的第一目标依赖文件和第二目标依赖文件添加更新注解;
基于带有更新注解的所述第一目标依赖文件和第二目标依赖文件,生成所述软件开发包的数据更新补丁。
在一种可能的实施方式中,所述生成模块330在利用目标编译器根据所述更新依赖文件对所述第一目标依赖文件和所述第二目标依赖文件进行更新,并对更新的第一目标依赖文件和第二目标依赖文件添加更新注解时,具体用于:
利用所述目标编译器及目标编译插件,将所述第一目标依赖文件及第二目标依赖文件中需要进行更新的无源依赖文件替换为所述更新依赖文件中对应的目标无源依赖文件,并对所述第一目标依赖文件及第二目标依赖文件中的目标无源依赖文件添加更新注解;
利用所述目标编译器,将所述第一目标依赖文件及第二目标依赖文件中需要进行更新的有源依赖文件替换为所述更新依赖文件中对应的目标有源依赖文件,并对所述第一目标依赖文件及第二目标依赖文件中的目标有源依赖文件添加更新注解。
参照图4所示,为本公开实施例二提供的另一种软件开发包更新装置的示意图,所述软件开发包更新装置300包括添加模块410、插桩模块420生成模块430及加密模块440,其中,
加密模块440,用于利用预先与客户端约定的加密方式,对所述数据更新补丁加密。
在一种可能的实施方式中,所述软件开发包更新装置400还包括发送模块450,所述发送模块450用于:
当检测到客户端发送的更新请求时,验证所述更新请求携带的应用身份标识及软件开发包版本;
在验证通过后,将所述数据更新补丁发送至所述客户端。
关于装置中的各模块的处理流程、以及各模块之间的交互流程的描述可以参照上述方法实施例中的相关说明,这里不再详述。
实施例三
基于同一技术构思,本申请实施例还提供了一种计算机设备。参照图5所示,为本申请实施例提供的计算机设备500的结构示意图,包括处理器501、存储器502、和总线503。其中,存储器502用于存储执行指令,包括内存5021和外部存储器5022;这里的内存5021也称内存储器,用于暂时存放处理器501中的运算数据,以及与硬盘等外部存储器5022交换的数据,处理器501通过内存5021与外部存储器5022进行数据交换,当计算机设备500运行时,处理器501与存储器502之间通过总线503通信,使得处理器501在执行以下指令:
在软件开发包的编译过程中,将第一目标依赖文件添加到第一预设目录;
对第一预设目录下的第一目标依赖文件进行插桩处理;
响应补丁生成指令,基于所述第一目标依赖文件以及第二预设目录下的第二目标依赖文件,生成所述软件开发包的数据更新补丁;所述数据更新补丁用于更新所述软件开发包。
一种可能的实施方式中,处理器501执行的指令中,所述第一目标依赖文件为所述软件开发包的内部依赖文件;所述第二目标依赖文件为所述软件开发包的外部依赖文件。
一种可能的实施方式中,处理器501执行的指令中,所述对第一预设目录下的第一目标依赖文件进行插桩处理,包括:
将所述第一预设目录添加到目标插桩插件的处理路径中,并利用目标插桩插件及自动存储管理插件,对所述第一预设目录下的第一目标依赖文件进行插桩处理。
一种可能的实施方式中,处理器501执行的指令中,
对第一预设目录下的第一目标依赖文件进行插桩处理之后,还包括:
生成插桩管理文件;所述插桩管理文件中包含指示有软件开发包中的可更新范围的文件编号;
所述基于所述第一目标依赖文件以及第二预设目录下的第二目标依赖文件,生成所述软件开发包的数据更新补丁,包括:
响应补丁生成指令,获取所述软件开发包的更新依赖文件;
根据所述插桩管理文件中指示的文件编号,确定所述更新依赖文件是否在可更新范围内;
若所述更新依赖文件在可更新范围内,则将所述第二预设目录添加到目标编译器的处理路径中,并利用目标编译器根据所述更新依赖文件对所述第一目标依赖文件和所述第二目标依赖文件进行更新,并对更新的第一目标依赖文件和第二目标依赖文件添加更新注解;
基于带有更新注解的所述第一目标依赖文件和第二目标依赖文件,生成所述软件开发包的数据更新补丁。
在一种可能的实施方式中,处理器501执行的指令中,所述利用目标编译器根据所述更新依赖文件对所述第一目标依赖文件和所述第二目标依赖文件进行更新,并对更新的第一目标依赖文件和第二目标依赖文件添加更新注解,包括:
利用所述目标编译器及目标编译插件,将所述第一目标依赖文件及第二目标依赖文件中需要进行更新的无源依赖文件替换为所述更新依赖文件中对应的目标无源依赖文件,并对所述第一目标依赖文件及第二目标依赖文件中的目标无源依赖文件添加更新注解;
利用所述目标编译器,将所述第一目标依赖文件及第二目标依赖文件中需要进行更新的有源依赖文件替换为所述更新依赖文件中对应的目标有源依赖文件,并对所述第一目标依赖文件及第二目标依赖文件中的目标有源依赖文件添加更新注解。
一种可能的实施方式中,处理器501还执行:
利用预先与客户端约定的加密方式,对所述数据更新补丁加密。
一种可能的实施方式中,处理器501还执行:
当检测到客户端发送的更新请求时,验证所述更新请求携带的应用身份标识及软件开发包版本;
在验证通过后,将所述数据更新补丁发送至所述客户端。
本公开实施例还提供一种计算机可读存储介质,该计算机可读存储介质上存储有计算机程序,该计算机程序被处理器运行时执行上述方法实施例中所述的软件开发包更新方法的步骤。其中,该存储介质可以是易失性或非易失的计算机可读取存储介质。
本公开实施例所提供的软件开发包更新方法的计算机程序产品,包括存储了程序代码的计算机可读存储介质,所述程序代码包括的指令可用于执行上述方法实施例中所述的软件开发包更新方法的步骤,具体可参见上述方法实施例,在此不再赘述。
本公开实施例还提供一种计算机程序,该计算机程序被处理器执行时实现前述实施例的任意一种方法。该计算机程序产品可以具体通过硬件、软件或其结合的方式实现。在一个可选实施例中,所述计算机程序产品具体体现为计算机存储介质,在另一个可选实施例中,计算机程序产品具体体现为软件产品,例如软件开发包(Software DevelopmentKit,SDK)等等。
所属领域的技术人员可以清楚地了解到,为描述的方便和简洁,上述描述的系统和装置的具体工作过程,可以参考前述方法实施例中的对应过程,在此不再赘述。在本公开所提供的几个实施例中,应该理解到,所揭露的系统、装置和方法,可以通过其它的方式实现。以上所描述的装置实施例仅仅是示意性的,例如,所述单元的划分,仅仅为一种逻辑功能划分,实际实现时可以有另外的划分方式,又例如,多个单元或组件可以结合或者可以集成到另一个系统,或一些特征可以忽略,或不执行。另一点,所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些通信接口,装置或单元的间接耦合或通信连接,可以是电性,机械或其它的形式。
所述作为分离部件说明的单元可以是或者也可以不是物理上分开的,作为单元显示的部件可以是或者也可以不是物理单元,即可以位于一个地方,或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。
另外,在本公开各个实施例中的各功能单元可以集成在一个处理单元中,也可以是各个单元单独物理存在,也可以两个或两个以上单元集成在一个单元中。
所述功能如果以软件功能单元的形式实现并作为独立的产品销售或使用时,可以存储在一个处理器可执行的非易失的计算机可读取存储介质中。基于这样的理解,本公开的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的部分可以以软件产品的形式体现出来,该计算机软件产品存储在一个存储介质中,包括若干指令用以使得一台计算机设备(可以是个人计算机,服务器,或者网络设备等)执行本公开各个实施例所述方法的全部或部分步骤。而前述的存储介质包括:U盘、移动硬盘、只读存储器(Read-OnlyMemory,ROM)、随机存取存储器(Random Access Memory,RAM)、磁碟或者光盘等各种可以存储程序代码的介质。
最后应说明的是:以上所述实施例,仅为本公开的具体实施方式,用以说明本公开的技术方案,而非对其限制,本公开的保护范围并不局限于此,尽管参照前述实施例对本公开进行了详细的说明,本领域的普通技术人员应当理解:任何熟悉本技术领域的技术人员在本公开揭露的技术范围内,其依然可以对前述实施例所记载的技术方案进行修改或可轻易想到变化,或者对其中部分技术特征进行等同替换;而这些修改、变化或者替换,并不使相应技术方案的本质脱离本公开实施例技术方案的精神和范围,都应涵盖在本公开的保护范围之内。因此,本公开的保护范围应所述以权利要求的保护范围为准。