CN109324946A - 运行监测方法、装置、电子设备及计算机可读存储介质 - Google Patents

Abstract

本申请提出一种运行监测方法、装置、电子设备以及计算机可读存储介质，其中，方法包括：通过调用第一线程执行目标事件，在执行目标事件过程中，监测执行时长以及获取在执行目标事件过程中占用运行资源的各第二线程的运行信息，若监测到第一线程的执行时长大于阈值时长，确定第一线程存在运行异常，最终将第一线程获取到的各第二线程的运行信息存储至目标存储位置。由此，当监测到第一线程执行目标事件的时长出现异常时，根据各第二线程的运行信息，确定造成第一线程运行异常的原因，进而可以精准定位到造成应用程序出现卡顿的线程，简化了程序开发人员优化修改程序的工作量。

Description

运行监测方法、装置、电子设备及计算机可读存储介质

技术领域

本申请涉及电子设备技术领域，尤其涉及一种运行监测方法、装置、电子设备以及计算机可读存储介质。

背景技术

随着移动互联网的普及，移动终端得到了用户的广泛使用，越来越多的应用程序(Application，APP)成为移动终端的重要组成部分。用户对于移动终端的质量要求越来越高，下载的APP也越来越复杂，但是，由于APP代码设计问题或硬件性能问题导致用户操作不流畅，交互掉帧等，出现卡顿现象。因此，移动终端中应用程序运行的流畅度已经成为衡量用户体验的一项重要的指标。

现有技术中，通过对主线程进行监测，对运行时间较长的事件相关信息进行存储，以用于分析卡顿原因。但这种方式，监测信息量有限，导致后期分析出的卡顿原因不准确。

发明内容

本申请旨在至少在一定程度上解决相关技术中的技术问题之一。

为此，本申请提出一种运行监测方法，以实现当应用程序运行过程中出现卡顿时，能够精确定位到卡顿的线程。

本申请实施例提出一种运行监测装置。

本申请实施例提出一种电子设备。

本申请实施例提出一种计算机可读存储介质。

本申请一方面实施例提出了一种运行监测方法，包括：

调用第一线程执行目标事件；

在执行所述目标事件过程中，监测执行时长以及获取在执行所述目标事件过程中占用运行资源的各第二线程的运行信息；

若监测到所述第一线程的执行时长大于阈值时长，确定所述第一线程存在运行异常；

将获取到的各第二线程的运行信息存储至目标存储位置。

本申请又一方面实施例提出了一种运行监测装置，包括：

调用模块，用于调用第一线程执行目标事件；

监测模块，用于在执行所述目标事件过程中，监测执行时长以及获取在执行所述目标事件过程中占用运行资源的各第二线程的运行信息；

确定模块，用于若监测到所述第一线程的执行时长大于阈值时长，确定所述第一线程存在运行异常；

存储模块，用于将获取到的各第二线程的运行信息存储至目标存储位置。

本申请又一方面实施例提出了一种电子设备，其特征在于，包括至少一个处理器；以及，与所述至少一个处理器通信连接的存储器；其中，所述存储器存储有可被所述至少一个处理器执行的指令，所述指令被设置为用于执行上述实施例中所述的运行监测方法。

本申请又一方面实施例提出了一种计算机可读存储介质，其特征在于，所述计算机可读存储介质存储有计算机可读指令，所述计算机可读指令用于使计算机执行上述实施例所述的运行监测方法。

本申请实施例提供的技术方案可以包含如下的有益效果：

调用第一线程执行目标事件；其中，第一线程用于执行目标事件，在执行目标事件过程中，监测执行时长以及获取在执行目标事件过程中占用运行资源的各第二线程的运行信息，若监测到第一线程的执行时长大于阈值时长，确定第一线程存在运行异常，最终将第一线程获取到的各第二线程的运行信息存储至目标存储位置。由此，当监测到第一线程执行目标事件的时长出现异常时，根据各第二线程的运行信息，确定造成第一线程运行异常的原因，进而可以精准定位到造成应用程序出现卡顿的线程，简化了程序开发人员优化修改程序的工作量。

