CN109189664B - 应用程序的信息采集方法及终端 - Google Patents

Abstract

本发明实施方式涉及计算机领域，公开了一种应用程序的信息采集方法及终端。本发明实施方式中，应用程序的信息采集方法包括：任务开始执行时，执行一计时事件；其中，计时事件的时长大于或等于任务的预设耗时时长；若计时事件优先任务完成，则对应用程序进行数据采集，以获取第一采集数据；在任务完成时，获取任务的开始时刻以及结束时刻，并根据开始时刻和结束时刻，获取任务的实际执行时长；若实际执行时长大于或等于预设卡顿阈值，则将第一采集数据上传至预设服务器。采用本发明实施方式，不仅能够尽可能多地采集应用程序发生卡顿期间的相关数据，而且不需要实时地进行数据采集，以避免过多资源的占用与浪费。

Description

应用程序的信息采集方法及终端

技术领域

本发明实施方式涉及计算机技术领域，特别涉及应用程序的信息采集方法及终端。

背景技术

随着网络技术的不断发展，安装在智能手机、平板电脑以及一些新兴智能设备等终端中的应用程序在功能、设计和服务范围上日新月异，用户每天花费在这些智能设备上的时间越来越多，应用程序的用户体验需求也越来越高。目前，应用程序用户体验的一个关键指标是应用流畅度。如果一个应用程序有各种卡顿问题，如，用户滑动页面时卡顿，用户操作响应缓慢，界面中的动画不流畅等等，那这个应用程序的用户体验就会很差。

本专利申请的发明人发现：应用程序出现卡顿跟各种各样的因素有关，比如终端的硬件状态、网络状态、用户操作行为、程序的代码逻辑问题等等。而应用程序出现卡顿通常都是不可控的，且应用程序出现卡顿并不是一个必现的缺陷，即使开发人员模拟用户当时的操作，也很难再将卡顿复现出来。因此，现有技术中的应用程序通常会在启动后就实时地收集相关数据，以便于获取卡顿发生期间的相关数据并进行上报，令开发人员能够基于应用程序上报的卡顿相关数据进行数据分析，获取应用程序的卡顿原因。由此可见，现有技术的卡顿信息获取方法需要实时地收集相关数据，收集到的信息量较为庞大。并且，现有技术的卡顿信息获取方法是以牺牲硬件资源来换取有效信息的，占用资源较多，资源利用率却较低。

发明内容

本发明实施方式的目的在于提供一种应用程序的信息采集方法及终端，不仅能够尽可能多地采集应用程序发生卡顿期间的相关数据，而且不需要实时地进行数据采集，以避免过多资源的占用与浪费。

为解决上述技术问题，本发明的实施方式提供了一种应用程序的信息采集方法，包括：

任务开始执行时，执行一计时事件；其中，计时事件的时长大于或等于任务的预设耗时时长；

若计时事件优先任务完成，则对应用程序进行数据采集，以获取第一采集数据；

在任务完成时，获取任务的开始时刻以及结束时刻，并根据开始时刻和结束时刻，获取任务的实际执行时长；

若实际执行时长大于或等于预设卡顿阈值，则将第一采集数据上传至预设服务器。

本发明的实施方式还提供了一种终端，包括：

至少一个处理器；以及，

与至少一个处理器通信连接的存储器；其中，

存储器存储有可被至少一个处理器执行的指令，指令被至少一个处理器执行，以使至少一个处理器能够执行上述的应用程序的信息采集方法。

本发明的实施方式还提供了一种计算机可读存储介质，存储有计算机程序，该计算机程序被处理器执行时实现上述的应用程序的信息采集方法。

本发明实施方式相对于现有技术而言，任务在开始执行时，设置一个计时事件来监测任务执行是否过于耗时，如果计时事件优先任务完成，则说明任务执行耗时，此时认为应用程序有发生卡顿的可能，需要对应用程序进行数据采集，获取第一采集数据。当任务完成时，根据任务的完成时刻以及开始时刻，计算任务的实际执行时长，如果任务的实际执行时长大于预设卡顿阈值，则说明应用程序发生了卡顿，此时将采集到的第一采集数据进行上报，以供开发人员进行数据分析，获取卡顿原因。这样，应用程序在初步判断任务执行过于耗时的情况下才进行数据采集，不仅能够尽可能多地采集应用程序发生卡顿期间的相关数据，而且不需要实时地进行数据采集，以避免过多资源的占用与浪费。

