CN111625456B - 一种卡顿定位方法和装置 - Google Patents

一种卡顿定位方法和装置 Download PDF

Info

Publication number
CN111625456B
CN111625456B CN202010457567.7A CN202010457567A CN111625456B CN 111625456 B CN111625456 B CN 111625456B CN 202010457567 A CN202010457567 A CN 202010457567A CN 111625456 B CN111625456 B CN 111625456B
Authority
CN
China
Prior art keywords
stack
thread
time
stuck
current
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
CN202010457567.7A
Other languages
English (en)
Other versions
CN111625456A (zh
Inventor
沈革
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Beijing Dajia Internet Information Technology Co Ltd
Original Assignee
Beijing Dajia Internet Information Technology Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Beijing Dajia Internet Information Technology Co Ltd filed Critical Beijing Dajia Internet Information Technology Co Ltd
Priority to CN202010457567.7A priority Critical patent/CN111625456B/zh
Publication of CN111625456A publication Critical patent/CN111625456A/zh
Application granted granted Critical
Publication of CN111625456B publication Critical patent/CN111625456B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00Error detection; Error correction; Monitoring
    • G06F11/36Preventing errors by testing or debugging software
    • G06F11/362Software debugging
    • G06F11/3644Software debugging by instrumenting at runtime
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00Error detection; Error correction; Monitoring
    • G06F11/36Preventing errors by testing or debugging software
    • G06F11/362Software debugging
    • G06F11/366Software debugging using diagnostics
    • YGENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y02TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
    • Y02DCLIMATE CHANGE MITIGATION TECHNOLOGIES IN INFORMATION AND COMMUNICATION TECHNOLOGIES [ICT], I.E. INFORMATION AND COMMUNICATION TECHNOLOGIES AIMING AT THE REDUCTION OF THEIR OWN ENERGY USE
    • Y02D10/00Energy efficient computing, e.g. low power processors, power management or thermal management

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Hardware Design (AREA)
  • Quality & Reliability (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Debugging And Monitoring (AREA)

Abstract

本公开提供了一种卡顿定位方法、装置、电子设备及存储介质,主线程的堆栈中包含主线程当前运行的函数、代码等数据,卡顿定位信息是依据堆栈生成的可被直接读取分析的文件。由于采集主线程堆栈资源消耗很小,而生成卡顿定位信息资源消耗较大,本公开方案周期性采集主线程堆栈,并使用预先创建的子线程判断主线程是否卡顿,当主线程卡顿时提取对应的卡顿堆栈生成卡顿定位信息,可以在资源消耗较小的情况下,有效对卡顿原因进行定位。

Description

一种卡顿定位方法和装置
技术领域
本公开涉计算机技术领域,尤其涉及一种卡顿定位方法、装置、电子设备及存储介质。
背景技术
iOS平台由于UIKit本身的特性,所有的UI操作都需要由主线程执行。由此,开发人员可能会将一些线程安全性不确定的逻辑放入主线程。而不安全逻辑中包含的大量计算、IO、绘制等工作都有可能造成主线程卡顿。
传统方案中,可以通过监测FPS的方式确定主线程是否卡顿,例如向主线程的RunLoop中添加定时器CADisplayLink,使每次屏幕刷新的时候都要执行一次CADisplayLink方法,由此统计内屏幕在固定时间内的刷新次数,也就是FPS,当FPS出现明显下降时,判断出现主线程卡顿。
传统方案存在的问题在于:卡顿发生时,FPS会出现明显下降。但转场动画等特殊场景也可能存在FPS的明显下降,传统方案得到的判断结果可能并不准确。且传统方案只能确定是否发生了卡顿,无法定位到具体的造成卡顿的代码逻辑。
发明内容
针对上述技术问题,本公开实施例提供一种卡顿定位方法,技术方案如下:
根据本公开实施例的第一方面,提供一种卡顿定位方法,包括:
按照指定的采集频率采集主线程的堆栈;
满足子线程启动条件后,启动预先创建的检测子线程,根据预设的检测规则检测主线程是否处于卡顿状态;
若检测到所述主线程处于卡顿状态,则在采集到的堆栈中查找到最近的最耗时堆栈,基于所述最耗时堆栈生成卡顿定位信息。
可选的,所述根据预设的检测规则检测主线程是否处于卡顿状态,包括:
检测到主线程Runloop的运行时间超过预定义阈值后,确定主线程处于卡顿状态,或,
检测到CPU的占用率超过预定义阈值后,确定主线程处于卡顿状态。
可选的,所述检测到主线程Runloop的运行时间超过预定义阈值,包括:
检测子线程检测所述主线程Runloop中的指定状态位的状态;
所述子线程从指定状态位的状态发生改变时开始计时,若预定义阀值到达时所述指定状态位的状态没有再次发生改变,则确定所述主线程Runloop的运行时间超过预定义阈值。
可选的,所述在所述指定数量的堆栈中查找到最耗时堆栈,基于所述最耗时堆栈生成卡顿定位信息,包括:
在采集的堆栈中查找最近的最耗时堆栈,确定为当前卡顿堆栈;
将所述当前卡顿堆栈与上一次确定的卡顿堆栈进行对比;
若所述当前卡顿堆栈与上一次确定的卡顿堆栈不同,则依据所述当前卡顿堆栈生成卡顿定位信息。
可选的,所述满足检测子线程启动条件,包括:
获取本次启动时间点,在所述本次启动时间点到达时,判定为满足检测子线程启动条件,其中,所述本次启动时间点由检测子线程上次启动时检测到的主线程的卡顿状态决定,在检测到所述主线程处于持续卡顿状态时,对应延后所述检测子线程的本次启动时间点。
可选的,所述依据所述当前卡顿堆栈生成卡顿定位信息,包括:
依据所述当前卡顿堆栈生成线程快照,将所述线程快照存储为卡顿定位信息。
可选的,若所述当前卡顿堆栈与上一次确定的卡顿堆栈相同,则不生成卡顿定位信息,确定本次休眠时间后控制所述检测子线程进入休眠,在本次休眠时间结束时满足检测子线程启动条件,再次启动检测子线程,其中,所述本次休眠时间不短于上次休眠时间。
可选的,所述确定本次休眠时间后控制所述检测子线程进入休眠,包括:
获取上次休眠时间,依据斐波那契数列在上次休眠时间的基础上进行时间递增,将递增后的时间确定为本次休眠时间;
依据所述本次休眠时间控制所述检测子线程进入休眠。
可选的,若检测到所述主线程处于非卡顿状态,则控制所述检测子线程进入休眠,并在固定时间后满足子线程启动条件,再次启动检测子线程。
可选的,所述在所述指定数量的堆栈中查找到最耗时堆栈,包括:
以栈顶函数为特征,当N个堆栈的栈顶函数相同时,确定所述N个堆栈为重复堆栈,将重复最多的堆栈确定为最耗时堆栈。
根据本公开实施例的第二方面,提供一种卡顿定位装置,包括:
堆栈采集模块,被配置为按照指定的采集频率采集主线程的堆栈;
状态检测模块,被配置为满足子线程启动条件后,启动预先创建的检测子线程,根据预设的检测规则检测主线程是否处于卡顿状态;
卡顿定位模块,被配置为若检测到所述主线程处于卡顿状态,则在采集到的堆栈中查找到最近的最耗时堆栈,基于所述最耗时堆栈生成卡顿定位信息。
可选的,所述状态检测模块,在根据预设的检测规则检测主线程是否处于卡顿状态时,被配置为:
检测到主线程Runloop的运行时间超过预定义阈值后,确定主线程处于卡顿状态,或,
检测到CPU的占用率超过预定义阈值后,确定主线程处于卡顿状态。
可选的,所述状态检测模块,在检测到主线程Runloop的运行时间超过预定义阈值时,被配置为:
检测子线程检测所述主线程Runloop中的指定状态位的状态;
所述子线程从指定状态位的状态发生改变时开始计时,若预定义阀值到达时所述指定状态位的状态没有再次发生改变,则确定所述主线程Runloop的运行时间超过预定义阈值。
可选的,所述满足检测子线程启动条件,包括:
获取本次启动时间点,在所述本次启动时间点到达时,判定为满足检测子线程启动条件,其中,所述本次启动时间点由检测子线程上次启动时检测到的主线程的卡顿状态决定,在检测到所述主线程处于持续卡顿状态时,对应延后所述检测子线程的本次启动时间点。
可选的,所述卡顿定位模块,在所述指定数量的堆栈中查找到最耗时堆栈,基于所述最耗时堆栈生成卡顿定位信息时,被配置为:
在采集的堆栈中查找最近的最耗时堆栈,确定为当前卡顿堆栈;
将所述当前卡顿堆栈与上一次确定的卡顿堆栈进行对比;
若所述当前卡顿堆栈与上一次确定的卡顿堆栈不同,则依据所述当前卡顿堆栈生成卡顿定位信息。
可选的,所述卡顿定位模块,在依据所述当前卡顿堆栈生成卡顿定位信息时,被配置为:
依据所述当前卡顿堆栈生成线程快照,将所述线程快照存储为卡顿定位信息。
可选的,所述卡顿定位模块,还包括:
休眠时间计算模块,被配置为若所述当前卡顿堆栈与上一次确定的卡顿堆栈相同,则不生成卡顿定位信息,确定本次休眠时间后控制所述检测子线程进入休眠,在本次休眠时间结束时满足检测子线程启动条件,再次启动检测子线程,其中,所述本次休眠时间不短于上次休眠时间。
可选的,所述休眠时间计算模块,在确定本次休眠时间后控制所述检测子线程进入休眠时,被配置为:
获取上次休眠时间,依据斐波那契数列在上次休眠时间的基础上进行时间递增,将递增后的时间确定为本次休眠时间;
依据所述本次休眠时间控制所述检测子线程进入休眠。
可选的,若检测到所述主线程处于非卡顿状态,则控制所述检测子线程进入休眠,并在固定时间后满足子线程启动条件,再次启动检测子线程。
可选的,所述卡顿定位模块,在所述指定数量的堆栈中查找到最耗时堆栈时,被配置为:
以栈顶函数为特征,当N个堆栈的栈顶函数相同时,确定所述N个堆栈为重复堆栈,将重复最多的堆栈确定为最耗时堆栈。
根据本公开实施例的第三方面,提供一种电子设备,包括:处理器;用于存储所述处理器可执行指令的存储器;其中,所述处理器被配置为执行所述指令,以实现如第一方面中所述的方法。
根据本公开实施例的第四方面,提供一种存储介质,当所述存储介质中的指令由电子设备的处理器执行时,使得电子设备能够执行如第一方面所述的方法。
本公开实施例提供了一种卡顿定位方法、装置、电子设备及存储介质。可以知道,主线程的堆栈中包含主线程当前运行的函数、代码等数据,卡顿定位信息是依据堆栈生成的可被直接读取分析的文件。由于采集主线程堆栈资源消耗很小,而生成卡顿定位信息资源消耗较大,本公开方案周期性采集主线程堆栈,并使用预先创建的子线程判断主线程是否卡顿,当主线程卡顿时提取对应的卡顿堆栈生成卡顿定位信息,可以在资源消耗较小的情况下,有效对卡顿原因进行定位。
应当理解的是,以上的一般描述和后文的细节描述仅是示例性和解释性的,并不能限制本公开实施例。
此外,本公开实施例中的任一实施例并不需要达到上述的全部效果。
附图说明
为了更清楚地说明本公开实施例或现有技术中的技术方案,下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍,显而易见地,下面描述中的附图仅仅是本公开实施例中记载的一些实施例,对于本领域普通技术人员来讲,还可以根据这些附图获得其他的附图。
图1是本公开一示例性实施例示出的卡顿定位方法的一种流程图;
图2是本公开一示例性实施例示出的主线程卡顿检测方法的一种示意图;
图3是本公开一示例性实施例示出的主线程堆栈采集方法的一种示意图;
图4是本公开一示例性实施例示出的主线程卡顿检测方法的一种流程图;
图5是本公开一示例性实施例示出的主线程卡顿检测方法的另一种示意图;
图6是本公开一示例性实施例示出的卡顿定位方法的另一种流程图;
图7是本公开一示例性实施例示出的最耗时堆栈获取方法的一种流程图;
图8是本公开一示例性实施例示出的卡顿定位方法的另一种流程图;
图9是本公开一示例性实施例示出的卡顿定位装置的一种示意图;
图10是本公开一示例性实施例示出的卡顿定位装置的另一种示意图。
具体实施方式
这里将详细地对示例性实施例进行说明,其示例表示在附图中。下面的描述涉及附图时,除非另有表示,不同附图中的相同数字表示相同或相似的要素。以下示例性实施例中所描述的实施方式并不代表与本公开相一致的所有实施方式。相反,它们仅是与如所附权利要求书中所详述的、本公开的一些方面相一致的装置和方法的例子。
在本公开使用的术语是仅仅出于描述特定实施例的目的,而非旨在限制本公开。在本公开和所附权利要求书中所使用的单数形式的“一种”、“所述”和“该”也旨在包括多数形式,除非上下文清楚地表示其他含义。还应当理解,本文中使用的术语“和/或”是指并包含一个或多个相关联的列出项目的任何或所有可能组合。
应当理解,尽管在本公开可能采用术语第一、第二、第三等来描述各种信息,但这些信息不应限于这些术语。这些术语仅用来将同一类型的信息彼此区分开。例如,在不脱离本公开范围的情况下,第一信息也可以被称为第二信息,类似地,第二信息也可以被称为第一信息。取决于语境,如在此所使用的词语“如果”可以被解释成为“在……时”或“当……时”或“响应于确定”。
本公开提供了一种卡顿定位方法,以及应用所述卡顿检测方法的卡顿检测设备,首先对该卡顿检测方法进行整体说明。参见图1,包括以下步骤S101~步骤S103:
在步骤S101中,按照指定的采集频率采集主线程的堆栈;
参见图2,以当前主线程事件为绘制背景,卡顿定位信息为当前线程快照为例,示意出为检测子线程的卡顿检测过程。该事件中,操作“绘制图标3”为耗时操作,是导致主线程超时的主要原因。
为了准确定位到卡顿原因,在本实施例中,周期性采集主线程的堆栈,在发生主线程超时卡顿时,就可以在采集的堆栈中查找到的最耗时堆栈来准确定位到卡顿原因为“绘制图标3”。
在本公开一实施例中,可以只留存采集时间与当前时间最近的指定数量的堆栈,避免占用太多的存储空间。采集时间与当前时间相距过远的堆栈与无法用于定位当前的卡顿情况。
具体地堆栈采集示意图可以参考图3,定时获取主线程堆栈,并将堆栈保存到内存的一个循环队列中。如图3,每间隔时间t获得一个堆栈,然后将堆栈保存到一个最大个数为3的循环队列中。可以通过一个不断变化指向的游标不断持续指向最近的堆栈。
需要注意的是,该持续采集并保存主线程堆栈的行为会占用少量的CPU资源,在实际测试数据中:每隔50毫秒采集一次主线程堆栈,并保存最近的20个主线程堆栈。会增加3%的CPU占用。需要根据当前应用场景的日常资源耗用等情况确定适合当前场景的采集频率。
在步骤S102中,满足子线程启动条件后,启动预先创建的检测子线程,根据预设的检测规则检测主线程是否处于卡顿状态;
在本公开一实施例中,根据预设的检测规则检测主线程是否处于卡顿状态时,可以通过如下两种方式却主线程的卡顿状态:
a)检测到主线程Runloop的运行时间超过预定义阈值后,确定主线程处于卡顿状态;
在本公开一实施例中,检测到主线程Runloop的时间超过预定阈值,可以采用但不限于以下方式:
(1-1)检测子线程检测所述主线程Runloop中的指定状态位的状态;
(1-2)所述子线程从指定状态位的状态发生改变时开始计时,若预定义阀值到达时所述指定状态位的状态没有再次发生改变,则确定所述主线程Runloop的运行时间超过预定义阈值。
具体而言,可以创建一个检测子线程,并使检测子线程按照预定义的启动条件执行启动-检测-休眠-启动的循环。在检测子线程进行检测时,可基于主线程观察者observer的通知消息,确定主线程Runloop是否停留一个状态太久,以此确定主线程是否处于卡顿状态。
上述(1-1)至(1-2)的具体实现过程,可详见图3所示实施例。
b)检测到CPU的占用率超过预定义阈值后,确定主线程处于卡顿状态。
CPU过高也可能导致应用出现卡顿,在检测子线程检查主线程状态的同时,如果检测到CPU占用过高,也可确定主线程处于卡顿状态。一般地,单核CPU的占用超过了80%时即可确定为CPU占用过高。
在步骤S103中,若检测到所述主线程处于卡顿状态,则在采集到的堆栈中查找到最近的最耗时堆栈,基于所述最耗时堆栈生成卡顿定位信息。
需要注意的是,在检测子线程对主线程的同一次检测中,只会确定出一个最耗时堆栈,不会同时确定出多个最耗时堆栈。因为“卡顿”这一现象说明了主线程卡在了其中一个位置,每一次卡顿只会对应一个最耗时堆栈。
在本公开一实施例中,执行步骤S103时,可以采用但不限于以下方式:
(2-1)在采集的堆栈中查找最近的最耗时堆栈,确定为当前卡顿堆栈;
(2-2)将所述当前卡顿堆栈与上一次确定的卡顿堆栈进行对比;
(2-3)若所述当前卡顿堆栈与上一次确定的卡顿堆栈不同,则依据所述当前卡顿堆栈生成卡顿定位信息。
存在一种情况,主线程会在执行某一段代码时卡死很久,这段时间内检测子线程可能启动了多次,如果检测子线程每次检测到主线程卡顿后都生成一个卡顿定位信息,那么这些针对同一次卡顿的卡顿定位信息实际也是相同的,而生成卡顿定位信息是一种较为消耗资源的操作,多次生成同样的卡顿定位信息会造成资源浪费。
为了避免这种资源浪费,在检测子线程每次检测到主线程卡顿后,先不生成卡顿定位信息,将所述当前卡顿堆栈与上一次确定的卡顿堆栈进行对比,根据对比结果确定是否生成卡顿定位信息。
即:如果对比结果表明,当前卡顿堆栈与上一次确定的卡顿堆栈不同,则说明本次主线程卡顿与上次主线程卡顿不是同一次卡顿,此时依据所述当前卡顿堆栈生成卡顿定位信息;如果对比结果表明,当前卡顿堆栈与上一次确定的卡顿堆栈相同,则说明本次主线程卡顿与上次主线程卡顿为同一次卡顿,此时不会生成卡顿定位信息。
举例说明:满足子线程启动条件后,检测子线程第一次启动并判定主线程卡顿,确定出第一个卡顿堆栈,生成卡顿定位信息并使检测子线程进入休眠;过了一段时间后再次满足检测子线程启动条件,检测子线程第二次启动仍然判定主线程卡顿,确定出第二个卡顿堆栈,此时将第二个卡顿堆栈与第一个卡顿堆栈进行对比,只有两者不同时,才生成卡顿定位信息。当两者相同时,跳过生成卡顿定位信息这一步骤,直接使检测子线程进入休眠。
上述(2-1)至(2-3)的具体实现过程,可详见图6所示实施例。
iOS平台由于UIKit本身的特性,所有的UI操作都需要由主线程执行。由此,开发人员可能会将一些线程安全性不确定的逻辑放入主线程。而不安全逻辑中包含的大量计算、IO、绘制等工作都有可能造成主线程卡顿。
传统方案中,可以通过监测FPS的方式确定主线程是否卡顿,例如向主线程的RunLoop中添加定时器CADisplayLink,使每次屏幕刷新的时候都要执行一次CADisplayLink方法,由此统计内屏幕在固定时间内的刷新次数,也就是FPS,当FPS出现明显下降时,判断出现主线程卡顿。
传统方案存在的问题在于:卡顿发生时,FPS会出现明显下降。但转场动画等特殊场景也可能存在FPS的明显下降,传统方案得到的判断结果可能并不准确。且传统方案只能确定是否发生了卡顿,无法定位到具体的造成卡顿的代码逻辑。
可以知道,卡顿就是在应用使用过程中出现界面不响应或者界面渲染粘滞的情况。而应用界面的渲染以及事件响应是在主线程完成的,出现卡顿的原因可以归结为主线程阻塞。
其中,在开发过程中,遇到的造成主线程阻塞的主要原因可能包括以下几点:
a)主线程在进行大量I/O操作:为了方便代码编写,直接在主线程去写入大量数据;
b)主线程在进行大量计算:代码编写不合理,主线程进行复杂计算;
c)大量UI绘制:界面过于复杂,UI绘制需要大量时间;
d)主线程在等锁:主线程完成任务需要获得锁A,但是当前某个子线程持有这个锁A,导致主线程不得不等待子线程完成任务。
针对这些可能的原因,如果能够捕获得到卡顿当时应用的主线程堆栈,那么就可以基于堆栈进行卡顿定位。根据堆栈,可以知道主线程在什么函数哪一行代码卡住了,是在等什么锁,是在进行I/O操作,或者是进行复杂计算。从而对问题进行针对性解决。
由此,在本公开实施例的卡顿检测方法中,一方面持续采集主线程的堆栈,另一方面利用预先创建的检测子线程在预定时间检测主线程是否卡顿。举例来说,可以每50毫秒采集并保存一次主线程的堆栈,每2秒启动一次检测子线程检测主线程是否卡顿。当主线程发生卡顿时,查找最近保存的数个堆栈中的最耗时堆栈。根据该最耗时堆栈生成卡顿定位信息,该卡顿定位信息即可用于准确定位卡顿原因。
图4是根据一示例性实施例示出的另一种卡顿定位方法的流程图,该卡顿检测方法可以用于能够执行卡顿检测的平台上,并建立在图1所示方法的基础上,如图4所示,可以包括以下步骤S401-S402:
在步骤S401中,检测子线程检测所述主线程Runloop中的指定状态位的状态;
在步骤S402中,所述子线程从指定状态位的状态发生改变时开始计时;
在步骤S403中,在预定义阀值到达时判断所述指定状态位的状态是否再次发生改变?如果未发生改变,执行步骤S404,如果发生改变,则不操作;
在步骤S404中,确定所述主线程Runloop的运行时间超过预定义阈值,上报主线程卡顿事件。
在一个例子中,本卡顿定位方法可应用于IOS平台。IOS平台中。Runloop是一种事件监听循环,用于管理事件/消息,让线程在没有处理消息时休眠以避免资源占用、在有消息到来时立刻被唤醒。即线程一直处于这个函数内部“接受消息->等待->处理”的循环中。事件/消息可以包括所接收到的用户对于IOS客户端的点击等操作。针对Runloop的卡顿检测示意图可参见图5。
具体而言,基于Ruloop的运行机制可知,处理事件主要有两个时间段,即kCFRunLoopBeforeSources发送之后,和kCFRunLoopAfterWaiting发送之后。
在Ruloop中,dispatch_semaphore_t是一个信号量机制,信号量到达或者超时都会继续向下进行,否则进入等待,如果信号量超时则返回的结果不为0,信号量到达返回的结果为0。
因此,卡顿出现的条件为:在信号量发送kCFRunLoopBeforeSources和kCFRunLoopAfterWaiting后进行了大量的操作,在一段时间内没有再发送信号量,导致超时。也就是说主线程通知状态会长时间的停留在这两个状态上。不会发生状态改变。由此,在预定义阀值到达时判断所述指定状态位的状态是否再次发生改变,如果没有改变,则确定所述主线程Runloop的运行时间超过预定义阈值,上报主线程卡顿事件。
图6是根据一示例性实施例示出的另一种卡顿定位方法的流程图,该卡顿检测方法可以用于能够执行卡顿检测的平台上,并建立在图1所示方法的基础上,如图6所示,可以包括以下步骤S601-S603:
在步骤S601中,在采集的堆栈中查找最近的最耗时堆栈,确定为当前卡顿堆栈;
本实施例中,提供如下方式,用于确定最近的最耗时堆栈:
以栈顶函数为特征,当两个堆栈的栈顶函数相同时,确定所述两个堆栈为重复堆栈,当N个堆栈的栈顶函数相同时,确定所述N个堆栈为重复堆栈。
N个堆栈为重复堆栈的定义为:N个堆栈实际上为同一个堆栈数据的N次重复采集。可以知道,由于每次采集堆栈的时间间隔都是相同的,可以通过同一堆栈的重复次数近似计算该堆栈的调用耗时,重复次数越多,则该堆栈耗时越多。由于可以获得最耗时堆栈,进而确定卡顿堆栈。
需要注意的是,可以存在多个堆栈重复次数相同的情况,在这种情况下,可以选择时间最近的一个最耗时堆栈确定为卡顿堆栈。
参见图7,为堆栈匹配的示意图,当内存中留存了最近采集的0~N号堆栈时,对该0~N号堆栈进行堆栈匹配,栈顶函数相同的堆栈视为匹配成功,将匹配成功的多个堆栈视为同一堆栈数据的多次重复采集。重复采集次数越多,则该堆栈耗时越长,将堆栈按照耗时长度从前而后进行排列。
堆栈匹配结束后,提取耗时长度排行最前的堆栈,确定为最耗时堆栈。如果有多个耗时长度相等(重复采集次数相同)的堆栈,则将其中采集时间与当前最近的堆栈确定为最耗时堆栈。采集时间与当前最近的堆栈中会包含更多的引起本次卡顿的代码数据。
在步骤S602中,将所述当前卡顿堆栈与上一次确定的卡顿堆栈进行对比;
在步骤S603中,判断当前卡顿堆栈与上一次确定的卡顿堆栈是否相同,若当前卡顿堆栈与上一次确定的卡顿堆栈相同,执行步骤S604,若当前卡顿堆栈与上一次确定的卡顿堆栈不相同,执行步骤S605;
在步骤S604中,依据所述当前卡顿堆栈生成卡顿定位信息。
检测子线程每隔一段时间启动一次,用于根据预设的检测规则检测主线程是否处于卡顿状态,存在一种情况,主线程会在执行某一段代码时卡死很久,这段时间内检测子线程可能启动了多次,如果检测子线程每次检测到主线程卡顿后都生成一个卡顿定位信息,那么这些针对同一次卡顿的卡顿定位信息实际也是相同的,而生成卡顿定位信息是一种较为消耗资源的操作,多次生成同样的卡顿定位信息会造成资源浪费。
为了避免这种资源浪费,在检测子线程每次检测到主线程卡顿后,先不生成卡顿定位信息,将所述当前卡顿堆栈与上一次确定的卡顿堆栈进行对比,根据对比结果确定是否生成卡顿定位信息。
如果对比结果表明,当前卡顿堆栈与上一次确定的卡顿堆栈不同,则说明本次主线程卡顿与上次主线程卡顿不是同一次卡顿,此时应依据所述当前卡顿堆栈生成卡顿定位信息。
在步骤S605中,不生成卡顿定位信息,确定本次休眠时间后控制所述检测子线程进入休眠,在本次休眠时间结束时满足检测子线程启动条件,其中,所述本次休眠时间不短于上次休眠时间。
如果对比结果表明,当前卡顿堆栈与上一次确定的卡顿堆栈相同,则说明本次主线程卡顿与上次主线程卡顿为同一次卡顿,此时不应生成卡顿定位信息。
由于启动检测子线程也会造成少量的资源消耗。当主线程处于长时间卡顿状态时,则应尽量减少检测子线程带来的资源消耗。避免“越测越卡”。
为此,在本实施例中,若本次主线程卡顿与上次主线程卡顿为同一次卡顿,则下一次启动检测子线程的时间会被延长。即:为检测子线程的本次休眠设定一个比上次休眠更长的时间,休眠时间结束时方满足检测子线程启动条件,可再次启动检测子线程进行卡顿检测。
本公开一实施例中,为了降低检测带来的性能损耗,设计了一种“退火算法”,检测子线程将根据退火算法的计算结果执行启动和休眠,具体参考图8,包括以下步骤S801到步骤S804:
在步骤S801中,启动检测子线程;
在步骤S802中,检测主线程是否发生卡顿,若发生卡顿,执行步骤S803,若没有发生卡顿,执行步骤S804;
在步骤S803中,生成卡顿信息;
在步骤S804中,控制子线程进入休眠,休眠时间由退火算法决定。
在本公开一实施例中,退火算法可以包括:若本次卡顿的最耗时堆栈与上次卡顿的最耗时堆栈相同,则获取上次休眠时间,依据斐波那契数列在上次休眠时间的基础上进行时间递增,将递增后的时间确定为本次休眠时间;
斐波那契数列指的是这样一个数列:1、1、2、3、5、8、13、21、34...在数学上,斐波那契数列以如下被以递推的方法定义:F(1)=1,F(2)=1,F(n)=F(n-1)+F(n-2)(n≥3,n∈N*)。
即当检测子线程启动后,确定出主线程的第一次卡顿时,生成卡顿信息并控制检测子线程进入休眠,当前休眠时间为斐波那契数列的第一个数值,即休眠1秒;
1秒结束后,满足检测子线程的启动条件,启动检测子线程,确定出主线程的第二次卡顿,若本次卡顿的最耗时堆栈与上次卡顿的最耗时堆栈相同,则说明第二次卡顿与第一次卡顿还是卡在同一个地方,不生成卡顿信息并控制检测子线程进入休眠,当前休眠时间为斐波那契数列的第二个数值,即仍为休眠1秒;依次类推,若下次卡顿的最耗时堆栈与本次卡顿的最耗时堆栈仍然相同,则检测子线程的休眠时间将为2秒,再下次休眠时间则为3秒、5秒、8秒...
依据斐波那契数列来确定休眠时间仅为一种例子,也可自行设定公式或数列,只要公式或数列能够满足“主线程卡顿时间越长,下一次启动检测子线程的间隔时间越长”这一条件即可。
相应的,如果本次卡顿的最耗时堆栈与上次卡顿的最耗时堆栈不相同,则说明两个不是相同的卡顿,重新按照固定间隔时间启动检测子线程,该固定时间可以为数列的初始值,如斐波那契数列中的1秒。
可以知道,主线程的堆栈中包含主线程当前运行的函数、代码等数据,卡顿定位信息是依据堆栈生成的可被直接读取分析的文件。由于采集主线程堆栈资源消耗很小,而生成卡顿定位信息资源消耗较大,本公开方案周期性采集主线程堆栈,并使用预先创建的子线程判断主线程是否卡顿,当主线程卡顿时提取对应的卡顿堆栈生成卡顿定位信息,可以在资源消耗较小的情况下,有效对卡顿原因进行定位。
相应于上述方法实施例,本公开实施例还提供一种卡顿定位装置,参见图9所示,所述装置可以包括:堆栈采集模块910,状态检测模块920和卡顿定位模块930。
堆栈采集模块910,被配置为按照指定的采集频率采集主线程的堆栈;
状态检测模块920,被配置为满足子线程启动条件后,启动预先创建的检测子线程,根据预设的检测规则检测主线程是否处于卡顿状态;
卡顿定位模块930,被配置为若检测到所述主线程处于卡顿状态,则在采集到的堆栈中查找到最近的最耗时堆栈,基于所述最耗时堆栈生成卡顿定位信息。
可选的,所述状态检测模块,在根据预设的检测规则检测主线程是否处于卡顿状态时,被配置为:
检测到主线程Runloop的运行时间超过预定义阈值后,确定主线程处于卡顿状态,或,
检测到CPU的占用率超过预定义阈值后,确定主线程处于卡顿状态。
可选的,所述状态检测模块,在检测到主线程Runloop的运行时间超过预定义阈值时,被配置为:
检测子线程检测所述主线程Runloop中的指定状态位的状态;
所述子线程从指定状态位的状态发生改变时开始计时,若预定义阀值到达时所述指定状态位的状态没有再次发生改变,则确定所述主线程Runloop的运行时间超过预定义阈值。
可选的,所述卡顿定位模块,在所述指定数量的堆栈中查找到最耗时堆栈,基于所述最耗时堆栈生成卡顿定位信息时,被配置为:
在采集的堆栈中查找最近的最耗时堆栈,确定为当前卡顿堆栈;
将所述当前卡顿堆栈与上一次确定的卡顿堆栈进行对比;
若所述当前卡顿堆栈与上一次确定的卡顿堆栈不同,则依据所述当前卡顿堆栈生成卡顿定位信息。
可选的,所述卡顿定位模块,在依据所述当前卡顿堆栈生成卡顿定位信息时,被配置为:
依据所述当前卡顿堆栈生成线程快照,将所述线程快照存储为卡顿定位信息。
可选的,所述卡顿定位模块,还包括:
休眠时间计算模块,被配置为若所述当前卡顿堆栈与上一次确定的卡顿堆栈相同,则不生成卡顿定位信息,确定本次休眠时间后控制所述检测子线程进入休眠,在本次休眠时间结束后再次启动检测子线程,其中,所述本次休眠时间不短于上次休眠时间。
可选的,所述休眠时间计算模块,在确定本次休眠时间后控制所述检测子线程进入休眠时,被配置为:
获取上次休眠时间,依据斐波那契数列在上次休眠时间的基础上进行时间递增,将递增后的时间确定为本次休眠时间;
依据所述本次休眠时间控制所述检测子线程进入休眠。
可选的,若检测到所述主线程处于非卡顿状态,则控制所述检测子线程进入休眠,并在固定时间后再次启动检测子线程。
可选的,所述卡顿定位模块,在所述指定数量的堆栈中查找到最耗时堆栈时,被配置为:
以栈顶函数为特征,当N个堆栈的栈顶函数相同时,确定所述N个堆栈为重复堆栈,将重复最多的堆栈确定为最耗时堆栈。
本公开实施例还提供一种电子设备,其至少包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序,其中,处理器执行所述程序时实现前述卡顿检测方法,包括:
按照指定的采集频率采集主线程的堆栈;
满足检测子线程启动条件后,启动预先创建的检测子线程,根据预设的检测规则检测主线程是否处于卡顿状态;
若检测到所述主线程处于卡顿状态,则在采集到的堆栈中查找到最近的最耗时堆栈,基于所述最耗时堆栈生成卡顿定位信息。
图10示出了根据本公开的一示例性实施例的基于主设备侧电子设备的示意结构图。请参考图10,在硬件层面,该电子设备包括处理器1002、内部总线1004、网络接口1010、内存1004以及非易失性存储器1010,当然还可能包括其他业务所需要的硬件。处理器1002从非易失性存储器1010中读取对应的计算机程序到内存1002中然后运行,在逻辑层面上形成执行卡顿检测方法的装置。当然,除了软件实现方式之外,本公开并不排除其他实现方式,比如逻辑器件抑或软硬件结合的方式等等,也就是说以下处理流程的执行主体并不限定于各个逻辑单元,也可以是硬件或逻辑器件。
本公开实施例还提供一种计算机可读存储介质,其上存储有计算机程序,该程序被处理器执行时实现前述的卡顿检测方法,包括:
按照指定的采集频率采集主线程的堆栈;
满足检测子线程启动条件后,启动预先创建的检测子线程,根据预设的检测规则检测主线程是否处于卡顿状态;
若检测到所述主线程处于卡顿状态,则在采集到的堆栈中查找到最近的最耗时堆栈,基于所述最耗时堆栈生成卡顿定位信息。
计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括,但不限于相变内存(PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其他类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、快闪记忆体或其他内存技术、只读光盘只读存储器(CD-ROM)、数字多功能光盘(DVD)或其他光学存储、磁盒式磁带,磁带磁存储设备存储或其他磁性存储设备或任何其他非传输介质,可用于存储可以被计算设备访问的信息。按照本文中的界定,计算机可读介质不包括暂存电脑可读媒体(transitory media),如调制的数据信号和载波。
对于装置实施例而言,由于其基本对应于方法实施例,所以相关之处参见方法实施例的部分说明即可。以上所描述的装置实施例仅仅是示意性的,其中所述作为分离部件说明的单元可以是或者也可以不是物理上分开的,作为单元显示的部件可以是或者也可以不是物理单元,即可以位于一个地方,或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本公开方案的目的。本领域普通技术人员在不付出创造性劳动的情况下,即可以理解并实施。
上述实施例阐明的系统、装置、模块或单元,具体可以由计算机芯片或实体实现,或者由具有某种功能的产品来实现。一种典型的实现设备为计算机,计算机的具体形式可以是个人计算机、膝上型计算机、蜂窝电话、相机电话、智能电话、个人数字助理、媒体播放器、导航设备、电子邮件收发设备、游戏控制台、平板计算机、可穿戴设备或者这些设备中的任意几种设备的组合。
以上所述仅是本公开实施例的具体实施方式,应当指出,对于本技术领域的普通技术人员来说,在不脱离本公开实施例原理的前提下,还可以做出若干改进和润饰,这些改进和润饰也应视为本公开实施例的保护范围。

Claims (18)

1.一种卡顿定位方法,其特征在于,包括:
按照指定的采集频率采集主线程的堆栈;
满足检测子线程启动条件后,启动预先创建的检测子线程,根据预设的检测规则检测主线程是否处于卡顿状态;
若检测到所述主线程处于卡顿状态,则在采集到的堆栈中查找到最近的最耗时堆栈,基于所述最耗时堆栈生成卡顿定位信息;所述在所述指定数量的堆栈中查找到最耗时堆栈,基于所述最耗时堆栈生成卡顿定位信息,包括:在采集的堆栈中查找最近的最耗时堆栈,确定为当前卡顿堆栈;将所述当前卡顿堆栈与上一次确定的卡顿堆栈进行对比;若所述当前卡顿堆栈与上一次确定的卡顿堆栈不同,则依据所述当前卡顿堆栈生成卡顿定位信息;
若所述当前卡顿堆栈与上一次确定的卡顿堆栈相同,则不生成卡顿定位信息,确定本次休眠时间后控制所述检测子线程进入休眠,在本次休眠时间结束时满足检测子线程启动条件,再次启动检测子线程,其中,所述本次休眠时间不短于上次休眠时间。
2.如权利要求1所述的方法,其特征在于,所述根据预设的检测规则检测主线程是否处于卡顿状态,包括:
检测到主线程Runloop的运行时间超过预定义阈值后,确定主线程处于卡顿状态,或,
检测到CPU的占用率超过预定义阈值后,确定主线程处于卡顿状态。
3.如权利要求2所述的方法,其特征在于,所述检测到主线程Runloop的运行时间超过预定义阈值,包括:
检测子线程检测所述主线程Runloop中的指定状态位的状态;
所述检测子线程从指定状态位的状态发生改变时开始计时,若预定义阀值到达时所述指定状态位的状态没有再次发生改变,则确定所述主线程Runloop的运行时间超过预定义阈值。
4.如权利要求1所述的方法,其特征在于,所述满足检测子线程启动条件,包括:
获取本次启动时间点,在所述本次启动时间点到达时,判定为满足检测子线程启动条件,其中,所述本次启动时间点由检测子线程上次启动时检测到的主线程的卡顿状态决定,在检测到所述主线程处于持续卡顿状态时,对应延后所述检测子线程的本次启动时间点。
5.如权利要求1所述的方法,其特征在于,所述依据所述当前卡顿堆栈生成卡顿定位信息,包括:
依据所述当前卡顿堆栈生成线程快照,将所述线程快照存储为卡顿定位信息。
6.如权利要求1所述的方法,其特征在于,所述确定本次休眠时间后控制所述检测子线程进入休眠,包括:
获取上次休眠时间,依据斐波那契数列在上次休眠时间的基础上进行时间递增,将递增后的时间确定为本次休眠时间;
依据所述本次休眠时间控制所述检测子线程进入休眠。
7.如权利要求1所述的方法,其特征在于,若检测到所述主线程处于非卡顿状态,则控制所述检测子线程进入休眠,并在固定时间后满足检测子线程启动条件,再次启动检测子线程。
8.如权利要求1所述的方法,其特征在于,所述在所述指定数量的堆栈中查找到最耗时堆栈,包括:
以栈顶函数为特征,当N个堆栈的栈顶函数相同时,确定所述N个堆栈为重复堆栈,将重复最多的堆栈确定为最耗时堆栈。
9.一种卡顿定位装置,其特征在于,包括:
堆栈采集模块,被配置为按照指定的采集频率采集主线程的堆栈;
状态检测模块,被配置为满足检测子线程启动条件后,启动预先创建的检测子线程,根据预设的检测规则检测主线程是否处于卡顿状态;
卡顿定位模块,被配置为若检测到所述主线程处于卡顿状态,则在采集到的堆栈中查找到最近的最耗时堆栈,基于所述最耗时堆栈生成卡顿定位信息;所述卡顿定位模块,在所述指定数量的堆栈中查找到最耗时堆栈,基于所述最耗时堆栈生成卡顿定位信息时,被配置为:在采集的堆栈中查找最近的最耗时堆栈,确定为当前卡顿堆栈;将所述当前卡顿堆栈与上一次确定的卡顿堆栈进行对比;若所述当前卡顿堆栈与上一次确定的卡顿堆栈不同,则依据所述当前卡顿堆栈生成卡顿定位信息;
所述卡顿定位模块,还包括:休眠时间计算模块,被配置为卡顿堆栈与上一次确定的卡顿堆栈相同,则不生成卡顿定位信息,确定本次休眠时间后控制所述检测子线程进入休眠,在本次休眠时间结束时满足检测子线程启动条件,再次启动检测子线程,其中,所述本次休眠时间不短于上次休眠时间。
10.如权利要求9所述的装置,其特征在于,所述状态检测模块,在根据预设的检测规则检测主线程是否处于卡顿状态时,被配置为:
检测到主线程Runloop的运行时间超过预定义阈值后,确定主线程处于卡顿状态,或,
检测到CPU的占用率超过预定义阈值后,确定主线程处于卡顿状态。
11.如权利要求10所述的装置,其特征在于,所述状态检测模块,在检测到主线程Runloop的运行时间超过预定义阈值时,被配置为:
检测子线程检测所述主线程Runloop中的指定状态位的状态;
所述子线程从指定状态位的状态发生改变时开始计时,若预定义阀值到达时所述指定状态位的状态没有再次发生改变,则确定所述主线程Runloop的运行时间超过预定义阈值。
12.如权利要求9所述的装置,其特征在于,所述满足检测子线程启动条件,包括:
获取本次启动时间点,在所述本次启动时间点到达时,判定为满足检测子线程启动条件,其中,所述本次启动时间点由检测子线程上次启动时检测到的主线程的卡顿状态决定,在检测到所述主线程处于持续卡顿状态时,对应延后所述检测子线程的本次启动时间点。
13.如权利要求9所述的装置,其特征在于,所述卡顿定位模块,在依据所述当前卡顿堆栈生成卡顿定位信息时,被配置为:
依据所述当前卡顿堆栈生成线程快照,将所述线程快照存储为卡顿定位信息。
14.如权利要求9所述的装置,其特征在于,所述休眠时间计算模块,在确定本次休眠时间后控制所述检测子线程进入休眠时,被配置为:
获取上次休眠时间,依据斐波那契数列在上次休眠时间的基础上进行时间递增,将递增后的时间确定为本次休眠时间;
依据所述本次休眠时间控制所述检测子线程进入休眠。
15.如权利要求9所述的装置,其特征在于,若检测到所述主线程处于非卡顿状态,则控制所述检测子线程进入休眠,并在固定时间后满足子线程启动条件,再次启动检测子线程。
16.如权利要求9所述的装置,其特征在于,所述卡顿定位模块,在所述指定数量的堆栈中查找到最耗时堆栈时,被配置为:
以栈顶函数为特征,当N个堆栈的栈顶函数相同时,确定所述N个堆栈为重复堆栈,将重复最多的堆栈确定为最耗时堆栈。
17.一种电子设备,其特征在于,包括:处理器;用于存储所述处理器可执行指令的存储器;其中,所述处理器被配置为执行所述指令,以实现如权利要求1至8中任一项所述的方法。
18.一种存储介质,其特征在于,当所述存储介质中的指令由电子设备的处理器执行时,使得电子设备能够执行如权利要求1至8中任一项所述的方法。
CN202010457567.7A 2020-05-26 2020-05-26 一种卡顿定位方法和装置 Active CN111625456B (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202010457567.7A CN111625456B (zh) 2020-05-26 2020-05-26 一种卡顿定位方法和装置

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202010457567.7A CN111625456B (zh) 2020-05-26 2020-05-26 一种卡顿定位方法和装置

Publications (2)

Publication Number Publication Date
CN111625456A CN111625456A (zh) 2020-09-04
CN111625456B true CN111625456B (zh) 2024-04-30

Family

ID=72260022

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202010457567.7A Active CN111625456B (zh) 2020-05-26 2020-05-26 一种卡顿定位方法和装置

Country Status (1)

Country Link
CN (1) CN111625456B (zh)

Families Citing this family (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN112527627B (zh) * 2020-11-02 2024-05-10 百果园技术(新加坡)有限公司 一种页面卡顿检测方法、装置、设备及介质
CN112433877B (zh) * 2020-12-01 2024-05-17 北京五八信息技术有限公司 应用启动崩溃的检测方法、装置、电子设备及存储介质
CN112764959B (zh) * 2021-01-27 2023-05-16 抖音视界有限公司 应用程序卡死问题的监测方法、装置、设备及存储介质
CN113835985B (zh) * 2021-09-27 2023-09-29 北京基调网络股份有限公司 一种监测卡顿、分析卡顿原因的方法、装置及设备

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN106681913A (zh) * 2016-12-08 2017-05-17 武汉斗鱼网络科技有限公司 一种应用卡顿定位系统及方法
CN108197032A (zh) * 2018-01-23 2018-06-22 武汉斗鱼网络科技有限公司 Ios应用的主线程卡顿监测方法、介质、设备及系统
CN108345524A (zh) * 2017-01-22 2018-07-31 腾讯科技(深圳)有限公司 应用程序监控方法及应用程序监控装置
CN108519923A (zh) * 2018-03-01 2018-09-11 北京三快在线科技有限公司 一种卡顿检测方法及装置和电子设备
CN108563526A (zh) * 2018-03-06 2018-09-21 北京酷我科技有限公司 一种iOS卡顿监控策略
CN109840177A (zh) * 2017-11-24 2019-06-04 腾讯科技(深圳)有限公司 一种卡顿的处理方法及相关设备

Family Cites Families (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10853480B2 (en) * 2018-04-13 2020-12-01 Webroot Inc. Stack pivot exploit detection and mitigation

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN106681913A (zh) * 2016-12-08 2017-05-17 武汉斗鱼网络科技有限公司 一种应用卡顿定位系统及方法
CN108345524A (zh) * 2017-01-22 2018-07-31 腾讯科技(深圳)有限公司 应用程序监控方法及应用程序监控装置
CN109840177A (zh) * 2017-11-24 2019-06-04 腾讯科技(深圳)有限公司 一种卡顿的处理方法及相关设备
CN108197032A (zh) * 2018-01-23 2018-06-22 武汉斗鱼网络科技有限公司 Ios应用的主线程卡顿监测方法、介质、设备及系统
CN108519923A (zh) * 2018-03-01 2018-09-11 北京三快在线科技有限公司 一种卡顿检测方法及装置和电子设备
CN108563526A (zh) * 2018-03-06 2018-09-21 北京酷我科技有限公司 一种iOS卡顿监控策略

Also Published As

Publication number Publication date
CN111625456A (zh) 2020-09-04

Similar Documents

Publication Publication Date Title
CN111625456B (zh) 一种卡顿定位方法和装置
CN108345524B (zh) 应用程序监控方法及应用程序监控装置
CN105302637A (zh) 系统进程运行异常引起卡顿的恢复方法、装置及移动终端
CN106959899B (zh) 一种消息阻塞检测方法、装置及计算机存储介质
CN102609276A (zh) 预先载入常用应用程序的方法及其电子装置
CN108259526B (zh) 一种数据传输方法和装置
CN107273080B (zh) 一种基于多线程的移动端图片渲染方法及装置
CN112764959B (zh) 应用程序卡死问题的监测方法、装置、设备及存储介质
CN111427637A (zh) 页面渲染方法和装置
CN110795239A (zh) 应用内存泄露的检测方法及装置
CN111857854A (zh) 关机资源加载方法、装置、存储介质和电子设备
CN114461323B (zh) 一种卡顿处理方法、装置、电子设备及存储介质
CN109491771B (zh) 基于系统性能优化的任务处理方法及相关设备
CN110955548A (zh) 数据处理方法及装置
CN115617518A (zh) 线程管理方法、装置、电子设备及存储介质
CN109657889B (zh) 考勤方法及装置
CN111309475B (zh) 一种检测任务执行方法及设备
CN110222016B (zh) 一种文件处理方法及装置
US20060100986A1 (en) Task switching
CN113687942A (zh) 检测方法、装置及电子设备
CN111078405A (zh) 内存分配方法、装置、存储介质及电子设备
WO2019153986A1 (zh) 应用的展示方法、装置、存储介质及电子设备
CN112131009B (zh) 一种内存调度方法、装置及计算机可读存储介质
CN111930464B (zh) 地图引擎的资源配置方法、装置及电子设备
CN107967181B (zh) 临界区的控制方法及装置

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
GR01 Patent grant
GR01 Patent grant