CN107861865A - Sdk定位方法、设备及计算机可读存储介质 - Google Patents

Abstract

本发明公开了一种软件开发包SDK定位方法，包括以下步骤：监测属主APP是否发生崩溃，其中，属主APP中接入有多个SDK；当属主APP发生崩溃时，获取崩溃内容信息并从中提取崩溃方法名；以所述崩溃方法名为关键字，搜索系统文件目录中与所述崩溃方法名匹配的文件名或类库名；当匹配成功时，输出所述文件名或类库名的路径信息以供定位对应的SDK。本发明还公开了一种SDK定位设备及计算机可读存储介质。本发明中，当存属主APP发生崩溃时，可以快速定位发生崩溃的SDK。

Description

SDK定位方法、设备及计算机可读存储介质

技术领域

本发明涉及应用程序处理技术领域，尤其涉及一种SDK定位方法、设备及计算机可读存储介质。

背景技术

目前，为减少程序开发工作量，通常各APP都会根据自身功能需要而接入多个现成的第三方SDK(Software Development Kit，软件开发工具包)，比如由第三方提供的支付SDK、定位SDK等。

现有技术中，当第三方SDK发生崩溃时，通常仅仅只会显示一些基本的崩溃信息而无法简便快速地定位到具体的第三方SDK。因此，由于不能及时排除第三方SDK导致的崩溃，进而导致属主APP运行不稳定，同时也不便于第三方SDK提供商进行技术改进。

发明内容

本发明的主要目的在于提供一种SDK定位方法、设备及计算机可读存储介质，旨在解决如何在属主APP发生崩溃时简便快速定位SDK的技术问题。

为实现上述目的，本发明提供一种SDK的定位方法，所述定位方法包括以下步骤：

监测属主APP是否发生崩溃，其中，属主APP中接入有多个SDK；

当属主APP发生崩溃时，获取崩溃内容信息并从中提取崩溃方法名；

以所述崩溃方法名为关键字，搜索系统文件目录中与所述崩溃方法名匹配的文件名或类库名；

当匹配成功时，输出所述文件名或类库名的路径信息以供定位对应的SDK。

可选地，所述监测属主APP是否发生崩溃的步骤包括：

在属主APP运行时，启动属主APP中的守护进程；

通过所述守护进程，向属主APP的主进程中注册各类崩溃信息对应的信号，并监测属主APP的主进程中是否存在所述信号；

若存在所述信号，则确定属主APP发生崩溃。

可选地，所述当属主APP发生崩溃时，获取崩溃内容信息并从中提取崩溃方法名的步骤包括：

当属主APP发生崩溃时，通过所述守护进程与所述主进程进行信息交互，确定崩溃进程，并获取所述崩溃进程对应的崩溃内容信息；

从所述崩溃内容信息中，提取崩溃方法名。

可选地，所述以所述崩溃方法名为关键字，搜索系统文件目录中与所述崩溃方法名匹配的文件名或类库名包括：

以所述崩溃方法名为关键字，基于GREP命令，搜索系统文件目录中与所述崩溃方法名匹配的文件名或类库名。

可选地，所述定位方法还包括：

当匹配失败时，从所述崩溃内容信息中提取崩溃基础特征；

基于所述崩溃基础特征，计算本次崩溃对应的崩溃哈希值；

查找崩溃数据库中是否存在与所述崩溃哈希值匹配的崩溃记录；

若存在，则基于该崩溃记录，确定本次崩溃对应的SDK。

可选地，所述定位方法采用如下公式计算崩溃哈希值：

S＝MD5(A₁&A₂…A_n-1&A_n)，其中，S表示崩溃哈希值，MD5为哈希算法函数，A_n表示崩溃基础特征。

可选地，所述崩溃基础特征包括：崩溃所在模块名、崩溃所在进程名、崩溃所在函数名、崩溃的异常类型。

可选地，所述定位方法还包括：

在定位到发生崩溃的SDK后，将获取的崩溃内容信息发送至该SDK的开发方。

进一步地，为实现上述目的，本发明还提供一种SDK定位设备，所述SDK定位设备包括：存储器、处理器及存储在所述存储器上并可在所述处理器上运行的SDK定位程序，所述SDK定位程序被所述处理器执行时实现如上述任一项所述的定位方法的步骤。

