CN110502416A - 应用卡顿检测方法、装置、计算机设备及可读介质 - Google Patents

Abstract

本申请提出一种应用卡顿检测方法、装置、计算机设备及可读介质，其中，方法包括：在应用运行过程中，监测应用中各函数的调用状态；在检测到应用中的目标函数被调用时，截获调用目标函数的请求，其中，目标函数为用于修改对象在应用客户端中呈现位置的函数；根据调用目标函数的请求，确定应用在运行过程中的卡顿状态。该方法能够实现根据目标函数是否被调用，自动确定应用在运行过程中是否存在卡顿现象，提升了应用卡顿检测的准确性和可靠性。此外，在应用卡顿检测的过程中，无需安装其他软件，简化了应用卡顿测试的操作，改善了用户体验。

Description

应用卡顿检测方法、装置、计算机设备及可读介质

技术领域

本申请涉及计算机技术领域，尤其涉及一种应用卡顿检测方法、装置、计算机设备及可读介质。

背景技术

3D游戏，因其具有逼真的场景和角色，可以提升用户的代入感，因而广受用户欢迎。但是，当3D游戏存在卡顿现象时，将会影响用户的实时战斗体验和战绩。

目前，相关技术中，针对各类对画面流畅度要求较高的应用，主要通过在终端设备(例如手机)中安装相应的测试应用，以采集画面的每秒帧数(Frames Per Second，简称FPS)值，而后根据FPS值，确定应用在运行过程中是否存在卡顿现象。其中，FPS值越高，应用在运行的过程中就越流畅，FPS越低，应用在运行的过程中就越卡顿。

这种方式下，由于需要在终端设备上安装专门的测试应用，操作步骤繁琐，占用终端设备的内存，且不同用户，对卡顿的感受不同，因此用FPS值衡量应用卡顿的方式，不准确。

发明内容

为此，本申请实施例提出一种应用卡顿检测方法，以实现根据目标函数是否被调用，自动确定应用在运行过程中是否存在卡顿现象，提升了应用卡顿检测的准确性和可靠性。

本申请一方面实施例提出了一种应用卡顿检测方法，包括：

在所述应用运行过程中，监测所述应用中各函数的调用状态；

在检测到所述应用中的目标函数被调用时，截获调用所述目标函数的请求，其中，所述目标函数为用于修改对象在应用客户端中呈现位置的函数；

根据所述调用所述目标函数的请求，确定所述应用在运行过程中的卡顿状态。

本申请实施例的应用卡顿检测方法，通过在应用运行过程中，监测应用中各函数的调用状态；在检测到应用中的目标函数被调用时，截获调用目标函数的请求，其中，目标函数为用于修改对象在应用客户端中呈现位置的函数；根据调用目标函数的请求，确定应用在运行过程中的卡顿状态。由此，可以实现根据目标函数是否被调用，自动确定应用在运行过程中是否存在卡顿现象，提升了应用卡顿检测的准确性和可靠性。

本申请又一方面实施例提出了一种应用卡顿检测装置，包括：

监测模块，用于在所述应用运行过程中，监测所述应用中各函数的调用状态。

截获模块，用于在检测到所述应用中的目标函数被调用时，截获调用所述目标函数的请求，其中，所述目标函数为用于修改对象在应用客户端中呈现位置的函数；

第一确定模块，用于根据所述调用所述目标函数的请求，确定所述应用在运行过程中的卡顿状态。

本申请实施例的应用卡顿检测装置，通过在应用运行过程中，监测应用中各函数的调用状态；在检测到应用中的目标函数被调用时，截获调用目标函数的请求，其中，目标函数为用于修改对象在应用客户端中呈现位置的函数；根据调用目标函数的请求，确定应用在运行过程中的卡顿状态。由此，可以实现根据目标函数是否被调用，自动确定应用在运行过程中是否存在卡顿现象，提升了应用卡顿检测的准确性和可靠性。

本申请又一方面实施例提出了一种计算机设备，包括：存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，所述处理器执行所述程序时，实现如本申请前述实施例所述的应用卡顿检测方法。

本申请又一方面实施例提出了一种计算机可读存储介质，其上存储有计算机程序，其特征在于，该程序被处理器执行时实现如本申请前述实施例所述的应用卡顿检测方法。

本申请附加的方面和优点将在下面的描述中部分给出，部分将从下面的描述中变得明显，或通过本申请的实践了解到。

附图说明

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

图1为ROOT或越狱后的测试流程示意图；

图2为非ROOT测试流程示意图；

图3当测试应用助手未启动时对应的测试界面示意图；

图4为终端设备与计算机设备未成功连接时对应的测试界面示意图；

图5为与ADB服务冲突时对应的测试界面示意图；

图6为本申请实施例一所提供的应用卡顿检测方法的流程示意图

图7为本申请实施例二所提供的应用卡顿检测方法的流程示意图；

图8为本本申请实施例中卡顿数据的显示位置示意图；

图9为本申请实施例三所提供的应用卡顿检测方法的流程示意图；

图10为本申请实施例四所提供的应用卡顿检测装置的结构示意图；

图11为本申请实施例五所提供的应用卡顿检测装置的结构示意图；

图12是根据一示例性实施例的计算机设备的结构示意图。

具体实施方式

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

