CN113971122A - 一种系统卡顿检测方法、智能终端及存储介质 - Google Patents

Abstract

本发明公开了一种系统卡顿检测方法、智能终端及存储介质，方法包括：监测事件处理进程；当监测到事件处理进程处理事件时，生成事件的处理时间；判断处理时间是否满足预设的卡顿条件；若处理时间满足卡顿条件，则向服务器上报卡顿。本发明能够快速精确地定位引起卡顿发生的具体阶段，提高后续系统及应用的优化效率。

Description

一种系统卡顿检测方法、智能终端及存储介质

技术领域

本发明涉及计算机技术领域，尤其涉及一种系统卡顿检测方法、智能终端及存储介质。

背景技术

日常生活中，电脑手机等智能终端所占比重越来越大。用户对智能终端的性能要求也越来越高。而很多性能是不易被发现的，但卡顿位问题是容易被直观感受到的。卡顿是指应用程序在运行时出现画面滞帧的现象。只是轻微的卡顿，也需要等到较长的时间才能生效。卡顿产生的原因错综复杂，涉及智能终端的系统优化，用户的手机内存，用户磁盘IO空间不足等等因素。

目前采用的卡顿问题分析主要是基于用户的使用日志。当用户上报系统存在卡顿时，需要用户上报终端的log日志，并根据log日志上记录的时间和系统状态，分析发生卡顿的原因。然而log日志和卡顿的发生存在时间差异，因此log日志并不能完全反映卡顿发生时的状况，卡顿产生的场景无法复现，因此程序员也无法真正发现卡顿产生的真实原因。一般情况下会建议用户清理控件和卸载应用，虽然能够短暂解决卡顿问题，但是随着用户的使用，数据依旧会累加，卡顿的问题依旧会出现。因此清理内存和卸载应用都仅仅是临时方案，只有找到卡顿发生的真正原因，才能够解决问题。

发明内容

本发明的主要目的在于提供一种系统卡顿检测方法、智能终端及存储介质，旨在解决现有技术中无法精确确定引起卡顿的真正原因的技术问题。

为实现上述目的，本发明提供一种系统卡顿检测方法，系统卡顿检测方法包括如下步骤：

监测事件处理进程；

当监测到事件处理进程处理事件时，生成事件的处理时间；

判断处理时间是否满足预设的卡顿条件；

若处理时间满足卡顿条件，则向服务器上报卡顿。

可选地，事件处理进程包括系统处理进程和应用处理进程；

其中，系统处理进程用于接收事件，对事件进行加工后生成事件信息，并将事件信息发送至应用处理进程；

应用处理进程用于根据事件信息执行事件，并将执行结果反馈至系统处理进程。

可选地，当监测到事件处理进程处理事件时，生成事件的处理时间，包括：

当监测到系统处理进程处理事件时，记录系统处理时刻；

当监测到应用处理进程处理事件时，记录应用处理时刻；

计算系统处理时刻内多个时刻的差值和应用处理时刻内多个时刻的差值，生成事件的处理时间。

可选地，当监测到系统处理进程处理事件时，记录系统处理时刻，包括：

当监测到系统处理进程接收事件时，记录当前的时刻并作为系统第一开始时刻；

当监测到系统处理进程对事件进行加工后生成事件信息时，记录开始加工的时刻和生成事件信息的时刻，并分别作为系统第二开始时刻和系统第二结束时刻；

当监测到系统处理进程将事件信息发送至应用处理进程时，记录当前的时刻并作为系统第一结束时刻。

可选地，当监测到应用处理进程处理事件时，记录应用处理时刻，包括：

当监测到应用处理进程接收事件信息时，记录当前的时刻并作为应用第一开始时刻；

当监测到应用处理进程根据事件信息执行事件时，记录开始执行的时刻和执行结束的时刻，并分别作为应用第二开始时刻和应用第二结束时刻；

当监测到应用处理进程将执行结果发送至系统处理进程时，记录当前的时刻并作为应用第一结束时刻。

可选地，计算系统处理时刻内多个时刻的差值和应用处理时刻内多个时刻的差值，生成事件的处理时间，包括：

计算系统第一开始时刻和系统第一结束时刻的差值，得到系统第一处理时间；

计算系统第二开始时刻和系统第二结束时刻的差值，得到系统第二处理时间；

计算应用第一开始时刻和应用第一结束时刻的差值，得到应用第一处理时间；

计算应用第二开始时刻和应用第二结束时刻的差值，得到应用第二处理时间；其中，系统第一处理时间、系统第二处理时间、应用第一处理时间和应用第二处理时间为事件的处理时间。

