CN110941551A - 一种应用卡顿检测方法、装置、设备及计算机存储介质 - Google Patents

Abstract

本申请提供一种应用卡顿检测方法、装置、设备及计算机存储介质，涉及计算机技术领域，用以提升应用卡顿检测的效率。该方法包括：响应于被检测客户端的开启操作，创建虚拟环境；获取待测试函数地址集合，待测试函数地址集合包括至少一个待测试函数的函数调用地址，待测试函数包括与被检测客户端关联的目标进程对应的函数；根据待测试函数集合，将执行监控代码注入所述目标线程的所述待测试函数；通过执行监控代码，获得所述待测试函数在被检测客户端发生卡顿时的执行信息，所述执行信息用于确定致使被检测客户端卡顿的目标函数。该方法中确定了对应用的卡顿影响大的目标函数，进而通过监控目标函数进行应用卡顿检测，能提高应用的卡顿检测的效率。

Description

一种应用卡顿检测方法、装置、设备及计算机存储介质

技术领域

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

背景技术

在测试游戏客户端，以及用户使用游戏客户端过程中，都可能会出现游戏客户端卡顿的情况。游戏客户端出现卡顿的原因可能有很多种，通常通过监控大量游戏函数以及监控函数的运行情况，以获取游戏客户端卡顿的卡顿信息，进而根据卡顿信息确定产生卡顿的原因；

在获取卡顿信息时，需要注入和监控大量与游戏客户端相关的函数的运行情况，极大地影响了获取卡顿信息的效率，进而严重影响检测游戏卡顿的效率，对于其他应用的应用客户端进行卡顿检测时，也存在同样的问题。

发明内容

本申请实施例提供一种应用卡顿检测方法、装置、设备及计算机存储介质，用于提升应用的卡顿检测效率。

本申请第一方面，提供一种应用卡顿检测方法，包括：

响应于被检测客户端的开启操作，创建虚拟环境；

获取待测试函数地址集合，所述待测试函数地址集合包括至少一个待测试函数的函数调用地址，所述待测试函数包括与所述被检测客户端关联的目标进程对应的函数；

根据所述待测试函数集合，将执行监控代码注入所述目标线程的所述待测试函数；

通过所述执行监控代码，获得所述待测试函数在所述被检测客户端发生卡顿时的执行信息，所述执行信息用于确定致使所述被检测客户端卡顿的目标函数。

在一种可能的实现方式中，所述方法应用于游戏客户端，所述获取待测试函数地址集合，包括：

确定目标游戏进程的进程信息；

获取与所述进程信息对应的待测试函数地址集合。

本申请第二方面，提供一种应用卡顿检测装置，包括：

环境创建单元，用于响应于被检测客户端的开启操作，创建虚拟环境；

函数地址获取单元，用于获取待测试函数地址集合，所述待测试函数地址集合包括至少一个待测试函数的函数调用地址，所述待测试函数包括与所述被检测客户端关联的目标进程对应的函数；

代码注入单元，用于根据所述待测试函数集合，将执行监控代码注入所述目标线程的所述待测试函数；

目标函数确定单元，用于通过所述执行监控代码，获得所述待测试函数在所述被检测客户端发生卡顿时的执行信息，所述执行信息用于确定致使所述被检测客户端卡顿的目标函数。

在一种可能的实现方式中，所述执行信息包括所述待测试函数的执行时长，所述目标函数包括：

执行时长大于第一设定时长的待测试函数；或者

执行时长排序在第一指定序位的待测试函数。

在一种可能的实现方式中，所述装置还包括目标函数再次确定单元，所述目标函数再次确定单元用于，若所述目标函数的个数超过设定值，则执行至少一次目标函数再次确定操作，直至再次确定的目标函数的个数不超过设定值，所述目标函数再次确定操作包括：

将所述个数超过设定值的目标函数作为新的待测试函数，将所述待测试函数地址集合中的函数调用地址更新为所述新的待测试函数的函数调用地址；

根据更新后的待测函数地址集合，将所述执行监控代码注入所述新的待测试函数；

通过所述执行监控代码，获得所述新的待测试函数在所述被检测客户端发生卡顿时的新的执行信息，所述新的执行信息用于确定致使卡顿的再次确定的目标函数。

在一种可能的实现方式中，所述执行信息包括所述新的待测试函数的执行时长，所述再次确定的目标函数包括：

执行时长大于第二设定时长的所述新的待测试函数；或者

执行时长排序在第二指定序位的所述新的待测试函数。

在一种可能的实现方式中，所述执行信息还包括执行次数，所述目标函数确定单元还用于：

根据获得的执行次数确定所述被检测客户端发生卡顿的卡顿原因。

在一种可能的实现方式中，所述目标函数确定单元还用于：

获得所述被检测客户端发生卡顿时的卡顿信息；

根据所述卡顿信息确定所述被检测客户端发生卡顿的卡顿原因。

在一种可能的实现方式中，所述被检测客户端为游戏客户端，所述待测试函数包括如下一种或多种：

监控游戏场景资源的加载函数；

监控垃圾回收函数；

用于更新游戏数据的更新函数。

本申请第三方面，提供一种计算机设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，所述处理器执行所述程序时实现第一方面及任一种可能的实施方式中任一所述的方法。

本申请第四方面，提供一种计算机可读存储介质，所述计算机可读存储介质存储有计算机指令，当所述计算机指令在计算机上运行时，使得计算机执行如第一方面及任一种可能的实施方式中任一所述的方法。

由于本申请实施例采用上述技术方案，至少具有如下技术效果：

