CN109840177B - 一种卡顿的处理方法及相关设备 - Google Patents

Abstract

本发明实施例公开了一种卡顿的处理方法及相关设备。本发明实施例方法包括：获取终端上报的卡顿时段内的N个栈帧中的函数信息，函数信息为终端每间隔预置时长从主线程运行时函数堆栈中获取的栈帧中记录的执行函数及执行函数之间的调用关系；根据函数信息所属的N个栈帧中的目标栈帧的数量及预置时长确定函数信息中每个执行函数的耗时时长；根据每个执行函数的耗时时长确定发生卡顿问题的目标执行函数。本申请实施例还提供了一种服务器及终端，对于APP开发来说，不需要漫长的时间来重现与定位卡顿问题原因，而是可以直接优化修改问题，节省了开发人员反复重现卡顿原因的时间，并保证APP运行过程中的流畅度和性能体验。

Description

一种卡顿的处理方法及相关设备

技术领域

本发明涉及计算机应用领域，尤其涉及应用程序的卡顿的处理方法及相关设备。

背景技术

随着移动互联网的发展，特别是智能手机的普及，用户根据自己的需求下载各种应用程序(Application，简写：APP)，极大的便利了人们的生活，例如，社交应用，视频应用，游戏应用等等，在APP开发的过程中，开发人员会对待上线的APP进行测试，检测是否会发生卡顿并查找卡顿原因，根据卡顿原因对该APP进行修改调试，但是，当APP上线后，也可能会由于客户端设备环境的不同出现卡顿问题。

传统方法中，当APP上线后，若APP在运行的过程中出现卡顿，则卡顿无法监控到，在开发测试过程中没有发生卡顿问题的APP，却在上线后经常遇到用户反馈出现卡顿，其原因往往和用户所使用的网络环境、存储空间等各种外部条件相关，这些条件在开发测试阶段难以模拟。

现有技术中，开发人员无法检测到正在运行的APP出现的卡顿问题，没有对应的监控方案可以将用户遇到的问题准确传达到APP开发人员，开发人员一般通过用户的反馈反复尝试重现问题，并且需要逐步排除原因来定位问题，这需要很长的时间，极大的浪费时间成本。

发明内容

本发明实施例提供了一种卡顿的处理方法及相关设备，用于节省开发人员反复重现卡顿原因的时间，并保证APP运行过程中的流畅度和性能体验。

第一方面，本申请实施例提供了一种卡顿的处理方法，包括：

获取终端上报的卡顿时段内的N个栈帧中的函数信息，所述函数信息为终端每间隔预置时长从主线程运行时函数堆栈中获取的栈帧中记录的执行函数及所述执行函数之间的调用关系；

根据所述函数信息所属的所述N个栈帧中的目标栈帧的数量及所述预置时长确定所述函数信息中每个执行函数的耗时时长；

根据每个执行函数的耗时时长确定发生卡顿问题的目标执行函数。

第二方面，本申请实施例提供了一种卡顿的处理方法，包括：

每间隔预置时长从主线程运行时函数堆栈中获取当前栈帧，所述栈帧记录了当前执行函数及所述执行函数之间的调用关系；

判断当前运行应用是否发生卡顿；

若确定发生卡顿，则将卡顿时段内的N个栈帧中的函数信息向服务器发送，所述N为大于1的正整数，以使所述服务器根据所述函数信息所属的所述N个栈帧中的目标栈帧的数量及所述预置时长确定所述函数信息中每个执行函数的耗时时长；以根据每个执行函数的耗时时长确定发生卡顿的问题执行函数。

第三方面，本申请实施例提供了一种卡顿的处理方法，包括：

每间隔预置时长从主线程运行时函数堆栈中获取当前栈帧，所述栈帧记录了当前执行函数及所述执行函数之间的调用关系；

判断当前运行应用是否发生卡顿；

若确定发生卡顿，则确定卡顿时段内的N个栈帧中的函数信息，所述N为大于1的正整数；

根据所述函数信息所属的所述N个栈帧中的目标栈帧的数量及所述预置时长确定所述函数信息中每个执行函数的耗时时长；

根据每个执行函数的耗时时长确定发生卡顿的问题执行函数。

第四方面，本申请实施例提供了一种服务器，包括：

获取模块，用于获取终端上报的卡顿时段内的N个栈帧中的函数信息，所述函数信息为终端每间隔预置时长从主线程运行时函数堆栈中获取的栈帧中记录的执行函数及所述执行函数之间的调用关系；

第一确定模块，用于根据所述获取模块获取的函数信息所属的所述N个栈帧中的目标栈帧的数量及所述预置时长确定所述函数信息中每个执行函数的耗时时长；

第二确定模块，用于根据第一确定模块确定的每个执行函数的耗时时长确定发生卡顿问题的目标执行函数。

第五方面，本申请实施例提供了一种终端，包括：

获取模块，用于每间隔预置时长从主线程运行时函数堆栈中获取当前栈帧，所述栈帧记录了当前执行函数及所述执行函数之间的调用关系；

判断模块，用于判断当前运行应用是否发生卡顿；

发送模块，用于当所述判断模块确定发生卡顿时，将卡顿时段内所述获取模块获取的N个栈帧中的函数信息向服务器发送，所述N为大于1的正整数，以使所述服务器根据所述函数信息所属的所述N个栈帧中的目标栈帧的数量及所述预置时长确定所述函数信息中每个执行函数的耗时时长；以根据每个执行函数的耗时时长确定发生卡顿的问题执行函数。

第六方面，本申请实施例提供了一种服务器，包括：

存储器，用于存储计算机可执行程序代码；

网络接口，以及

处理器，与所述存储器和所述收发器耦合；

其中所述程序代码包括指令，当所述处理器执行所述指令时，所述指令使所述服务器执行第一方面所述的卡顿的处理方法。

第七方面，本申请实施例提供了一种终端，包括：

存储器，用于存储计算机可执行程序代码；

收发器，以及

处理器，与所述存储器和所述收发器耦合；

其中所述程序代码包括指令，当所述处理器执行所述指令时，所述指令使所述服务器执行第二方面所述的卡顿的处理方法。

从以上技术方案可以看出，本发明实施例具有以下优点：

