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

Abstract

本公开提供了一种热修复方法、装置、电子设备及存储介质，该方法为，获得所述应用程序的待修复SDK的补丁包，补丁包中包括目标修复对象的补丁包，目标修复对象为待修复SDK中需热修复的对象；确定所述目标修复对象是否已被加载到运行内存；在确定所述目标修复对象未被加载到运行内存的情况下，在所述应用程序运行过程中，拦截所述目标修复对象的加载流程，并将目标修复对象的加载路径修改为指向所述目标修复对象的补丁包所在的补丁位置路径，以使所述应用程序能够加载所述补丁位置路径下的所述目标修复对象，这样，针对未被加载的目标修复对象，拦截加载流程以指向补丁位置路径，实现目标修复对象的热修复立即生效，而不需要应用程序重启。

Description

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

技术领域

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

背景技术

热修复技术是一种快速高效的应用程序修复方式，可以对已安装的应用程序使用补丁进行修复，应用程序的热修复包括so库热修复，相关技术中，so库热修复方法主要是针对应用程序级别的，并且是应用程序重启后才会生效，降低了效率，并且会使得用户打开已启动应用程序中某功能时，热修复补丁不能及时生效而导致漏洞没有修复而出现问题，影响用户使用体验。

发明内容

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

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

获得所述应用程序的待修复SDK的补丁包，其中，所述补丁包中包括目标修复对象的补丁包，所述目标修复对象为所述待修复SDK中需热修复的对象；

确定所述目标修复对象是否已被加载到运行内存；

在确定所述目标修复对象未被加载到运行内存的情况下，在所述应用程序运行过程中，拦截所述目标修复对象的加载流程，并将所述目标修复对象的加载路径，修改为指向所述目标修复对象的补丁包所在的补丁位置路径，以使所述应用程序能够加载所述补丁位置路径下的所述目标修复对象。

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

获得模块，用于获得所述应用程序的待修复软件开发功能包SDK的补丁包，其中，所述补丁包中包括目标修复对象的补丁包，所述目标修复对象为所述待修复SDK中需热修复的对象；

确定模块，用于确定所述目标修复对象是否已被加载到运行内存；

第一处理模块，用于在确定所述目标修复对象未被加载到运行内存的情况下，在所述应用程序运行过程中，拦截所述目标修复对象的加载流程，并将所述目标修复对象的加载路径，修改为指向所述目标修复对象的补丁包所在的补丁位置路径，以使所述应用程序能够加载所述补丁位置路径下的所述目标修复对象。

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

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

本公开实施例中，在应用程序运行情况下，获得所述应用程序的待修复SDK的补丁包，其中，所述补丁包中至少包括目标修复对象的补丁包；确定所述目标修复对象是否已被加载到运行内存；在确定所述目标修复对象未被加载到运行内存的情况下，在所述应用程序运行过程中，拦截所述目标修复对象的加载流程，并将目标修复对象的加载路径，修改为指向所述目标修复对象的补丁包所在的补丁位置路径，以使所述应用程序能够加载所述补丁位置路径下的所述目标修复对象，这样，针对SDK的目标修复对象，可以在未被加载到运行内存时，即进行拦截加载流程并指向补丁位置路径，可以使得不需要应用程序重启，就可以在调用目标修复对象时，加载补丁位置路径下的目标修复对象，实现目标修复对象的热修复立即生效。

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

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

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

附图说明

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

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

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

图3示出了本公开实施例所提供的hook目标修复对象的补丁位置路径的原理示意图；

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

图5示出了本公开实施例所提供的热修复方法中判断目标修复对象是否已被加载到运行内存的方法流程图；

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

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

具体实施方式

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

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

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

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

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

钩子(hook)：表示改变程序代码执行流程的一种方法，能够将某目标代码融入被勾住的应用程序的进程中，成为该进程的一个部分，使用技术手段在运行时动态的将该额外的目标代码依附现进程，从而实现替换现有处理逻辑或插入额外功能的目的，本公开实施例中，可以使用hook方法，改变读取目标修复对象的路径，指向目标修复对象的补丁位置路径。