相关技术中，针对游戏类应用，主要通过采集FPS值，根据FPS值，确定应用在运行过程中是否存在卡顿现象，即判断两帧游戏画面之间的渲染是否超过预设阈值。举例来说，若两帧游戏画面之间的渲染总耗时超过40ms，即1s内播放的画面帧数低于25帧，则认为游戏出现卡顿或者游戏流畅度不佳；若两帧游戏画面之间的渲染总耗时超过55ms，即1s内播放的画面帧数低于18帧，则认为游戏出现严重卡顿。其中，FPS值越高，应用在运行的过程中就越流畅，FPS越低，应用在运行的过程中就越卡顿。

具体地，目前，常用的一种测试应用可以通过下述获取终端设备操作系统权限和非获取终端设备操作系统权限两种方式，来获取FPS数据。

第一种方式，获取终端设备操作系统权限。对于操作系统为安卓(Android)的终端设备来说，可以通过在系统中设置超级用户(ROOT)，来获取终端设备操作系统的权限；对于苹果(IOS)操作系统来说，需要首先破解将该系统对用户的读写操作(称为越狱)，来获取终端设备操作系统的权限。如图1所示，当终端设备已ROOT或者越狱后，即可在终端设备中安装测试应用，而后打开测试应用，选择通用性能测试，而后选择待测试应用，即可对待测试应用进行测试。在测试结束后，点击预设按钮上传数据，上传完成后，即可在测试应用报告页面查看FPS数据。

第二种方式，非获取终端设备操作系统权限，即非ROOT。仅针对操作系统为Android的终端设备，如图2所示，终端设备可以预先安装测试应用，计算机设备，例如PC可以预先安装并运行测试应用助手，终端设备通过USB线连接计算机设备，并开始进行测试模式。具体地，终端设备打开测试应用，选择待测试应用，对待测试应用进行测试。在测试结束后，点击预设按钮上传数据，上传完成后，即可在测试应用报告页面查看FPS数据。

第一种方式下，对于操作系统为Android的终端设备，需要ROOT，对于操作系统版本为6.0及以上的终端设备，ROOT的成本较高，此外，一些机型的终端设备需要对操作系统刷新升级，才能ROOT，限制较高，且不能保证ROOT的成功率。另外，无论何种操作系统的终端设备，均需下载测试应用，操作步骤繁琐。

第二种方式下，虽然可以免ROOT，但是需要计算机设备安装测试应用助手，且终端设备需要安装测试应用。并且，当终端设备连接计算机设备的过程中，可能发生如图3所示的测试应用助手后台程序未启动的情况，或者发生如图4所示的未发现设备连接的情况，或者发生如图5所示的调试桥工具(Android Debug Bridge，简称ADB)服务冲突的情况等，操作步骤极为繁琐。

并且，上述两种方式下，测试应用每测试一个场景后，均需上传数据并重启应用，才能在报告页面查看FPS数据，耗时较高。

本申请主要针对现有技术中在对应用进行卡顿检测时，需要安装测试应用，操作步骤繁琐，且测试应用每测试一个场景后，均需上传数据并重启应用，才能在报告页面查看FPS数据，耗时较高的技术问题，提出一种应用卡顿检测方法。

本申请实施例中，在应用运行过程中，监测应用中各函数的调用状态，在检测到应用中的目标函数被调用时，截获调用目标函数的请求，其中，目标函数为用于修改对象在应用客户端中呈现位置的函数；根据调用目标函数的请求，确定应用在运行过程中的卡顿状态。由此，可以实现根据目标函数是否被调用，自动确定应用在运行过程中是否存在卡顿现象，从而提升了应用卡顿检测的精确性和实时性。此外，在应用卡顿检测的过程中，无需安装其他软件，简化了应用卡顿测试的操作，改善了用户体验。

下面参考附图描述本申请实施例的应用卡顿检测方法、装置、计算机设备及存储介质。

图6为本申请实施例一所提供的应用卡顿检测方法的流程示意图。

本申请实施例提供的应用卡顿检测方法，可以由本申请实施例提供的应用卡顿检测装置实现，该装置可以被配置在终端设备中任何需要进行卡顿检测的应用中，以对该应用进行卡顿检测。

其中，终端设备可以为手机、平板电脑、个人数字助理、穿戴式设备等具有各种操作系统、触摸屏和/或显示屏的硬件设备。

如图6所示，该应用卡顿检测方法包括以下步骤：

步骤101，在应用运行过程中，监测应用中各函数的调用状态。

本申请实施例中，应用是指可以运行在终端设备上、为用户提供任意服务的软件程序，例如为游戏类应用、视频类应用等等。

本申请实施例中，为了提升应用卡顿检测的准确性以及及时性，在应用运行过程中，应用卡顿检测装置可以实时监测应用中各函数的调用状态。例如，可以在终端设备中设置监听器，实时监测应用中各函数的调用状态。

作为一种可能的实现方式，在应用运行过程中，应用卡顿检测装置可以根据与各函数关联的钩子函数(hook函数)的被调用状态，监测应用中各函数被调用状态。由于将各函数设置“钩子”后，调用各函数时，必须通过调用钩子函数才能实现，因此，本申请可直接通过检测钩子函数是否被调用，来确定应用中各函数被调用状态。

步骤102，在检测到应用中的目标函数被调用时，截获调用目标函数的请求，其中，目标函数为用于修改对象在应用客户端中呈现位置的函数。

