一种日志处理方法及装置、设备与流程

本发明涉及智能终端技术，尤指一种日志处理方法及装置、设备。

背景技术：

android是基于java和c/c++编写而成的操作系统，同样android应用也可以使用java和c/c++编写应用代码，java和c/c++之间通过jni进行沟通，java代码运行在java虚拟机之上，c/c++代码编译成so库，被java虚拟机调用。android应用的这种可以使用java和c/c++编写代码的属性，决定了android应用会出现java层的应用崩溃和native层的应用崩溃(即c/c++代码出错)。一般来说，native应用崩溃、java应用崩溃是由于空指针、引用越界、内存泄露等导致。

目前各大手机厂商都在机器预制了当系统出现异常时，自动上传异常信息到服务器供开发人员分析的模块。其一般实现原理是在系统中出现异常时，抓取系统的一些信息，并将这些信息压缩后通过网络上传到服务器上，服务器端根据上传的机器imei号定位该机器具体出现了什么异常。相关技术中，服务器端收到终端上传的大量应用崩溃日志之后，开发人员需要对每一条日志进行分析，不仅费时耗力，成本高，而且不能及时准确的找到终端存在的问题，从而无法及时完成终端的系统维修，以至于降低了用户体验。

技术实现要素：

针对上述技术问题，本发明提供了一种日志处理方法及装置，能够将相同原因导致的崩溃日志进行归并，使开发人员更快速对崩溃日志进行分析，以快速、准确的找到终端存在的问题。

本申请提供了：

一种日志处理方法，应用于服务器端，包括：

接收来自客户端的崩溃异常堆栈；

将所述崩溃异常堆栈所指示原因相同的应用崩溃日志归并。

其中，所述应用崩溃日志为如下之一：

java层崩溃日志；

native层崩溃日志。

其中，所述将所述崩溃异常堆栈所指示原因相同的应用崩溃日志归并，包括：解析所述崩溃异常堆栈，获取崩溃堆栈信息；将所述崩溃堆栈信息中应用包名、原因和堆栈相同的应用崩溃日志归并。

其中，所述将所述崩溃异常堆栈所指示原因相同的应用崩溃日志归并，包括：解析所述崩溃异常堆栈，获取崩溃堆栈信息；将所述崩溃堆栈信息中应用包名、问题信号、崩溃返回码、崩溃信息以及堆栈相同的应用崩溃日志归并。

一种日志处理装置，包括：

接收模块，用于接收来自客户端的崩溃异常堆栈；

归并模块，用于将所述崩溃异常堆栈所指示原因相同的应用崩溃日志归并。

其中，所述应用崩溃日志为如下之一：

java层崩溃日志；

native层崩溃日志。

其中，所述归并模块，具体用于：解析所述崩溃异常堆栈，获取崩溃堆栈信息；将所述崩溃堆栈信息中应用包名、原因和堆栈相同的应用崩溃日志归并。

其中，所述归并模块，具体用于：解析所述崩溃异常堆栈，获取崩溃堆栈信息；将所述崩溃堆栈信息中应用包名、问题信号、崩溃返回码、崩溃信息以及堆栈相同的应用崩溃日志归并。

一种设备，包括存储器、处理器及存储在所述存储器上并可在所述处理器上运行的计算机程序，所述处理器执行所述计算机程序时实现以下步骤：

接收来自客户端的崩溃异常堆栈；

将所述崩溃异常堆栈所指示原因相同的应用崩溃日志归并。

一种计算机可读存储介质，其上存储有计算机程序，所述计算机程序被处理器执行时实现以下步骤：

接收来自客户端的崩溃异常堆栈；

将所述崩溃异常堆栈所指示原因相同的应用崩溃日志归并。

本申请能够将相同原因导致的崩溃日志进行归并，归并后大量的应用崩溃日志将归并成少量的不同崩溃原因导致的应用崩溃日志，开发人员只对这些经过归并的应用崩溃日志进行分析即可，一次即可对同一类应用崩溃日志进行分析，不仅省时省力，成本低，而且使开发人员能够快速完成崩溃日志的分析，以快速、准确的找到终端存在的问题。

此外，便于终端生产商根据归并后的应用崩溃日志，获取各类型终端的崩溃日志中各种问题出现的比率等数据，能够更加有针对性的进行处理，有利于改善终端的整体性能，并提高用户体验。

附图说明

此处所说明的附图用来提供对本发明的进一步理解，构成本申请的一部分，本发明的示意性实施例及其说明用于解释本发明，并不构成对本发明的不当限定。在附图中：

图1为实现本发明各个实施例的移动终端的硬件结构示意；

图2为支持本发明移动终端之间进行通信的通信系统的示意图；

图3为本申请日志处理方法的流程示意图；

