CN116775087A - 一种热修复方法、装置、电子设备及存储介质 - Google Patents

Abstract

本公开提供了一种热修复方法、装置、电子设备及存储介质，该方法为，确定所述应用程序的当前运行架构类型；根据所述当前运行架构类型和所述应用程序的当前目标修复对象，确定所述应用程序的当前编译工具类型；基于所述当前运行架构类型和所述当前编译工具类型，获得所述应用程序的待修复SDK的目标补丁包，其中，所述目标补丁包是与所述当前运行架构类型和所述当前编译工具类型关联的补丁包，所述目标补丁包中至少包括所述待修复SDK中热修复的目标修复对象的补丁包，这样，可以降低SDK的目标补丁包的大小。

Description

一种热修复方法、装置、电子设备及存储介质

技术领域

本公开涉及计算机技术领域，具体而言，涉及一种热修复方法、装置、电子设备及存储介质。

背景技术

热修复技术是一种快速高效的应用程序修复方式，可以对已安装的应用程序使用补丁进行修复，应用程序的热修复包括so库热修复，相关技术中，so库热修复的补丁包大小的优化方法，主要是采用通过新旧版本进行差分比对的方式，并且主要是针对应用程序(Application，APP)级别的，针对应用程序中软件开发工具包(Software DevelopmentKit，SDK)级别的热修复方法还比较少，由于SDK与APP不同，SDK仅是APP的一种功能包，SDK的补丁包还需要加载到APP中再编译使用，简单的差分对比并不能有效缩减SDK补丁包，增加了内存占用，降低了效率。

发明内容

本公开实施例至少提供一种热修复方法、装置、电子设备及存储介质。

第一方面，本公开实施例提供了一种热修复方法，包括：

确定所述应用程序的当前运行架构类型；

根据所述当前运行架构类型和所述应用程序的当前目标修复对象，确定所述应用程序的当前编译工具类型；

基于所述当前运行架构类型和所述当前编译工具类型，获得所述应用程序的待修复SDK的目标补丁包，其中，所述目标补丁包是与所述当前运行架构类型和所述当前编译工具类型关联的补丁包，所述目标补丁包中至少包括所述待修复SDK中热修复的目标修复对象的补丁包。

第二方面，本公开实施例还提供一种热修复装置，包括：

第一确定模块，用于确定所述应用程序的当前运行架构类型；

第二确定模块，用于根据所述当前运行架构类型和所述应用程序的当前目标修复对象，确定所述应用程序的当前编译工具类型；

获得模块，用于基于所述当前运行架构类型和所述当前编译工具类型，获得所述应用程序的待修复软件开发功能包SDK的目标补丁包，其中，所述目标补丁包是与所述当前运行架构类型和所述当前编译工具类型关联的补丁包，所述目标补丁包中至少包括所述待修复SDK中热修复的目标修复对象的补丁包。

第三方面，本公开可选实现方式还提供一种电子设备，包括处理器、存储器，所述存储器存储有所述处理器可执行的机器可读指令，所述处理器用于执行所述存储器中存储的机器可读指令，所述机器可读指令被所述处理器执行时，所述处理器执行上述第一方面，或第一方面中任一种可能的实施方式中的步骤。

第四方面，本公开可选实现方式还提供一种计算机可读存储介质，其上存储有计算机程序，所述计算机程序被处理器执行时实现上述第一方面，或第一方面中任一种可能的实施方式中的步骤。

本公开实施例中，确定所述应用程序的当前运行架构类型；根据所述当前运行架构类型和所述应用程序的当前目标修复对象，确定所述应用程序的当前编译工具类型；基于所述当前运行架构类型和所述当前编译工具类型，获得所述应用程序的待修复SDK的目标补丁包，其中，所述目标补丁包是与所述当前运行架构类型和所述当前编译工具类型关联的补丁包，所述目标补丁包中至少包括所述待修复SDK中热修复的目标修复对象的补丁包，这样，基于不同运行架构类型和不同编译工具类型而生成不同的补丁包，降低补丁包的大小，从而在运行应用程序时，确定出当前运行架构类型和当前编译工具类型，可以仅下载当前运行架构类型和当前编译工具类型所对应的目标补丁包，优化了热修复补丁包的大小，实现了针对SDK的有效的降低补丁包大小的方案，从而下载的目标补丁包缩减了，还可以提升补丁包的触发率，使得用户能够尽快应用补丁包，提升用户体验。

关于上述热修复装置、电子设备、及计算机可读存储介质的效果描述参见上述热修复方法的说明，这里不再赘述。

应当理解的是，以上的一般描述和后文的细节描述仅是示例性和解释性的，而非限制本公开的技术方案。

为使本公开的上述目的、特征和优点能更明显易懂，下文特举较佳实施例，并配合所附附图，作详细说明如下。

附图说明

为了更清楚地说明本公开实施例的技术方案，下面将对实施例中所需要使用的附图作简单地介绍，此处的附图被并入说明书中并构成本说明书中的一部分，这些附图示出了符合本公开的实施例，并与说明书一起用于说明本公开的技术方案。应当理解，以下附图仅示出了本公开的某些实施例，因此不应被看作是对范围的限定，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他相关的附图。

图1示出了本公开实施例所提供的热修复整体方案流程图；

图2示出了本公开实施例所提供的一种热修复方法的流程图；

图3示出了本公开实施例所提供的探针方法实现原理示意图；

图4示出了本公开实施例所提供的另一种热修复方法的流程图；

图5示出了本公开实施例所提供的一种热修复装置的结构示意图；

图6示出了本公开实施例所提供的一种电子设备的示意图。

具体实施方式

可以理解的是，在使用本公开各实施例公开的技术方案之前，均应当依据相关法律法规通过恰当的方式对本公开所涉及个人信息的类型、使用范围、使用场景等告知用户并获得用户的授权。

