CN105589783A - 应用程序卡顿问题数据获取方法及装置 - Google Patents

Abstract

本发明公开了一种应用程序卡顿问题数据获取方法及装置，该方法包括：计算应用程序中需要监控的执行消息的处理时间；判断所述需要监控的执行消息的处理时间是否超过预设的阈值；如果超过预设的阈值，则分析处理所述执行消息的信息记录以得到所述应用程序卡顿问题数据。通过上述方式，本发明能够获取应用程序卡顿问题数据，从而为监控卡顿问题提供基础。

Description

应用程序卡顿问题数据获取方法及装置

技术领域

本发明涉及操作***应用技术领域，特别是涉及一种应用程序卡顿问题数据获取方法及装置。

背景技术

卡顿问题一般出现在手机、笔记本等电子设备中，出现状况为：在电子设备操作过程中，例如玩游戏的时候卡，或者听歌的时候画面滞帧，也就是通常人们所说的“卡”。

在浏览器功能日渐强大的过程中，浏览器卡顿问题越来越成为关注的重点，每一个新的功能加入，都可能引入一些问题，例如：效率低、线程等待、死锁等，这些问题容易导致浏览器出现卡顿。

如何去有效持续地监控和发现这些卡顿问题，是解决卡顿问题的关键。但是，现阶段还没有现成的方法去监控安卓(Android)应用程序的卡顿问题。

发明内容

本发明主要解决的技术问题是提供一种应用程序卡顿问题数据获取方法及装置，能够获取应用程序卡顿问题数据，从而为监控卡顿问题提供基础。

为解决上述技术问题，本发明采用的一个技术方案是：提供一种应用程序卡顿问题数据获取方法，包括：计算应用程序中需要监控的执行消息的处理时间；判断所述需要监控的执行消息的处理时间是否超过预设的阈值；如果超过预设的阈值，则分析处理所述执行消息的信息记录以得到所述应用程序卡顿问题数据。

其中，所述计算应用程序中需要监控的执行消息的处理时间包括：在开始处理所述需要监控的执行消息的时候，记录开始处理的时间；在完成所述需要监控的执行消息的处理后，记录完成处理的时间；通过所述开始处理的时间和所述完成处理的时间，计算应用程序中所述需要监控的执行消息的处理时间

其中，所述计算应用程序中需要监控的执行消息的处理时间之前，包括：增加新接口，通过所述新接口载入用于标记所述需要监控的执行消息的函数。

其中，所述执行消息的信息记录包括：处理执行消息的Handler名、处理该执行消息的线程名、执行消息的ID、***的内存信息、执行消息的处理时间。

其中，所述分析处理所述执行消息的信息记录以得到所述卡顿问题数据之后，还包括：通过数据分析脚本对所述卡顿问题数据进行分析，以获得所述卡顿问题分析结果。

为解决上述技术问题，本发明采用的另一个技术方案是：提供一种应用程序卡顿问题数据获取装置，所述装置包括：计算模块，用于计算应用程序中需要监控的执行消息的处理时间；判断模块，用于判断所述需要监控的执行消息的处理时间是否超过预设的阈值；第一分析模块，用于在超过预设的阈值时，分析处理所述执行消息的信息记录以得到所述应用程序卡顿问题数据。

其中，所述计算模块包括：第一记录单元，用于在开始处理所述需要监控的执行消息的时候，记录开始处理的时间；第二记录单元，用于在完成所述需要监控的执行消息的处理后，记录完成处理的时间；计算单元，用于通过所述开始处理的时间和所述完成处理的时间，计算应用程序中所述需要监控的执行消息的处理时间。

其中，所述装置还包括：接口增加模块，用于增加新接口，通过所述新接口载入用于标记所述需要监控的执行消息的函数。

其中，所述执行消息的信息记录包括：处理执行消息的Handler名、处理该执行消息的线程名、执行消息的ID、***的内存信息、执行消息的处理时间。

其中，所述装置还包括：第二分析模块，用于通过数据分析脚本对所述卡顿问题数据进行分析，以获得所述卡顿问题分析结果。

本发明的有益效果是：区别于现有技术的情况，本发明计算应用程序中需要监控的执行消息的处理时间；判断所述需要监控的执行消息的处理时间是否超过预设的阈值；如果超过预设的阈值，则分析处理所述执行消息的信息记录以得到所述应用程序卡顿问题数据。由于监控执行消息的处理时间，在处理时间超过预设的阈值，分析处理所述执行消息的信息记录以得到应用程序卡顿问题数据，通过这种方式，能够获取应用程序卡顿问题数据，从而为监控卡顿问题提供基础。