可选地，卡顿条件包括服务器根据智能终端的机型信息下发的处理时间阈值，判断处理时间是否满足预设的卡顿条件，包括：

判断处理时间是否大于处理时间阈值；

若处理时间大于处理时间阈值，则确定处理时间满足卡顿条件。

可选地，向服务器上报卡顿之前，方法还包括：

获取当前的运行数据；

对运行数据进行封装，生成运行数据包。

向服务器上报卡顿，包括：

基于预设的应用编程接口，将运行数据包发送至服务器。

可选地，监测事件处理进程之前，包括：

获取智能终端的机型信息，并将机型信息发送至服务器；

接收服务器根据机型信息返回的参考条件；

判断参考条件与卡顿条件是否存在差异；

若存在，则根据参考条件，对卡顿条件进行更新。

此外，为实现上述目的，本发明还提供一种智能终端，其中，智能终端包括：存储器、处理器及存储在存储器上并可在处理器上运行的卡顿检测程序，卡顿检测程序被处理器执行时实现如上系统卡顿检测方法的步骤。

此外，为实现上述目的，本发明还提供一种存储介质，其中，存储介质存储有卡顿检测程序，卡顿检测程序被处理器执行时实现如上系统卡顿检测方法的步骤。

本发明提出了一种系统卡顿检测方法、智能终端及存储介质，能够监测事件处理进程。当事件处理进程在处理事件时，通过预先安置的埋点，对其中的部分或全部线程进行处理时刻的采集。然后通过这些处理时刻，可计算事件处理过程中某个线程、某段步骤或整个处理过程的处理时间。再将得到的处理时间和卡顿条件进行比较，当处理时间满足卡顿条件时，可确定当前的处理时间可能会引起卡顿，因此获取当前的运行数据，再将运行数据发送至服务器，服务器根据这些运行数据，可准确判断卡顿发生的真正原因，并以此对系统或应用进行优化。本发明的处理时间是伴随着事件处理而记录的，因此采集的运行数据具有实时性，相较于以往的方法，具有更高的真实性和可重复性，提高判断卡顿产生的原因的准确性。

此外，在本发明中，智能终端还可根据服务器下发的参考条件对卡顿条件进行更新，以减少误报的发生。将运行数据发送至服务器时，本发明还提供了一种通过应用编程接口传输运行数据至服务器的方法，减少服务器后续的数据提取时间，提高处理效率。

附图说明

图1是本发明系统卡顿检测方法提供的实施例的流程图；

图2和图3是本发明系统卡顿检测方法的较佳实施例中步骤S100之前的流程示意图；

图4是本发明系统卡顿检测方法的较佳实施例中步骤S200流程图；

图5是本发明系统卡顿检测方法的较佳实施例中步骤S210流程图；

图6是本发明系统卡顿检测方法的较佳实施例中事件处理流程图；

图7是本发明系统卡顿检测方法的较佳实施例中步骤S220流程图；

图8是本发明系统卡顿检测方法的较佳实施例中步骤S300流程图；

图9是本发明系统卡顿检测方法的较佳实施例中步骤S400之前流程的示意图图；

图10是本发明系统卡顿检测方法的较佳实施例的检测过程的流程图；

图11为本发明智能终端的较佳实施例的运行环境示意图。

具体实施方式

为使本发明的目的、技术方案及优点更加清楚、明确，以下参照附图并举实施例对本发明进一步详细说明。应当理解，此处所描述的具体实施例仅仅用以解释本发明，并不用于限定本发明。

本发明较佳实施例系统卡顿检测方法，如图1所示，系统卡顿检测方法包括以下步骤：

步骤S100、系统卡顿检测程序监测事件处理进程。

在本实施例中，智能终端可以是手机、平板、电视等具有各种操作系统和输入装置的硬件设备，执行主体为安装于智能终端上的系统卡顿检测程序。具体地，可通过监测器或埋点的方式对事件处理进程进行监测。以埋点为例，常规的埋点包括手动埋点和可视化埋点。手动埋点，也叫代码埋点，即纯手动写代码，调用埋点SDK的函数，在需要埋点的业务逻辑功能位置调用接口，上报埋点数据。在本发明中，在事件处理进程中关注的逻辑节点进行埋点，当事件处理进程在处理事件时，可通过埋点逻辑对其进行实时监测。

进一步地，参阅图2和图3，在步骤S100之前，还包括以下步骤：

步骤S110、系统卡顿检测程序获取智能终端的机型信息，并将机型信息发送至服务器。

