IOS应用的主线程卡顿监测方法、介质、设备及系统与流程

本发明涉及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状态；若均是，判断为发生卡顿；否则，判断为发生卡顿。

本发明不局限于上述实施方式，对于本技术领域的普通技术人员来说，在不脱离本发明原理的前提下，还可以做出若干改进和润饰，这些改进和润饰也视为本发明的保护范围之内。本说明书中未作详细描述的内容属于本领域专业技术人员公知的现有技术。