服务器可以获取终端上报的卡顿时段内的N个栈帧中的函数信息，所述函数信息为终端每间隔预置时长从主线程运行时函数堆栈中获取的栈帧中记录的执行函数及所述执行函数之间的调用关系；然后根据所述函数信息所属的所述N个栈帧中的目标栈帧的数量及所述预置时长确定所述函数信息中每个执行函数的耗时时长；根据每个执行函数的耗时时长确定发生卡顿问题的目标执行函数。对于APP开发来说，不需要漫长的时间来重现与定位卡顿问题原因，而是可以直接优化修改问题，节省了开发人员反复重现卡顿原因的时间，并保证APP运行过程中的流畅度和性能体验。

附图说明

为了更清楚地说明本发明实施例中的技术方案，下面将对实施例描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域技术人员来讲，还可以根据这些附图获得其他的附图。

图1为本申请实施例中卡顿的处理系统的架构示意图；

图2为本申请实施例中一种卡顿的处理方法的一个实施例的方法流程图；

图3为本申请实施例中性能监控线程获取函数堆栈的场景示意图；

图4为本申请实施例中卡顿监测的场景示意图；

图5为本申请实施例中卡顿时段的示意图；

图6为本申请实施例中翻译函数信息示意图；

图7为本申请实施例中耗时拓扑结构的示意图；

图8为本申请实施例中多个终端对应的拓扑结构示意图；

图9为本申请实施例中执行函数拓扑结构示意图；

图10为本申请实施例中一种服务器的一个实施例的结构示意图；

图11为本申请实施例中一种服务器的另一个实施例的结构示意图；

图12为本申请实施例中一种服务器的另一个实施例的结构示意图；

图13为本申请实施例中一种服务器的另一个实施例的结构示意图；

图14为本申请实施例中一种服务器的另一个实施例的结构示意图；

图15为本申请实施例中一种服务器的另一个实施例的结构示意图；

图16为本申请实施例中一种服务器的另一个实施例的结构示意图；

图17为本申请实施例中一种终端的一个实施例的结构示意图；

图18为本申请实施例中一种终端的另一个实施例的结构示意图。

具体实施方式

本发明实施例提供了一种卡顿的处理方法及相关设备，用于节省开发人员反复重现卡顿原因的时间，并保证APP运行过程中的流畅度和性能体验。

为了使本技术领域的人员更好地理解本发明方案，下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分的实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员所获得的所有其他实施例，都应当属于本发明保护的范围。

本发明的说明书和权利要求书及上述附图中的术语“第一”、“第二”、“第三”“第四”等(如果存在)是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的实施例能够以除了在这里图示或描述的内容以外的顺序实施。此外，术语“包括”和“具有”以及他们的任何变形，意图在于覆盖不排他的包含，例如，包含了一系列步骤或单元的过程、方法、系统、产品或设备不必限于清楚地列出的那些步骤或单元，而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或单元。

本申请实施例中提供了一种卡顿的处理方法，该处理方法应用于一种卡顿的处理系统，请参阅图1所示，图1为本申请实施例中卡顿的处理系统的架构示意图，该卡顿处理系统100包括终端101和服务器102，该终端101包括但不限定于手机、电脑、PDA等等，终端101用于每间隔预置时长从主线程运行时函数堆栈中获取当前栈帧，该栈帧记录了当前执行函数及所述执行函数之间的调用关系；终端101判断当前运行的APP是否发生卡顿，若确定发生卡顿，则将卡顿时段内的N个栈帧中的函数信息向服务器102发送，该服务器102接收到该N个栈帧中的函数信息，该服务器102可以根据所述函数信息所属的所述N个栈帧中的目标栈帧的数量及所述预置时长确定所述函数信息中每个执行函数的耗时时长；根据每个执行函数的耗时时长确定发生卡顿的问题执行函数。本申请时实施例中，在APP上线后，在用户使用的过程中遇到卡顿问题时，对该卡顿问题进行定位，可以进一步分析定位卡顿问题原因。对于APP开发来说，不再需要漫长的时间来重现与定位问题原因，而是可以直接优化修改问题，节省了开发人员反复重现卡顿原因的时间，并保证APP运行过程中的流畅度和性能体验。

为了方便理解，对本申请中涉及的词语进行说明。

CADisplayLink:执行频率是根据设备屏幕的刷新频率来计算的，是以屏幕刷新频率将内容绘制到屏幕上的定时器。

CADisplayLink的回调：屏幕刷新的通知。

badfood：IOS系统上APP长时间无法响应用户操作被系统强制退出。

运行时堆栈：运行时的数据结构，栈和堆均是操作系统中分配给用户程序使用的一段内存区域，该运行时堆栈包括运行时的函数调用关系上下文。每个函数的每次调用，都有它自己独立的一个栈帧，这个栈帧中维持着所需要的各种信息。因此，栈的作用就是用来保持栈帧的活动记录(即函数调用)。

栈帧：可以理解的是，栈帧将栈分割成了N个记录块，但是这些记录块大小不是固定的，栈帧表示程序的函数调用记录。栈帧记录了执行函数及执行函数之间的调用关系。

符号表：APP编译时生成，里面存储有地址对应的函数名以及代码行号等信息。

翻译：用符号表将地址转换为函数名及代码行等信息。

需要说明的是，本申请中终端中的操作系统以IOS操作系统为例进行说明。本申请实施例中提供的卡顿的处理方法可以应用于IOS和MAC平台上以Objective-C/C++、C及C++语言编写的APP的卡顿监控与分析。

请参阅图2所示，图2为本申请中一种卡顿的处理方法的一个实施例的方法流程图。下面对本申请实施例中的卡顿的处理方法进行详细说明。

步骤201、终端每间隔预置时长从主线程运行时函数堆栈中获取当前栈帧，所述栈帧记录了当前执行函数及所述执行函数之间的调用关系。

在主线程运行时，需要另外一个线程，即性能监控线程每间隔预置时长(如16.7ms)来抓取函数堆栈，需要说明的是，该预置时长为举例说明，并不造成对本申请的限定性说明。

为精确定位卡顿原因，本方案在运行时抓取函数堆栈。请结合图3进行理解，图3为本申请实施例中性能监控线程获取函数堆栈的场景示意图。

在ARM的用户(user)模式下，ARM CPU有16个数据寄存器，被命名为R0～R15，其中，R13为堆栈指针(The Stack Pointer，缩写：SP)，R14为链接寄存器(Link Register，缩写：LR)，R15为程序计数器(The Program Counter，缩写：PC)，另外，还有R11是可选的，被称为FP(frame pointer，指向栈中一个函数的本地变量的首地址)。