附图说明

本申请上述的和/或附加的方面和优点从下面结合附图对实施例的描述中将变得明显和容易理解，其中：

图1为本申请实施例所提供的相关技术中运行监测方法的原理图；

图2为本申请实施例所提供的一种运行监测方法的流程示意图；

图3为本申请实施例所提供的一种Android***为例的运行监测方法的流程示意图；

图4为本申请实施例所提供的一种Android***为例的运行监测方法的原理图；

图5为本申请实施例所提供的一种运行监测装置的结构示意图；

图6为本申请实施例所提供的另一种运行监测装置的结构示意图；

图7是图示根据本申请的实施例的电子设备的硬件结构示意图；以及

图8是图示根据本申请实施例的计算机可读存储介质的示意图。

具体实施方式

下面详细描述本申请的实施例，所述实施例的示例在附图中示出，其中自始至终相同或类似的标号表示相同或类似的元件或具有相同或类似功能的元件。下面通过参考附图描述的实施例是示例性的，旨在用于解释本申请，而不能理解为对本申请的限制。

由于APP在运行过程中可能会出现卡顿的现象，为了解决卡顿问题，开发者和运营人员需要首先找到卡顿的原因，即精确定位到卡顿是由什么原因造成的。

相关技术中，造成卡顿的原因主要可能是主线程执行操作时占用CPU时间过长，或者是从线程抢占了CPU资源，导致主线程无法获取足够的CPU资源在预定时间内执行完原本完成的任务。但是，现有的开发者和运营人员无法精确定位到从线程主线程CPU的时间导致卡顿的原因，反而认为所有的卡顿原因都是因为主线程占用CPU时间过长造成的。

作为一种示例，当移动设备***为Android时，Android平台的人机交互采用的是事件循环方案，即主线程循环进行事件处理，从而达到持续交互的目的。主线程循环进行事件处理的过程，是由Looper类来实际执行的。其中，Looper类是Android平台事件循环处理的核心类。

执行过程参见图1，具体定位卡顿原因的执行步骤如下：App启动时，通过调用Looper的setMessageLogging()方法设置Printer对象，其中，Printer对象用于输出内容到标准输出，进而，开发人员用自己实现的Printer对象覆盖***默认的Printer对象，并且在自己实现的Printer对象中加入执行时间计算的功能。每次事件处理前后，Android***都会调用开发人员设置的Printer对象的print()方法，用于监控每个事件处理所花费的时间。同时，在App启动时开启另一个线程B，定期循环获取Looper类所在线程(即主线程)的调用栈信息。当监控到某个事件C执行时间过长时，查询线程B在处理C事件时的调用栈信息。根据调用栈信息来定位是哪个方法执行时间过长，从而定位卡顿原因。其中，调用栈信息，是指CPU会按照栈(后进先出的数据结构)的方式来执行一段程序，这个栈的快照，称为调用栈信息。

上述示例中主线程循环进行事件处理的过程中，其他线程执行的程序可能会占用CPU时间过长，使得主线程占用CPU时间缩短，导致主线程无法获取足够的CPU资源来执行程序。例如，主线程原本只需要1s执行的程序，由于其他线程抢占CPU资源，占有过多的CPU时间，导致主线程需要花费10s来完成，导致卡顿现象。由于相关技术中只采集了Looper类所在主线程的堆栈信息，因此误以为主线程导致APP卡顿，其实由于其他线程中执行的程序抢占主线程CPU时间才是卡顿的真正原因。因此，该方案无法精确定位到造成卡顿的线程，导致开发人员不能彻底解决造成APP卡顿的问题。

