CN109074303A - 一种卡顿检测方法及装置 - Google Patents

Abstract

本申请的实施例提供一种卡顿检测方法及装置，涉及通信技术领域，可检测应用运行时发生卡顿的具体环节，以便准确定位卡顿原因，从而降低发生死机现象的几率提高用户体验。该方法包括：当检测到对目标应用的触发操作时，终端执行与该触发操作对应的目标任务；终端记录从生成该目标任务到开始执行该目标任务所花费的第一时长，以及执行该目标任务所花费的第二时长；终端通过比较第一时长与预设的第一参考值的大小，以及比较第二时长与预设的第二参考值的大小，确定发生卡顿的位置位于执行该目标任务之前的其他任务的过程中或者位于执行该目标任务的过程中。

Description

一种卡顿检测方法及装置

技术领域

本申请实施例涉及通信技术领域，尤其涉及一种卡顿检测方法及装置。

背景技术

目前，用户对手机、可穿戴设备以及平板电脑等终端中应用运行时的流畅度要求越来越高。而随着终端实现的功能越来越多，应用在运行时占用的资源越来越碎片化，导致用户在使用终端时会出现卡顿的现象，极大地影响了用户体验。

通常，终端可以通过看门狗(Watchdog)机制或应用程序未响应(Application Notresponding，ANR)机制来监控终端内是否出现卡顿。示例性的，如果在预设时间内没有收到应用的响应消息，终端可向用户提示当前应用未响应，用户可以选择继续等待或者强制关闭该应用。

那么，如果用户选择强制关闭该应用，则终端正在执行的该应用的所有场景将会丢失，用户体验较差。如果用户选择继续等待，则终端将会继续停留在发生卡顿的界面，甚至发生死机现象，用户体验感较差通常，终端可以通过看门狗(Watchdog)机制或应用程序未响应(Application Not responding，ANR)机制来监控终端内是否出现卡顿。示例性的，如果在预设时间内没有收到应用的响应消息，终端可向用户提示当前应用未响应，用户可以选择继续等待或者强制关闭该应用。

那么，如果用户选择强制关闭该应用，则终端正在执行的该应用的所有场景将会丢失，用户体验较差。如果用户选择继续等待，则终端将会继续停留在发生卡顿的界面，甚至发生死机现象，用户体验感较差。

发明内容

本申请的实施例提供一种卡顿检测方法及装置，可检测应用运行时发生卡顿的具体环节，以便准确定位卡顿原因，从而降低发生卡顿或死机现象的几率提高用户体验。

为达到上述目的，本申请的实施例采用如下技术方案：

第一方面，本申请实施例提供一种卡顿检测方法，包括：当检测到对目标应用的触发操作时，终端执行与该触发操作对应的目标任务；终端记录从生成该目标任务到开始执行该目标任务所花费的第一时长，以及执行该目标任务所花费的第二时长；终端通过比较第一时长与预设的第一参考值的大小，以及比较第二时长与预设的第二参考值的大小，确定发生卡顿的位置位于执行该目标任务之前的其他任务的过程中或者位于执行该目标任务的过程中。

可以看出，通过获取目标应用的目标任务在等待执行时的第一时长和在实际执行时的第二时长，可以检测出运行该目标应用的目标任务时发生卡顿的具体环节，例如，该卡顿发生在任务执行过程中，或者发生在任务等待执行的过程中。这样，根据发生卡顿的具体环节可以有针对性的对终端进行性能优化，从而降低终端发生卡顿或死机现象的几率，同时可提高用户体验。

在一种可能的设计方法中，终端通过比较第一时长与预设的第一参考值的大小，以及比较第二时长与预设的第二参考值的大小，确定发生卡顿的位置位于执行该目标任务之前的其他任务的过程中或者位于执行该目标任务的过程中，包括：当第一时长大于第一参考值时，说明上述目标任务在目标应用的任务队列中等待的时间过长，造成用户对目标应用执行的触发操作迟迟得不到响应，因此，终端可确定发生卡顿的位置位于执行该目标任务之前的其他任务的过程中；当第二时长大于第二参考值时，说明终端在执行上述目标任务时花费的时间过长，造成用户对目标应用执行的触发操作迟迟得不到响应，因此，终端可确定发生卡顿的位置位于执行该目标任务的过程中。

在一种可能的设计方法中，在终端确定发生卡顿的位置位于执行该目标任务之前的其他任务的过程中之后，还包括：当再次检测到对该目标应用的触发操作时，终端将位于当前目标任务之前的至少一个任务作为子线程进行分流处理，从而加快该目标任务的处理速度，避免在相同的应用场景下再次出现卡顿现象。

在一种可能的设计方法中，在终端确定发生卡顿的位置位于执行该目标任务之前的其他任务的过程中之后，还包括：当再次检测到对该目标应用的触发操作时，终端将位于当前目标任务之前的至少一个任务作为等待关闭的候选目标任务；当获取到用户选择的候选目标任务时，终端删除该用户选择的候选目标任务。这样，终端便无需执行这些被删除的候选任务，使得与上述触发操作对应的目标任务可以尽快的移动至任务队列的队头，从而加快该目标任务的处理速度，避免在相同的应用场景下再次出现卡顿现象。

在一种可能的设计方法中，在终端确定发生卡顿的位置位于执行该目标任务之前的其他任务的过程中之后，还包括：当再次检测到用户对该目标应用的触发操作时，终端删除当前目标应用生成的所有任务，并重新启动该目标应用。

在一种可能的设计方法中，在终端确定发生卡顿的位置位于执行该目标任务的过程中之后，还包括：当再次检测到用户对该目标应用的触发操作时，终端增加执行该目标任务时的运行资源，从而加快该目标任务在任务队列中的处理速度，避免在相同的应用场景下再次出现卡顿现象。

在一种可能的设计方法中，在终端记录从生成该目标任务到开始执行该目标任务所花费的第一时长，以及执行该目标任务所花费的第二时长之后，还包括：终端将第一时长和第二时长发送给服务器，由服务器根据终端上报的第一时长和第二时长，刷新上述第一参考值和第二参考值。

在一种可能的设计方法中，该方法还包括：终端从服务器获取第一参考值和第二参考值，第一参考值用于指示该目标任务等待执行时所花费时长的中位值，第二参考值用于指示执行该目标任务时所花费时长的中位值。

在一种可能的设计方法中，在确定发生卡顿的位置位于执行该目标任务之前的其他任务的过程中或者位于执行该目标任务的过程中之后，还包括：终端在显示界面中向用户提示发生卡顿的位置位于执行该目标任务之前的其他任务的过程中或者位于执行该目标任务的过程中，以便用户获知发生卡顿的具体原因，避免用户误以为终端此时发生卡死现象。

第二方面，本申请实施例提供一种卡顿检测方法，包括：服务器获取第一终端发送的第一时长和第二时长，第一时长用于指示第一终端从生成目标任务到开始执行该目标任务所花费的时长，第二时长用于指示第一终端执行该目标任务所花费的时长，该目标任务为响应于对目标应用的触发操作生成的；该服务器根据第一时长，确定等待执行该目标任务时的第一参考值；该服务器根据第二时长，确定执行该目标任务时的第二参考值。

在一种可能的设计方法中，该方法还包括：该服务器获取第二终端发送的第三时长和第四时长，该第三时长用于指示第二终端从生成目标任务到开始执行该目标任务所花费的时长，该第四时长用于指示第二终端执行该目标任务所花费的时长，该目标任务为响应于对目标应用的触发操作生成的；该服务器根据该第三时长更新第一参考值；该服务器根据该第四时长更新第二参考值。

在一种可能的设计方法中，该方法还包括：该服务器将第一参考值和第二参考值发送给第一终端。

在一种可能的设计方法中，在该服务器将第一参考值和第二参考值发送给第一终端之后，还包括：服务器获取第一终端发送的第五时长和第六时长，该第五时长用于指示第一终端从再次生成目标任务到开始执行该目标任务所花费的时长，第二时长用于指示第一终端再次执行该目标任务所花费的时长，该目标任务为响应于对目标应用的触发操作生成的；该服务器根据该第五时长更新第一参考值；该服务器根据该第六时长更新第二参考值。

第三方面，本申请实施例提供一种终端，包括：执行单元，用于：当检测到对目标应用的触发操作时，执行与该触发操作对应的目标任务；记录单元，用于：记录从生成该目标任务到开始执行该目标任务所花费的第一时长，以及执行该目标任务所花费的第二时长；确定单元，用于：通过比较第一时长与预设的第一参考值的大小，以及比较第二时长与预设的第二参考值的大小，确定发生卡顿的位置位于执行该目标任务之前的其他任务的过程中或者位于执行该目标任务的过程中。