运行时函数堆栈信息中可以得到在当前时刻正在执行什么代码，精度可以到代码行。在性能监控线程中，每隔16.7ms挂起主线程，使用系统应用程序编程接口(ApplicationProgramming Interface，缩写：API)获取到主线程的寄存器信息，然后根据寄存器信息对堆栈进行反向遍历得到当前栈帧。栈帧中即存储有当前正在执行的函数以及调用关系等信息，具体的，在程序执行过程中，通过SP和FP所限定的堆栈(stack frame)，就可以得到母函数的SP和FP，从而得到母函数的stack frame(PC，LR，SP，FP会在函数调用的第一时间压栈)，以此追溯，即可得到所有函数的调用顺序及当前的执行函数。然后，获取到调用栈帧后唤醒主线程继续执行。

步骤202、终端判断当前运行应用是否发生卡顿。

在一种可能的实现方式中：监听连续两次屏幕刷新回调的间隔时长。

终端判断所述间隔时长是否大于阈值；若所述间隔时长大于所述阈值，则确定所述应用发生卡顿；若所述间隔时长未大于所述阈值，则确定所述应用未发生卡顿。

例如，本申请实施例中可以通过CADisplayLink通知间隔来检测卡顿，如果两次屏幕刷新的回调超过一定阀值，标识UI线程发生阻塞，界面刷新不流畅，也即有卡顿发生。CADisplayLink是IOS系统中屏幕刷新的回调，正常情况下，可以以16.7ms间隔回调到监听线程。

对于卡顿的监控正是基于这个原理，在主线程中增加对CADisplayLink的监听，通过系统回调的间隔来判断是否发生卡顿。如果连续两次回调的间隔不超过16.7ms，则认为主线程(UI线程)可以正常的刷新及响应用户操作，也即没有卡顿发生。需要说明的是，在实际应用中，受定时器精度、线程调度、CPU使用率等影响，这个间隔时长可能精确等于16.7ms，而是在16.7ms附近浮动，该16.7ms为举例说明，并不造成对本申请的限定性说明，本申请中的阈值为一个区间，例如，该区间为16.5-17ms。本申请中实施例中，该阈值以16.7ms进行举例说明。

如果该间隔时长大于16.7ms，则认为主线程因处理其它事务(如网络、IO)导致界面刷新延迟，且无法及时响应用户操作，也即发生了卡顿。

本申请实施例中，终端可以通过监听连续两次屏幕刷新回调的间隔时长。通过判断该间隔时长是否大于阈值来智能监控运行时应用程序是否有卡顿发生，相对比现有技术，在用户使用APP时，只有当卡顿发生后，用户有感知到卡顿，但是卡顿已经发生，影响用户体验，本申请中可以通过终端实时监控APP卡顿，解决了现有技术中无法智能监控运行APP发生卡顿的问题。

在另一种可能实现的方式中：在所述主线程中监听连续两次屏幕刷新回调的第一间隔时长，并在性能监控线程中监听连续两次屏幕刷新回调的第二间隔时长；判断所述第一间隔时长是否大于阈值，所述第二间隔时长是否大于阈值；若所述第一间隔时长大于所述阈值，所述第二间隔时长大于所述阈值，则确定所述应用未发生卡顿；若所述第一间隔时长大于所述阈值，所述第二间隔时长未大于所述阈值，则确定所述应用发生卡顿。本实施例中，为了减小监控卡顿的误差，该性能监控线程用于对卡顿进行校验。

请结合图4进行理解，图4为卡顿监测的场景示意图。在IOS系统中，APP有时会被挂起(如APP在后台运行，该APP为挂起状态)，在这种情况下，按上述原理识别卡顿可能会产生误差，例如，APP挂起后，代码将不能执行，也即收不到CADisplayLink回调)。这种情况下，需要在另外一个线程(性能监控线程)中同时监听CADisplayLink回调，来校验主线的卡顿是否为有效卡顿。

由于性能监控线程中只做非常有限的操作，除系统挂起等原因外，不会发生CADisplayLink回调延迟的情况。如果主线程发现卡顿，需要同时检测性能监控线程是否也发现了卡顿，如果两个线程同时有耗时相近的卡顿，则认为是APP受其它原因干扰，是无效卡顿。例如，性能监控线程监测CADisplayLink回调延迟，也即第二监控时长大于该阈值，该APP为挂起状态，则虽然主线程发生未接收到CADisplayLink回调，但是，由于该APP已经被挂起，主线程自然将不能接收到CADisplayLink回调，因此，该APP的主线程发生的卡顿，属于无效卡顿。同理，如果性能监控线程中未发现卡顿，则认为是有效卡顿。

步骤203、若确定发生卡顿，终端将卡顿时段内的N个栈帧中的函数信息向服务器发送，所述N为大于1的正整数，

卡顿时段为连续两次间隔时长大于阈值的时长。请结合图5进行理解，图5为本申请中卡顿时段的示意图，每间隔16.7ms监测两次屏幕刷新回调，例如，从时刻t0开始，在第一个16.7ms后，监听到屏幕刷新回调，回调时刻为t1，再经过16.7ms后，再次监听到屏幕刷新回调，回调时刻为t2，当第三次监听到屏幕刷新回调的时刻为t3，但是t2和t3之间的间隔时长大于16.7ms，则此时已经发生卡顿，则是t2和t3之间为卡顿时段。

步骤204、服务器根据所述函数信息所属的所述N个栈帧中的目标栈帧的数量及所述预置时长确定所述函数信息中每个执行函数的耗时时长。

服务器获取终端上报的卡顿时段内的N个栈帧中的函数信息，该函数信息包括执行函数和执行函数之间的调用关系。

具体的，请结合图6进行理解，图6为本申请中翻译函数信息示意图。

终端抓取的栈帧中的函数是以函数地址的形式(如0xXXXXXXXX)，也就是说，终端可以将抓取到的函数地址上报给服务器，服务器可以根据符号表对该函数地址进行翻译，该符号表可以存储在服务器中，也可以是该服务器从另一个设备中实时获取的，具体的，服务器获取符号表的具体方式并不限定。

服务器根据符号表对所述函数地址进行翻译，得到对应的函数的名称(如functionA)及执行位置，该执行位置可以为所在文件及对应的代码行数等。

服务器根据每个执行函数的耗时时长及所述执行函数之间的调用关系对所述N个栈帧中的所有执行函数进行汇总，得到执行函数的耗时拓扑结构。