附图说明

图1是本发明应用程序卡顿问题数据获取方法一实施方式的流程图；

图2是本发明应用程序卡顿问题数据获取方法另一实施方式的流程图；

图3是本发明应用程序卡顿问题数据获取方法又一实施方式的流程图；

图4是本发明应用程序卡顿问题数据获取方法又一实施方式的流程图；

图5是本发明应用程序卡顿问题数据获取装置一实施方式的结构示意图；

图6是本发明应用程序卡顿问题数据获取装置另一实施方式的结构示意图；

图7是本发明应用程序卡顿问题数据获取装置又一实施方式的结构示意图；

图8是本发明应用程序卡顿问题数据获取装置又一实施方式的结构示意图。

具体实施方式

下面结合附图和实施方式对本发明进行详细说明。

参阅图1，图1是本发明应用程序卡顿问题数据获取方法一实施方式的流程图，包括：

步骤S101：计算应用程序中需要监控的执行消息的处理时间。

Android应用程序是消息驱动的，Android通过Looper、Handler来实现消息循环机制，Android消息循环是针对线程的(即，每个线程都可以有自己的消息队列和消息循环)。

Android的消息循环主要由4个要素构成：Message、MessageQueue、Looper以及Handler，其中：

Message：表示一个具体的消息；

MessageQueue：表示消息队列，具体的消息产生后加入到消息队列中；

Looper：用于循环取出消息，以便于进行处理；

Handler：用于对消息进行处理。

因此，每个消息经过一个消息循环，即可知道每个消息的处理时间，在应用程序正常的情况下，每个消息的处理时间在正常的范围内，当某个消息处理的时间太长，则可能出现了卡顿问题。

步骤S102：判断需要监控的执行消息的处理时间是否超过预设的阈值。

按照消息处理正常的时间范围，预先设定一个阈值，判断需要监控的执行消息的处理时间是否超过预设的阈值。

步骤S103：如果超过预设的阈值，则分析处理执行消息的信息记录以得到应用程序卡顿问题数据。

如果需要监控的执行消息的处理时间超过预设的阈值，则有可能出现卡顿问题，因此分析处理执行消息的信息记录以得到应用程序卡顿问题数据。执行消息的信息记录包括但不限于：处理该执行消息的Handler名、该执行消息的ID、处理该执行消息的线程名、***的内存信息、执行消息的处理时间等。这些信息记录经过分析处理后组合成一条完整的卡顿问题数据。

本发明实施方式计算应用程序中需要监控的执行消息的处理时间；判断需要监控的执行消息的处理时间是否超过预设的阈值；如果超过预设的阈值，则分析处理所述执行消息的信息记录以得到所述应用程序卡顿问题数据。由于监控执行消息的处理时间，在处理时间超过预设的阈值，分析处理所述执行消息的信息记录以得到应用程序卡顿问题数据，通过这种方式，能够获取应用程序卡顿问题数据，从而为监控卡顿问题提供基础。

参阅图2至图4，图2至图4是本发明应用程序卡顿问题数据获取方法三个实施方式的流程图，本发明的三个实施方式与图1的实施方式基本相同，相同之处请参见图1以及相应的文字说明，该方法包括：

步骤S201：增加新接口，通过新接口载入用于标记需要监控的执行消息的函数。

给Looper设置一个Printer对象，接口Printer只声明一个方法println(Stringx)，该方法原意是打印消息循环的一些信息，这些信息在调用println()函数的时候，通过参数x传递进去。当Printer不为空，在每条消息处理的前后，Looper都会调用println()函数，通过参数x传入Handler名、消息ID等信息，通过重载println()函数，在该方法中获得相关信息，并且计算消息的处理时间。增加一个子类实现接口Printer，并重载println()函数，在该函数中即可记录时间。

设置了Printer的对象，即为需要监控的执行消息。

步骤S202：在开始处理需要监控的执行消息的时候，记录开始处理的时间。

如果执行消息设置有标记函数Printer，则在开始处理该执行消息时，记录开始处理的时间。

步骤S203：在完成需要监控的执行消息的处理后，记录完成处理的时间。