为使本公开实施例的目的、技术方案和优点更加清楚，下面将结合本公开实施例中附图，对本公开实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本公开一部分实施例，而不是全部的实施例。通常在此处描述和示出的本公开实施例的组件可以以各种不同的配置来布置和设计。因此，以下对本公开的实施例的详细描述并非旨在限制要求保护的本公开的范围，而是仅仅表示本公开的选定实施例。基于本公开的实施例，本领域技术人员在没有做出创造性劳动的前提下所获得的所有其他实施例，都属于本公开保护的范围。

为便于对本公开技术方案的理解，首先对本公开实施例中的技术用语加以说明：

热修复：热修复是一种快速高效的修复应用程序(Application，App)缺陷或漏洞的方式，其不依赖于应用程序的版本更新来对应用程序的漏洞进行修复，可以理解为一种打补丁的方式，可以在用户无感知情况下对已安装的应用程序使用补丁进行修复，通常热修复包括类热修复、资源热修复和so热修复。

so热修复：so文件表示动态链接库，so库的修复本质是对native方法的修复和替换，和类加载方案类似，可以把补丁so库的路径插入到nativeLibraryDirectories数组的最前面，使得可以优先加载补丁so库而非原来so库以来达到修复目的。

应用程序二进制接口(Application Binary Interface，ABI)：其定义了二进制文件(尤其是.so文件)如何运行在相应的系统平台上，例如包括从使用的指令集、内存对齐、可用的系统函数库等，在终端设备中，不同终端设备使用不同CPU架构，而不同的CPU支持不同的指令集，CPU与指令集的每种组合都有专属的ABI，通常CPU可以支持一种或多种ABI，当一个应用程序安装在终端设备中时，只有该终端设备支持的CPU架构对应的.so文件会被安装。

缩减(strip)处理：可以对可执行二进制程序和对象文件中，删除不必要的信息，从而带来更好的性能和减少磁盘空间的使用，其中，不必要的信息指的是正常执行功能过程中，不需要的二进制信息，例如调试和符号信息等，例如，本公开实施例中，在编译过程中，通常会对so进行strip处理，以缩减不必要的信息。

经研究发现，相关技术中，so库热修复方法主要是针对APP级别的，APP中包括多种功能的软件开发工具包(Software Development Kit，SDK)，APP依赖SDK可以快捷地实现一定功能，若需针对某功能进行修复，由于APP发版周期长等特征，会降低效率，因此针对SDK中的so热修复是非常必要的，而目前针对SDK级别的热修复方案还比较少。

并且，相关技术中，so库热修复的补丁包大小的优化方法，主要是采用通过新旧版本进行差分比对的方式，该方式比较适用于针对APP级别的，但是SDK和APP不同，简单的差分对比并不能有效缩减SDK补丁包，例如，SDK中的so可能和最终该SDK接入APP中的so不一样，这是因为，对于APP来说，编译生成安卓安装包(Android Package，APK)之后，其so就确定了，不会再变化了，而对于SDK来说，SDK编译时会对so进行编译处理，但是编译后的SDK还需要被集成到APP中进行再次编译，这时会再使用APP的编译工具对SDK中so再次进行编译处理，从而使得SDK中的so和APK中的so不一样，进而由于SDK中旧版本的so不确定，因此无法使用差分方式来缩减补丁包大小。又例如，目前CPU ABI架构类型有多种，实际应用时终端设备只需择一使用即可，但是SDK并不确定所应用的终端设备采用的是哪种CPU ABI架构类型，因此SDK中需要考虑所有可能的CPU ABI架构类型，都会放到SDK补丁包中，增加了SDK补丁包大小。

基于上述研究，本公开提供了一种热修复方法，确定应用程序的当前运行架构类型；根据当前运行架构类型和应用程序的当前目标修复对象，确定应用程序的当前编译工具类型，从而基于当前运行架构类型和当前编译工具类型，获得应用程序的待修复SDK的目标补丁包，其中，目标补丁包是与当前运行架构类型和当前编译工具类型关联的补丁包，这样，识别应用程序运行的当前运行架构类型和当前编译工具类型，从而可以只下载该当前运行架构类型和当前编译工具类型对应的目标补丁包，从而能够针对SDK，有效降低SDK补丁包的大小。

针对以上方案所存在的缺陷，均是发明人在经过实践并仔细研究后得出的结果，因此，上述问题的发现过程以及下文中本公开针对上述问题所提出的解决方案，都应该是发明人在本公开过程中对本公开做出的贡献。

应注意到：相似的标号和字母在下面的附图中表示类似项，因此，一旦某一项在一个附图中被定义，则在随后的附图中不需要对其进行进一步定义和解释。

为便于对本实施例进行理解，下面从补丁开发到最终补丁包在终端生效，对热修复方案的整体进行简单说明。参阅图1所示，为本公开实施例中热修复整体方案流程。

如图1所示，整体方案流程主要可以包括四部分，分别为SDK开发过程、补丁包生成过程、补丁包投放过程和补丁包生效过程。具体地，1)SDK开发过程。在该阶段主要为：编译待修复SDK，具体包括：为SDK中可能需要修复的方法插桩，留出一个修复接口；对被插桩的方法记录管理信息，便于后续补丁包(patch)生效时校验是否作用于正确的方法。2)补丁包生成过程。该阶段主要为，编译并生成补丁包，具体包括：对待修复方法和需要添加的方法加注解，用于标注需要修复的地方；遍历待修复方法，收集patch生效时所需的额外信息，例如方法是否抛出异常等，并将其中的语句翻译成线上可识别的方法；添加单个patch的patch管理类，结合patch自身的类，最终打包生成patch。3)补丁包投放过程。该阶段主要为服务器端补丁包投放，具体包括：根据patch预期的生效需求，配置该patch对应的特征；将patch上传到服务器统一管理，以供客户端请求下载。4)补丁包生效过程。该阶段主要为客户端运行时补丁包生效，具体包括：运行时从客户端提取SDK特征，从服务器端拉取信息，下载各个SDK对应的patch；将所有的patch进行合并，方便patch的管理与加载；根据patch的服务器配置特征以及每个patch的管理类，决定patch如何生效。