在一种可能的设计方法中，该确定单元，具体用于：当第一时长大于第一参考值时，确定发生卡顿的位置位于执行该目标任务之前的其他任务的过程中；当第二时长大于第二参考值时，确定发生卡顿的位置位于执行该目标任务的过程中。

在一种可能的设计方法中，该执行单元，还用于：当再次检测到对该目标应用的触发操作时，将位于当前目标任务之前的至少一个任务作为子线程进行分流处理。

在一种可能的设计方法中，该执行单元，还用于：当再次检测到对该目标应用的触发操作时，将位于当前目标任务之前的至少一个任务作为等待关闭的候选目标任务；当获取到用户选择的候选目标任务时，删除该用户选择的候选目标任务。

在一种可能的设计方法中，该执行单元，还用于：当再次检测到用户对该目标应用的触发操作时，删除当前目标应用生成的所有任务，并重新启动该目标应用。

在一种可能的设计方法中，该执行单元，还用于：当再次检测到对该目标应用的触发操作时，增加执行该目标任务时的运行资源。

在一种可能的设计方法中，终端还包括：发送单元，用于：将第一时长和第二时长发送给服务器。

在一种可能的设计方法中，终端还包括：获取单元，用于：从服务器获取第一参考值和第二参考值，第一参考值用于指示该目标任务等待执行时所花费时长的中位值，第二参考值用于指示执行该目标任务时所花费时长的中位值。

在一种可能的设计方法中，终端还包括：显示单元，用于：在显示界面中向用户提示发生卡顿的位置位于执行该目标任务之前的其他任务的过程中或者位于执行该目标任务的过程中。

第四方面，本申请实施例提供一种服务器，包括：获取单元，用于：获取第一终端发送的第一时长和第二时长，第一时长用于指示第一终端从生成目标任务到开始执行该目标任务所花费的时长，第二时长用于指示第一终端执行该目标任务所花费的时长，该目标任务为响应于对目标应用的触发操作生成的；确定单元，用于：根据第一时长，确定等待执行该目标任务时的第一参考值；根据第二时长，确定执行该目标任务时的第二参考值。

在一种可能的设计方法中，该获取单元，还用于：获取第二终端发送的第三时长和第四时长，该第三时长用于指示第二终端从生成目标任务到开始执行该目标任务所花费的时长，该第四时长用于指示第二终端执行该目标任务所花费的时长，该目标任务为响应于对目标应用的触发操作生成的；该确定单元，还用于：根据该第三时长更新第一参考值；根据该第四时长更新第二参考值。

在一种可能的设计方法中，该服务器还包括发送单元，用于：将第一参考值和第二参考值发送给第一终端。

在一种可能的设计方法中，该获取单元，还用于：获取第一终端发送的第五时长和第六时长，该第五时长用于指示第一终端从再次生成目标任务到开始执行该目标任务所花费的时长，第二时长用于指示第一终端再次执行该目标任务所花费的时长，该目标任务为响应于对目标应用的触发操作生成的；该确定单元，还用于：根据该第五时长更新第一参考值；根据该第六时长更新第二参考值。

第五方面，本申请实施例提供一种终端，包括：通过总线连接的输入设备、处理器、显示器以及通信接口，其中，该输入设备，用于：检测对目标应用的触发操作；该处理器，用于：执行与该触发操作对应的目标任务；记录从生成该目标任务到开始执行该目标任务所花费的第一时长，以及执行该目标任务所花费的第二时长；通过比较第一时长与预设的第一参考值的大小，以及比较第二时长与预设的第二参考值的大小，确定发生卡顿的位置位于执行该目标任务之前的其他任务的过程中或者位于执行该目标任务的过程中。

在一种可能的设计方法中，该处理器，具体用于：当第一时长大于第一参考值时，确定发生卡顿的位置位于执行该目标任务之前的其他任务的过程中；当第二时长大于第二参考值时，确定发生卡顿的位置位于执行该目标任务的过程中。

在一种可能的设计方法中，该输入设备，还用于：再次检测对该目标应用的触发操作；该处理器，还用于：将位于当前目标任务之前的至少一个任务作为子线程进行分流处理。

在一种可能的设计方法中，该输入设备，还用于：再次检测对该目标应用的触发操作；获取用户选择的候选目标任务；该处理器，还用于：将位于当前目标任务之前的至少一个任务作为等待关闭的候选目标任务；删除该用户选择的候选目标任务。

在一种可能的设计方法中，该输入设备，还用于：再次检测对该目标应用的触发操作；该处理器，还用于：删除当前目标应用生成的所有任务，并重新启动该目标应用。

在一种可能的设计方法中，该输入设备，还用于：再次检测对该目标应用的触发操作；该处理器，还用于：增加执行该目标任务时的运行资源。

在一种可能的设计方法中，该通信接口，用于：将第一时长和第二时长发送给服务器。

在一种可能的设计方法中，该通信接口，还用于：从服务器获取第一参考值和第二参考值，第一参考值用于指示该目标任务等待执行时所花费时长的中位值，第二参考值用于指示执行该目标任务时所花费时长的中位值。

在一种可能的设计方法中，该显示器，用于：在显示界面中向用户提示发生卡顿的位置位于执行该目标任务之前的其他任务的过程中或者位于执行该目标任务的过程中。

第六方面，本申请实施例提供一种服务器，包括：通过总线连接的处理器和通信接口，其中，该通信接口，用于：获取第一终端发送的第一时长和第二时长，第一时长用于指示第一终端从生成目标任务到开始执行该目标任务所花费的时长，第二时长用于指示第一终端执行该目标任务所花费的时长，该目标任务为响应于对目标应用的触发操作生成的；该处理器，用于：根据第一时长，确定等待执行该目标任务时的第一参考值；根据第二时长，确定执行该目标任务时的第二参考值。

在一种可能的设计方法中，该通信接口，还用于：获取第二终端发送的第三时长和第四时长，该第三时长用于指示第二终端从生成目标任务到开始执行该目标任务所花费的时长，该第四时长用于指示第二终端执行该目标任务所花费的时长，该目标任务为响应于对目标应用的触发操作生成的；该处理器，还用于：根据该第三时长更新第一参考值；根据该第四时长更新第二参考值。

在一种可能的设计方法中，该通信接口，还用于：将第一参考值和第二参考值发送给第一终端。

在一种可能的设计方法中，该通信接口，还用于：获取第一终端发送的第五时长和第六时长，该第五时长用于指示第一终端从再次生成目标任务到开始执行该目标任务所花费的时长，第二时长用于指示第一终端再次执行该目标任务所花费的时长，该目标任务为响应于对目标应用的触发操作生成的；该处理器，还用于：根据该第五时长更新第一参考值；根据该第六时长更新第二参考值。

第七方面，本申请实施例提供一种显示在终端的触摸屏中的图形用户界面(Graphical User Interface，GUI)，所述图形用户界面包括：在终端的触摸屏中显示第一GUI；当检测到用户在触摸屏上对目标应用触发的第一手势时，在触摸屏中显示第二GUI，该第二GUI中包括用于向用户提示发生卡顿的位置的第一界面元素。

在一种可能的设计方法中，上述第二GUI中还包括用于指示卡顿的处理进度的第二界面元素。

在一种可能的设计方法中，上述第二GUI中还包括用于提示进行卡顿优化的第三界面元素。

第八方面，本申请的实施例提供一种终端，包括：处理器、存储器、总线和通信接口；该存储器用于存储计算机执行指令，该处理器与该存储器通过该总线连接，当终端运行时，该处理器执行该存储器存储的该计算机执行指令，以使终端执行上述任一项卡顿检测方法。

第九方面，本申请的实施例提供一种服务器，包括：处理器、存储器、总线和通信接口；该存储器用于存储计算机执行指令，该处理器与该存储器通过该总线连接，当服务器运行时，该处理器执行该存储器存储的该计算机执行指令，以使服务器执行上述任一项卡顿检测方法。

第十方面，本申请实施例提供一种计算机可读存储介质，该计算机可读存储介质中存储有指令，当该指令在上述任一项终端上运行时，使得终端执行上述任一项卡顿检测方法。

