一种组装产品中定位崩溃堆栈所属组件的方法及其系统与流程

本发明涉及计算机通讯技术领域，特别是一种组装产品中定位崩溃堆栈所属组件的方法及其系统。

背景技术：

近几年，为了程序之间各个模块之间的解耦以及高效的开发应用，各大公司推出相应的应用工厂的框架，原各个模块定义为独立的工作的组件，生产一个应用时，选择对应的组件，根据应用工厂的框架，即可生产出一个完整的应用，像生产汽车似的。这样在自动化测试系统中收集了很多crashbug(崩溃bug)，一堆一堆的代码，如何快速定位到所属的组件以及对应版本呢？如何加快bug的解决呢？

现在各大公司都有自己的自动化云测试系统，包括ui自动化、性能自动化、兼容性测试、稳定性测试等等，各种测试都会收集大量的crash日志。这种方式缺点是：大量的crash日志发给开发员，一个个开发人员排查过去是不是自己的组件、效率低下。

技术实现要素：

为克服上述问题，本发明的目的是提供一种组装产品中定位崩溃堆栈所属组件的方法，精准定位到所属的组件名称和版本，大大提高了测试效率。

本发明采用以下方案实现：一种组装产品中定位崩溃堆栈所属组件的方法，所述方法包括如下步骤：

步骤s1、获取项目中应用和应用所需依赖组件的信息，所述信息包括组件信息和应用信息，并上传保存到服务端的数据库；

步骤s2、保存组件信息的同时，根据组件信息和组件库管理方式拼出组件库的下载地址，再通过java服务对组件库进行下载和解析，解析获取组件库所有的类名，将类名保存到服务端的数据库；

步骤s3、在java服务端开发一个根据类名查询组件信息的接口；

步骤s4、当一个应用程序发生崩溃时，通过获取崩溃堆栈发生类的定位算法，获取引起崩溃的类名，并通过所述的接口在数据库中进行查询获得对应的组件信息。

进一步的，所述步骤s1进一步具体为：对项目中应用所需组件的依赖信息进行配置管理，将组件所依赖的依赖信息保存在assets目录下的tree.txt文件中，解析tree.txt文件获取组件信息，所述组件信息包括项目组织唯一的标识符groupid、项目的唯一的标识符artifactid、版本号version、以及后缀名suffix；通过android系统api获取应用信息，所述应用信息包括应用的包名和版本信息；将组件信息和应用信息存储到服务端的数据库中。

进一步的，所述s2进一步具体为：设置一组件库，通过java服务器应用程序sonatypenexusrepositorymanager对组件库进行管理，通过nexus域名和所述组件信息得到下载地址：nexus域名/groupid/artifactid/version/artifactid-version.suffix，然后通过该下载地址下载组件库保存到服务端；解析组件库通过命令jar-tf组件库的路径，即可获取该组件库的所有组件类名，将组件类名保存到服务端的数据库中。

进一步的，所述步骤s4进一步具体为：当一个应用程序发生崩溃时，循环崩溃堆栈，匹配每一行堆栈信息是否包含预先设定的应用的包名关键字，匹配成功后，对这一条堆栈信息进行处理，取出类名，该类即为引起崩溃的类名，并通过所述的接口在数据库中进行查询获得对应的组件信息。

本发明还提供了一种组装产品中定位崩溃堆栈所属组件的系统，所述系统包括获取信息模块、组件类名获取模块、接口开发模块、以及查询模块；

所述获取信息模块，获取项目中应用和应用所需依赖组件的信息，所述信息包括组件信息和应用信息，并上传保存到服务端的数据库；

所述组件类名获取模块，用于在保存组件信息的同时，根据组件信息和组件库管理方式拼出组件库的下载地址，再通过java服务对组件库进行下载和解析，解析获取组件库所有的类名，将类名保存到服务端的数据库；

所述接口开发模块，用于在java服务端开发一个根据类名查询组件信息的接口；

所述查询模块，用于当一个应用程序发生崩溃时，通过获取崩溃堆栈发生类的定位算法，获取引起崩溃的类名，并通过所述的接口在数据库中进行查询获得对应的组件信息。

进一步的，所述获取信息模块进一步具体为：对项目中应用所需组件的依赖信息进行配置管理，将组件所依赖的依赖信息保存在assets目录下的tree.txt文件中，解析tree.txt文件获取组件信息，所述组件信息包括项目组织唯一的标识符groupid、项目的唯一的标识符artifactid、版本号version、以及后缀名suffix；通过android系统序api获取应用信息，所述应用信息包括应用的包名和版本信息；将组件信息和应用信息存储到服务端的数据库中。