经研究发现，相关技术中，so库热修复方法主要是针对APP级别的，APP中包括多种功能的软件开发工具包(Software Development Kit，SDK)，APP依赖SDK可以快捷地实现一定功能，若需针对某功能进行修复，由于APP发版周期长等特征，会降低效率，因此针对SDK中的so热修复是非常必要的，而目前针对SDK级别的热修复方案还比较少；并且相关技术中so热修复是在应用程序重启后才会生效，降低了效率，并且会使得用户打开已启动应用程序中某功能时，该功能SDK的热修复补丁不能及时生效而导致漏洞没有修复而出现问题，影响用户使用体验。

基于上述研究，本公开提供了一种热修复方法，在应用程序运行情况下，获得应用程序的待修复SDK的补丁包，其中，补丁包中至少包括目标修复对象的补丁包；确定目标修复对象是否已被加载到运行内存；在确定目标修复对象未被加载到运行内存的情况下，在应用程序运行过程中，拦截目标修复对象的加载流程，并将目标修复对象的加载路径，修改为指向目标修复对象的补丁包所在的补丁位置路径，以使应用程序能够加载补丁位置路径下的目标修复对象，这样，实现了更优的针对SDK的so热修复方案，并且通过是否已被加载到运行内存的判断，能够识别哪些目标修复对象是可以立即生效修复的，从而可以针对未被加载到运行内存的目标修复对象，能够使其修复立即生效，而不需要应用程序重启，提高效率和用户使用体验，尤其是针对重度游戏APP中的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进行修复。

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

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

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

S201：获得应用程序的待修复SDK的补丁包，其中，补丁包中包括目标修复对象的补丁包，目标修复对象为待修复SDK中需热修复的对象。

其中，应用程序可以依赖SDK而实现特定功能，通常应用程序可以包括多个SDK，SDK是实现一定功能的代码集合，可以认为SDK是用于实现应用程序的相应功能的功能包集合，本公开实施例中，主要是针对SDK级别的热修复，SDK热修复是用于热修复应用程序中通过SDK实现的相应功能，每进行一次SDK热修复就会生成一个相应的补丁包，并通过补丁包来完成具体的SDK热修复，即SDK热修复是用来热修复应用程序中接入或加载的SDK的。

并且，本公开实施例中，针对SDK中目标修复对象的热修复，该目标修复对象为so，当然也可以为其它热修复对象，对此本公开实施例中并不进行限制，本公开实施例中以so为例，则待修复SDK的补丁包中即包括热修复的so的补丁包，即热修复后的so。

针对该步骤S201，具体地，本公开实施例中，可以从服务器请求下载该应用程序的待修复SDK的补丁包，其中，待修复SDK可以为一个或多个，例如启动应用程序后，向服务器发送SDK补丁包下载请求，服务器若确定该应用程序有多个SDK需热修复，则可以同时下发该多个SDK的补丁包给终端设备，进而终端设备接收到补丁包后，完成补丁包的安装，即将待修复SDK的补丁包放到该应用程序的一个指定路径下，本公开实施例中，该指定路径也称为补丁位置路径。

S202：确定目标修复对象是否已被加载到运行内存。

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

1)确定系统锁所在的锁位置路径，其中，系统锁为加载目标修复对象过程中所需使用的锁。

通常，系统在加载so时会使用到一个系统锁，在加载时使用系统锁，系统锁具有排他性，可以保证不会有其它加载或卸载操作而影响本次加载，避免出错，加载完后释放系统锁，等待这个系统锁的其它操作，例如可以加载另一个so，再进行加锁操作以继续执行，因此，本公开实施例中，在遍历系统运行内存中已被加载的so时，需使用该系统锁进行加锁以避免出错，若使用该系统锁，就需要先确定出该系统锁的锁位置路径。

具体确定系统锁所在的锁位置路径，针对不同情况，本公开提供了几种可能的实施方式：