另外，对应用程序进行数据采集，获取第一采集数据，具体包括：获取N个采集时刻点；根据N个采集时刻点对应用程序进行N次数据采集，并将N次数据采集的结果作为第一采集数据；其中，N为大于1的正整数。这样，对应用程序进行若干次数据采集，不仅能够获取供开发人员进行卡顿分析的数据，而且能够进一步地降低数据采集量，以便于进一步地减少因数据采集所占用的资源，从而进一步地提升资源的有效利用率。

另外，获取N个采集时刻点，具体包括：根据散列算法以及应用程序的界面渲染周期，计算获取N个采集时刻点。这样，提供了获取N个采集时刻点的一种具体实现形式，增加了本发明实施方式的灵活性。

另外，应用程序的信息采集方法还包括：在计时事件执行期间，对应用程序进行M次数据采集，并将M次数据采集的结果作为第二采集数据；其中，M为大于0的正整数；若实际执行时长大于或等于预设卡顿阈值，还将第二采集数据上传至预设服务器。这样，在计时事件执行期间进行数据采集，为开发人员能够获取较为全面的数据采集结果，分析出更准确的卡顿原因提供了基础。

另外，任务的预设耗时时长等于应用程序的界面渲染周期。这样，计时事件优先任务完成，则表示应用程序丢帧，由于丢帧是卡顿现象的直接体现，因此基于应用程序的界面渲染周期来设置任务的预设耗时时长，为获取较为准确地卡顿分析结果提供了数据基础。

另外，若任务优先计时事件完成，则取消计时事件，从而能够及时地释放资源，进一步地提升了资源的有效利用率。

另外，若实际执行时长小于预设卡顿阈值，则清除第一采集数据，从而能够及时地清除无效数据，提高内存空间的利用率。

附图说明

一个或多个实施方式通过与之对应的附图中的图片进行示例性说明，这些示例性说明并不构成对实施方式的限定，附图中具有相同参考数字标号的元件表示为类似的元件，除非有特别申明，附图中的图不构成比例限制。

图1是本发明第一实施方式中应用程序的信息采集方法的流程示意图；

图2是本发明第一实施方式中应用程序的主线程待执行队列的示意图；

图3是本发明第二实施方式中应用程序的信息采集方法的流程示意图；

图4是本发明第三实施方式中终端的结构示意图。

具体实施方式

为使本发明实施方式的目的、技术方案和优点更加清楚，下面将结合附图对本发明的各实施方式进行详细的阐述。然而，本领域的普通技术人员可以理解，在本发明各实施方式中，为了使读者更好地理解本申请而提出了许多技术细节。但是，即使没有这些技术细节和基于以下各实施方式的种种变化和修改，也可以实现本申请所要求保护的技术方案。

本发明的第一实施方式涉及一种应用程序的信息采集方法，具体流程如图1所示。本实施方式中应用程序的信息采集方法可以在智能手机、平板电脑以及一些新兴智能设备等终端上进行实施，步骤如下：

步骤101，任务开始执行时，执行一计时事件。

具体地说，任务可以是用户的一次操作，也可以是应用程序某个界面的打开，任务的预设耗时时长可以由技术人员预先设置并保存在应用程序中。

更具体地说，应用程序发生卡顿的直接原因是由于应用程序的主线程被阻塞了，而造成应用程序的主线程被阻塞的主要原因为当前任务过于耗时，耗时任务一直占用着应用程序的主线程，导致用户与应用程序的交互工作一直没机会响应。基于此，开发人员设置计时事件的计时时长大于或等于任务的预设耗时时长，能够较为准确地衡量任务执行是否过于耗时。

本专利申请的发明人发现，安卓系统底层是会按照一定频率周期定时渲染界面，应用程序先主动通知底层来监听它的渲染事件，这样应用程序会接收到该渲染事件的回调。理想状态下，应用程序能够流畅使用的基础是应用程序能够准时地进行界面渲染(即，应用程序根据界面渲染周期，定期进行界面渲染，应用程序不丢帧)。基于此，开发人员可以设置预设耗时时长等于应用程序的界面渲染周期，能够提高后续数据采集时机的准确度，保证终端资源的高利用率。以下进行具体说明：

