CN111752735A - 一种sdk异常排查方法及装置、计算机可读存储介质 - Google Patents

Abstract

本发明公开了一种SDK异常排查方法，所述方法包括：获取APP运行时的SDK异常信息；根据所述SDK异常信息修复SDK代码，将修复后的所述SDK代码打包生成修复后的dex文件；重新启动所述APP，调用SDK启动接口，加载所述修复后的dex文件，并将所述修复后的dex文件合并至原始SDK后并执行。本发明还提供了一种SDK异常排查装置、计算机可读存储介质。本发明可以实现在无需APP开发者协助的情况下，完成对SDK异常问题的排查、修复、验证，从而减少SDK开发者与APP开发者的沟通。

Description

一种SDK异常排查方法及装置、计算机可读存储介质

技术领域

本发明涉及计算机技术领域，特别涉及一种基于SDK异常排查方法及装置、计算机可读存储介质。

背景技术

SDK(Software Development Kit，软件开发工具包)是为特定的软件包、软件框架、硬件平台、操作系统等建立应用软件时的开发工具的集合。在SDK嵌入APP(Application，应用软件)后，APP的运营过程中，SDK可能会出现异常，SDK开发者则需及时排查APP中SDK的异常问题。

现有的SDK异常问题排查方法。通常为：SDK嵌入APP后，若SDK出现异常，则将异常信息反馈给SDK开发者。SDK开发者根据异常信息向SDK中添加测试代码，并打包发送给APP开发者重新嵌入并执行，在执行过程中，APP开发者查看APP运营过程中SDK是否仍然存在异常，若存在则将异常信息反馈给SDK开发者，然后继续反复执行上述操作过程，直至SDK的异常问题修复。在实现本发明的过程中，发明人发现现有的SDK异常问题排查方法至少存在以下问题：

为了定位以及修复异常问题，并验证异常问题的修复结果，需要APP开发者反复协助SDK开发者向APP中重新嵌入修复后的SDK，并需要双方进行反复沟通。

发明内容

为了解决现有技术中的问题，本发明实施例提供了一种SDK异常排查方法及装置、计算机可读存储介质。所述技术方案如下：

第一方面，提供了一种SDK异常排查方法，所述方法包括：

获取APP运行时的SDK异常信息；

根据所述SDK异常信息修复SDK代码，将修复后的所述SDK代码打包生成修复后的dex文件；

重新启动所述APP，调用SDK启动接口，加载所述修复后的dex文件，并将所述修复后的dex文件合并至原始SDK后形成新SDK并执行；

根据所述新SDK的执行结果与执行过程日志，验证所述SDK异常信息是否修复。

进一步的，在将修复后的所述SDK代码打包生成所述修复后的dex文件之后，所述方法还包括：将所述修复后的dex文件发送至外部存储空间。

进一步的，所述调用SDK启动接口，加载所述修复后的dex文件，并将所述修复后的dex文件合并至原始SDK后形成新SDK并执行具体包括：

判断所述外部存储空间是否存在所述修复后的dex文件；

若存在，则通过DexClassLoader加载所述修复后的dex文件，通过PathClassLoader加载所述原始SDK；

将所述修复后的dex文件合并至所述原始SDK，形成新SDK，其中所述修复后的dex文件中包含的类置于所述原始SDK所包含的类之前；

将所述新SDK重新赋值给所述PathClassLoader加载并执行。

进一步的，在获取APP运行时的SDK异常信息之前，所述方法还包括：执行所述原始SDK或者所述新的SDK，并判断是否异常。

进一步的，所述根据所述SDK异常信息修复SDK代码，包括：

根据所述原始SDK的代码混淆规则，生成所述修复后的dex文件。

第二方面，提供了一种SDK异常排查装置，所述装置包括异常记录模块、文件生成模块、文件加载模块以及异常验证模块：

所述异常记录模块，用于获取APP运行时的SDK异常信息；

所述文件生成模块，用于根据所述SDK异常信息修复SDK代码，将修复后的所述SDK代码打包生成修复后的dex文件；

所述文件加载模块，用于调用SDK启动接口，加载所述修复后的dex文件，并将所述修复后的dex文件合并至原始SDK后形成新SDK并执行；

根据所述新SDK的执行结果与执行过程日志，验证所述SDK异常信息是否修复。

进一步的，所述文件生成模块还用于将所述修复后的dex文件发送至外部存储空间。

进一步的，所述文件加载模块还用于：