一种可能的实施方式，确定系统锁所在的锁位置路径，包括：获取系统锁对应的系统文件；对系统文件进行解析，并根据系统锁的符号名，从解析后的系统文件中确定出系统锁所在的锁位置路径。

例如，对于Android5.0及以上的终端设备，在Android5.0及以上的环境中，使用系统锁时，会外露该系统锁的符合名，例如Android5.0及以上中系统锁的符号名为_dl__ZL10g_dl_mutex，因此可以先获取加载系统锁所使用到的系统文件，该系统锁本质也可以理解为是系统so方法，该系统文件即为linker二进制文件，并解析该系统文件，根据外露的符号名找到系统锁在运行内存中的锁位置路径。

另一种可能的实施方式，确定系统锁所在的锁位置路径，包括：执行调用加载操作或卸载操作；其中，在执行加载操作或卸载操作时会加载系统锁；遍历加载操作或卸载操作所对应的调用栈信息，确定系统锁所在的锁位置路径。

例如，对于Android5.0以下的终端设备或部分游戏模拟器，在linker中可能并没有暴露符号名，因此针对该情况，可以采用其它方式来确定，由于系统在调用加载或卸载时会上锁，则可以调用一次无用的加载或卸载操作，通过遍历调用栈的方式，找到该系统锁在运行内存中锁位置路径。

当然，本公开实施例中对于确定系统锁位置的实施方式，还可以采用其它方式，并不进行限制。

2)基于锁位置路径加载系统锁，并在加载系统锁后，获取应用程序对应的已被加载到运行内存的各对象。

本公开实施例中，在遍历系统运行内存中已被加载的so时，先基于该系统锁进行上锁，这是因为在遍历过程中没有发现需修复的so，因此认为能够立即修复生效，但是其实在遍历过程中有另外的逻辑将这个so加载到运行内存了，则该情况就会出现判断错误，进而影响后续的热修复。

进而基于锁位置路径加载系统锁，进行上锁后，就可以遍历运行内存以获得当前已被加载到运行内存中的各对象，例如已被加载的各个so。具体针对不同情况，针对获取应用程序对应的已被加载到运行内存的各对象，本公开实施例中提供了几种可能的实施方式：

一种可能的实施方式中，获取应用程序对应的已被加载到运行内存的各对象，包括：通过预设目标接口，访问运行内存并在运行内存中，读取应用程序对应的已被加载到运行内存的各对象。

例如，对于Android5.0及以上的终端设备，该预设目标接口为dl_iterate_phdr，可以通过该接口来读取该应用程序已被加载到运行内存的各对象，例如已被加载的各个so。

这样，通过系统提供的预设目标接口来获取已被加载的各对象，更加稳定可靠，也更加高效。

另一种可能的实施方式中，获取所述应用程序对应的已被加载到运行内存的各对象，包括：确定应用程序对应的各应用进程；读取各应用进程的运行文件，并获得应用程序对应的已被加载到运行内存的各对象，其中，运行文件中至少记录有所加载的各对象描述信息。

通常一个应用程序可以有多个应用进程，每个应用进程对应一个运行文件，例如maps文件，该maps文件为应用进程内存地址映射文件，记录有加载运行信息，对于so，应用进程加载so时会写到对应的maps文件，包括该so在运行内存中所占用的虚拟地址空间、读写运行权限、so名称等信息，并且一个应用程序可能有多个应用进程会使用到待修复SDK的功能，因此，可以确定该应用程序当前对应的各应用进程以来获取已被加载的各个so。

例如，对于Android5.0以下的终端设备或部分游戏模拟器，可能没有提供系统访问接口，则可以通过读取各应用进程的maps文件方式，获得该应用程序的已被加载的各对象。

3)根据获取的各对象和目标修复对象的比对，确定目标修复对象是否已被加载到运行内存。

即可以遍历获得的已被加载的各对象，判断其中是否有待修复SDK的补丁包中的目标修复对象。