1)本申请实施例中，通过在虚拟环境中运行被检测客户端，再将卡顿检测代码注入到被检测客户端关联的目标进程中，由于被检测客户端是直接运行在虚拟环境中的，因此无需获得对应的终端设备的超级权限；且根据待测试函数地址集合将执行监控代码针对性地注入的方式，不受限于所使用的进程引擎，且在客户端对函数执行地址的注入而不是对函数的注入，客户端在进行数据整理与数据拼接的时候是通过地址进行操作的，性能开销低。

2)本申请实施例中，由于从大量的待测试函数中确定出了对卡顿影响大的目标函数，进而在卡顿检测时，监控确定出的目标函数即可快速准确地获得卡顿信息，确定出卡顿原因，提高了卡顿检测的效率。

3)上述被检测客户端为游戏客户端时，待测试函数包括用于更新游戏数据的更新函数，在确定目标函数的过程中获得了更新函数的执行信息，进而能获得大部分函数执行的信息，便于对游戏客户端的卡顿原因进行更全面的分析定位。

附图说明

图1为本申请实施例提供的一种卡顿检测客户端的处理机制示例图示意图；

图2为本申请实施例提供的一种确定目标函数的应用场景示例图；

图3为本申请实施例提供的一种目标函数确定方法的过程示意图；

图4为本申请实施例提供的一种添加待检测客户端过程的界面变化示例图；

图5为本申请实施例提供的一种由检测客户端确定新的目标函数的过程示意图；

图6为本申请实施例提供的一种由服务器确定新的目标函数的过程示意图；

图7为本申请实施例提供的一种应用目标函数检测游戏客户端卡顿的场景示例图；

图8为本申请实施例提供的一种根据目标函数监控游戏客户端是否卡顿的过程示意图；

图9为本申请实施例提供的一种显示卡顿问题上传状态的界面示意图；

图10为本申请实施例提供的一种卡顿原因分析的时序图；

图11为本申请实施例提供的一种卡顿原因的分析结果展示界面示意图；

图12为本申请实施例提供的一种应用卡顿检测装置的结构图；

图13为本申请实施例提供的另一种应用卡顿检测装置的结构图；

图14为本申请实施例提供的一种终端设备的结构图。

具体实施方式

为了更好的理解本申请实施例提供的技术方案，下面将结合说明书附图以及具体的实施方式进行详细的说明。

为了便于本领域技术人员更好地理解本申请的技术方案，下面对本申请涉及的技术术语进行说明。

虚拟环境：本申请中是指用于支持被检测客户端运行的环境，该环境可以是与终端设备的操作系统相对独立的运行环境，例如可以是模拟的操作系统等，该模拟的操作系统不同于终端设备的真实操作系统，该模拟的操作系统仅存在于卡顿检测客户端中。

待测试函数：被检测客户端在运行过程中调用的部分或全部函数。

引擎：支持代码运行的核心组件，用于辅助支持客户端的运行。不同的客户端所对应的引擎类型可能不相同，也可能相同。例如游戏客户端的引擎类型包括Unity3D(又可以简写为U3D)、il2cpp以及UE4等。

Profiler工具：一种性能深度定位分析工具，不同的引擎会提供不同的性能分析工具。

Development性能包：一种开发版本的性能包，会根据引擎设计向某些固定的socket端口写全量的性能信息，供性能定位使用。

终端设备：可以是移动终端、固定终端或便携式终端，例如移动手机、站点、单元、设备、多媒体计算机、多媒体平板、互联网节点、通信器、台式计算机、膝上型计算机、笔记本计算机、上网本计算机、平板计算机、个人通信系统(PCS)设备、个人导航设备、个人数字助理(PDA)、音频/视频播放器、数码相机/摄像机、定位设备、电视接收器、无线电广播接收器、电子书设备、游戏设备或者其任意组合，包括这些设备的配件和外设或者其任意组合。

下面对本申请的设计思想进行说明。

在测试应用的被检测客户端，以及用户使用被检测客户端过程中，都可能会出现被检测客户端卡顿的情况。被检测客户端出现卡顿的原因可能有很多种，通常通过监控大量相关函数的运行情况，以获取卡顿信息以及卡顿原因，由于上述过程需要监控大量函数的运行情况，严重影响检测游戏卡顿的效率，在对被检测客户端进行卡顿检测时对检测工具的依赖性强，且检测过程复杂，如在对游戏客户端进行卡顿检测时，常通过游戏引擎提供的Profiler工具，构建Development版本包，在测试场景中对被测游戏场景进行复现，然后监控大量与目标进程关联函数以及各种监控函数的执行情况，去确定游戏客户端是否发生卡顿以及卡顿原因，但是上述过程具有如下缺陷：

1)通过监控大量函数的执行情况判断游戏客户端是否发生卡顿，消耗资源大，且由于需要监控的函数量大，会严重影响检测卡顿的效率。

2)在检测卡顿时，对检测工具的依赖性很大，必须通过特定的引擎如Unity3D引擎，对其他引擎如cocos2引擎或其他自研发引擎不支持；且需要特定引擎提供的特定检测工具如Profiler、特定检测版本包如Development版本包进行

3)在每次进行卡顿检测及卡顿原因分析时，都需要重新构建Development版本包，在测试环境进行游戏场景的复现，检测卡顿的过程复杂。

鉴于此，发明人设计了一种应用卡顿检测方法、装置、设备及计算机存储介质，该方法可以通过终端设备中的软件模块执行，例如终端设备中的卡顿检测客户端、小程序等。该方法通过为其它被检测客户端创建虚拟环境，并获取待测试函数地址集合，在虚拟环境中拉起被检测客户端，在被检测客户端运行过程中，根据待测试函数地址集合将执行监控代码进行针对性的注入，进而通过执行监控代码获得待测试函数在被检测客户端发绳卡顿时的执行信息，根据执行信息确定致使被检测客户端卡顿的目标函数。