在本实施例中，当智能终端开机时，获取智能终端的机型信息，因为不同的机型，所安装的系统、设备对输入的感应、传输等方面都存在差异，因此卡顿条件应当根据不同的机型来设定。然后将机型信息发送至服务器，以请求服务器根据之前采集的处理时间生成的参考条件。

步骤S120、系统卡顿检测程序接收服务器根据机型信息返回的参考条件。

具体地，服务器接收机型信息后，根据机型信息，在数据库中查找对应的参考条件并返回。

步骤S130、系统卡顿检测程序判断参考条件与卡顿条件是否存在差异。

具体地，预先设置的卡顿条件是通过服务器下发的参考条件生成的，服务器端会不断根据机型或其他设备反馈的处理时间，对参考条件进行更新。将参考条件与本地已保存的卡顿条件进行比较，判断两者是否存在差异，若有差异，则说明参考条件存在更新。

步骤S140、若存在，则系统卡顿检测程序根据参考条件，对卡顿条件进行更新。

具体地，若两者存在差异，则根据参考条件，对卡顿条件进行更新。一种更新方式是将预先设置的卡顿条件删除，并将参考条件的文件名改为卡顿条件；另一种更新方式是直接将卡顿条件中与参考条件不一致的内容修改为参考条件中的内容。

在本实施例中，提供了一种参考条件的更新方案，以减少误报的发生。

步骤S200、当监测到事件处理进程处理事件时，系统卡顿检测程序生成事件的处理时间。

具体地，预先在事件处理进程中埋下多个采集点，用于记录事件处理进程在处理事件过程中的处理时刻。事件处理进程包括多个处理阶段，采集点可以埋在事件处理进程的开始和/或结束，也可以埋在处理阶段的开始和结束，用于记录事件处理过程中的部分或全部阶段的处理时间。处理时刻包括开始时刻和结束时刻，计算开始时刻和结束时刻之间的差值，生成事件的处理时间。

进一步地，事件处理进程包括系统处理进程和应用处理进程；其中，系统处理进程用于接收事件，对事件进行加工后生成事件信息，并将事件信息发送至应用处理进程；应用处理进程用于根据事件信息执行事件，并将执行结果反馈至系统处理进程。

具体地，事件处理进程可分为事件分派和事件执行，其中，事件分派是将输入的某个事件，如点击、按键、滑动，传递到某个具体的窗口的过程，而事件执行则是对应的窗口执行对应的事件内容并在窗口上显示结果的过程，而窗口执行事件本质上是对应的应用执行事件，因此事件处理进程可视为终端的系统接收并发送事件的系统处理进程，和接收事件，确定执行的窗口并执行的应用处理进程。系统处理进程接收事件，然后确定输入事件的输入设备等信息，再将这些信息加工打包，生成事件信息，最后将事件信息发送至对应的应用处理进程。而应用处理进程接收事件信息后，根据事件信息执行对应的事件内容，如在终端的界面上显示用户通过键盘输入的数字，执行事件内容后，应用处理进程会通知系统处理进程事件已经执行完毕，避免系统处理进程重复派发事件信息。

进一步地，参阅图4，步骤S200包括：

步骤S210、当监测到系统处理进程处理事件时，系统卡顿检测程序记录系统处理时刻。

具体地，当监测到系统处理进程处理事件时，由于预先在系统处理进程中埋下采集点，基于该采集点，记录系统处理进程接收事件的时刻和发送事件信息的时刻，前者作为系统处理开始时刻，后者作为系统处理结束时刻。此外，系统处理进程包括多个线程，可在部分或全部线程埋下采集点，用于记录每一个线程的处理时间，以便后续服务器更好确定卡顿发生的原因。

步骤S220、当监测到应用处理进程处理事件时，系统卡顿检测程序记录应用处理时刻。

具体地，当监测到应用处理进程处理事件时，由于预先在应用处理进程中埋下采集点，基于该采集点，记录应用处理进程接收事件信息的时刻和向系统处理进程反馈执行结果的时刻，前者作为应用处理开始时刻，后者作为应用处理结束时刻。此外，应用处理进程包括多个线程，可在部分或全部线程埋下采集点，用于记录每一个线程的处理时间，以便后续服务器更好确定卡顿发生的原因。

步骤S230、系统卡顿检测程序计算系统处理时刻内多个时刻的差值和应用处理时刻内多个时刻的差值，生成事件的处理时间。