请结合图7进行理解，图7为耗时拓扑结构的示意图。该耗时拓扑结构是根据每个执行函数的耗时时长生成的，例如，栈帧的数量为4，需要说明的是，本申请实施例中栈帧的数量只是为了方便说明，而举的例子，并不造成对本申请的限定性说明，每个栈帧中记录的执行函数及调用关系如下表1所示：

表1

栈帧1	栈帧2	栈帧3	栈帧4
				functionA	functionA	functionA	functionA
functionC	functionC	functionE	functionE
				functionD	functionD	functionF	functionF

在上述表1中，栈帧1记录的执行函数包括functionA，functionC和functionD等，执行函数之间的调用关系包括functionA调用functionC，functionC调用functionD；例如，栈帧3中包括functionA，functionE和functionF，执行函数之间的调用关系包括：functionA调用functionE，functionE调用functionF。需要说明的是，上述表1中的函数只是举例说明，并不造成对本申请的限定性说明。

将N个栈帧中的执行函数就行汇总，在捕捉到的N个栈帧中，如果有某个执行函数A连续在m个栈帧中出现，目标栈帧的数量为m个，并且在这m个栈帧中，函数A所处的位置相同，栈帧中的函数关系是调用者与被调用者的关系，也可以理解为父子函数关系，这里的位置相同，即在调用链中的父函数以及父函数的父函数……都相同，则可以认为函数A在这m个栈帧间隔的时间中一直在执行，也即函数耗时≈m*16.7ms，根据这个原理，可以将N个栈帧合并为耗时拓扑结构，该耗时拓扑结构可以理解为耗时树，该耗时拓扑结构用于耗时原因分析。

以上述表1中记录4个栈帧为例进行说明，例如，functionA所属的目标栈帧的数量m为4，则functionA的耗时为4*16.7ms＝66.8ms；functionA所属的目标栈帧的数量m为2，则functionC的耗时为2*16.7ms＝33.4ms；同理，functionD的耗时为2*16.7ms＝33.4ms；functionE所属的目标栈帧的数量m为2，则functionE的耗时为2*16.7ms＝33.4ms；functionF所属的目标栈帧的数量m为2，则functionF的耗时为2*16.7ms＝33.4ms。

步骤205、服务器根据每个执行函数的耗时时长确定发生卡顿的问题执行函数。

在一种可能的实现方式中，服务器对全部的执行函数的耗时时长进行排序，按照耗时的时长确定发生卡顿的问题执行函数，确定预置序列的执行函数为发生卡顿问题的执行函数。该预置序列可以为第一位，或第一位和第二位，具体的并不限定。例如，在图7中，functionA的耗时时长最长，则确定functionA为发生卡顿的问题的目标执行函数。

在另一种可能的实现方式，服务器对全部的执行函数的上报次数进行排序，例如，该终端发生多次卡顿，对每次发生卡顿的执行函数进行统计，确定多次卡顿时段中，每个执行函数的上报次数，对该上报次数进行排序，确定预置排序序位的执行函数为目标执行函数。例如，虽然在每次发生卡段的时段内，一个执行函数functionE的耗时时长并非最长，但是，每次发生卡顿时段内，都包含该执行函数functionE，也就是说该functionE是上报次数最多的执行函数，则确定该functionE为发生卡顿问题的目标执行函数。

在另一种可能的实现方式根据所述执行函数的耗时拓扑结构确定发生卡顿问题的目标执行函数，根据每个执行函数的耗时时长和/或上报次数进行排序，得到排序结果；可以根据每个执行函数的耗时时长和上报次数确定目标执行函数，例如，可以根据耗时时长和上报次数进行权重计算，确定该执行函数的目标序位，根据所有执行函数的目标序位确定发生卡顿问题的目标执行函数。

可选的，在上述实施例的基础上，服务器可以生成所述终端对应的ID标识；将所述函数信息中的执行函数与所述ID标识对应存储。客户端在运行过程中发现并上报卡顿信息，包括卡顿时长与栈帧信息等。上报后信息经翻译后存储到个例存储区中，个例存储区可以根据用户标识ID等信息查询某个用户遇到的卡顿情况。

可选的，在上述实施例的基础上，服务器存储所述函数信息；当再次接收到所述终端上报的函数信息时，将接收到的函数信息与存储的函数信息进行比较，得到比较结果。根据所述比较结果确定是否有新增的发生卡顿问题的目标执行函数。

请结合图8进行理解，图8为本申请实施例中多个终端对应的拓扑结构示意图，服务器可以周期性的将所有个例数据(每个终端对应一个个例数据)汇总到一起，以卡顿函数为节点(例如functionA)，组成一颗庞大的排序树。请结合图9进行理解，图9为本申请实施例中执行函数拓扑结构示意图。当样本量足够以后，如果有某个或者某些个例卡顿数据需要在排序树上新加节点，则代表着有新的卡顿问题出现。例如，引起新的卡顿问题的执行函数为functionK，进一步的，可以进行新增目标执行函数预警。

卡顿的监控与定位一直是APP开发及运营过程中的难点。而卡顿问题往往与用户使用环境及使用习惯等息息相关。在开发测试过程中没有卡顿问题的APP，却在外发后经常遇到用户反馈，其原因往往和用户所使用的网络环境、存储空间等各种外部条件相关，这些条件在开发测试阶段难以模拟。

本申请中提供的一种在APP运行时独立检测卡顿与定位卡顿原因的方案，通过与网络上报平台结合，可实现自动化监控APP的卡顿，并通过堆栈信息进一步分析定位卡顿问题原因。根据所述函数信息所属的所述N个栈帧中的目标栈帧的数量及所述预置时长确定所述函数信息中每个执行函数的耗时时长；根据每个执行函数的耗时时长确定发生卡顿问题的目标执行函数。

本申请中可以为IOS和Mac程序提供统一的卡顿自动化监控分析平台，帮助IOS和Macc应用发现和解决卡顿问题，对于APP开发来说，不再需要漫长的时间来重现与定位问题原因，而是可以直接优化修改问题，从而保证app的流畅度和性能体验，并节省发现问题的时间成本。

比如：手机QQ5.5之前的版本中，有一部分用户反馈频繁卡死，APP几乎无法使用，问题在开发测试环境中极难重现，没有任何线索可以跟进。在本申请中的方法上线后，在几个小时内就确定这部分用户因为使用QQ时间较长，积累了非常多的配置文件，这些文件在读取/写入时高概率引发长时间卡顿，导致系统强制关闭APP。

本申请中的方法在手机QQ(IOS)、MAC QQ、QQ音乐(IOS)、全民K歌(IOS)等二十几个APP内应用，各APP的性能均有明显提升，用户反馈也逐渐减少。