可以根据被检测客户端关联的目标进程的进程信息，获取与上述目标进程对应的待测试函数地址集合，这样一来，便可以确定出不同目标进程的目标函数，进而通过监控目标函数检测卡顿，提升检测卡顿的效率。

进一步地，若卡顿检测客户端确定出执行信息后，还可由终端设备将上述执行信息发送给服务器，服务器进一步根据执行信息确定致使卡顿的目标函数。

为了更清楚地理解本申请的设计思路，以下以卡顿检测客户端确定目标函数的处理机制进行示例介绍。

请参照图1，表示一种卡顿检测客户端的处理机制示例图，或者也可以表示一种终端设备的内部架构示意图。图1中通过卡顿检测客户端120检测卡顿并确定目标函数。在用户安装被检测客户端110之后，卡顿检测客户端120可以通过终端设备100的接口获取被检测客户端110的基本信息。接口例如终端设备100中的应用列表getApplist接口。基本信息包括包名，包名是指客户端对应的安装包的名称。基本信息还可以包括被检测客户端110的应用名称、应用图标、引擎类型、目标进程的进程信息中的一种或几种组合等。在卡顿检测客户端120获取基本信息之后，卡顿检测客户端120就可以在其界面上显示该被检测客户端110的基本信息。

当用户想要进行卡顿检测时，用户可以在卡顿检测客户端120中开启被检测客户端110，例如用户可以点击该被检测客户端110，卡顿检测客户端120会创建虚拟环境，虚拟环境用于为被检测客户端110提供运行环境，例如虚拟应用(virtual Application，VA)。被检测客户端110可以在虚拟环境中启动运行，此时，卡顿检测客户端120可以将卡顿检测代码注入到被检测客户端110中，实现对被检测客户端110的卡顿检测。

其中，被检测客户端110可以是任意类型的客户端，例如游戏客户端、视频客户端、查询信息类应用客户端等等，本申请不限制被检测客户端110的具体类型。

请继续参照图1，被检测客户端110以游戏客户端为例，执行监控代码可以实现对被检测客户端110中各个待检测函数130的执行时间的检测。

在介绍完本申请实施例的设计思想之后，下面对本申请实施例的技术方案能够适用的应用场景做一些简单介绍，需要说明的是，以下介绍的应用场景仅用于说明本申请实施例而非限定。在具体实施过程中，可以根据实际需要灵活地应用本申请实施例提供的技术方案。

请参照图2，表示一种应用场景示例图。该应用场景中包括多个终端设备100和服务器200，每个终端设备100中安装有卡顿检测客户端120和被检测客户端110，卡顿检测客户端120可以与服务器200之间相互通信，卡顿检测客户端120检测得到被检测客户端110的卡顿信息以及待测试函数在被检测客户端发生卡顿时的执行信息。

卡顿检测客户端120在检测得到待测试函数在被检测客户端发生卡顿时的执行信息，可以根据该执行信息从待检测函数中确定出致使卡顿的目标函数，或者将获得的执行信息发送给服务器，由服务器根据上述执行信息从待检测函数中确定出致使卡顿的目标函数。

卡顿检测客户端在检测到的被检测客户端110的卡顿信息之后，可以将该卡顿信息反馈给服务器200，服务器200根据该卡顿信息，分析被检测客户端110的卡顿原因，服务器200可以向各个终端设备100反馈卡顿原因，使得用户可以及时地根据卡顿原因进行处理。服务器200也可以将卡顿信息以及对应的卡顿原因存储，并提示工作人员，及时地解决卡顿问题。

本申请实施例中涉及的目标函数确定方法可以适用于用户使用被检测客户端110过程中，实时检测被检测客户端110的目标函数和/或卡顿原因，也可以适用于应用测试过程中，便于工作人员获得容易致使卡顿的目标函数，或者及时处理被检测客户端110的卡顿原因。

本申请的卡顿检测客户端120可以采用ARM处理器，且上述卡顿检测客户端120可以应用在安卓平台、微软平台、虚拟机平台等；服务器200可以包括采用X86结构的服务器如数据库服务器、网络服务器等。

基于图2的应用场景，下面对本申请实施例中涉及的应用卡顿检测方法进行示例说明。

请参照图3，表示本申请实施例设计的应用卡顿检测方法的交互示意图，该交互过程具体如下：

步骤S301，卡顿检测客户端120获取被检测客户端110的基本信息。

具体的，如前文图1中论述的内容，卡顿检测客户端120可以通过终端设备100中的接口获取终端设备100中安装的客户端列表，客户端列表包括一个或多个客户端的基本信息，以游戏客户端作为被检测客户端为例，基本信息可以为游戏进程的游戏安装包(AndroidPackage，APK)，该游戏安装包中可以包括游戏应用名称以及游戏安装程序等，基本信息也可以参照前文论述的内容，此处不再赘述。卡顿检测客户端120可以是周期性地通过接口获取客户端列表，也可以是当终端设备100中出现新安装的客户端时，就可以通过接口实时获取客户端列表。

作为一种实施例，卡顿检测客户端120可以获取终端设备100中所有安装的客户端的基本信息，响应于用户的选择操作，卡顿检测客户端120可以根据用户选择的客户端，将该客户端作为被检测的客户端。

例如，请参照图4，卡顿检测客户端120拉取的客户端列表如图4中a所示，该客户端列表中包括应用A、应用B以及应用C，例如应用A的基本信息包括应用A的应用名称、包名(com.x.yingyongA)以及应用A的应用图标等。用户点击添加控件401之后，添加应用B，此时卡顿检测客户端120中增加应用B的基本信息，如图4中b所示，当用户点击图4中的开启控件402时，可以运行应用B，点击历史卡顿检测查看控件403时，可以查看该应用之前的卡顿信息等。