步骤S204：通过开始处理的时间和完成处理的时间，计算安卓应用中需要监控的执行消息的处理时间。

步骤S205：判断需要监控的执行消息的处理时间是否超过预设的阈值。

步骤S206：如果超过预设的阈值，则分析处理执行消息的信息记录以得到所述应用程序卡顿问题数据。

步骤S207：将得到的应用程序卡顿问题数据存储于数据库，其中，数据库用于存储应用程序卡顿问题数据。数据库可以位于远程服务器上。将卡顿问题数据存储于数据库，可以用于后续分析。

上述步骤在实际应用可以具体是：

(1)对于需要监控的线程，在线程初始化完成后，指定Printer对象，并设置到Looper，开始进行监控。如果想要取消监控，只需要将Looper中的Printer设置为null即可；

(2)当一个执行消息被Looper从消息队列中取出后，首先判断是否有设置Printer，如果有，则进入(3)，否则进入(4)；

(3)执行println()，记录该执行消息开始处理的时间。

(4)将执行消息交由handler进行消息处理。完成消息处理后，判断是否有设置Printer，如果有，进入(5)，否则完成该次消息循环；

(5)判断该执行消息相应的处理时间是否超过预设阈值，如果超过预设阈值，则进入(6)，否则本次消息循环完成，进行下一消息的相应处理；

(6)将处理本次执行消息的信息记录上传到服务器中的数据库。处理本次执行消息的信息记录包括：处理执行消息的Handler名、处理该执行消息的线程名、执行消息的ID、***的内存信息(包括总容量，以及使用信息等)、执行消息的处理时间。

步骤S208：通过数据分析脚本对卡顿问题数据进行分析，以获得卡顿问题分析结果。

数据分析脚本可以由Perl语言实现，一方面可以由研发人员分析数据时手动运行，另一方面可以部署在服务器，每天在固定的时间对数据库里的卡顿问题数据自动进行分析，获得分析结果。

参见图3，在步骤S208之后，还可以包括：

步骤S209：在网页页面，接收用户的卡顿问题分析结果查询请求。

步骤S210：将卡顿问题分析结果显示在网页页面，以便于用户查看。

通过网页页面，提供卡顿问题分析结果查询的功能，能够提高操作便捷性。

参见图4，在步骤S208之后，或者还可以包括：

步骤S211：在预定时间通过邮件向用户发送卡顿问题分析结果。

后台数据库自动运行数据分析脚本，获得卡顿问题分析结果，并在每天预定时间段通过邮件的形式，将卡顿问题分析结果发送给监控人员，邮件监控***可以对卡顿问题分析结果进行排名，并可以监控排名的变化，从而可以及时监控新的卡顿问题的产生。

本发明实施方式计算应用程序中需要监控的执行消息的处理时间；判断需要监控的执行消息的处理时间是否超过预设的阈值；如果超过预设的阈值，则分析处理所述执行消息的信息记录以得到所述应用程序卡顿问题数据。由于监控执行消息的处理时间，在处理时间超过预设的阈值，分析处理所述执行消息的信息记录以得到应用程序卡顿问题数据，通过这种方式，能够获取应用程序卡顿问题数据，从而为监控卡顿问题提供基础。

另外，本发明方法可移植性强、代码改动小、且能够实现监控自动化。

在实际应用中，利用本发明方法，已发现大量的卡顿问题，有效地推动解决卡顿问题的进度。自动监控到的卡顿问题，例如：

小说模块加载小说目录的卡顿，相关消息：

com.UCMobile.novel.service.NovelCatalogService.onReaderCatalogReceived

调用PP助手下载引入的卡顿，相关消息：

com.uc.ppassistant.PPImagesDownloadController$1

浏览器置入后台写io操作引起的卡顿，相关消息：

com.uc.browser.BrowserController--2224。

上述实际应用，进一步验证了本发明方法的能够提供卡顿问题数据从而为应用程序中的卡顿问题进行监控提供基础，体现本发明方法的应用价值。

参阅图5，图5是本发明应用程序卡顿问题数据获取装置一实施方式的结构示意图，本实施方式的装置可以执行上述图1至图4中的步骤。该装置包括：计算模块11、判断模块12以及第一分析模块13。

计算模块11用于计算应用程序中需要监控的执行消息的处理时间。

