CN109032909A - 应用程序崩溃日志的处理方法、系统、设备和存储介质 - Google Patents

Abstract

本发明提供应用程序崩溃日志的处理方法、系统、电子设备和存储介质，其中处理方法包括：接收应用程序上报的崩溃日志；对所述崩溃日志进行符号化处理，将所述崩溃日志的格式转化成可读格式；解析所述崩溃日志，获取所述崩溃日志的指纹信息；计算各崩溃日志的指纹信息之间的相似度，将指纹信息的相似度高于预设的相似度阈值的崩溃日志归入同一崩溃聚类；获取所述崩溃聚类的特征信息，根据所述特征信息将所述崩溃聚类推送至对应的业务部门。本发明通过对崩溃日志进行符号化和聚类处理，并识别聚类所属的业务部门，方便开发人员及时了解、排查和修复崩溃问题。

Description

应用程序崩溃日志的处理方法、系统、设备和存储介质

技术领域

本发明涉及互联网技术领域，具体地说，涉及一种应用程序崩溃日志的处理方法、系统、电子设备和存储介质。

背景技术

客户端在运行应用程序(APPlication，简称APP)的过程中，可能会因为应用违反操作系统规则，或应用中有Bug(漏洞)等原因发生崩溃并产生崩溃日志。

目前，大部分客户端都有崩溃上报程序，当客户端发生崩溃时，会由崩溃上报程序收集产生的崩溃日志上报给服务器。服务器接收到崩溃日志后保存，以便由研发人员根据服务器上保存的崩溃日志进行分析。

然而，随着应用程序产品的增多，不同APP产品，甚至是同一APP产品的不同模块单元，可能是由不同的开发人员负责，这使得开发人员需要从服务器上保存的大量的崩溃日志中查找出与自己负责的APP产品有关的崩溃日志来加以分析，查找过程浪费了很多时间，导致Bug排查效率低下。

并且，日志信息无法和公司内部的业务部门关联，无法根据业务进行分类统计、邮件报警等，也无法将崩溃日志导出，供其他系统进行数据挖掘、分析，崩溃日志的使用率差。

需要说明的是，在上述背景技术部分公开的信息仅用于加强对本发明的背景的理解，因此可以包括不构成对本领域普通技术人员已知的现有技术的信息。

发明内容

针对现有技术中的问题，本发明提供一种应用程序崩溃日志的处理方法、系统、电子设备和存储介质，克服崩溃漏洞排查效率低，崩溃日志使用率差的问题。

根据本发明的一个方面，提供一种应用程序崩溃日志的处理方法，包括如下步骤：接收应用程序上报的崩溃日志；对所述崩溃日志进行符号化处理，将所述崩溃日志的格式转化成可读格式；解析所述崩溃日志，获取所述崩溃日志的指纹信息；计算各崩溃日志的指纹信息之间的相似度，将指纹信息的相似度高于预设的相似度阈值的崩溃日志归入同一崩溃聚类；获取所述崩溃聚类的特征信息，根据所述特征信息将所述崩溃聚类推送至对应的业务部门。

优选的，上述的处理方法中，对所述崩溃日志进行符号化处理的步骤包括：获取所述崩溃日志包含的操作系统平台信息；根据所述操作系统平台信息，获取对应版本的所述应用程序编译时生成的符号表；根据所述符号表，对所述崩溃日志进行符号化处理。

优选的，上述的处理方法中，通过异步下载队列下载所述符号表，并根据LRU淘汰机制对下载的所述符号表进行过滤。

优选的，上述的处理方法中，获取所述崩溃日志的指纹信息的步骤包括：解析所述崩溃日志，过滤所述崩溃日志中的噪音信息；提取所述崩溃日志中包含的导致所述应用程序崩溃的错误堆栈；根据所述错误堆栈，采用Hash函数计算所述崩溃日志的指纹信息。

优选的，上述的处理方法中，采用LCS算法计算各崩溃日志的指纹信息之间的相似度。

优选的，上述的处理方法中，当一崩溃日志的指纹信息与其余崩溃日志的指纹信息之间的相似度均未达所述相似度阈值时，将该崩溃日志单独创建一崩溃聚类。