步骤S302，卡顿检测客户端120响应于被检测客户端110的开启操作，创建虚拟环境。

具体的，被检测客户端可能有多个，用户可以在卡顿检测客户端120中点击自己想要运行的客户端，卡顿检测客户端120响应于被检测客户端110的开启操作，准备开启被检测客户端110，卡顿检测客户端120可以创建与该被检测客户端110对应的虚拟环境。

作为一种实施例，用户可以开启多个被检测客户端110，卡顿检测客户端120可以支持开启多个服务，每个服务创建对应的虚拟环境，为对应的被检测客户端110提供服务，实现对多个被检测客户端110同时进行卡顿检测。

当然，当用户开启被检测客户端110的数量超过预设数量时，卡顿检测客户端120可以提示用户当前已无法支持过多的被检测客户端110的运行。由于卡顿检测客户端120的资源是有限的，本申请实施例限制用户开启的被检测客户端110的数量，可以避免卡顿检测客户端120过载而崩溃的情况。

作为一种实施例，虚拟环境可以是虚拟机，虚拟机可以适用于大多数的客户端的运行；例如，请继续参照图4，用户可以点击开启控件402，相当于用户进行对应用B的开启操作，卡顿检测客户端120创建相应的虚拟环境。

步骤S303，卡顿检测客户端120根据基本信息，获取待测试函数地址集合；

具体地，卡顿检测客户端120可以将与被检测客户端关联的目标进程对应的函数作为待测试函数，获取待测试函数的函数调用地址作为待测试函数地址集合，具体可包括如下步骤S3031和步骤S3032。

步骤S3031，检测客户端120可以将在步骤S301中获取的被检测客户端110的基本信息发送给服务器200；

步骤S3031，服务器200获取与基本信息对应的待测试函数的函数调用地址，将获取的函数调用地址作为待测试函数地址集合发送给卡顿检测客户端120。

此处以游戏客户端作为被检测客户端110进行示例性说明，游戏客户端通常卡顿的原因包括游戏画面造成的卡顿，因此在对游戏客户端进行卡顿检测时，通常是需要对用于形成画面的函数进行监控，但是对于不同的引擎类型游戏客户端，游戏客户端对应的形成画面的函数是不同的，因此，本申请实施例中，卡顿检测客户端120还可以根据游戏客户端对应的引擎类型，获得与该被检测客户端110的引擎类型匹配的待测试函数的函数调用地址。

具体的，卡顿检测客户端120可以预存有获取待测试函数地址的关系，卡顿检测客户端120在获得被检测客户端110的引擎类型之后，可以获取该引擎类型对应待测试函数的函数调用地址添加到待测试函数地址集合中，从而获得与该引擎类型所对应的待测试函数地址结合。

作为一种实施例，被检测客户端110为游戏客户端时，上述待测试函数包括如下一种或多种函数：

监控游戏场景资源的加载函数，可以但不局限于包括监控游戏场景资源的加载函数，上述加载函数可以但不局限于包括用于游戏场景资源的初始化、加载、卸载等操作的函数。

监控垃圾回收函数，可以但不局限于包括gc Allocate函数、回收游戏垃圾的函数、垃圾回收异步处理函数。

用于更新游戏数据的更新函数，可以打不局限于包括游戏的update函数、laterupdate函数、ctor函数。

步骤S304，卡顿检测客户端120根据所述待测试函数集合，将执行监控代码注入与被检测客户端110关联的目标线程的待测试函数中。

具体地，如果卡顿检测客户端120想获得被待测试函数在被检测客户端发生卡顿时的执行时长，则需要生成用于检测执行时长的执行监控代码，该执行监控代码可以按照一定形式注入待测试函数，以通过该执行监控代码获取待测试函数的执行时长。

作为一种实施例，待测试函数地址集合中的函数调用地址可以按照一定规则排序，卡顿检测客户端120可以按照待测试函数地址集合中的函数调用地址的排序，将执行监控代码依次注入待测试函数，卡顿检测客户端120也可以按照其他方式将控执行代码注入待测试函数，此处不做过多限定。

执行监控代码注入待测试函数的方式与执行监控代码的逻辑有关，此处对执行监控代码注入待测试函数的方式不做限定，如在代码逻辑允许的情况下，可以将执行监控代码对应的代码片段分别注入待测试函数的开始和结束，或者检测客户端通过执行监控函数在被检测客户端110的目标进程中进行插桩操作，从而实现将执行监控代码注入待测试函数。执行监控代码可以利用hook技术，修改待测试函数的返回数据地址，从而获得各个待测试函数的运行信息等。

步骤S305，卡顿检测客户端120通过执行监控代码，获取待测试函数在所述被检测客户端发生卡顿时的执行信息。

具体地，卡顿检测客户端120在检测到被检测客户端发生卡顿时，通过执行监控函数获取各个待测试函数在卡顿期间的执行信息，上述执行信息可以包待测试函数的执行时长。

步骤S306，卡顿检测客户端120可以根据获得的执行信息，从待测试函数中确定出导致卡顿的目标函数。

作为一种实施例，步骤S306也可以由服务器执行，步骤S306可以替换为如下步骤S3061和步骤S3062。

步骤S3061，卡顿检测客户端120将执行信息发送给服务器；

步骤S3062，服务器200根据获得的执行信息，待测试函数中确定出导致卡顿的目标函数。

具体地，执行信息包括执行时长时，可以但不局限于按照如下两种方式中的一种或结合确定目标函数：

第一种目标函数确定方法：将执行时长大于第一设定时长的待测试函数确定为目标函数。