进一步地，为实现上述目的，本发明还提供一种计算机可读存储介质，所述计算机可读存储介质上存储有SDK定位程序，所述SDK定位程序被处理器执行时实现如上述任一项所述的SDK定位方法的步骤。

本发明中，在属主APP发生崩溃时，获取崩溃内容信息并从中提取崩溃方法名，进而再以崩溃方法名为关键字，搜索系统文件目录中与之匹配的文件名或类库名，并在匹配成功时，输出对应文件名或类库名的路径信息，进而根据该路径信息即可简便快速定位对应的SDK，并将问题反馈至SDK提供商以供进行技术改进，从而提升属主APP运行的稳定性，进而提升用户使用体验。

附图说明

图1为本发明实施例方案涉及硬件运行环境的SDK定位设备的结构示意图；

图2为本发明SDK定位方法一实施例的流程示意图；

图3为本发明SDK定位方法另一实施例的流程示意图。

本发明目的的实现、功能特点及优点将结合实施例，参照附图做进一步说明。

具体实施方式

应当理解，此处所描述的具体实施例仅用以解释本发明，并不用于限定本发明。

如图1所示，图1是本发明实施例方案涉及的硬件运行环境的SDK定位设备的结构示意图。

本发明实施例SDK定位设备可以是智能手机、平板电脑、电子书阅读器、便携计算机等具有显示功能的设备。

如图1所示，该SDK定位设备可以包括：处理器1001，例如CPU，通信总线1002、用户接口1003，网络接口1004，存储器1005。其中，通信总线1002用于实现这些组件之间的连接通信。用户接口1003可以包括显示屏(Display)、输入单元比如键盘(Keyboard)，可选用户接口1003还可以包括标准的有线接口、无线接口。网络接口1004可选的可以包括标准的有线接口、无线接口(如WI-FI接口)。存储器1005可以是高速RAM存储器，也可以是稳定的存储器(non-volatile memory)，例如磁盘存储器。存储器1005可选的还可以是独立于前述处理器1001的存储设备。

可选地，SDK定位设备还可以包括摄像头、RF(Radio Frequency，射频)电路，传感器、音频电路、WiFi模块等等。

本领域技术人员可以理解，图1中示出的SDK定位设备结构并不构成对SDK定位设备的限定，可以包括比图示更多或更少的部件，或者组合某些部件，或者不同的部件布置。

如图1所示，作为一种计算机可读存储介质的存储器1005中可以包括操作系统、网络通信模块、用户接口模块以及SDK定位程序。其中，操作系统是管理和控制SDK定位设备与软件资源的程序，支持网络通信模块、用户接口模块、SDK定位程序以及其他程序或软件的运行；网络通信模块用于管理和控制网络接口1002；用户接口模块用于管理和控制用户接口1003。

在图1所示的SDK定位设备中，网络接口1004主要用于连接系统后台，与系统后台进行数据通信；用户接口1003主要用于连接客户端(用户端)，与客户端进行数据通信；SDK定位设备通过处理器1001调用存储器1005中存储的SDK定位程序，并执行以下步骤：

监测属主APP是否发生崩溃，其中，属主APP中接入有多个SDK；

当属主APP发生崩溃时，获取崩溃内容信息并从中提取崩溃方法名；

以所述崩溃方法名为关键字，搜索系统文件目录中与所述崩溃方法名匹配的文件名或类库名；

当匹配成功时，输出所述文件名或类库名的路径信息以供定位对应的SDK。

进一步地，所述SDK定位设备通过处理器1001调用存储器1005中存储的SDK定位程序，以执行以下操作：

在属主APP运行时，启动属主APP中的守护进程；

通过所述守护进程，向属主APP的主进程中注册各类崩溃信息对应的信号，并监测属主APP的主进程中是否存在所述信号；

若存在所述信号，则确定属主APP发生崩溃。

进一步地，所述SDK定位设备通过处理器1001调用存储器1005中存储的SDK定位程序，以执行以下操作：

当属主APP发生崩溃时，通过所述守护进程与所述主进程进行信息交互，确定崩溃进程，并获取所述崩溃进程对应的崩溃内容信息；