具体地，可计算系统处理开始时刻与应用处理结束时刻之间的差值，得到事件处理进程的处理时间。还可计算系统处理开始时刻与系统处理结束时刻之间的差值，得到系统处理进程的处理时间；还可计算应用处理开始时刻与应用处理结束时刻之间的差值，得到应用处理进程的处理时间。

进一步地，参阅图5和图6，步骤S210包括：

步骤S211、当监测到系统处理进程接收事件时，系统卡顿检测程序记录当前的时刻并作为系统第一开始时刻。

在本实施例中，终端采用的系统为Android系统，用户通过终端的屏幕返回按键，输入按键事件。在Android系统中负责管理输入事件的主要是输入管理服务(InputManager Service，IMS)。IMS主要的任务是从输入设备中读取事件数据，然后将输入事件发送至焦点窗口，并处理部分系统按键。输入事件按照事件类型可分为输入事件、按键事件等。当输入设备输入按键事件时，IMS中的输入事件管理模块EventHub获取事件，EventHub用于管理输入设备和读取输入事件，它采用inotify方法监测输入设备的添加和移除，并监测输入设备的数据变化。EventHub后续会将点击发生在屏幕上的位置坐标、事件的事件类型等信息打包，作为事件的原始事件数据发送至后续的输入事件读取模块InputReader。预先在EventHub埋下采集点，当EventHub接收事件时，记录当前的时刻，并将其作为系统第一开始时刻。

步骤S212、当监测到系统处理进程对事件进行加工后生成事件信息时，系统卡顿检测程序记录开始加工的时刻和生成事件信息的时刻，并分别作为系统第二开始时刻和系统第二结束时刻。

具体地，EventHub将原始数据发送至输入事件读取模块InputReader后，InputReader开始对原始数据进行加工，生成事件信息。当输入设备初次连接的时候，InputReader会根据设备类型创建并添加相对应的输入设备的输入映射，如键盘设备添加KeyboardInputMapper。InputReader接收EventHub发送的事件的原始数据后，分两个步骤处理该事件。首先确定该事件所对应的输入设备类型，如鼠标、键盘、触摸屏。其次，根据用户按下键和抬起键的时间和位置的变化，确定事件所对应的输入事件的类型，如点击事件、滑动事件。最后对事件进行解析，如在按键事件中，根据按键点击发生的坐标以及预先添加的输入映射，确定其对应的键盘码。基于预先埋下的采集点，可记录InputReader刚接收原始数据的时刻及InputReader将事件信息传递给输入事件分发模块的时刻，并分别作为系统第二开始时刻和系统第二结束时刻。此外，由于InputReader加工是先按照输入设备类型处理，再根据事件类型处理，为达到更好确定卡顿是由于哪一阶段引起，可在设备类型处理阶段和事件类型处理阶段分别埋下采集点，并在加工过程中，基于采集点，记录InputReader设备类型处理阶段开始的时刻和结束的时刻，以及事件类型处理阶段开始的时刻和结束的时刻，用于后续根据他们的开始时刻和结束时刻计算这一阶段的处理时间。InputReader有一个对应的输入事件读取线程，当EventHub传输事件信息时，该线程被唤醒，并从EventHub获取事件信息。

步骤S213、当监测到系统处理进程将事件信息发送至应用处理进程时，系统卡顿检测程序记录当前的时刻并作为系统第一结束时刻。

具体地，InputReader将事件信息发送输入事件派发模块，如InputDispather。InputDispather对应一个事件派发线程(InputDispatcherThread)，先将事件添加至一个队列中，事件派发线程被唤醒后循环将事件派发出去。基于预先设置的采集点，可记录将事件派发出去的时刻并作为系统第一结束时刻。事件派发需要先找到当前的窗口，然后根据窗口找到连接对应应用的连接通道，再将事件信息添加到对应的连接通道的队列中，再调用函数将事件信息发送出去。发送事件信息后，将发送记录在等待队列的队尾，直到接收应用处理进程执行完事件对应的事件内容返回的消息后，在对应的等待队列中将记录删除，避免重复派送。此外，还可记录InputDispather接收InputReader发送事件信息的时刻并作为InputDispatcher的进入时刻，InputDispatcher按照事件类型处理事件信息的开始时刻和结束时刻。

此外，本实施例仅仅以简单的事件分派为例进行描述，在另一个实施例中，InputDispatcher并不能直接将事件信息派发至应用处理进程，在事件分发之前还要进行一次拦截。例如HOME键在派发前会被拦截，并转交给手机窗口管理(PhoneWindowManager)，由其启动HOMO桌面并消费掉事件。为确定拦截是否是引起卡顿的原因，在拦截和拦截处理完返回处理结果时，也记录拦截发生和返回处理结果的时刻。