进一步地，确定目标修复对象是否已被加载到运行内存之后，本公开实施例中还可以进行释放锁，即对于之前上锁所使用的系统锁而进行释放。

S203：在确定目标修复对象未被加载到运行内存的情况下，在应用程序运行过程中，拦截目标修复对象的加载流程，并将目标修复对象的加载路径，修改为指向目标修复对象的补丁包所在的补丁位置路径，以使应用程序能够加载补丁位置路径下的目标修复对象。

其中，拦截目标修复对象的加载流程，并将目标修复对象的加载路径，修改为指向目标修复对象的补丁包所在的补丁位置路径的执行方式，即可以通过hook技术来实现，hook加载so的流程，将修复后的so的补丁位置路径放到前面，例如，参阅图3所示，为本公开实施例中hook目标修复对象的补丁位置路径的原理示意图，以so为例，hook补丁位置路径，即是so补丁包所在的补丁位置路径插入到nativeLibraryDirectories数组的最前面，nativeLibraryDirectories数组中包括应用程序中各个so的位置路径。

这样，在应用程序运行中，即立即hook补丁位置路径，进而等待用户使用待修复SDK的功能，进行调用，在调用时，由于补丁位置路径放到最前面，因此加载生效时就会直接加载该补丁位置路径下的修复后的目标修复对象，从而可以使得修复后的目标修复对象能够立即生效，即实现目标修复对象的热修复立即生效而无需应用程序重启。

进一步地，针对目标修复对象已被加载到运行内存的情况，本公开还提供了一种可能的实施方式，在确定目标修复对象已被加载到运行内存的情况下，记录目标修复对象的补丁包所在的补丁位置路径；在应用程序关闭并重新运行后，拦截目标修复对象的加载流程，并修改为指向补丁位置路径，以使应用程序能够加载补丁位置路径下的目标修复对象。

也就是说，对于已被加载到运行内存中的目标修复对象，则在应用程序运行内存中不进行hook，此时可以直接释放系统锁，并将补丁位置路径记录下来，等该应用程序重新启动运行后，再hook该目标修复对象的补丁位置路径。

本公开实施例中，对于未被加载到运行内存的目标修复对象，在应用程序运行过程中，立即hook补丁位置路径，而对于已被加载到运行内存的目标修复对象，等待应用程序重新启动后再hook补丁位置路径，这是因为，若目标修复对象已被加载到运行内存，此时hook可能会出现即加载了修复前的目标修复对象，又加载了修复后的补丁包中的目标修复对象，出现错误或功能使用错误等问题。

本公开实施例中，获得应用程序的待修复SDK的补丁包，确定目标修复对象是否已被加载到运行内存；在确定目标修复对象未被加载到运行内存的情况下，在应用程序运行过程中，拦截目标修复对象的加载流程，并将目标修复对象的加载路径，修改为指向目标修复对象的补丁包所在的补丁位置路径，以使应用程序能够加载补丁位置路径下的目标修复对象，这样，针对SDK中的目标修复对象，可以准确地判断是否已被加载，来决定是否立即hook补丁位置路径，对于未被加载的目标修复对象，在应用程序运行过程中即立即hook补丁位置路径，从而使得未被加载的目标修复对象的热修复能够立即生效，而无需等待应用程序重启，提高了效率。

尤其是针对重度游戏中的SDK，SDK的功能入口大多位于游戏中间，这些SDK的目标修复对象加载的时机会比较晚，在补丁包下载并安装后，可能都还未加载到运行内存，因此通过本公开实施例中的热修复方法，能够保证大多的目标修复对象的热修复立即生效，提升游戏用户对于SDK功能的使用体验。

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

S400：运行应用程序。

S401：下载应用程序的待修复SDK的补丁包。

S402：完成补丁包安装。

S403：判断目标修复so是否已被加载到运行内存，若是，则执行步骤S404，否则，则执行步骤S406。

S404：不hook补丁位置路径。

即本公开实施例中，此时不将目标修复so的补丁位置路径hook到nativeLibraryDirectories的最前面。