本申请实施例针对上述现有技术中，无法精准定位到造成APP卡顿的具体线程，导致不能针对性的优化APP的代码设计的技术问题，提出了一种运行监测方法，通过调用第一线程执行目标事件；其中，第一线程用于执行目标事件，并在执行目标事件过程中，监测执行时长以及获取在执行目标事件过程中占用运行资源的各第二线程的运行信息，若第一线程监测到的执行时长大于阈值时长，确定第一线程存在运行异常，最终将第一线程获取到的各第二线程的运行信息存储至目标存储位置。

下面参考附图描述本申请实施例的运行监测方法和装置。

图2为本申请实施例所提供的一种运行监测方法的流程示意图。

本申请实施例中，电子设备可以为手机、平板电脑、个人数字助理、穿戴式设备等具有各种操作***、应用程序的硬件设备。

如图2所示，该运行监测方法，具体可以由运行在该电子设备上的线程执行，具体可以为独立于本实施例中提及的第一线程的监视线程执行，具体监测方法包括以下步骤：

步骤101，调用第一线程执行目标事件。

其中，第一线程用于执行目标事件。本实施例中，第一线程为主线程，主线程为一个进程启动时自动创建的，如UI界面和main函数均为主线程。其中，第一线程用于执行目标事件。

步骤102，在执行目标事件过程中，监测执行时长以及获取在执行目标事件过程中占用运行资源的各第二线程的运行信息。

其中，第二线程包括主线程、用于监测第一线程执行时长的子线程以及其他子线程。

需要说明的是，应用程序的第一线程和各第二线程执行的过程中都会占用CPU的运行资源，因此，第二线程中子线程执行的时间过长时，会抢占主线程的CPU运行资源，导致主线程无法在预设时间内执行，从而导致应用程序出现卡顿的现象。

具体地，当电子设备中待监测的应用程序启动时，处理器调用第一线程循环执行目标事件，并且在第一线程执行目标事件的过程中，通过第二线程监测第一线程执行目标事件的时长以及获取在执行目标事件过程中占用CPU运行资源的各第二线程的运行信息。其中，第二进程的运行信息包括主线程和各子线程执行的时长以及方法的调用。

步骤103，若监测到第一线程的执行时长大于阈值时长，确定第一线程存在运行异常。

其中，阈值时长，可以是预先设置的用于判断线程运行是否存在异常的执行时长。当监测到第一线程的执行目标事件的时长大于该阈值时长，则说明第一线程存在运行异常的情况；当监测到第一线程的执行目标事件的时长小于或等于该阈值时长，则说明第一线程运行正常。

本实施例中，在步骤102中，第二线程监测到的应用程序的第一线程执行目标事件的时长大于预设的阈值时长，因此，可以确定第一线程运行异常。

步骤104，将获取到的各第二线程的运行信息存储至目标存储位置。

其中，运行信息包括各第二线程执行事件的时长以及调用的方法。

具体地，确定第一线程运行异常后，第一线程已通过调用相关接口获取到的各第二线程的运行信息并生成临时文件，将该文件存储至目标存储位置。其中，目标存储位置为预设的用于存储线程运行异常时存储卡顿记录文件的目录。进而，在应用程序出现卡顿的情况下，可以查看存储目录下存储的卡顿记录文件并进行分析，进而找到卡顿的原因。

进一步地，在获取到各第二线程的运行信息后，根据各第二线程的运行信息，确定各第二线程的方法调用耗时和/或调用的方法，进而，根据各第二线程的方法调用耗时和/或调用的方法，确定第一线程运行异常的原因。

作为一种可能的实现方式，根据各第二线程的运行信息，确定各第二线程中子线程的调用耗时和/或调用的方法均正常，此时，可能为第一线程的主程序在执行任务的过程中运行时间过长，造成应用程序出现卡顿现象。