图4为本申请java层崩溃日志处理的流程示意图；

图5为本申请native层崩溃日志的流程示意图；

图6为本申请日志处理装置的组成结构示意图；

图7为本申请中服务器的结构示意图。

具体实施方式

下面将结合附图及实施例对本发明的技术方案进行更详细的说明。

现在将参考附图描述实现本发明各个实施例的终端。在后续的描述中，使用用于表示元件的诸如“模块”、“部件”或“单元”的后缀仅为了有利于本发明的说明，其本身并没有特定的意义。因此，"模块"与"部件"可以混合地使用。

终端可以以各种形式来实施。例如，本发明中描述的终端可以包括诸如移动电话、智能电话、笔记本电脑、数字广播接收器、pda(个人数字助理)、pad(平板电脑)、pmp(便携式多媒体播放器)、导航装置等等的移动终端以及诸如数字tv、台式计算机等等的固定终端。下面，以终端是移动终端为例进行说明。然而，本领域技术人员将理解的是，除了特别用于移动目的的元件之外，根据本发明的实施方式的构造也能够应用于固定类型的终端。

图1为实现本发明各个实施例的移动终端的硬件结构示意图。

移动终端100可以包括无线通信单元110、a/v(音频/视频)输入单元120、用户输入单元130、感测单元140、输出单元150、存储器160、接口单元170、控制器180和电源单元190等等。图1示出了具有各种组件的移动终端，但是应理解的是，并不要求实施所有示出的组件。可以替代地实施更多或更少的组件。将在下面详细描述移动终端的元件。

无线通信单元110通常包括一个或多个组件，其允许移动终端100与无线通信系统或网络之间的无线电通信。例如，无线通信单元可以包括广播接收模块111、移动通信模块112、无线互联网模块113、短程通信模块114和位置信息模块115中的至少一个。

广播接收模块111经由广播信道从外部广播管理服务器接收广播信号和/或广播相关信息。广播信道可以包括卫星信道和/或地面信道。广播管理服务器可以是生成并发送广播信号和/或广播相关信息的服务器或者接收之前生成的广播信号和/或广播相关信息并且将其发送给终端的服务器。广播信号可以包括tv广播信号、无线电广播信号、数据广播信号等等。而且，广播信号可以进一步包括与tv或无线电广播信号组合的广播信号。广播相关信息也可以经由移动通信网络提供，并且在该情况下，广播相关信息可以由移动通信模块112来接收。广播信号可以以各种形式存在，例如，其可以以数字多媒体广播(dmb)的电子节目指南(epg)、数字视频广播手持(dvb-h)的电子服务指南(esg)等等的形式而存在。广播接收模块111可以通过使用各种类型的广播系统接收信号广播。特别地，广播接收模块111可以通过使用诸如多媒体广播-地面(dmb-t)、数字多媒体广播-卫星(dmb-s)、数字视频广播-手持(dvb-h)，前向链路媒体(mediaflo^@)的数据广播系统、地面数字广播综合服务(isdb-t)等等的数字广播系统接收数字广播。广播接收模块111可以被构造为适合提供广播信号的各种广播系统以及上述数字广播系统。经由广播接收模块111接收的广播信号和/或广播相关信息可以存储在存储器160(或者其它类型的存储介质)中。

移动通信模块112将无线电信号发送到基站(例如，接入点、节点b等等)、外部终端以及服务器中的至少一个和/或从其接收无线电信号。这样的无线电信号可以包括语音通话信号、视频通话信号、或者根据文本和/或多媒体消息发送和/或接收的各种类型的数据。

无线互联网模块113支持移动终端的无线互联网接入。该模块可以内部或外部地耦接到终端。该模块所涉及的无线互联网接入技术可以包括wlan(无线lan)(wi-fi)、wibro(无线宽带)、wimax(全球微波互联接入)、hsdpa(高速下行链路分组接入)等等。

短程通信模块114是用于支持短程通信的模块。短程通信技术的一些示例包括蓝牙^tm、射频识别(rfid)、红外数据协会(irda)、超宽带(uwb)、紫蜂^tm等等。

位置信息模块115是用于检查或获取移动终端的位置信息的模块。位置信息模块的典型示例是gps(全球定位系统)。根据当前的技术，gps模块115计算来自三个或更多卫星的距离信息和准确的时间信息并且对于计算的信息应用三角测量法，从而根据经度、纬度和高度准确地计算三维当前位置信息。当前，用于计算位置和时间信息的方法使用三颗卫星并且通过使用另外的一颗卫星校正计算出的位置和时间信息的误差。此外，gps模块115能够通过实时地连续计算当前位置信息来计算速度信息。