判断所述外部存储空间是否存在所述修复后的dex文件；

若存在，则通过DexClassLoader加载所述修复后的dex文件，通过PathClassLoader加载所述原始SDK；

将所述修复后的dex文件合并至所述原始SDK，形成新SDK，其中所述修复后的dex文件中包含的类置于所述原始SDK所包含的类之前；

将所述新SDK重新赋值给所述PathClassLoader加载并执行

进一步的，所述文件加载模块还用于，执行所述原始SDK或者所述新的SDK，并判断是否异常。

进一步的，所述文件生成模块还用于，根据所述原始SDK的代码混淆规则，生成所述修复后的dex文件。

第三方面，提供了一种计算机可读存储介质，所述存储介质中存储有至少一条指令、至少一段程序、代码集或指令集，所述至少一条指令、所述至少一段程序、所述代码集或指令集由处理器加载并执行以实现第一方面所述的SDK异常排查方法。

本发明实施例提供的技术方案带来的有益效果是：在进行SDK异常问题排查时，通过控制APP重启复现SDK的执行过程，并在执行过程中动态加载修复后的dex文件。可以实现在无需APP开发者协助的情况下，完成对SDK异常问题的排查、修复、验证，从而减少SDK开发者与APP开发者的沟通。再者，编译修复后的dex文件时，可以参考开发原编译SDK的原始代码生成的混淆文件，使得，修复后的dex文件与原始SDK的混淆规则一致，可以避免代码混淆引入其它异常信息，从而减小SDK异常问题的排查难度。另外，通过控制APP重启复现SDK的执行过程，本发明实施例不受APP加固技术的影响，在SDK异常排查过程中，可以避免通过反编译APP的方式了解SDK调用方式，同样的也降低了SDK异常问题的排查难度。

附图说明

为了更清楚地说明本发明实施例中的技术方案，下面将对实施例描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1是本发明实施例中SDK异常排查方法流程图；

图2是本发明实施例中SDK异常排查装置的模块示意图；

图3是本发明实施例中SDK异常排查装置的结构示意图。

具体实施方式

下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。

通常而言，SDK开发者可以根据APP开发者所提出的业务需求，开发出与业务需求功能一致的SDK提供给APP开发者嵌入APP中。SDK开发者可以通过Android Studio或者Eclipse开发工具，将SDK打包为jar(Java Archive)包或者aar(Android Archive)包，连同SDK示例代码和SDK接入文档上传至SDK开发者网站供APP开发者下载。APP开发者下载SDK后，同样通过Android Studio或者Eclipse开发工具将SDK嵌入APP。比如可以通过Eclipse开发工具中导入jar包，并安装adt(Android Development Tools)插件，使得Eclipse开发工具可以和SDK建立连接。然后，按照SDK接入文档修改配置文件后，即可完成SDK嵌入APP。

APP开发者在将SDK嵌入APP之后，在APP运行过程中，如果所嵌入的SDK发生异常，就需要对SDK异常进行排查。由于异常发生在APP内，SDK开发者并没有APP的源代码，所以无法直接从代码层面定位并修复异常；也无法模拟APP开发者的环境复现问题，只能运行发生异常的APP进行观察和推测。对于经过加固的APP，SDK开发者无法通过对APP反编译了解SDK的调用方式，从而增大了SDK异常问题的排查难度。即使SDK开发者可以对APP进行反编译，反编译后的代码可能进行过代码混淆处理，同样也增大了SDK的异常问题的排查难度。

因此，本发明实施例提供了SDK异常排查方法，获取APP运行时的SDK异常信息；根据所述SDK异常信息修复SDK代码，将修复后的所述SDK代码打包生成修复后的dex文件；重新启动所述APP，调用SDK启动接口，加载所述修复后的dex文件，并将所述修复后的dex文件合并至原始SDK后形成新SDK并执行，其中，原始SDK是指SDK开发者初始发布的SDK代码程序，且由APP开发者已经嵌入其APP内，亦指下文中所涉及的原始SDK，后续不再赘述。形成新SDK后根据新SDK的执行结果与执行过程日志，可以验证SDK异常信息是否修复。具体的排查流程请参阅图1，本发明实施例提供的SDK异常排查方法的执行步骤如下：

步骤S101及S102：启动APP，并调用SDK启动接口，以启动SDK。

在APP接收到启动指令或者重启指令后，将会执行本步骤。

步骤S103：判断外部存储空间是否存在修复后的dex文件。

