应用崩溃操作日志的捕获方法、装置及移动终端与流程

本发明涉及互联网技术领域，尤其是涉及一种应用崩溃操作日志的捕获方法、装置及移动终端。

背景技术：

目前，智能终端中，用户安装的应用的数量越来越多，应用的来源也是各不相同，这些应用的稳定程度也不一样。对于很多android应用来说，不可避免的会发生崩溃(crash)。当crash发生时，android系统会杀掉程序，表现就是闪退或者程序已经停止运行，这对用户来说是不友好的，也是开发人员不愿意看到的。

开发人员对于crash信息的检测与重现很大程度上是依赖于用户的评论与反馈，收集crash发生时的堆栈信息和一些设备信息等崩溃报告信息。由于android应用的用户交互通常涉及手势或者传感器交互，这些步骤的重现通常和时序有紧密关系，仅仅依靠自然语言描述并不能够完整重现crash，因此获取的崩溃报告信息通常是不完整的，无法用于还原crash发生时的情景。

技术实现要素：

有鉴于此，本发明的目的在于提供一种应用崩溃操作日志的捕获方法、装置及移动终端，以捕获用于重现应用crash的操作日志，以便于还原crash发生时的情景，进而便于确定应用发生crash的原因以及修复应用crash。

第一方面，本发明实施例提供了一种应用崩溃操作日志的捕获方法，应用于移动终端，所述方法包括：

当应用启动时，获取目标文件夹，其中，所述目标文件夹为空文件夹；

捕获所述移动终端上的所有输入事件的事件流信息，并将捕获的所述事件流信息作为操作日志保存至所述目标文件夹；

当所述应用发生崩溃时，将当前保存的操作日志发送至监控服务器。

结合第一方面，本发明实施例提供了第一方面的第一种可能的实施方式，其中，当所述移动终端采用安卓android系统时，所述方法还包括：

当监测到所述android系统为所述应用创建application对象时，确定所述应用启动。

结合第一方面，本发明实施例提供了第一方面的第二种可能的实施方式，其中，所述当应用启动时，获取目标文件夹，包括：

当应用启动时，检测所述移动终端是否存在目标文件夹；

如果是，则清空所述目标文件夹；

如果否，则新建文件夹，并将新建的文件夹作为目标文件夹。

结合第一方面的第一种可能的实施方式，本发明实施例提供了第一方面的第三种可能的实施方式，其中，所述捕获所述移动终端上的所有输入事件的事件流信息，包括：

利用androidsdk的getevent工具，记录所述应用运行过程中所述移动终端上的所有输入事件的事件流信息。

结合第一方面的第一种可能的实施方式，本发明实施例提供了第一方面的第四种可能的实施方式，其中，所述方法还包括：

当监测到所述android系统执行thread类中的setdefaultuncaughtexceptionhandler时，确定所述应用发生崩溃。

结合第一方面，本发明实施例提供了第一方面的第五种可能的实施方式，其中，所述当所述应用发生崩溃时，将当前保存的操作日志发送至监控服务器，包括：

当所述应用发生崩溃时，从所述目标文件夹中调取当前保存的操作日志；

将所述操作日志发送至监控服务器。

结合第一方面的第五种可能的实施方式，本发明实施例提供了第一方面的第六种可能的实施方式，其中，所述将所述操作日志发送至监控服务器之前，所述方法还包括：

扫描所述操作日志内的事件流信息；

对所述事件流信息进行时间字段的标准化处理，得到标准化处理后的操作日志。

第二方面，本发明实施例还提供一种应用崩溃操作日志的捕获装置，应用于移动终端，所述装置包括：

第一获取模块，用于当应用启动时，获取目标文件夹，其中，所述目标文件夹为空文件夹；

第二获取模块，用于捕获所述移动终端上的所有输入事件的事件流信息，并将捕获的所述事件流信息作为操作日志保存至所述目标文件夹；

发送模块，用于当所述应用发生崩溃时，将当前保存的操作日志发送至监控服务器。

第三方面，本发明实施例还提供一种移动终端，包括存储器、处理器，所述存储器中存储有可在所述处理器上运行的计算机程序，所述处理器执行所述计算机程序时实现上述第一方面所述的方法的步骤。

第四方面，本发明实施例还提供一种具有处理器可执行的非易失的程序代码的计算机可读介质，所述程序代码使所述处理器执行上述第一方面所述方法。

本发明实施例带来了以下有益效果：