需要说明的是，在另一个实施例中，该卡顿的处理方法应用于一种卡顿的处理系统，本申请中对该架构只是示例性说明，当然该终端所执行的功能和该服务器所执行的功能也可以集成到一个设备中进行，例如，该终端执行的功能和该服务器执行的功能均有该终端来执行，例如，该终端可以用于执行以下步骤来实现卡顿的监控与定位。

每间隔预置时长从主线程运行时函数堆栈中获取当前栈帧，所述栈帧记录了当前执行函数及所述执行函数之间的调用关系；判断当前运行应用是否发生卡顿；若确定发生卡顿，则确定卡顿时段内的N个栈帧中的函数信息，所述N为大于1的正整数；根据所述函数信息所属的所述N个栈帧中的目标栈帧的数量及所述预置时长确定所述函数信息中每个执行函数的耗时时长；根据每个执行函数的耗时时长确定发生卡顿的问题执行函数。

可选的，所述判断当前运行主线程是否发生卡顿，具体的，终端监听连续两次屏幕刷新回调的间隔时长；判断所述间隔时长是否大于阈值；若所述间隔时长大于所述阈值，则确定所述应用发生卡顿；若所述间隔时长未大于所述阈值，则确定所述应用未发生卡顿。

在另一种实现方式中，所述判断当前运行主线程是否发生卡顿，包括：在所述主线程中监听连续两次屏幕刷新回调的第一间隔时长，并在性能监控线程中监听连续两次屏幕刷新回调的第二间隔时长；判断所述第一间隔时长是否大于阈值，所述第二间隔时长是否大于阈值；若所述第一间隔时长大于所述阈值，所述第二间隔时长大于所述阈值，则确定所述应用未发生卡顿；若所述第一间隔时长大于所述阈值，所述第二间隔时长未大于所述阈值，则确定所述应用发生卡顿。

可选的，终端抓取卡顿时段内的N个栈帧中的函数地址；根据符号表对所述函数地址进行翻译，得到所述函数的名称及执行位置。该符号表可以是终端从另一个设备中获取的。

可选的，终端根据每个执行函数的耗时时长及所述执行函数之间的调用关系对所述N个栈帧中的所有执行函数进行汇总，得到执行函数的耗时拓扑结构；根据所述执行函数的耗时拓扑结构确定发生卡顿问题的目标执行函数。

可选的，终端根据每个执行函数的耗时时长和/或上报次数进行排序，得到排序结果；根据所述排序结果确定发生卡顿的目标执行函数。

上面对本申请中一种卡顿的处理方法进行了说明，下面对本申请实施例中该卡顿的处理方法应用的服务器进行说明，请参阅图10所示，图10为本申请实施例中一种服务器1000的一个实施例的结构示意图。

获取模块1001，用于获取终端上报的卡顿时段内的N个栈帧中的函数信息，所述函数信息为终端每间隔预置时长从主线程运行时函数堆栈中获取的栈帧中记录的执行函数及所述执行函数之间的调用关系；

第一确定模块1002，用于根据所述获取模块1001获取的函数信息所属的所述N个栈帧中的目标栈帧的数量及所述预置时长确定所述函数信息中每个执行函数的耗时时长；

第二确定模块1003，用于根据第一确定模块1002确定的每个执行函数的耗时时长确定发生卡顿问题的目标执行函数。

在上述图10对应的实施例的基础上，请参阅图11所示，本申请实施例提供了一种服务器1100的另一个实施例。

可选的，所述获取模块1001包括获取单元10011和翻译单元10012；

获取单元10011，用于获取终端上报的卡顿时段内的N个栈帧中的函数地址；

翻译单元10012，用于根据符号表对所述获取单元10011获取的函数地址进行翻译，得到所述函数的名称及执行位置。

在上述图10对应的实施例的基础上，请参阅图12所示，本申请实施例提供了一种服务器1200的另一个实施例。

所述服务器还包括汇总模块1004；

所述汇总模块1004，用于根据第一确定模块1002确定的每个执行函数的耗时时长及所述执行函数之间的调用关系对所述N个栈帧中的所有执行函数进行汇总，得到执行函数的耗时拓扑结构；

第二确定模块1003，还用于根据汇总模块1004汇总的所述执行函数的耗时拓扑结构确定发生卡顿问题的目标执行函数。

可选的，在上述图10对应的实施例的基础上，请参阅图13所示，本申请实施例提供了一种服务器1300的另一个实施例。

所述第二确定模块1003还包括排序单元10031和确定单元10032。

所述排序单元10031，用于根据第一确定函数确定的每个执行函数的耗时时长和/或上报次数进行排序，得到排序结果；

确定单元10032，用于根据所述排序单元10031确定的排序结果确定发生卡顿的目标执行函数。

在上述图10对应的实施例的基础上，请参阅图14所示，本申请实施例提供了一种服务器1400的另一个实施例。

所述服务器还包括生成模块1005和存储模块1006。生成模块1005，用于生成所述终端对应的ID标识；

存储模块1006，用于将获取模块1001获取的所述函数信息中的执行函数与所述生成模块1005生成的ID标识对应存储。

在上述图10对应的实施例的基础上，请参阅图15所示，本申请实施例提供了一种服务器1500的另一个实施例。

服务器还包括存储模块1006，比较模块1007和第三确定模块1008；

存储模块1006，用于存储所述获取模块1001获取的函数信息；

比较模块1007，用于当再次接收到终端上报的函数信息时，将获取模块1001获取的函数信息与存储模块1006存储的函数信息进行比较，得到比较结果；

第三确定模块1008，用于根据所述比较模块1007确定的比较结果确定是否有新增的发生卡顿问题的目标执行函数。

进一步的，图10-图15中的服务器是以功能模块的形式来呈现。这里的“模块”可以指特定应用集成电路(application-specific integrated circuit，ASIC)，电路，执行一个或多个软件或固件程序的处理器和存储器，集成逻辑电路，和/或其他可以提供上述功能的器件。在一个简单的实施例中，图10-图15中的服务器可以采用图16所示的形式。

