CN108563526A - 一种iOS卡顿监控策略 - Google Patents

Abstract

本发明涉及一种iOS卡顿监控策略，包括如下步骤：调用监听管理器，对以下事件进行监听：监听ui界面，监听App崩溃信息，监听管理器将获取的监听数据存储于运行App的设备的本地，调用上报策略，开启后台线程用于上报监听数据，读取存储于本地的监听数据，将其写入上报数据缓冲区，将缓冲区内数据归类，将归类数据打包，然后发起上报请求，服务端接收上报的数据。本发明，监控内容丰富，流程清晰，数据获取全面，有利于辅助程序员准确判断卡顿的发生时间、卡顿原因，为提高App性能，确保数据安全提供更好的保障。

Description

一种iOS卡顿监控策略

技术领域

本发明涉及iOS系统监控技术领域，具体说是一种iOS卡顿监控策略。

背景技术

现有的移动设备（手机，平板电脑，等等），有越来越多的App被开发、发布出来，而开发者并非都是专业、经验丰富的软件设计人员，在如此复杂的环境中，开发软件最关注的话题之一就是性能。程序员除了需要努力提高代码质量之外，如何及时发现和监控软件中那些造成性能低下的“罪魁祸首”也是急需解决的问题。毕竟工欲善其事必先利其器，如果不能及时、有效的进行实时卡顿监控，则不利于程序员及时发现、排除程序BUG，尤其是一些隐藏的问题将很难发现。

在开发测试阶段，分析软件运行的性能消耗，有许多辅助调试工具，例如在Xcode中已经集成了非常方便的调试工具Instruments。但一款软件经过测试流程和实验室分析肯定是不够的，在正式环境中，由大量用户在使用过程中监控、分析到的数据，更能说明实际情况，有助于解决一些隐藏的问题，提高用户的使用体验，确保软件的可靠运行，确保用户数据的安全。

众所周知，iOS平台因为UIKit（iOS界面组件UIkit 是 YOOtheme 团队开发的一款轻量级、模块化的前端框架，可快速构建强大的web前端界面。UIKit提供了全面的HTML、CSS及JS组件，它们使用简单，容易定制和扩展。所有UIKit控件均继承自 UIView。UIKit框架是iPhone应用程序开发中最基本的框架，也是用得最多、最重要的框架，从名字我们就能理解是界面相关操作组件集合。）本身的特性，需要将所有的UI操作都放在主线程执行，所以也造成不少程序员都习惯将一些线程安全性不确定的逻辑，以及其它线程结束后的汇总工作等等放到了主线，所以主线程中包含的这些大量计算、IO、绘制都有可能造成卡顿。监控卡顿，最直接就是找到主线程都在干些什么。

发明内容

针对现有技术中存在的缺陷，本发明的目的在于提供一种iOS卡顿监控策略，监控内容丰富，流程清晰，数据获取全面，有利于辅助程序员准确判断卡顿的发生时间、卡顿原因，为提高App性能，确保数据安全提供更好的保障。

为达到以上目的，本发明采取的技术方案是：

一种iOS卡顿监控策略，其特征在于，包括如下步骤：

调用监听管理器，对以下事件进行监听：

监听ui界面，

监听App崩溃信息，

监听管理器将获取的监听数据存储于运行App的设备的本地，

调用上报策略，

开启后台线程用于上报监听数据，

读取存储于本地的监听数据，将其写入上报数据缓冲区，

将缓冲区内数据归类，

将归类数据打包，然后发起上报请求，

服务端接收上报的数据。

在上述技术方案的基础上，上报请求如果无响应，则循环上报3次，依然无响应，则返回上报数据错误信息。

在上述技术方案的基础上，服务端成功接收上报的数据后，根据缓冲区中的资源信息，清理存储于本地的监听数据。

在上述技术方案的基础上，所述监听ui界面，具体步骤如下：

监听UIView和CALayer的setNeedsLayout、setNeedsDisplay、setNeedsDisplayInRect方法，

setNeedsLayout方法用于标记视图为需要重新布局，

setNeedsDisplay方法用于刷新、重绘视图内容contents，

setNeedsDisplayInRect方法用于标记视图需要进行重画，

判断被监听的方法是否在主线程，

如果在主线程，则继续监听，

如果不在主线程，则进行如下处理：

获取调用堆栈信息，

将主要信息存储到本地资源文件，所述主要信息至少包括：调用时机，堆栈信息，

继续监听。

在上述技术方案的基础上，所述监听App崩溃信息，具体步骤如下：

注册异常监听信号，

持续捕获App异常，

产生异常时，获取异常堆栈信息

将主要信息存储到本地资源文件，所述主要信息至少包括：调用时机，堆栈信息，

继续监听。

在上述技术方案的基础上，监听管理器还对网络请求进行统计，对数据缓存进行记录，形成本地资源监控文件，作为监听数据的一部分。

在上述技术方案的基础上，对网络请求进行统计时，检测每一个网络请求的结果，判断网络请求是否成功，

如果成功，则无进一步处理，继续监听，

如果失败，则将网络请求url，错误码，请求时机，返回数据存储到本地资源监控文件，继续监听。

在上述技术方案的基础上，对数据缓存进行记录时，根据预设的数据缓存存取阈值，与每次数据存取的时间进行比对，判断存取时间是否超过存取阈值，

如果未超过，则无进一步处理，继续监听，

如果超过，则将存取时机，存取时间，存取sql语句存储到本地资源监控文件，继续监听。