优选的，上述的处理方法中，根据所述特征信息将所述崩溃聚类推送至对应的业务部门的步骤包括：获取所述崩溃聚类的包名或文件名，作为所述崩溃聚类的特征信息；根据所述崩溃聚类的特征信息，遍历数据库中预存的特征信息与业务部门的映射关系表；筛选出特征信息与所述崩溃聚类的特征信息相匹配的业务部门，推送所述崩溃聚类。

优选的，上述的处理方法中，预存所述特征信息与业务部门的映射关系表的步骤包括：扫描所述应用程序的代码，获取所述应用程序的代码所包含的各单元的包名和文件名，映射至对应的业务部门；将各单元的包名和文件名作为各单元的特征信息，与对应的业务部门建立所述映射关系表。

优选的，上述的处理方法中，通过消息队列的异步方式接收所述应用程序上报的所述崩溃日志；以及，接收所述崩溃日志后，对所述崩溃日志进行预处理，所述预处理包括解密和解压缩。

优选的，上述的处理方法还包括：对所述崩溃日志进行实时统计，统计维度包括：对应不同操作系统平台的不同客户端版本，所述应用程序在预设周期内的总崩溃数、影响用户数和各崩溃类别占比。

优选的，上述的处理方法还包括：为每一统计维度预设一参数阈值，对统计结果进行周期性检查，当一统计维度下统计结果超出该统计维度下预设的参数阈值时，推送报警信息。

根据本发明的另一个方面，提供一种应用程序崩溃日志的处理系统，包括：符号化处理模块，接收应用程序上报的崩溃日志，对所述崩溃日志进行符号化处理，将所述崩溃日志的格式转化成可读格式；聚类模块，解析所述崩溃日志，获取所述崩溃日志的指纹信息，计算各崩溃日志的指纹信息之间的相似度，将指纹信息的相似度高于预设的相似度阈值的崩溃日志归入同一崩溃聚类；标签化模块，获取所述崩溃聚类的特征信息，根据所述特征信息将所述崩溃聚类推送至对应的业务部门。

优选的，上述的处理系统还包括：统计模块，对所述崩溃日志进行实时统计，统计维度包括：对应不同操作系统平台的不同客户端版本，所述应用程序在预设周期内的总崩溃数、影响用户数和各崩溃类别占比。

优选的，上述的处理系统还包括：报警模块，为每一统计维度预设一参数阈值，对统计结果进行周期性检查，当一统计维度下统计结果超出该统计维度下预设的参数阈值时，推送报警信息。

根据本发明的另一个方面，提供一种电子设备，包括：处理器；以及存储器，用于存储可执行指令；其中，所述处理器配置为经由执行所述可执行指令来执行上述的应用程序崩溃日志的处理方法的步骤。

根据本发明的另一个方面，提供一种计算机可读存储介质，其上存储有计算机程序，所述计算机程序被处理器执行时实现上述的应用程序崩溃日志的处理方法的步骤。

本发明与现有技术相比的有益效果在于：

本发明通过对崩溃日志进行符号化和聚类处理，并识别聚类所属的业务部门，将崩溃日志推送至对应的业务部门，方便开发人员及时了解、排查和修复崩溃问题；

同时，通过对崩溃日志进行统计和预警，供开发人员读取并及时处理。

应当理解的是，以上的一般描述和后文的细节描述仅是示例性和解释性的，并不能限制本发明。

附图说明

此处的附图被并入说明书中并构成本说明书的一部分，示出了符合本发明的实施例，并与说明书一起用于解释本发明的原理。显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1示出本发明实施例中应用程序崩溃日志的处理方法的流程示意图；

图2示出本发明实施例中应用程序崩溃日志的处理方法的应用场景示意图；

图3示出本发明实施例中应用程序崩溃日志的处理系统的模块示意图；

图4示出本发明实施例中电子设备的示意图；

图5示出本发明实施例中计算机可读存储介质的示意图。

具体实施方式

现在将参考附图更全面地描述示例实施方式。然而，示例实施方式能够以多种形式实施，且不应被理解为限于在此阐述的实施方式。相反，提供这些实施方式使得本发明将全面和完整，并将示例实施方式的构思全面地传达给本领域的技术人员。在图中相同的附图标记表示相同或类似的结构，因而将省略对它们的重复描述。

图1是实施例中应用程序崩溃日志的处理方法的流程示意图，图2示出实施例中应用程序崩溃日志的处理方法的应用场景示意图。参照图1和图2所示，应用程序崩溃日志的处理方法包括：