本发明实施例中，当应用启动时，获取目标文件夹，其中，该目标文件夹为空文件夹；捕获移动终端上的所有输入事件的事件流信息，并将捕获的事件流信息作为操作日志保存至目标文件夹；当该应用发生崩溃时，将当前保存的操作日志发送至监控服务器。由于以底层事件流信息的形式记录了移动终端上的所有输入事件，并且包含可以精确到微秒的时序关系，即事件流信息可以完整体现用户交互涉及的手势交互以及传感器交互的具体过程，因此包含事件流信息的操作日志可以用于完整重现crash发生时的情景。因此，本发明提供的应用崩溃操作日志的捕获方法、装置及移动终端，当应用发生crash时，可以捕获用于重现该应用crash的操作日志，以便于还原crash发生时的情景，进而便于确定应用发生crash的原因以及修复应用crash。

本发明的其他特征和优点将在随后的说明书中阐述，并且，部分地从说明书中变得显而易见，或者通过实施本发明而了解。本发明的目的和其他优点在说明书、权利要求书以及附图中所特别指出的结构来实现和获得。

为使本发明的上述目的、特征和优点能更明显易懂，下文特举较佳实施例，并配合所附附图，作详细说明如下。

附图说明

为了更清楚地说明本发明具体实施方式或现有技术中的技术方案，下面将对具体实施方式或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图是本发明的一些实施方式，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1为本发明实施例提供的应用崩溃操作日志的捕获方法的第一种流程示意图；

图2为本发明实施例提供的应用崩溃操作日志的捕获方法的第二种流程示意图；

图3为本发明实施例提供的应用崩溃操作日志的捕获装置的模块组成示意图；

图4为本发明实施例提供的移动终端的结构示意图。

具体实施方式

为使本发明实施例的目的、技术方案和优点更加清楚，下面将结合附图对本发明的技术方案进行清楚、完整地描述，显然，所描述的实施例是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。

目前开发人员对于crash信息的检测与重现很大程度上是依赖于用户的评论与反馈，收集crash发生时的堆栈信息和一些设备信息等崩溃报告信息，然而获取的崩溃报告信息通常是不完整的，无法用于还原crash发生时的情景。基于此，本发明实施例提供的一种应用崩溃操作日志的捕获方法、装置及移动终端，可以捕获用于重现应用crash的操作日志，以便于还原crash发生时的情景，进而便于确定应用发生crash的原因以及修复应用crash。

为便于对本实施例进行理解，首先对本发明实施例所公开的一种应用崩溃操作日志的捕获方法进行详细介绍。

实施例一：

本发明实施例提供的应用崩溃操作日志的捕获方法应用于移动终端，该移动终端可以是手机、平板电脑、pda(personaldigitalassistant，个人数字助理)、车载电脑等任意可以下载并使用应用的设备。

图1为本发明实施例提供的应用崩溃操作日志的捕获方法的第一种流程示意图，如图1所示，以移动终端为手机，且采用安卓android系统为例，该方法包括以下几个步骤：

步骤s101，当应用启动时，获取目标文件夹，其中，该目标文件夹为空文件夹。

实时监测待监控的应用是否在用户的手机上启动。在一个可能的实施例中，当监测到手机的android系统为该应用创建application对象时，确定该应用启动。具体地，在手机的android系统中，application对象的生命周期是整个程序中最长的，它的生命周期等于整个应用的生命周期；application和activity、service一样，是android框架的一个系统组件，当应用启动时系统会为该应用创建一个application对象，用来存储系统的一些信息。因此，当监测到手机的android系统为应用创建application对象时，就可以确定该应用启动。

每当该应用启动时，检测该手机内是否存在目标文件夹；如果是，则清空该目标文件夹；如果否，则新建文件夹，并将新建的文件夹作为目标文件夹。该目标文件夹是用于存放后续采集的事件流信息对应的操作日志，以便当该应用崩溃时，可以只将本次崩溃涉及到的操作日志发送给监控服务器。

步骤s102，捕获手机上的所有输入事件的事件流信息，并将捕获的事件流信息作为操作日志保存至上述目标文件夹。

获取到目标文件夹后，在用户使用上述应用的过程中，利用androidsdk(softwaredevelopmentkit，软件开发工具包)的getevent工具，通过读取/dev/input/event*文件，实时记录应用运行过程中手机上的所有输入事件的事件流信息，并将捕获的事件流信息作为操作日志保存至上述目标文件夹。该事件流信息为时间序列化的底层事件流信息，包括手机上所有应用的操作事件流信息，不仅记录了用户通过手机触摸屏产生的输入事件，还记录了所有来自于手机内传感器触发的事件。由于事件流信息记录了移动终端上的所有输入事件，并且包含可以精确到微秒的时序关系，即事件流信息可以完整体现用户交互涉及的手势交互以及传感器交互的具体过程，因此包含事件流信息的操作日志可以用于完整重现crash发生时的情景。