a/v输入单元120用于接收音频或视频信号。a/v输入单元120可以包括相机121和麦克风1220，相机121对在视频捕获模式或图像捕获模式中由图像捕获装置获得的静态图片或视频的图像数据进行处理。处理后的图像帧可以显示在显示单元151上。经相机121处理后的图像帧可以存储在存储器160(或其它存储介质)中或者经由无线通信单元110进行发送，可以根据移动终端的构造提供两个或更多相机1210。麦克风122可以在电话通话模式、记录模式、语音识别模式等等运行模式中经由麦克风接收声音(音频数据)，并且能够将这样的声音处理为音频数据。处理后的音频(语音)数据可以在电话通话模式的情况下转换为可经由移动通信模块112发送到移动通信基站的格式输出。麦克风122可以实施各种类型的噪声消除(或抑制)算法以消除(或抑制)在接收和发送音频信号的过程中产生的噪声或者干扰。

用户输入单元130可以根据用户输入的命令生成键输入数据以控制移动终端的各种操作。用户输入单元130允许用户输入各种类型的信息，并且可以包括键盘、锅仔片、触摸板(例如，检测由于被接触而导致的电阻、压力、电容等等的变化的触敏组件)、滚轮、摇杆等等。特别地，当触摸板以层的形式叠加在显示单元151上时，可以形成触摸屏。

感测单元140检测移动终端100的当前状态，(例如，移动终端100的打开或关闭状态)、移动终端100的位置、用户对于移动终端100的接触(即，触摸输入)的有无、移动终端100的取向、移动终端100的加速或减速移动和方向等等，并且生成用于控制移动终端100的操作的命令或信号。例如，当移动终端100实施为滑动型移动电话时，感测单元140可以感测该滑动型电话是打开还是关闭。另外，感测单元140能够检测电源单元190是否提供电力或者接口单元170是否与外部装置耦接。感测单元140可以包括接近传感器1410将在下面结合触摸屏来对此进行描述。

接口单元170用作至少一个外部装置与移动终端100连接可以通过的接口。例如，外部装置可以包括有线或无线头戴式耳机端口、外部电源(或电池充电器)端口、有线或无线数据端口、存储卡端口、用于连接具有识别模块的装置的端口、音频输入/输出(i/o)端口、视频i/o端口、耳机端口等等。识别模块可以是存储用于验证用户使用移动终端100的各种信息并且可以包括用户识别模块(uim)、客户识别模块(sim)、通用客户识别模块(usim)等等。另外，具有识别模块的装置(下面称为"识别装置")可以采取智能卡的形式，因此，识别装置可以经由端口或其它连接装置与移动终端100连接。接口单元170可以用于接收来自外部装置的输入(例如，数据信息、电力等等)并且将接收到的输入传输到移动终端100内的一个或多个元件或者可以用于在移动终端和外部装置之间传输数据。

另外，当移动终端100与外部底座连接时，接口单元170可以用作允许通过其将电力从底座提供到移动终端100的路径或者可以用作允许从底座输入的各种命令信号通过其传输到移动终端的路径。从底座输入的各种命令信号或电力可以用作用于识别移动终端是否准确地安装在底座上的信号。输出单元150被构造为以视觉、音频和/或触觉方式提供输出信号(例如，音频信号、视频信号、警报信号、振动信号等等)。输出单元150可以包括显示单元151、音频输出模块152、警报单元153等等。

显示单元151可以显示在移动终端100中处理的信息。例如，当移动终端100处于电话通话模式时，显示单元151可以显示与通话或其它通信(例如，文本消息收发、多媒体文件下载等等)相关的用户界面(ui)或图形用户界面(gui)。当移动终端100处于视频通话模式或者图像捕获模式时，显示单元151可以显示捕获的图像和/或接收的图像、示出视频或图像以及相关功能的ui或gui等等。

同时，当显示单元151和触摸板以层的形式彼此叠加以形成触摸屏时，显示单元151可以用作输入装置和输出装置。显示单元151可以包括液晶显示器(lcd)、薄膜晶体管lcd(tft-lcd)、有机发光二极管(oled)显示器、柔性显示器、三维(3d)显示器等等中的至少一种。这些显示器中的一些可以被构造为透明状以允许用户从外部观看，这可以称为透明显示器，典型的透明显示器可以例如为toled(透明有机发光二极管)显示器等等。根据特定想要的实施方式，移动终端100可以包括两个或更多显示单元(或其它显示装置)，例如，移动终端可以包括外部显示单元(未示出)和内部显示单元(未示出)。触摸屏可用于检测触摸输入压力以及触摸输入位置和触摸输入面积。