第十一方面，本申请实施例提供一种计算机可读存储介质，该计算机可读存储介质中存储有指令，当该指令在上述任一项服务器上运行时，使得服务器执行上述任一项卡顿检测方法。

第十二方面，本申请实施例提供一种包含指令的计算机程序产品，当其在上述任一项终端上运行时，使得终端执行上述任一项卡顿检测方法。

第十三方面，本申请实施例提供一种包含指令的计算机程序产品，当其在上述任一项服务器上运行时，使得服务器执行上述任一项卡顿检测方法。

本申请的实施例中，上述终端或服务器的名字对设备本身不构成限定，在实际实现中，这些设备可以以其他名称出现。只要各个设备的功能和本申请的实施例类似，即属于本申请权利要求及其等同技术的范围之内。

另外，第二方面至第十三方面中任一种设计方式所带来的技术效果可参见上述第一方面中不同设计方法所带来的技术效果，此处不再赘述。

附图说明

图1为本申请实施例提供的一种终端的结构示意图一；

图2为本申请实施例提供的一种安卓操作***架构示意图；

图3为本申请实施例提供的一种卡顿检测方法的应用场景示意图一；

图4为本申请实施例提供的一种卡顿检测方法的流程示意图；

图5为本申请实施例提供的一种卡顿检测方法的应用场景示意图二；

图6为本申请实施例提供的一种卡顿检测方法的应用场景示意图三；

图7为本申请实施例提供的一种卡顿检测方法的应用场景示意图四；

图8为本申请实施例提供的一种卡顿检测方法的应用场景示意图五；

图9为本申请实施例提供的一种卡顿检测方法的应用场景示意图六；

图10为本申请实施例提供的一种卡顿检测方法的应用场景示意图七；

图11为本申请实施例提供的一种卡顿检测方法的应用场景示意图八；

图12为本申请实施例提供的一种卡顿检测方法的应用场景示意图九；

图13为本申请实施例提供的一种卡顿检测方法的应用场景示意图十；

图14为本申请实施例提供的一种卡顿检测方法的应用场景示意图十一；

图15为本申请实施例提供的一种卡顿检测方法的应用场景示意图十二；

图16为本申请实施例提供的一种终端的结构示意图二；

图17为本申请实施例提供的一种服务器的结构示意图一；

图18为本申请实施例提供的一种终端的结构示意图三；

图19为本申请实施例提供的一种服务器的结构示意图二。

具体实施方式

以下，术语“第一”、“第二”仅用于描述目的，而不能理解为指示或暗示相对重要性或者隐含指明所指示的技术特征的数量。由此，限定有“第一”、“第二”的特征可以明示或者隐含地包括一个或者更多个该特征。在本申请实施例的描述中，除非另有说明，“多个”的含义是两个或两个以上。

本申请的实施例提供一种卡顿检测方法，可应用于手机、可穿戴设备、AR(增强现实)\VR(虚拟现实)设备、平板电脑、笔记本电脑、UMPC(超级移动个人计算机)、上网本、PDA(个人数字助理)等可以运行APP的任意终端，本申请实施例对此不作任何限制。

如图1所示，本申请实施例中的终端可以为手机100。下面以手机100为例对实施例进行具体说明。应该理解的是，图示手机100仅是终端的一个范例，并且手机100可以具有比图中所示出的更多的或者更少的部件，可以组合两个或更多的部件，或者可以具有不同的部件配置。

如图1所示，手机100具体可以包括：处理器101、射频(RF)电路102、存储器103、触摸屏104、蓝牙装置105、一个或多个传感器106、Wi-Fi装置107、定位装置108、音频电路109、外设接口110以及电源***111等部件。这些部件可通过一根或多根通信总线或信号线(图1中未示出)进行通信。本领域技术人员可以理解，图1中示出的硬件结构并不构成对手机的限定，手机100可以包括比图示更多或更少的部件，或者组合某些部件，或者不同的部件布置。

下面结合图1对手机100的各个部件进行具体的介绍：

处理器101是手机100的控制中心，利用各种接口和线路连接手机100的各个部分，通过运行或执行存储在存储器103内的应用程序(以下可以简称App)，以及调用存储在存储器103内的数据，执行手机100的各种功能和处理数据。在一些实施例中，处理器101可包括一个或多个处理单元；举例来说，处理器101可以是华为技术有限公司制造的麒麟960芯片。

射频电路102可用于在收发信息或通话过程中，无线信号的接收和发送。特别地，射频电路102可以将基站的下行数据接收后，给处理器101处理；另外，将涉及上行的数据发送给基站。通常，射频电路包括但不限于天线、至少一个放大器、收发信机、耦合器、低噪声放大器、双工器等。此外，射频电路102还可以通过无线通信和其他设备通信。所述无线通信可以使用任一通信标准或协议，包括但不限于全球移动通讯***、通用分组无线服务、码分多址、宽带码分多址、长期演进、电子邮件、短消息服务等。

存储器103用于存储应用程序以及数据，处理器101通过运行存储在存储器103的应用程序以及数据，执行手机100的各种功能以及数据处理。存储器103主要包括存储程序区以及存储数据区，其中，存储程序区可存储操作***、至少一个功能所需的应用程序(比如声音播放功能、图像播放功能等)；存储数据区可以存储根据使用手机100时所创建的数据(比如音频数据、电话本等)。此外，存储器103可以包括高速随机存取存储器，还可以包括非易失存储器，例如磁盘存储器件、闪存器件或其他易失性固态存储器件等。存储器103可以存储各种操作***，例如，苹果公司所开发的iOS操作***，谷歌公司所开发的Android操作***等。

触摸屏104可以包括触控板104-1和显示器104-2。其中，触控板104-1可采集手机100的用户在其上或附近的触摸事件(比如用户使用手指、触控笔等任何适合的物体在触控板104-1上或在触控板104-1附近的操作)，并将采集到的触摸信息发送给其他器件例如处理器101。虽然在图1中，触控板104-1与显示屏104-2是作为两个独立的部件来实现手机100的输入和输出功能，但是在某些实施例中，可以将触控板104-1与显示屏104-2集成而实现手机100的输入和输出功能。可以理解的是，触摸屏104是由多层的材料堆叠而成，本申请实施例中只展示出了触控板(层)和显示屏(层)，其他层在本申请实施例中不予记载。另外，在本申请其他一些实施例中，触控板104-1可以覆盖在显示器104-2之上，并且触控板104-1的尺寸大于显示屏104-2的尺寸，使得显示屏104-2全部覆盖在触控板104-1下面，或者，上述触控板104-1可以以全面板的形式配置在手机100的正面，也即用户在手机100正面的触摸均能被手机感知，这样就可以实现手机正面的全触控体验。在其他一些实施例中，触控板104-1以全面板的形式配置在手机100的正面，显示屏104-2也可以以全面板的形式配置在手机100的正面，这样在手机的正面就能够实现无边框的结构。

在本申请实施例中，手机100还可以具有指纹识别功能。例如，可以在手机100的背面(例如后置摄像头的下方)配置指纹识别器112，或者在手机100的正面(例如触摸屏104的下方)配置指纹识别器112。又例如，可以在触摸屏104中配置指纹采集器件112来实现指纹识别功能，即指纹采集器件112可以与触摸屏104集成在一起来实现手机100的指纹识别功能。在这种情况下，该指纹采集器件112配置在触摸屏104中，可以是触摸屏104的一部分，也可以以其他方式配置在触摸屏104中。本申请实施例中的指纹采集器件112的主要部件是指纹传感器，该指纹传感器可以采用任何类型的感测技术，包括但不限于光学式、电容式、压电式或超声波传感技术等。

在本申请实施例中，手机100还可以包括蓝牙装置105，用于实现手机100与其他短距离的终端(例如手机、智能手表等)之间的数据交换。本申请实施例中的蓝牙装置可以是集成电路或者蓝牙芯片等。

Wi-Fi装置107，用于为手机100提供遵循Wi-Fi相关标准协议的网络接入，手机100可以通过Wi-Fi装置107接入到Wi-Fi接入点，进而帮助用户收发电子邮件、浏览网页和访问流媒体等，它为用户提供了无线的宽带互联网访问。在其他一些实施例中，该Wi-Fi装置107也可以作为Wi-Fi无线接入点，可以为其他终端提供Wi-Fi网络接入。