本申请实施例中，对象，是指应用显示界面呈现的、用户可操控的模型，例如当应用为游戏类应用时，对象可以为游戏中的角色。

为方便说明书，本申请以下各实施例，以游戏类应用为例，对本申请提供的应用卡顿检测方法等进行详细说明。

需要说明的是，在应用运行时，服务器会根据应用中每个对象的属性，比如对象对应的预设移动速度、角色及当前的设备类型等等，以及应用此次启动后至当前时刻所经历的时间，实时计算每个对象的位置，之后即可将计算得到的位置信息下发给对应的应用客户端，并且应用客户端可以实时采集每个对象当前在应用客户端中呈现的位置。正常情况下，对象在应用客户端中呈现的位置，与服务器计算的对象对应的位置之间的差值应处于预设范围内，而当对象在应用客户端中呈现的位置，与服务器计算的对象对应的位置之间的差值大于预设范围时，应用客户端即会通过调用目标函数，以将对象的位置，强制修改到与服务下发的位置信息一致的位置，此时在应用显示画面中，即会出现卡顿现象。

因此，本申请实施例中，应用卡顿检测装置在应用运行过程中，即可实时检测应用中的目标函数是否被调用，当在检测到应用中的目标函数被调用时，可以确定应用在运行过程中存在卡顿现象。

具体地，在应用运行过程中，应用卡顿检测装置在检测到与目标函数关联的钩子函数(hook函数)的被调用时，确定目标函数被调用，此时，应用需要根据服务器计算的对象对应的位置，将对象在客户端中的位置进行强制修改，从而应用就会出现卡顿现象，而每当强制修改对象在客户端中的位置一次，就会调用一次hook函数(目标函数)，因此，本申请实施例中通过根据hook函数的被调用状态，可以检测应用在运行中是否出现了卡顿现象。从而使得对卡顿现象的检测，不依赖用户体验，仅由应用本身的性能决定，测试结果的准确性、可靠性较高，且通过对应用中各函数的监控，来检测卡顿是否发生，不受应用所在终端操作系统差异影响，提高了测试结果的通用性。

本申请实施例中，在检测到应用中的目标函数被调用时，为了定位卡顿在应用中所处的位置，从而使得此次卡顿现象可以精确地重现，进而便于开发人员根据该位置快速修复卡顿，本申请中，应用卡顿检测装置可以截获调用目标函数的请求。

步骤103，根据调用目标函数的请求，确定应用在运行过程中的卡顿状态。

本申请实施例中，在截获到调用目标函数的请求后，应用卡顿检测装置可以根据调用目标函数的请求，确定应用在运行过程中的卡顿状态。其中，卡顿状态可以包括卡顿数据，卡顿数据可以包括：发生卡顿时目标对象的标识、目标对象当前在应用客户端中的第一位置及目标对象待调整至的第二位置等数据。

可选地，应用卡顿检测装置可以对各调用目标函数的请求进行解析处理，获取当前目标对象的标识、目标对象当前在应用客户端中的第一位置及目标对象待调整至的第二位置，而后可以根据目标对象标识、第一位置及第二位置，生成当前的卡顿数据。

其中，目标对象为当前目标函数待调整的对象。例如，当应用为游戏类应用时，目标对象可以为该终端设备上所登录的用户对应的游戏角色，或者，也可以为该游戏类应用中任一由其它终端设备控制的游戏角色；目标对象的标识用于唯一标识该目标对象，例如可以为目标对象的ID、昵称等；第一位置为目标对象当前在应用客户端中的位置，而第二位置为服务器计算的目标对象的位置。

本申请实施例中，在应用运行的过程中，可以实时获取服务器发送的移动包，根据移动包，确定服务器计算的目标对象的位置，即第二位置。之后即可确定目标对象当前在应用客户端中的位置，即第一位置，然后确定第一位置与第二位置间的差值不在预设范围内时，则会以第一位置、第二位置及目标对象为参数，调用目标函数(钩子函数)，此时应用卡顿检测装置即可检测到目标函数被调用，从而应用卡顿检测装置通过对调用目标函数的请求进行解析处理，即可获取当前目标对象的标识、目标对象当前在应用客户端中的第一位置及目标对象待调整至的第二位置。

本申请实施例中，卡顿数据可以包括目标对象标识、第一位置及第二位置。应用卡顿检测装置，通过记录发生卡顿时目标对象的标识、第一位置及第二位置，从而即可根据上述卡顿数据，对此次卡顿现象进行精确的重现，从而为开发人员解决卡顿问题提供了可靠依据。

本实施例的应用卡顿检测方法，通过在应用运行过程中，监测应用中各函数的调用状态，在检测到应用中的目标函数被调用时，截获调用目标函数的请求，其中，目标函数为用于修改对象在应用客户端中呈现位置的函数；根据调用目标函数的请求，确定应用在运行过程中的卡顿状态。由此，可以实现根据目标函数是否被调用，自动确定应用在运行过程中是否存在卡顿现象，提升了应用卡顿检测的准确性和可靠性。此外，在应用卡顿检测的过程中，无需安装其他软件，简化了应用卡顿测试的操作，改善了用户体验。进一步地，根据调用目标函数的请求，确定应用在运行过程中的卡顿状态，可以定位卡顿在应用中所处的位置，对此次卡顿现象进行精确的重现，从而为开发人员解决卡顿问题提供了可靠依据。

