CN108197032B - Ios应用的主线程卡顿监测方法、介质、设备及系统 - Google Patents
Ios应用的主线程卡顿监测方法、介质、设备及系统 Download PDFInfo
- Publication number
- CN108197032B CN108197032B CN201810065370.1A CN201810065370A CN108197032B CN 108197032 B CN108197032 B CN 108197032B CN 201810065370 A CN201810065370 A CN 201810065370A CN 108197032 B CN108197032 B CN 108197032B
- Authority
- CN
- China
- Prior art keywords
- main thread
- thread
- semaphore
- jamming
- class
- 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
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/36—Preventing errors by testing or debugging software
- G06F11/3668—Software testing
- G06F11/3672—Test management
- G06F11/3684—Test management for test design, e.g. generating new test cases
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/36—Preventing errors by testing or debugging software
- G06F11/3668—Software testing
- G06F11/3672—Test management
- G06F11/3688—Test management for test execution, e.g. scheduling of test suites
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
本发明公开了一种IOS应用的主线程卡顿监测方法、介质、设备及系统,涉及IOS应用技术领域,本发明定义一个Objective‑C的类,在Objective‑C的类中增加通知观察者,使用通知观察者注册监听主线程消息循环中的状态变化事件,设置当通知观察者监听到状态变化事件时发出信号量;创建一个第一子线程,通过第一子线程等待信号量,根据收到信号量的时间和主线程消息循环的状态判断是否发生卡顿。本方案通过定义Objective‑C的类实现IOS应用运行时主线程卡顿监测,在IOS移动端开发Objective‑C的类所需代码小,运行时占用内存也小,因此本方案可实现IOS应用在移动端发布之后对移动端的IOS应用的IOS应用运行时主线程卡顿的有效监控。
Description
技术领域
本发明涉及IOS应用技术领域,具体涉及一种IOS应用的主线程卡顿监测方法、介质、设备及系统。
背景技术
在移动应用的开发过程中,可能会遇到一些性能瓶颈,例如程序运行的卡顿或内存无法正确的释放,都无法得到很好的监控或反馈。一般的方法是将手机连上电脑,利用Xcode(一种Mac OS X操作系统上的集成开发工具)所带的Instrument工具进行监控。Xcode自带的Instrument工具是一个以独立APP形式存在的工具集,包含了很多强大的检测功能:其中包括在真机和模拟器上进行性能测试,对APP进行性能分析,检查一个或多个应用或进程的行为。Instrument工具主要用于在调试过程中随时发现问题,及时优化。但是Instrument工具只能供有应用源码的程序员使用,因此必须连接电脑,无法测量用户真实使用场景下的性能,即无法在IOS应用发布之后依然对IOS应用的运行情况进行有效的监控。
发明内容
针对现有技术中存在的缺陷,本发明的目的在于提供一种IOS应用的主线程卡顿监测方法、介质、设备及系统,实现IOS应用发布之后对IOS应用运行时主线程卡顿的有效监控。
为达到以上目的,本发明采取的技术方案是:一种IOS应用的主线程卡顿监测方法:
S1,定义一个Objective-C的类,并实现该类的单例加载;在Objective-C的类中增加一个属性:信号量;在所述Objective-C的类中增加通知观察者,使用通知观察者监听主线程消息循环中的状态变化事件,设置当所述通知观察者监听到状态变化事件时发出信号量;
S2,创建一个第一子线程,通过所述第一子线程等待信号量,根据收到信号量的时间和所述主线程消息循环的当前状态判断是否发生卡顿;若是,进入步骤S3;若否,进入步骤S4;
S3,返回发生卡顿;
S4,刷新阻塞时间,返回步骤S2。
在上述技术方案的基础上,步骤S3还包括创建第二子线程,通过所述第二子线程抓取所述IOS应用运行时主线程的堆栈信息并存入本地数据库。
在上述技术方案的基础上,根据收到信号量的时间判断是否发生卡顿的方法是:
先判断收到信号量的时间是否大于预设的阻塞时间阈值;若是,再判断所述主线程消息循环是否为kCFRunLoopBeforeSources状态或kCFRunLoopAfterWaiting状态;若均是,判断为发生卡顿;否则,判断为发生卡顿。
在上述技术方案的基础上,所述阻塞时间阈值为500ms。
本发明还公开了一种存储介质,该存储介质上存储有计算机程序:所述计算机程序被处理器执行时实现IOS应用的主线程卡顿监测方法。
本发明还公开了一种电子设备,包括存储器和处理器,存储器上储存有在处理器上运行的计算机程序:处理器执行计算机程序时实现IOS应用的主线程卡顿监测方法。
本发明还公开了一种IOS应用的主线程卡顿监测系统,包括:
监听模块,其用于定义一个Objective-C的类,并实现该类的单例加载;在Objective-C的类中增加一个属性:信号量;在所述Objective-C的类中增加通知观察者,使用通知观察者监听主线程消息循环中的状态变化事件,设置当所述通知观察者监听到状态变化事件时发出信号量;
卡顿监测模块,其用于创建一个第一子线程,通过所述第一子线程等待信号量,根据收到信号量的时间和所述主线程消息循环的当前状态判断是否发生卡顿;若是,返回发生卡顿;若否,刷新阻塞时间,继续通过所述第一子线程等待信号量;
在上述技术方案的基础上,所述主线程卡顿监测系统还包括堆栈抓取模块,其用于判断为发生卡顿时,创建第二子线程,通过所述第二子线程抓取堆栈并存入本地数据库。
在上述技术方案的基础上,所述卡顿监测模块用于:
先判断收到信号量的时间是否大于预设的阻塞时间阈值;若是,再判断所述主线程消息循环是否为kCFRunLoopBeforeSources状态或kCFRunLoopAfterWaiting状态;若均是,判断为发生卡顿;否则,判断为发生卡顿。
在上述技术方案的基础上,所述阻塞时间阈值为500ms。
与现有技术相比,本发明的优点在于:
本发明定义一个Objective-C的类,并实现该类的单例加载;在Objective-C的类中增加通知观察者,使用通知观察者注册监听主线程消息循环中的状态变化事件,设置当通知观察者监听到状态变化事件时发出信号量;创建一个第一子线程,通过第一子线程等待信号量,根据收到信号量的时间和主线程消息循环的状态判断是否发生卡顿。本方案通过定义Objective-C的类实现IOS应用运行时主线程卡顿监测,在IOS移动端开发Objective-C的类所需代码小,运行时占用内存也小,因此本方案可实现IOS应用在移动端发布之后对移动端的IOS应用的IOS应用运行时主线程卡顿的有效监控。
判断为发生卡顿时,创建第二子线程,通过第二子线程抓取IOS应用运行时主线程的堆栈信息并存入本地数据库,可通过IOS应用运行时主线程的堆栈信息分析发生卡顿的原因。
附图说明
图1为本发明实施例中IOS应用的主线程卡顿监测方法的流程示意图;
图2为本发明实施例中IOS应用的主线程卡顿监测系统的结构示意图。
具体实施方式
以下结合附图及实施例对本发明作进一步详细说明。
为了使本发明的目的、技术方案及优点更加清楚明白,以下结合附图及实施例,对本发明进行进一步详细说明。应当理解,此处所描述的具体实施例仅仅用以解释本发明,并不用于限定本发明。此外,下面所描述的本发明各个实施方式中所涉及到的技术特征只要彼此之间未构成冲突就可以相互组合。
以下首先就本发明的术语进行解释和说明:
Objective-C的类:类是核心支持面向对象编程及Objective-C的特点,通常被称为用户定义的类型。类是用来指定对象的形式,它结合了数据表示和方法操纵这些数据转换成一个整齐的包。
实现类单例加载:即保证一个类只生成一个实例对象。
通知观察者,通知观察者注册成为被观察者的监听者,当被观察者发生某些变化的时刻,就会触发这个监听,调用通知观察者中的监听方法。
主线程消息循环,消息循环又叫运行循环,只有主线程的消息循环是默认开启,是专门为主线程检测UI交互事件的。
kCFRunLoopBeforeSources状态或kCFRunLoopAfterWaiting状态:根据Runloop的运行机制,Runloop包括三个阶段:kCFRunLoopBeforeSources、kCFRunLoopBeforeWaiting和kCFRunLoopAfterWaiting。其中处理事件主要有两个时间段:kCFRunLoopBeforeSources发送之后和kCFRunLoopAfterWaiting发送之后。利用这个特性判断卡顿出现的条件为:在发送kCFRunLoopBeforeSources后或kCFRunLoopAfterWaiting后进行了大量的操作,且在一段时间内没有再发送信号量,即为超时。也就是说主线程通知状态长时间的停留在这两个状态上了。所以,判断是否卡顿的方法为:判断有没有超时,超时了,判断当前停留的状态是不是这两个状态,如果是,就判定为卡顿。
实施例1:
参见图1所示,本发明实施例提供一种IOS应用的主线程卡顿监测方法:
S1,定义一个Objective-C的类,并实现该类的单例加载;在Objective-C的类中增加一个属性:信号量;在Objective-C的类中增加通知观察者,使用通知观察者监听主线程消息循环中的状态变化事件,设置当通知观察者监听到状态变化事件时发出信号量;
S2,创建一个第一子线程,通过第一子线程等待信号量,根据收到信号量的时间和主线程消息循环的当前状态判断是否发生卡顿;若是,进入步骤S3;若否,进入步骤S4;
S3,返回发生卡顿;创建第二子线程,通过第二子线程抓取所述IOS应用运行时主线程的堆栈信息并存入本地数据库;
S4,刷新阻塞时间,返回步骤S2。
本方案通过定义Objective-C的类实现IOS应用运行时主线程卡顿监测,在IOS移动端开发Objective-C的类所需代码小,运行时占用内存也小,因此本方案可实现IOS应用在移动端发布之后对移动端的IOS应用的IOS应用运行时主线程卡顿的有效监控。
本方案在判断发生卡顿时,创建第二子线程,通过所述第二子线程抓取所述IOS应用运行时主线程的堆栈信息并存入本地数据库,可通过IOS应用运行时主线程的堆栈信息分析发生卡顿的原因。
根据收到信号量的时间判断是否发生卡顿的方法是:
先判断收到信号量的时间是否大于预设的阻塞时间阈值;所述阻塞时间阈值为500ms。若是,再判断所述主线程消息循环是否为kCFRunLoopBeforeSources状态或kCFRunLoopAfterWaiting状态;若均是,判断为发生卡顿;否则,判断为发生卡顿。
实施例2:
本发明实施例还公开了一种存储介质,该存储介质上存储有计算机程序,所述计算机程序被处理器执行时实现IOS应用的主线程卡顿监测方法。
实施例3:
本发明实施例还公开了一种电子设备,包括存储器和处理器,存储器上储存有在处理器上运行的计算机程序:处理器执行计算机程序时实现IOS应用的主线程卡顿监测方法。
实施例4:
参见图2所示,本发明实施例还公开了一种IOS应用的主线程卡顿监测系统,包括:
监听模块,其用于定义一个Objective-C的类,并实现该类的单例加载;在Objective-C的类中增加一个属性:信号量;在所述Objective-C的类中增加通知观察者,使用通知观察者监听主线程消息循环中的状态变化事件,设置当所述通知观察者监听到状态变化事件时发出信号量;
卡顿监测模块,其用于创建一个第一子线程,通过所述第一子线程等待信号量,根据收到信号量的时间和所述主线程消息循环的当前状态判断是否发生卡顿;若是,返回发生卡顿;若否,刷新阻塞时间,继续通过所述第一子线程等待信号量;
主线程卡顿监测系统还包括堆栈抓取模块,其用于判断为发生卡顿时,创建第二子线程,通过所述第二子线程抓取堆栈并存入本地数据库。
所述卡顿监测模块用于:
先判断收到信号量的时间是否大于预设的阻塞时间阈值;所述阻塞时间阈值为500ms。若是,再判断所述主线程消息循环是否为kCFRunLoopBeforeSources状态或kCFRunLoopAfterWaiting状态;若均是,判断为发生卡顿;否则,判断为发生卡顿。
本发明不局限于上述实施方式,对于本技术领域的普通技术人员来说,在不脱离本发明原理的前提下,还可以做出若干改进和润饰,这些改进和润饰也视为本发明的保护范围之内。本说明书中未作详细描述的内容属于本领域专业技术人员公知的现有技术。
Claims (8)
1.一种IOS应用的主线程卡顿监测方法,其特征在于:
S1,定义一个Objective-C的类,并实现该类的单例加载;在Objective-C的类中增加一个属性:信号量;在所述Objective-C的类中增加通知观察者,使用通知观察者监听主线程消息循环的状态变化事件,设置当所述通知观察者监听到状态变化事件时发出信号量;
S2,创建一个第一子线程,通过所述第一子线程等待信号量,根据收到信号量的时间和所述主线程消息循环的当前状态判断是否发生卡顿;若是,进入步骤S3;若否,进入步骤S4;
S3,返回发生卡顿;
S4,刷新阻塞时间,返回步骤S2;所述步骤S3还包括创建第二子线程,通过所述第二子线程抓取所述IOS应用运行时主线程的堆栈信息并存入本地数据库;根据收到信号量的时间判断是否发生卡顿的方法是:
先判断收到信号量的时间是否大于预设的阻塞时间阈值;若是,再判断所述主线程消息循环是否为kCFRunLoopBeforeSources状态或kCFRunLoopAfterWaiting状态;若均是,判断为发生卡顿;否则,判断为发生卡顿。
2.如权利要求1所述的一种IOS应用的主线程卡顿监测方法,其特征在于:所述阻塞时间阈值为500ms。
3.一种存储介质,该存储介质上存储有计算机程序,其特征在于:所述计算机程序被处理器执行时实现权利要求1至2任一项所述的方法。
4.一种电子设备,包括存储器和处理器,存储器上储存有在处理器上运行的计算机程序,其特征在于:处理器执行计算机程序时实现权利要求1至2任一项所述的方法。
5.一种IOS应用的主线程卡顿监测系统,其特征在于,包括:
监听模块,其用于定义一个Objective-C的类,并实现该类的单例加载;在Objective-C的类中增加一个属性:信号量;在所述Objective-C的类中增加通知观察者,使用通知观察者监听主线程消息循环中的状态变化事件,设置当所述通知观察者监听到状态变化事件时发出信号量;
卡顿监测模块,其用于创建一个第一子线程,通过所述第一子线程等待信号量,根据收到信号量的时间和所述主线程消息循环的当前状态判断是否发生卡顿;若是,返回发生卡顿;若否,刷新阻塞时间,继续通过所述第一子线程等待信号量。
6.如权利要求5所述的一种IOS应用的主线程卡顿监测系统,其特征在于:所述主线程卡顿监测系统还包括堆栈抓取模块,其用于判断为发生卡顿时,创建第二子线程,通过所述第二子线程抓取堆栈并存入本地数据库。
7.如权利要求5所述的一种IOS应用的主线程卡顿监测系统,其特征在于:所述卡顿监测模块用于:
先判断收到信号量的时间是否大于预设的阻塞时间阈值;若是,再判断所述主线程消息循环是否为kCFRunLoopBeforeSources状态或kCFRunLoopAfterWaiting状态;若均是,判断为发生卡顿;否则,判断为发生卡顿。
8.如权利要求6所述的一种IOS应用的主线程卡顿监测系统,其特征在于:所述阻塞时间阈值为500ms。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201810065370.1A CN108197032B (zh) | 2018-01-23 | 2018-01-23 | Ios应用的主线程卡顿监测方法、介质、设备及系统 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201810065370.1A CN108197032B (zh) | 2018-01-23 | 2018-01-23 | Ios应用的主线程卡顿监测方法、介质、设备及系统 |
Publications (2)
Publication Number | Publication Date |
---|---|
CN108197032A CN108197032A (zh) | 2018-06-22 |
CN108197032B true CN108197032B (zh) | 2021-04-27 |
Family
ID=62590494
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN201810065370.1A Active CN108197032B (zh) | 2018-01-23 | 2018-01-23 | Ios应用的主线程卡顿监测方法、介质、设备及系统 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN108197032B (zh) |
Families Citing this family (10)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
WO2020082354A1 (zh) * | 2018-10-26 | 2020-04-30 | 深圳市欢太科技有限公司 | 一种系统状态检测方法、系统状态装置及终端设备 |
CN109582536B (zh) * | 2018-11-05 | 2022-04-12 | 广州方硅信息技术有限公司 | 应用程序无响应的上报方法、装置和计算机设备 |
CN111221697B (zh) * | 2018-11-23 | 2024-02-27 | 阿里巴巴集团控股有限公司 | 调用监听方法、操作检测方法、装置及计算设备 |
CN111382026B (zh) * | 2018-12-28 | 2024-02-06 | 广州市百果园信息技术有限公司 | 卡顿监控方法、装置、系统、存储介质和计算机设备 |
CN111538638A (zh) * | 2020-04-28 | 2020-08-14 | 北京思特奇信息技术股份有限公司 | 一种iOS端应用程序性能的监控方法和装置 |
CN111611092B (zh) * | 2020-05-21 | 2023-10-20 | 广州探途网络技术有限公司 | 通知处理方法、装置及设备 |
CN111625456B (zh) * | 2020-05-26 | 2024-04-30 | 北京达佳互联信息技术有限公司 | 一种卡顿定位方法和装置 |
CN111752719A (zh) * | 2020-06-28 | 2020-10-09 | 腾讯音乐娱乐科技(深圳)有限公司 | 检测卡顿的方法和装置 |
CN113268422B (zh) * | 2021-05-24 | 2024-05-03 | 康键信息技术(深圳)有限公司 | 基于分级量化的卡顿检测方法、装置、设备及存储介质 |
CN113835985B (zh) * | 2021-09-27 | 2023-09-29 | 北京基调网络股份有限公司 | 一种监测卡顿、分析卡顿原因的方法、装置及设备 |
Citations (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JPH10116211A (ja) * | 1996-10-11 | 1998-05-06 | Nec Corp | システムコンソール故障通知方式 |
CN102047222A (zh) * | 2008-06-02 | 2011-05-04 | 微软公司 | 用于线程安全数据集合的阻塞和绑定包装器 |
CN103399818A (zh) * | 2013-08-13 | 2013-11-20 | 中国科学技术大学苏州研究院 | 操作系统中的死锁检测方法 |
-
2018
- 2018-01-23 CN CN201810065370.1A patent/CN108197032B/zh active Active
Patent Citations (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JPH10116211A (ja) * | 1996-10-11 | 1998-05-06 | Nec Corp | システムコンソール故障通知方式 |
CN102047222A (zh) * | 2008-06-02 | 2011-05-04 | 微软公司 | 用于线程安全数据集合的阻塞和绑定包装器 |
CN103399818A (zh) * | 2013-08-13 | 2013-11-20 | 中国科学技术大学苏州研究院 | 操作系统中的死锁检测方法 |
Non-Patent Citations (1)
Title |
---|
iOS实时卡顿检测-RunLoop(附实例);路飞_Luck;《简书 https://www.jianshu.com/p/d0aab0eb8ce4》;20171129;第1-13页 * |
Also Published As
Publication number | Publication date |
---|---|
CN108197032A (zh) | 2018-06-22 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN108197032B (zh) | Ios应用的主线程卡顿监测方法、介质、设备及系统 | |
US8250543B2 (en) | Software tracing | |
US8370816B2 (en) | Device, method and computer program product for evaluating a debugger script | |
CN106844136B (zh) | 一种程序崩溃信息的收集方法及系统 | |
CN103699480B (zh) | 一种基于java的web动态安全漏洞检测方法 | |
US8051409B1 (en) | Monitoring memory accesses for multiple computer processes | |
US8418149B2 (en) | Differential comparison system and method | |
US9355003B2 (en) | Capturing trace information using annotated trace output | |
US20070143766A1 (en) | Deadlock detection in a computing environment | |
CN110363004B (zh) | 一种代码漏洞检测方法、装置、介质及设备 | |
US20080276129A1 (en) | Software tracing | |
CN113190427B (zh) | 卡顿监控方法、装置、电子设备及存储介质 | |
CN107045475B (zh) | 测试方法和装置 | |
CN113127314B (zh) | 一种检测程序性能瓶颈的方法、装置及计算机设备 | |
US6978399B2 (en) | Debug thread termination control points | |
US9104801B2 (en) | Analyzing concurrent debugging sessions | |
CN106775620B (zh) | 一种定时方法及装置 | |
CN110688245A (zh) | 信息获取方法、装置、存储介质及设备 | |
US7657792B2 (en) | Identifying race conditions involving asynchronous memory updates | |
CN107656849B (zh) | 一种软件系统性能问题定位方法以及装置 | |
CN112199642B (zh) | 一种安卓系统反调试的检测方法、移动终端及存储介质 | |
CN117421242A (zh) | 应用检测方法、装置、计算机设备和计算机可读存储介质 | |
CN108197005B (zh) | Ios应用的底层运行性能监测方法、介质、设备及系统 | |
KR101685299B1 (ko) | 비결정적인 이벤트 처리가 가능한 프로그램의 자동 테스트 방법 및 자동 테스트 장치 | |
CN113742113B (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 |