步骤S10、接收应用程序上报的崩溃日志。

在优选的实施方式中，通过消息队列的异步方式接收应用程序上报的崩溃日志。接收崩溃日志后，对崩溃日志进行预处理，包括解密和解压缩等操作。

具体来说，参照图2，APP在崩溃并重新启动后，会将收集到的错误信息，即崩溃日志201发送给服务器(Http Sever)202的HTTP RESTful接口。服务器202经过解密、解压缩等一系列预处理后，根据用户手机的平台信息，通过消息中间件203发送给相应的消息消费者204，包括Android消费者和IOS消费者进行消费。消息消费者204可以是一个服务集群平台，分为Android平台和IOS平台。服务器202和消费者204之间通过消息队列的异步方式保证了REST接口的高性能和信息的不丢失。

步骤S20、对崩溃日志进行符号化处理，将崩溃日志的格式转化成可读格式。

在优选的实施方式中，对崩溃日志进行符号化处理的步骤包括：获取崩溃日志包含的操作系统平台信息；根据操作系统平台信息，获取对应版本的应用程序(如上，包括Android版本和IOS版本)编译时生成的符号表；根据符号表，对崩溃日志进行符号化处理。

具体来说，应用程序上报的崩溃日志，其内容都是经过混淆的替换符号或十六进制地址，无法供工程师阅读。因此需要对其进行符号化处理，符号化处理的过程需要APP编译打包时生成的符号表。用户在“移动发布平台”打包得到APK或IPA产物(APK是AndroidPackage的缩写，即Android安装包；IPA是APPle程序应用文件iPhoneAPPlication的缩写)后，系统同时会保存相应的MAPPing File或Symbol File。Android/IOS消费者通过一个异步的下载队列去下载符号表，放入本地的磁盘缓存(如图2所示的Key-Value存储系统205)中，并根据LRU淘汰机制删除多余文件。在获得需要的符号表后，Android平台使用proguardretrace软件对崩溃日志进行翻译工作，IOS平台使用XCode symbolicatecrash程序对崩溃日志进行符号化操作。

步骤S30、解析崩溃日志，获取崩溃日志的指纹信息。

在优选的实施方式中，获取崩溃日志的指纹信息的步骤包括：解析崩溃日志，过滤崩溃日志中的噪音信息；提取崩溃日志中包含的导致应用程序崩溃的错误堆栈；根据错误堆栈，采用Hash函数计算崩溃日志的指纹信息。

具体来说，崩溃日志在翻译，即符号化后，需要进行统一归类，以避免对重复日志重复分析。归类的第一步，是对崩溃日志的内容进行解析，过滤掉没有价值的噪音。在只保留关键字符后，得到崩溃日志的错误类型Exception Type，错误标题Exception Title以及错误堆栈Exception Stack。再利用错误堆栈Exception Stack得到APP相关的指纹信息Exception Signature，即采用Hash算法计算错误堆栈Exception Stack的hash值，作为应用程序的指纹信息。

步骤S40、计算各崩溃日志的指纹信息之间的相似度，将指纹信息的相似度高于预设的相似度阈值的崩溃日志归入同一崩溃聚类。

在优选的实施方式中，采用LCS算法计算各崩溃日志的指纹信息之间的相似度。当一崩溃日志的指纹信息与其余崩溃日志的指纹信息之间的相似度均未达相似度阈值时，将该崩溃日志单独创建一崩溃聚类。经过聚类，相似度符合要求的崩溃日志被归为一类。

一般情况下，利用指纹信息Exception Signature就能找出与崩溃日志匹配度最高的所属类别。但有时，错误堆栈Exception Stack中与APP直接相关的信息太少，导致指纹信息Exception Signature置信度不高。此时需要使用LCS(Longest Common Subsequence)算法进行相似度匹配，计算出与崩溃日志相似度最高的类别。

步骤S50、获取崩溃聚类的特征信息，根据特征信息将崩溃聚类推送至对应的业务部门。

在优选的实施方式中，根据特征信息将崩溃聚类推送至对应的业务部门的步骤包括：获取崩溃聚类的包名或文件名，作为崩溃聚类的特征信息；根据崩溃聚类的特征信息，遍历数据库中预存的特征信息与业务部门的映射关系表；筛选出特征信息与崩溃聚类的特征信息相匹配的业务部门，推送崩溃聚类。其中，预存特征信息与业务部门的映射关系表的步骤包括：扫描应用程序的代码，获取应用程序的代码所包含的各单元的包名和文件名，映射至对应的业务部门；将各单元的包名和文件名作为各单元的特征信息，与对应的业务部门建立映射关系表。