进一步地，卡顿数据还可以包括时间信息，该时间信息为应用此次启动后至当前时刻所经历的时间。

可以理解的是，当确定时间信息后，服务器可以根据目标对象对应的预设移动速度，以及位移公式，确定目标对象待调整至的第二位置，同时，应用客户端通过实时采集目标对象的移动速度，根据采集的移动速度以及位移公式，确定目标对象当前在应用客户端中的第一位置。

作为一种可能的实现方式，为了更加精确的定位应用中出现卡顿现象的位置，在生成当前的卡顿数据之前，还可以获取目标对象当前的属性信息，以及目标对象当前所在的场景信息。

本申请实施例中，目标对象当前的属性信息可以为目标对象的装备、角色、使用的武器等。

可选地，应用中可以包括N个场景，目标对象当前所在的场景信息可以包括：当前时刻目标对象所在的目标场景标识，及当前时刻距离目标场景起始时刻的时长。

其中，目标场景标识用于唯一标识该目标场景，例如可以为目标场景ID等。作为一种示例，当应用为游戏类应用时，参见表1，游戏具有N关，且游戏的每一关均可以具有对应的地图，目标对象当前所在的场景信息可以包括地图ID、地图名称等等，根据地图ID，可以快速定位目标对象在游戏中的哪一关。

由下表1可以看出，应用服务器，通过统计各应用客户端中的应用卡顿检测装置，返回的卡顿数据，即可确定该应用各个场景对应的卡顿率及卡顿几率等数据，从而即可对该应用进行准确的修复和改善，以改善用户的体验。

表1

可以理解的是，用户在玩游戏时，根据游戏场景标识可以确定目标对象在游戏的哪一关，根据当前时刻距离目标场景起始时刻的时长，可以确定目标对象在游戏场景的具体位置。可以理解的是，由于不同用户玩游戏的水平不同，因此，不同用户从进入目标场景到目标场景中同一位置所用的时长不同。举例而言，目标场景为游戏的第三关，用户A从进入第三关开始，到第三关的位置W时，所用的时长为8分钟，而用户B从进入第三关开始，到第三关的位置W时所用的时长为9分钟。因此，可以根据用户的水平，以及当前时刻距离目标场景起始时刻的时长，确定目标对象当前所在的目标场景中的具体位置。

现有技术中，由于卡顿现象受限于终端设备操作系统类型、不同用户的主观反馈、卡顿现象持续时长的长短、卡顿现象发生的频率等，较低的FPS值对应的卡顿现象，在应用中的场景很难重现。例如，针对同一应用，操作系统不同时，和/或，操作系统的版本信息不同时，测试应用无法捕捉在同一场景中必然出现的卡顿。而本申请实施例中，通过根据目标对象标识、第一位置、第二位置、目标对象当前的属性信息及目标对象当前所在的场景信息，生成当前的卡顿数据，从而即可根据生成的卡顿数据，准确定位卡顿在应用中所处的位置以及具体的场景，进而可以便于应用开发者根据该位置和场景，快速修复卡顿。

可以理解的是，当确定卡顿在应用中所处的位置以及具体的场景时，应用开发者根据该位置和场景，快速修复卡顿，从而降低卡顿现象在应用中出现的概率，提升用户的使用体验。

作为一种可能的实现方式，在生成当前的卡顿数据之后，即可直接将当前的卡顿数据，发送给服务器，由此，无需在终端设备本地保存大量数据，由服务器对卡顿数据进行存储，以便于实时分析卡顿现象的原因，从而对卡顿进行修复。或者，还可以在应用运行结束后，将应用运行过程中的所有卡顿数据，发送给服务器，对此不作限制。

作为一种可能的实现方式，为了方便测试人员实时了解卡顿产生的原因以及卡顿等级，可以在测试的过程中，在应用画面上显示卡顿数据。其中，卡顿等级可以由第一位置和第二位置之间的差值来确定。具体地，根据第一位置和第二位置之间的差值，可以确定目标对象位置改变时，需要强制变换的画面数量。当差值越大时，变换的画面数量越多，卡顿等级越高，而当差值越小时，变换的画面数量越少，卡顿等级越小。下面结合图7，对上述过程进行详细说明。

图7为本申请实施例二所提供的应用卡顿检测方法的流程示意图。

如图7所示，该应用卡顿检测方法可以包括以下步骤：

步骤201，在应用运行过程中，监测应用中各函数的调用状态。

步骤201的执行过程可以参见上述实施例中步骤101的执行过程，此处不做赘述。

步骤202，获取服务器下发的目标对象的第二位置及目标对象当前在应用客户端中的第一位置。

本申请实施例中，在应用运行时，服务器可以根据目标对象对应的预设移动速度，以及应用此次启动后至当前时刻所经历的时间，实时计算目标对象的第二位置，应用客户端可以根据用户对目标对象的操作实时的获取目标对象当前在应用客户端中呈现的第一位置。从而应用卡顿检测装置可以从服务器中获取目标对象的第二位置及目标对象当前在应用客户端中的第一位置。

步骤203，比较分析第一位置与第二位置间的差值，确定差值未在预设范围内。