Android应用程序是消息驱动的，Android通过Looper、Handler来实现消息循环机制，Android消息循环是针对线程的(即，每个线程都可以有自己的消息队列和消息循环)。

Android的消息循环主要由4个要素构成：Message、MessageQueue、Looper以及Handler，其中：

Message：表示一个具体的消息；

MessageQueue：表示消息队列，具体的消息产生后加入到消息队列中；

Looper：用于循环取出消息，以便于进行处理；

Handler：用于对消息进行处理。

因此，每个消息经过一个消息循环，即可知道每个消息的处理时间，在应用程序正常的情况下，每个消息的处理时间在正常的范围内，当某个消息处理的时间太长，则可能出现了卡顿问题。

判断模块12用于判断需要监控的执行消息的处理时间是否超过预设的阈值。

按照消息处理正常的时间范围，预先设定一个阈值，判断需要监控的执行消息的处理时间是否超过预设的阈值。

第一分析模块13用于在超过预设的阈值时，分析处理所述执行消息的信息记录以得到所述应用程序卡顿问题数据。

如果需要监控的执行消息的处理时间超过预设的阈值，则有可能出现卡顿问题，因此分析处理执行消息的信息记录以得到应用程序卡顿问题数据。执行消息的信息记录包括但不限于：处理执行消息的Handler名、处理该执行消息的线程名、执行消息的ID、***的内存信息(包括总容量，以及使用信息等)、执行消息的处理时间等。这些信息记录经过分析处理后组合成一条完整的卡顿问题数据。

本发明实施方式计算应用程序中需要监控的执行消息的处理时间；判断需要监控的执行消息的处理时间是否超过预设的阈值；如果超过预设的阈值，则分析处理所述执行消息的信息记录以得到所述应用程序卡顿问题数据。由于监控执行消息的处理时间，在处理时间超过预设的阈值，分析处理所述执行消息的信息记录以得到应用程序卡顿问题数据，通过这种方式，能够获取应用程序卡顿问题数据，从而为监控卡顿问题提供基础。

参阅图6至图8，图6至图8是本发明应用程序卡顿问题数据获取装置三个实施方式的结构示意图，本发明的三个实施方式与图5的实施方式基本相同，相同之处请参见图5以及相应的文字说明，该装置包括：计算模块11、判断模块12、第一分析模块13。

计算模块11用于计算应用程序中需要监控的执行消息的处理时间。

判断模块12用于判断需要监控的执行消息的处理时间是否超过预设的阈值。

第一分析模块13用于在超过预设的阈值时，分析处理所述执行消息的信息记录以得到所述应用程序卡顿问题数据。

该装置还包括：存储模块14。

存储模块14用于将得到的应用程序卡顿问题数据存储于数据库，其中，数据库用于存储应用程序卡顿问题数据。数据库可以位于远程服务器上。将卡顿问题数据存储于数据库，可以用于后续分析。

该装置还包括：第二分析模块15。

第二分析模块15用于通过数据分析脚本对卡顿问题数据进行分析，以获得卡顿问题分析结果。

数据分析脚本可以由Perl语言实现，一方面可以由研发人员分析数据时手动运行，另一方面可以部署在服务器，每天在固定的时间对数据库里的卡顿问题数据自动进行分析，获得分析结果。

其中，计算模块11包括：第一记录单元111、第二记录单元112以及计算单元113。

第一记录单元111用于在开始处理需要监控的执行消息的时候，记录开始处理的时间。

第二记录单元112用于在完成需要监控的执行消息的处理后，记录完成处理的时间。

计算单元113用于通过开始处理的时间和完成处理的时间，计算安卓应用中需要监控的执行消息的处理时间。

装置还包括：接口增加模块16。

接口增加模块16用于增加新接口，通过新接口载入用于标记需要监控的执行消息的函数。

给Looper设置一个Printer对象，接口Printer只声明一个方法println(Stringx)，该方法原意是打印消息循环的一些信息，这些信息在调用println()函数的时候，通过参数x传递进去。当Printer不为空，在每条消息处理的前后，Looper都会调用println()函数，通过参数x传入Handler名、消息ID等信息，通过重载println()函数，在该方法中获得相关信息，并且计算消息的处理时间。增加一个子类实现接口Printer，并重载println()函数，在该函数中即可记录时间。

设置了Printer的对象，即为需要监控的执行消息。

参阅图7，该装置包括：接收模块17和显示模块18。