进一步的，所述组件类名获取模块进一步具体为：设置一组件库，通过java服务器应用程序sonatypenexusrepositorymanager对组件库进行管理，通过nexus域名和所述组件信息得到下载地址：nexus域名/groupid/artifactid/version/artifactid-version.suffix，然后通过该下载地址下载组件库保存到服务端；解析组件库通过命令jar-tf组件库的路径，即可获取该组件库的所有组件类名，将组件类名保存到服务端的数据库中。

进一步的，所述查询模块进一步具体为：当一个应用程序发生崩溃时，循环崩溃堆栈，匹配每一行堆栈信息是否包含预先设定的应用的包名关键字，匹配成功后，对这一条堆栈信息进行处理，取出类名，该类即为引起崩溃的类名，并通过所述的接口在数据库中进行查询获得对应的组件信息。

本发明的有益效果在于：现有的方法人工分析费时，效率低下，不利于bug的快速解决；而本发明的程序全自动化分析，无需人工介入，精准定位到所属的组件名称和版本，大大提高了测试效率，大大提高了bug的解决速度。

附图说明

图1是本发明的方法流程示意图。

图2是本发明的系统框图。

具体实施方式

下面结合附图对本发明做进一步说明。

请参阅图1所示，本发明的一种组装产品中定位崩溃堆栈所属组件的方法，所述方法包括如下步骤：

步骤s1、获取项目中应用和应用所需依赖组件的信息，所述信息包括组件信息和应用信息，并上传保存到服务端的数据库；

步骤s2、保存组件信息的同时，根据组件信息和组件库管理方式拼出组件库的下载地址，再通过java服务对组件库进行下载和解析，解析获取组件库所有的类名，将类名保存到服务端的数据库；

步骤s3、在java服务端开发一个根据类名查询组件信息的接口；

步骤s4、当一个应用程序发生崩溃时，通过获取崩溃堆栈发生类的定位算法，获取引起崩溃的类名，并通过步骤s3的接口在数据库中进行查询获得对应的组件信息。

所述步骤s1进一步具体为：对项目中应用所需组件的依赖信息进行配置管理，将组件所依赖的依赖信息保存在assets目录下的tree.txt文件中，解析tree.txt文件获取组件信息，所述组件信息包括项目组织唯一的标识符groupid、项目的唯一的标识符artifactid、版本号version、以及后缀名suffix；通过android系统api获取应用信息，所述应用信息包括应用的包名和版本信息；将组件信息和应用信息存储到服务端的数据库中。

所述s2进一步具体为：设置一组件库，通过java服务器应用程序sonatypenexusrepositorymanager对组件库进行管理，通过nexus域名和所述组件信息得到下载地址：nexus域名/groupid/artifactid/version/artifactid-version.suffix，然后通过该下载地址下载组件库保存到服务端；解析组件库通过命令jar-tf组件库的路径，即可获取该组件库的所有组件类名，将组件类名保存到服务端的数据库中。

所述步骤s4进一步具体为：当一个应用程序发生崩溃时，循环崩溃堆栈，匹配每一行堆栈信息是否包含预先设定的(即公司自研产品)的应用的包名的关键字，匹配成功后，对这一条堆栈信息进行处理，取出类名，该类即为引起崩溃的类名，并通过步骤s3的接口在数据库中进行查询获得对应的组件信息。

下面结合一具体实施例对本发明作进一步说明：

s1：获取应用和所需依赖组件的信息服务：

监控程序打包服务，根据程序包获取应用的包名、版本等信息，查询服务端是否存在该应用信息，否，则解析apk应用，对项目中应用所需组件的依赖信息进行配置管理，配置管理：在公司应用工厂的框架中，对应用所需组件进行了依赖信息的配置管理，保存在assets目录下的tree.txt文件下，组件的配置格式为：

‘com.nd.android.audiosdk:audio-trans-sdk-impl:0.1.69.release@aar'，按“:”和“@”分割依次是groupid、artifactid、version、suffix；

解析步骤：修改apk包的后缀名为zip，解压zip，获取assets目录下的tree.txt文件，解析tree.txt文件获取项目组织唯一的标识符groupid、项目的唯一的标识符artifactid、版本号version、以及后缀名suffix。(即组件信息)

应用信息：可通过系统android系统api获取应用的包名和版本信息。

综上所述将获取的groupid、artifactid、version、suffix、应用的包名和版本信息上传并保存到服务端数据库待用。

s2:解析组件类服务

下载组件库：行业里一般用marven私服(一种库包的管理服务)管理自己开发的库，公司的应用工厂使用了这个服务，即通过sonatypenexusrepositorymanager(一个java服务器应用程序)对组件的库进行管理，可通过nexus域名以及s1中得到的组件信息拼出下载地址：nexus域名/groupid/artifactid/version/artifactid-version.suffix，然后通过该地址下载组件库保存到服务端。