作为另一种可能的实现方式，根据各第二线程的运行信息，确定各第二线程中子线程运行程序时耗时超过阈值时长，或者子线程的调用方法存在异常，或者子线程运行程序时耗时超过阈值时长的同时子线程的调用方法也存在异常，由于子线程卡顿导致长时间占用CPU运行资源，使得主线程无法获取足够的CPU资源来执行程序，因此，无法在预定时间内正常执行完程序，使得第一线程运行异常，从而造成应用程序出现卡顿现象。

本实施例中的运行监测方法，通过调用第一线程执行目标事件；其中，第一线程用于执行目标事件，在执行目标事件过程中，监测执行时长以及获取在执行目标事件过程中占用运行资源的各第二线程的运行信息，若监测到第一线程的执行时长大于阈值时长，确定第一线程存在运行异常，最终将获取到的各第二线程的运行信息存储至目标存储位置。由此，通过监测第一线程执行目标事件的时长以及获取各第二线程的运行信息，进而，根据各第二线程的运行信息，确定造成第一线程运行异常的原因，解决了现有技术中由于子线程竞争运行资源导致主线程无法正常运行使得应用程序出现卡顿时，误认为是主线程的原因导致卡顿现象的技术问题。

为了清楚说明前述过程，参见图3，在图2所述实施例的基础上，本申请实施例以Android***为例，对运行监测方法进行详细说明。

如图3所示，该运行监测方法包括以下步骤：

步骤201，控制第一线程调用用于循环执行的类，以循环执行目标事件。

本实施例中，第一线程为主线程，因此，在监测到应用程序启动之后，电子设备的处理器首先控制第一线程调用用于循环执行的类，以循环执行目标事件。

作为一种示例，参见图4，当电子设备配置的***为Android***时，电子设备中的应用程序启动时，控制第一线程调用用于循环执行的类，即Looper，是Android***事件循环处理的核心类，以循环执行目标事件。

步骤202，每一次执行目标事件之前，控制第一线程通过调用预设输出对象开始计时，以及开始调用CPU调度接口以获取临时文件，临时文件用于指示各第二线程的运行信息。

其中，临时文件中记录了各第二线程的运行信息，即各线程的耗时时长和/或调用方法，用于分析应用程序卡顿的原因。

仍以上述示例为例，在应用程序启动时，通过调用Looper的setMessageLogging()方法设置Printer对象。采用新的的Printer对象覆盖***默认的Printer对象。其中新的Printer对象中加入了执行计时的功能，同时，新的Printer对象的print()方法中加入对TraceView的调用。Traceview是Android***的CPU调度分析工具，能够用于记录分析CPU占用情况，并以图形化的方式展示。

新的Printer对象通过对Debug.startMethodTraceSampling(filePath)函数的调用，启动TraceView功能，并生成临时文件，若该临时文件已经存在，则将已存在的临时文件重置为空文件，或者，对其进行覆盖存储。

步骤203，每一次执行目标事件之后，控制第一线程通过调用输出对象结束计时，以及结束调用CPU调度接口。

仍以上述示例为例，每一次执行目标事件后，电子设备的处理器都会触发Printer对象的print()方法，确定本次执行目标事件所耗时长，触发Printer对象通过对Debug.stopMethodTrace()函数的调用，停止TraceView功能，以结束调用CPU调用接口。

步骤204，若监测到第一线程的执行时长大于阈值时长，确定第一线程存在运行异常，并将获取到的各第二线程的运行信息存储至目标存储位置。

本申请实施例中，判断第一线程存在运行异常，以及第一线程获取到的各第二线程的运行信息存储至目标存储位置的方法，如上述实施例中步骤103和步骤104所述，在此不再赘述。

仍以上述示例为例，如果监测到某个事件执行时间大于阈值时长，可确定该事件运行存在异常，进而，将监测到存在异常事件的运行信息即Debug.startMethodTraceSampling(filePath)和Debug.stopMethodTrace()生成的临时TraceView文件，转移到一个Android设备的目标存储位置中，作为一条卡顿记录文件。例如图4中，在目标存储位置存储的卡顿记录1以及卡顿记录2。当研发人员查看造成应用程序卡顿原因时，从Android设备的目标存储位置获取卡顿记录文件，并将该记录文件转移到PC上进行详细分析。