由于在被检测客户端发生卡顿时，执行时长较大的函数会消耗更多的资源，进而容易使卡顿更严重，因此将这部分函数确定出来，在之后的卡顿检测中重点监控这部分函数，将会提升卡顿检测的效率。

上述第一设定时长可由本领域的技术人员根据测验获得，此处对第一设定时长的来源及数值不做过多限定，在本实施例中，可以将上述第一设定时长设置为100毫秒。

第二种目标函数确定方法：将执行时长排序在第一指定序位的待测试函数确定为目标函数。

卡顿检测客户端120或服务器200在获得各个待测试函数的执行时长后，可以按照执行时长从大至小的顺序排列，具体可参照表1。

表1：

执行时长1	待测试函数1
		执行时长2	待测试函数2、待测试函数3、待测试函数4
执行时长3	待测试函数5、待测试函数6、…
		…	…
…	…
		执行时长n	待测试函数m

表1中，执行时长1至执行时长n表示从大到小的各个执行时长，其中n为正整数，仅为了便于理解，用以表示执行时长的编号；表1中的待测试函数1至待测试函数m仅表示不同的待测试函数的标识信息，其中m为正整数，仅为了便于理解，用以表示待测试函数的标识信息的编号。

请参见表1，在被检测客户端发生卡顿时，不同的待测试函数的执行时长可能相同，如表1中的待测试函数1至待测试函数3的执行时长相同。

上述第一指定序位可以但不局限于为表1中执行时长1至执行时长i对应的位置，i为大于1小于n的正整数，用以辅助表示第一指定序位，如将i的值设定为500，则表示表1中与执行时长1至执行时长500对应的待测试函数为目标函数。

作为一种实施例，按照上述方法，从待测试函数中确定出的目标函数的个数有可能仍然较多，此时可以按照下述方法，从已确定的目标函数中筛选出对卡顿影响相对较重的函数，作为最终的目标函数。

在步骤S306确定出目标函数后，若目标函数的个数超过设定值，则执行至少一次目标函数再次确定操作，直至再次确定的目标函数的个数不超过设定值，上述目标函数再次确定操作包括如下两种场景。

对上述设定值不做过多限定，本领域的技术人员可根据实际需求设置，如将其设置成2000、2500、3000等。

第一种场景，由检测客户端确定新的目标函数。

请参见图5，具体包括：

卡顿检测客户端120将最近一次确定的目标函数作为新的待测试函数，将待测试函数集合中的函数调用地址更新为新的待测试函数的函数调用地址，获得新的待测试函数集合；

卡顿检测客户端120根据新的待测试函数地址集合，将上述执行监控代码注入新的待测试函数；

卡顿检测客户端120在被检测客户端执行过程中，通过执行监控代码，获得上述新的待测试函数在被检测客户端发生卡顿时的新的执行时间。

卡顿检测客户端120根据新的执行时间，从新的待测试函数中确定新的目标函数。

第二种场景，由服务器200确定新的目标函数。

请参见图6，具体包括：

服务器200将最近一次确定的目标函数作为新的待测试函数，将待测试函数集合中的函数调用地址更新为新的待测试函数的函数调用地址，获得新的待测试函数集合并发送给卡顿检测客户端120；

卡顿检测客户端120根据新的待测试函数地址集合，将上述执行监控代码注入新的待测试函数；

卡顿检测客户端120在被检测客户端执行过程中，通过执行监控代码，获得上述新的待测试函数在被检测客户端发生卡顿时的新的执行时间，并将新的执行时间发送给服务器200。

服务器200根据新的执行时间，从新的待测试函数中确定新的目标函数。

作为一种实施例，上述卡顿检测客户端120或服务器200，可以将执行时长大于第二设定时长的新的待测试函数确定为新的目标函数，其中，可以将第二设定时长设置为与上述第一设定时长相等，或，将第二设定时长设置为略高于第一设定时长，如第一设定时长为100毫秒时，第二设定时长可以为110毫秒或120毫秒等。

上述卡顿检测客户端120或服务器200，还可以将获取的新的执行时长进行排序，将执行时长排序在第二指定序位的新的待测试函数确定为新的目标函数，其中，可以按照上述表1部分的叙述将新的执行时长进行排序，此处不再重复叙述。

由于同一待测试函数在被检测客户端不同的卡顿情况下的执行情况可能不同，即同一待测试函数的新的执行时长可能与之前的执行时长不一致，上述第二指定序位可以与上述第一指定序位包含的执行时长的范围一致，上述第二指定序位包含的执行时长的范围也可以略小于或略大于第一指定序位包含的执行时长的范围。

在卡顿检测客户端120或服务器200确定目标函数或新的目标函数后，可以将确定的目标函数或新的目标函数的函数调用地址更新到待测试函数地址集合中，并将更新的待测试函数地址保存在卡顿检测客户端或服务器上。

作为一种实施例，上述执行信息还包括待测试函数的调用次数，卡顿检测客户端120在获取各个待测试函数在被检测客户端110发生卡顿时的调用次数后，可以将获取的调用次数发送给服务器200，以便服务器200根据各个待测试函数的调用次数确定卡顿原因。

作为一种实施例，卡顿检测客户端在获取各待测试函数的执行信息时，还可以获取被检测客户端发生卡顿时的卡顿信息，进而将获得的卡顿信息发送给服务器200，以便服务器200根据卡顿信息确定卡顿原因。

上述卡顿信息可以但不局限于包括被检测客户端110发生卡顿时的卡顿截图、卡顿波形图、卡顿时间点。

服务器200可以结合接收的执行信息和卡顿信息确定卡顿原因，并将执行信息和卡顿信息与卡顿原因进行关联成一个卡顿记录，以后后续可以根据卡顿记录快速定位卡顿原因。