S405：等待下次应用程序重启时hook补丁位置路径。

S406：hook补丁位置路径。

即通过hook技术，拦截so加载流程，并修改为指向目标修复so的补丁包所在的补丁位置路径。

S407：使用待修复SDK功能。

S408：业务侧调用目标修复so。

例如，使用System.loadLibrary进行调用。

S409：加载补丁位置路径下的目标修复so。

这时即可以加载修复后的目标修复so，实现该目标修复so的热修复生效。

其中，针对上述步骤S403，提供了一种可能的具体实施方式，参阅图5所示，为本公开实施例中热修复方法中判断目标修复对象是否已被加载到运行内存的方法流程图，具体包括：

S500：读取系统文件中系统锁的符号名。

该步骤S500主要针对Android5.0及以上的终端设备的场景，例如，系统文件为linker文件，通过系统锁的符号名来确定系统锁的锁位置路径。

S501：遍历加载操作或卸载操作的调用栈信息。

该步骤S501主要针对Android5.0以下的终端设备或部分游戏模拟器，对于系统锁的符号名不外露的场景，可以通过执行一次无用的加载操作或卸载操作，通过遍历调用栈信息以确定锁位置路径。

S502：基于锁位置路径加载系统锁。

S503：使用系统锁进行上锁，并执行步骤S504或步骤S505。

例如，通过pthread_mutex_lock方法进行上锁。

进而就可以遍历运行内存来获取当前该应用程序的已被加载到运行内存的各个so，基于不同场景，也可以采用不同方式。

S504：读取应用程序的各应用进程的运行文件。

该步骤S504主要针对Android5.0以下的终端设备或部分游戏模拟器的场景。

S505：通过预设目标接口读取运行内存中已被加载的so。

例如，该预设目标接口为dl_iterate_phdr接口，并且在使用该目标接口dl_iterate_phdr访问运行内存时，还可以先进行一次锁操作，以避免出错，进而遍历系统的运行内存的soinfo文件以进行读取，读取完成后可以释放锁。

S506：获取应用程序对应的已被加载到运行内存的各so。

即可以得到一个该应用程序的so列表，该so列表中包括已被加载到运行内存的so。

S507：判断是否有目标修复so。

即确定当前已被加载的so中是否有待修复SDK的补丁包中的so，补丁包的so可以理解为目标修复so，即需要修复的so，通过获得的so列表并进行比对，可以判断so列表中是否有目标修复so，从而可以判断目标修复so是否已被加载到运行内存。

S508：释放系统锁。

S509：返回目标修复so是否已被加载运行内存的判断结果。

这样，本公开实施例中，针对SDK中的so，在应用程序运行情况下，在补丁包安装完成时，可以准确地判断出目标修复so是否已被加载到运行内存，进而来确定是否立即hook补丁位置路径，可以使得未被加载到运行内存的目标修复so，可以在不重启应用程序时，立即hook补丁位置路径，实现该目标修复so的热修复立即生效，提升了用户体验。

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

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

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

获得模块61，用于获得所述应用程序的待修复SDK的补丁包，其中，所述补丁包中包括目标修复对象的补丁包，所述目标修复对象为所述待修复SDK中需热修复的对象；

确定模块62，用于确定所述目标修复对象是否已被加载到运行内存；

第一处理模块63，用于在确定所述目标修复对象未被加载到运行内存的情况下，在所述应用程序运行过程中，拦截所述目标修复对象的加载流程，并将所述目标修复对象的加载路径，修改为指向所述目标修复对象的补丁包所在的补丁位置路径，以使所述应用程序能够加载所述补丁位置路径下的所述目标修复对象。

一种可选的实施方式中，所述确定所述目标修复对象是否已被加载到运行内存时，确定模块62用于：

确定系统锁所在的锁位置路径，其中，所述系统锁为加载所述目标修复对象过程中所需使用的锁；