在一个可选的实施例中，可以通过在SDK启动接口所增加的dex文件检测程序，判断外部存储空间中是否存在修复后的dex文件，若存在，则首先执行步骤S104及S105，然后执行S106及S107；若不存在，则直接执行步骤S106及S107。

在本实施方式中，如果APP为首次启动，SDK代码程序从未执行过的情况下，无法发现SDK异常，即不存在修复后的dex文件。外部存储空间可以是安装有APP的任意设备的SD卡(Secure Digital Memory Card)，也可以是其它存储介质，本发明对此不作限定。

步骤S104及S105：调用SDK启动接口，加载修复后的dex文件，并将修复后的dex文件合并至原始SDK后并执行。

在本实施例中，修复后的dex文件是根据异常信息生成的，并存储在外部空间中，可以通过基于Android平台的类加载器DexClassLoader动态加载。DexClassLoader和PathClassLoader继承自父类BaseDexClassLoader，DexClassLoader用于加载外部存储空间中的修复后的dex文件，PathClassLoader用于加载APP本身已安装的APK文件，即加载APK文件中的原始SDK或者dex文件。具体而言，DexClassLoader所加载的为修复后的dex数组，PathClassLoader所加载的为原始dex数组。首先，在SDK的启动流程中，通过增加的dex文件检测程序，检测外部存储空间中是否存在修复后的dex文件，若存在，则通过DexClassLoader加载修复后的dex数组。然后，将修复后的dex数组与原始dex数组合并形成新数组(也就是将dex文件合并至原始SDK，形成新SDK)，新数组中修复后的dex数组置于原始dex数组之前，并将新数组重新赋值给PathClassLoader加载，这样，可以保证外部存储空间中的修复后的dex文件优先于异常SDK执行，并且设置新数组中在执行修复后的dex数组之后，新数组中后续的原始dex数组将不再执行。从而实现替换异常SDK的代码程序。

步骤S106及S107，执行SDK，并判断SDK是否发生异常，如果发生异常则依次执行步骤S108、S109、S110；如果没有发生异常，则结束SDK异常排查。

具体而言，嵌入SDK后的APP在运行过程中，若出现卡顿、崩溃、数据传输故障等现象，则表示SDK发生了异常。

步骤S108，获取SDK的异常信息。

在一个可选的实施例中，在SDK开发者提供的SDK中预先定义有异常捕捉器，以监控SDK是否发生异常，并在发生异常时获取SDK的异常信息，该异常捕捉器可以是try catch程序。异常捕捉器在获取到异常信息后可以将异常信息记录在APP后台程序中，后续可以通过工单反馈给SDK开发者；也可以将异常信息直接上报至后台服务器中，由后台服务器定时汇总异常信息，一并反馈给SDK开发者。无论是采用哪种方式将SDK异常信息反馈给SDK开发者，在进行SDK异常信息反馈时，均需上报发生SDK异常的APP版本信息，SDK开发者可以根据汇总的异常信息以及APP版本信息修复SDK异常问题。

步骤S109，根据所述SDK异常信息修复SDK代码，将修复后的所述SDK代码打包生成dex文件。

在一个可选的实施例中，SDK开发者收到异常信息以后，根据异常信息排查出问题，然后修复出现问题的SDK代码，并将修改代码后的SDK重新打包为修复后的dex文件。

在一个可选的实施例中，在根据异常信息生成修复后的dex文件后，可以将修复后的dex文件打包发送至外部存储空间，即发送至安装有APP的任意设备的SD卡或者其它存储介质，其中APP信息无需APP开发方提供，可以由SDK开发方通过APP应用市场或者其它网络渠道下载。

此外，由于在原始SDK的编译过程中可能进行了代码混淆处理，则在修改出现问题的SDK代码时，还需参考原始SDK的代码混淆规则，修改出现问题的SDK代码，这样可以使修复后的dex文件与原始SDK的混淆规则一致，可以避免代码混淆引入其它异常信息而影响SDK异常验证，而且被混淆的代码程序便于理解和阅读。从而可以减小SDK的异常问题的排查难度。

步骤S110，发出重启指令。

在一个可选的实施例中，将修复后的dex文件发送至外部存储空间后，需重新启动SDK发生异常的APP，以复现调用SDK的过程。在重新启动SDK发生异常的APP后，则返回执行步骤S101。