从所述崩溃内容信息中，提取崩溃方法名。

进一步地，所述SDK定位设备通过处理器1001调用存储器1005中存储的SDK定位程序，以执行以下操作：

以所述崩溃方法名为关键字，基于GREP命令，搜索系统文件目录中与所述崩溃方法名匹配的文件名或类库名。

进一步地，所述SDK定位设备通过处理器1001调用存储器1005中存储的SDK定位程序，以执行以下操作：

当匹配失败时，从所述崩溃内容信息中提取崩溃基础特征；

基于所述崩溃基础特征，计算本次崩溃对应的崩溃哈希值；

查找崩溃数据库中是否存在与所述崩溃哈希值匹配的崩溃记录；

若存在，则基于该崩溃记录，确定本次崩溃对应的SDK。

进一步地，所述SDK定位设备通过处理器1001调用存储器1005中存储的SDK定位程序，以执行以下操作：

在定位到发生崩溃的SDK后，将获取的崩溃内容信息发送至该SDK的开发方。

基于上述SDK定位设备硬件结构，提出本发明SDK定位方法的各个实施例。

参照图2，图2为本发明SDK定位方法一实施例的流程示意图。本实施例中，SDK定位方法包括：

步骤S10，监测属主APP是否发生崩溃，其中，属主APP中接入有多个SDK；

本实施例中，通过监测属主APP的运行，用以确定当前是否发生崩溃，对于监测判断属主APP是否发生崩溃的方式不限，比如检测APP是否为正常退出，如果不是，则确定当前APP发生了崩溃，或者检测是否存在系统输出崩溃信息，若存在则可确定当前发生了崩溃。

此外，本实施例汇总，属主APP中接入有多个SDK，该SDK既可以是属主APP方自己开发的，也可以是由第三方提供的。例如，APP想集成支付、定位功能，则该APP可以接入第三方提供的支付SDK、定位SDK等。

步骤S20，当属主APP发生崩溃时，获取崩溃内容信息并从中提取崩溃方法名；

本实施例中，对于获取崩溃内容信息的方式不限。比如在监测APP运行过程中，直接获取崩溃内容信息，或者从APP所在系统的崩溃日志中提取。

可选的，在一实施例中，当属主APP发生崩溃时，获取当前崩溃对应的崩溃日志并解析，得到崩溃内容信息；从崩溃内容信息中，提取崩溃方法名。例如，当发生崩溃时，系统自动记录崩溃信息以形成崩溃日志，崩溃日志中包含有多种崩溃内容信息，比如发生崩溃的时间、发生崩溃的方法和类等。

步骤S30，以崩溃方法名为关键字，搜索系统文件目录中与崩溃方法名匹配的文件名或类库名；

本实施例中，系统文件目录具体是指属主APP所在系统的文件目录，比如系统根目录。系统文件目录中保存有所有SDK的文件信息，包括SDK的文件名、类库名、方法名等。因此，本实施例中，以崩溃方法名为搜索关键字，搜索文件目录，比如搜索各SDK文件目录。在搜索过程中，将崩溃方法名与文件目录中的文件名或类库名进行关键字匹配，若匹配则说明该崩溃方法名与该文件名或该类库名属于同一个SDK。

可选的，优选基于SHELL脚本程序，以崩溃方法名为关键字，基于GREP命令，搜索系统文件目录中与崩溃方法名匹配的文件名或类库名，进而提升搜索匹配效率。GREP(globalsearch regular expression and print out the line，全面搜索正则表达式并把行打印出来)是一种强大的文本搜索工具，它能使用正则表达式搜索文本，并把匹配的行打印出来。

GREP命令的基本格式如下：

grep pattern[file...]

1、grep搜索字符串[filename]

2、grep正则表达式[filename]

在文件中搜索所有pattern出现的位置，pattern既可以是要搜索的字符串，也可以是一个正则表达式。

本实施例中，若崩溃方法名与文件名或类库名属于同一个SDK，则其必然存在相同的关键字，因此，可基于关键字匹配来确定对应的文件名或者类名，进而确定对应的SDK。

步骤S40，当匹配成功时，输出文件名或类库名的路径信息以供定位对应的SDK。