进一步地，参阅图6和图7，步骤S220包括：

步骤S221、当监测到应用处理进程接收事件信息时，系统卡顿检测程序记录当前的时刻并作为应用第一开始时刻。

在本实施例中，当应用处理进程在调用窗口管理服务(Window ManangerService，WMS)的addWindow方法时，WMS会为应用和InputDispatcher建立一个建立事件通道(InputChannel)并将其注册到InputDispatcher，因此InputDispatcher可通过事件通道将事件信息派送给对应的窗口。基于预先设置在应用处理进程中的多个采集点，当监测到应用处理进程接收到事件信息的时候，记录当前的时刻并作为应用第一开始时刻。

步骤S222、当监测到应用处理进程根据事件信息执行事件时，系统卡顿检测程序记录开始执行的时刻和执行结束的时刻，并分别作为应用第二开始时刻和应用第二结束时刻。

具体地，应用处理进程获取事件信息后，将事件信息所包含的事件读取出来，并传递至窗口管理模块ViewRootImpl，ViewRootImpl相当于一个窗口的控制者，通过一个责任链，确定事件的处理顺序和方式，以及确定哪一个窗口执行。然后将事件信息发送至对应的窗口，然后该窗口执行所属事件信息对应的事件内容，如在窗口上显示某个字母。基于预先设置在应用处理进程中的多个采集点，当监测到应用处理进程开始处理事件信息的时候，记录当前的时刻并作为应用第二开始时刻，并记录窗口结束处理的时刻并作为应用第二结束时刻。此外，还可记录ViewRootImpl开始寻找目标窗口的时刻、确定目标窗口的时刻和发送事件信息至目标窗口的时刻，用于后续判断将事件信息分派至对应窗口阶段是否存在卡顿。

步骤S223、当监测到应用处理进程将执行结果发送至系统处理进程时，记录当前的时刻并作为应用第一结束时刻。

具体地，当目标窗口执行完事件后，应用处理进程需要将执行结果返回系统处理进程，系统处理进程将事件在队列中删除，因此可将收到应用处理进程反馈执行结果作为事件已经执行完成的标志，当监测到应用处理进程将执行结果反馈至系统处理进程时，基于预先埋点的采集点，记录当前时刻T32，并将其作为应用第一结束时刻。

在另一个实施例中，若执行失败，系统处理进程会查看是否有备选事件，并将备选事件加入待分派事件的队列，下一次循环时发送至窗口，以执行备选事件，只有当系统处理进程接收的反馈结果为成功时，才记录当前时刻并作为应用第一结束时刻。

进一步地，步骤S230包括：

系统卡顿检测程序计算系统第一开始时刻和系统第一结束时刻的差值，得到系统第一处理时间；

系统卡顿检测程序计算系统第二开始时刻和系统第二结束时刻的差值，得到系统第二处理时间；

系统卡顿检测程序计算应用第一开始时刻和应用第一结束时刻的差值，得到应用第一处理时间；

系统卡顿检测程序计算应用第二开始时刻和应用第二结束时刻的差值，得到应用第二处理时间；其中，系统第一处理时间、系统第二处理时间、应用第一处理时间和应用第二处理时间为事件的处理时间。

具体地，计算系统第一开始时刻和系统第一结束时刻的差值、系统第二开始时刻和系统第二结束时刻的差值、应用第一开始时刻和应用第一结束时刻的差值，以及应用第二开始时刻和应用第二结束时刻的差值，分别生成系统第一处理时间、系统第二处理时间、应用第一处理时间和应用第二处理时间，后续用于与卡顿条件一一比较。

此外，系统第二处理时间还可包括InputReader设备类型处理时间和时间类型处理时间，可根据上述InputReader设备类型处理阶段开始的时刻和结束的时刻，以及事件类型处理阶段开始的时刻和结束的时刻的差值计算生成；应用第二处理时间还可包括确定窗口时间，可计算上述ViewRootImpl开始寻找目标窗口的时刻、确定目标窗口的时刻和/或发送事件信息至目标窗口的时刻之间的差值生成；处理时间还可包括拦截处理时间，计算上述拦截发生时刻和返回拦截处理结果时刻生成拦截处理时间。

计算差值和生成事件的处理时间并不存在先后顺序关系，例如生成系统第一处理时间和系统第二处理时间可以是一旦记录下来就生成，也可以是在全部执行完事件后生成，本实施例对此并不加以进行限制，程序在执行过程中可自由选择。