图16是本发明实施例提供的一种服务器结构示意图，该服务器1600可因配置或性能不同而产生比较大的差异，可以包括一个或一个以上中央处理器(central processingunits，CPU)1622(例如，一个或一个以上处理器)和存储器1632，一个或一个以上存储应用程序1642或数据1644的存储介质1630(例如一个或一个以上海量存储设备)。其中，存储器1632和存储介质1630可以是短暂存储或持久存储。存储在存储介质1630的程序可以包括一个或一个以上模块(图示没标出)，每个模块可以包括对服务器中的一系列指令操作。更进一步地，中央处理器1622可以设置为与存储介质1630通信，在服务器1600上执行存储介质1630中的一系列指令操作。

服务器1600还可以包括一个或一个以上电源1626，一个或一个以上有线或无线网络接口1650，一个或一个以上输入输出接口1658，和/或，一个或一个以上操作系统1641，例如Windows ServerTM，Mac OS XTM，UnixTM,LinuxTM，FreeBSDTM等等。

上述实施例中由服务器所执行的步骤可以基于该图16所示的服务器结构。

中央处理器1622用于使服务器执行图2对应的方法实施例中服务器实际执行的方法。

网络接口1650，用于获取终端上报的卡顿时段内的N个栈帧中的函数信息，所述函数信息为终端每间隔预置时长从主线程运行时函数堆栈中获取的栈帧中记录的执行函数及所述执行函数之间的调用关系；

中央处理器1622，用于根据所述函数信息所属的所述N个栈帧中的目标栈帧的数量及所述预置时长确定所述函数信息中每个执行函数的耗时时长；根据每个执行函数的耗时时长确定发生卡顿问题的目标执行函数。

可选的，网络接口1650，还用于获取终端上报的卡顿时段内的N个栈帧中的函数地址；

中央处理器1622，还用于根据符号表对所述函数地址进行翻译，得到所述函数的名称及执行位置。

可选的，中央处理器1622，还用于根据每个执行函数的耗时时长及所述执行函数之间的调用关系对所述N个栈帧中的所有执行函数进行汇总，得到执行函数的耗时拓扑结构；根据所述执行函数的耗时拓扑结构确定发生卡顿问题的目标执行函数。

可选的，中央处理器1622，还用于根据每个执行函数的耗时时长和/或上报次数进行排序，得到排序结果；根据所述排序结果确定发生卡顿的目标执行函数。

可选的，中央处理器1622，还用于生成所述终端对应的ID标识；

存储器1632，用于将所述函数信息中的执行函数与所述ID标识对应存储。

可选的，存储器1632，用于存储所述函数信息；

中央处理器1622，还用于当再次接收到终端上报的函数信息时，将接收到的函数信息与存储的函数信息进行比较，得到比较结果；根据所述比较结果确定是否有新增的发生卡顿问题的目标执行函数。

本申请又提供了一种计算机可读存储介质，所述计算机可读存储介质中存储有指令，当其在计算机上运行时，使得计算机执行上述方法实施例中服务器所执行的方法。

上面对服务器进行了说明，下面对本申请中一种卡顿的处理方法所应用的终端进行说明，请参阅图17所示，图17为本申请中一种终端1700的一个实施例的结构示意图。

获取模块1701，用于每间隔预置时长从主线程运行时函数堆栈中获取当前栈帧，所述栈帧记录了当前执行函数及所述执行函数之间的调用关系；

判断模块1702，用于判断当前运行应用是否发生卡顿；

发送模块1703，用于当所述判断模块1702确定发生卡顿时，将卡顿时段内所述获取模块1701获取的N个栈帧中的函数信息向服务器发送，所述N为大于1的正整数，以使所述服务器根据所述函数信息所属的所述N个栈帧中的目标栈帧的数量及所述预置时长确定所述函数信息中每个执行函数的耗时时长；以根据每个执行函数的耗时时长确定发生卡顿的问题执行函数。

可选的，所述判断模块1702还用于：

监听连续两次屏幕刷新回调的间隔时长；

判断所述间隔时长是否大于阈值；

若所述间隔时长大于所述阈值，则确定所述应用发生卡顿；

若所述间隔时长未大于所述阈值，则确定所述应用未发生卡顿。

可选的，所述判断模块1702还用于：

在所述主线程中监听连续两次屏幕刷新回调的第一间隔时长，并在性能监控线程中监听连续两次屏幕刷新回调的第二间隔时长；

判断所述第一间隔时长是否大于阈值，所述第二间隔时长是否大于阈值；

若所述第一间隔时长大于所述阈值，所述第二间隔时长大于所述阈值，则确定所述应用未发生卡顿；

若所述第一间隔时长大于所述阈值，所述第二间隔时长未大于所述阈值，则确定所述应用发生卡顿。

进一步的，图17中的终端是以功能模块的形式来呈现。这里的“模块”可以指特定应用集成电路(application-specific integrated circuit，ASIC)，电路，执行一个或多个软件或固件程序的处理器和存储器，集成逻辑电路，和/或其他可以提供上述功能的器件。在一个简单的实施例中，图17中的终端可以采用图18所示的形式。

本发明实施例还提供了另一种终端，如图18所示，为了便于说明，仅示出了与本发明实施例相关的部分，具体技术细节未揭示的，请参照本发明实施例方法部分。该终端可以为包括手机、平板电脑、PDA(Personal Digital Assistant，个人数字助理)等任意终端设备，以终端为手机为例：

图18示出的是与本发明实施例提供的终端相关的手机的部分结构的框图。参考图18，手机包括：射频(Radio Frequency，RF)电路1810、存储器1820、输入单元1830、显示单元1840、音频电路1860、无线保真(wireless fidelity，WiFi)模块1870、处理器1880、以及电源1890等部件。本领域技术人员可以理解，图18中示出的手机结构并不构成对手机的限定，可以包括比图示更多或更少的部件，或者组合某些部件，或者不同的部件布置。

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

RF电路1810可用于收发信息或通话过程中，信号的接收和发送，特别地，将基站的下行信息接收后，给处理器1880处理；另外，将设计上行的数据发送给基站。通常，RF电路1810包括但不限于天线、至少一个放大器、收发信机、耦合器、低噪声放大器(Low NoiseAmplifier，LNA)、双工器等。此外，RF电路1810还可以通过无线通信与网络和其他设备通信。上述无线通信可以使用任一通信标准或协议，包括但不限于全球移动通讯系统(GlobalSystem of Mobile communication，GSM)、通用分组无线服务(General Packet RadioService，GPRS)、码分多址(Code Division Multiple Access，CDMA)、宽带码分多址(Wideband Code Division Multiple Access,WCDMA)、长期演进(Long Term Evolution，LTE)、电子邮件、短消息服务(Short Messaging Service，SMS)等。