在本实施例中，在进行SDK异常问题排查时，采用DexClassLoader动态加载外部存储空间中的dex文件的方案，可以避免APP开发者协助进行SDK的重新嵌入，从而减少SDK开发者与APP开发者的沟通成本。另外，该方案避免了对加固的软件产品的反编译过程，从而也可以降低SDK异常问题的排查难度。

SDK开发者重新启动发生SDK异常的APP的方式，可以是通过调试设备向APP发送重启指令，APP接收并执行重启指令后，重新调用SDK启动接口。从而实现在无需APP开发者协助的情况下重新启动SDK，减少了SDK开发者与APP开发者的沟通。

在本实施方式中，在SDK异常问题修复之后，需验证修复结果，即监控修复后的APP是否再次出现运行卡顿、崩溃以及数据传输故障等现象。可以通过APP后台或者后台服务器中是否再次反馈SDK的异常信息，即新SDK执行后的执行结果。还可以在新SDK的执行过程中，根据新SDK的执行过程日志，确定是否修复成功。

请参阅图2，本发明实施例提供的SDK异常排查装置，装置包括异常记录模块201、文件生成模块202、文件加载模块203以及异常验证模块204：

异常记录模块201，用于获取APP运行时的SDK异常信息；

文件生成模块202，用于根据SDK异常信息修复SDK代码，将修复后的SDK代码打包生成修复后的dex文件；

文件加载模块203，用于调用SDK启动接口，加载修复后的dex文件，并将修复后的dex文件合并至原始SDK后形成新SDK并执行；

异常记录模块204，用于根据所述新SDK的执行结果与执行过程日志，验证所述SDK异常信息是否修复。

进一步的，文件生成模块202还用于将修复后的dex文件发送至外部存储空间。

进一步的，文件加载模块203还用于：

判断外部存储空间是否存在修复后的dex文件；

若存在，则通过DexClassLoader加载修复后的dex文件，通过PathClassLoader加载原始SDK；

将修复后的dex文件合并至原始SDK，形成新SDK，其中所述修复后的dex文件中包含的类置于所述原始SDK所包含的类之前；

将新SDK重新赋值给PathClassLoader加载并执行

进一步的，文件加载模块203还用于，执行原始SDK或者所述新SDK，并判断是否异常。

进一步的，文件生成模块202还用于，根据原始SDK的代码混淆规则，生成所述修复后的dex文件。

由上可见，本发明实施例提供的SDK异常排查方法及装置。在进行SDK异常问题排查时，通过控制APP重启复现SDK的执行过程，并在执行过程中动态加载修复后的dex文件。可以实现在无需APP开发者协助的情况下，完成对SDK异常问题的排查、修复、验证，从而减少SDK开发者与APP开发者的沟通。再者，编译修复后的dex文件时，可以参考开发原编译SDK的原始代码生成的混淆文件，使得，修复后的dex文件与原始SDK的混淆规则一致，可以避免代码混淆引入其它异常信息，从而减小SDK异常问题的排查难度。另外，通过控制APP重启复现SDK的执行过程，本发明实施例不受APP加固技术的影响，在SDK异常排查过程中，可以避免通过反编译APP的方式了解SDK调用方式，同样的也降低了SDK异常问题的排查难度。

图3是本发明实施例提供的SDK异常排查装置的结构示意图。该SDK异常排查装置1100可因配置或性能不同而产生比较大的差异，可以包括一个或一个以上中央处理器1122(例如，一个或一个以上处理器)和存储器1132，一个或一个以上存储应用程序1142或数据1144的存储介质1130(例如一个或一个以上海量存储设备)。其中，存储器1132和存储介质1130可以是短暂存储或持久存储。存储在存储介质1130的程序可以包括一个或一个以上模块(图示没标出)，每个模块可以包括对SDK异常排查装置1100中的一系列指令操作。更进一步地，中央处理器1122可以设置为与存储介质1130通信，在SDK异常排查装置1100上执行存储介质1130中的一系列指令操作。

SDK异常排查装置1100还可以包括一个或一个以上电源1129，一个或一个以上有线或无线网络接口1150，一个或一个以上输入输出接口1158，一个或一个以上键盘1156，和/或，一个或一个以上操作系统1141，例如Windows Server，Mac OS X，Unix，Linux，FreeBSD等等。

SDK异常排查装置1100可以包括有存储器，以及一个或者一个以上的程序，其中一个或者一个以上程序存储于存储器中，且经配置以由一个或者一个以上处理器执行所述一个或者一个以上程序包含用于进行上述SDK嵌入特征的指令。