本发明所述的iOS卡顿监控策略，监控内容丰富，流程清晰，数据获取全面，有利于辅助程序员准确判断卡顿的发生时间、卡顿原因，为提高App性能，确保数据安全提供更好的保障。

附图说明

本发明有如下附图：

图1本发明的流程图。

具体实施方式

以下结合附图对本发明作进一步详细说明。

如图1所示，本发明所述的iOS卡顿监控策略，包括如下步骤：

调用监听管理器，对以下事件进行监听：

监听ui界面，

监听App崩溃信息，

监听管理器将获取的监听数据存储于运行App的设备的本地，

调用上报策略，

开启后台线程用于上报监听数据，

读取存储于本地的监听数据，将其写入上报数据缓冲区，

将缓冲区内数据归类，

将归类数据打包，然后发起上报请求，

服务端接收上报的数据。

在上述技术方案的基础上，上报请求如果无响应，则循环上报3次，依然无响应，则返回上报数据错误信息。

在上述技术方案的基础上，服务端成功接收上报的数据后，根据缓冲区中的资源信息，清理存储于本地的监听数据。

在上述技术方案的基础上，所述监听ui界面，具体步骤如下：

监听UIView和CALayer的setNeedsLayout、setNeedsDisplay、setNeedsDisplayInRect方法，

setNeedsLayout方法用于标记视图为需要重新布局，

setNeedsDisplay方法用于刷新、重绘视图内容contents，

setNeedsDisplayInRect方法用于标记视图需要进行重画，

判断被监听的方法是否在主线程，

如果在主线程，则继续监听，

如果不在主线程，则进行如下处理：

获取调用堆栈信息，

将主要信息存储到本地资源文件，所述主要信息至少包括：调用时机，堆栈信息，

继续监听。

在上述技术方案的基础上，所述监听App崩溃信息，具体步骤如下：

注册异常监听信号，

持续捕获App异常，

产生异常时，获取异常堆栈信息

将主要信息存储到本地资源文件，所述主要信息至少包括：调用时机，堆栈信息，

继续监听。

在上述技术方案的基础上，监听管理器还对网络请求进行统计，对数据缓存进行记录，形成本地资源监控文件，作为监听数据的一部分。

在上述技术方案的基础上，对网络请求进行统计时，检测每一个网络请求的结果，判断网络请求是否成功，

如果成功，则无进一步处理，继续监听，

如果失败，则将网络请求url，错误码，请求时机，返回数据存储到本地资源监控文件，继续监听。

在上述技术方案的基础上，对数据缓存进行记录时，根据预设的数据缓存存取阈值，与每次数据存取的时间进行比对，判断存取时间是否超过存取阈值，

如果未超过，则无进一步处理，继续监听，

如果超过，则将存取时机，存取时间，存取sql语句存储到本地资源监控文件，继续监听。

本说明书中未作详细描述的内容属于本领域专业技术人员公知的现有技术。

Claims (8)

1.一种iOS卡顿监控策略，其特征在于，包括如下步骤：

调用监听管理器，对以下事件进行监听：

监听ui界面，

监听App崩溃信息，

监听管理器将获取的监听数据存储于运行App的设备的本地，

调用上报策略，

开启后台线程用于上报监听数据，

读取存储于本地的监听数据，将其写入上报数据缓冲区，

将缓冲区内数据归类，

将归类数据打包，然后发起上报请求，

服务端接收上报的数据。

2.如权利要求1所述的iOS卡顿监控策略，其特征在于：上报请求如果无响应，则循环上报3次，依然无响应，则返回上报数据错误信息。

3.如权利要求1所述的iOS卡顿监控策略，其特征在于：服务端成功接收上报的数据后，根据缓冲区中的资源信息，清理存储于本地的监听数据。

4.如权利要求1所述的iOS卡顿监控策略，其特征在于：所述监听ui界面，具体步骤如下：

监听UIView和CALayer的setNeedsLayout、setNeedsDisplay、setNeedsDisplayInRect方法，

setNeedsLayout方法用于标记视图为需要重新布局，

setNeedsDisplay方法用于刷新、重绘视图内容contents，

setNeedsDisplayInRect方法用于标记视图需要进行重画，

判断被监听的方法是否在主线程，

如果在主线程，则继续监听，

如果不在主线程，则进行如下处理：

获取调用堆栈信息，

将主要信息存储到本地资源文件，所述主要信息至少包括：调用时机，堆栈信息，

继续监听。

5.如权利要求1所述的iOS卡顿监控策略，其特征在于：所述监听App崩溃信息，具体步骤如下：

注册异常监听信号，

持续捕获App异常，

产生异常时，获取异常堆栈信息

将主要信息存储到本地资源文件，所述主要信息至少包括：调用时机，堆栈信息，

继续监听。

6.如权利要求1所述的iOS卡顿监控策略，其特征在于：监听管理器还对网络请求进行统计，对数据缓存进行记录，形成本地资源监控文件，作为监听数据的一部分。

7.如权利要求6所述的iOS卡顿监控策略，其特征在于：对网络请求进行统计时，检测每一个网络请求的结果，判断网络请求是否成功，

如果成功，则无进一步处理，继续监听，

如果失败，则将网络请求url，错误码，请求时机，返回数据存储到本地资源监控文件，继续监听。

8.如权利要求6所述的iOS卡顿监控策略，其特征在于：对数据缓存进行记录时，根据预设的数据缓存存取阈值，与每次数据存取的时间进行比对，判断存取时间是否超过存取阈值，

如果未超过，则无进一步处理，继续监听，

如果超过，则将存取时机，存取时间，存取sql语句存储到本地资源监控文件，继续监听。