崩溃日志的监听方法、设备、装置及存储介质与流程

1.本发明涉及计算机应用技术领域，具体涉及一种崩溃日志的监听方法、设备、装置及存储介质。


背景技术：

2.对于目前很多软件应用，用户正在使用软件时往往会出现异常问题，便会束手无策，通过层层反馈，再到软件解决问题，是一个比较耗时且存在解决周期的事，对于复现问题到排查问题往往耗时耗力，得不偿失。
3.android(安卓)是一种基于linux的自由及开放源代码的操作系统，主要用在移动设备上，如智能手机、平板电脑等。安卓系统由于其良好的开源特性，使得从事安卓应用程序开发的人员越来越多，进而也促使市面上出现了多版本的安卓系统和应用程序。众多的版本造成了系统的兼容性变差，使安卓系统的碎片化严重，常常出现应用程序崩溃的现象，有些严重的崩溃问题还发生在软件产品发布以后，使得用户体验变差。而崩溃是开发中不可避免的一件事，考虑不够周全的代码、糟糕的网络环境、让人头疼的碎片化问题都可能导致崩溃，更糟糕的是，当应用程序发生了崩溃之后，开发者却无法得知程序为何发生崩溃，因此需要知道用户崩溃时的崩溃信息。因此，崩溃信息的收集变得非常重要。然而，现有技术中，并没有较好的崩溃信息的收集方法。


技术实现要素：