在服务器200确定出卡顿原因之后，还可以将卡顿原因反馈给卡顿检测客户端120。卡顿检测客户端120在接收到卡顿原因之后，可以显示卡顿原因，以便于用户及时查看卡顿原因，或者便于用户解决部分卡顿原因。

以游戏客户端作为上述被检测客户端进行示例性说明，可以通过上述方法从与游戏相关的大量的函数中筛选出容易致使游戏客户端发生卡顿的目标函数，进而可以通过监控目标函数的执行情况判断客户端是否卡顿，能提升判断游戏卡顿的效率。

以下以游戏客户端作为被检测客户端为例，提供一种应用目标函数检测游戏客户端卡顿的场景，请参照图7，该场景中包括卡顿检测客户端710，服务器720，其中，所述卡顿检测客户端710可以采用ARM(Advanced RISC Machine)结构的处理器，服务器720可以是采用X86架构处理器的服务器如卡顿检测服务器、数据库服务器、web服务器等。

上述卡顿检测客户端710可以采用安卓系统，数据库服务器和卡顿检测服务器可以采用windows xp版本及以上版本的操作系统，web服务器可以采用linux操作系统。

Web服务器可以在web端修改卡顿检测的参数配置，所述参数可以包括游戏客户端的包名、APK名称、卡顿检测模型版本、目标函数地址集合信息等，并将获取的参数配置写入数据库服务器。

卡顿检测客户端在游戏客户端启动后获取游戏的基本信息，根据基本信息构造配置请求包，请求从数据库服务器中获取卡顿检测的参数配置，进而对游戏客户端进行卡顿检测。

请参照图8，提供一种根据目标函数监控游戏客户端是否卡顿的方法，具体包括：

步骤S801，卡顿检测客户端响应于游戏客户端的开启操作，启动游戏客户端，以及开启卡顿分析功能；

步骤S802，卡顿检测客户端获取游戏客户端的基本信息，并根据基本信息从服务器拉取对应的目标函数地址集合。

上述基本信息可以是游戏客户端已经启动的游戏进程的进程信息或游戏客户端的APK名称等；卡顿检测客户端在游戏客户端启动时，将so文件注入到游戏客户端对应的线程中，进而卡顿检测客户端可以根据APK名称获取对应的目标函数地址集合。

上述目标函数地址集合中包括，按照上述应用卡顿检测方法从与上述游戏进程对应的待测试函数中确定出的目标函数的函数调用地址，确定出的目标函数是容易导致游戏客户端卡顿的函数。

步骤S803，卡顿检测客户端在游戏客户端进入游戏场景后，根据获取的目标函数地址集合，监控目标函数的执行情况。

步骤S804，卡顿检测客户端若根据目标函数的执行情况确定游戏客户端发生卡顿，则确定卡顿问题并发送给服务器。

上述卡顿问题可以包括卡顿信息，以及根据卡顿信息确定的卡顿原因。

例如，请参照图9，表示一种卡顿检测客户端上传卡顿问题后的界面示意图。卡顿检测客户端120在确定卡顿问题之后，可以存储卡顿问题，并将卡顿问题反馈给服务器200，并显示该测试记录中显示已上传。

步骤S805，服务器接收并显示卡顿问题，以及根据指示处理卡顿问题。

技术人员可在控制游戏的后台服务器上确认提交的卡顿问题是否准确，若准确则结束流程，若提交的卡顿问题不准确，则技术人员可以指示卡顿检测客户端监控与游戏进程对应的所有待测试函数的执行情况，并根据所有待测试函数的执行情况再次确定卡顿问题。

服务器可以通过下面几类函数的执行情况对卡顿问题的卡顿原因进行分析，具体可参照图10的卡顿原因分析的时序图，在该时序图中主要包括卡顿模型检测部分、监控目标函数部分和服务端，其中，目标函数包括游戏场景资源的加载函数、垃圾回收函数GC、用于更新游戏数据的更新UPDATE函数。

服务器在对卡顿原因进行分析后，可以展示卡顿原因的分析结果，请参见图11，可以展示发生卡顿的卡顿类型、卡顿时间点、卡顿时长、卡顿的严重等级、卡顿坐标、卡顿截图、卡顿函数帧耗时数据流、卡顿函数帧耗时等，其中图11中展示出了三种卡顿即毛刺卡顿、连帧卡顿和连续卡顿等，且图11中显示的毛刺卡顿是由于GC函数导致的，显示的连帧卡顿是由加载游戏场景导致的，显示的连续卡顿是由UI切换导致的，技术人员在得知上述卡顿原因后，更便于针对上述不同卡顿原因快速解决卡顿问题。

在上述方法中，通过监控确定出的目标函数的执行情况，能更便捷快速地判断游戏客户端在运行过程中的卡顿问题，不需要依赖于特殊的卡顿分析工具，且适用于所有的游戏引擎；通过只注入目标地址函数中有限个目标函数，以监控目标函数的运行情况的方式检测游戏卡顿问题，能提升检测卡顿的效率，且这种检测方式，不需要构建特殊的分析性能包如Development版本包等，且在普通的测试场景便能开启卡顿分析功能，遇到卡顿问题可以智能分析，无需在特定的游戏测试环境中对卡顿问题进行复现，简化了游戏卡顿检测的过程。

本申请的方案中，根据代检测函数地址集合针对性地将执行监控代码注入，进而通过执行监控代码获取的各待测试函数的执行信息，从待测试函数中确定出易导致被检测客户端卡顿的目标函数，进而可以通过监控目标函数的执行情况的方式，更便捷快速地判断被检测客户端是否发生卡顿，提高了应用的卡顿检测的效率。