手机100还可以包括至少一种传感器106，比如光传感器、运动传感器以及其他传感器。具体地，光传感器可包括环境光传感器及接近传感器，其中，环境光传感器可根据环境光线的明暗来调节触摸屏104的显示器的亮度，接近传感器可在手机100移动到耳边时，关闭显示器的电源。作为运动传感器的一种，加速计传感器可检测各个方向上(一般为三轴)加速度的大小，静止时可检测出重力的大小及方向，可用于识别手机姿态的应用(比如横竖屏切换、相关游戏、磁力计姿态校准)、振动识别相关功能(比如计步器、敲击)等；至于手机100还可配置的陀螺仪、气压计、湿度计、温度计、红外线传感器等其他传感器，在此不再赘述。

定位装置108，用于为手机100提供地理位置。可以理解的是，该定位装置108具体可以是全球定位***(GPS)或北斗卫星导航***、俄罗斯GLONASS等定位***的接收器。定位装置108在接收到上述定位***发送的地理位置后，将该信息发送给处理器101进行处理，或者发送给存储器103进行保存。在另外的一些实施例中，该定位装置108还可以是辅助全球卫星定位***(AGPS)的接收器，AGPS***通过作为辅助服务器来协助定位装置108完成测距和定位服务，在这种情况下，辅助定位服务器通过无线通信网络与终端例如手机100的定位装置108(即GPS接收器)通信而提供定位协助。在另外的一些实施例中，该定位装置108也可以是基于Wi-Fi接入点的定位技术。由于每一个Wi-Fi接入点都有一个全球唯一的MAC地址，终端在开启Wi-Fi的情况下即可扫描并收集周围的Wi-Fi接入点的广播信号，因此可以获取到Wi-Fi接入点广播出来的MAC地址；终端将这些能够标示Wi-Fi接入点的数据(例如MAC地址)通过无线通信网络发送给位置服务器，由位置服务器检索出每一个Wi-Fi接入点的地理位置，并结合Wi-Fi广播信号的强弱程度，计算出该终端的地理位置并发送到该终端的定位装置108中。

音频电路109、扬声器113、麦克风114可提供用户与手机100之间的音频接口。音频电路109可将接收到的音频数据转换后的电信号，传输到扬声器113，由扬声器113转换为声音信号输出；另一方面，麦克风114将收集的声音信号转换为电信号，由音频电路109接收后转换为音频数据，再将音频数据输出至RF电路102以发送给比如另一手机，或者将音频数据输出至存储器103以便进一步处理。

外设接口110，用于为外部的输入/输出设备(例如键盘、鼠标、外接显示器、外部存储器、用户识别模块卡等)提供各种接口。例如通过通用串行总线(USB)接口与鼠标连接，通过用户识别模块卡卡槽上的金属触点与电信运营商提供的用户识别模块卡(SIM)卡进行连接。外设接口110可以被用来将上述外部的输入/输出***设备耦接到处理器101和存储器103。

手机100还可以包括给各个部件供电的电源装置111(比如电池和电源管理芯片)，电池可以通过电源管理芯片与处理器101逻辑相连，从而通过电源装置111实现管理充电、放电、以及功耗管理等功能。

尽管图1未示出，手机100还可以包括摄像头(前置摄像头和/或后置摄像头)、闪光灯、微型投影装置、近场通信(NFC)装置等，在此不再赘述。

进一步地，上述手机100中可以运行在Android或IOS等操作***中，本申请实施例对此不作任何限制。

以Android操作***为例，如图2所示，Android操作***可以划分为四层，从高层到低层分别是应用程序层201(即APP层)、应用程序框架层202(即Framework层)、***运行库层203(即Libraries层)和Linux内核层204。

其中，Linux内核层204可用于控制手机100的安全(Security)，存储器管理(Memory Management)，程序管理(Process Management)，网络堆栈(Network Stack)，驱动程序模型(Driver Model)等功能。Linux内核层204同时也作为硬件(例如，CPU、网卡以及内存等)和软件栈之间的抽象层，它可隐藏具体硬件细节从而为上层(***运行库层203、应用程序框架层202以及应用程序层201)提供统一的服务。

***运行库层203中包含一些C/C++库，例如，媒体库、***C库以及显示管理库(Surface Manager)等，这些库能被Android***中不同的组件使用，***运行库层203可通过Framework层202为开发人员提供服务。

Framework层202为开发人员提供了一个可以完全访问应用程序所使用的API框架。具体的，Framework层202为开发应用程序提供了非常多的API，通过调用相应的API可以构造满足相关业务需求的APP。

应用程序层201主要包括用java语言编写的运行在虚拟机上的APP，用户在操作APP上的操作界面时，通过调用Framework层202中的相关API，与***运行库层203或Linux内核层204进行交互，实现与该操作界面相对应的功能。

示例性的，如图3所示，手机100的应用程序层201中安装有应用A，当手机100检测到用户点击桌面上应用A的图标这一触发操作时，触发应用A调用Framework层202中的相应API生成一个动作事件(ActionEvent)，该动作事件表示应用A中图标被点击了。进而，如图3所示，Framework层202为处理该动作事件可生成一个或多个目标任务，例如，启动应用A的相关组件、加载广告以及显示首页内容等任务，上述目标任务生成后被送至应用A的任务队列(task queue)中等待处理。

后续，手机100按照先进先出的原则依次执行上述任务队列中的各个任务，当执行完任务队列中位于上述目标任务之前的所有任务后，该目标任务从任务队列的队尾移动至队头。当目标任务位于任务队列的队头时，手机100开始执行该目标任务，从而实现与用户点击应用A的图标这一触发操作对应的应用A的启动过程。

在本申请实施例中，为了确定应用运行时发生卡顿的具体环节，终端可以预先获取到用于判断是否发生卡顿的参考值，例如，该参考值可包括：用于指示一个任务在任务队列中等待执行时所花费的参考时长(即第一参考值)，以及用于指示执行一个任务时所花费的参考时长(即第二参考值)。示例性的，该第一参考值为10ms，该第二参考值为20ms。

那么，终端可以监控上述任务队列中的每个任务在任务队列中等待执行时所花费的实际时长(即第一时长)，以及执行该任务时所花费的实际时长(即第二时长)。这样，通过对比上述第一参考值和上述第一时长，终端可以确定出该任务在任务队列内等待执行时是否发生卡顿，例如，当检测出上述第一时长为15ms(大于第一参考值10ms)时，可确定该任务在任务队列内等待执行时发生卡顿。相应的，通过对比上述第二参考值和上述第二时长，终端可以确定出该任务在实际执行过程中是否发生卡顿，例如，当检测出上述第二时长为25ms(大于第二参考值20ms)时，可确定该任务在执行过程中发生卡顿。

可以看出，本申请实施例提供的卡顿检测方法，通过获取应用运行时生成的各个任务在等待执行时的第一时长和在实际执行时的第二时长，可以检测出该应用运行时发生卡顿的具体环节，例如，该卡顿发生在任务执行过程中，或者发生在任务等待执行的过程中。这样，根据发生卡顿的具体环节可以有针对性的对终端进行性能优化，从而降低终端发生死机现象的几率，同时可提高用户体验。

以下将结合具体实施例详细阐述本申请实施例提供的一种卡顿检测方法，如图4所示，该方法包括：

400、终端从服务器获取第一参考值和第二参考值。

其中，该第一参考值具体可以为服务器根据各个终端上报的某个应用(例如，应用A)生成的任务在任务队列中等待执行时所花费时长的中位值；相应的，第二参考值具体可以为服务器根据各个终端上报的某个应用(例如，应用A)生成的任务在实际执行时所花费时长的中位值。

具体的，如图5所示，本申请实施例提供的卡顿检测方法可应用于图5所示的检测***中，该***中包括服务器51以及与服务器51相连的N个终端52。

示例性的，上述N个终端中每个终端52内都安装有应用A。那么，每个终端在运行应用A时，可以记录应用A生成的每个任务在任务队列中的等待时间T1，以及执行每个任务花费的执行时间T2，进而，将每个任务的等待时间T1和执行时间T2上报给服务器51。当然，终端还可以将每个任务的标识以及应用A的标识(例如应用A的包名)一并发给服务器。

那么，服务器51可以获取到在不同终端52中执行上述每个任务时的等待时间T1和执行时间T2，进而，对于每一个任务，服务器51可以将获取到的所有该任务的等待时间T1的中位值作为上述第一参考值发送给每一个终端52，并将获取到的所有该任务的执行时间T2的中位值作为上述第二参考值发送给每一个终端52。这样，终端可以得到执行应用A时每一个任务所对应的第一参考值和第二参考值。