具体来说，聚类完成后，需要判断崩溃聚类属于哪一个业务部门。首先，在发布新版本APP时，对Android和IOS客户端代码进行扫描。扫面的过程为，在平台上发起扫描请求，由调度系统调度相应的Job进行工作。Job会根据请求，从代码仓库中下载源代码，在应用程序的各个模块代码中去扫描包名、文件名等特征信息。这些信息最终会被映射到相关业务下，并存储到数据库中去。当生成一个新的崩溃聚类时，系统扫描错误堆栈，寻找可以匹配的包名或文件名，并根据业务部门的优先级计算出所属的业务部门，作为该崩溃聚类的标签。

本实施例中Android/IOS消费者204对上报的崩溃日志201进行了符号化和聚类处理，并识别出崩溃聚类所属的业务部门进行推送，便于对应的开发人员排查和修复崩溃问题。

进一步的，应用程序崩溃日志的处理方法还包括：

步骤S60、对崩溃日志进行实时统计。统计维度包括：对应不同操作系统平台的不同客户端版本，应用程序在预设周期内的总崩溃数、影响用户数和各崩溃类别占比。

具体来说，结合图2所示，标签完成后，崩溃日志将会流转到实时计算系统206中，实时地统计数据在不同维度下的度量值。实时计算系统206例如为一个服务器集群系统，根据APP ID，Client Version(客户端版本)，OS Platform(操作系统平台)等维度对总崩溃数、影响用户数、应用打开次数、在线用户数等参数，以一小时为一个预设周期进行聚合和统计。其中，应用打开次数会由APP在每次打开时上传至Http Server接口；在线用户信息来源，通过APP使用心跳机制向Http Server发送心跳包实现。统计所需的参数等信息可存储于NoSQL数据库7中。其他统计信息如：每个崩溃类别下的总错误数、影响用户数、版本占比、地区占比等，均在实时计算系统206中完成。所有统计信息会在末端节点存储到关系数据库208中。

步骤S70、为每一统计维度预设一参数阈值，对统计结果进行周期性检查，当一统计维度下统计结果超出该统计维度下预设的参数阈值时，推送报警信息。

具体来说，报警操作例如由图2所示的定时报警调度系统209执行。定时报警调度系统209由定时任务系统实现。不同的定时任务会根据不同的配置，定时地，即周期性地去运行特定任务。例如，Job A会定期地访问搜索服务系统，查询并记录当前占比最高的N个客户端版本。Job B负责按照周期T，查找过去T时间内，版本占比最高的N个客户端版本下，崩溃次数超过阈值(Threshold X)的崩溃类别，并根据类别所属业务，发送邮件(Email)至相应的负责人210处。Job C则会每天统计每个部门，当天崩溃次数最多的崩溃类别，并发送邮件至负责人处。其中，周期T、阈值Threshold X等参数均可以通过动态配置进行在线修改。

在其他实施方式中，实时计算系统206也可以直接获取Http Sever服务器202中的崩溃日志，进行统计分析。也即，崩溃日志201可以经Android/IOS消费者204消费后，流转至实时计算系统206进行统计分析；或者，崩溃日志201可以同步地流转至Android/IOS消费者204进行消费，以及实时计算系统206进行统计分析。

综上，本实施例的应用程序崩溃日志的处理方法对上报的崩溃日志进行符号化和聚类处理，并识别聚类所属的业务部门；同时在各个维度上进行统计，供其他系统读取，以及通过邮件等报警的方式通知相关人员。

本发明实施例还提供一种应用程序崩溃日志的处理系统，参照图3所示，包括：

符号化处理模块301，对崩溃日志进行符号化处理，将崩溃日志的格式转化成可读格式。

具体来说，针对不同操作系统平台的崩溃日志，主要包括Android平台和IOS平台，符号化处理模块301采用不同的程序进行符号化处理。针对Android平台的崩溃日志，使用proguard retrace程序以及对应版本的应用程序在编译时生成的Mapping文件进行符号化处理。针对IOS平台的崩溃日志，使用XCode symbolicatecrash程序以及对应版本的应用程序在编译时生成的SYM文件进行符号化处理。从而，将原始崩溃日志301转化成符号化崩溃日志302。