正常情况下，目标对象在应用客户端中呈现的第一位置，与服务器计算的目标对象对应的第二位置之间的差值应处于预设范围内，而当对象在应用客户端中呈现的第一位置与服务器计算的对象对应的第二位置之间的差值将超出预设范围时，应用客户端即会根据第二位置，调整应用中对象的位置，从而应用即会出现卡顿现象。

步骤204，检测应用中目标函数是否被调用，若是，执行步骤205，否则，执行步骤201。

可选地，当差值未在预设范围内时，可以检测应用中目标函数是否被调用，若是，则表明应用在运行过程中出现卡顿现象，此时，可以触发步骤205，否则，则表明应用在运行过程中未出现卡顿现象，此时，可以继续监测应用中各函数的调用状态。

步骤205，截获调用目标函数的请求。

步骤206，对各调用目标函数的请求进行解析处理，以获取当前目标对象的标识、目标对象当前在应用客户端中的第一位置及目标对象待调整至的第二位置。

步骤207，根据目标对象标识、第一位置及第二位置，生成当前的卡顿数据。

步骤205～207的执行过程可以参见上述实施例中步骤102～103的执行过程，此处不做赘述。

步骤208，判断应用当前的运行环境是否为测试环境。

步骤209，若是，则将卡顿数据显示在应用画面的顶层。

本申请实施例中，只有在应用当前的运行环境为测试环境时，才需要在应用画面显示卡顿数据，从而方便测试人员实时了解卡顿产生的位置、及卡顿等级等信息。

作为一种可能的实现方式，为了不影响用户使用应用，可以将卡顿数据非全屏地显示在应用画面的顶层。例如，用户在玩游戏时，如果将卡顿数据全屏地显示在应用画面的顶层，用户将无法查看游戏画面，可能严重影响用户的实时战斗体验和战绩。

作为一种示例，参见图8，图8为本本申请实施例中卡顿数据的显示位置示意图。如图8所示，在测试时，可以将卡顿数据非全屏地显示在应用画面的顶层，从而用户可以实时查看游戏画面，提升用户的游戏体验。

本申请实施例中，当应用当前的运行环境为测试环境时，将卡顿数据显示在应用画面的顶层，可以方便测试人员实时了解卡顿产生的位置以及卡顿等级，从而为准确定位卡顿产生的位置，提供了条件，同时仅在应用运行中测试场景时，在应用画面的顶层显示卡顿数据，可以避免影响用户使用应用，提升用户使用体验。

作为一种可能的实现方式，本申请中，还可以预先获取各种类型的卡顿数据，例如特殊地形、碰撞检测缺失、瞬时位移变化、特殊技能、同步算法误差等类型的卡顿数据，利用各种类型的卡顿数据训练各类型卡顿对应的预设的卡顿模型。从而在对应用进行测试时，当确定卡顿数据后，可以根据卡顿数据与各预设的卡顿模型的匹配度，确定当前的卡顿现象所属的类型，从而可以根据卡顿现象所属的类型，快速修复卡顿，提升问题发现和解决的效率。

需要说明的是，由于服务器计算的对象的第二位置，是根据应用的后台算法实现的，而应用客户端确定的对象的第一位置，是根据应用的前端算法实现的，而前端算法和后台算法，通常是由不同的开发人员分别开发的，且前端算法和后台算法，通常采用的语言类型不同，而不同类型的语言中，对同一对象定义的精度、数据类型可能不同，比如前端、后台对游戏中角色模型的尺寸定义不同，从而会导致服务器根据后台算法计算的目标对象的第二位置，与应用客户端根据前端算法计算的目标对象在应用中呈现的第一位置不同。

因此，本申请中，可以根据前端算法及后台算法的差异，确定卡顿现象的原因。下面结合图9，对上述过程进行详细说明。

图9为本申请实施例三所提供的应用卡顿检测方法的流程示意图。

如图9所示，在检测到应用中的目标函数被调用之后，该应用卡顿检测方法还可以包括以下步骤：

步骤301，获取应用中与预设时间段对应的前端算法及后台算法，其中，预设时间段为目标函数最近一次被调用的时间至当前时刻间的时间段。

步骤302，根据前端算法及后台算法的差异，确定卡顿现象的原因。

可以理解的是，本申请实施例中，通过比较应用中前后两次发生卡顿时对应的前端算法及后台算法，即可确定最后一次发生的卡顿现象产生的原因。

举例来说，若目标函数最近一次被调用时(即最近一次产生卡顿时)对应的前端算法中的代码行数为：4466，后台算法中的代码行数为4452；而当前目标函数被调用时，对应前端算法中的代码行数为4498，后台算法中的代码行为数位4482。从而通过比较前端算法中的第4466-4498间的代码，与后台算法中的第4452-4498间的代码差异，即可确定当前时刻产生卡顿现象的原因。

比如，通过比较前端算法与后台算法的差异，确定中该部分中，前端算法中的位移计算公式与后台算法中的位移计算公式不同，那么就可以准确确定当前的卡顿现象是由于位移计算公式不同而引起的；或者，通过比较前端算法与后台算法的差异，确定中该部分中，前端算法中的目标对象的尺寸与后台算法中目标对象的尺寸不同，那么就可以确定当前的卡顿现象是由于目标对象的尺寸不同引起的等等。从而开发人员根据卡顿现象的原因，即可对前端算法或者后台算法进行准确修改。