本申请实施例的运行监测方法，通过控制第一线程调用用于循环执行的类，以循环执行目标事件，每一次执行目标事件之前，控制第一线程通过调用预设输出对象开始计时，以及开始调用CPU调度接口以获取临时文件，临时文件用于指示各第二线程的运行信息，每一次执行目标事件之后，控制第一线程通过调用输出对象结束计时，以及结束调用CPU调度接口，若监测到第一线程的执行时长大于阈值时长，确定第一线程存在运行异常，并将第一线程获取到的各第二线程的运行信息存储至目标存储位置。由于TraceView文件包含了所有线程的所有方法调用耗时，因此可以精确定位到造成了应用程序出现卡顿现象的具体线程或方法，简化了程序开发人员优化修改程序的工作量。

为了实现上述实施例，本申请实施例还提出一种运行监测装置。

图5为本申请实施例提供的一种运行监测装置的结构示意图。

如图5所示，该运行监测装置包括：调用模块51、监测模块52、确定模块53以及存储模块54。

调用模块51，用于调用第一线程执行目标事件。

监测模块52，用于在执行目标事件过程中，监测执行时长以及获取在执行目标事件过程中占用运行资源的各第二线程的运行信息。

确定模块53，用于若监测到第一线程的执行时长大于阈值时长，确定第一线程存在运行异常。

存储模块54，用于将获取到的各第二线程的运行信息存储至目标存储位置。

需要说明的是，前述对运行监测方法实施例的解释说明也适用于该实施例的运行监测装置，此处不再赘述。

本实施例中的运行监测装置，通过调用第一线程执行目标事件；其中，第一线程用于执行目标事件，在执行目标事件过程中，监测执行时长以及获取在执行目标事件过程中占用运行资源的各第二线程的运行信息，若监测到第一线程的执行时长大于阈值时长，确定第一线程存在运行异常，最终将第一线程获取到的各第二线程的运行信息存储至目标存储位置。由此，通过监测第一线程执行目标事件的时长以及获取各第二线程的运行信息，进而，根据各第二线程的运行信息，确定造成第一线程运行异常的原因，解决了现有技术中由于子线程竞争运行资源导致主线程无法正常运行使得应用程序出现卡顿时，误认为是主线程的原因导致卡顿现象的技术问题。

基于上述实施例，本发明实施例还提供了一种运行监测装置的可能的实现方式，图6为本发明实施例所提供的另一种运行监测装置的结构示意图，在上一实施例的基础上，如图6所示，该装置还包括：第一确定模块55和第二确定模块55。

第一确定模块55，用于根据各第二线程的运行信息，确定各第二线程的方法调用耗时和/或调用的方法。

第二确定模块56，用于根据各第二线程的方法调用耗时和/或调用的方法，确定异常原因。

作为一种可能的实现方式，上述调用模块51，具体还可以用于在待监测的应用程序启动时，调用第一线程循环执行目标事件。

作为另一种可能的实现方式，上述调用模块51，具体还可以用于控制第一线程调用用于循环执行的类，以循环执行目标事件；

每一次执行目标事件之前，控制第一线程通过调用预设输出对象开始计时，以及开始调用CPU调度接口以获取临时文件，临时文件用于指示各第二线程的运行信息；

每一次执行目标事件之后，控制第一线程通过调用输出对象结束计时，以及结束调用CPU调度接口。

作为另一种可能的实现方式，调用模块51，还包括：

调用单元，用于当待监测的应用程序启动之后，调用用于循环执行的类设置输出对象；其中输出对象，用于计时以及调用CPU调度接口。

作为另一种可能的实现方式，存储模块54，具体还可以用于将第一线程获取到的临时文件存储至目标存储位置。