后续，以应用A的任务1为例，终端52接收到服务器发送的任务1的第一参考值和第二参考值后，可以以该第一参考值为标准，判断应用A的任务1在任务队列中等待时是否发生卡顿，还可以以上述第二参考值为标准，判断应用A的任务1在执行时是否发生卡顿，从而确定出任务1在运行过程中发生卡顿的具体环节。

当然，服务器51也可以根据各个终端52上报的等待时间T1和执行时间T2，使用相应的数学模型或算法计算上述第一参考值和第二参考值，本申请实施例对此不作任何限制。

例如，由于不同设备类型的终端的处理能力不同，因此，终端52在上报上述等待时间T1和执行时间T2时还可以上报自身的设备类型，不同设备类型所对应的等待时间T1和执行时间T2的权值不同。这样，服务器51在计算上述第一参考值和第二参考值时，可以根据每个终端的设备信息将上述N个等待时间T1进行加权平均后得到上述第一参考值，并且，可以根据每个终端的设备信息将上述N个执行时间T2进行加权平均后得到上述第二参考值，从而提高后续定位卡顿位置的准确性。

可以理解的是，上述第一参考值和第二参考值是一个实时更新的过程。也就是说，服务器51可以根据不同的终端52实时上报的等待时间T1和执行时间T2刷新上述第一参考值和第二参考值，并将刷新后的第一参考值和第二参考值发送给终端52。

401、当检测到用户对目标应用的触发操作时，终端生成与该触发操作对应的目标任务。

如图3所示，当终端检测到用户对目标应用(例如应用A)执行的触发操作时，例如，用户点击联系人应用的搜索按钮，可触发应用A调用Framework层202中相应API的生成一个动作事件(ActionEvent)，进而，Framework层202为处理该动作事件会生成一个或多个目标任务，例如，加载本地联系人任务、搜索任务、以及显示搜索结果等任务，上述目标任务生成后被送至应用A的任务队列中等待处理。

其中，上述目标任务具体可以为一个或多个message(消息)对象，在安卓操作***中，可以通过消息处理机制传递相关事件的参数。具体的，当一个应用启动时，终端会开启一个主线程(即UI线程)来管理UI(界面)，监听用户点击等事件。那么，当检测到用户对应用A执行的触发操作时，终端可生成相应的一个或多个message对象作为目标任务送入消息队列(即任务队列)中等待执行，当目标任务出队后，终端便可调用与上述message对象对应的handler对象的handleMessage()方法对其进行处理，即执行该目标任务。

可以理解的是，应用A的任务队列中的任务也可以与其他应用的任务(例如，应用B)的任务队列中的任务相关联。例如，应用A为购物应用，应用B为支付应用，当用户触发应用A中的支付按钮时，如图6所示，应用A可以生成一个刷新支付页面的目标任务1和显示支付结果的目标任务2，并将任务1和任务2送至与应用A对应的任务队列1的队尾。同时，目标任务1的生成可触发应用B生成相应的支付任务，例如，目标任务3，此时，应用B将目标任务3送至与应用B对应的任务队列2的队尾中等待处理。此时，上述目标任务包括应用A的目标任务1和目标任务2，以及应用B的目标任务3。

402、终端记录上述目标任务从进入任务队列到移动至该任务队列的对头所花费的第一时长。

示例性的，终端生成与上述触发操作对应的目标任务后，将该目标任务加入目标应用的任务队列的队尾，如图7中的(a)所示，在目标应用的任务队列中，在目标任务之前还有任务1-任务6共6个待处理的任务。将该目标任务加入目标应用的任务队列的队尾时，终端还可以通过调用函数：getCurrentTime()获取当前的***时间C1，例如，本次getCurrentTime()返回的当前的***时间C1为：21点10分10秒25毫秒。

后续，终端可以按照先进先出的原则继续执行上述任务队列中的各个任务，如图7中的(b)所示，当终端执行完任务队列中位于上述目标任务之前的任务1-任务6后，上述目标任务从任务队列的队尾移动至任务队列的对头，此时，终端可以再次通过调用函数：getCurrentTime()获取当前的***时间C2，例如，本次getCurrentTime()返回的当前的***时间C2为：21点10分10秒45毫秒。

那么，终端根据上述两次获取到的***时间，可以确定出上述目标任务从进入任务队列到移动至该任务队列的对头所花费的第一时长为C2-C1＝20毫秒，该第一时长可以反映出从生成上述目标任务到开始执行该目标任务所花费的时长。

403、当上述目标任务移动至任务队列的对头时，终端记录执行该目标任务所花费的第二时长。

在步骤403中，当上述目标任务移动至任务队列的对头时，终端开始执行上述目标任务，当执行完上述目标任务后，终端会将执行完成该目标任务的响应消息返回给目标应用，此时，可以触发终端可以再次调用函数：getCurrentTime()获取当前的***时间C3，例如，本次getCurrentTime()返回的当前的***时间C3为：21点10分11秒01毫秒。

那么，终端可以确定出执行上述目标任务所花费的第二时长为C3-C2＝26毫秒。

404、终端将上述记录的第一时长和第二时长发送给服务器。

可选的，终端还可以将获取到的上述第一时长作为步骤400中的等待时间T1，将获取到的上述第二时长作为步骤400中的执行时间T2发送给服务器，由服务器刷新上述第一参考值和第二参考值，并将刷新后的第一参考值和第二参考值发送给终端。

后续，终端可以通过比较上述第一时长与第一参考值之间的大小，以及上述第二时长与第二参考值之间的大小，确定运行上述目标任务时是否发生卡顿，如果发生卡顿，则终端可进一步定位发生卡顿的具***置。

当然，终端在发送上述第一时长和第二时长时还可以携带上述目标任务所属的应用的包名，上述目标任务的标识等信息，这样服务器可以以应用的任务为粒度，为不同应用的不同任务确定出对应的第一参考值和第二参考值。

405a、当上述第一时长大于第一参考值时，终端确定发生卡顿的位置位于执行上述目标任务之前的其他任务的过程中。

示例性的，上述第一时长为C2-C1＝20毫秒，而服务器预先发送给终端的上述目标任务的第一参考值为10毫秒，此时，第一时长大于该第一参考值，说明上述目标任务在目标应用的任务队列中等待的时间过长，造成用户对目标应用执行的触发操作迟迟得不到响应。

此时，终端可以确定发生卡顿的原因是因为处理该任务队列中位于目标任务之前的其他任务时花费的时间过长导致的，从而使得终端可以准确的定位出目标应用运行时发生卡顿的具体原因。

另外，当终端检测到上述目标任务在任务队列中等待的时长大于上述第一参考值还未开始执行时，如图8中的(a)所示，终端还可以通过一个提示框向用户提示当前终端正在处理该目标任务。例如，终端可以根据目前任务队列中等待处理的任务的个数计算出用户等待的时间并提示给用户，或者，根据目前任务队列中等待处理的任务的个数计算出完成该目标任务的当前进度并提示给用户。

或者，如图8中的(b)所示，终端还可以通过一个提示框向用户提示发生卡顿的具体原因，请用户耐心等待，避免用户误以为终端此时发生卡死现象。

又或者，如图8中的(c)所示，终端还可以通过一个提示框向用户提示是否对出现的卡顿进行优化，如果用户确认对卡顿进行优化，则终端可继续执行下述实施例中提供的卡顿优化方法。

具体的，为了降低后续用户对该目标应用再次执行上述触发操作时发生卡顿现象的几率，开发人员可以通过在应用的运行代码中***日志(log)的方法获取上述第一时长和第二时长。

例如，如图9中的(a)所示，当终端将上述目标任务加入目标应用的任务队列的队尾时可***log1，log1用于记录将上述目标任务加入目标应用的任务队列的队尾这一动作的***时间C1；如图9中的(b)所示，在终端开始执行上述目标任务之前，可再次***一条日志，例如log2，log2用于记录开始执行上述目标任务的***时间C2；如图9中的(c)所示，当终端执行完上述目标任务后，可再次***一条日志，例如log3，log3用于记录执行完上述目标任务的***时间C3。

这样，开发人员可以通过打印上述log1-log3，便可以确定出上述目标任务从进入任务队列到移动至该任务队列的对头所花费的第一时长C2-C1，以及执行上述目标任务所花费的第二时长C3-C2。进而，通过比较上述第一时长与第一参考值之间的大小，以及上述第二时长与第二参考值之间的大小，开发人员便可以确定运行上述目标任务时发生卡顿的具***置。