4.本发明提供了一种崩溃日志的监听方法、设备、装置及存储介质，旨在解决程序发生异常之后无法很好的收集有效的异常数据的技术问题。
5.为实现上述目的，本发明提供了一种崩溃日志的监听方法，包括：
6.若监听到运行的应用程序存在异常，则获得应用程序对应的异常数据；
7.基于异常数据对应的异常类型对异常数据进行筛选处理，并存储筛选后的异常数据。
8.为实现上述目的，本技术还提出一种崩溃日志的监听装置，包括：
9.数据获取模块，用于若监听到运行的应用程序存在异常，则获得应用程序对应的异常数据；
10.数据筛选模块，用于基于异常数据对应的异常类型对异常数据进行筛选处理，并存储筛选后的异常数据。
11.为实现上述目的，本技术还提出一种崩溃日志的监听设备，崩溃日志的监听设备包括存储器、处理器以及存储在存储器上并可在处理器上运行的崩溃日志的监听程序，处理器执行崩溃日志的监听程序时实现上述的崩溃日志的监听方法的步骤。
12.为实现上述目的，本技术还提出一种计算机可读存储介质，计算机可读存储介质上存储有崩溃日志的监听程序，崩溃日志的监听程序被处理器执行时实现上述的崩溃日志的监听方法的步骤。
13.本技术中，通过对应用程序进行监听，若监听到存在应用程序有异常行为并导致崩溃，则获取异常行为对应的异常数据，然后对异常数据进行筛选，并存储筛选后的异常数据，从而使得开发维护人员能够基于存储下来的异常数据对应用程序的异常进行观测，更及时、准确的解决崩溃问题，避免消耗大量的时间对崩溃的原因进行排查。
附图说明
14.为了更清楚地说明本发明实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图示出的结构获得其他的附图。
15.图1为本发明一实施例的崩溃日志的监听方法的模块结构示意图；
16.图2为本发明一实施例的崩溃日志的监听方法的流程图；
17.图3为本发明一实施例的崩溃日志的监听方法的模块结构示意图。
具体实施方式
18.应当理解，此处所描述的具体实施例仅仅用以解释本发明，并不用于限定本发明。
19.请参照图1，图1为本发明各个实施例中所提供的崩溃日志的监听设备的硬件结构示意图。崩溃日志的监听设备包括执行模块01、存储器02、处理器03、电池系统等部件。本领域技术人员可以理解，图1中所示出的设备还可以包括比图示更多或更少的部件，或者组合某些部件，或者不同的部件布置。其中，处理器03分别与存储器02和执行模块01连接，存储器02上存储有崩溃日志的监听程序，崩溃日志的监听程序同时被处理器03执行。
20.执行模块01，可若监听到运行的应用程序存在异常，则获得所述应用程序对应的异常数据；基于异常数据对应的异常类型对异常数据进行筛选处理，并存储筛选后的异常数据。同时反馈以上信息发送给处理器03。
21.存储器02，可用于存储软件程序以及各种数据。存储器02可主要包括存储程序区和存储数据区，其中，存储程序区可存储操作系统、多个功能所需的应用程序等；存储数据区可存储根据物联网终端的使用所创建的数据或信息等。此外，存储器02可以包括高速随机存取存储器，还可以包括非易失性存储器，例如多个磁盘存储器件、闪存器件、或其他易失性固态存储器件。
22.处理器03，是处理平台的控制中心，利用各种接口和线路连接整个物联网终端的各个部分，通过运行或执行存储在存储器02内的软件程序和/或模块，以及调用存储在存储器02内的数据，执行物联网终端的各种功能和处理数据，从而对崩溃日志的监听设备进行整体监控。处理器03可包括一个或多个处理单元；优选的，处理器03可集成应用处理器和调制解调处理器，其中，应用处理器主要处理操作系统、用户界面和应用程序等，调制解调处理器主要处理无线通信。可以理解的是，上述调制解调处理器也可以不集成到处理器03中。
23.本领域技术人员可以理解，图1中示出的崩溃日志的监听设备结构并不构成对设备的限定，可以包括比图示更多或更少的部件，或者组合某些部件，或者不同的部件布置。
24.根据上述硬件结构，提出本发明方法各个实施例。
25.为了解决上述问题，本技术提出了一种崩溃日志的监听方法，参照图2，在本发明
崩溃日志的监听方法的第一实施例中，崩溃日志的监听方法包括：
26.步骤s100，若监听到运行的应用程序存在异常，则获得应用程序对应的异常数据；
27.本实施例中，监听应用程序的方式至少包括两种，第一种监听方式全局异常监听，即为自定义一个全局的监听入口，设置一个全局异常处理类的实现异常处理程序类接口，并全局设置为异常处理监听；第二种监听方式为单线程异常监听，即设置单线程的实现异常处理程序类接口，并为不同的线程单独设置异常处理监听。在一实施例中，全局异常监听可以是自定义一个全局的application，同时自定义一个crashhandler，然后将crashhandler设置为全局异常处理类，用于进行全局异常监听；在另一实施例中，单线程异常监听仅针对某一单独的线程，当应用程序发生一个未捕获的异常时，java虚拟机将会通过getdefaultuncaughtexceptionhandler的方法，来查询这个线程的uncaughtexceptionhandler，用于进行该线程中异常的监听。
28.本实施例中，无论是通过全局异常监听或是单线程异常监听，只要监听到应用程序存在异常，即获取应用程序的异常数据即可。例如，当应用程序开始运行，对各应用程序分别加载监听接口，并对这些监听接口分别进行初始化；这些监听接口用于监听native层是否存在异常。.
29.具体地，首先对各应用程序分别加载监听接口。本实施例中，监听接口通过监听器实现，监听器是一个实现特定接口的普通java程序，监听器用于监听另一个java对象的方法调用或属性的改变状况。每个监听接口内部包含了若干处理上述事件的抽象方法。通常每个应用程序都有一个监听接口与监听器相对应，每个接口还可以定义一个或多个监听方法。当特定的事件发生时，就会调用这些监听方法。例如，当被监听对象发生方法调用或属性改变事件后，设定在监听接口中的特定监听方法将立即被执行。本技术中的监听接口用于监听native层是否发生异常。linux存在一种信号机制，信号机制是linux进程间通信的一种重要的方式，linux信号一方面用于正常的任务调度和进程间通信。另一方面还负责监控系统的异常和中断，当系统发生异常时，linux内核将产生异常数据并且通知当前进程。监听程序收到了linux内核发出的异常数据通知，即知道native层发生了异常，于是便获取发生异常时的异常数据。
30.步骤s200，基于异常数据对应的异常类型对异常数据进行筛选处理，并存储筛选后的异常数据。
31.本实施例中，在获取应用程序发生异常时的异常数据之后，还需要进一步的对异常数据进行筛选，筛选的规则由本领域技术人员提前设置，并可进行实时调整。具体地，在native层面上引发应用程序异常的原因有许多种，例如硬件发生异常、非法内存访问、内存崩溃，或进程调用的库发现错误，给自己发送了中止信号使得进程终止等均会导致应用程序发生异常，由于应用程序发生异常的原因各不相同，因此应用程序发生异常时的异常数据也各不相同。异常数据指的是那些在应用程序运行过程中参与、涉及到的有用的软硬件信息，如异常数据可能是记录了异常发生过程的logcat日志，可能是正在使用的终端设备的信息、也可能是发生崩溃的应用程序的基本信息等。收集这类异常数据，能帮助程序开发人员全面了解发生native崩溃的具体原因。因此在应用程序发生异常时，需要收集不同的异常数据并进行筛选，然后将筛选过后的异常数据进行存储。
32.本技术通过对应用程序进行监听，若监听到存在应用程序有异常行为并导致崩
溃，则获取异常行为对应的异常数据，然后对异常数据进行筛选，并存储筛选后的异常数据，从而使得开发维护人员能够基于存储下来的异常数据对应用程序的异常进行观测，更及时、准确的解决崩溃问题，避免消耗大量的时间对崩溃的原因进行排查。
33.具体地，捕获异常数据之前需要捕获异常接口，并通过该异常接口获取异常数据。本实施例中，如果应用程序中出现异常数据，那么可以通过捕获异常接口来得到异常数据。其中，异常接口为异常数据的获取接口。具体地，如果native层出现了uncaught exception(未捕获异常),即可通过捕获异常接口来获取异常数据。
34.此外，引发应用程序发生异常的原因有许多。即异常数据对应的异常类型有很多，可根据异常数据获取这些异常数据对应的异常类型，并基于异常类型对异常数据进行筛选。即存储一部分异常类型的异常数据，并过滤掉另一部分异常类型的异常数据。
35.如上，例如硬件发生异常、代码异常、非法内存访问、内存崩溃，或进程调用的库发现错误，给自己发送了中止信号使得进程终止等异常类型均会导致应用程序发生异常，由于应用程序发生异常的原因各不相同，因此应用程序发生异常时的异常类型也各不相同，而异常类型可以根据异常数据获得。在一实施例中，硬件发生异常、代码异常、非法内存访问这三种异常类型的异常数据需要保存，其他异常类型均需要被过滤。
36.例如有如下c代码：
37.int*p＝0；
38.*p＝1；
39.当执行到第二行代码的时候，程序会发生崩溃。这里定义的指针p是一个空指针，给空指针赋值是不可以的，会导致native发生异常，进而崩溃。这样的异常类型可以归结为代码异常。
40.因此，则可将该次的异常数据进行存储。本实施例通过获取异常数据对应的异常类型，并根据异常类型对异常数据进行筛选，能够快速获取优先级较高类型的异常数据，既便于对程序的维护，又节省了内存。
41.在一实施例中，若监听到运行的应用程序存在异常，则获得应用程序对应的异常数据之后，方法还包括：
42.基于异常数据发送异常提示信息，异常提示信息用于提示用户发生异常。
43.在一实施例中，若监听到运行的应用程序存在异常，则获得应用程序对应的异常数据，包括：
44.若监听到运行的应用程序即将发生崩溃或已经发生崩溃，则获得即将发生奔溃或已经发生崩溃的应用程序对应的异常数据。
45.通常情况下，若应用程序发生异常，会进一步导致崩溃，而当崩溃发生时，系统会kill掉正在执行的应用程序，从而导致应用程序闪退，或者系统提示用户应用程序已经停止运行。然而本实施例中，若系统监听到应用程序存在异常，并且异常导致应用程序即将发生崩溃或监听到存在应用程序已经发生崩溃，则获取崩溃对应的异常数据，并基于该异常数据向用户发送异常提示信息，以提示用户应用程序发生异常，并可能即将导致崩溃或已经发生崩溃。
46.若应用程序还未发生崩溃，则异常提示信息可以提示用户做出应对，以避免崩溃的发生；若应用程序已经发生崩溃，则异常提示信息可以提示用户阻止系统kill正在运行
的应用程序，避免崩溃的影响进一步扩大。
47.在一实施例中，基于异常数据对应的异常类型对异常数据进行筛选处理，并存储筛选后的异常数据，包括：
48.根据预先设置的异常类型优先级确定异常数据对应的异常类型；
49.若异常数据的异常类型为重要优先级，则将异常数据设置为重要异常数据，并存储重要异常数据；其中，重要异常数据为即将不可控的异常数据，重要优先级为与重要异常数据存在对应关系的异常类型。
50.在一实施例中，根据预先设置的异常类型优先级确定异常数据对应的异常类型之后，方法还包括：
51.若异常数据的异常类型为一般优先级，则将异常数据设置为一般异常数据，并过滤一般异常数据；其中，一般异常数据为可控的异常数据，一般优先级为与一般异常数据存在对应关系的异常类型。
52.本实施例中，根据异常数据的异常类型的异常类型优先级，可将异常数据分为重要异常数据和一般异常数据，异常数据的优先级由本领域技术人员或用户提前设置，并可根据具体情况进行实时调整。具体地，本领域技术人员可以根据异常数据造成的影响对异常数据进行优先级设置，也可以根据用户设置的关注度对异常数据进行优先级设置。
53.在一些实施例中，根据根据异常数据造成的影响对异常数据进行优先级设置，在异常数据对应的异常类型中，有些异常类型造成的崩溃是可控的，有些异常类型造成的崩溃是不可控的；为了避免不可控的数据异常带来过大的影响，需要筛选出不可控的异常数据进行存储，因此即将不可控的异常数据的异常类型设置为重要优先级，并筛选出这些重要优先级的异常数据进行存储，以便后续过程中本领域技术人员基于这些重要优先级的异常数据对应用程序进行维护和修复。
54.在另一些实施例中，根据用户的关注度对异常数据进行分类。若用户想要对非法内存访问这一类型的异常进行分析，那么就可以将非法内存访问这一类型设置为重要优先级，将其他异常类型均设置为一般优先级。然后将重要优先级的异常数据进行存储，将一般优先级的异常数据进行过滤。通过本实施例中的数据分类存储方式，能够集中收集用户较为关注的异常数据，方便用户迅速得到想要的异常类型的异常数据，来进行统一分析。
55.此外，本实施例中可以将所有类型均设置为重要优先级，也可以将所有类型均设置为一般优先级，还可以按照数据类型将所有异常数据进行灵活划分，分成三种、四种甚至更多优先级，在此不做具体限定。通过异常类型的划分，用户可以仅存储对其自己而言重要程度较高的异常数据，而过滤掉一些重要程度低的异常数据，从而节省内存。
56.在一实施例中，存储筛选后的异常数据，包括：
57.将筛选后的异常数据存入设备或存储磁盘中的指定路径。
58.本实施例中，异常数据记录了发生崩溃时的主要信息，程序开发人员通过对异常数据的分析，就能够找到崩溃发生的原因。此外，异常数据中可能出现重复的信息，因此在对异常数据进行存储之前，还需要一个去重的过程。进一步地，存储筛选之后异常数据的步骤可以是将筛选之后的异常数据写入应用程序运行的设备中的指定路径中，也可以是将筛选之后的异常数据存入存储磁盘中的指定路径中，还可以将筛选之后的异常数据上传云服务器。值得注意的是，可以单独以上述方式中的一种对异常数据进行存储，也可以以上述方
式中的多种对异常数据进行存储。在对异常数据进行存储之后，开发人员可以根据异常数据的存储路径或存储方式来获取存储的异常数据，并通过对异常数据的分析，对应用程序进行维护和修复。
59.在一实施例中，将筛选后的异常数据存入设备或存储磁盘中的指定路径之后，方法还包括：
60.若接收到异常数据导出请求；
61.对导出请求进行身份校验，若身份校验通过，则导出筛选后的异常数据。
62.本实施例中，在对筛选之后的异常数据以日志信息的形式存入设备、存储磁盘或云服务器之后，若用户想要读取或者导出这些存储的异常数据，需要通过身份校验。只有通过了身份校验，用户才能读取或导出存储的异常数据，若未通过身份校验，用户无法读取或者导出存储的异常数据。
63.如图3所示，本发明还提出一种一种崩溃日志的监听装置，崩溃日志的监听装置包括：
64.数据获取模块a10，用于若监听到运行的应用程序存在异常，则获得应用程序对应的异常数据；
65.数据筛选模块a20，用于基于异常数据对应的异常类型对异常数据进行筛选处理，并存储筛选后的异常数据。
66.作为本技术的一种实现方式，上述数据获取模块a10包括：
67.异常提示单元：用于基于所述异常数据发送异常提示信息，所述异常提示信息用于提示用户发生异常。
68.作为本技术的一种实现方式，上述数据获取模块a10还包括：
69.数据获取单元，用于若监听到运行的应用程序即将发生崩溃或已经发生崩溃，则获得即将发生奔溃或已经发生崩溃的所述应用程序对应的异常数据。
70.作为本技术的一种实现方式，上述数据获取模块a20包括：
71.确定单元，用于根据预先设置的异常类型优先级确定所述异常数据对应的异常类型；
72.第一设置单元，用于若所述异常数据的异常类型为重要优先级，则将所述异常数据设置为重要异常数据，并存储所述重要异常数据；其中，所述重要异常数据为即将不可控的异常数据，所述重要优先级为与所述重要异常数据存在对应关系的异常类型。
73.作为本技术的一种实现方式，上述数据获取模块a20还包括：
74.第二设置单元，用于若所述异常数据的异常类型为一般优先级，则将所述异常数据设置为一般异常数据，并过滤所述一般异常数据；其中，所述一般异常数据为可控的异常数据，所述一般优先级为与所述一般异常数据存在对应关系的异常类型。
75.作为本技术的一种实现方式，上述数据获取模块a20还包括：
76.存储单元，用于将所述筛选后的异常数据存入设备或存储磁盘中的指定路径。
77.作为本技术的一种实现方式，上述数据获取模块a20还包括：
78.接收单元，用于若接收到异常数据导出请求；
79.校验单元，用于对所述导出请求进行身份校验，若所述身份校验通过，则导出所述筛选后的异常数据。
80.崩溃日志的监听装置用于执行时实现崩溃日志的监听方法。
81.本发明还提出一种崩溃日志的监听设备，崩溃日志的监听设备包括存储器、处理器以及存储在存储器上并可在处理器上运行的崩溃日志的监听程序，处理器执行崩溃日志的监听程序时实现本发明各个实施例的方法的步骤。
82.本发明还提出一种计算机可读存储介质，计算机可读存储介质上存储有崩溃日志的监听程序，奔溃日志的监听程序被处理器执行时实现上述的奔溃日志的监听方法的步骤。存储介质包括计算机可读存储介质，计算机可读存储介质可以是图1的中的存储器，也可以是如rom(read-only memory，只读存储器)/ram(random access memory，随机存取存储器)、磁碟、光盘中的至少一种，存储介质包括若干指令用以使得一台具有处理器的物联网终端设备(可以是手机，计算机，服务器，物联网终端，或者网络设备等)执行本发明各个实施例的方法。
83.在本发明中，术语“第一”“第二”“第三”“第四”“第五”仅用于描述的目的，而不能理解为指示或暗示相对重要性，对于本领域的普通技术人员而言，可以根据具体情况理解上述术语在本发明中的具体含义。
84.在本说明书的描述中，参考术语“一个实施例”、“一些实施例”、“示例”、“具体示例”、或“一些示例”等的描述意指结合该实施例或示例描述的具体特征、结构、材料或者特点包含于本发明的多个实施例或示例中。在本说明书中，对上述术语的示意性表述不必须针对的是相同的实施例或示例。而且，描述的具体特征、结构、材料或者特点可以在任一个或多个实施例或示例中以合适的方式结合。此外，在不相互矛盾的情况下，本领域的技术人员可以将本说明书中描述的不同实施例或示例以及不同实施例或示例的特征进行结合和组合。
85.尽管上面已经示出和描述了本发明的实施例，本发明保护的范围并不局限于此，可以理解的是，上述实施例是示例性的，不能理解为对本发明的限制，本领域的普通技术人员在本发明的范围内可以对上述实施例进行变化、修改和替换，这些变化、修改和替换都应涵盖在本发明的保护范围之内。因此，本发明的保护范围应以权利要求的保护范围为准。