本发明实施例提供的SDK异常排查装置可以实现如图1所示的SDK异常排查方法相同的技术效果，在此不再赘述。

以上所描述的装置实施例仅仅是示意性的，其中所述分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本实施例方案的目的。本领域技术人员在不付出创造性劳动的情况下，即可以理解并实施。

通过以上实施的实施方式的描述，本领域的技术人员可以清楚地了解到各实施方式可借助软件加必需的通用硬件平台的方式来实现，当然也可以通过硬件。基于这样的理解，上述技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品可以存储在计算机可读存储介质中，如ROM/RAM、磁碟、光盘等，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行各个实施例或者实施例的某些部分所述的方法。

以上所述仅为本发明的较佳实施例，并不用以限制本发明，凡在本发明的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。

Claims (11)

1.一种SDK异常排查方法，其特征在于，所述方法包括：

获取APP运行时的SDK异常信息；

根据所述SDK异常信息修复SDK代码，将修复后的所述SDK代码打包生成修复后的dex文件；

重新启动所述APP，调用SDK启动接口，加载所述修复后的dex文件，并将所述修复后的dex文件合并至原始SDK后形成新SDK并执行；

根据所述新SDK的执行结果与执行过程日志，验证所述SDK异常信息是否修复。

2.根据权利要求1所述的方法，其特征在于，在将修复后的所述SDK代码打包生成所述修复后的dex文件之后，所述方法还包括：将所述修复后的dex文件发送至外部存储空间。

3.根据权利要求2所述的方法，其特征在于，所述调用SDK启动接口，加载所述修复后的dex文件，并将所述修复后的dex文件合并至原始SDK后形成新SDK并执行具体包括：

判断所述外部存储空间是否存在所述修复后的dex文件；

若存在，则通过DexClassLoader加载所述修复后的dex文件，通过PathClassLoader加载所述原始SDK；

将所述修复后的dex文件合并至所述原始SDK，形成新SDK，其中所述修复后的dex文件中包含的类置于所述原始SDK所包含的类之前；

将所述新SDK重新赋值给所述PathClassLoader加载并执行。

4.根据权利要求3所述的方法，其特征在于，在获取APP运行时的SDK异常信息之前，所述方法还包括：执行所述原始SDK或者所述新SDK，并判断是否异常。

5.根据权利要求1所述的方法，其特征在于，所述根据所述SDK异常信息修复SDK代码，包括：

根据所述原始SDK的代码混淆规则，生成所述修复后的dex文件。

6.一种SDK异常排查装置，其特征在于，所述装置包括异常记录模块、文件生成模块、文件加载模块以及异常验证模块：

所述异常记录模块，用于获取APP运行时的SDK异常信息；

所述文件生成模块，用于根据所述SDK异常信息修复SDK代码，将修复后的所述SDK代码打包生成修复后的dex文件；

所述文件加载模块，用于调用SDK启动接口，加载所述修复后的dex文件，并将所述修复后的dex文件合并至原始SDK后形成新SDK并执行；

所述异常验证模块，用于根据所述新SDK的执行结果与执行过程日志，验证所述SDK异常信息是否修复。

7.根据权利要求6所述的装置，其特征在于，所述文件生成模块还用于将所述修复后的dex文件发送至外部存储空间。

8.根据权利要求7所述的装置，其特征在于，所述文件加载模块还用于：

判断所述外部存储空间是否存在所述修复后的dex文件；

若存在，则通过DexClassLoader加载所述修复后的dex文件，通过PathClassLoader加载所述原始SDK；

将所述修复后的dex文件合并至所述原始SDK，形成新SDK，其中所述修复后的dex文件中包含的类置于所述原始SDK所包含的类之前；

将所述新SDK重新赋值给所述PathClassLoader加载并执行。

9.根据权利要求8所述的装置，其特征在于，所述文件加载模块还用于，执行所述原始SDK或者所述新SDK，并判断是否异常。

10.根据权利要求6所述的装置，其特征在于，所述文件生成模块还用于，根据所述原始SDK的代码混淆规则，生成所述修复后的dex文件。

11.一种计算机可读存储介质，所述存储介质中存储有至少一条指令、至少一段程序、代码集或指令集，所述至少一条指令、所述至少一段程序、所述代码集或指令集由处理器加载并执行以实现如权利要求1至5任一项所述的SDK异常排查方法。

Images