聚类模块302，解析崩溃日志，获取崩溃日志的指纹信息，计算各崩溃日志的指纹信息之间的相似度，将指纹信息的相似度高于预设的相似度阈值的崩溃日志归入同一崩溃聚类。

具体来说，聚类模块302计算符号化崩溃日志302的指纹信息，并基于指纹信息采用LCS算法对符号化崩溃日志302进行相似度匹配，形成由相似度高的崩溃日志组成的崩溃聚类313。

标签化模块303，获取崩溃聚类的特征信息，根据特征信息将崩溃聚类推送至对应的业务部门。

具体来说，获取崩溃聚类313的包名或文件名作为特征信息，进行业务部门的对应匹配。使得每个崩溃聚类标记上对应业务部门的标签，形成标记信息314推送至各业务部门，便于对应业务部门的工程人员排查和修复崩溃问题。

进一步的，应用程序崩溃日志的处理系统还包括：统计模块304，对崩溃日志进行实时统计，统计维度包括：对应不同操作系统平台的不同客户端版本，应用程序在预设周期内的总崩溃数、影响用户数和各崩溃类别占比。以及报警模块(未示出)，为每一统计维度预设一参数阈值，对统计结果进行周期性检查，当一统计维度下统计结果超出该统计维度下预设的参数阈值时，推送报警信息。

具体来说，统计模块304对标签化后的标记信息314进行多维度统计，并基于统计结果315执行相应的推送和报警操作。

需要说明的是，上述的应用程序崩溃日志的处理系统可以是包含多台服务器的集群系统，也可以是包含多个服务集群的分布式系统，甚至是包含多个处理模块的一台服务装置，均可用来实现上述的处理系统。

本发明实施例还提供一种电子设备，包括处理器和存储器，存储器中存储有可执行指令，处理器被配置为经由执行可执行指令来执行上述实施例中的应用程序崩溃日志的处理方法的步骤。

如上所述，本实施例的电子设备能够对上报的崩溃日志进行符号化和聚类处理，并识别聚类所属的业务部门；同时在各个维度上进行统计，供其他系统读取，以及通过邮件等报警的方式通知相关人员。

图4是本发明实施例中电子设备的结构示意图，应当理解的是，图4仅仅是示意性地示出各个模块，这些模块可以是虚拟的软件模块或实际的硬件模块，这些模块的合并、拆分及其余模块的增加都在本发明的保护范围之内。

如图4所示，电子设备400以通用计算设备的形式表现。电子设备400的组件可以包括但不限于：至少一个处理单元410、至少一个存储单元420、连接不同平台组件(包括存储单元420和处理单元410)的总线430、显示单元440等。

其中，存储单元存储有程序代码，程序代码可以被处理单元410执行，使得处理单元410执行上述的应用程序崩溃日志的处理方法部分描述的一个或多个步骤。例如，处理单元410可以执行如图1中所示的步骤。

存储单元420可以包括易失性存储单元形式的可读介质，例如随机存取存储单元(RAM)4201和/或高速缓存存储单元4202，还可以进一步包括只读存储单元(ROM)4203。

存储单元420还可以包括具有一组(至少一个)程序模块4205的程序/实用工具4204，这样的程序模块4205包括但不限于：操作系统、一个或者多个应用程序、其它程序模块以及程序数据，这些示例中的每一个或某种组合中可能包括网络环境的实现。

总线430可以为表示几类总线结构中的一种或多种，包括存储单元总线或者存储单元控制器、外围总线、图形加速端口、处理单元或者使用多种总线结构中的任意总线结构的局域总线。

电子设备400也可以与一个或多个外部设备500(例如键盘、指向设备、蓝牙设备等)通信，还可与一个或者多个使得用户能与该电子设备400交互的设备通信，和/或与使得该电子设备400能与一个或多个其它计算设备进行通信的任何设备(例如路由器、调制解调器等等)通信。这种通信可以通过输入/输出(I/O)接口450进行。并且，电子设备400还可以通过网络适配器460与一个或者多个网络(例如局域网(LAN)，广域网(WAN)和/或公共网络，例如因特网)通信。网络适配器460可以通过总线430与电子设备400的其它模块通信。应当明白，尽管图中未示出，可以结合电子设备400使用其它硬件和/或软件模块，包括但不限于：微代码、设备驱动器、冗余处理单元、外部磁盘驱动阵列、RAID系统、磁带驱动器以及数据备份存储平台等。