其中，可以理解SDK开发过程和补丁包生成过程，主要面向开发人员，可以在开发人员所使用的第一终端设备中执行，进而生成补丁包后，开发人员可以将补丁包上传到服务器，即补丁包投放过程可以是通过第一终端设备将补丁包上传到服务器以进行存储，而补丁包生效过程，主要面向所有使用人员，可以在该使用人员的第二终端设备中执行，第二终端设备可以从服务器中下载补丁包，以在第二终端设备中加载生效，实现对应用程序中SDK进行修复。

基于上述实施例，本公开实施例中的热修复方法，主要针对上述补丁包生成过程、补丁包投放过程和补丁包生效过程而进行优化改进，下面对本公开实施例所公开的一种热修复方法进行详细介绍，本公开实施例所提供的热修复方法的执行主体一般为具有一定计算能力的电子设备，该电子设备例如包括：终端设备或服务器或其它处理设备，终端设备可以为用户设备(User Equipment，UE)、移动设备、蜂窝电话、无绳电话、个人数字助理(Personal Digital Assistant，PDA)、手持设备、计算设备、车载设备、可穿戴设备等，其中，个人数字助理是一种手持式电子设备，具有电子计算机的某些功能，可以用来管理个人信息，也可以上网浏览，收发电子邮件等，一般不配备键盘，也可以称为掌上电脑。在一些可能的实现方式中，该热修复方法可以通过处理器调用存储器中存储的计算机可读指令的方式来实现。

下面以执行主体为终端设备为例对本公开实施例提供的热修复方法加以说明。并且本公开实施例中热修复可以适用于基于任意运行平台的终端设备，为便于描述，本公开实施例中以安卓(Android)平台为例进行说明。

参见图2所示，为本公开实施例提供的一种热修复方法的流程图，该方法包括：

S201：确定应用程序的当前运行架构类型。

本公开实施例中，运行架构类型例如CPU ABI架构类型，目前CPU ABI架构类型有多种，例如包括x86，x86_64，armeabi-v7a、arm64-v8a等，而终端设备中运行应用程序时只需使用其中一种，因此本公开实施例中，可以确定出应用程序运行的当前运行架构类型。

具体本公开实施例中，提供了一种可能的实施方式，确定应用程序的当前运行架构类型，包括：通过应用程序中预设的探针方法，获得应用程序的当前运行架构类型，预设的探针方法用于实现返回当前运行架构类型的功能。

也就是说，本公开实施例中可以定义一种探针方法，将该探针方法可以预埋在应用程序的APK中，这样在运行应用程序时，可以基于该探针方法来获取当前运行架构类型，例如参阅图3所示，为本公开实施例中探针方法实现原理示意图。

如图3所示，定义的探针为libfrankie_sh_util.so，探针本质上也可以理解为一种so，运行应用程序时先加载该探针，基于不同运行架构类型，可以分别生成x86/libfrankie_sh_util.so、x86_64/libfrankie_sh_util.so、armeabi-v7a/libfrankie_sh_util.so和arm64-v8a/libfrankie_sh_util.so，则可以对基于运行架构类型生成后的探针进行识别，例如，针对x86/libfrankie_sh_util.so，可以返回当前运行架构类型为x86，针对x86_64/libfrankie_sh_util.so，可以返回当前运行架构类型为x86_64，针对armeabi-v7a/libfrankie_sh_util.so，可以返回当前运行架构类型为armeabi-v7a，针对arm64-v8a/libfrankie_sh_util.so，可以返回当前运行架构类型为arm64-v8a。

本公开实施例中，通过探针方法确定当前运行架构类型的方式，适用场景更多，对于普通终端设备、游戏模拟器等都可以适用，游戏模拟器通常会对系统架构进行魔改，兼容性问题比较多，基于探针方法可以准确地确定出应用程序运行的当前运行架构类型。

另外还可以采用相关技术中其它方式，来确定当前运行架构类型，本公开实施例中并不进行限制。

S202：根据当前运行架构类型和应用程序的当前目标修复对象，确定应用程序的当前编译工具类型。

本公开实施例中，基于不同编译工具环境进行编译时，会进行strip处理，不同编译工具所执行的strip操作是不同的，这里的编译工具类型可以表示为不同的strip类型。

具体执行该步骤S202时，本公开提供了一种可能的实施方式，包括：

1)根据当前运行架构类型，向服务器请求获得类型描述信息中当前运行架构类型对应的各候选编译目标修复对象。

其中，服务器中存储有待修复SDK的当前版本的类型描述信息，类型描述信息中包括各运行架构类型和各编译工具类型下对应的候选编译目标修复对象。

本公开实施例中，在生成补丁包阶段，会针对待修复SDK的当前版本，基于不同的编译工具类型的编译工具再分别进行编译，并结合不同的运行架构类型，记录不同运行架构类型和不同编译工具类型下所对应的候选编译目标修复对象，即获得待修复SDK当前版本对应的类型描述信息。

进而本公开实施例中，可以基于当前运行架构类型，向服务器发送类型描述信息请求，基于类型描述信息中包括的内容，找到该当前运行架构类型对应的各个候选编译目标修复对象。

2)获取应用程序运行时的当前目标修复对象，并确定当前目标修复对象的当前标识信息。

其中，该当前目标修复对象例如可以为任意一个需修复的a.so，计算a.so的当前标识信息，例如为a.so的md5值。

3)根据当前标识信息和获得的各候选编译目标修复对象，确定当前目标修复对象对应的第一候选编译目标修复对象。

其中，获得的各候选编译目标修复对象，即为该a.so对应在不同运行架构类型和不同编译工具类型下处理后的a.so，同样地，分别计算各候选编译目标修复对象的md5值，从而将当前目标修复对象的md5值和各候选编译目标修复对象的md5值进行比对，确定出md5相同的候选编译目标修复，即称为第一候选编译目标修复对象。

4)根据第一候选编译目标修复对象对应的编译工具类型，确定当前目标修复对象的编译工具类型，并将当前目标修复对象的编译工具类型，确定为应用程序的当前编译工具类型。