请参照图12，基于同一发明构思，本申请实施例提供一种应用卡顿检测装置1200，包括：

环境创建单元1201，用于响应于被检测客户端的开启操作，创建虚拟环境；

函数地址获取单元1202，用于获取待测试函数地址集合，所述待测试函数地址集合包括至少一个待测试函数的函数调用地址，所述待测试函数包括与所述待测试客户端关联的目标进程对应的函数；

代码注入单元1203，用于根据所述待测试函数集合，将执行监控代码注入所述目标线程的所述待测试函数；

目标函数确定单元1204，用于通过所述执行监控代码，获得所述待测试函数在所述被检测客户端发生卡顿时的执行信息，所述执行信息用于确定致使上述被检测客户端卡顿的目标函数。

在一种可能的实施例中，所述执行信息包括所述待测试函数的执行时长，所述目标函数包括：

执行时长大于第一设定时长的待测试函数；或者

执行时长排序在第一指定序位的待测试函数。

在一种可能的实施例中，所述装置还包括目标函数再次确定单元，所述目标函数再次确定单元用于，若所述目标函数的个数超过设定值，则执行至少一次目标函数再次确定操作，直至再次确定的目标函数的个数不超过设定值，所述目标函数再次确定操作包括：

将所述个数超过设定值的目标函数作为新的待测试函数，将所述待测试函数地址集合中的函数调用地址更新为所述新的待测试函数的函数调用地址；

根据更新后的待测函数地址集合，将所述执行监控代码注入所述新的待测试函数；

通过所述执行监控代码，获得所述新的待测试函数在所述被检测客户端发生卡顿时的新的执行信息，所述新的执行信息用于确定致使卡顿的再次确定的目标函数。

在一种可能的实施例中，所述执行信息包括所述新的待测试函数的执行时长，所述再次确定的目标函数包括：

执行时长大于第二设定时长的所述新的待测试函数；或者

执行时长排序在第二指定序位的所述新的待测试函数。

在一种可能的实现方式中，所述执行信息还包括执行次数，所述目标函数确定单元还用于：

根据获得的执行次数确定所述被检测客户端发生卡顿的卡顿原因。

在一种可能的实现方式中，所述目标函数确定单元还用于：

获得所述被检测客户端发生卡顿时的卡顿信息；

根据所述卡顿信息确定所述被检测客户端发生卡顿的卡顿原因。

在一种可能的实现方式中，所述被检测客户端为游戏客户端，所述待测试函数包括如下一种或多种：

监控游戏场景资源的加载函数；

监控垃圾回收函数；

用于更新游戏数据的更新函数。

作为一种实施例，图12中的装置可以用于实现前文论述的任意一种应用卡顿检测方法。

基于同一发明构思，本申请实施例提供一种应用卡顿检测装置，该装置相当于前文论述的被检测客户端110，请参照图13，该装置1300包括收发模块1301和处理模块1302，其中：

收发模块1301，用于在处理模块1302的控制下，在虚拟环境内运行，并接收执行监控代码；其中，虚拟环境是响应于被检测客户端的开启操作时，为被检测客户端创建的运行环境，执行监控代码用于监控被检测客户端关联的进程中，待测试函数在被检测客户端发生卡顿时的执行情况；以及，根据执行监控代码，上报在运行过程中待测试函数的执行信息，其中待测试函数的种类可参照上述方法侧实施例的描述。

作为一种实施例，图13中的装置可以用于实现前文论述的目标函数确定方法。

基于同一发明构思，本申请实施例提供一种终端设备，下面对该终端设备进行介绍。

请参照图14，该终端设备100包括显示单元1440、处理器1480以及存储器1420，其中，显示单元1440包括显示面板1441，用于显示由用户输入的信息或提供给用户的信息以及卡顿检测客户端120和被检测客户端110的各种操作界面等，在本申请实施例中主要用于显示终端设备100中已安装的客户端的界面、快捷窗口等。

可选的，可以采用液晶显示器(Liquid Crystal Display，LCD)或有机发光二极管OLED(Organic Light-Emitting Diode)等形式来配置显示面板1441。

处理器1480用于读取计算机程序，然后执行计算机程序定义的方法，例如处理器1480读取卡顿检测应用以及被检测应用等，从而在该终端设备100上运行应用，在显示单元1440上显示应用的界面。处理器1480可以包括一个或多个通用处理器，还可包括一个或多个DSP(Digital Signal Processor，数字信号处理器)，用于执行相关操作，以实现本申请实施例所提供的技术方案。

存储器1420一般包括内存和外存，内存可以为随机存储器(RAM)，只读存储器(ROM)，以及高速缓存(CACHE)等。外存可以为硬盘、光盘、USB盘、软盘或磁带机等。存储器1420用于存储计算机程序和其他数据，该计算机程序包括客户端对应的应用程序等，其他数据可包括操作系统或应用程序被运行后产生的数据，该数据包括系统数据(例如操作系统的配置参数)和用户数据。本申请实施例中程序指令存储在存储器1420中，处理器1480执行存储其中存储器1420中的程序指令，实现前文图论述的任意的一种目标函数确定方法。