例如，当上述第一时长大于该第一参考值时，开发人员可以确定发生卡顿的具体原因是因为任务队列中位于上述目标任务之前的其他任务时花费的时间过长导致的，因此，开发人员可以对图7(a)中位于上述目标任务之前的任务1-任务6的运行代码进行精简，使得用户在后续执行相同的触发操作时，可以提高任务队列中位于上述目标任务之前的其他任务的执行效率，从而减缓卡顿现象。

当然，也可以在终端确定出上述第一时长(C2-C1)和上述第二时长(C3-C2)之后***log记录该第一时长和第二时长时具体取值，本申请实施例对***的log中的具体内容不作任何限制。

在本申请的一些实施例中，由于终端已经确定了发生卡顿的具体环节是在执行任务队列中位于上述目标任务之前的其他任务时发生的，因此，当再次检测到用户对上述目标应用执行相同的触发操作，例如，用户再次点击联系人应用的搜索按钮时，终端同样会生成与这次触发操作对应的目标任务(即当前的目标任务)，可以理解的是，当前的目标任务生成的时间与步骤401中最近一次目标任务的生成时间虽然不同，但是其触发的场景是相同的，因此，上述当前目标任务与步骤401中生成的目标任务的内容是相同的，例如，二者均为一个联系人搜索任务。

此时，终端可以将当前的任务队列中位于上述目标任务之前的至少一个任务作为子线程进行分流处理。如图10所示，当再次检测到用户对上述目标应用执行相同的触发操作时，终端可建立两个子线程处理任务队列中位于目标任务之前的任务1-任务6，其中，子线程1用于处理任务1、任务3和任务5，子线程2用于处理任务2、任务4和任务6。这样，目标应用响应于上述触发操作，将生成的目标任务送入任务队列，此时，任务队列中的其他任务都已经分流至子线程1和子线程2，那么，目标应用的主线程可立即处理该目标任务，从而加快该目标任务的处理速度，避免在相同的应用场景下再次出现卡顿现象。

在本申请的另一些实施例中，当再次检测到用户对上述目标应用执行相同的触发操作时，由于终端已经确定了发生卡顿的具体环节是在执行任务队列中位于上述目标任务之前的其他任务时发生的，因此，如图11所示，终端可以将上述任务队列中位于上述目标任务之前的一个或多个任务，例如，位于上述目标任务之前的任务1-任务3作为候选任务提示给用户，由用户手动的选择是否关闭其中的一个或多个任务。那么，当终端获取到用户选择的候选任务时，终端可以从上述任务队列中将用户选择的候选任务删除。这样，终端便无需执行这些被删除的候选任务，使得与上述触发操作对应的目标任务可以尽快的移动至任务队列的队头，从而加快该目标任务的处理速度，避免在相同的应用场景下再次出现卡顿现象。

又或者，当再次检测到用户对上述目标应用执行相同的触发操作时，终端可以自动为删除上述任务队列中位于上述目标任务之前的一个或多个任务，从而加快该目标任务在任务队列中的处理速度。

又或者，当再次检测到用户对上述目标应用执行相同的触发操作时，如图12所示，如果终端检测到上述目标任务在任务队列中等待的时长大于上述第一参考值还未开始执行时，终端可以提示用户关闭该应用后重新启动该应用等，本申请实施例对此不作任何限制。

当然，如果终端检测到上述目标任务在任务队列中等待的时长大于上述第一参考值还未开始执行时，终端还可以提示用户关闭除上述目标应用之外的其他应用，从而释放当前终端的内存资源，终端可以利用这部分被释放的内存资源加速执行任务队列中的各个任务，从而加快该目标任务在任务队列中的处理速度。

在本申请的另一些实施例中，由于终端在步骤405a中已经确定了发生卡顿的具体环节是在执行任务队列中位于上述目标任务之前的其他任务时发生的，并且，终端可以监测到任务队列中每一个任务在执行时花费的时长，因此，终端可以根据上述任务队列中位于上述目标任务之前的每个任务执行时花费的时长，确定出任务队列中位于上述目标任务之前运行较慢的一个或多个卡顿任务。

示例性的，仍如图7中的(a)所示，终端在监测上述目标任务从进入任务队列到移动至该任务队列的对头所花费的第一时长的同时，还可以同时监测执行该任务队列中的任务1-任务6中每一个任务时所花费的时长。当执行某个任务(例如任务3)花费的时长大于上述第二参考值时，说明终端在执行任务3时运行速度较慢，导致终端运行目标任务时发生卡顿，因此，可以将任务3作为上述卡顿任务之一。

那么，当再次检测到用户对上述目标应用执行相同的触发操作时，为了避免在相同的应用场景下再次出现卡顿现象，如图13所示，终端可以自动删除任务队列中的卡顿任务(例如，上述任务3)，从而加快该目标任务在任务队列中的处理速度；或者，终端还可以在执行上述任务队列中的卡顿任务时为其分配更多的运行资源，例如，提高CPU的运行频率、增加处理上述卡顿任务时的内存资源等，这样，终端可以更快的执行完位于目标任务之前的卡顿任务，从而加快该目标任务在任务队列中的处理速度。

405b、当上述第二时长大于第二参考值时，终端确定发生卡顿的位置位于执行上述目标任务的过程中。

示例性的，上述第二时长为C3-C2＝26毫秒，而服务器预先发送给终端的上述目标任务的第二参考值为20毫秒，此时，第二时长大于该第二参考值，说明终端在执行上述目标任务时花费的时间过长，造成用户对目标应用执行的触发操作迟迟得不到响应。

此时，终端可以确定发生卡顿的原因是因为执行该目标任务时花费的时间过长导致的，使得终端可以准确的定位出目标应用运行时发生卡顿的具体原因。

此时，为了避免后续用户对目标应用再次执行上述触发操作时再次发生卡顿，当再次检测到用户对上述目标应用执行相同的触发操作时，终端将目标应用生成的目标任务送入其任务队列的队尾，当该目标任务移动至任务队列的队头时，终端开始执行该目标任务。此时，如图14所示，终端可以在执行该目标任务时为其分配更多的运行资源，例如，提高CPU的运行频率、增加处理上述卡顿任务时的内存资源等，从而加快该目标任务在任务队列中的处理速度，避免在相同的应用场景下再次出现卡顿现象。

另外，在本申请实施例中，如图15所示，终端还可以根据任务类型对任务队列中的任务进行划分。示例性的，可以将显示类任务(例如，任务1-任务3)作为第一类任务，将搜索类任务(例如，任务4-任务6以及当前的目标任务)作为第二类任务。由于终端在执行不同种类任务时花费的时间会有所差距，因此，服务器发送的上述第二参考值中具体可以包括2个参考值K1和K2，其中，K1可用于指示终端执行显示类任务时所花费时间的中位值，例如15毫秒，K2可用于指示终端执行搜索类任务时所花费时间的中位值，例如10毫秒。

这样，当终端执行上述目标任务时，可以根据目标任务所属的种类，将实际执行该目标任务花费的第二时长与相应的第二参考值进行比较，从而更加准确的确定出在执行目标任务时是否发生卡顿。

例如，图15中所示的目标任务为搜索类任务，而搜索类任务的第二参考值K2为10毫秒。那么，终端获取到执行上述目标任务所花费的第二时长(C3-C2)后，可将该第二时长与10毫秒进行比较，当第二时长大于10毫秒时，可以确定在执行该目标任务时发生卡顿，从而提高终端检测卡顿时的准确性。

当然，终端在向服务器上报上述第一时长和第二时长时，还可以一并上报上述目标任务所属的种类的标识，例如，标识0代表上述第一类任务，标识1代表上述第二类任务。这样，服务器也可以根据各个终端上报在执行不同种类任务时所花费的时长，更新上述第二参考值中K1和K2的取值，并将更新后的K1和K2的取值发送给终端，使得终端获取到对不同种类任务检测卡顿时更加准确的参考值，从而提高终端检测卡顿时的准确性。

另外，本申请实施例还提供一种显示在终端的触摸屏中的图形用户界面(GUI)，示例性的，该图形用户界面包括：

在终端的触摸屏中显示第一GUI，例如，该第一GUI可以为终端的桌面(launch)界面，或者为某一应用运行时的任意界面，本申请实施例对此不做任何限制。进而，当检测到用户在触摸屏上对目标应用触发的第一手势时，例如，点击目标应用图标的手势，响应于该手势，终端可在触摸屏中显示第二GUI，该第二GUI中包括用于向用户提示发生卡顿的位置的第一界面元素，例如，该第一界面元素可以为图8(b)中所示的提示框。