由于该第一候选编译目标修复对象也是针对a.so，基于当前运行架构类型和某编译工具类型的编译工具进行处理后得到的，当前目标修复对象和第一候选编译目标修复对象的md5相同，则可以确定该当前目标修复对象也是采用该某编译工具类型的编译工具进行处理的，因此可以将第一候选编译目标修复对象对应的编译工具类型，确定为应用程序的当前编译工具类型。

进一步地，若比对后，当前目标修复对象和各候选编译目标修复对象均不一致，则可以认为未确定出当前编译工具类型是什么，另外还可以将当前编译工具类型标识为未知，对此本公开实施例中并不进行限制。

S203：基于当前运行架构类型和当前编译工具类型，获得应用程序的待修复SDK的目标补丁包，其中，目标补丁包是与当前运行架构类型和当前编译工具类型关联的补丁包，目标补丁包中至少包括待修复SDK中热修复的目标修复对象的补丁包。

其中，目标差分补丁包是服务器根据当前运行架构类型和当前编译工具类型，从待修复SDK对应的各候选差分补丁包中确定的。

本公开实施例中，在服务器存储有针对待修复SDK的多个候选差分补丁包，这些候选差分补丁包，是基于不同运行架构类型和不同编译工具类型的当前版本的待修复SDK，与更新版本的SDK进行差分处理后而获得的，这样，由于各个候选差分补丁包都是仅对应一种运行架构类型和一种编译工具类型，因此可以进行差分处理，并且生成的候选差分补丁包不需要包括所有的运行架构类型，从而可以降低各个候选差分补丁包的大小。

进而确定出当前运行架构类型和当前编译工具类型后，可以向服务器请求下载对应的目标补丁包，服务器根据该当前运行架构类型和当前编译工具类型，从各候选差分补丁包中筛选出该当前运行架构类型和当前编译工具类型对应的候选差分补丁包，作为目标补丁包以返回给终端设备，其中，本公开实施例中，待修复SDK可以为一个或多个，则相应地可以获取到一个或多个目标补丁包。

进而终端设备接收到目标补丁包后，完成目标补丁包的安装，即将待修复SDK的目标补丁包放到该应用程序的一个指定路径下，从而可以加载该指定路径下的目标补丁包，实现对待修复SDK的目标修复对象的热修复。

本公开实施例中，确定应用程序的当前运行架构类型；根据当前运行架构类型和应用程序的当前目标修复对象，确定应用程序的当前编译工具类型，进而基于当前运行架构类型和当前编译工具类型，获得应用程序的待修复SDK的目标补丁包，其中，目标补丁包是与当前运行架构类型和当前编译工具类型关联的补丁包，这样，提供了一种适用于SDK或多个SDK中目标修复对象的热修复补丁包大小的优化方案，运行时确定当前运行架构类型，并确定当前编译工具类型，可以仅获得该当前运行架构类型和当前编译工具类型所关联的目标补丁包，通过区分不同的运行架构类型和编译工具类型，不仅可以适用于SDK，而且目标补丁包中仅需包括当前运行架构类型即可，不需要打包所有的运行架构类型，降低了目标补丁包的大小，降低了内存占用，提高了效率，从而由于降低了补丁包大小，因此还可以提升补丁包的触发率和生效率，提升用户体验。

基于上述实施例，本公开实施例中在补丁包生成阶段，可以生成针对不同运行架构类型和不同编译工具类型下的补丁包，具体针对待修复SDK对应的各候选差分补丁包的生成方式，本公开提供了一种可能的实施方式，可以包括：

1)获取待修复SDK的当前版本。

2)基于各编译工具类型，分别对当前版本中当前目标修复对象进行编译处理，获得各编译工具类型对应的候选编译目标修复对象，并基于各运行架构类型，获得各运行架构类型和各编译工具类型下对应的候选编译目标修复对象。

由于APK可能存在不同的编译环境，造成so被可能被不同编译工具进行不同的strip处理，以添加不同的strip类型(type)信息，因此，本公开实施例中，在编译当前版本的待修复SDK中的so时，可以基于不同的编译工具都进行一次编译，生成所有可能的编译后的so。

例如，枚举当前所有的编译工具类型的编译工具，本公开实施例中为便于描述，也可以将编译工具类型称为strip type，例如共有三种编译工具类型，分别为：1)llvm-a20：对应ndk版本>20的llvm strip工具；2)gcc-a16：对应16<＝ndk版本<＝20的gcc strip工具；3)gcc-b16：对应ndk版本<16的gcc strip工具。

进而将基于不同编译工具类型生成的so，结合不同的运行架构类型，就可以获得各编译工具类型和各运行架构类型下对应的so，例如，运行架构类型有两种，分别为x86，x86_64，则针对同一个so，可以获得六种不同可能性的so，分别为llvm-a20+x86下的so、llvm-a20+x86_64下的so、gcc-a16+x86下的so、gcc-a16+x86_64下的so、gcc-b16+x86下的so、以及gcc-b16+x86下的so。

进一步地，本公开实施例中，还需要记录针对当前版本，基于不同编译工具类型和不同运行架构类型而处理后的类型描述信息，包括各运行架构类型和各编译工具类型下对应的候选编译目标修复对象，便于后续下载补丁包时，来确定应用程序的strip type类型。

3)获取待修复SDK的在各运行架构类型下的更新版本。

本公开实施例中，该更新版本即相较于当前版本而热修复后的版本，针对更新版本，可以使用任意一种编译工具类型进行编译即可，因为后续是将更新版本与当前版本做差分，因此，只需针对当前版本而基于多个不同编译工具和多个运行架构进行处理即可，针对更新版本不需要限制其所采用的编译工具类型。

4)分别将各运行架构类型和各编译工具类型下对应的候选编译目标修复对象，以及在各运行架构类型下更新版本中的更新目标修复对象，进行差分处理，获得各运行架构类型和各编译工具类型下分别对应的候选差分补丁包。