具体地，android系统自带了getevent工具，在使用getevent工具得到事件流信息过程中，应用程序的性能不受影响。该事件流信息为五元组格式，依次包括时间字段、输入设备字段、输入设备类型字段、按键扫描码字段和附加码字段。例如：[100.119269]/dev/input/event4:00020004000000ef表示一条事件五元组编码(即事件流信息)，其中：[100.119269]为时间字段，表示该事件距离手机系统(android系统)最近一次启动的时间间隔为100.119269秒；/dev/input/event4:为输入设备字段，表示输入设备为event4；00020004000000ef分别为输入设备类型字段、按键扫描码字段、附加码字段，分别指事件的type(输入设备类型)、code(按键扫描码)、value(附加码)。

android其它复杂的事件都是由上述事件流格式组合而成。触摸屏手势编码如下：

[100.119269]/dev/input/event0:00030039000002a5表示一次touch的开始；

[100.119278]/dev/input/event0:0003003000000004表示点击开始；

[100.119286]/dev/input/event0:000300350000017b表示触摸点x坐标；

[100.119295]/dev/input/event0:00030036000001cf表示触摸点y坐标；

[100.119363]/dev/input/event0:0003003a0000001c表示触摸点大小；

[100.119562]/dev/input/event0:0000000000000000表示事件同步(点击结束)；

[100.119967]/dev/input/event0:00030039ffffffff表示一次touch结束；

[100.119269]/dev/input/event0:0000000000000000表示事件同步(事件结束)。

步骤s103，当上述应用发生崩溃时，将当前保存的操作日志发送至监控服务器。

实时监测上述应用是否发生崩溃。在一个可能的实施例中，当监测到手机的android系统执行thread类中的setdefaultuncaughtexceptionhandler(uncaughtexceptionhandlerhandler)时，确定该应用发生崩溃。当应用崩溃后，通过执行本发明设计的实现uncaughtexceptionhandler接口的类代码，完成崩溃后操作日志的调取及上传等操作。

当上述应用发生崩溃时，从上述目标文件夹中调取当前保存的操作日志，并将该操作日志发送至监控服务器。具体地，当应用发生crash的时候，在应用进程结束之前对目标文件夹进行扫描，查找最近上传的操作日志文件，并获取该操作日志文件的名称与路径，最后进行操作日志的上传。操作日志的上传具体为：服务端(监控服务器)使用tomcat+servlet，客户端(手机等移动终端)使用okhttp，其中，okhttp为处理网络请求的开源项目。

另外，当上述应用发生崩溃时，还可以收集设备信息和堆栈信息，并将该设备信息和堆栈信息保存为设备文件和堆栈文件，与操作日志同时上传至监控服务器。其中，设备信息包括应用运行的操作系统及版本(如android4.0)、网络环境(4g环境或者wi-fi(wireless-fidelity，无线保真)环境)、内存信息等；堆栈信息主要包括错误代码行的位置和函数的调用栈。收集的设备信息和堆栈信息便于后续更好地还原应用的运行环境，更好地重现应用crash。

本发明实施例中，当应用启动时，获取目标文件夹，其中，该目标文件夹为空文件夹；捕获移动终端上的所有输入事件的事件流信息，并将捕获的事件流信息作为操作日志保存至目标文件夹；当该应用发生崩溃时，将当前保存的操作日志发送至监控服务器。由于以底层事件流信息的形式记录了移动终端上的所有输入事件，并且包含可以精确到微秒的时序关系，即事件流信息可以完整体现用户交互涉及的手势交互以及传感器交互的具体过程，因此包含事件流信息的操作日志可以用于完整重现crash发生时的情景。因此，本发明提供的应用崩溃操作日志的捕获方法，当应用发生crash时，可以捕获用于重现该应用crash的操作日志，以便于还原crash发生时的情景，进而便于确定应用发生crash的原因以及修复应用crash。

进一步地，由于不同厂商的原因，android手机采集到的事件流有所差别，不同手机型号的事件流格式表示不一致，如某品牌手机a的事件流格式为：

[17928.197972]/dev/input/event4:0002000900000799

某品牌手机b的事件流格式为：

[1492524733.054756]/dev/input/event2:0002000100000001