步骤S300，系统卡顿检测程序判断处理时间是否满足预设的卡顿条件。

具体的，预先设定根据处理时间判断智能终端是否卡顿的卡顿条件，判断处理时间是否满足卡顿条件，若满足，则智能终端卡顿，执行后续步骤。

进一步地，参阅图8，卡顿条件包括服务器根据智能终端的机型信息下发的处理时间阈值，步骤S300包括：

步骤S310，系统卡顿检测程序判断处理时间是否大于处理时间阈值。

在本实施例中，预设的卡顿条件包括处理时间阈值，获得处理时间后，将其与预先设置的处理时间阈值进行大小比较。

步骤S320，若处理时间大于处理时间阈值，则系统卡顿检测程序确定处理时间满足卡顿条件。

若处理时间大于处理时间阈值，则确定处理时间满足预设的卡顿条件，若处理时间大于等于处理时间阈值，则处理时间不满足预设的卡顿条件。

步骤S400，若处理时间满足卡顿条件，则系统卡顿检测程序向服务器上报卡顿。

具体地，若处理时间满足卡顿条件，则确定事件处理过程出现了卡顿，并向服务器上报该卡顿。在上报卡顿的时候，可选择将当前终端的运行状态以及处理时间一同上报至服务器。

进一步地，参阅图9和图10，步骤S400之前，方法还包括：

步骤S410，系统卡顿检测程序获取当前的运行数据。

具体地，在确定是否发生卡顿之前，可先获取智能终端的各项运行数据，例如期间的CPU占用率，内存占用率，存储状态，运行程序以及事件的处理时间等等，以保证后续发送给服务器的运行数据包是卡顿发生时的运行数据，而非执行事件之后的运行数据，提高数据的有效性。

步骤S420，系统卡顿检测程序对运行数据进行封装，生成运行数据包。

在本实施例中，获取运行数据后，将其写入空白的文件中，从而生成易于解析的运行数据报。例如该文件格式为JSON(JavaScriptObjectNatation，JS对象简谱)格式，JSON是一种轻量级的数据交换格式，层次接受简洁清晰，易于服务器或终端解析或生成。

进一步地，步骤S400中，系统卡顿检测程序向服务器上报卡顿，包括：

基于预设的应用编程接口，系统卡顿检测程序将运行数据包发送至服务器。

具体地，预先在系统中设有专门传输数据的应用编程接口(ApplicationProgramming Interface，API)，当生成运行数据包后，通过API传输运行数据包至服务器。本实施例选用API接口进行数据的传输，而非常用的log日志形式进行传输，可减少服务器解析的时间，提高获取运行数据的速率。

服务器接收数据包后，服务器对其进行解析，并分析发生卡顿的原因。若发生的原因主要是系统底层的缺陷，可在系统代码中进行优化，并将优化后的系统推送给用户。若发生的原因是应用程序层面，可在应用的代码中进行修正和打补丁，并将修正后的应用或补丁推送给用户。此外，若并非代码层面的原因，而是存储空间不足，还可针对性地提醒用户清理存储空间中不需要的数据。

进一步地，如图11所示，基于上述系统卡顿检测方法，本发明还相应提供了一种智能终端，智能终端包括处理器11、存储器20及显示器30。图10仅示出了智能终端的部分组件，但是应理解的是，并不要求实施所有示出的组件，可以替代的实施更多或者更少的组件。

存储器20在一些实施例中可以是智能终端的内部存储单元，例如智能终端的硬盘或内存。存储器20在另一些实施例中也可以是智能终端的外部存储设备，例如智能终端上配备的插接式硬盘，智能存储卡(Smart Media Card,SMC)，安全数字(Secure Digital,SD)卡，闪存卡(Flash Card)等。进一步地，存储器20还可以既包括智能终端的内部存储单元也包括外部存储设备。存储器20用于存储安装于智能终端的应用软件及各类数据，例如安装智能终端的程序代码等。存储器20还可以用于暂时地存储已经输出或者将要输出的数据。在一实施例中，存储器20上存储有卡顿检测程序40，该卡顿检测程序40可被处理器10所执行，从而实现本申请中系统卡顿检测方法。

处理器10在一些实施例中可以是一中央处理器(Central Processing Unit,CPU)，微处理器或其他数据处理芯片，用于运行存储器20中存储的程序代码或处理数据，例如执行系统卡顿检测方法等。

显示器30在一些实施例中可以是LED显示器、液晶显示器、触控式液晶显示器以及OLED(Organic Light-Emitting Diode，有机发光二极管)触摸器等。显示器30用于显示在智能终端的信息以及用于显示可视化的用户界面。智能终端的部件10-30通过系统总线相互通信。