本实施例中，当系统文件目录中存在与崩溃方法名匹配的文件名或类库名时，获取该文件名或该类库名的路径信息。本实施例中，如果崩溃方法名与文件名或类库名匹配，则说明该崩溃方法名与该文件名或该类库名属于同一个SDK，进而可根据文件名或类库名的路径信息，定位对应的第三方SDK。不同的SDK其对应的文件名或类库名的路径必然不同且惟一，因此，基于路径信息即可定位惟一的SDK，且该SDK即为发生崩溃的SDK。

本实施例中，在属主APP发生崩溃时，获取崩溃内容信息并从中提取崩溃方法名，进而再以崩溃方法名为关键字，搜索系统文件目录中与之匹配的文件名或类库名，并在匹配成功时，输出对应文件名或类库名的路径信息，进而根据该路径信息即可简便快速定位对应的SDK，并将问题反馈至SDK提供商以供进行技术改进，从而提升属主APP运行的稳定性，进而提升用户使用体验。

进一步可选的，基于上述实施例，在本发明SDK定位方法另一实施例中，上述步骤S10进一步包括：

步骤S101，在属主APP运行时，启动属主APP中的守护进程；

步骤S102，通过所述守护进程，向属主APP的主进程中注册各类崩溃信息对应的信号，并监测属主APP的主进程中是否存在所述信号；

步骤S103，若存在所述信号，则确定属主APP发生崩溃。

本实施例中，守护进程是一种为实现某种功能需要而不断检测预定条件是否成立而启动的程序，也就是通常说的Daemon进程，是Linux中的后台服务进程，它是一个生存期较长的进程。通常守护进程启动后会一直监控主程序的状态。

本实施例中，守护进程被设计为向主进程中注册各类崩溃信息所对应的信号，并检测主进行中是否存在该信号，若存在该信号，则确定属主APP中发生了崩溃。

本实施例通过守护进程的方式检测属主APP中是否发生崩溃，此方式不仅能够测得是否发生崩溃，同时还可以进一步定位发生崩溃的范围，提供定位精确度。

进一步可选的，基于上述实施例，在本发明SDK定位方法另一实施例中，上述步骤S20进一步包括：

步骤S201，当属主APP发生崩溃时，通过所述守护进程与所述主进程进行信息交互，确定崩溃进程，并获取所述崩溃进程对应的崩溃内容信息；

步骤S202，从所述崩溃内容信息中，提取崩溃方法名。

本实施例中，当属主APP发生崩溃时，守护进程通过Handler机制与主进程进行信息交互，进而确定崩溃进程。Handler能够接收守护线程发送的数据，并用此数据配合主线程更新。

当确定崩溃进程后，守护进程与崩溃进程进行交互，获取崩溃进程对应的崩溃内容信息，同时，从崩溃内容信息中，提取崩溃方法名。比如采用正则表达式从崩溃内容信息中提取崩溃方法名。

进一步可选的，在本发明SDK定位方法另一实施例中，基于上述第一实施例，本实施例中，在提取崩溃方法名后，搜索系统文件目录中与崩溃方法名匹配的文件名或类库名时，若匹配失败，则切换系统语言模式，并继续以崩溃方法名为关键字，搜索系统文件目录中与崩溃方法名匹配的文件名或类库名。

本实施例中，匹配失败的原因主要有两种：第一种是系统文件目录中并不存在与崩溃方法名匹配的文件名或类库名；第二种则可能是第三方SDK采用的语言与系统采用的语言不一致。因此，为排除第二种原因，本实施例中在匹配失败时，进行系统语言模式的切换，比如中文模式切换成英文模式，并在语言模式切换完成后，再继续以崩溃方法名为关键字，搜索系统文件目录中与崩溃方法名匹配的文件名或类库名。而若再次匹配失败，则反馈匹配失败的相关信息，以供属主APP方开发人员进行手动查找。

参照图3，图3为本发明SDK定位方法另一实施例的流程示意图。在本实施例中，所述定位方法还包括：

步骤S50，当匹配失败时，从所述崩溃内容信息中提取崩溃基础特征；

步骤S60，基于所述崩溃基础特征，计算本次崩溃对应的崩溃哈希值；

步骤S70，查找崩溃数据库中是否存在与所述崩溃哈希值匹配的崩溃记录；