本发明实施例还提供一种计算机可读存储介质，用于存储程序，程序被执行时实现上述实施例的应用程序崩溃日志的处理方法的步骤。在一些可能的实施方式中，本发明的各个方面还可以实现为一种程序产品的形式，其包括程序代码，当程序产品在终端设备上运行时，程序代码用于使终端设备执行本说明书上述网页曝光数据采集方法部分中描述的根据本发明各种示例性实施方式的步骤。

如上所述，本实施例的计算机可读存储介质能够对上报的崩溃日志进行符号化和聚类处理，并识别聚类所属的业务部门；同时在各个维度上进行统计，供其他系统读取，以及通过邮件等报警的方式通知相关人员。

图5是本发明的计算机可读存储介质的结构示意图。参考图5所示，描述了根据本发明的实施方式的用于实现上述方法的程序产品600，其可以采用便携式紧凑盘只读存储器(CD-ROM)并包括程序代码，并可以在终端设备，例如个人电脑上运行。然而，本发明的程序产品不限于此，在本文件中，可读存储介质可以是任何包含或存储程序的有形介质，该程序可以被指令执行系统、装置或者器件使用或者与其结合使用。

程序产品可以采用一个或多个可读介质的任意组合。可读介质可以是可读信号介质或者可读存储介质。可读存储介质例如可以为但不限于电、磁、光、电磁、红外线、或半导体的系统、装置或器件，或者任意以上的组合。可读存储介质的更具体的例子(非穷举的列表)包括：具有一个或多个导线的电连接、便携式盘、硬盘、随机存取存储器(RAM)、只读存储器(ROM)、可擦式可编程只读存储器(EPROM或闪存)、光纤、便携式紧凑盘只读存储器(CD-ROM)、光存储器件、磁存储器件、或者上述的任意合适的组合。

计算机可读存储介质可以包括在基带中或者作为载波一部分传播的数据信号，其中承载了可读程序代码。这种传播的数据信号可以采用多种形式，包括但不限于电磁信号、光信号或上述的任意合适的组合。可读存储介质还可以是可读存储介质以外的任何可读介质，该可读介质可以发送、传播或者传输用于由指令执行系统、装置或者器件使用或者与其结合使用的程序。可读存储介质上包含的程序代码可以用任何适当的介质传输，包括但不限于无线、有线、光缆、RF等等，或者上述的任意合适的组合。

可以以一种或多种程序设计语言的任意组合来编写用于执行本发明操作的程序代码，程序设计语言包括面向对象的程序设计语言—诸如Java、C++等，还包括常规的过程式程序设计语言—诸如“C”语言或类似的程序设计语言。程序代码可以完全地在用户计算设备上执行、部分地在用户设备上执行、作为一个独立的软件包执行、部分在用户计算设备上部分在远程计算设备上执行、或者完全在远程计算设备或服务器上执行。在涉及远程计算设备的情形中，远程计算设备可以通过任意种类的网络，包括局域网(LAN)或广域网(WAN)，连接到用户计算设备，或者，可以连接到外部计算设备(例如利用因特网服务提供商来通过因特网连接)。

以上内容是结合具体的优选实施方式对本发明所作的进一步详细说明，不能认定本发明的具体实施只局限于这些说明。对于本发明所属技术领域的普通技术人员来说，在不脱离本发明构思的前提下，还可以做出若干简单推演或替换，都应当视为属于本发明的保护范围。

Claims (16)

1.一种应用程序崩溃日志的处理方法，其特征在于，包括如下步骤：

接收应用程序上报的崩溃日志；

对所述崩溃日志进行符号化处理，将所述崩溃日志的格式转化成可读格式；

解析所述崩溃日志，获取所述崩溃日志的指纹信息；

计算各崩溃日志的指纹信息之间的相似度，将指纹信息的相似度高于预设的相似度阈值的崩溃日志归入同一崩溃聚类；

获取所述崩溃聚类的特征信息，根据所述特征信息将所述崩溃聚类推送至对应的业务部门。

2.如权利要求1所述的处理方法，其特征在于，对所述崩溃日志进行符号化处理的步骤包括：