例如，针对一个a.so，以运行架构类型包括x86和x86_64、编译工具类型称包括llvm-a20、gcc-a16和gcc-b16为例，当前版本对应生成了六种不同的a.so，历史版本对应有x86和x86_64两种运行架构类型下的a.so，从而进行差分处理，可以生成当前版本和更新版本中a.so的差分补丁包，可以获得六种不同的候选差分补丁包，例如分别为llvm-a20+x86a.diff so、llvm-a20+x86_64a.diff so、gcc-a16+x86 a.diff so、gcc-a16+x86_64a.diffso、gcc-b16+x86 a.diff so、gcc-b16+x86_64a.diff so。

另外，本公开实施例中，还可以获得两个候选完整补丁包，即在该两个运行架构类型下的更新版本，例如分别为x86对应的更新版本sdk中完整a.so、x86_64对应的更新版本sdk中完整a.so。

这样，本公开实施例中，不仅可以生成不同的候选差分补丁包，还可以生成不同运行架构类型的候选完整补丁包，可以预防未确定出应用程序所使用的当前编译工具类型的情况，在当前编译工具类型未知的情况下，可以直接下发完整补丁包，保证热修复可用。

进一步地，生成候选差分补丁包和候选完整补丁包后，就可以上传至服务器，针对上传至服务器的补丁包投放阶段，具体本公开提供了一种可能的实施方式，待修复SDK对应的各候选差分补丁包，是通过以下方式存储在服务器的：

1)将获得的各候选差分补丁包和各候选差分补丁包所对应的运行架构类型和编译工具类型，以及各更新版本所表征的候选完整补丁包和各候选完整补丁包所对应的运行架构类型，上传并存储至服务器。

即针对各候选差分补丁包，添加对应的运行架构类型和编译工具类型，各候选完整补丁包，添加对应的运行架构类型。

2)将当前版本的类型描述信息存储至服务器，其中，类型描述信息中包括各运行架构类型和各编译工具类型下对应的候选编译目标修复对象。

进而终端设备在运行应用程序时，可以下载对应的目标补丁包，具体提供了几种可能的实施方式：

一种可能的实施方式中，基于当前运行架构类型和当前编译工具类型，获得应用程序的待修复SDK的目标补丁包，包括：向所述服务器发送第一补丁包下载请求，其中，第一补丁包下载请求中至少包括当前运行架构类型和当前编译工具类型；接收服务器返回的目标差分补丁包，其中，目标差分补丁包是服务器根据当前运行架构类型和当前编译工具类型从各候选差分补丁包中确定的。

例如，各候选差分补丁包及其对应的运行架构类型和编译工具类型分别为，llvm-a20+x86 a.diff so、llvm-a20+x86_64a.diff so、gcc-a16+x86 a.diffso、gcc-a16+x86_64a.diff so、gcc-b16+x86 a.diff so、gcc-b16+x86_64a.diff so，确定出的当前编译工具类型为llvm-a20，并且当前运行架构类型为x86，则服务器从各候选差分补丁包中进行筛选，可以筛选出llvm-a20+x86 a.diff so，作为目标补丁包以返回给终端设备。

另一种可能的实施方式中，还包括：在未确定出当前编译工具类型的情况下，向服务器发送第二补丁包下载请求，其中，第二补丁包下载请求中至少包括当前运行架构类型，或者第二补丁包下载请求中至少包括当前运行架构类型和标识为未知的当前编译工具类型；接收服务器返回的目标完整补丁包，其中，目标完整补丁包是服务器根据当前运行架构类型从各候选完整补丁包中确定的。

例如，以目标修复对象为a.so为例，候选完整补丁包分别为x86对应的更新版本sdk中完整a.so、x86_64对应的更新版本sdk中完整a.so，确定出的当前运行架构类型为x86，而当前编译工具类型未知，则服务器从各候选完整补丁包中进行筛选，可以筛选出x86对应的更新版本sdk中完整a.so，作为目标补丁包以返回给终端设备。

这样，基于不同情况，可以从服务器下载候选差分补丁包或候选完整补丁包，可以保证不同情况下的热修复都能够可用，并且可以仅下载一种关联的候选差分补丁包或候选完整补丁包，降低了补丁包的大小。

下面采用具体应用场景进行说明。以基于Android平台，并且目标修复对象为目标修复so为例，参阅图4所示，为本公开实施例中另一种热修复方法的流程图，如图4所示，该方法包括：

S400：补丁包生成阶段。

S401：针对当前版本，基于各编译工具类型进行编译处理，并获得各运行架构类型和各编译工具类型下对应的候选编译目标修复对象。

S402：获得各编译工具类型和各运行架构类型下对应的候选差分补丁包。

即分别将各运行架构类型和各编译工具类型下对应的候选编译目标修复对象，以及在各运行架构类型下更新版本中的更新目标修复对象，进行差分处理，从而获得不同的候选差分补丁包。

S403：补丁包投放阶段。

S404：将各候选差分补丁包和各候选完整补丁包上传并存储至服务器，以及将当前版本的类型描述信息存储至服务器。

其中，该类型描述信息包括各运行架构类型和各编译工具类型下对应的候选编译目标修复对象。

S405：补丁包生效阶段。

S406：确定当前运行架构类型。

S407：确定当前编译工具类型。

S408：基于当前运行架构类型和当前编译工具类型，向服务器请求下载补丁包。

本公开实施例中，在确定出当前编译工具类型是什么的情况下，即携带当前运行架构类型和当前编译工具发送第一补丁包下载请求，在未确定出当前编译工具类型是什么的情况下，可以携带当前运行架构类型发送第二补丁包下载请求。

S409：下载对应的目标补丁包。

这样，本公开实施例中，针对SDK，区分不同编译工具类型和不同运行架构类型，并且结合差分处理，而生成不同编译工具类型和不同运行架构类型对应的候选差分补丁包，进而上传并存储至服务器，在补丁包生成阶段和补丁包投放阶段均进行了优化处理，可以将候选差分补丁包和候选完整补丁包的大小都可以降低，从而降低终端设备所下载的目标补丁包所占内存大小，提高了效率。