具体地说，终端的渲染机制会令应用程序按照一定的频率来刷新界面，如，安卓系统终端的刷新频率是60fps，也就是说，1秒钟更新60次界面，那么应用程序的界面渲染周期就是1/60s，即约等于16.67ms。由此可以看出，应用程序会每隔16.67ms更新界面，更新界面也是一个任务，也是需要在应用程序的主线程中进行处理的。假设更新界面这个任务记为R1，则R1这个任务会进入主线程的待执行队列中排序等待，如图2所示。如果在R1前面的任务R2被处理完的总耗时不超过16.67ms，那么应用程序就不会发生丢帧现象，如果在R1任务之前的任务R2过于耗时了，那么应用程序就会发生丢帧现象，由于丢帧是卡顿的直接体现，应用程序丢帧过多时，用户就能感知到应用程序发生卡顿，因此，基于应用程序的界面渲染周期来设置任务的预设耗时时长，相当于基于应用程序的丢帧来判断应用程序是否有发生卡顿的可能，为后续获取较为准确地数据采集时机提供了数据基础。

更具体地说，以安卓系统为例，开发人员可以设置计时事件的时长略大于任务的预设耗时时长，如，计时事件的时长可以设定为20ms。

步骤102，判断计时事件是否优先任务完成。若是，则执行步骤103，否则执行步骤107。

具体地说，若步骤102的判断结果为是，则说明任务过于耗时，应用程序已经发生丢帧现象，应用程序卡顿的可能性较大，此时需要执行步骤103，对应用程序进行数据采集，以获取第一采集数据，实现卡顿期间相关数据的采集。若步骤102的判断结果为否，则说明任务正常完成，应用程序未发生丢帧现象，不存在卡顿的可能性，此时执行步骤107，取消计时事件，以便于及时地释放资源，提升资源的有效利用率。

更具体地说，在对应用程序进行数据采集，获取第一采集数据时，应用程序可以在任务完成前，对应用程序进行实时地数据采集，以便于获取较为全面的数据。而在本实施方式中，在对应用程序进行数据采集，获取第一采集数据时，终端的应用程序是根据N个采集时刻点进行N次数据采集，并将N次数据采集的结果作为第一采集数据的。其中，N为大于1的正整数。这样，应用程序仅进行若干次数据采集，不仅能够获取供开发人员进行卡顿分析的数据，令开发人员基于采集到的多份数据进行分析对比，来查看是否是由于某个任务太过耗时所导致的卡顿，而且能够进一步地降低数据采集量，并进一步地减少因数据采集所占用的资源，提升资源的有效利用率。其中，第一采集数据放置在暂存区进行暂存。N个采集时刻点可以根据散列算法以及应用程序的界面渲染周期来设置，能够实现采样时刻点的随机设置，为采集到较具分析价值的数据提供了基础。

步骤104，在任务完成时，获取任务的开始时刻以及结束时刻，并根据开始时刻和结束时刻，获取任务的实际执行时长。

具体地说，应用程序借助终端系统运行原理，获取任务的开始时刻以及结束时刻，以便于根据开始时刻和结束时刻，获取任务的实际执行时长。以下对终端系统运行原理进行解释说明：

应用程序都是基于消息驱动机制运行的，即，每个应用程序都有唯一一个主线程。通常来说，所有任务都默认运行在主线程中，这些任务包括与用户交互，界面刷新等等。而消息驱动机制又规定，同一时刻主线程中只会有一个任务处于工作中，其余任务均在该线程对应的消息队列中排队等待执行。因此，基于以上内容，应用程序可以知晓主线程中每个任务的开始时刻和结束时刻。

步骤105，判断实际执行时长是否大于或等于预设卡顿阈值。若是，则执行步骤106，否则执行步骤108。

具体地说，预设卡顿阈值可以由开发人员预先设置并保存在应用程序中。若步骤105的执行结果为是，则说明应用程序发生了卡顿，此时执行步骤106，将第一采集数据上传至预设服务器，以便于开发人员能够及时地根据预设服务器接收到的数据进行卡顿分析，获取卡顿产生原因。若步骤105的执行结果为否，则说明应用程序只是丢帧，并未发生卡顿，此时执行步骤108，清除第一采集数据，以便于及时地清除无效数据，提高内存空间的利用率。