获取所述崩溃日志包含的操作系统平台信息；

根据所述操作系统平台信息，获取对应版本的所述应用程序编译时生成的符号表；

根据所述符号表，对所述崩溃日志进行符号化处理。

3.如权利要求2所述的处理方法，其特征在于，通过异步下载队列下载所述符号表，并根据LRU淘汰机制对下载的所述符号表进行过滤。

4.如权利要求1所述的处理方法，其特征在于，获取所述崩溃日志的指纹信息的步骤包括：

解析所述崩溃日志，过滤所述崩溃日志中的噪音信息；

提取所述崩溃日志中包含的导致所述应用程序崩溃的错误堆栈；

根据所述错误堆栈，采用Hash函数计算所述崩溃日志的指纹信息。

5.如权利要求1所述的处理方法，其特征在于，采用LCS算法计算各崩溃日志的指纹信息之间的相似度。

6.如权利要求5所述的处理方法，其特征在于，当一崩溃日志的指纹信息与其余崩溃日志的指纹信息之间的相似度均未达所述相似度阈值时，将该崩溃日志单独创建一崩溃聚类。

7.如权利要求1所述的处理方法，其特征在于，根据所述特征信息将所述崩溃聚类推送至对应的业务部门的步骤包括：

获取所述崩溃聚类的包名或文件名，作为所述崩溃聚类的特征信息；

根据所述崩溃聚类的特征信息，遍历数据库中预存的特征信息与业务部门的映射关系表；

筛选出特征信息与所述崩溃聚类的特征信息相匹配的业务部门，推送所述崩溃聚类。

8.如权利要求7所述的处理方法，其特征在于，预存所述特征信息与业务部门的映射关系表的步骤包括：

扫描所述应用程序的代码，获取所述应用程序的代码所包含的各单元的包名和文件名，映射至对应的业务部门；

将各单元的包名和文件名作为各单元的特征信息，与对应的业务部门建立所述映射关系表。

9.如权利要求1所述的处理方法，其特征在于，通过消息队列的异步方式接收所述应用程序上报的所述崩溃日志；以及

接收所述崩溃日志后，对所述崩溃日志进行预处理，所述预处理包括解密和解压缩。

10.如权利要求1所述的处理方法，其特征在于，还包括：

对所述崩溃日志进行实时统计，统计维度包括：对应不同操作系统平台的不同客户端版本，所述应用程序在预设周期内的总崩溃数、影响用户数和各崩溃类别占比。

11.如权利要求10所述的处理方法，其特征在于，还包括：

为每一统计维度预设一参数阈值，对统计结果进行周期性检查，当一统计维度下统计结果超出该统计维度下预设的参数阈值时，推送报警信息。

12.一种应用程序崩溃日志的处理系统，其特征在于，包括：

符号化处理模块，接收应用程序上报的崩溃日志，对所述崩溃日志进行符号化处理，将所述崩溃日志的格式转化成可读格式；

聚类模块，解析所述崩溃日志，获取所述崩溃日志的指纹信息，计算各崩溃日志的指纹信息之间的相似度，将指纹信息的相似度高于预设的相似度阈值的崩溃日志归入同一崩溃聚类；

标签化模块，获取所述崩溃聚类的特征信息，根据所述特征信息将所述崩溃聚类推送至对应的业务部门。

13.如权利要求12所述的处理系统，其特征在于，还包括：

统计模块，对所述崩溃日志进行实时统计，统计维度包括：对应不同操作系统平台的不同客户端版本，所述应用程序在预设周期内的总崩溃数、影响用户数和各崩溃类别占比。

14.如权利要求12所述的处理系统，其特征在于，还包括：

报警模块，为每一统计维度预设一参数阈值，对统计结果进行周期性检查，当一统计维度下统计结果超出该统计维度下预设的参数阈值时，推送报警信息。

15.一种电子设备，其特征在于，包括：

处理器；以及

存储器，用于存储可执行指令；

其中，所述处理器配置为经由执行所述可执行指令来执行权利要求1～11任一项所述的应用程序崩溃日志的处理方法的步骤。

16.一种计算机可读存储介质，其上存储有计算机程序，其特征在于，所述计算机程序被处理器执行时实现权利要求1～11任一项所述的应用程序崩溃日志的处理方法的步骤。