步骤S80，若存在，则基于该崩溃记录，确定本次崩溃对应的SDK。

本实施例中，可以通过多种程序语言或脚本工具来构建特征提取脚本，通过该特征提取脚本可以从崩溃内容信息中提取崩溃基础特征。特征提取脚本可以根据预先设置的正则表达式，从崩溃内容信息中提取出崩溃基础特征，正则表达式可检索或替换符合格式模板的文本内容。

崩溃基础特征用于描述崩溃的基本属性，包括：崩溃所在模块名、进程名、函数名、异常类型等等。例如，在崩溃内容信息中，FOLLOWUP_IP表示崩溃所在函数名，ExceptionCode标识异常类型，PROCESS_NAME标识崩溃所在进程，MODULE_NAME标识崩溃所在模块。

本实施例中，预先设置有崩溃数据库，该数据库中存储了多种不同的崩溃记录，每一种崩溃记录对应一个发生崩溃的SDK。为便于查找与匹配，因此，采用计算崩溃哈希值的方式进行确定。

本实施例具体对提取的所有崩溃基础特征进行哈希运算，进而得到本次崩溃对应的崩溃哈希值，然后再基于该崩溃哈希值即可在崩溃数据库中确定本次崩溃对应的SDK。

可选的，采用如下公式计算崩溃哈希值：

S＝MD5(A₁&A₂…A_n-1&A_n)，其中，S表示崩溃哈希值，MD5为哈希算法函数，A_n表示崩溃基础特征。MD5(Message-Digest Algorithm 5，信息-摘要算法5)，是一种哈希算法函数。当然，本发明还可以采用其他类型的哈希算法函数。

进一步可选的，所述崩溃基础特征包括：崩溃所在模块名、崩溃所在进程名、崩溃所在函数名、崩溃的异常类型。也即S＝MD5(A₁&A₂…A_n-1&A_n)＝MD5(崩溃所在模块名&崩溃所在进程名&崩溃所在函数名&崩溃的异常类型)。其中，&符合表示字符串合并，比如A₁为“abc”，A₂为“def”，则A₁&A₂为“abcdef”。

进一步可选的，在本发明SDK定位方法一实施例中，在定位到发生崩溃的SDK后，将获取的崩溃内容信息发送至该SDK的开发方。

通常SDK开发方很难对上线后的SDK进行监控，因此，本实施例中，可以每隔预设时间，通过邮件将所获取的崩溃内容信息发送至发生崩溃的SDK的开发方或者属主APP的开发方，进而能够提醒开发者及时查看崩溃内容信息，确定崩溃位置，以及查找崩溃原因，便于及时查找和清除问题，提高属主APP运行的稳定性。

本发明还提供一种计算机可读存储介质，计算机可读存储介质上存储有SDK定位程序，SDK定位程序被处理器执行时实现如下操作：

监测属主APP是否发生崩溃，其中，属主APP中接入有多个SDK；

当属主APP发生崩溃时，获取崩溃内容信息并从中提取崩溃方法名；

以所述崩溃方法名为关键字，搜索系统文件目录中与所述崩溃方法名匹配的文件名或类库名；

当匹配成功时，输出所述文件名或类库名的路径信息以供定位对应的SDK。

本实施例中，在属主APP发生崩溃时，获取崩溃内容信息并从中提取崩溃方法名，进而再以崩溃方法名为关键字，搜索系统文件目录中与之匹配的文件名或类库名，并在匹配成功时，输出对应文件名或类库名的路径信息，进而根据该路径信息即可简便快速定位对应的SDK，并将问题反馈至SDK提供商以供进行技术改进，从而提升属主APP运行的稳定性，进而提升用户使用体验。

进一步地，所述SDK定位程序被处理器执行时还实现如下操作：

在属主APP运行时，启动属主APP中的守护进程；

通过所述守护进程，向属主APP的主进程中注册各类崩溃信息对应的信号，并监测属主APP的主进程中是否存在所述信号；

若存在所述信号，则确定属主APP发生崩溃。

进一步地，所述SDK定位程序被处理器执行时还实现如下操作：