基于所述锁位置路径加载所述系统锁，并在加载所述系统锁后，获取所述应用程序对应的已被加载到运行内存的各对象；

根据获取的所述各对象和所述目标修复对象的比对，确定所述目标修复对象是否已被加载到运行内存。

一种可选的实施方式中，所述确定系统锁所在的锁位置路径时，确定模块62用于：

获取所述系统锁对应的系统文件；

对所述系统文件进行解析，并根据所述系统锁的符号名，从解析后的所述系统文件中确定出所述系统锁所在的锁位置路径。

一种可选的实施方式中，所述确定系统锁所在的锁位置路径时，确定模块62用于：

执行调用加载操作或卸载操作；其中，在执行所述加载操作或所述卸载操作时会加载所述系统锁；

遍历所述加载操作或卸载操作所对应的调用栈信息，确定所述系统锁所在的锁位置路径。

一种可选的实施方式中，所述获取所述应用程序对应的已被加载到运行内存的各对象时，确定模块62用于：

通过预设目标接口，访问所述运行内存并在所述运行内存中，读取所述应用程序对应的已被加载到所述运行内存的各对象。

一种可选的实施方式中，所述获取所述应用程序对应的已被加载到运行内存的各对象时，确定模块62用于：

确定所述应用程序对应的各应用进程；

读取所述各应用进程的运行文件，并获得所述应用程序对应的已被加载到运行内存的各对象，其中，所述运行文件中至少记录有所加载的各对象描述信息。

一种可选的实施方式中，还包括第二处理模块64，用于：

在确定所述目标修复对象已被加载到运行内存的情况下，记录所述目标修复对象的补丁包所在的补丁位置路径；

在所述应用程序关闭并重新运行后，拦截所述目标修复对象的加载流程，并修改为指向所述补丁位置路径，以使所述应用程序能够加载所述补丁位置路径下的所述目标修复对象。

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

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

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

获得所述应用程序的待修复SDK的补丁包，其中，所述补丁包中包括目标修复对象的补丁包，所述目标修复对象为所述待修复SDK中需热修复的对象；

确定所述目标修复对象是否已被加载到运行内存；

在确定所述目标修复对象未被加载到运行内存的情况下，在所述应用程序运行过程中，拦截所述目标修复对象的加载流程，并将所述目标修复对象的加载路径，修改为指向所述目标修复对象的补丁包所在的补丁位置路径，以使所述应用程序能够加载所述补丁位置路径下的所述目标修复对象。

一种可选的实施方式中，所述确定所述目标修复对象是否已被加载到运行内存时，处理器71用于：

确定系统锁所在的锁位置路径，其中，所述系统锁为加载所述目标修复对象过程中所需使用的锁；

基于所述锁位置路径加载所述系统锁，并在加载所述系统锁后，获取所述应用程序对应的已被加载到运行内存的各对象；

根据获取的所述各对象和所述目标修复对象的比对，确定所述目标修复对象是否已被加载到运行内存。

一种可选的实施方式中，所述确定系统锁所在的锁位置路径时，处理器71用于：

获取所述系统锁对应的系统文件；

对所述系统文件进行解析，并根据所述系统锁的符号名，从解析后的所述系统文件中确定出所述系统锁所在的锁位置路径。

一种可选的实施方式中，所述确定系统锁所在的锁位置路径时，处理器71用于：

执行调用加载操作或卸载操作；其中，在执行所述加载操作或所述卸载操作时会加载所述系统锁；

遍历所述加载操作或卸载操作所对应的调用栈信息，确定所述系统锁所在的锁位置路径。

一种可选的实施方式中，所述获取所述应用程序对应的已被加载到运行内存的各对象时，处理器71用于：

通过预设目标接口，访问所述运行内存并在所述运行内存中，读取所述应用程序对应的已被加载到所述运行内存的各对象。

一种可选的实施方式中，所述获取所述应用程序对应的已被加载到运行内存的各对象时，处理器71用于：

确定所述应用程序对应的各应用进程；

