本发明涉及信息处理技术领域，特别是涉及一种应用程序监控方法以及一种应用程序监控装置。
背景技术：
随着智能手机、平板电脑等智能终端设备的日益普及，智能终端设备的处理能力越来越强，所能够安装运行的应用程序的数目越多。在应用程序的运行过程中，可能会出现卡顿现象，对应用程序的卡顿现象进行收集，以便于应用程序的卡顿问题进行分析，以对应用程序的性能进行分析，进而便于应用程序进行改进，是应用程序应用中的一项重要内容。目前针对应用程序卡顿问题的监控，通常是在应用程序出现卡顿现象时，在应用程序的日志中进行记录，并基于日志记录尝试重现，据此进行分析。然而，由于日志记录并不能完全反映出卡顿现场，而且用户使用环境不仅相同，基于日志记录并不能完整的重现卡顿，从而容易导致对卡顿现象分析的不准确性。
技术实现要素：
基于此，本实施例的目的在于提供一种应用程序监控方法以及一种应用程序监控装置，其可以在保留卡顿现场的情况下对应用程序的卡顿现象进行监控，据此提高对应用程序卡顿现象监控和分析的准确性。
为达到上述目的，本实施例采用以下技术方案：
一种应用程序监控方法，包括步骤：
监听应用程序的运行参数；
根据监听到的运行参数判断所述应用程序是否发生卡顿现象；
在判定所述应用程序发生卡顿现象时，记录所述应用程序的当前进程的运行状态和各个线程的堆栈信息。
一种应用程序监控方法装置，包括：
监听模块，用于监听应用程序的运行参数；
判断模块，用于根据所述监听模块监听到的运行参数判断所述应用程序是否发生卡顿现象；
记录模块，用于在所述判断模块判定所述应用程序发生卡顿现象时，记录所述应用程序的当前进程的运行状态和各个线程的堆栈信息。
基于如上所述的实施例的方案，其通过对应用程序的运行参数进行监听，并在根据监听到的运行参数判定应用程序发生卡顿现象时，记录该应用程序的当前进程的运行状态和各个线程的堆栈信息，而应用程序的当前进程的运行状态和各个线程的堆栈信息很好的反映了卡顿现场，从而可以在保留卡顿现场的情况下对应用程序的卡顿现象进行监控，据此提高对应用程序卡顿现象监控和分析的准确性。
附图说明
图1是一个实施例中的方案的应用环境的示意图；
图2是一个实施例中的终端的组成结构的示意图；
图3是一个实施例中的应用程序监控方法的流程示意图；
图4是一个具体示例中的本实施例方案的监控原理示意图；
图5是一个具体示例中的上传界面的示意图；
图6是一个具体示例中的后台服务器的原理示意图；
图7是一个具体示例中对卡顿现象进行分析的界面的示意图；
图8是一个实施例的应用程序监控装置的结构示意图；
图9是一个具体示例中的监听模块的结构示意图；
图10是一个具体示例中的记录模块的结构示意图。
具体实施方式
为使本发明的目的、技术方案及优点更加清楚明白，以下结合附图及实施例，对本发明进行进一步的详细说明。应当理解，此处所描述的具体实施方式仅仅用以解释本发明，并不限定本发明的保护范围。
图1示出了本发明一个实施例中的工作环境示意图，如图1所示，其工作环境涉及终端101以及后台服务器102，终端101与后台服务器102可以通过网络进行通信。终端101上运行有各种应用程序，终端101对其运行的应用程序进行监控，在监听到应用程序发生卡顿现象时，终端101记录发生卡顿现场的相关参数，并将这些相关参数发送给后台服务器102，由后台服务器102根据接收到的这些相关参数对应用程序的卡顿现象进行分析。本发明实施例涉及的是终端101对应用程序的卡顿现象进行监控的方案。
终端101在一个实施例中的结构示意图如图2所示。该终端101包括通过系统总线连接的处理器、存储介质、通信接口、电源接口和内存。其中，终端101的存储介质存储有一种应用程序监控装置，该装置用于实现一种应用程序监控方法。终端101的通信接口用于与后台服务器102连接和通信，终端101的电源接口用于与外部电源连接，外部电源通过该电源接口向终端101供电。终端101可以是任何一种能够实现智能输入输出的设备，例如移动终端，比如手机、平板电脑等；个人计算机等，也可以是其它具有上述结构的设备。
图3示出了一个实施例中的应用程序监控方法的流程示意图，如图3所示，该实施例的应用程序监控方法包括：
步骤s301：监听应用程序的运行参数；
步骤s302：根据监听到的运行参数判断所述应用程序是否发生卡顿现象，在判定述应用程序发生卡顿现象时，进入步骤s303；
步骤s303：记录所述应用程序的当前进程的运行状态和各个线程的堆栈信息。
基于如上所述的实施例的方案，其通过对应用程序的运行参数进行监听，并在根据监听到的运行参数判定应用程序发生卡顿现象时，记录该应用程序的当前进程的运行状态和各个线程的堆栈信息，而应用程序的当前进程的运行状态和各个线程的堆栈信息很好的反映了卡顿现场，从而可以在保留卡顿现场的情况下对应用程序的卡顿现象进行监控，据此提高对应用程序卡顿现象监控和分析的准确性。
其中，在上述步骤s301中监听应用程序的运行参数时，可以采用任何可能的方式进行，以下结合其中几种方式进行举例说明。
在一个具体示例中，监听应用程序的运行参数的方式可以包括：监听所述应用程序的主线程的开始运行时间，此时，上述运行参数包括所述开始运行时间。在具体技术应用中，可以通过创建一个新的监控子线程对应用程序的主线程的开始运行时间进行监控。
此时，在上述步骤s302根据监听到的运行参数判断所述应用程序是否发生卡顿现象时，可以在所述应用程序的当前进程的运行状态为运行中、且当前时间与所述开始运行时间的差值大于或者等于预定时间阈值时，判定所述应用程序发生卡顿现象。
在具体技术应用中，可以记录每一次主线程的开始运行时间以及该每一次主线程的结束运行时间，从而可以将时间最近的主线程的开始运行时间作为应用程序的主线程的开始运行时间。记录下的各次主线程的开始运行时间、结束运行时间，可以用以进行其他的相关的相关分析。另一方面，也可以是仅记录应用程序的主线程的开始运行时间，在主线程结束运行后，清除掉记录的该开始运行时间，从而在上述步骤s302进行判断时，直接读取记录的该开始运行时间即可。
在监听应用程序的主线程的开始运行时间时，在一个应用示例中，可以是通过在应用程序的主线程中嵌入observer函数，并通过嵌入在主线程里的observer函数监听所述应用程序的主线程的开始运行时间。在另一个应用示例中，可以通过与所述应用程序关联的屏幕刷新定时器监听所述应用程序的渲染帧开始时间，并将所述渲染帧开始时间作为所述开始运行时间。这里的屏幕刷新定时器可以是例如cadisplaylinkui，从而可以将cadisplaylinkui嵌入到主线程后，通过嵌入在主线程里的cadisplaylinkui对象监听所述应用程序的所述渲染帧开始时间。
在另一个具体示例中，监听应用程序的运行参数的方式可以包括：监听所述应用程序的主线程的运行状态。此时，上述运行参数包括所述应用程序的主线程的运行状态。
在此情况下，在上述步骤s302中根据监听到的运行参数判断所述应用程序是否发生卡顿现象时，可以是在所述应用程序的主线程的运行状态为等待事件阶段时，判定所述应用程序发生卡顿现象。
在另一个具体示例中，监听应用程序的运行参数的方式可以包括：监听所述应用程序的cpu使用率。此时，上述运行参数包括所述应用程序的cpu使用率。
在此情况下，在上述步骤s302中根据监听到的运行参数判断所述应用程序是否发生卡顿现象时，可以是在所述应用程序的cpu使用率大于或者等于使用率阈值时，判定所述应用程序发生卡顿现象。
在另一个具体示例中，监听应用程序的运行参数的方式可以包括：监听所述应用程序的帧渲染信息。此时，上述运行参数包括所述应用程序的帧渲染信息。
在此情况下，在上述步骤s302中根据监听到的运行参数判断所述应用程序是否发生卡顿现象时，可以是在所述应用程序的帧渲染信息判定所述应用程序掉帧时，判定所述应用程序发生卡顿现象。
在具体应用示例中，在上述步骤s301对应用程序的运行参数进行监听时，可以是每间隔一定的时间段监听一次，从而持续不断地实现对运行参数的监听。该时间段可以结合实际技术应用需要进行设定。据此，在上述步骤s302中判定所述应用程序未发生卡顿现象时，还可以在间隔预设时间段后，返回根据监听到的运行参数判断所述应用程序是否发生卡顿现象的步骤，重新对是否发生卡顿现象进行判断。该预设时间段可以结合实际需要进行设定，可以与上述监听运行参数的时间段相同，也可以是大于上述监听运行参数的时间段。
在上述步骤s303中的记录所述应用程序的当前进程的运行状态和各个线程的堆栈信息时，一个具体示例中的方式可以包括：将所述应用程序的当前进程的运行状态和各个线程的堆栈信息记录到dump文件。从而可以将应用程序的当前进程的运行状态和各个线程的堆栈信息以文件的方式记录下来，便于存储和便于上传到后台服务器进行后续的分析。
其中，在上述记录到dump文件时，一个具体示例中的方式可以是：
判断是否有与该卡顿现象对应的dump文件；具体判断时，可以是判断应用程序的当前主线程的调用栈与上一次卡顿现象的dump文件中记录的当前主线程的调用栈是否相同；若相同，则可以判定有与该卡顿现象对应的dump文件；若不相同，则可以判定没有与该卡顿现象对应的dump文件。
若是，即判定有与该卡顿现象对应的dump文件，则忽略该卡顿现象，无需重复生成对应的dump文件。
若否，即判定没有与该卡顿现象对应的dump文件，则生成该卡顿现象的dump文件，并将所述应用程序的当前进程的运行状态和各个线程的堆栈信息记录到生成的该dump文件。
在一个具体示例中，在上述步骤s303中记录所述应用程序的当前进程的运行状态和各个线程的堆栈信息后，还可以将记录的这些信息向后台服务器发送，以便后台服务器进行分析。因此，本实施例的方法还可以包括步骤：
向后台服务器发送卡顿记录信息，所述卡顿记录信息包括记录的所述应用程序的当前进程的运行状态和各个线程的堆栈信息，由后台服务器根据所述卡顿记录信息进行数据分析。
其中，在上述步骤s303中记录应用程序的当前进行的运行状态和各个线程的堆栈信息时是记录为dump文件时，则可以是将dump文件上传到后台服务器。在将dump文件上传到后台服务器是，可以是定时上传，也可以是基于终端用户的指令上传。
以基于终端用户的指令上传的情况下，此时，本实施例中的应用程序监控方法还可以包括步骤：
接收上传指令，所述上传指令包括时间范围；
获取所述时间范围内的dump文件；
将所述时间范围内的dump文件发送给后台服务器，由后台服务器根据所述dump文件进行数据分析。
在定时上传的情况下，此时，本实施例中的应用程序监控方法还可以包括步骤：
在到达预定上报时间点时，获取上一次预定上报时间点与当前预定上报时间点之间的dump文件；
将获取的dump文件发送给后台服务器，由后台服务器根据所述dump文件进行数据分析。
基于如上所述的实施例中的应用程序监控方法，其在终端用户使用终端的过程中，当终端的应用程序(例如app(application，第三方应用程序))在运行过程中出现卡顿时，本实施例方案可以记录下卡顿现场，即上述应用程序的当前进程的运行状态和各个线程的堆栈信息，然后上传到后台服务器进行分析。当然，如上所述，在生成dump文件的话，还可以由终端用户主动将dump文件上传到后台服务器供开发人员进行分析。
据此，图4示出了一个具体示例中的本实施例方案的监控原理的示意图，本实施例方案中，可以创建独立的监控子线程对终端的应用程序的一系列运行指标进行监控，这些运行指标与终端使用应用程序的过程中应用程序是否卡顿息息相关。此外，还可以对各运行指标设置对应的阈值，在监测到的运行指标超过对应的阈值时，即可以视为应用程序发生了卡顿，同时进行应用程序的相关参数急性记录，以捕获该卡顿现场。
在应用程序发生卡顿时，主要体现为界面操作没有反应，而在应用程序的代码层面，则主要体现在主线程繁忙、主线程进入等待事件阶段或者cpu使用率过高等等，从而导致主线程没有响应用户的点击或滑动等事件。
据此，在一个应用示例中，如图4所示，可以是对应用程序的主线程进行监控每一次主线程的运行时间。例如，可以是对主线程runloop进行监控，监控每一次主线程runloop的运行时间，如果运行时间过长则认为是卡顿。具体技术应用中，可以是通过在主线程runloop里增加observer函数，从而通过observer函数可以知晓每一个主线程runloop开始运行的时间点，即开始运行时间，通过开启一个子线程作为监控线程后，该监控线程可以定时地通过observer对每次主线程runloop的开始运行时间进行检查，如果超过一定时间该次主线程runloop还未执行完毕，即当前时间与该次主线程runloop的开始运行时间的差值大于或者等于预定时间阈值时，则判定主线程产生卡顿。
在监控到应用程序发生卡顿现象后，需要保留卡顿现场，为了能够有更多的有用信息，本实施例中可以在监控到应用程序发生卡顿现象时，将应用程序的进程内所有线程的调用栈都记录下来，包括应用程序的当前进程的运行状态和各个线程的堆栈信息，作为分析卡顿原因时的信息。
在监控到应用程序发生卡顿现象后，可以根据应用程序的当前主线程的调用栈，判断该当前卡顿现象是否已经在最近被记录为dump文件，例如判断应用程序的当前主线程的调用栈与上一次卡顿现象的dump文件中记录的当前主线程的调用栈是否相同，如果相同，则已经被记录为dump文件，如果不相同，则未被记录为dump文件。
如果已经被记录为dump文件，为了避免重复记录dump文件消耗终端本地存储空间，则忽略该卡顿现象，则暂时不进行记录，如果没有被记录为dump文件，则记录为dump文件并进行保存。其中，在记录为dump文件时，还可以同时将应用程序的部分日志信息写入该dump文件。其中，每一个卡顿现象可以生成一个对应的dump文件。
终端在生成dump文件以后，可以基于设定的策略上传到后台服务器，后台服务器会将接收到的dump文件保存，并做分析处理获得最终的分析结果，供开发人员使用。
终端在将dump文件上传到后台服务器时，可以是终端每间隔一定时间后自动将上传一次上报之后生成的dump文件或者是一定数量的dump文件上传到后台服务器，也可以是手动进行上报。图5示出了一个具体示例中的上传界面的示意图，如图5所示，可以选择上报全部的dump文件或者是哪个时间段(例如某天)的dump文件。终端将dump文件上传到后台服务器时，可以基于任何可能的网络通信协议进行。
后台服务器可以一台独立的服务器，也可以是一个服务器集群。以后台服务器是服务器集群为例，图6示出了一个具体示例中的后台服务器的原理示意图，后台服务器在接收到终端上传的dump文件后，将接收到的dump文件保存在存储服务器，然后由分析服务器定时从存储服务器拉取数据分析，数据分析后的结果可以开发人员使用的终端上进行显示，供开发人员查看，便于对应用程序进行改进等。在进行数据分析时，可以采用任何可能的方式进行。由于dump文件中记录了应用程序的当前进程的运行状态和各个线程的堆栈信息，因此，在进行分析时，可以通过聚类等方式进行分析，具体的聚类分析方式本实施例不做限定，一个具体示例中对卡顿现象进行分析后分析界面如图7所示。
如上所述的实施例中的方法，可以集成应用在应用程序中，也可以是集成应用在一个组件上，以供其他的应用程序调用。
基于与上述实施例中的方法相同的思想，还提供一种应用程序监控装置。
图8示出了一个实施例中的应用程序监控装置的结构示意图，该实施例中的应用程序监控装置包括：
监听模块801，用于监听应用程序的运行参数；
判断模块802，用于根据所述监听模块监听到的运行参数判断所述应用程序是否发生卡顿现象；
记录模块803，用于在所述判断模块判定所述应用程序发生卡顿现象时，记录所述应用程序的当前进程的运行状态和各个线程的堆栈信息。
基于如上所述的实施例的方案，其通过对应用程序的运行参数进行监听，并在根据监听到的运行参数判定应用程序发生卡顿现象时，记录该应用程序的当前进程的运行状态和各个线程的堆栈信息，而应用程序的当前进程的运行状态和各个线程的堆栈信息很好的反映了卡顿现场，从而可以在保留卡顿现场的情况下对应用程序的卡顿现象进行监控，据此提高对应用程序卡顿现象监控和分析的准确性。
监听模块801在监听应用程序的运行参数时，可以采用任何可能的方式进行。图9中示出了一个具体示例中的监听模块的结构示意图。
如图9所示，在一个具体示例中，监听模块801可以包括：
运行时间监听模块8011，用于监听所述应用程序的主线程的开始运行时间，此时，上述运行参数包括所述开始运行时间。在具体技术应用中，可以通过创建一个新的监控子线程对应用程序的主线程的开始运行时间进行监控。
此时，上述判断模块802可以在所述应用程序的当前进程的运行状态为运行中、且当前时间与所述开始运行时间的差值大于或者等于预定时间阈值时，判定所述应用程序发生卡顿现象。
在具体技术应用中，可以记录每一次主线程的开始运行时间以及该每一次主线程的结束运行时间，从而可以将时间最近的主线程的开始运行时间作为应用程序的主线程的开始运行时间。记录下的各次主线程的开始运行时间、结束运行时间，可以用以进行其他的相关的相关分析。另一方面，也可以是仅记录应用程序的主线程的开始运行时间，在主线程结束运行后，清除掉记录的该开始运行时间，从而判断模块802在进行判断时，直接读取记录的该开始运行时间即可。
在一个具体示例中，运行时间监听模块8011可以通过嵌入在主线程里的observer函数监听所述应用程序的主线程的开始运行时间。在另一个应用示例中，运行时间监听模块8011可以通过与所述应用程序关联的屏幕刷新定时器监听所述应用程序的渲染帧开始时间，并将所述渲染帧开始时间作为所述开始运行时间。这里的屏幕刷新定时器可以是例如cadisplaylinkui(一个能以和屏幕刷新率相同的频率将内容画到屏幕上的定时器)，从而可以将cadisplaylinkui嵌入到主线程后，通过嵌入在主线程里的cadisplaylinkui对象监听所述应用程序的所述渲染帧开始时间。
在另一个具体示例中，如图9所示，该监听模块801可以包括：
运行状态监听模块8012，用于监听所述应用程序的主线程的运行状态。此时，上述运行参数包括所述应用程序的主线程的运行状态。
在此情况下，判断模块802可以在所述应用程序的主线程的运行状态为等待事件阶段时，判定所述应用程序发生卡顿现象。
在另一个具体示例中，如图9所示，该监听模块801可以包括：
使用率监听模块8013，用于监听所述应用程序的cpu使用率。此时，上述运行参数包括所述应用程序的cpu使用率。
在此情况下，判断模块802可以在所述应用程序的cpu使用率大于或者等于使用率阈值时，判定所述应用程序发生卡顿现象。
在另一个具体示例中，如图9所示，该监听模块801可以包括：
渲染信息监听模块8014，用于监听所述应用程序的帧渲染信息。此时，上述运行参数包括所述应用程序的帧渲染信息。
在此情况下，判断模块802可以在所述应用程序的帧渲染信息判定所述应用程序掉帧时，判定所述应用程序发生卡顿现象。
在具体应用示例中，判断模块802在对应用程序的运行参数进行监听时，可以是每间隔一定的时间段监听一次，从而持续不断地实现对运行参数的监听。该时间段可以结合实际技术应用需要进行设定。
据此，在一个具体示例中，上述判断模块802，还用于在判定所述应用程序发生卡顿现象时在间隔预设时间段后，重新根据所述监听模块监听到的运行参数判断所述应用程序是否发生卡顿现象。该预设时间段可以结合实际需要进行设定，可以与上述监听运行参数的时间段相同，也可以是大于上述监听运行参数的时间段。
在记录模块803记录所述应用程序的当前进程的运行状态和各个线程的堆栈信息时，一个具体示例中的方式可以包括：将所述应用程序的当前进程的运行状态和各个线程的堆栈信息记录到dump文件。从而可以将应用程序的当前进程的运行状态和各个线程的堆栈信息以文件的方式记录下来，便于存储和便于上传到后台服务器进行后续的分析。
图10中示出了一个具体示例中的记录模块803的结构示意图，该记录模块803包括：
查找模块8031，用于判断是否有与该卡顿现象对应的dump文件；具体判断时，可以是判断应用程序的当前主线程的调用栈与上一次卡顿现象的dump文件中记录的当前主线程的调用栈是否相同；若相同，则可以判定有与该卡顿现象对应的dump文件；若不相同，则可以判定没有与该卡顿现象对应的dump文件；
文件生成模块8032，用于在查找模块8031的判定结果为否时，生成该卡顿现象的dump文件，并将所述应用程序的当前进程的运行状态和各个线程的堆栈信息记录到生成的该dump文件。
若查找模块8031的判定结果为是，即判定有与该卡顿现象对应的dump文件，则文件生成模块8032忽略该卡顿现象，无需重复生成对应的dump文件。
在一个具体示例中，在记录模块803记录所述应用程序的当前进程的运行状态和各个线程的堆栈信息后，还可以将记录的这些信息向后台服务器发送，以便后台服务器进行分析。因此，如图8所示，本实施例的装置还可以包括上传模块804。
其中，在一个具体示例中，该上传模块804，用于向后台服务器发送卡顿记录信息，所述卡顿记录信息包括记录的所述应用程序的当前进程的运行状态和各个线程的堆栈信息，由后台服务器根据所述卡顿记录信息进行数据分析。
在将上述应用程序的当前进程的运行状态和各个线程的堆栈信息记录到dump文件后，则可以是将dump文件上传到后台服务器。
在将dump文件上传到后台服务器时，可以是定时上传，也可以是基于终端用户的指令上传。
以基于终端用户的指令上传的情况下，此时，该上传模块804，用于接收上传指令，所述上传指令包括时间范围，获取所述时间范围内的dump文件，并将所述时间范围内的dump文件发送给后台服务器，由后台服务器根据所述dump文件进行数据分析。此时，上述卡顿记录信息可以是通过该dump文件来体现，或者说dump文件中包括上述卡顿记录信息。
在定时上传的情况下，此时，该上传模块804，用于在到达预定上报时间点时，获取上一次预定上报时间点与当前预定上报时间点之间的dump文件，并将获取的dump文件发送给后台服务器，由后台服务器根据所述dump文件进行数据分析。此时，上述卡顿记录信息可以是通过该dump文件来体现，或者说dump文件中包括上述卡顿记录信息。
本领域普通技术人员可以理解实现上述实施例方法中的全部或部分流程，是可以通过计算机程序来指令相关的硬件来完成，所述的程序可存储于一非易失性的计算机可读取存储介质中，如本发明实施例中，该程序可存储于计算机系统的存储介质中，并被该计算机系统中的至少一个处理器执行，以实现包括如上述各方法的实施例的流程。其中，所述的存储介质可为磁碟、光盘、只读存储记忆体(read-onlymemory，rom)或随机存储记忆体(randomaccessmemory，ram)等。
以上所述实施例的各技术特征可以进行任意的组合，为使描述简洁，未对上述实施例中的各个技术特征所有可能的组合都进行描述，然而，只要这些技术特征的组合不存在矛盾，都应当认为是本说明书记载的范围。
以上所述实施例仅表达了本发明的几种实施方式，其描述较为具体和详细，但并不能因此而理解为对发明专利范围的限制。应当指出的是，对于本领域的普通技术人员来说，在不脱离本发明构思的前提下，还可以做出若干变形和改进，这些都属于本发明的保护范围。因此，本发明专利的保护范围应以所附权利要求为准。