在一实施例中，当处理器10执行存储器20中卡顿检测程序40时实现以下步骤：

监测事件处理进程；

当监测到事件处理进程处理事件时，生成事件的处理时间；

判断处理时间是否满足预设的卡顿条件；

若处理时间满足卡顿条件，则向服务器上报卡顿。

其中，事件处理进程包括系统处理进程和应用处理进程；

其中，系统处理进程用于接收事件，对事件进行加工后生成事件信息，并将事件信息发送至应用处理进程；

应用处理进程用于根据事件信息执行事件，并将执行结果反馈至系统处理进程。

其中，当监测到事件处理进程处理事件时，生成事件的处理时间，包括：

当监测到系统处理进程处理事件时，记录系统处理时刻；

当监测到应用处理进程处理事件时，记录应用处理时刻；

计算系统处理时刻内多个时刻的差值和应用处理时刻内多个时刻的差值，生成事件的处理时间。

其中，当监测到系统处理进程处理事件时，记录系统处理时刻，包括：

当监测到系统处理进程接收事件时，记录当前的时刻并作为系统第一开始时刻；

当监测到系统处理进程对事件进行加工后生成事件信息时，记录开始加工的时刻和生成事件信息的时刻，并分别作为系统第二开始时刻和系统第二结束时刻；

当监测到系统处理进程将事件信息发送至应用处理进程时，记录当前的时刻并作为系统第一结束时刻。

其中，当监测到应用处理进程处理事件时，记录应用处理时刻，包括：

当监测到应用处理进程接收事件信息时，记录当前的时刻并作为应用第一开始时刻；

当监测到应用处理进程根据事件信息执行事件时，记录开始执行的时刻和执行结束的时刻，并分别作为应用第二开始时刻和应用第二结束时刻；

当监测到应用处理进程将执行结果发送至系统处理进程时，记录当前的时刻并作为应用第一结束时刻。

其中，计算系统处理时刻内多个时刻的差值和应用处理时刻内多个时刻的差值，生成事件的处理时间，包括：

计算系统第一开始时刻和系统第一结束时刻的差值，得到系统第一处理时间；

计算系统第二开始时刻和系统第二结束时刻的差值，得到系统第二处理时间；

计算应用第一开始时刻和应用第一结束时刻的差值，得到应用第一处理时间；

计算应用第二开始时刻和应用第二结束时刻的差值，得到应用第二处理时间；其中，系统第一处理时间、系统第二处理时间、应用第一处理时间和应用第二处理时间为事件的处理时间。

其中，卡顿条件包括服务器根据智能终端的机型信息下发的处理时间阈值，判断处理时间是否满足预设的卡顿条件，包括：

判断处理时间是否大于处理时间阈值；

若处理时间大于处理时间阈值，则确定处理时间满足卡顿条件。

其中，向服务器上报卡顿之前，还包括：

获取当前的运行数据；

对运行数据进行封装，生成运行数据包；

向服务器上报卡顿，包括：

基于预设的应用编程接口，将运行数据包发送至服务器。

其中，监测事件处理进程之前，包括：

获取智能终端的机型信息，并将机型信息发送至服务器；

接收服务器根据机型信息返回的参考条件；

判断参考条件与卡顿条件是否存在差异；

若存在，则根据参考条件，对卡顿条件进行更新

本发明还提供一种存储介质，其中，存储介质存储有卡顿检测程序，卡顿检测程序被处理器执行时实现如上系统卡顿检测方法的步骤。

综上，本发明提供一种系统卡顿检测方法、智能终端及存储介质，方法包括：监测事件处理进程；当监测到事件处理进程处理事件时，生成事件的处理时间；判断处理时间是否满足预设的卡顿条件；若处理时间满足卡顿条件，则向服务器上报卡顿。本发明能够准确判断卡顿发生的真正原因，并以此对系统或应用进行优化。

当然，本领域普通技术人员可以理解实现上述实施例方法中的全部或部分流程，是可以通过计算机程序来指令相关硬件(如处理器，控制器等)来完成，程序可存储于一计算机可读取的存储介质中，程序在执行时可包括如上述各方法实施例的流程。其中存储介质可为存储器、磁碟、光盘等。

应当理解的是，本发明的应用不限于上述的举例，对本领域普通技术人员来说，可以根据上述说明加以改进或变换，所有这些改进和变换都应属于本发明所附权利要求的保护范围。

Claims (11)

1.一种系统卡顿检测方法，其特征在于，包括：