需要说明的是，前述对运行监测方法实施例的解释说明也适用于该实施例的运行监测装置，此处不再赘述。

本实施例中的运行监测装置，通过调用第一线程执行目标事件；其中，第一线程用于执行目标事件，在执行目标事件过程中，监测执行时长以及获取在执行目标事件过程中占用运行资源的各第二线程的运行信息，若监测到第一线程的执行时长大于阈值时长，确定第一线程存在运行异常，最终将第一线程获取到的各第二线程的运行信息存储至目标存储位置。由此，通过监测第一线程执行目标事件的时长以及获取各第二线程的运行信息，进而，根据各第二线程的运行信息，确定造成第一线程运行异常的原因，解决了现有技术中由于子线程竞争运行资源导致主线程无法正常运行使得应用程序出现卡顿时，误认为是主线程的原因导致卡顿现象的技术问题。

为了实现上述实施例，本申请实施例还提出一种电子设备，该电子设备包括至少一个处理器；以及，与所述至少一个处理器通信连接的存储器；其中，所述存储器存储有可被所述至少一个处理器执行的指令，所述指令被设置为用于执行上述实施例所述的运行监测方法。

图7是图示根据本申请实施例的电子设备的硬件结构示意图。电子设备可以以各种形式来实施，本申请实施例中的电子设备可以包括但不限于诸如移动电话、智能电话、笔记本电脑、数字广播接收器、PDA(个人数字助理)、PAD(平板电脑)、PMP(便携式多媒体播放器)、导航装置、车载终端设备、车载显示终端、车载电子后视镜等等的移动终端设备以及诸如数字TV、台式计算机等等的固定终端设备。

如图7所示，电子设备1100可以包括无线通信单元1110、A/V(音频/视频)输入单元1120、用户输入单元1130、感测单元1140、输出单元1150、存储器1160、接口单元1170、控制器1180和电源单元1190等等。图7示出了具有各种组件的终端设备，但是应理解的是，并不要求实施所有示出的组件。可以替代地实施更多或更少的组件。

其中，无线通信单元1110允许终端设备1100与无线通信***或网络之间的无线电通信。A/V输入单元1120用于接收音频或视频信号。用户输入单元1130可以根据用户输入的命令生成键输入数据以控制终端设备的各种操作。感测单元1140检测电子设备1100的当前状态、电子设备1100的位置、用户对于电子设备1100的触摸输入的有无、电子设备1100的取向、电子设备1100的加速或减速移动和方向等等，并且生成用于控制电子设备1100的操作的命令或信号。接口单元1170用作至少一个外部装置与电子设备1100连接可以通过的接口。输出单元1150被构造为以视觉、音频和/或触觉方式提供输出信号。存储器1160可以存储由控制器1180执行的处理和控制操作的软件程序等等，或者可以暂时地存储己经输出或将要输出的数据。存储器1160可以包括至少一种类型的存储介质。而且，电子设备1100可以与通过网络连接执行存储器1160的存储功能的网络存储装置协作。控制器1180通常控制终端设备的总体操作。另外，控制器1180可以包括用于再现或回放多媒体数据的多媒体模块。控制器1180可以执行模式识别处理，以将在触摸屏上执行的手写输入或者图片绘制输入识别为字符或图像。电源单元1190在控制器1180的控制下接收外部电力或内部电力并且提供操作各元件和组件所需的适当的电力。

本申请实施例提出的运行监测方法的各种实施方式可以以使用例如计算机软件、硬件或其任何组合的计算机可读介质来实施。对于硬件实施，本申请实施例提出的运行监测方法的各种实施方式可以通过使用特定用途集成电路(ASIC)、数字信号处理器(DSP)、数字信号处理装置(DSPD)、可编程逻辑装置(PLD)、现场可编程门阵列(FPGA)、处理器、控制器、微控制器、微处理器、被设计为执行这里描述的功能的电子单元中的至少一种来实施，在一些情况下，本申请实施例提出的媒体检索方法的各种实施方式可以在控制器1180中实施。对于软件实施，本申请实施例提出的运行监测方法的各种实施方式可以与允许执行至少一种功能或操作的单独的软件模块来实施。软件代码可以由以任何适当的编程语言编写的软件应用程序(或程序)来实施，软件代码可以存储在存储器1160中并且由控制器1180执行。