某品牌手机a的事件流信息中的时间字段记录的是当前时刻距离手机系统最近一次启动的时间间隔，而某品牌手机b对应的时间字段记录的是时间戳，即从格林威治时间1970年01月01日00时00分00秒(北京时间1970年01月01日08时00分00秒)起至当前时刻的总秒数。另外，在时间字段中，有的采用短横线，有的采用小数点；有的采用中括号，有的采用大括号(花括号)等。

考虑到不同android机型对应的事件流格式表示不统一，且主要是时间字段的不统一，会影响后续的crash重现，在将上述操作日志发送至监控服务器之前，上述方法还包括：

扫描操作日志内的事件流信息，对该事件流信息以统一的五元组格式表示：时间字段、输入设备字段、输入设备类型字段、按键扫描码字段和附加码字段。

具体地，对操作日志进行扫描，对于扫描到的每条事件流信息，利用字符串替换的方法，将该事件流信息的时间字段中的括号替换为空格，并将时间字段中的短横线替换为小数点；再将替换后的时间字段中的空格切割掉，即可得到标准化处理后的事件流信息，标准化处理后的事件流信息形成了标准化处理后的操作日志。其中，括号包括在时间字段中可能出现的各种类型的括号，例如大括号、中括号等。例如：对于“[99.578741]”，经括号替换后变为“99.578741”，再对空格进行切割后变为“99.578741”；对于“40-764251/dev/input/event4:000300300000001e”这种格式的事件流信息，将“-”替换为“.”后，其时间字段变为“40.764251”。最终将所有的时间字段变为统一的格式，例如“99.578741/dev/input/event4:000300300000001e”。

这样，通过对事件流格式的标准化处理，可以得到统一的事件流五元组格式，解决了不同android设备事件流格式不一致的问题，为自动化重现应用crash提供了可能。

图2为本发明实施例提供的应用崩溃操作日志的捕获方法的第二种流程示意图，如图2所示，该方法的第二种流程包括以下几个步骤：

步骤s201，当应用启动时，判断是否存在目标文件夹。如果是，则执行步骤s2021；如果否，则执行步骤s2022。

步骤s2021，清空目标文件夹。

步骤s2022，新建文件夹，并将新建的文件夹作为目标文件夹。

步骤s203，捕获事件流信息，并将该事件流信息作为操作日志保存至上述目标文件夹。

步骤s204，判断上述应用是否发生crash。如果是，则执行步骤s2051；如果否，则执行步骤s2052。

步骤s2051，将当前保存的操作日志发送至监控服务器。执行过程结束。

步骤s2052，判断上述应用是否退出。如果否，则重新执行步骤s203；如果是，则执行过程结束。

综上可知，本发明实施例提供的应用崩溃操作日志的捕获方法，可以捕获事件流信息，且应用程序的性能在捕获事件流信息的过程中不受影响，还可以收集设备信息和堆栈信息，为后续crash的重现和定位提供了技术支持。

实施例二：

图3为本发明实施例提供的应用崩溃操作日志的捕获装置的模块组成示意图，该装置应用于移动终端，如图3所示，该装置包括：

第一获取模块31，用于当应用启动时，获取目标文件夹，其中，该目标文件夹为空文件夹；

第二获取模块32，用于捕获移动终端上的所有输入事件的事件流信息，并将捕获的事件流信息作为操作日志保存至上述目标文件夹；

发送模块33，用于当上述应用发生崩溃时，将当前保存的操作日志发送至监控服务器。

本发明实施例中，当应用启动时，获取目标文件夹，其中，该目标文件夹为空文件夹；捕获移动终端上的所有输入事件的事件流信息，并将捕获的事件流信息作为操作日志保存至目标文件夹；当该应用发生崩溃时，将当前保存的操作日志发送至监控服务器。由于以底层事件流信息的形式记录了移动终端上的所有输入事件，并且包含可以精确到微秒的时序关系，即事件流信息可以完整体现用户交互涉及的手势交互以及传感器交互的具体过程，因此包含事件流信息的操作日志可以用于完整重现crash发生时的情景。因此，本发明提供的应用崩溃操作日志的捕获装置，当应用发生crash时，可以捕获用于重现该应用crash的操作日志，以便于还原crash发生时的情景，进而便于确定应用发生crash的原因以及修复应用crash。

实施例三：

参见图4，本发明实施例还提供一种移动终端100，包括：处理器40，存储器41，总线42和通信接口43，所述处理器40、通信接口43和存储器41通过总线42连接；处理器40用于执行存储器41中存储的可执行模块，例如计算机程序。