当属主APP发生崩溃时，通过所述守护进程与所述主进程进行信息交互，确定崩溃进程，并获取所述崩溃进程对应的崩溃内容信息；

从所述崩溃内容信息中，提取崩溃方法名。

进一步地，所述SDK定位程序被处理器执行时还实现如下操作：

以所述崩溃方法名为关键字，基于GREP命令，搜索系统文件目录中与所述崩溃方法名匹配的文件名或类库名。

进一步地，所述SDK定位程序被处理器执行时还实现如下操作：

当匹配失败时，从所述崩溃内容信息中提取崩溃基础特征；

基于所述崩溃基础特征，计算本次崩溃对应的崩溃哈希值；

查找崩溃数据库中是否存在与所述崩溃哈希值匹配的崩溃记录；

若存在，则基于该崩溃记录，确定本次崩溃对应的SDK。

进一步地，所述SDK定位程序被处理器执行时还实现如下操作：

在定位到发生崩溃的SDK后，将获取的崩溃内容信息发送至该SDK的开发方。

以上仅为本发明的优选实施例，并非因此限制本发明的专利范围，凡是利用本发明说明书及附图内容所作的等效结构或等效流程变换，或直接或间接运用在其他相关的技术领域，均同理包括在本发明的专利保护范围内。

Claims (10)

1.一种软件开发包SDK定位方法，其特征在于，所述定位方法包括以下步骤：

监测属主APP是否发生崩溃，其中，属主APP中接入有多个SDK；

当属主APP发生崩溃时，获取崩溃内容信息并从中提取崩溃方法名；

以所述崩溃方法名为关键字，搜索系统文件目录中与所述崩溃方法名匹配的文件名或类库名；

当匹配成功时，输出所述文件名或类库名的路径信息以供定位对应的SDK。

2.如权利要求1所述的定位方法，其特征在于，所述监测属主APP是否发生崩溃的步骤包括：

在属主APP运行时，启动属主APP中的守护进程；

通过所述守护进程，向属主APP的主进程中注册各类崩溃信息对应的信号，并监测属主APP的主进程中是否存在所述信号；

若存在所述信号，则确定属主APP发生崩溃。

3.如权利要求2所述的定位方法，其特征在于，所述当属主APP发生崩溃时，获取崩溃内容信息并从中提取崩溃方法名的步骤包括：

当属主APP发生崩溃时，通过所述守护进程与所述主进程进行信息交互，确定崩溃进程，并获取所述崩溃进程对应的崩溃内容信息；

从所述崩溃内容信息中，提取崩溃方法名。

4.如权利要求1-3中任一项所述的定位方法，其特征在于，所述以所述崩溃方法名为关键字，搜索系统文件目录中与所述崩溃方法名匹配的文件名或类库名的步骤包括：

以所述崩溃方法名为关键字，基于GREP命令，搜索系统文件目录中与所述崩溃方法名匹配的文件名或类库名。

5.如权利要求1所述的定位方法，其特征在于，所述定位方法还包括：

当匹配失败时，从所述崩溃内容信息中提取崩溃基础特征；

基于所述崩溃基础特征，计算本次崩溃对应的崩溃哈希值；

查找崩溃数据库中是否存在与所述崩溃哈希值匹配的崩溃记录；

若存在，则基于该崩溃记录，确定本次崩溃对应的SDK。

6.如权利要求5所述的定位方法，其特征在于，所述定位方法采用如下公式计算崩溃哈希值：

S＝MD5(A₁&A₂…A_n-1&A_n)，其中，S表示崩溃哈希值，MD5为哈希算法函数，A_n表示崩溃基础特征。

7.如权利要求6所述的定位方法，其特征在于，所述崩溃基础特征包括：崩溃所在模块名、崩溃所在进程名、崩溃所在函数名、崩溃的异常类型。

8.如权利要求7所述的定位方法，其特征在于，所述定位方法还包括：

在定位到发生崩溃的SDK后，将获取的崩溃内容信息发送至该SDK的开发方。

9.一种SDK定位设备，其特征在于，所述SDK定位设备包括：存储器、处理器及存储在所述存储器上并可在所述处理器上运行的SDK定位程序，所述SDK定位程序被所述处理器执行时实现如权利要求1至8中任一项所述的定位方法的步骤。

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