音频输出模块152可以在移动终端处于呼叫信号接收模式、通话模式、记录模式、语音识别模式、广播接收模式等等模式下时，将无线通信单元110接收的或者在存储器160中存储的音频数据转换音频信号并且输出为声音。而且，音频输出模块152可以提供与移动终端100执行的特定功能相关的音频输出(例如，呼叫信号接收声音、消息接收声音等等)。音频输出模块152可以包括扬声器、蜂鸣器等等。

警报单元153可以提供输出以将事件的发生通知给移动终端100。典型的事件可以包括呼叫接收、消息接收、键信号输入、触摸输入等等。除了音频或视频输出之外，警报单元153可以以不同的方式提供输出以通知事件的发生。例如，警报单元153可以以振动的形式提供输出，当接收到呼叫、消息或一些其它进入通信(incomingcommunication)时，警报单元153可以提供触觉输出(即，振动)以将其通知给用户。通过提供这样的触觉输出，即使在用户的移动电话处于用户的口袋中时，用户也能够识别出各种事件的发生。警报单元153也可以经由显示单元151或音频输出模块152提供通知事件的发生的输出。

存储器160可以存储由控制器180执行的处理和控制操作的软件程序等等，或者可以暂时地存储己经输出或将要输出的数据(例如，电话簿、消息、静态图像、视频等等)。而且，存储器160可以存储关于当触摸施加到触摸屏时输出的各种方式的振动和音频信号的数据。

存储器160可以包括至少一种类型的存储介质，所述存储介质包括闪存、硬盘、多媒体卡、卡型存储器(例如，sd或dx存储器等等)、随机访问存储器(ram)、静态随机访问存储器(sram)、只读存储器(rom)、电可擦除可编程只读存储器(eeprom)、可编程只读存储器(prom)、磁性存储器、磁盘、光盘等等。而且，移动终端100可以与通过网络连接执行存储器160的存储功能的网络存储装置协作。

控制器180通常控制移动终端的总体操作。例如，控制器180执行与语音通话、数据通信、视频通话等等相关的控制和处理。另外，控制器180可以包括用于再现(或回放)多媒体数据的多媒体模块1810，多媒体模块1810可以构造在控制器180内，或者可以构造为与控制器180分离。控制器180可以执行模式识别处理，以将在触摸屏上执行的手写输入或者图片绘制输入识别为字符或图像。

电源单元190在控制器180的控制下接收外部电力或内部电力并且提供操作各元件和组件所需的适当的电力。

这里描述的各种实施方式可以以使用例如计算机软件、硬件或其任何组合的计算机可读介质来实施。对于硬件实施，这里描述的实施方式可以通过使用特定用途集成电路(asic)、数字信号处理器(dsp)、数字信号处理装置(dspd)、可编程逻辑装置(pld)、现场可编程门阵列(fpga)、处理器、控制器、微控制器、微处理器、被设计为执行这里描述的功能的电子单元中的至少一种来实施，在一些情况下，这样的实施方式可以在控制器180中实施。对于软件实施，诸如过程或功能的实施方式可以与允许执行至少一种功能或操作的单独的软件模块来实施。软件代码可以由以任何适当的编程语言编写的软件应用程序(或程序)来实施，软件代码可以存储在存储器160中并且由控制器180执行。

至此，己经按照其功能描述了移动终端。下面，为了简要起见，将描述诸如折叠型、直板型、摆动型、滑动型移动终端等等的各种类型的移动终端中的滑动型移动终端作为示例。因此，本发明能够应用于任何类型的移动终端，并且不限于滑动型移动终端。

如图1中所示的移动终端100可以被构造为利用经由帧或分组发送数据的诸如有线和无线通信系统以及基于卫星的通信系统来操作。

现在将参考图2描述其中根据本发明的移动终端能够操作的通信系统。

这样的通信系统可以使用不同的空中接口和/或物理层。例如，由通信系统使用的空中接口包括例如频分多址(fdma)、时分多址(tdma)、码分多址(cdma)和通用移动通信系统(umts)(特别地，长期演进(lte))、全球移动通信系统(gsm)等等。作为非限制性示例，下面的描述涉及cdma通信系统，但是这样的教导同样适用于其它类型的系统。

参考图2，cdma无线通信系统可以包括多个移动终端100、多个基站(bs)270、基站控制器(bsc)275和移动交换中心(msc)280。msc280被构造为与公共电话交换网络(pstn)290形成接口。msc280还被构造为与可以经由回程线路耦接到基站270的bsc275形成接口。回程线路可以根据若干己知的接口中的任一种来构造，所述接口包括例如e1/t1、atm，ip、ppp、帧中继、hdsl、adsl或xdsl。将理解的是，如图2中所示的系统可以包括多个bsc2750。