解析组件库的组件类名：通过命令jar-tf组件库的路径，即可获取该组件库的所有类名，将类名保存到服务端数据库。

s3：获取崩溃堆栈发生类的定位算法

当一个app发生crash时，crash的堆栈是各种各样的，甚至有上百行，如何定位到代码的出错的类呢？错误日志的输出首先是报错原因，其次是代码堆栈，这个代码堆栈的输出顺序跟调用顺序是相反的，为什么呢？因为java的方法在执行的时候是在虚拟机栈中执行的，每执行一个方法就会新建一个栈帧然后压入到虚拟机栈中。这是一个后进先出的结构，所以报错的时候也是从被调用者最开始报错，然后调用者依次报错，所以打印错误时的顺序也是报错的位置在最上面，调用者依次向后排。大部分情况下，最上方的报错信息就是代码出错的位置。但是有时候最上方的日志并不是自己的代码，那是因为代码调用了一些第三方jar包的代码。但是这并不影响去定位问题，还是根据上面报错，下面跟随来定位问题，那么真正报错的位置还是在上面。那么只需要从上往下依次找自己的代码即可；第一个找到的的代码类就是代码中引发报错的类。

所以根据上面java程序崩溃日志的原理，错误日志从上到下依次是崩溃原因、第三方代码或自己代码调用，依次去循环判断每行堆栈信息是否包含公司自研应用的包名的关键字，这个包命名关键字一般公司都有特殊的命名规则，所以第一次匹配到包名的关键字的就是崩溃位置的类。

比如：公司的包命名规则是“com.xx”,在下面的堆栈中，排除掉第一行的崩溃原因，逐条判断是否包含有“com.xx”关键字，由下面案例可知第三行包含，即是错误代码的位置行，因为最后面f2是方法，所以截取掉方法后，com.xx.test即是引发报错的类。

exceptioninthread“main”java.lang.nullpointerexception

com.android.test.f1(testexception.java:22)

com.xx.test.f2(testexception.java:17)；

s4:通过崩溃类名查询组件接口服务

在上面s1和s2中已经获取了应用、组件以及组件类名等信息，通过崩溃类名在组件类名、应用信息数据库中即可查询出该崩溃类类所属的组件，所以现在实现一个崩溃类名查询组件接口服务供第三方使用。注意，在收到请求的堆栈后，经过s3的处理获取崩溃类后再进行查询获取组件信息。这样能精准定位到所属的组件名称和版本，大大提高了测试效率。

请参阅图2所示，本发明的一种组装产品中定位崩溃堆栈所属组件的系统，所述系统包括获取信息模块、组件类名获取模块、接口开发模块、以及查询模块；

所述获取信息模块，获取项目中应用和应用所需依赖组件的信息，所述信息包括组件信息和应用信息，并上传保存到服务端的数据库；

所述组件类名获取模块，用于在保存组件信息的同时，根据组件信息和组件库管理方式拼出组件库的下载地址，再通过java服务对组件库进行下载和解析，解析获取组件库所有的类名，将类名保存到服务端的数据库；

所述接口开发模块，用于在java服务端开发一个根据类名查询组件信息的接口；

所述查询模块，用于当一个应用程序发生崩溃时，通过获取崩溃堆栈发生类的定位算法，获取引起崩溃的类名，并通过所述接口在数据库中进行查询获得对应的组件信息。

所述获取信息模块进一步具体为：对项目中应用所需组件的依赖信息进行配置管理，将组件所依赖的依赖信息保存在assets目录下的tree.txt文件中，解析tree.txt文件获取组件信息，所述组件信息包括项目组织唯一的标识符groupid、项目的唯一的标识符artifactid、版本号version、以及后缀名suffix；通过android系统api获取应用信息，所述应用信息包括应用的包名和版本信息；将组件信息和应用信息存储到服务端的数据库中。

所述组件类名获取模块进一步具体为：设置一组件库，通过java服务器应用程序sonatypenexusrepositorymanager对组件库进行管理，通过nexus域名和所述组件信息得到下载地址：nexus域名/groupid/artifactid/version/artifactid-version.suffix，然后通过该下载地址下载组件库保存到服务端；解析组件库通过命令jar-tf组件库的路径，即可获取该组件库的所有组件类名，将组件类名保存到服务端的数据库中。

进一步的，所述查询模块进一步具体为：当一个应用程序发生崩溃时，循环崩溃堆栈，匹配每一行堆栈信息是否包含预先设定的应用的包名的关键字，匹配成功后，对这一条堆栈信息进行处理，取出类名，该类即为引起崩溃的类名，并通过所述的接口在数据库中进行查询获得对应的组件信息。

以上所述仅为本发明的较佳实施例，凡依本发明申请专利范围所做的均等变化与修饰，皆应属本发明的涵盖范围。