又或者，如图8(a)中所示，上述第二GUI中还可以包括用于指示卡顿的处理进度的第二界面元素。

又或者，如图8(c)中所示，上述第二GUI中还可以包括用于提示进行卡顿优化的第三界面元素，本申请实施例对此不作任何限制。

可以理解的是，上述终端等为了实现上述功能，其包含了执行各个功能相应的硬件结构和/或软件模块。本领域技术人员应该很容易意识到，结合本文中所公开的实施例描述的各示例的单元及算法步骤，本申请实施例能够以硬件或硬件和计算机软件的结合形式来实现。某个功能究竟以硬件还是计算机软件驱动硬件的方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本申请实施例的范围。

本申请实施例可以根据上述方法示例对上述终端等进行功能模块的划分，例如，可以对应各个功能划分各个功能模块，也可以将两个或两个以上的功能集成在一个处理模块中。上述集成的模块既可以采用硬件的形式实现，也可以采用软件功能模块的形式实现。需要说明的是，本申请实施例中对模块的划分是示意性的，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式。

在采用对应各个功能划分各个功能模块的情况下，图16示出了上述实施例中所涉及的终端的一种可能的结构示意图，该终端包括：获取单元1101、执行单元1102、记录单元1103、确定单元1104、发送单元1105以及显示单元1106。

获取单元1101用于支持终端执行图4中的过程400；执行单元1102用于支持终端执行图4中的过程401；记录单元1103用于支持终端执行图4中的过程402和403；确定单元1104用于支持终端执行图4中的过程405a和405b；发送单元1105用于支持终端执行图4中的过程404；显示单元1106用于在显示界面中向用户提示发生卡顿的位置位于执行目标任务之前的其他任务的过程中或者位于执行目标任务的过程中。其中，上述方法实施例涉及的各步骤的所有相关内容均可以援引到对应发明内容中的功能描述，在此不再赘述。

相应的，在采用对应各个功能划分各个功能模块的情况下，图17示出了上述实施例中所涉及的服务器的一种可能的结构示意图，该服务器包括：获取单元1201、确定单元1202以及发送单元1203。

其中，获取单元1201，用于：获取第一终端发送的第一时长和第二时长，所述第一时长用于指示所述第一终端从生成目标任务到开始执行所述目标任务所花费的时长，所述第二时长用于指示所述第一终端执行所述目标任务所花费的时长，所述目标任务为响应于对目标应用的触发操作生成的；

确定单元1202，用于：根据所述第一时长，确定等待执行所述目标任务时的第一参考值；根据所述第二时长，确定执行所述目标任务时的第二参考值。

进一步地，获取单元1201，还用于：获取第二终端发送的第三时长和第四时长，所述第三时长用于指示所述第二终端从生成目标任务到开始执行所述目标任务所花费的时长，所述第四时长用于指示所述第二终端执行所述目标任务所花费的时长，所述目标任务为响应于对目标应用的触发操作生成的；

确定单元1202，还用于：根据所述第三时长更新所述第一参考值；根据所述第四时长更新所述第二参考值。

进一步地，发送单元1203，用于：将所述第一参考值和所述第二参考值发送给所述第一终端。

进一步地，获取单元1201，还用于：获取第一终端发送的第五时长和第六时长，所述第五时长用于指示所述第一终端从再次生成目标任务到开始执行所述目标任务所花费的时长，所述第二时长用于指示所述第一终端再次执行所述目标任务所花费的时长，所述目标任务为响应于对目标应用的触发操作生成的；

确定单元1202，还用于：根据所述第五时长更新所述第一参考值；根据所述第六时长更新所述第二参考值。

在采用集成的单元的情况下，图18示出了上述实施例中所涉及的终端的一种可能的结构示意图。该终端包括：处理模块1302和通信模块1303。处理模块1302用于对终端的动作进行控制管理。通信模块1303用于支持终端与其他网络实体的通信。该终端还可以包括存储模块1301，用于存终端的程序代码和数据。

类似的，在采用集成的单元的情况下，图19示出了上述实施例中所涉及的服务器的一种可能的结构示意图。该服务器包括：处理模块1402和通信模块1403。处理模块1402用于对服务器的动作进行控制管理。通信模块1403用于支持服务器与其他网络实体的通信。该服务器还可以包括存储模块1401，用于存服务器的程序代码和数据。

其中，处理模块1302/1402可以是处理器或控制器，例如可以是中央处理器(Central Processing Unit，CPU)，通用处理器，数字信号处理器(Digital SignalProcessor，DSP)，专用集成电路(Application-Specific Integrated Circuit，ASIC)，现场可编程门阵列(Field Programmable Gate Array，FPGA)或者其他可编程逻辑器件、晶体管逻辑器件、硬件部件或者其任意组合。其可以实现或执行结合本申请公开内容所描述的各种示例性的逻辑方框，模块和电路。所述处理器也可以是实现计算功能的组合，例如包含一个或多个微处理器组合，DSP和微处理器的组合等等。通信模块1303/1403可以是收发器、收发电路或通信接口等。存储模块1301/1401可以是存储器。

当处理模块1302为处理器，通信模块1303为RF收发电路，存储模块1301为存储器时，本申请实施例所提供的终端可以为图1所示的手机100。

在上述实施例中，可以全部或部分的通过软件，硬件，固件或者其任意组合来实现。当使用软件程序实现时，可以全部或部分地以计算机程序产品的形式出现。所述计算机程序产品包括一个或多个计算机指令。在计算机上加载和执行所述计算机程序指令时，全部或部分地产生按照本申请实施例所述的流程或功能。所述计算机可以是通用计算机、专用计算机、计算机网络、或者其他可编程装置。所述计算机指令可以存储在计算机可读存储介质中，或者从一个计算机可读存储介质向另一个计算机可读存储介质传输，例如，所述计算机指令可以从一个网站站点、计算机、服务器或数据中心通过有线(例如同轴电缆、光纤、数字用户线(DSL))或无线(例如红外、无线、微波等)方式向另一个网站站点、计算机、服务器或数据中心传输。所述计算机可读存储介质可以是计算机能够存取的任何可用介质或者是包含一个或多个可用介质集成的服务器、数据中心等数据存储设备。该可用介质可以是磁性介质，(例如，软盘，硬盘、磁带)、光介质(例如，DVD)或者半导体介质(例如固态硬盘Solid State Disk(SSD))等。

以上所述，仅为本申请的具体实施方式，但本申请的保护范围并不局限于此，任何在本申请揭露的技术范围内的变化或替换，都应涵盖在本申请的保护范围之内。因此，本申请的保护范围应以所述权利要求的保护范围为准。

Claims (30)

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

当检测到对目标应用的触发操作时，终端执行与所述触发操作对应的目标任务；

所述终端记录从生成所述目标任务到开始执行所述目标任务所花费的第一时长，以及执行所述目标任务所花费的第二时长；

所述终端通过比较所述第一时长与预设的第一参考值的大小，以及比较所述第二时长与预设的第二参考值的大小，确定发生卡顿的位置位于执行所述目标任务之前的其他任务的过程中或者位于执行所述目标任务的过程中。

2.根据权利要求1所述的方法，其特征在于，所述终端通过比较所述第一时长与预设的第一参考值的大小，以及比较所述第二时长与预设的第二参考值的大小，确定发生卡顿的位置位于执行所述目标任务之前的其他任务的过程中或者位于执行所述目标任务的过程中，包括：

当所述第一时长大于所述第一参考值时，所述终端确定发生卡顿的位置位于执行所述目标任务之前的其他任务的过程中；

当所述第二时长大于所述第二参考值时，所述终端确定发生卡顿的位置位于执行所述目标任务的过程中。

3.根据权利要求2所述的方法，其特征在于，在所述终端确定发生卡顿的位置位于执行所述目标任务之前的其他任务的过程中之后，还包括：

当再次检测到对所述目标应用的触发操作时，所述终端将位于当前目标任务之前的至少一个任务作为子线程进行分流处理。

4.根据权利要求2所述的方法，其特征在于，在所述终端确定发生卡顿的位置位于执行所述目标任务之前的其他任务的过程中之后，还包括：

当再次检测到对所述目标应用的触发操作时，所述终端将位于当前目标任务之前的至少一个任务作为等待关闭的候选目标任务；