每个bs270可以服务一个或多个分区(或区域)，由多向天线或指向特定方向的天线覆盖的每个分区放射状地远离bs270。或者，每个分区可以由用于分集接收的两个或更多天线覆盖。每个bs270可以被构造为支持多个频率分配，并且每个频率分配具有特定频谱(例如，1.25mhz,5mhz等等)。

分区与频率分配的交叉可以被称为cdma信道。bs270也可以被称为基站收发器子系统(bts)或者其它等效术语。在这样的情况下，术语"基站"可以用于笼统地表示单个bsc275和至少一个bs270。基站也可以被称为"蜂窝站"。或者，特定bs270的各分区可以被称为多个蜂窝站。

如图2中所示，广播发射器(bt)295将广播信号发送给在系统内操作的移动终端100。如图1中所示的广播接收模块111被设置在移动终端100处以接收由bt295发送的广播信号。在图2中，示出了几个全球定位系统(gps)卫星300。卫星300帮助定位多个移动终端100中的至少一个。

在图2中，描绘了多个卫星300，但是理解的是，可以利用任何数目的卫星获得有用的定位信息。如图1中所示的gps模块115通常被构造为与卫星300配合以获得想要的定位信息。替代gps跟踪技术或者在gps跟踪技术之外，可以使用可以跟踪移动终端的位置的其它技术。另外，至少一个gps卫星300可以选择性地或者额外地处理卫星dmb传输。

作为无线通信系统的一个典型操作，bs270接收来自各种移动终端100的反向链路信号。移动终端100通常参与通话、消息收发和其它类型的通信。特定基站270接收的每个反向链路信号被在特定bs270内进行处理。获得的数据被转发给相关的bsc275。bsc提供通话资源分配和包括bs270之间的软切换过程的协调的移动管理功能。bsc275还将接收到的数据路由到msc280，其提供用于与pstn290形成接口的额外的路由服务。类似地，pstn290与msc280形成接口，msc与bsc275形成接口，并且bsc275相应地控制bs270以将正向链路信号发送到移动终端100。

基于上述移动终端硬件结构以及通信系统，提出本发明方法各个实施例。

在程序开发过程中，log是广泛使用的用来记录程序执行过程的机制。android为用户空间的程序开发人员提供了轻量级的logger日志系统，该日志系统是以驱动程序的形式实现在内核空间中的，产生的log是以设备文件的形式存储在文件夹/dev/log/中，该日志系统提供了写log到设备文件和从设备文件中读log接口。android在用户空间提供了使用logger日志系统的java接口和c/c++接口供开发人员使用，log文件的写入是android框架层代码通过jni调用系统运行库，并通过系统运行库将log写入设备文件中；log文件的读取通过android提供的logcat工具执行，logcat工具根据开发人员输入的命令从设备文件中读取log，并根据开发人员的要求将经过格式化的log信息输出。

实际应用中，终端将大量的应用崩溃日志(如java层崩溃日志、native层崩溃日志等)上传给服务器，服务器接收终端上传的应用崩溃日志，开发人员需要对服务器上终端的大量应用崩溃日志进行分析，以找出终端存在的问题。

假如某终端厂商在市场上有1000万台机器，在终端的生命周期范围内应用java层崩溃异常上报率为10％，则服务器上将有100万条应用java层崩溃日志信息。假如某厂商在市场上有1000万台机器，手机生命周期范围内应用native层崩溃异常上报率为5％，则服务器上将有50万条应用native层崩溃日志信息。

如果开发人员对每一条日志都进行分析的话，很明显这是无法完成的任务。一方面，耗时费力，效率低，成本高；另一方面，对日志分析的速度和准确度，将直接影响到是否能及时准确的发现终端的问题，如果不能及时准确的发现终端存在的问题并予以解决，将会给用户以及终端生产商都带来损失。

针对上述问题，本申请提供一种日志处理方法，能够将相同原因导致的日志进行自动归并，便于开发人员对归并后的一类日志进行处理，一方面可以提高日志处理效率，降低人力成本和时间成本，另一方面，也能够有效提高日志处理的速度和准确度，从而使得开发人员能够及时准确的发现终端存在的问题，避免损失。

实施例一

根据本发明的一个实施例，提供了一种日志处理方法，如图3所示，包括：

步骤301，接收来自客户端的崩溃异常堆栈；

步骤302，将所述崩溃异常堆栈所指示原因相同的应用崩溃日志归并。

本实施例中，能够将相同原因导致的崩溃日志进行归并，归并后大量的应用崩溃日志将归并成少量的不同崩溃原因导致的应用崩溃日志，开发人员只对这些经过归并的应用崩溃日志进行分析即可，一次即可对同一类应用崩溃日志进行分析，不仅省时省力，成本低，而且使开发人员能够快速完成崩溃日志的分析，以快速、准确的找到终端存在的问题。此外，便于终端生产商根据归并后的应用崩溃日志，获取各类型终端的崩溃日志中各种问题出现的比率等数据，能够更加有针对性的进行处理，有利于改善终端的整体性能，并提高用户体验。