其中，存储器41可能包含高速随机存取存储器(ram，randomaccessmemory)，也可能还包括非不稳定的存储器(non-volatilememory)，例如至少一个磁盘存储器。通过至少一个通信接口43(可以是有线或者无线)实现该系统网元与至少一个其他网元之间的通信连接，可以使用互联网，广域网，本地网，城域网等。

总线42可以是isa总线、pci总线或eisa总线等。所述总线可以分为地址总线、数据总线、控制总线等。为便于表示，图4中仅用一个双向箭头表示，但并不表示仅有一根总线或一种类型的总线。

其中，存储器41用于存储程序，所述处理器40在接收到执行指令后，执行所述程序，前述本发明实施例任一实施例揭示的流过程定义的装置所执行的方法可以应用于处理器40中，或者由处理器40实现。

处理器40可能是一种集成电路芯片，具有信号的处理能力。在实现过程中，上述方法的各步骤可以通过处理器40中的硬件的集成逻辑电路或者软件形式的指令完成。上述的处理器40可以是通用处理器，包括中央处理器(centralprocessingunit，简称cpu)、网络处理器(networkprocessor，简称np)等；还可以是数字信号处理器(digitalsignalprocessing，简称dsp)、专用集成电路(applicationspecificintegratedcircuit，简称asic)、现成可编程门阵列(field-programmablegatearray，简称fpga)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件。可以实现或者执行本发明实施例中的公开的各方法、步骤及逻辑框图。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。结合本发明实施例所公开的方法的步骤可以直接体现为硬件译码处理器执行完成，或者用译码处理器中的硬件及软件模块组合执行完成。软件模块可以位于随机存储器，闪存、只读存储器，可编程只读存储器或者电可擦写可编程存储器、寄存器等本领域成熟的存储介质中。该存储介质位于存储器41，处理器40读取存储器41中的信息，结合其硬件完成上述方法的步骤。

所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，上述描述的装置及移动终端的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。

本发明实施例提供的应用崩溃操作日志的捕获装置及移动终端，与上述实施例提供的应用崩溃操作日志的捕获方法具有相同的技术特征，所以也能解决相同的技术问题，达到相同的技术效果。

附图中的流程图和框图显示了根据本发明的多个实施例的装置、方法和计算机程序产品的可能实现的体系架构、功能和操作。在这点上，流程图或框图中的每个方框可以代表一个模块、程序段或代码的一部分，所述模块、程序段或代码的一部分包含一个或多个用于实现规定的逻辑功能的可执行指令。也应当注意，在有些作为替换的实现中，方框中所标注的功能也可以以不同于附图中所标注的顺序发生。例如，两个连续的方框实际上可以基本并行地执行，它们有时也可以按相反的顺序执行，这依所涉及的功能而定。也要注意的是，框图和/或流程图中的每个方框、以及框图和/或流程图中的方框的组合，可以用执行规定的功能或动作的专用的基于硬件的系统来实现，或者可以用专用硬件与计算机指令的组合来实现。

本发明实施例所提供的进行应用崩溃操作日志的捕获方法的计算机程序产品，包括存储了处理器可执行的非易失的程序代码的计算机可读存储介质，所述程序代码包括的指令可用于执行前面方法实施例中所述的方法，具体实现可参见方法实施例，在此不再赘述。

在本申请所提供的几个实施例中，应该理解到，所揭露的方法、装置及移动终端，可以通过其它的方式实现。以上所描述的装置实施例仅仅是示意性的，例如，所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，又例如，多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些通信接口，装置或单元的间接耦合或通信连接，可以是电性，机械或其它的形式。

所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。

另外，在本发明各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。

所述功能如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个处理器可执行的非易失的计算机可读取存储介质中。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本发明各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：u盘、移动硬盘、只读存储器(rom，read-onlymemory)、随机存取存储器(ram，randomaccessmemory)、磁碟或者光盘等各种可以存储程序代码的介质。

最后应说明的是：以上所述实施例，仅为本发明的具体实施方式，用以说明本发明的技术方案，而非对其限制，本发明的保护范围并不局限于此，尽管参照前述实施例对本发明进行了详细的说明，本领域的普通技术人员应当理解：任何熟悉本技术领域的技术人员在本发明揭露的技术范围内，其依然可以对前述实施例所记载的技术方案进行修改或可轻易想到变化，或者对其中部分技术特征进行等同替换；而这些修改、变化或者替换，并不使相应技术方案的本质脱离本发明实施例技术方案的精神和范围，都应涵盖在本发明的保护范围之内。因此，本发明的保护范围应所述以权利要求的保护范围为准。