为了实现上述实施例，本申请还提出一种应用卡顿检测装置。

图10为本申请实施例四所提供的应用卡顿检测装置的结构示意图。

如图10所示，该应用卡顿检测装置100包括：监测模块101、截获模块102，以及第一确定模块103。其中，

监测模块101，用于在应用运行过程中，监测应用中各函数的调用状态。

截获模块102，用于在检测到应用中的目标函数被调用时，截获调用目标函数的请求，其中，目标函数为用于修改对象在应用客户端中呈现位置的函数。

第一确定模块103，用于根据调用目标函数的请求，确定应用在运行过程中的卡顿状态。

进一步地，在本申请实施例的一种可能的实现方式中，参见图11，在图10所示实施例的基础上，该应用卡顿检测装置100还可以包括：

作为一种可能的实现方式，第一确定模块103，包括：

处理子模块1031，用于对各调用目标函数的请求进行解析处理，以获取当前目标对象的标识、目标对象当前在应用客户端中的第一位置及目标对象待调整至的第二位置.

生成子模块1032，用于根据目标对象标识、第一位置及第二位置，生成当前的卡顿数据。

可选地，第一确定模块103，还包括：

获取子模块1033，用于在生成当前的卡顿数据之前，获取目标对象当前的属性信息及目标对象当前所在的场景信息。

生成子模块1032，具体用于根据目标对象标识、第一位置、第二位置、目标对象当前的属性信息及目标对象当前所在的场景信息，生成当前的卡顿数据。

作为一种可能的实现方式，应用中可以包括N个场景，目标对象当前所在的场景信息，包括：当前时刻目标对象所在的目标场景标识，及当前时刻距离目标场景起始时刻的时长。

发送模块104，用于在生成当前的卡顿数据之后，将当前的卡顿数据，发送给服务器；或者，确定应用运行结束后，将应用运行过程中的所有卡顿数据，发送给服务器。

判断模块105，用于在生成当前的卡顿数据之后，判断应用当前的运行环境是否为测试环境。

显示模块106，用于若是，则将卡顿数据显示在应用画面的顶层。

第二确定模块107，用于在成当前的卡顿数据之后，根据卡顿数据与各预设的卡顿模型的匹配度，确定当前的卡顿现象所属的类型。

第一获取模块108，用于在检测应用中目标函数是否被调用之前，获取服务器下发的目标对象的第二位置及目标对象当前在应用客户端中的第一位置。

比较模块109，用于比较分析第一位置与第二位置间的差值，确定差值未在预设范围内。

第二获取模块110，用于在检测到应用中的目标函数被调用之后，获取应用中与预设时间段对应的前端算法及后台算法，其中，预设时间段为目标函数最近一次被调用的时间至当前时刻间的时间段。

第三确定模块111，用于根据前端算法及后台算法的差异，确定卡顿现象的原因。

需要说明的是，前述对应用卡顿检测方法实施例的解释说明也适用于该实施例的应用卡顿检测装置100，此处不再赘述。

本实施例的应用卡顿检测装置，通过在应用运行过程中，监测应用中各函数的调用状态，在检测到应用中的目标函数被调用时，截获调用目标函数的请求，其中，目标函数为用于修改对象在应用客户端中呈现位置的函数；根据调用目标函数的请求，确定应用在运行过程中的卡顿状态。由此，可以实现根据目标函数是否被调用，自动确定应用在运行过程中是否存在卡顿现象，提升了应用卡顿检测的准确性和可靠性。此外，在应用卡顿检测的过程中，无需安装其他软件，简化了应用卡顿测试的操作，改善了用户体验。进一步地，根据调用目标函数的请求，确定应用在运行过程中的卡顿状态，可以定位卡顿在应用中所处的位置，对此次卡顿现象进行精确的重现，从而为开发人员解决卡顿问题提供了可靠依据。

为了实现上述实施例，本申请还提出一种计算机设备。

图12是根据一示例性实施例的计算机设备的结构示意图。图12显示的计算机设备仅仅是一个示例，不应对本申请实施例的功能和使用范围带来任何限制。

参照图12，该计算机设备200包括：存储器210及处理器220，连接不同组件(包括存储器210和处理器220)的总线230，存储器210存储有计算机程序，当处理器220执行所述程序时实现前述实施例所述的应用卡顿检测方法。

总线230表示几类总线结构中的一种或多种，包括存储器总线或者存储器控制器，外围总线，图形加速端口，处理器或者使用多种总线结构中的任意总线结构的局域总线。举例来说，这些体系结构包括但不限于工业标准体系结构(ISA)总线，微通道体系结构(MAC)总线，增强型ISA总线、视频电子标准协会(VESA)局域总线以及外围组件互连(PCI)总线。

计算机设备200典型地包括多种计算机设备可读介质。这些介质可以是任何能够被计算机设备200访问的可用介质，包括易失性和非易失性介质，可移动的和不可移动的介质。