存储器1820可用于存储软件程序以及模块，处理器1880通过运行存储在存储器1820的软件程序以及模块，从而执行手机的各种功能应用以及数据处理。存储器1820可主要包括存储程序区和存储数据区，其中，存储程序区可存储操作系统、至少一个功能所需的应用程序(比如声音播放功能、图像播放功能等)等；存储数据区可存储根据手机的使用所创建的数据(比如音频数据、电话本等)等。此外，存储器1820可以包括高速随机存取存储器，还可以包括非易失性存储器，例如至少一个磁盘存储器件、闪存器件、或其他易失性固态存储器件。

输入单元1830可用于接收输入的数字或字符信息，以及产生与手机的用户设置以及功能控制有关的键信号输入。具体地，输入单元1830可包括触控面板1831以及其他输入设备1832。触控面板1831，也称为触摸屏，可收集用户在其上或附近的触摸操作(比如用户使用手指、触笔等任何适合的物体或附件在触控面板1831上或在触控面板1831附近的操作)，并根据预先设定的程式驱动相应的连接装置。可选的，触控面板1831可包括触摸检测装置和触摸控制器两个部分。其中，触摸检测装置检测用户的触摸方位，并检测触摸操作带来的信号，将信号传送给触摸控制器；触摸控制器从触摸检测装置上接收触摸信息，并将它转换成触点坐标，再送给处理器1880，并能接收处理器1880发来的命令并加以执行。此外，可以采用电阻式、电容式、红外线以及表面声波等多种类型实现触控面板1831。除了触控面板1831，输入单元1830还可以包括其他输入设备1832。具体地，其他输入设备1832可以包括但不限于物理键盘、功能键(比如音量控制按键、开关按键等)、轨迹球、鼠标、操作杆等中的一种或多种。

显示单元1840可用于显示由用户输入的信息或提供给用户的信息以及手机的各种菜单。显示单元1840可包括显示面板1841，可选的，可以采用液晶显示器(LiquidCrystal Display，LCD)、有机发光二极管(Organic Light-Emitting Diode,OLED)等形式来配置显示面板1841。进一步的，触控面板1831可覆盖显示面板1841，当触控面板1831检测到在其上或附近的触摸操作后，传送给处理器1880以确定触摸事件的类型，随后处理器1880根据触摸事件的类型在显示面板1841上提供相应的视觉输出。虽然在图18中，触控面板1831与显示面板1841是作为两个独立的部件来实现手机的输入和输入功能，但是在某些实施例中，可以将触控面板1831与显示面板1841集成而实现手机的输入和输出功能。

音频电路1860、扬声器1861，传声器1862可提供用户与手机之间的音频接口。音频电路1860可将接收到的音频数据转换后的电信号，传输到扬声器1861，由扬声器1861转换为声音信号输出；另一方面，传声器1862将收集的声音信号转换为电信号，由音频电路1860接收后转换为音频数据，再将音频数据输出处理器1880处理后，经RF电路1810以发送给比如另一手机，或者将音频数据输出至存储器1820以便进一步处理。

WiFi属于短距离无线传输技术，手机通过WiFi模块1870可以帮助用户收发电子邮件、浏览网页和访问流式媒体等，它为用户提供了无线的宽带互联网访问。虽然图18示出了WiFi模块1870，但是可以理解的是，其并不属于手机的必须构成，完全可以根据需要在不改变发明的本质的范围内而省略。

处理器1880是手机的控制中心，利用各种接口和线路连接整个手机的各个部分，通过运行或执行存储在存储器1820内的软件程序和/或模块，以及调用存储在存储器1820内的数据，执行手机的各种功能和处理数据，从而对手机进行整体监控。可选的，处理器1880可包括一个或多个处理单元；优选的，处理器1880可集成应用处理器和调制解调处理器，其中，应用处理器主要处理操作系统、用户界面和应用程序等，调制解调处理器主要处理无线通信。可以理解的是，上述调制解调处理器也可以不集成到处理器1880中。

手机还包括给各个部件供电的电源1890(比如电池)，优选的，电源可以通过电源管理系统与处理器1880逻辑相连，从而通过电源管理系统实现管理充电、放电、以及功耗管理等功能。

尽管未示出，手机还可以包括摄像头、蓝牙模块等，在此不再赘述。

在本发明实施例中，该终端所包括的处理器1880还具有以下功能：

该处理器用于使所述终端执行图2对应的方法实施例中的终端所执行的方法步骤。

本申请又提供了一种计算机可读存储介质，所述计算机可读存储介质中存储有指令，当其在计算机上运行时，使得计算机执行上述方法实施例中服务器所执行的方法。

所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，上述描述的系统，装置和单元的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。

在本申请所提供的几个实施例中，应该理解到，所揭露的系统，装置和方法，可以通过其它的方式实现。例如，以上所描述的装置实施例仅仅是示意性的，例如，所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或单元的间接耦合或通信连接，可以是电性，机械或其它的形式。

所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。

另外，在本发明各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。

所述集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本发明各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器(ROM，Read-OnlyMemory)、随机存取存储器(RAM，Random Access Memory)、磁碟或者光盘等各种可以存储程序代码的介质。

以上所述，以上实施例仅用以说明本发明的技术方案，而非对其限制；尽管参照前述实施例对本发明进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本发明各实施例技术方案的精神和范围。

Claims (11)

1.一种卡顿的处理方法，其特征在于，包括：

获取终端上报的卡顿时段内的N个栈帧中的函数信息，所述函数信息为终端每间隔预置时长从主线程运行时函数堆栈中获取的栈帧中记录的执行函数及所述执行函数之间的调用关系，所述N为大于1的正整数；

根据所述函数信息所属的所述N个栈帧中的目标栈帧的数量及所述预置时长确定所述函数信息中每个执行函数的耗时时长；

根据每个执行函数的耗时时长及所述执行函数之间的调用关系对所述N个栈帧中的所有执行函数进行汇总，得到执行函数的耗时拓扑结构；

根据每个执行函数的耗时时长和/或上报次数进行排序，得到排序结果；

根据所述排序结果确定发生卡顿的目标执行函数；

存储所述函数信息；

当再次接收到终端上报的函数信息时，将接收到的函数信息与存储的函数信息进行比较，得到比较结果；

根据所述比较结果确定是否有新增的发生卡顿问题的目标执行函数。

2.根据权利要求1所述的卡顿的处理方法，其特征在于，所述获取终端上报的卡顿时段内的N个栈帧中的函数信息，包括：