本领域技术人员可以理解，在具体实施方式的上述方法中，各步骤的撰写顺序并不意味着严格的执行顺序而对实施过程构成任何限定，各步骤的具体执行顺序应当以其功能和可能的内在逻辑确定。

基于同一发明构思，本公开实施例中还提供了与热修复方法对应的热修复装置，由于本公开实施例中的装置解决问题的原理与本公开实施例上述方法相似，因此装置的实施可以参见方法的实施，重复之处不再赘述。

参照图5所示，为本公开实施例提供的一种热修复装置的结构示意图，该装置包括：

第一确定模块51，用于确定所述应用程序的当前运行架构类型；

第二确定模块52，用于根据所述当前运行架构类型和所述应用程序的当前目标修复对象，确定所述应用程序的当前编译工具类型；

获得模块53，用于基于所述当前运行架构类型和所述当前编译工具类型，获得所述应用程序的待修复软件开发功能包SDK的目标补丁包，其中，所述目标补丁包是与所述当前运行架构类型和所述当前编译工具类型关联的补丁包，所述目标补丁包中至少包括所述待修复SDK中热修复的目标修复对象的补丁包。

一种可选的实施例中，所述确定所述应用程序的当前运行架构类型时，第一确定模块51用于：

在所述应用程序运行过程中，通过所述应用程序中预设的探针方法，获得所述应用程序的当前运行架构类型，所述预设的探针方法用于实现返回所述当前运行架构类型的功能。

一种可选的实施例中，所述根据所述当前运行架构类型和所述应用程序的当前目标修复对象，确定所述应用程序的当前编译工具类型时，第二确定模块52用于：

根据所述当前运行架构类型，向服务器请求获得类型描述信息中所述当前运行架构类型对应的各候选编译目标修复对象，其中，所述服务器中存储有所述待修复SDK的当前版本的类型描述信息，所述类型描述信息中包括各运行架构类型和各编译工具类型下对应的候选编译目标修复对象；

获取所述应用程序运行时的当前目标修复对象，并确定所述当前目标修复对象的当前标识信息；

根据所述当前标识信息和获得的各所述候选编译目标修复对象，确定所述当前目标修复对象对应的第一候选编译目标修复对象；

根据所述第一候选编译目标修复对象对应的编译工具类型，确定所述当前目标修复对象的编译工具类型，并将所述当前目标修复对象的编译工具类型，确定为所述应用程序的当前编译工具类型。

一种可选的实施例中，所述目标差分补丁包是服务器根据所述当前运行架构类型和所述当前编译工具类型，从所述待修复SDK对应的各候选差分补丁包中确定的；

则还包括生成模块54，其中，所述待修复SDK对应的各候选差分补丁包，是生成模块54通过以下方式获得的：

获取所述待修复SDK的当前版本；

基于各编译工具类型，分别对所述当前版本中当前目标修复对象进行编译处理，获得各所述编译工具类型对应的候选编译目标修复对象，并基于各运行架构类型，获得各所述运行架构类型和各所述编译工具类型下对应的候选编译目标修复对象；

获取所述待修复SDK的在各所述运行架构类型下的更新版本；

分别将各所述运行架构类型和各所述编译工具类型下对应的候选编译目标修复对象，以及在各所述运行架构类型下更新版本中的更新目标修复对象，进行差分处理，获得各所述运行架构类型和各所述编译工具类型下分别对应的候选差分补丁包。

一种可选的实施例中，还包括投放模块55，所述待修复SDK对应的各候选差分补丁包，是投放模块55通过以下方式存储在所述服务器的：

将获得的各所述候选差分补丁包和各所述候选差分补丁包所对应的所述运行架构类型和所述编译工具类型，以及各所述更新版本所表征的候选完整补丁包和各所述候选完整补丁包所对应的所述运行架构类型，上传并存储至服务器；

并将所述当前版本的类型描述信息存储至所述服务器，其中，所述类型描述信息中包括各所述运行架构类型和各所述编译工具类型下对应的候选编译目标修复对象。

一种可选的实施例中，基于所述当前运行架构类型和所述当前编译工具类型，获得所述应用程序的待修复软件开发功能包SDK的目标补丁包时，获得模块53用于：

向所述服务器发送第一补丁包下载请求，其中，所述第一补丁包下载请求中至少包括所述当前运行架构类型和所述当前编译工具类型；

接收所述服务器返回的目标差分补丁包，其中，所述目标差分补丁包是所述服务器根据所述当前运行架构类型和所述当前编译工具类型从各所述候选差分补丁包中确定的。

一种可选的实施例中，获得模块53还用于：

在未确定出所述当前编译工具类型的情况下，向所述服务器发送第二补丁包下载请求，其中，所述第二补丁包下载请求中至少包括所述当前运行架构类型，或者第二补丁包下载请求中至少包括所述当前运行架构类型和标识为未知的所述当前编译工具类型；

接收所述服务器返回的目标完整补丁包，其中，所述目标完整补丁包是所述服务器根据所述当前运行架构类型从各所述候选完整补丁包中确定的。

关于装置中的各模块的处理流程、以及各模块的交互流程的描述可以参照上述方法实施例中的相关说明，这里不再详述。

本公开实施例还提供了一种电子设备，如图6所示，为本公开实施例提供的电子设备结构示意图，包括：

处理器61和存储器62；所述存储器62存储有处理器61可执行的机器可读指令，处理器61用于执行存储器62中存储的机器可读指令，所述机器可读指令被处理器61执行时，处理器61执行下述步骤：

在应用程序运行情况下，确定所述应用程序的当前运行架构类型；

根据所述当前运行架构类型和所述应用程序的当前目标修复对象，确定所述应用程序的当前编译工具类型；

基于所述当前运行架构类型和所述当前编译工具类型，获得所述应用程序的待修复软件开发功能包SDK的目标补丁包，其中，所述目标补丁包是与所述当前运行架构类型和所述当前编译工具类型关联的补丁包，所述目标补丁包中至少包括所述待修复SDK中热修复的目标修复对象的补丁包。