当获取到用户选择的候选目标任务时，所述终端删除所述用户选择的候选目标任务。

5.根据权利要求2所述的方法，其特征在于，在所述终端确定发生卡顿的位置位于执行所述目标任务之前的其他任务的过程中之后，还包括：

当再次检测到用户对所述目标应用的触发操作时，所述终端删除当前目标应用生成的所有任务，并重新启动所述目标应用。

6.根据权利要求2-5中任一项所述的方法，其特征在于，在所述终端确定发生卡顿的位置位于执行所述目标任务的过程中之后，还包括：

当再次检测到对所述目标应用的触发操作时，所述终端增加执行所述目标任务时的运行资源。

7.根据权利要求1-6中任一项所述的方法，其特征在于，在所述终端记录从生成所述目标任务到开始执行所述目标任务所花费的第一时长，以及执行所述目标任务所花费的第二时长之后，还包括：

所述终端将所述第一时长和所述第二时长发送给服务器。

8.根据权利要求1-7中任一项所述的方法，其特征在于，所述方法还包括：

所述终端从服务器获取所述第一参考值和所述第二参考值，所述第一参考值用于指示所述目标任务等待执行时所花费时长的中位值，所述第二参考值用于指示执行所述目标任务时所花费时长的中位值。

9.根据权利要求1-8中任一项所述的方法，其特征在于，在确定发生卡顿的位置位于执行所述目标任务之前的其他任务的过程中或者位于执行所述目标任务的过程中之后，还包括：

所述终端在显示界面中向用户提示发生卡顿的位置位于执行所述目标任务之前的其他任务的过程中或者位于执行所述目标任务的过程中。

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

服务器获取第一终端发送的第一时长和第二时长，所述第一时长用于指示所述第一终端从生成目标任务到开始执行所述目标任务所花费的时长，所述第二时长用于指示所述第一终端执行所述目标任务所花费的时长，所述目标任务为响应于对目标应用的触发操作生成的；

所述服务器根据所述第一时长，确定等待执行所述目标任务时的第一参考值；

所述服务器根据所述第二时长，确定执行所述目标任务时的第二参考值。

11.根据权利要求10所述的方法，其特征在于，所述方法还包括：

所述服务器获取第二终端发送的第三时长和第四时长，所述第三时长用于指示所述第二终端从生成目标任务到开始执行所述目标任务所花费的时长，所述第四时长用于指示所述第二终端执行所述目标任务所花费的时长，所述目标任务为响应于对目标应用的触发操作生成的；

所述服务器根据所述第三时长更新所述第一参考值；

所述服务器根据所述第四时长更新所述第二参考值。

12.根据权利要求10或11所述的方法，其特征在于，所述方法还包括：

所述服务器将所述第一参考值和所述第二参考值发送给所述第一终端。

13.根据权利要求12所述的方法，其特征在于，在所述服务器将所述第一参考值和所述第二参考值发送给所述第一终端之后，还包括：

服务器获取第一终端发送的第五时长和第六时长，所述第五时长用于指示所述第一终端从再次生成目标任务到开始执行所述目标任务所花费的时长，所述第二时长用于指示所述第一终端再次执行所述目标任务所花费的时长，所述目标任务为响应于对目标应用的触发操作生成的；

所述服务器根据所述第五时长更新所述第一参考值；

所述服务器根据所述第六时长更新所述第二参考值。

14.一种终端，其特征在于，包括：通过总线连接的输入设备、处理器、显示器以及通信接口，其中，

所述输入设备，用于：检测对目标应用的触发操作；

所述处理器，用于：执行与所述触发操作对应的目标任务；记录从生成所述目标任务到开始执行所述目标任务所花费的第一时长，以及执行所述目标任务所花费的第二时长；通过比较所述第一时长与预设的第一参考值的大小，以及比较所述第二时长与预设的第二参考值的大小，确定发生卡顿的位置位于执行所述目标任务之前的其他任务的过程中或者位于执行所述目标任务的过程中。

15.根据权利要求14所述的终端，其特征在于，

所述处理器，具体用于：当所述第一时长大于所述第一参考值时，确定发生卡顿的位置位于执行所述目标任务之前的其他任务的过程中；当所述第二时长大于所述第二参考值时，确定发生卡顿的位置位于执行所述目标任务的过程中。

16.根据权利要求15所述的终端，其特征在于，

所述输入设备，还用于：再次检测对所述目标应用的触发操作；

所述处理器，还用于：将位于当前目标任务之前的至少一个任务作为子线程进行分流处理。

17.根据权利要求15所述的终端，其特征在于，

所述输入设备，还用于：再次检测对所述目标应用的触发操作；获取用户选择的候选目标任务；

所述处理器，还用于：将位于当前目标任务之前的至少一个任务作为等待关闭的候选目标任务；删除所述用户选择的候选目标任务。

18.根据权利要求15所述的终端，其特征在于，

所述输入设备，还用于：再次检测对所述目标应用的触发操作；

所述处理器，还用于：删除当前目标应用生成的所有任务，并重新启动所述目标应用。

19.根据权利要求15-18中任一项所述的终端，其特征在于，

所述输入设备，还用于：再次检测对所述目标应用的触发操作；

所述处理器，还用于：增加执行所述目标任务时的运行资源。

20.根据权利要求14-19中任一项所述的终端，其特征在于，

所述通信接口，用于：将所述第一时长和所述第二时长发送给服务器。

21.根据权利要求14-20中任一项所述的终端，其特征在于，

所述通信接口，还用于：从服务器获取所述第一参考值和所述第二参考值，所述第一参考值用于指示所述目标任务等待执行时所花费时长的中位值，所述第二参考值用于指示执行所述目标任务时所花费时长的中位值。

22.根据权利要求14-21中任一项所述的终端，其特征在于，

所述显示器，用于：在显示界面中向用户提示发生卡顿的位置位于执行所述目标任务之前的其他任务的过程中或者位于执行所述目标任务的过程中。

23.一种服务器，其特征在于，包括：通过总线连接的处理器和通信接口，其中，

所述通信接口，用于：获取第一终端发送的第一时长和第二时长，所述第一时长用于指示所述第一终端从生成目标任务到开始执行所述目标任务所花费的时长，所述第二时长用于指示所述第一终端执行所述目标任务所花费的时长，所述目标任务为响应于对目标应用的触发操作生成的；

所述处理器，用于：根据所述第一时长，确定等待执行所述目标任务时的第一参考值；根据所述第二时长，确定执行所述目标任务时的第二参考值。

24.根据权利要求23所述的服务器，其特征在于，

所述通信接口，还用于：获取第二终端发送的第三时长和第四时长，所述第三时长用于指示所述第二终端从生成目标任务到开始执行所述目标任务所花费的时长，所述第四时长用于指示所述第二终端执行所述目标任务所花费的时长，所述目标任务为响应于对目标应用的触发操作生成的；

所述处理器，还用于：根据所述第三时长更新所述第一参考值；根据所述第四时长更新所述第二参考值。

25.根据权利要求23或24所述的服务器，其特征在于，

所述通信接口，还用于：将所述第一参考值和所述第二参考值发送给所述第一终端。

26.根据权利要求25所述的服务器，其特征在于，

所述通信接口，还用于：获取第一终端发送的第五时长和第六时长，所述第五时长用于指示所述第一终端从再次生成目标任务到开始执行所述目标任务所花费的时长，所述第二时长用于指示所述第一终端再次执行所述目标任务所花费的时长，所述目标任务为响应于对目标应用的触发操作生成的；

所述处理器，还用于：根据所述第五时长更新所述第一参考值；根据所述第六时长更新所述第二参考值。

27.一种计算机可读存储介质，所述计算机可读存储介质中存储有指令，其特征在于，当所述指令在终端上运行时，使得所述终端执行如权利要求1-9中任一项所述的卡顿检测方法。

28.一种计算机可读存储介质，所述计算机可读存储介质中存储有指令，其特征在于，当所述指令在服务器上运行时，使得所述服务器执行如权利要求10-13中任一项所述的卡顿检测方法。

29.一种包含指令的计算机程序产品，其特征在于，当所述计算机程序产品在终端上运行时，使得所述终端执行如权利要求1-9中任一项所述的卡顿检测方法。

30.一种包含指令的计算机程序产品，其特征在于，当所述计算机程序产品在服务器上运行时，使得所述服务器执行如权利要求10-13中任一项所述的卡顿检测方法。