更具体地说，由图2及图2对应的示例可知：应用程序要流畅运行，应用程序应该每16.67ms都可以正常的更新界面，因此应用程序会在执行R1任务时，先根据终端系统的运行原理，计算上一个界面刷新任务R1结束至当前界面刷新任务R1前所有任务的总执行时长，以便于应用程序根据这一总执行时长计算出总共丢了多少帧，从而根据丢帧数来判断是否发生了卡顿。通常情况下，应用程序丢失几帧，用户对于丢失的这几帧并不会有很明显的感知，因此在实际开发中，开发人员可以设置预设卡顿阈值远大于应用程序的界面渲染周期，如，预设卡顿阈值可以为500毫秒。

本发明实施方式相对于现有技术而言，任务在开始执行时，设置一个计时事件来监测任务执行是否过于耗时，如果计时事件优先任务完成，则说明任务执行耗时，此时认为应用程序有发生卡顿的可能，需要对应用程序进行数据采集，获取第一采集数据。当任务完成时，根据任务的完成时刻以及开始时刻，计算任务的实际执行时长，如果任务的实际执行时长大于预设卡顿阈值，则说明应用程序发生了卡顿，此时将采集到的第一采集数据进行上报，以供开发人员进行数据分析，获取卡顿原因。这样，利用计时事件来评判应用程序是否丢帧，在应用程序不发生丢帧现象，正常运行时，并不会进行数据的采集工作，从而可以实现节省资源的目的，为延长电池电量，减少CPU运行负压提供了基础，应用程序在发生丢帧现象时，进行数据采集，不仅能够尽可能多地采集应用程序发生卡顿期间的相关数据，而且不需要实时地进行数据采集，以避免过多资源的占用与浪费。

本发明的第二实施方式涉及一种应用程序的信息采集方法，具体流程如图3所示。第二实施方式在第一实施方式的基础上加以改进，主要改进之处在于：在本发明第二实施方式中，还在计时事件执行期间进行数据采集，能够获取较为全面的数据。以下进行具体说明：

本实施方式中的步骤201与第一实施方式中的步骤101大致相同，步骤203至步骤206与第一实施方式中的步骤102至步骤105大致相同，为避免重复，在此不再赘述，以下仅对不同部分进行说明：

步骤202，在计时事件执行期间，对应用程序进行M次数据采集，并将M次数据采集的结果作为第二采集数据。

具体地说，为避免卡顿发生在计时事件执行期间(此种情况概率较低)，应用程序在计时事件执行期间，还进行M次数据采集，并将M次数据采集的结果作为第二采集数据。其中，应用程序可以通过随机算法进行若干次数据采集，也可以仅进行一次数据采集，如，在计时事件的开始执行时刻，对应用程序进行一次数据采集，对此，本实施方式并不做任何限定。

步骤207，将第一采集数据以及第二采集数据上传至预设服务器。

步骤209，清除第一采集数据以及第二采集数据。

与第一实施方式相比，本实施方式能够在计时事件执行期间进行数据采集，为开发人员能够获取较为全面的数据采集结果，分析出更准确的卡顿原因提供了基础。

上面各种方法的步骤划分，只是为了描述清楚，实现时可以合并为一个步骤或者对某些步骤进行拆分，分解为多个步骤，只要包括相同的逻辑关系，都在本专利的保护范围内；对算法中或者流程中添加无关紧要的修改或者引入无关紧要的设计，但不改变其算法和流程的核心设计都在该专利的保护范围内。

本发明第三实施方式涉及一种终端，如图4所示，包括：至少一个处理器301；以及，与至少一个处理器301通信连接的存储器302；其中，存储器302存储有可被至少一个处理器301执行的指令，指令被至少一个处理器301执行，以使至少一个处理器301能够执行上述方法实施方式中的应用程序的信息采集方法。

其中，存储器302和处理器301采用总线方式连接，总线可以包括任意数量的互联的总线和桥，总线将一个或多个处理器301和存储器302的各种电路连接在一起。总线还可以将诸如外围设备、稳压器和功率管理电路等之类的各种其他电路连接在一起，这些都是本领域所公知的，因此，本文不再对其进行进一步描述。总线接口在总线和收发机之间提供接口。收发机可以是一个元件，也可以是多个元件，比如多个接收器和发送器，提供用于在传输介质上与各种其他装置通信的单元。经处理器301处理的数据通过天线在无线介质上进行传输，进一步，天线还接收数据并将数据传送给处理器301。