存储器210还可以包括易失性存储器形式的计算机系统可读介质，例如随机存取存储器(RAM)240和/或高速缓存存储器250。计算机设备200可以进一步包括其它可移动/不可移动的、易失性/非易失性计算机系统存储介质。仅作为举例，存储系统260可以用于读写不可移动的、非易失性磁介质(图12未显示，通常称为“硬盘驱动器”)。尽管图12中未示出，可以提供用于对可移动非易失性磁盘(例如“软盘”)读写的磁盘驱动器，以及对可移动非易失性光盘(例如CD-ROM,DVD-ROM或者其它光介质)读写的光盘驱动器。在这些情况下，每个驱动器可以通过一个或者多个数据介质接口与总线230相连。存储器210可以包括至少一个程序产品，该程序产品具有一组(例如至少一个)程序模块，这些程序模块被配置以执行本申请各实施例的功能。

具有一组(至少一个)程序模块270的程序/实用工具280，可以存储在例如存储器210中，这样的程序模块270包括——但不限于——操作系统、一个或者多个应用程序、其它程序模块以及程序数据，这些示例中的每一个或某种组合中可能包括网络环境的实现。程序模块270通常执行本申请所描述的实施例中的功能和/或方法。

计算机设备200也可以与一个或多个外部设备290(例如键盘、指向设备、显示器291等)通信，还可与一个或者多个使得用户能与该计算机设备200交互的设备通信，和/或与使得该计算机设备200能与一个或多个其它计算设备进行通信的任何设备(例如网卡，调制解调器等等)通信。这种通信可以通过输入/输出(I/O)接口292进行。并且，计算机设备200还可以通过网络适配器293与一个或者多个网络(例如局域网(LAN)，广域网(WAN)和/或公共网络，例如因特网)通信。如图所示，网络适配器293通过总线230与计算机设备200的其它模块通信。应当明白，尽管图中未示出，可以结合计算机设备200使用其它硬件和/或软件模块，包括但不限于：微代码、设备驱动器、冗余处理单元、外部磁盘驱动阵列、RAID系统、磁带驱动器以及数据备份存储系统等。

处理器220通过运行存储在存储器210中的程序，从而执行各种功能应用以及数据处理，例如实现前述实施例所述的应用卡顿检测方法。

需要说明的是，前述对应用卡顿检测方法实施例的解释说明也适用于该实施例的计算机设备，其实现原理类似，此处不再赘述。

本申请实施例提供的计算机设备，通过在应用运行过程中，监测应用中各函数的调用状态，在检测到应用中的目标函数被调用时，截获调用目标函数的请求，其中，目标函数为用于修改对象在应用客户端中呈现位置的函数；根据调用目标函数的请求，确定应用在运行过程中的卡顿状态。由此，可以实现根据目标函数是否被调用，自动确定应用在运行过程中是否存在卡顿现象，提升了应用卡顿检测的准确性和可靠性。此外，在应用卡顿检测的过程中，无需安装其他软件，简化了应用卡顿测试的操作，改善了用户体验。进一步地，根据调用目标函数的请求，确定应用在运行过程中的卡顿状态，可以定位卡顿在应用中所处的位置，对此次卡顿现象进行精确的重现，从而为开发人员解决卡顿问题提供了可靠依据。

为了实现上述实施例，本申请还提出一种计算机可读存储介质，其上存储有计算机程序，其特征在于，该程序被处理器执行时实现如本申请前述实施例提出的应用卡顿检测方法。

在本说明书的描述中，参考术语“一个实施例”、“一些实施例”、“示例”、“具体示例”、或“一些示例”等的描述意指结合该实施例或示例描述的具体特征、结构、材料或者特点包含于本申请的至少一个实施例或示例中。在本说明书中，对上述术语的示意性表述不必须针对的是相同的实施例或示例。而且，描述的具体特征、结构、材料或者特点可以在任一个或多个实施例或示例中以合适的方式结合。此外，在不相互矛盾的情况下，本领域的技术人员可以将本说明书中描述的不同实施例或示例以及不同实施例或示例的特征进行结合和组合。

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

流程图中或在此以其他方式描述的任何过程或方法描述可以被理解为，表示包括一个或更多个用于实现定制逻辑功能或过程的步骤的可执行指令的代码的模块、片段或部分，并且本申请的优选实施方式的范围包括另外的实现，其中可以不按所示出或讨论的顺序，包括根据所涉及的功能按基本同时的方式或按相反的顺序，来执行功能，这应被本申请的实施例所属技术领域的技术人员所理解。

在流程图中表示或在此以其他方式描述的逻辑和/或步骤，例如，可以被认为是用于实现逻辑功能的可执行指令的定序列表，可以具体实现在任何计算机可读介质中，以供指令执行系统、装置或设备(如基于计算机的系统、包括处理器的系统或其他可以从指令执行系统、装置或设备取指令并执行指令的系统)使用，或结合这些指令执行系统、装置或设备而使用。就本说明书而言，"计算机可读介质"可以是任何可以包含、存储、通信、传播或传输程序以供指令执行系统、装置或设备或结合这些指令执行系统、装置或设备而使用的装置。计算机可读介质的更具体的示例(非穷尽性列表)包括以下：具有一个或多个布线的电连接部(电子装置)，便携式计算机盘盒(磁装置)，随机存取存储器(RAM)，只读存储器(ROM)，可擦除可编辑只读存储器(EPROM或闪速存储器)，光纤装置，以及便携式光盘只读存储器(CDROM)。另外，计算机可读介质甚至可以是可在其上打印所述程序的纸或其他合适的介质，因为可以例如通过对纸或其他介质进行光学扫描，接着进行编辑、解译或必要时以其他合适方式进行处理来以电子方式获得所述程序，然后将其存储在计算机存储器中。