一种可选的实施例中，所述确定所述应用程序的当前运行架构类型时，处理器61用于：

在所述应用程序运行过程中，通过所述应用程序中预设的探针方法，获得所述应用程序的当前运行架构类型，所述预设的探针方法用于实现返回所述当前运行架构类型的功能。

一种可选的实施例中，所述根据所述当前运行架构类型和所述应用程序的当前目标修复对象，确定所述应用程序的当前编译工具类型时，处理器61用于：

根据所述当前运行架构类型，向服务器请求获得类型描述信息中所述当前运行架构类型对应的各候选编译目标修复对象，其中，所述服务器中存储有所述待修复SDK的当前版本的类型描述信息，所述类型描述信息中包括各运行架构类型和各编译工具类型下对应的候选编译目标修复对象；

获取所述应用程序运行时的当前目标修复对象，并确定所述当前目标修复对象的当前标识信息；

根据所述当前标识信息和获得的各所述候选编译目标修复对象，确定所述当前目标修复对象对应的第一候选编译目标修复对象；

根据所述第一候选编译目标修复对象对应的编译工具类型，确定所述当前目标修复对象的编译工具类型，并将所述当前目标修复对象的编译工具类型，确定为所述应用程序的当前编译工具类型。

一种可选的实施例中，所述目标差分补丁包是服务器根据所述当前运行架构类型和所述当前编译工具类型，从所述待修复SDK对应的各候选差分补丁包中确定的；其中，所述待修复SDK对应的各候选差分补丁包，是处理器61通过以下方式获得的：

获取所述待修复SDK的当前版本；

基于各编译工具类型，分别对所述当前版本中当前目标修复对象进行编译处理，获得各所述编译工具类型对应的候选编译目标修复对象，并基于各运行架构类型，获得各所述运行架构类型和各所述编译工具类型下对应的候选编译目标修复对象；

获取所述待修复SDK的在各所述运行架构类型下的更新版本；

分别将各所述运行架构类型和各所述编译工具类型下对应的候选编译目标修复对象，以及在各所述运行架构类型下更新版本中的更新目标修复对象，进行差分处理，获得各所述运行架构类型和各所述编译工具类型下分别对应的候选差分补丁包。

一种可选的实施例中，所述待修复SDK对应的各候选差分补丁包，是处理器61通过以下方式存储在所述服务器的：

将获得的各所述候选差分补丁包和各所述候选差分补丁包所对应的所述运行架构类型和所述编译工具类型，以及各所述更新版本所表征的候选完整补丁包和各所述候选完整补丁包所对应的所述运行架构类型，上传并存储至服务器；

并将所述当前版本的类型描述信息存储至所述服务器，其中，所述类型描述信息中包括各所述运行架构类型和各所述编译工具类型下对应的候选编译目标修复对象。

一种可选的实施例中，基于所述当前运行架构类型和所述当前编译工具类型，获得所述应用程序的待修复软件开发功能包SDK的目标补丁包时，处理器61用于：

向所述服务器发送第一补丁包下载请求，其中，所述第一补丁包下载请求中至少包括所述当前运行架构类型和所述当前编译工具类型；

接收所述服务器返回的目标差分补丁包，其中，所述目标差分补丁包是所述服务器根据所述当前运行架构类型和所述当前编译工具类型从各所述候选差分补丁包中确定的。

一种可选的实施例中，处理器61还用于：

在未确定出所述当前编译工具类型的情况下，向所述服务器发送第二补丁包下载请求，其中，所述第二补丁包下载请求中至少包括所述当前运行架构类型，或者第二补丁包下载请求中至少包括所述当前运行架构类型和标识为未知的所述当前编译工具类型；

接收所述服务器返回的目标完整补丁包，其中，所述目标完整补丁包是所述服务器根据所述当前运行架构类型从各所述候选完整补丁包中确定的。

上述存储器62包括内存621和外部存储器622；这里的内存621也称内存储器，用于暂时存放处理器61中的运算数据，以及与硬盘等外部存储器622交换的数据，处理器61通过内存621与外部存储器622进行数据交换。

上述指令的具体执行过程可以参考本公开实施例中所述的热修复方法的步骤，此处不再赘述。

本公开实施例还提供一种计算机可读存储介质，该计算机可读存储介质上存储有计算机程序，该计算机程序被处理器运行时执行上述方法实施例中所述的热修复方法的步骤。其中，该存储介质可以是易失性或非易失的计算机可读取存储介质。

本公开实施例还提供一种计算机程序产品，该计算机程序产品承载有程序代码，所述程序代码包括的指令可用于执行上述方法实施例中所述的热修复方法的步骤，具体可参见上述方法实施例，在此不再赘述。

其中，上述计算机程序产品可以具体通过硬件、软件或其结合的方式实现。在一个可选实施例中，所述计算机程序产品具体体现为计算机存储介质，在另一个可选实施例中，计算机程序产品具体体现为软件产品，例如软件开发包(Software Development Kit，SDK)等等。

所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，上述描述的系统和装置的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。在本公开所提供的几个实施例中，应该理解到，所揭露的系统、装置和方法，可以通过其它的方式实现。以上所描述的装置实施例仅仅是示意性的，例如，所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，又例如，多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些通信接口，装置或单元的间接耦合或通信连接，可以是电性，机械或其它的形式。

所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。

另外，在本公开各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。

所述功能如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个处理器可执行的非易失的计算机可读取存储介质中。基于这样的理解，本公开的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台电子设备(可以是个人计算机，服务器，或者网络设备等)执行本公开各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器(Read-OnlyMemory，ROM)、随机存取存储器(Random Access Memory，RAM)、磁碟或者光盘等各种可以存储程序代码的介质。