获取终端上报的卡顿时段内的N个栈帧中的函数地址；

根据符号表对所述函数地址进行翻译，得到所述函数的名称及执行位置。

3.根据权利要求1或2所述的卡顿的处理方法，其特征在于，所述方法还包括：

生成所述终端对应的ID标识；

将所述函数信息中的执行函数与所述ID标识对应存储。

4.一种卡顿的处理方法，其特征在于，包括：

每间隔预置时长从主线程运行时函数堆栈中获取当前栈帧，所述栈帧记录了当前执行函数及所述执行函数之间的调用关系；

判断当前运行应用是否发生卡顿；

若确定发生卡顿，则将卡顿时段内的N个栈帧中的函数信息向服务器发送，所述N为大于1的正整数，以使所述服务器根据所述函数信息所属的所述N个栈帧中的目标栈帧的数量及所述预置时长确定所述函数信息中每个执行函数的耗时时长；并根据每个执行函数的耗时时长及所述执行函数之间的调用关系对所述N个栈帧中的所有执行函数进行汇总，得到执行函数的耗时拓扑结构；以根据每个执行函数的耗时时长和/或上报次数进行排序，得到排序结果；再根据所述排序结果确定发生卡顿的目标执行函数；且存储所述函数信息；当再次接收到终端的函数信息时，将接收到的函数信息与存储的函数信息进行比较，得到比较结果；根据所述比较结果确定是否有新增的发生卡顿问题的目标执行函数。

5.根据权利要求4所述的卡顿的处理方法，其特征在于，所述判断当前运行应用是否发生卡顿，包括：

监听连续两次屏幕刷新回调的间隔时长；

判断所述间隔时长是否大于阈值；

若所述间隔时长大于所述阈值，则确定所述应用发生卡顿；

若所述间隔时长未大于所述阈值，则确定所述应用未发生卡顿。

6.根据权利要求4所述的卡顿的处理方法，其特征在于，所述判断当前运行应用是否发生卡顿，包括：

在所述主线程中监听连续两次屏幕刷新回调的第一间隔时长，并在性能监控线程中监听连续两次屏幕刷新回调的第二间隔时长；

判断所述第一间隔时长是否大于阈值，所述第二间隔时长是否大于阈值；

若所述第一间隔时长大于所述阈值，所述第二间隔时长大于所述阈值，则确定所述应用未发生卡顿；

若所述第一间隔时长大于所述阈值，所述第二间隔时长未大于所述阈值，则确定所述应用发生卡顿。

7.一种卡顿的处理方法，其特征在于，包括：

每间隔预置时长从主线程运行时函数堆栈中获取当前栈帧，所述栈帧记录了当前执行函数及所述执行函数之间的调用关系；

判断当前运行应用是否发生卡顿；

若确定发生卡顿，则确定卡顿时段内的N个栈帧中的函数信息，所述N为大于1的正整数；

根据所述函数信息所属的所述N个栈帧中的目标栈帧的数量及所述预置时长确定所述函数信息中每个执行函数的耗时时长；

根据每个执行函数的耗时时长及所述执行函数之间的调用关系对所述N个栈帧中的所有执行函数进行汇总，得到执行函数的耗时拓扑结构；

根据每个执行函数的耗时时长和/或上报次数进行排序，得到排序结果；

根据所述排序结果确定发生卡顿的目标执行函数；

存储所述函数信息；

当再次接收到终端上报的函数信息时，将接收到的函数信息与存储的函数信息进行比较，得到比较结果；

根据所述比较结果确定是否有新增的发生卡顿问题的目标执行函数。

8.一种服务器，其特征在于，包括：

获取模块，用于获取终端上报的卡顿时段内的N个栈帧中的函数信息，所述函数信息为终端每间隔预置时长从主线程运行时函数堆栈中获取的栈帧中记录的执行函数及所述执行函数之间的调用关系；

第一确定模块，用于根据所述获取模块获取的函数信息所属的所述N个栈帧中的目标栈帧的数量及所述预置时长确定所述函数信息中每个执行函数的耗时时长；

所述第一确定模块，还用于根据每个执行函数的耗时时长及所述执行函数之间的调用关系对所述N个栈帧中的所有执行函数进行汇总，得到执行函数的耗时拓扑结构；

第二确定模块，用于根据每个执行函数的耗时时长和/或上报次数进行排序，得到排序结果；

根据所述排序结果确定发生卡顿的目标执行函数；

存储模块，用于存储所述函数信息；

比较模块，用于当再次接收到终端上报的函数信息时，将接收到的函数信息与存储的函数信息进行比较，得到比较结果；

第三确定模块，用于根据所述比较结果确定是否有新增的发生卡顿问题的目标执行函数。

9.一种终端，其特征在于，包括：

获取模块，用于每间隔预置时长从主线程运行时函数堆栈中获取当前栈帧，所述栈帧记录了当前执行函数及所述执行函数之间的调用关系；

判断模块，用于判断当前运行应用是否发生卡顿；

发送模块，用于当所述判断模块确定发生卡顿时，将卡顿时段内所述获取模块获取的N个栈帧中的函数信息向服务器发送，所述N为大于1的正整数，以使所述服务器根据所述函数信息所属的所述N个栈帧中的目标栈帧的数量及所述预置时长确定所述函数信息中每个执行函数的耗时时长；并根据每个执行函数的耗时时长及所述执行函数之间的调用关系对所述N个栈帧中的所有执行函数进行汇总，得到执行函数的耗时拓扑结构；以根根据每个执行函数的耗时时长和/或上报次数进行排序，得到排序结果；再根据所述排序结果确定发生卡顿的目标执行函数；且存储所述函数信息；当再次接收到终端的函数信息时，将接收到的函数信息与存储的函数信息进行比较，得到比较结果；根据所述比较结果确定是否有新增的发生卡顿问题的目标执行函数。

10.一种服务器，其特征在于，包括：

存储器，用于存储计算机可执行程序代码；

网络接口，以及

处理器，与所述存储器和所述网络接口耦合；

其中所述程序代码包括指令，当所述处理器执行所述指令时，所述指令使所述服务器执行如权利要求1至3中的任一项所述的卡顿的处理方法。

11.一种终端，其特征在于，包括：

存储器，用于存储计算机可执行程序代码；

收发器，以及

处理器，与所述存储器和所述收发器耦合；

其中所述程序代码包括指令，当所述处理器执行所述指令时，所述指令使所述终端执行如权利要求4至6中的任一项所述的卡顿的处理方法。

Images