实际应用中，所述应用崩溃日志可以为如下之一：1)java层崩溃日志；2)native层崩溃日志。

一种实现方式中，将所述崩溃异常堆栈所指示原因相同的应用崩溃日志归并，可以包括：解析所述崩溃异常堆栈，获取崩溃堆栈信息；将所述崩溃堆栈信息中应用包名、原因和堆栈相同的应用崩溃日志归并。

另一种实现方式中，将所述崩溃异常堆栈所指示原因相同的应用崩溃日志归并，可以包括：解析所述崩溃异常堆栈，获取崩溃堆栈信息；将所述崩溃堆栈信息中应用包名、问题信号、崩溃返回码、崩溃信息以及堆栈相同的应用崩溃日志归并。

下面分别以不同实例来详细说明日志处理的过程。

实例1

本实例以android应用java层崩溃日志为例进行详细说明。

本实例中，android应用java层崩溃日志的处理方法可以包括：服务器接收客户端上传的应用java层崩溃日志，根据所述应用java层崩溃日志的java层崩溃堆栈信息(逻辑上认为对于相同的应用有相同java层崩溃堆栈信息是相同原因导致的)，将相同原因导致的java层崩溃日志进行归并。这样归并后，大量的应用java层崩溃日志将归并成少量的不同java层崩溃原因导致的应用java层崩溃日志，开发人员只对这些经过归并的应用java层崩溃日志进行分析即可，不仅省时省力，成本低，而且使开发人员能够快速完成应用java层崩溃日志的分析，以快速、准确的找到终端存在的问题。

实际应用中，制作应用java层崩溃日志自动解析脚本，通过运行该脚本可以对上传到服务器上的应用java崩溃日志进行解析归并。经过解析归并后，相同原因导致的应用java层崩溃日志将归并为一个相同问题，开发人员分析和解决问题会更加高效。

实际应用中，客户端在log上报系统中配置受保护的广播。当应用出现java层崩溃时，系统发送该广播到log上报系统中。log上报系统收到广播后，上传出现java层崩溃的崩溃异常堆栈至服务器，该崩溃异常堆栈为java层崩溃异常堆栈stack.txt，可以包括应用包名packagename、崩溃原因和java堆栈信息等内容。实际应用中，该客户端可以是如图1所示的终端。

服务器接收客户端上传的崩溃异常堆栈，解析客户端上传的java层崩溃异常堆栈stack.txt。通过java层崩溃异常堆栈stack.txt，可获取到出现java层崩溃的应用包名packagename，出现java层崩溃的原因reason，以及出现java层崩溃时的堆栈stack。如果两份java层崩溃日志的packagename、reason、stack都相同，则认为这两个java层崩溃是相同java层崩溃问题导致的。也就是说，将packagename、reason、stack都相同的java层崩溃日志归并为一类(例如，归并为一个队列)，便于开发人员按照归并的类别进行日志分析。

实际应用中，归并java层崩溃日志时可以将使用packagename+reason+stack作为关键字进行归并。其中，packagename、reason和stack分别为字符串，packagename+reason+stack为上述三个字符串链接在一起形成的匹配字符串，可以以该匹配字符串为关键字对java层崩溃日志进行匹配处理，从而将packagename、reason和stack都相同的java层崩溃日志放入同一队列进行处理。

如图4所示，本实例中日志处理的流程可以包括：

步骤401，获取stack.txt文件，从文件开头开始读取文件行，进入步骤402。

步骤402，读取下一行，读取结束？如果是，则进入步骤406；如果够，则进入步骤407。

步骤403，读取下一行，该行字符串是否以at或…开头，如果是则进入步骤405；如果不是，则进入步骤404。

步骤404，设置该行字符串为reason，返回步骤402。

步骤405，添加该行到stack中，返回步骤402。

步骤406，获取到了当前应用java崩溃日志的packagename、reason、trace之后，在已有应用java层崩溃问题队列中查找是否包含当前应用java崩溃日志的packagename+reason+trace，如果是，则进入步骤407，否则进入步骤408。

步骤407，将该应用java崩溃日志作为已有应用java崩溃日志处理，结束。

步骤408，将packagename+reason+trace添加到应用java层崩溃问题队列，将该应用java层崩溃日志作为新的应用java层崩溃原因处理，结束。