接收模块17用于在网页页面，接收用户的卡顿问题分析结果查询请求。

显示模块18用于将卡顿问题分析结果显示在网页页面，以便于用户查看。

通过网页页面，提供卡顿问题分析结果查询的功能，能够提高操作便捷性。

参阅图8，该装置还包括：发送模块19。

发送模块19用于在预定时间通过邮件向用户发送卡顿问题分析结果。

后台服务器自动运行数据分析脚本，获得卡顿问题分析结果，并在每天预定时间段通过邮件的形式，将卡顿问题分析结果发送给监控人员，邮件监控***可以对卡顿问题分析结果进行排名，并可以监控排名的变化，从而可以及时监控新的卡顿问题的产生。

本发明实施方式计算安卓应用中需要监控的执行消息的处理时间；判断需要监控的执行消息的处理时间是否超过预设的阈值；如果超过预设的阈值，则将处理执行消息的信息记录上传至服务器的数据库，其中，服务器的数据库用于存储上传的由信息记录组成的卡顿数据；通过数据分析脚本对上传的信息记录进行分析，获得卡顿问题分析结果。由于监控执行消息的处理时间，在处理时间超过预设的阈值，上传信息记录给服务器数据库以便于分析，通过这种方式，能够对安卓应用中的卡顿问题进行监控。

以上所述仅为本发明的实施方式，并非因此限制本发明的专利范围，凡是利用本发明说明书及附图内容所作的等效结构或等效流程变换，或直接或间接运用在其他相关的技术领域，均同理包括在本发明的专利保护范围内。

Claims (10)

1.一种应用程序卡顿问题数据获取方法，其特征在于，包括：

计算应用程序中需要监控的执行消息的处理时间；

判断所述需要监控的执行消息的处理时间是否超过预设的阈值；

如果超过预设的阈值，则分析处理所述执行消息的信息记录以得到所述应用程序卡顿问题数据。

2.根据权利要求1所述的方法，其特征在于，所述计算应用程序中需要监控的执行消息的处理时间包括：

在开始处理所述需要监控的执行消息的时候，记录开始处理的时间；

在完成所述需要监控的执行消息的处理后，记录完成处理的时间；

通过所述开始处理的时间和所述完成处理的时间，计算应用程序中所述需要监控的执行消息的处理时间。

3.根据权利要求1所述的方法，其特征在于，所述计算应用程序中需要监控的执行消息的处理时间之前，包括：增加新接口，通过所述新接口载入用于标记所述需要监控的执行消息的函数。

4.根据权利要求1所述的方法，其特征在于，所述执行消息的信息记录包括：处理所述执行消息的Handler名、处理所述执行消息的线程名、所述执行消息的ID、***的内存信息、所述执行消息的处理时间。

5.根据权利要求1所述的方法，其特征在于，所述分析处理所述执行消息的信息记录以得到所述卡顿问题数据之后，还包括：通过数据分析脚本对所述卡顿问题数据进行分析，以获得所述卡顿问题分析结果。

6.一种应用程序卡顿问题数据获取装置，其特征在于，所述装置包括：

计算模块，用于计算应用程序中需要监控的执行消息的处理时间；

判断模块，用于判断所述需要监控的执行消息的处理时间是否超过预设的阈值；

第一分析模块，用于在超过预设的阈值时，分析处理所述执行消息的信息记录以得到所述应用程序卡顿问题数据。

7.根据权利要求6所述的装置，其特征在于，所述计算模块包括：

第一记录单元，用于在开始处理所述需要监控的执行消息的时候，记录开始处理的时间；

第二记录单元，用于在完成所述需要监控的执行消息的处理后，记录完成处理的时间；

计算单元，用于通过所述开始处理的时间和所述完成处理的时间，计算应用程序中所述需要监控的执行消息的处理时间。

8.根据权利要求6所述的装置，其特征在于，所述装置还包括：

接口增加模块，用于增加新接口，通过所述新接口载入用于标记所述需要监控的执行消息的函数。

9.根据权利要求6所述的装置，其特征在于，所述执行消息的信息记录包括：处理执行消息的Handler名、处理该执行消息的线程名、执行消息的ID、***的内存信息、执行消息的处理时间。

10.根据权利要求6所述的装置，其特征在于，所述装置还包括：

第二分析模块，用于通过数据分析脚本对所述卡顿问题数据进行分析，以获得所述卡顿问题分析结果。