应当理解，本申请的各部分可以用硬件、软件、固件或它们的组合来实现。在上述实施方式中，多个步骤或方法可以用存储在存储器中且由合适的指令执行系统执行的软件或固件来实现。如，如果用硬件来实现和在另一实施方式中一样，可用本领域公知的下列技术中的任一项或他们的组合来实现：具有用于对数据信号实现逻辑功能的逻辑门电路的离散逻辑电路，具有合适的组合逻辑门电路的专用集成电路，可编程门阵列(PGA)，现场可编程门阵列(FPGA)等。

本技术领域的普通技术人员可以理解实现上述实施例方法携带的全部或部分步骤是可以通过程序来指令相关的硬件完成，所述的程序可以存储于一种计算机可读存储介质中，该程序在执行时，包括方法实施例的步骤之一或其组合。

此外，在本申请各个实施例中的各功能单元可以集成在一个处理模块中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个模块中。上述集成的模块既可以采用硬件的形式实现，也可以采用软件功能模块的形式实现。所述集成的模块如果以软件功能模块的形式实现并作为独立的产品销售或使用时，也可以存储在一个计算机可读取存储介质中。

上述提到的存储介质可以是只读存储器，磁盘或光盘等。尽管上面已经示出和描述了本申请的实施例，可以理解的是，上述实施例是示例性的，不能理解为对本申请的限制，本领域的普通技术人员在本申请的范围内可以对上述实施例进行变化、修改、替换和变型。

Claims (13)

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

在所述应用运行过程中，监测所述应用中各函数的调用状态；

在检测到所述应用中的目标函数被调用时，截获调用所述目标函数的请求，其中，所述目标函数为用于修改对象在应用客户端中呈现位置的函数；

根据所述调用所述目标函数的请求，确定所述应用在运行过程中的卡顿状态。

2.如权利要求1所述的方法，其特征在于，所述监测所述应用中各函数的调用状态，包括：

根据与各函数关联的钩子函数的被调用状态，监测各函数被调用状态。

3.如权利要求1所述的方法，其特征在于，所述根据所述调用所述目标函数的请求，确定所述应用在运行过程中的卡顿状态，包括：

对各调用所述目标函数的请求进行解析处理，以获取当前目标对象的标识、所述目标对象当前在所述应用客户端中的第一位置及所述目标对象待调整至的第二位置；

根据所述目标对象标识、所述第一位置及所述第二位置，生成当前的卡顿数据。

4.如权利要求3所述的方法，其特征在于，所述生成当前的卡顿数据之前，还包括：

获取所述目标对象当前的属性信息及所述目标对象当前所在的场景信息；

所述生成当前的卡顿数据，包括：

根据所述目标对象标识、第一位置、所述第二位置、所述目标对象当前的属性信息及所述目标对象当前所在的场景信息，生成当前的卡顿数据。

5.如权利要求4所述的方法，其特征在于，所述应用中包括N个场景；

所述目标对象当前所在的场景信息，包括：

当前时刻所述目标对象所在的目标场景标识，及当前时刻距离所述目标场景起始时刻的时长。

6.如权利要求3所述的方法，其特征在于，所述生成当前的卡顿数据之后，还包括：

将所述当前的卡顿数据，发送给服务器；

或者，

确定所述应用运行结束后，将所述应用运行过程中的所有卡顿数据，发送给所述服务器。

7.如权利要求3所述的方法，其特征在于，所述生成当前的卡顿数据之后，还包括：

判断所述应用当前的运行环境是否为测试环境；

若是，则将所述卡顿数据显示在所述应用画面的顶层。

8.如权利要求3-7任一所述的方法，其特征在于，所述生成当前的卡顿数据之后，还包括：

根据所述卡顿数据与各预设的卡顿模型的匹配度，确定当前的卡顿现象所属的类型。

9.如权利要求1所述的方法，其特征在于，所述检测到所述应用中的目标函数被调用之前，还包括：

获取服务器下发的目标对象的第二位置及所述目标对象当前在应用客户端中的第一位置；

比较分析所述第一位置与所述第二位置间的差值，确定所述差值未在预设范围内。

10.如权利要求1-7任一所述的方法，其特征在于，所述在检测到所述应用中的目标函数被调用之后，还包括：

获取所述应用中与预设时间段对应的前端算法及后台算法，其中，预设时间段为所述目标函数最近一次被调用的时间至当前时刻间的时间段；

根据所述前端算法及后台算法的差异，确定所述卡顿现象的原因。

11.一种应用卡顿检测装置，其特征在于，包括：

监测模块，用于在所述应用运行过程中，监测所述应用中各函数的调用状态。

截获模块，用于在检测到所述应用中的目标函数被调用时，截获调用所述目标函数的请求，其中，所述目标函数为用于修改对象在应用客户端中呈现位置的函数；

第一确定模块，用于根据所述调用所述目标函数的请求，确定所述应用在运行过程中的卡顿状态。

12.一种计算机设备，其特征在于，包括：存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，所述处理器执行所述程序时，实现如权利要求1-10中任一所述的方法。

13.一种计算机可读存储介质，其上存储有计算机程序，其特征在于，该程序被处理器执行时实现如权利要求1-10中任一所述的方法。