本实例中，将上传到服务器的应用java层崩溃日志进行解析和归并处理。根据解析出的java层崩溃的堆栈信息，对相同原因导致的java层崩溃日志进行归并。经过归并后，大量的应用java层崩溃日志将归并成少量的不同java层崩溃原因导致的应用java层崩溃日志，开发人员只对这些经过归并的应用java层崩溃日志进行分析，不仅省时省力，成本低，而且使开发人员能够快速完成崩溃日志的分析，以快速、准确的找到终端存在的问题。此外，便于终端生产商根据归并后的应用崩溃日志，获取各类型终端的崩溃日志中各种问题出现的比率等数据，能够更加有针对性的进行处理，有利于改善终端的整体性能，并提高用户体验。

实例2

本实例以android应用native层崩溃日志为例进行详细说明。

本实例中，将上传到服务器的应用native层崩溃日志进行解析和归并处理。根据解析出的native层崩溃的堆栈信息(逻辑上认为对于相同的应用有相同native层崩溃堆栈信息是相同原因导致的)，对相同原因导致的native层崩溃日志进行归并。经过归并后，大量的应用native层崩溃日志将归并成少量的不同native层崩溃原因导致的应用native层崩溃日志，开发人员只对这些经过归并的应用native层崩溃日志进行分析即可，使得开发人员能够更加快速的完成应用native层崩溃日志的分析。

实际应用中，可以制作应用native层崩溃日志自动解析脚本，通过运行该脚本可以对上传到服务器的应用native崩溃日志进行解析归并。经过解析归并后，相同原因导致的应用native层崩溃日志将归并为一个相同问题，开发人员分析和解决问题会更加高效。

实际应用中，客户端在log上报系统中配置受保护的广播。当应用出现native层崩溃时，系统发送该广播到log上报系统中。log上报系统收到广播后，上传出现java层崩溃的崩溃异常堆栈至服务器，该崩溃异常堆栈为java层崩溃异常堆栈stack.txt，可以包括应用包名packagename、崩溃时native堆栈信息等内容。实际应用中，该客户端可以是如图1所示的终端。

服务器接收客户端上传的native层崩溃异常堆栈stack.txt并解析进行解析。通过native层崩溃异常堆栈stack.txt，可获取到出现native层崩溃的应用包名packagename、出现native层崩溃时问题信号signal、崩溃返回码code、崩溃信息abortmessage以及出现native层崩溃时的堆栈stack。如果两份native层崩溃日志的packagename、signal、code、abortmessage、stack都相同，则认为这两个native层崩溃日志是相同的native层崩溃问题导致的。也就是说，将packagename、signal、code、abortmessage、stack都相同的native层崩溃日志归并为一类(例如，归并为一个队列)，便于开发人员按照归并的类别进行native层崩溃日志分析。

实际应用中，归并native层崩溃日志时可以将使用packagename+signal+code+abortmessage+stack作为关键字进行归并。具体的，packagename、signal、code、abortmessage、stack都是字符串，packagename+signal+code+abortmessage

+stack为上述五个字符串链接在一起形成的匹配字符串，可以以该匹配字符串为关键字对native层崩溃日志进行匹配处理，从而将packagename、signal、code、abortmessage、stack都相同的native层崩溃日志放入同一队列进行处理。

如图5所示，本实例中应用native层崩溃日志的处理流程可以包括：

步骤501，获取stack.txt文件，从文件开头开始读取文件行，进入步骤502。

步骤502，读取下一行，是否读取结束，如果是则进入步骤510，如果不是则进入步骤503。

步骤503，该行字符串是否包含packagename，如果不是则进入步骤502；如果是则进入步骤504。

步骤504，获取下一行的问题信号(signal)、问题返回码(code)，继续进入步骤505。

步骤505，继续获取下一行的崩溃信息abortmessage，继续进入步骤506。

步骤506，读取下一行，是否读取结束，如果否则返回步骤507，如果是则进入步骤510。

步骤507，该行字符串是否包含回溯堆栈(backtrace)，如果否则返回步骤506；如果是则进入步骤508。

步骤508，继续读取下一行，是否读取结束，如果否则进入步骤509；如果是则进入步骤510。

步骤509，该行是否包含/system或者/data，如果是则继续步骤510，否则返回步骤508。

实际应用中，系统应用安装后，是安装在/system分区中。第三方应用或者系统应用更新包是安装在/data分区中。所以当发生nativecrash时，出现异常的库文件的路径以/system或/data开头。因此，在步骤509中要验证该含是否包含/system或者/data，以确认是否为出现异常的库文件。

步骤510，将该字符串存入stack。

步骤511，此时已获取到当前应用native崩溃日志的packagename，signal、code、abortmessage以及stack，判断已有应用native层崩溃问题队列中查找是否包含packagename+signal+code+abortmessage+stack，如果是则进入步骤512，否则进入步骤513。

步骤512，将该应用native崩溃日志作为已有应用native崩溃日志处理，结束。