处理器301负责管理总线和通常的处理，还可以提供各种功能，包括定时，外围接口，电压调节、电源管理以及其他控制功能。而存储器302可以被用于存储处理器301在执行操作时所使用的数据。

与现有技术相比，本实施方式不仅能够尽可能多地采集应用程序发生卡顿期间的相关数据，而且不需要实时地进行数据采集，以避免过多资源的占用与浪费。

本发明第四实施方式涉及一种计算机可读存储介质，存储有计算机程序。计算机程序被处理器执行时实现上述方法实施方式。

与现有技术相比，本实施方式不仅能够尽可能多地采集应用程序发生卡顿期间的相关数据，而且不需要实时地进行数据采集，以避免过多资源的占用与浪费。

即，本领域技术人员可以理解，实现上述实施方式方法中的全部或部分步骤是可以通过程序来指令相关的硬件来完成，该程序存储在一个存储介质中，包括若干指令用以使得一个设备(可以是单片机，芯片等)或处理器(processor)执行本申请各个实施方式所述方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器(ROM，Read-Only Memory)、随机存取存储器(RAM，Random Access Memory)、磁碟或者光盘等各种可以存储程序代码的介质。

本领域的普通技术人员可以理解，上述各实施方式是实现本发明的具体实施方式，而在实际应用中，可以在形式上和细节上对其作各种改变，而不偏离本发明的精神和范围。

Claims (9)

1.一种应用程序的信息采集方法，其特征在于，包括：

任务开始执行时，执行一计时事件；其中，所述计时事件的时长大于或等于所述任务的预设耗时时长；

若所述计时事件优先所述任务完成，则对所述应用程序进行数据采集，以获取第一采集数据；

在所述任务完成时，获取所述任务的开始时刻以及结束时刻，并根据所述开始时刻和所述结束时刻，获取所述任务的实际执行时长；

若所述实际执行时长大于或等于预设卡顿阈值，则将所述第一采集数据上传至预设服务器；

所述对所述应用程序进行数据采集，获取第一采集数据，具体包括：

获取N个采集时刻点；

根据所述N个采集时刻点对所述应用程序进行N次数据采集，并将所述N次数据采集的结果作为所述第一采集数据；其中，N为大于1的正整数。

2.根据权利要求1所述的应用程序的信息采集方法，其特征在于，所述获取N个采集时刻点，具体包括：

根据散列算法以及所述应用程序的界面渲染周期，计算获取所述N个采集时刻点。

3.根据权利要求1所述的应用程序的信息采集方法，其特征在于，还包括：

在所述计时事件执行期间，对所述应用程序进行M次数据采集，并将所述M次数据采集的结果作为第二采集数据；其中，M为大于0的正整数；

若所述实际执行时长大于或等于预设卡顿阈值，还将所述第二采集数据上传至预设服务器。

4.根据权利要求3所述的应用程序的信息采集方法，其特征在于，在所述计时事件执行期间，对所述应用程序进行M次数据采集，具体包括：

在所述计时事件的开始执行时刻，对所述应用程序进行一次数据采集。

5.根据权利要求1所述的应用程序的信息采集方法，其特征在于，所述任务的预设耗时时长等于所述应用程序的界面渲染周期。

6.根据权利要求1所述的应用程序的信息采集方法，其特征在于，还包括：

若所述任务优先所述计时事件完成，则取消所述计时事件。

7.根据权利要求1所述的应用程序的信息采集方法，其特征在于，还包括：

若所述实际执行时长小于预设卡顿阈值，则清除所述第一采集数据。

8.一种终端，其特征在于，包括：

至少一个处理器；以及，

与所述至少一个处理器通信连接的存储器；其中，

所述存储器存储有可被所述至少一个处理器执行的指令，所述指令被所述至少一个处理器执行，以使所述至少一个处理器能够执行如权利要求1至7中任一所述的应用程序的信息采集方法。

9.一种计算机可读存储介质，存储有计算机程序，其特征在于，所述计算机程序被处理器执行时实现权利要求1至7中任一项所述的应用程序的信息采集方法。

Images