为了实现上述实施例，本申请实施例还提出一种计算机可读存储介质，其特征在于，所述计算机可读存储介质存储有计算机可读指令，所述计算机可读指令用于使计算机执行上述实施例所述的运行监测方法。

图8是图示根据本申请实施例的计算机可读存储介质的示意图。如图8所示，根据本申请实施例的计算机可读存储介质300，其上存储有计算机可读指令301。当该计算机可读指令301由处理器运行时，执行前述的本申请各实施例的运行监测方法的全部或部分步骤。

Claims (10)

1.一种运行监测方法，其特征在于，所述方法包括：

调用第一线程执行目标事件；

在执行所述目标事件过程中，监测执行时长以及获取在执行所述目标事件过程中占用运行资源的各第二线程的运行信息；

若监测到所述第一线程的执行时长大于阈值时长，确定所述第一线程存在运行异常；

将获取到的各第二线程的运行信息存储至目标存储位置。

2.根据权利要求1所述的运行监测方法，其特征在于，所述将获取到的各第二线程的运行信息存储至目标存储位置之后，还包括：

根据各第二线程的运行信息，确定各第二线程的方法调用耗时和/或调用的方法；

根据各第二线程的方法调用耗时和/或调用的方法，确定异常原因。

3.根据权利要求1所述的运行监测方法，其特征在于，所述调用第一线程执行目标事件，包括：

当待监测的应用程序启动时，调用第一线程循环执行所述目标事件。

4.根据权利要求3所述的运行监测方法，其特征在于，所述调用第一线程循环执行所述目标事件包括：

控制所述第一线程调用用于循环执行的类，以循环执行所述目标事件；

每一次执行所述目标事件之前，控制所述第一线程通过调用预设输出对象开始计时，以及开始调用所述CPU调度接口以获取临时文件，所述临时文件用于指示各第二线程的运行信息；

每一次执行所述目标事件之后，控制所述第一线程通过调用所述输出对象结束计时，以及结束调用所述CPU调度接口。

5.根据权利要求4所述的运行监测方法，其特征在于，所述方法，还包括：

当待监测的应用程序启动之后，调用用于循环执行的类设置所述输出对象；所述输出对象，用于计时以及调用所述CPU调度接口。

6.根据权利要求4所述的运行监测方法，其特征在于，所述将获取到的各第二线程的运行信息存储至目标存储位置，包括：

将所述临时文件存储至所述目标存储位置。

7.根据权利要求1-6任一项所述的运行监测方法，其特征在于，

所述第一线程为主线程；

所述第二线程包括所述主线程和对应的子线程。

8.一种运行监测装置，其特征在于，所述装置包括：

调用模块，用于调用第一线程执行目标事件；

监测模块，用于在执行所述目标事件过程中，监测执行时长以及获取在执行所述目标事件过程中占用运行资源的各第二线程的运行信息；

确定模块，用于若监测到所述第一线程的执行时长大于阈值时长，确定所述第一线程存在运行异常；

存储模块，用于将获取到的各第二线程的运行信息存储至目标存储位置。

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

至少一个处理器；以及，与所述至少一个处理器通信连接的存储器；

其中，所述存储器存储有可被所述至少一个处理器执行的指令，所述指令被设置为用于执行上述权利要求1-7任一项所述的运行监测方法。

10.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质存储有计算机可读指令，所述计算机可读指令用于使计算机执行权利要求1-7任一项所述的运行监测方法。