步骤513，将packagename+signal+code+abortmessage+stack添加到应用native层崩溃问题队列，将该应用native层崩溃日志作为新的应用native层崩溃原因处理，结束。

本实例中，将上传到服务器的应用native层崩溃日志进行解析和归并处理。根据native层崩溃的堆栈信息，对相同原因导致的native层崩溃日志进行归并。经过归并后，大量的应用native层崩溃日志将归并成少量的不同native层崩溃原因导致的应用native层崩溃日志，开发人员只对这些经过归并的应用native层崩溃日志进行分析，不仅省时省力，成本低，而且使开发人员能够快速完成崩溃日志的分析，以快速、准确的找到终端存在的问题。此外，便于终端生产商根据归并后的应用崩溃日志，获取各类型终端的崩溃日志中各种问题出现的比率等数据，能够更加有针对性的进行处理，有利于改善终端的整体性能，并提高用户体验。

实施例二

根据本发明的另一实施例，提供了一种日志处理装置，如图6所示，可以包括：

接收模块61，用于接收来自客户端的崩溃异常堆栈；

归并模块62，用于将所述崩溃异常堆栈所指示原因相同的应用崩溃日志归并。

实际应用中，所述应用崩溃日志为如下之一：java层崩溃日志；native层崩溃日志。

一种实现方式中，所述归并模块62，具体可以用于：解析所述崩溃异常堆栈，获取崩溃堆栈信息；将所述崩溃堆栈信息中应用包名、原因和堆栈相同的应用崩溃日志归并。

另一种实现方式中，所述归并模块62，具体可以用于：解析所述崩溃异常堆栈，获取崩溃堆栈信息；将所述崩溃堆栈信息中应用包名、问题信号、崩溃返回码、崩溃信息以及堆栈相同的应用崩溃日志归并。

本实施例中的日志处理装置可以实现实施例一所述方法的所有细节，可参照方法的相关说明。实际应用中，本实施例中的日志处理装置可以通过设置于服务器或其他类似设备上来实现上述功能，或者本实施例中的日志处理装置可以直接通过服务器或其他类似设备来实现。

实际应用中，接收模块61和归并模块62分别可以通过软件、硬件或两者结合的方式实现。对此，本文不作限制。例如，接收模块61和归并模块62可以通过应用崩溃日志自动解析脚本来实现。

如图7所示，为上述服务器的结构示意图，包括：输入输出(io)总线、处理器70、存储器71、内存72和通信装置73。其中，

输入输出(io)总线分别与自身所属的服务器的其它部件(处理器70、存储器71、内存72和通信装置73)连接，并且为其它部件提供传送线路。

处理器70通常控制自身所属的服务器的总体操作。例如，处理器70执行计算和确认等操作。其中，处理器70可以是中央处理器(cpu)。

通信装置73，通常包括一个或多个组件，其允许自身所属的服务器与无线通信系统或网络之间的无线电通信。

存储器71存储处理器70可读、处理器可执行的软件代码，其包含用于控制处理器70执行本文描述的功能的指令(即软件执行功能)。

其中，上述日志处理装置中，实现接收模块61和归并模块62的功能的软件代码可存储在存储器71中，并由处理器70执行或编译后执行。

实施例三

根据本发明的又一实施例，提供了一种设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，所述处理器执行所述程序时实现以下步骤：

接收来自客户端的崩溃异常堆栈；

将所述崩溃异常堆栈所指示原因相同的应用崩溃日志归并。

本实施例中的设备可以实现实施例一所述方法的所有细节，可参照方法的相关说明。实际应用中，本实施例中的设备可以通过通过服务器或其他类似设备来实现。例如，可以通过图7所示的服务器来实现。

实施例四

根据本发明的又一实施例，提供了一种计算机可读存储介质，其上存储有计算机程序，该程序被处理器执行时实现以下步骤：

接收来自客户端的崩溃异常堆栈；

将所述崩溃异常堆栈所指示原因相同的应用崩溃日志归并。

可选地，在本实施例中，上述存储介质可以包括但不限于：u盘、只读存储器(rom，read-onlymemory)、随机存取存储器(ram，randomaccessmemory)、移动硬盘、磁碟或者光盘等各种可以存储程序代码的介质。

可选地，在本实施例中，处理器根据存储介质中已存储的程序代码执行上述实施例的方法步骤。

可选地，本实施例中的具体示例可以参考上述实施例及可选实施方式中所描述的示例，本实施例在此不再赘述。

需要说明的是，在本文中，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者装置不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者装置所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括该要素的过程、方法、物品或者装置中还存在另外的相同要素。

上述本发明实施例序号仅仅为了描述，不代表实施例的优劣。

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

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