监测事件处理进程；

当监测到所述事件处理进程处理事件时，生成所述事件的处理时间；

判断所述处理时间是否满足预设的卡顿条件；

若所述处理时间满足所述卡顿条件，则向服务器上报卡顿。

2.根据权利要求1所述的方法，其特征在于，所述事件处理进程包括系统处理进程和应用处理进程；

其中，所述系统处理进程用于接收所述事件，对所述事件进行加工后生成事件信息，并将所述事件信息发送至所述应用处理进程；

所述应用处理进程用于根据所述事件信息执行所述事件，并将执行结果反馈至所述系统处理进程。

3.根据权利要求2所述的方法，其特征在于，所述当监测到所述事件处理进程处理事件时，生成所述事件的处理时间，包括：

当监测到所述系统处理进程处理所述事件时，记录所述系统处理时刻；

当监测到所述应用处理进程处理所述事件时，记录所述应用处理时刻；

计算所述系统处理时刻内多个时刻的差值和所述应用处理时刻内多个时刻的差值，生成所述事件的处理时间。

4.根据权利要求3所述的方法，其特征在于，所述当监测到所述系统处理进程处理所述事件时，记录所述系统处理时刻，包括：

当监测到所述系统处理进程接收所述事件时，记录当前的时刻并作为系统第一开始时刻；

当监测到所述系统处理进程对所述事件进行加工后生成事件信息时，记录开始加工的时刻和生成事件信息的时刻，并分别作为系统第二开始时刻和系统第二结束时刻；

当监测到所述系统处理进程将所述事件信息发送至所述应用处理进程时，记录当前的时刻并作为系统第一结束时刻。

5.根据权利要求4所述的方法，其特征在于，所述当监测到所述应用处理进程处理所述事件时，记录所述应用处理时刻，包括：

当监测到所述应用处理进程接收所述事件信息时，记录当前的时刻并作为应用第一开始时刻；

当监测到所述应用处理进程根据所述事件信息执行所述事件时，记录开始执行的时刻和执行结束的时刻，并分别作为应用第二开始时刻和应用第二结束时刻；

当监测到所述应用处理进程将所述执行结果发送至所述系统处理进程时，记录当前的时刻并作为应用第一结束时刻。

6.根据权利要求5所述的方法，其特征在于，所述计算所述系统处理时刻内多个时刻的差值和所述应用处理时刻内多个时刻的差值，生成所述事件的处理时间，包括：

计算所述系统第一开始时刻和所述系统第一结束时刻的差值，得到系统第一处理时间；

计算所述系统第二开始时刻和所述系统第二结束时刻的差值，得到系统第二处理时间；

计算所述应用第一开始时刻和所述应用第一结束时刻的差值，得到应用第一处理时间；

计算所述应用第二开始时刻和所述应用第二结束时刻的差值，得到应用第二处理时间；其中，所述系统第一处理时间、所述系统第二处理时间、所述应用第一处理时间和所述应用第二处理时间为所述事件的处理时间。

7.根据权利要求1所述的方法，其特征在于，所述卡顿条件包括服务器根据智能终端的机型信息下发的处理时间阈值，所述判断所述处理时间是否满足预设的卡顿条件，包括：

判断所述处理时间是否大于所述处理时间阈值；

若所述处理时间大于所述处理时间阈值，则确定所述处理时间满足所述卡顿条件。

8.根据权利要求1所述的方法，其特征在于，所述向服务器上报卡顿之前，所述方法还包括：

获取当前的运行数据；

对所述运行数据进行封装，生成运行数据包；

所述向服务器上报卡顿，包括：

基于预设的应用编程接口，将所述运行数据包发送至所述服务器。

9.根据权利要求1-8任一项所述的方法，其特征在于，所述监测事件处理进程之前，还包括：

获取智能终端的机型信息，并将所述机型信息发送至所述服务器；

接收所述服务器根据所述机型信息返回的参考条件；

判断所述参考条件与所述卡顿条件是否存在差异；

若存在，则根据所述参考条件，对所述卡顿条件进行更新。

10.一种智能终端，其特征在于，所述智能终端包括：存储器、处理器及存储在所述存储器上并可在所述处理器上运行的卡顿检测程序，所述卡顿检测程序被所述处理器执行时实现如权利要求1-9任一项所述的系统卡顿检测方法的步骤。

11.一种存储介质，其特征在于，所述存储介质存储有卡顿检测程序，所述卡顿检测程序被处理器执行时实现如权利要求1-9任一项所述的系统卡顿检测方法的步骤。

Images