最后应说明的是：以上所述实施例，仅为本公开的具体实施方式，用以说明本公开的技术方案，而非对其限制，本公开的保护范围并不局限于此，尽管参照前述实施例对本公开进行了详细的说明，本领域的普通技术人员应当理解：任何熟悉本技术领域的技术人员在本公开揭露的技术范围内，其依然可以对前述实施例所记载的技术方案进行修改或可轻易想到变化，或者对其中部分技术特征进行等同替换；而这些修改、变化或者替换，并不使相应技术方案的本质脱离本公开实施例技术方案的精神和范围，都应涵盖在本公开的保护范围之内。因此，本公开的保护范围应所述以权利要求的保护范围为准。

Claims (10)

1.一种热修复方法，其特征在于，包括：

确定所述应用程序的当前运行架构类型；

根据所述当前运行架构类型和所述应用程序的当前目标修复对象，确定所述应用程序的当前编译工具类型；

基于所述当前运行架构类型和所述当前编译工具类型，获得所述应用程序的待修复软件开发功能包SDK的目标补丁包，其中，所述目标补丁包是与所述当前运行架构类型和所述当前编译工具类型关联的补丁包，所述目标补丁包中至少包括所述待修复SDK中热修复的目标修复对象的补丁包。

2.根据权利要求1所述的方法，其特征在于，所述确定所述应用程序的当前运行架构类型，包括：

通过所述应用程序中预设的探针方法，获得所述应用程序的当前运行架构类型，所述预设的探针方法用于实现返回所述当前运行架构类型的功能。

3.根据权利要求1所述的方法，其特征在于，所述根据所述当前运行架构类型和所述应用程序的当前目标修复对象，确定所述应用程序的当前编译工具类型，包括：

根据所述当前运行架构类型，向服务器请求获得类型描述信息中所述当前运行架构类型对应的各候选编译目标修复对象，其中，所述服务器中存储有所述待修复SDK的当前版本的类型描述信息，所述类型描述信息中包括各运行架构类型和各编译工具类型下对应的候选编译目标修复对象；

获取所述应用程序运行时的当前目标修复对象，并确定所述当前目标修复对象的当前标识信息；

根据所述当前标识信息和获得的各所述候选编译目标修复对象，确定所述当前目标修复对象对应的第一候选编译目标修复对象；

根据所述第一候选编译目标修复对象对应的编译工具类型，确定所述当前目标修复对象的编译工具类型，并将所述当前目标修复对象的编译工具类型，确定为所述应用程序的当前编译工具类型。

4.根据权利要求1-3任一项所述的方法，其特征在于，所述目标差分补丁包是服务器根据所述当前运行架构类型和所述当前编译工具类型，从所述待修复SDK对应的各候选差分补丁包中确定的；

其中，所述待修复SDK对应的各候选差分补丁包，是通过以下方式获得的：

获取所述待修复SDK的当前版本；

基于各编译工具类型，分别对所述当前版本中当前目标修复对象进行编译处理，获得各所述编译工具类型对应的候选编译目标修复对象，并基于各运行架构类型，获得各所述运行架构类型和各所述编译工具类型下对应的候选编译目标修复对象；

获取所述待修复SDK的在各所述运行架构类型下的更新版本；

分别将各所述运行架构类型和各所述编译工具类型下对应的候选编译目标修复对象，以及在各所述运行架构类型下更新版本中的更新目标修复对象，进行差分处理，获得各所述运行架构类型和各所述编译工具类型下分别对应的候选差分补丁包。

5.根据权利要求4所述的方法，其特征在于，所述待修复SDK对应的各候选差分补丁包，是通过以下方式存储在所述服务器的：

将获得的各所述候选差分补丁包和各所述候选差分补丁包所对应的所述运行架构类型和所述编译工具类型，以及各所述更新版本所表征的候选完整补丁包和各所述候选完整补丁包所对应的所述运行架构类型，上传并存储至服务器；

并将所述当前版本的类型描述信息存储至所述服务器，其中，所述类型描述信息中包括各所述运行架构类型和各所述编译工具类型下对应的候选编译目标修复对象。

6.根据权利要求5所述的方法，其特征在于，基于所述当前运行架构类型和所述当前编译工具类型，获得所述应用程序的待修复软件开发功能包SDK的目标补丁包，包括：

向所述服务器发送第一补丁包下载请求，其中，所述第一补丁包下载请求中至少包括所述当前运行架构类型和所述当前编译工具类型；

接收所述服务器返回的目标差分补丁包，其中，所述目标差分补丁包是所述服务器根据所述当前运行架构类型和所述当前编译工具类型从各所述候选差分补丁包中确定的。

7.根据权利要求5所述的方法，其特征在于，所述方法还包括：

在未确定出所述当前编译工具类型的情况下，向所述服务器发送第二补丁包下载请求，其中，所述第二补丁包下载请求中至少包括所述当前运行架构类型，或者第二补丁包下载请求中至少包括所述当前运行架构类型和标识为未知的所述当前编译工具类型；

接收所述服务器返回的目标完整补丁包，其中，所述目标完整补丁包是所述服务器根据所述当前运行架构类型从各所述候选完整补丁包中确定的。

8.一种热修复装置，其特征在于，包括：

第一确定模块，用于确定所述应用程序的当前运行架构类型；

第二确定模块，用于根据所述当前运行架构类型和所述应用程序的当前目标修复对象，确定所述应用程序的当前编译工具类型；

获得模块，用于基于所述当前运行架构类型和所述当前编译工具类型，获得所述应用程序的待修复软件开发功能包SDK的目标补丁包，其中，所述目标补丁包是与所述当前运行架构类型和所述当前编译工具类型关联的补丁包，所述目标补丁包中至少包括所述待修复SDK中热修复的目标修复对象的补丁包。

9.一种电子设备，其特征在于，包括：处理器、存储器，所述存储器存储有所述处理器可执行的机器可读指令，所述处理器用于执行所述存储器中存储的机器可读指令，所述机器可读指令被所述处理器执行时，所述处理器执行如权利要求1-7任一项所述方法的步骤。

10.一种计算机可读存储介质，其上存储有计算机程序，其特征在于：所述计算机程序被处理器执行时实现权利要求1-7任一项所述方法的步骤。