读取所述各应用进程的运行文件，并获得所述应用程序对应的已被加载到运行内存的各对象，其中，所述运行文件中至少记录有所加载的各对象描述信息。

一种可选的实施方式中，处理器71还用于：

在确定所述目标修复对象已被加载到运行内存的情况下，记录所述目标修复对象的补丁包所在的补丁位置路径；

在所述应用程序关闭并重新运行后，拦截所述目标修复对象的加载流程，并修改为指向所述补丁位置路径，以使所述应用程序能够加载所述补丁位置路径下的所述目标修复对象。

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

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

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

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

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

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

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

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

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

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

Claims (10)

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

获得应用程序的待修复软件开发功能包SDK的补丁包，其中，所述补丁包中包括目标修复对象的补丁包，所述目标修复对象为所述待修复SDK中需热修复的对象；

确定所述目标修复对象是否已被加载到运行内存；

在确定所述目标修复对象未被加载到运行内存的情况下，在所述应用程序运行过程中，拦截所述目标修复对象的加载流程，并将所述目标修复对象的加载路径，修改为指向所述目标修复对象的补丁包所在的补丁位置路径，以使所述应用程序能够加载所述补丁位置路径下的所述目标修复对象。

2.根据权利要求1所述的方法，其特征在于，所述确定所述目标修复对象是否已被加载到运行内存，包括：

确定系统锁所在的锁位置路径，其中，所述系统锁为加载所述目标修复对象过程中所需使用的锁；

基于所述锁位置路径加载所述系统锁，并在加载所述系统锁后，获取所述应用程序对应的已被加载到运行内存的各对象；

根据获取的所述各对象和所述目标修复对象的比对，确定所述目标修复对象是否已被加载到运行内存。

3.根据权利要求2所述的方法，其特征在于，所述确定系统锁所在的锁位置路径，包括：

获取所述系统锁对应的系统文件；

对所述系统文件进行解析，并根据所述系统锁的符号名，从解析后的所述系统文件中确定出所述系统锁所在的锁位置路径。

4.根据权利要求2所述的方法，其特征在于，所述确定系统锁所在的锁位置路径，包括：

执行调用加载操作或卸载操作；其中，在执行所述加载操作或所述卸载操作时会加载所述系统锁；

遍历所述加载操作或卸载操作所对应的调用栈信息，确定所述系统锁所在的锁位置路径。

5.根据权利要求2-4任一项所述的方法，其特征在于，所述获取所述应用程序对应的已被加载到运行内存的各对象，包括：

通过预设目标接口，访问所述运行内存并在所述运行内存中，读取所述应用程序对应的已被加载到所述运行内存的各对象。

6.根据权利要求2-4任一项所述的方法，其特征在于，所述获取所述应用程序对应的已被加载到运行内存的各对象，包括：

确定所述应用程序对应的各应用进程；

读取所述各应用进程的运行文件，并获得所述应用程序对应的已被加载到运行内存的各对象，其中，所述运行文件中至少记录有所加载的各对象描述信息。

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

在确定所述目标修复对象已被加载到运行内存的情况下，记录所述目标修复对象的补丁包所在的补丁位置路径；

在所述应用程序关闭并重新运行后，拦截所述目标修复对象的加载流程，并修改为指向所述补丁位置路径，以使所述应用程序能够加载所述补丁位置路径下的所述目标修复对象。

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

获得模块，用于获得所述应用程序的待修复软件开发功能包SDK的补丁包，其中，所述补丁包中包括目标修复对象的补丁包，所述目标修复对象为所述待修复SDK中需热修复的对象；

确定模块，用于确定所述目标修复对象是否已被加载到运行内存；

第一处理模块，用于在确定所述目标修复对象未被加载到运行内存的情况下，在所述应用程序运行过程中，拦截所述目标修复对象的加载流程，并将所述目标修复对象的加载路径，修改为指向所述目标修复对象的补丁包所在的补丁位置路径，以使所述应用程序能够加载所述补丁位置路径下的所述目标修复对象。

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

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