此外，终端设备100还可以包括显示单元1440，用于接收输入的数字信息、字符信息或接触式触摸操作/非接触式手势，以及产生与终端设备100的用户设置以及功能控制有关的信号输入等。具体地，本申请实施例中，该显示单元1440可以包括显示面板1441。显示面板1441例如触摸屏，可收集用户在其上或附近的触摸操作(比如用户使用手指、触笔等任何适合的物体或附件在显示面板1441上或在显示面板1441的操作)，并根据预先设定的程式驱动相应的连接装置。可选的，显示面板1441可包括触摸检测装置和触摸控制器两个部分。其中，触摸检测装置检测玩家的触摸方位，并检测触摸操作带来的信号，将信号传送给触摸控制器；触摸控制器从触摸检测装置上接收触摸信息，并将它转换成触点坐标，再送给处理器1480，并能接收处理器1480发来的命令并加以执行。在本申请实施例中，若用户点击被检测客户端110，则在显示面板1441中的触摸检测装置检测到触摸操作，则将检测到的触摸操作对应的信号发送的触摸控制器，触摸控制器将信号转换成触点坐标发送给处理器1480，处理器1480根据接收到的触点坐标确定用户需要对被检测客户端110进行卡顿检测。

其中，显示面板1441可以采用电阻式、电容式、红外线以及表面声波等多种类型实现。除了显示单元1440，终端设备100还可以包括输入单元1430(包括图像输入设备1431和其他输入设备1432)，输入单元1430可以包括但不限于物理键盘、功能键(比如音量控制按键、开关按键等)、轨迹球、鼠标、操作杆等中的一种或多种。

除以上之外，终端设备100还可以包括用于给其他模块供电的电源1490、音频电路1460、近场通信模块1470和RF电路。终端设备100还可以包括一个或多个传感器1450，例如加速度传感器、光传感器、压力传感器等。音频电路1460具体包括扬声器1461和麦克风1462等，例如终端设备100可以通过麦克风1462采集用户的声音，进行相应的操作等。

作为一种实施例，处理器1480的数量可以是一个或多个，处理器1480和存储器1420可以是耦合设置，也可以是相对独立设置。

作为一种实施例，图14中的处理器1480可以用于实现如图12中的环境创建模块1201、函数地址获取单元1202、代码注入单元1203和目标函数确定单元1204的功能。

作为一种实施例，图14中的处理器1480可以用于实现如图13中的处理模块1301和收发模块1302的功能。

作为一种实施例，图14中的处理器1480可以用于实现前文论述的卡顿检测客户端120的功能，和/或被检测客户端的110功能。

基于同一技术构思，本申请实施例还一种计算机可读存储介质，该计算机可读存储介质存储有计算机指令，当所述计算机指令在计算机上运行时，使得计算机执行如前文论述的目标函数确定方法。

本领域内的技术人员应明白，本申请的实施例可提供为方法、系统、或计算机程序产品。因此，本申请可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本申请可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。

显然，本领域的技术人员可以对本申请进行各种改动和变型而不脱离本申请的精神和范围。这样，倘若本申请的这些修改和变型属于本申请权利要求及其等同技术的范围之内，则本申请也意图包含这些改动和变型在内。

Claims (10)

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

响应于被检测客户端的开启操作，创建虚拟环境；

获取待测试函数地址集合，所述待测试函数地址集合包括至少一个待测试函数的函数调用地址，所述待测试函数包括与所述被检测客户端关联的目标进程对应的函数；

根据所述待测试函数集合，将执行监控代码注入所述目标线程的所述待测试函数；

通过所述执行监控代码，获得所述待测试函数在所述被检测客户端发生卡顿时的执行信息，所述执行信息用于确定致使所述被检测客户端卡顿的目标函数。

2.如权利要求1所述的方法，其特征在于，所述执行信息包括所述待测试函数的执行时长，所述目标函数包括：

执行时长大于第一设定时长的待测试函数；或者

执行时长排序在第一指定序位的待测试函数。

3.如权利要求1所述的方法，其特征在于，还包括：

若所述目标函数的个数超过设定值，则执行至少一次目标函数再次确定操作，直至再次确定的目标函数的个数不超过设定值，所述目标函数再次确定操作包括：

将所述个数超过设定值的目标函数作为新的待测试函数，将所述待测试函数地址集合中的函数调用地址更新为所述新的待测试函数的函数调用地址；

根据更新后的待测函数地址集合，将所述执行监控代码注入所述新的待测试函数；

通过所述执行监控代码，获得所述新的待测试函数在所述被检测客户端发生卡顿时的新的执行信息，所述新的执行信息用于确定致使卡顿的再次确定的目标函数。

4.如权利要求3所述的方法，其特征在于，所述执行信息包括所述新的待测试函数的执行时长，所述再次确定的目标函数包括：

执行时长大于第二设定时长的所述新的待测试函数；或者

执行时长排序在第二指定序位的所述新的待测试函数。

5.如权利要求1-4任一所述的方法，其特征在于，所述执行信息还包括执行次数，还包括：

根据获得的执行次数确定所述被检测客户端发生卡顿的卡顿原因。

6.如权利要求1-4任一所述的方法，其特征在于，还包括：

获得所述被检测客户端发生卡顿时的卡顿信息；

根据所述卡顿信息确定所述被检测客户端发生卡顿的卡顿原因。

7.如权利要求1所述的方法，其特征在于，所述被检测客户端为游戏客户端，所述待测试函数包括如下一种或多种函数：

监控游戏场景资源的加载函数；

监控垃圾回收函数；

用于更新游戏数据的更新函数。

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

环境创建单元，用于响应于被检测客户端的开启操作，创建虚拟环境；

函数地址获取单元，用于获取待测试函数地址集合，所述待测试函数地址集合包括至少一个待测试函数的函数调用地址，所述待测试函数包括与所述被检测客户端关联的目标进程对应的函数；

代码注入单元，用于根据所述待测试函数集合，将执行监控代码注入所述目标线程的所述待测试函数；

目标函数确定单元，用于通过所述执行监控代码，获得所述待测试函数在所述被检测客户端发生卡顿时的执行信息，所述执行信息用于确定致使所述被检测客户端卡顿的目标函数。

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

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

Images