应用程序的监测方法、装置及可读存储介质

技术领域

本申请涉及计算机技术领域，具体而言，涉及一种应用程序的监测方法、装置及可读存储介质。

背景技术

应用程序无响应(Application Not Responding，ANR)是指在对应用程序输入指令或请求后，在一段特定时间内没有得到响应或无法完成的情况。以安卓(Android)系统为例，应用程序响应由工作流管理器(Activity Manager)和窗口管理器(Window Manager)系统服务进行监视。在安卓应用程序中，应用无响应(ANR)是一种常见的问题，通常的原因是应用程序在主线程中执行了耗时的操作，导致主线程无法及时响应用户的操作。该场景常见于网络请求、数据库处理、繁琐的界面绘制、不恰当的逻辑导致循环或锁竞争等。

然而，在大型应用程序项目中，如果应用程序中的应用无响应事件出现频率居高不下，而开发者又无法快速、准确地找到导致应用程序无响应的原因，则会极大影响开发效率。

发明内容

为了至少克服现有技术中的上述不足，本申请的目的在于提供一种应用程序的监测方法、装置及可读存储介质。

第一方面，本申请实施例提供一种应用程序的监测方法，所述应用程序的监测方法应用于客户端，所述方法包括：

对运行于所述客户端的应用程序进行监测，得到对所述应用程序进行操作的响应时长；

基于所述响应时长判定所述应用程序是否发生应用无响应事件；

在所述应用程序发生应用无响应事件时，判定发生所述应用无响应事件的应用程序是否为目标应用程序；

在判定发生所述应用无响应事件的应用程序为目标应用程序时，获取所述目标应用程序中各个功能模块的日志信息，得到所述目标应用程序的日志文件；

基于所述目标应用程序的日志文件分析所述目标应用程序中发生应用无响应事件的功能模块中的操作业务

在一种可能的实现方式中，所述对运行于所述客户端的应用程序进行监测，得到对所述应用程序进行操作的响应时长的步骤，包括：

通过第一变量记录对所述应用程序进行操作时的时间，作为当前帧的起始时间；

监测所述当前帧的执行情况，采用第二变量记录所述当前帧执行完毕的时间，作为所述当前帧的结束时间；

基于所述第一变量记录的时间和所述第二变量记录的时间，计算得到对所述应用程序进行操作的响应时长。

在一种可能的实现方式中，所述基于所述响应时长判定所述应用程序是否发生应用无响应事件的步骤，包括：

将所述响应时长与预设的响应时长阈值进行比较；

在所述响应时长大于或等于所述预设的响应时长阈值时，判定所述应用程序发生应用无响应事件，在所述响应时长小于所述预设的响应时长阈值时，判定所述应用程序未发生应用无响应事件。

在一种可能的实现方式中，所述在所述应用程序发生应用无响应事件时，判定发生所述应用无响应事件的应用程序是否为目标应用程序的步骤，包括：

在所述应用程序发生应用无响应事件时，获取所述应用程序发生应用无响应事件时的执行轨迹信息，其中，所述执行轨迹信息包括与所述应用无响应事件相关的线程堆栈信息；

基于所述执行轨迹信息，获取发生无响应事件的所述应用程序的进程名称；

将所述进程名称与所述目标应用程序的名称进行对比，若所述进程名称与所述目标应用程序的名称一致，则判定所述目标应用程序发生所述应用无响应事件，若所述进程名称与所述目标应用程序的名称不一致，则判定所述目标应用程序未发生所述应用无响应事件。

在一种可能的实现方式中，所述在判定发生所述应用无响应事件的应用程序为目标应用程序时，获取所述目标应用程序中各个功能模块的日志信息，得到所述目标应用程序的日志文件的步骤，包括：

若判定所述目标应用程序发生所述应用无响应事件，则获取所述应用无响应事件的时间戳；

获取所述目标应用程序在所述时间戳之前的日志信息，得到所述目标应用程序的日志文件，其中，所述日志文件以所述时间戳进行命名。

在一种可能的实现方式中，在所述对运行于所述客户端的应用程序进行监测，得到对所述应用程序进行操作的响应时长的步骤之前，所述方法还包括：

在所述目标应用程序的功能模块中预先配置模块日志系统；

在所述获取所述目标应用程序在所述时间戳之前的日志信息，得到所述目标应用程序的日志文件的步骤之前，所述方法还包括：

当所述目标应用程序运行到预先配置有模块日志系统的功能模块时，通过预先配置的模块日志系统记录所述功能模块的日志信息。

在一种可能的实现方式中，所述基于所述目标应用程序的日志文件分析所述目标应用程序中发生应用无响应事件的功能模块中的操作业务的步骤，包括：

对所述目标应用程序的日志文件进行解析，获取时间戳；

对所述目标应用程序中各个功能模块的日志信息进行检测，得到在所述时间戳前写入日志信息的目标功能模块；

对所述目标功能模块的日志信息进行检测，将所述目标功能模块在所述时间戳时执行的操作业务作为导致所述目标应用程序发生所述应用无响应事件的操作业务。

第二方面，本申请实施例还提供另一种应用程序的监测方法，应用于应用程序监测系统，所述应用程序监测系统包括通信连接的客户端和服务器，所述方法包括：

所述客户端对运行于所述客户端的应用程序进行监测，得到对所述应用程序进行操作的响应时长；

所述客户端基于所述响应时长判定所述应用程序是否发生应用无响应事件；

所述客户端在所述应用程序发生应用无响应事件时，判定发生所述应用无响应事件的应用程序是否为目标应用程序；

所述客户端在判定发生所述应用无响应事件的应用程序为目标应用程序时，获取所述目标应用程序中各个功能模块的日志信息，得到所述目标应用程序的日志文件，并将所述目标应用程序的日志文件发送给所述服务器；

所述服务器基于所述目标应用程序的日志文件分析所述目标应用程序中发生应用无响应事件的功能模块。

在一种可能的实现方式中，所述服务器基于所述目标应用程序的日志文件分析所述目标应用程序中发生应用无响应事件的功能模块的步骤，包括：

所述服务器对所述目标应用程序的日志文件进行解析，获取时间戳；

对所述目标应用程序中各个功能模块的日志信息进行检测，得到在所述时间戳前写入日志信息的目标功能模块；

对所述目标功能模块的日志信息进行检测，将所述目标功能模块在所述时间戳时执行的操作作为导致所述目标应用程序发生所述应用无响应事件的执行操作。

第三方面，本申请实施例还提供一种应用程序的监测装置，所述装置包括：

检测模块，用于对运行于客户端的应用程序进行监测，得到对所述应用程序进行操作的响应时长；

事件发生判定模块，用于基于所述响应时长判定所述应用程序是否发生应用无响应事件；

目标程序判定模块，用于在所述应用程序发生应用无响应事件时，判定发生所述应用无响应事件的应用程序是否为目标应用程序；

日志获取模块，用于在判定发生所述应用无响应事件的应用程序为目标应用程序时，获取所述目标应用程序中各个功能模块的日志信息，得到所述目标应用程序的日志文件；

分析模块，用于基于所述目标应用程序的日志文件分析所述目标应用程序中发生应用无响应事件的功能模块。

第四方面，本申请实施例还提供一种计算机可读存储介质，其上存储有计算机程序，该计算机程序被处理器执行时实现如第一方面或第二方面中任意一种所述的应用程序的监测方法或第三方面所述的应用程序的监测装置的功能。

基于上述任意一个方面，本申请实施例提供的应用程序的监测方法、装置及可读存储介质，采用该应用程序的监测方法不仅可以快速得知目标应用程序是否发生应用无响应事件时，还可以通过分析目标应用程序中各个功能模块的日志信息明确各功能模块中的业务执行逻辑，快速查找到导致目标应用程序发生应用无响应事件的操作业务。从而帮助开发者对目标应用程序进行优化，提高开发者的开发效率。

附图说明

为了更清楚地说明本申请实施例的技术方案，下面将对实施例中所需要调用的附图作简单地介绍，应当理解，以下附图仅示出了本申请的某些实施例，因此不应被看作是对范围的限定，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其它相关的附图。

图1为本申请提供的应用程序的监测方法的一种可能的流程示意图；

图2为图1中步骤S11的子步骤流程示意图；

图3为图1中步骤S13的子步骤流程示意图；

图4为图1中步骤S14的子步骤流程示意图；

图5为图1中步骤S15的子步骤流程示意图；

图6为本申请提供的应用程序的监测方法的另一种可能的流程示意图；

图7为图6中步骤S25的子步骤流程示意图；

图8为本申请实施例提供的应用程序的监测装置的一种功能模块示意图；

图9为本申请实施例提供的客户端的结构方框示意图。

具体实施方式

为使本申请实施例的目的、技术方案和优点更加清楚，下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，应当理解，本申请中附图仅起到说明和描述的目的，并不用于限定本申请的保护范围。另外，应当理解，示意性的附图并未按实物比例绘制。本申请中使用的流程图示出了根据本申请实施例的一些实施例实现的操作。应该理解，流程图的操作可以不按顺序实现，没有逻辑的上下文关系的步骤可以反转顺序或者同时实施。此外，本领域技术人员在本申请内容的指引下，可以向流程图添加一个或多个其它操作，也可以从流程图中移除一个或多个操作。

另外，所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例。通常在此处附图中描述和示出的本申请实施例的组件可以以各种不同的配置来布置和设计。因此，以下对在附图中提供的本申请的实施例的详细描述并非旨在限制要求保护的本申请的范围，而是仅仅表示本申请的选定实施例。基于本申请的实施例，本领域技术人员在没有做出创造性劳动的前提下所获得的所有其它实施例，都属于本申请保护的范围。

需要说明的是，在不冲突的情况下，本申请的实施例中的不同特征之间可以相互结合。

为了解决现有技术中存在的上述技术问题，本申请实施例提供一种应用程序的监测方法，为了便于理解本申请方案，先对本申请可能应用的应用程序监测系统进行介绍，可以理解下面介绍的应用程序监测系统只是为了说明本申请方案的可能应用场景，本申请方案也可以应用在下述场景之外的其他应用场景中。

第一实施例

下面结合图1所示的流程示意图对本申请实施例提供的应用程序的监测方法进行示例性说明。本申请实施例提供的应用程序的监测方法可以由客户端执行，在本申请实施例的应用程序的监测方法中的部分步骤的顺序可以根据实际需要相互交换，或者其中的部分步骤也可以省略或删除，该客户端执行的应用程序的监测方法的详细步骤介绍如下。

步骤S11：对运行于客户端的应用程序进行监测，得到对应用程序进行操作的响应时长。

在本步骤中，以安卓系统为例，可以由安卓系统中的Activity Manager和WindowManager系统服务对应用程序进行监测，得到对应用程序进行操作的响应时长。需要说明的是，在本申请实施例中不对监测应用程序获取响应时长的具体实现方式进行限定。

步骤S12：基于响应时长判定应用程序是否发生应用无响应事件。

在本步骤中，当响应时长过长时，即当运行应用程序的主线程出现响应耗时过长时，则可以认为应用程序出现应用无响应事件。示例性地，以安卓系统为例，当安卓系统监测到应用程度的用户界面线程(UI Thread)超过5s无响应，或广播(Broadcast)超过10s无响应等情况视为出现了应用无响应事件，即可以判定应用程序出现应用无响应事件。

步骤S13：在应用程序发生应用无响应事件时，判定发生应用无响应事件的应用程序是否为目标应用程序。

在本步骤中，以安卓系统为例，当任意一个应用程序发生应用无响应事件时，系统都会将应用程序当前的跟踪(trace)数据写入监听的文件目录(/data/anr)下，因此当监听到该文件目录的变动，只能确定该安卓系统中的存在应用程序发生了应用无响应事件，而无法确定发生应用无响应事件的应用程序是否为开发者关注的目标应用程序程序。其中，文件目录(/data/anr)下包括多个跟踪文件(traces.txt)，每个跟踪文件对应一个应用程序发生的应用无响应事件，跟踪文件(traces.txt)中的跟踪(trace)数据通常包括应用程序的所有线程的名称、状态和各自调用栈信息等，通过查看跟踪文件(traces.txt)获取应用程序的名称以及所有线程的调用栈信息，可以更全面地分析应用无响应事件的发生原因，即也可以确定发生应用无响应事件的应用程序是否为目标应用程序。

步骤S14：在判定发生应用无响应事件的应用程序为目标应用程序时，获取目标应用程序中各个功能模块的日志信息，得到目标应用程序的日志文件。

在本步骤中，日志信息可以用于记录程序的状态、事件、错误等信息，可以帮助开发者了解程序的执行情况、诊断问题和跟踪错误。在记录目标应用程序的日志信息时，可以通过调用相应的接口(API)获取各个功能模块的线程堆栈信息，并将其添加到对应的模块日志当中。

步骤S15：基于目标应用程序的日志文件分析目标应用程序中发生应用无响应事件的功能模块中的操作业务。

在本步骤中，客户端通过分析日志文件中的模块日志信息，可以明确各功能模块中的业务执行逻辑，快速查找到导致目标应用程序发生应用无响应事件的操作业务，从而帮助开发者对目标应用程序进行优化，可以提高开发者的工作效率。

在本实施例中，采用该应用程序的监测方法不仅可以快速得知目标应用程序是否发生应用无响应事件时，还可以通过分析目标应用程序中各个功能模块的日志信息明确各功能模块中的业务执行逻辑，快速查找到导致目标应用程序发生应用无响应事件的操作业务，从而帮助开发者对目标应用程序进行优化，提高开发者的开发效率。

请参阅图2，在本申请的一种可能的实施方式中，步骤S11可以通过以下方法实现。

子步骤S111：通过第一变量记录对应用程序进行操作时的时间，作为当前帧的起始时间。

子步骤S112：监测当前帧的执行情况，采用第二变量记录当前帧执行完毕的时间，作为当前帧的结束时间。

子步骤S113：基于第一变量记录的时间和第二变量记录的时间，计算得到对应用程序进行操作的响应时长。

在本实施例中，可以在安卓系统中的循环函数(Looper.loop())增加第一变量A及第二变量B，用以记录当前帧的起始时间及当前帧的结束时间。将第一变量A与第二变量B之间的差作为对应用程序进行操作的响应时长。具体地，以B-A表示对应用程序进行操作的响应时长。

更进一步地，在获得响应时长后，将响应时长与预设的响应时长阈值进行比较。在响应时长大于或等于预设的响应时长阈值时，可以判定应用程序发生应用无响应事件；在响应时长小于预设的响应时长阈值时，则判定应用程序未发生应用无响应事件。

需要说明的是，预设的响应时长可以由技术人员根据具体情况进行配置。示例性地，预设的响应时长可以配置为5s，当第一变量A与第二变量B之间的差大于或等于5s时，则可以认为当前的应用程序出现卡顿、帧冻结等应用无响应事件。

请参阅图3，在本实施例的一种可能实施方式中，步骤S13可以通过以下方法实现。

子步骤S131：在应用程序发生应用无响应事件时，获取应用程序发生应用无响应事件时的执行轨迹信息，其中，执行轨迹信息包括与应用无响应事件相关的线程堆栈信息。

在本步骤中，执行轨迹信息可以指前文所述的跟踪(trace)数据。

子步骤S132：基于执行轨迹信息，获取发生无响应事件的应用程序的进程名称。

在本步骤中，可以通过读取执行轨迹信息获取应用程序的进程名称，进程名称又称为进程标识符(pid)，是指操作系统中用于标识进程的唯一数字标识符，每个正在运行的应用程序都有唯一一个对应的进程标识符。根据执行轨迹信息中的进程名称可以判断发生应用无响应事件的应用程序是否为目标应用程序。

子步骤S133：将进程名称与目标应用程序的名称进行对比，若进程名称与目标应用程序的名称一致，则判定目标应用程序发生应用无响应事件，若进程名称与目标应用程序的名称不一致，则判定目标应用程序未发生应用无响应事件。

在本步骤中，目标应用程序的名称也称为程序包名(程序包标识符)，是指安卓应用程序中用于唯一标识应用程序的字符串。

在本实施例中，当监听器监听到文件目录(/data/anr)发生变化时，则可以得知应用程序发生应用无响应事件，此时获取该文件目录(/data/anr)下新增的执行轨迹信息(跟踪文件(traces.txt)中的跟踪(trace)数据)，通过读取执行轨迹信息可以获得发生应用无响应事件的应用程序的进程名称，当执行轨迹信息中的进程名称与目标应用程序的名称一致时，则可以判定目标应用程序发生了无响应事件。

请参阅图4，在本实施例的一种可能实施方式中，步骤S14可以通过以下方法实现。

子步骤S141：若判定目标应用程序发生应用无响应事件，则获取应用无响应事件的时间戳。

在本步骤中，可以通过监听器监获得应用无响应事件发生的时间戳，该时间戳指的是当监听器监听到目标应用程序发生无响应事件的时间。

子步骤S142：获取目标应用程序在时间戳之前的日志信息，得到目标应用程序的日志文件，其中，日志文件以时间戳进行命名。

在本步骤中，当监听到目标应用程序发生应用无响应事件时，该监听器将会向日志系统发送一个带有时间戳的广播，此时日志系统将会获取目标应用程序在时间戳之前的各个功能模块的日志信息，得到目标应用程序的日志文件，其中，日志文件以时间戳命名可以便于后续服务器获取目标应用程序发生无响应事件的时间。

进一步地，为了实现子步骤S142，在步骤S11之前，还需要在目标应用程序的功能模块中预先配置模块日志系统，需要说明的是，并非所有功能模块都需要预先配置模块日志系统，可以只在部分功能模块中进行配置，在选定需要配置的功能模块后，可以只对功能模块中的部分业务配置模块日志系统，详细地，在需要配置的业务所对应的代码中加入该模块日志系统。

具体地，当开发者认为某个功能模块中的某个业务(Activity)可能会导致目标应用程序发生应用无响应事件时，可以在执行该业务(Activity)的代码处配置模块日志系统，该模块日志系统可以视为一个专有的模块日志接口(API)，用于记录该模块执行该业务(Activity)时的日志信息，此外，模块日志系统还能够将模块的日志信息发送给目标应用程序的日志系统。其中，在记录目标应用程序的日志信息时，还可以通过调用相应的接口(API)获取各个功能模块的线程堆栈信息，并将其添加到对应的模块日志当中。

而在执行子步骤S142之前，还包括以下步骤：当目标应用程序运行到预先配置有模块日志系统的功能模块时，通过预先配置的模块日志系统记录功能模块的日志信息。示例性地，假设在目标应用程序中的A功能模块写入模块日志系统，当A功能模块执行“打开App-打开首页-打开‘我的’页面”的过程中，可以写下以下“‘App被打开’、‘首页被打开’、‘我的页面被打开’”模块日志信息，但当开发者觉得“打开首页”这个业务(Activity)导致目标应用程序发生应用无响应事件的几率较小时，可以选择不在此处写入模块日志系统，则当目标应用程序发生应用无响应事件时上传的日志信息仅保存“‘App被打开’、‘我的页面被打开’”。

在本实施例中，采用模块日志系统不仅可以记录目标应用程序中的各功能模块业务执行情况，还可以记录各个功能模块的线程堆栈信息，在目标应用程序发生应用无响应事件时，这些详细的线程堆栈信息和业务执行日志可以帮助开发者快速查找到导致目标应用程序发生应用无响应事件的操作业务。此外，本实施例的模块日志系统接入方式简单，与项目低耦合，具有更高的灵活性与可扩展性。

请参阅图5，在本实施例的一种可能实施方式中，步骤S15可以通过以下方法实现。

子步骤S151：对目标应用程序的日志文件进行解析，获取时间戳。

子步骤S152：对目标应用程序中各个功能模块的日志信息进行检测，得到在时间戳前写入日志信息的目标功能模块。

子步骤S153：对目标功能模块的日志信息进行检测，将目标功能模块在时间戳时执行的操作业务作为导致目标应用程序发生应用无响应事件的操作业务。

在本实施例中，客户端可以通过分析文件名称得到时间戳，而后对日志文件进行解压，根据解压后的日志信息得到在时间戳前写入日志信息的目标功能模块，而后根据目标功能模块的模块日志信息明确目标功能模块中的业务执行逻辑，得到与时间戳对应的操作业务，将该操作视为导致目标应用程序发生应用无响应事件的操作业务。

在本实施例的一种可能实施方式中，步骤S15之后还包括以下方法。

根据导致目标应用程序发生应用无响应事件的操作业务生成无响应事件日志，并将该无响应事件日志上传至服务器，以便于开发者对目标应用程序进行优化。

第二实施例

请参阅图6，本申请实施例还提供另一种应用程序的监测方法，应用于应用程序监测系统，应用程序监测系统包括通信连接的客户端和服务器，方法包括：

步骤S21：客户端对运行于客户端的应用程序进行监测，得到对应用程序进行操作的响应时长。

在本步骤中，以安卓系统为例，可以由安卓系统中的Activity Manager和WindowManager系统服务对应用程序进行监测，得到对应用程序进行操作的响应时长。需要说明的是，在本申请实施例中不对监测应用程序获取响应时长的具体实现方式进行限定。

步骤S22：客户端基于响应时长判定应用程序是否发生应用无响应事件。

在本步骤中，当响应时长过长时，即当运行应用程序的主线程出现高响应耗时时，则可以认为应用程序出现应用无响应事件。示例性地，以安卓系统为例，当安卓系统监测到应用程度的用户界面线程(UI Thread)超过五s无响应，或广播(Broadcast)超过10无响应等情况视为出现应用无响应事件，即可以判定应用程序出现无响应事件。

步骤S23：客户端在应用程序发生应用无响应事件时，判定发生应用无响应事件的应用程序是否为目标应用程序。

在本步骤中，以安卓系统为例，当任意一个应用程序发生应用无响应事件时，系统都会将应用程序当前的跟踪(trace)数据写入监听的文件目录(/data/anr)下，因此当监听到该文件目录的变动，只能确定该安卓系统中的存在应用程序发生了应用无响应事件，而无法确定发生应用无响应事件的应用程序是否为开发者关注的目标应用程序程序。其中，文件目录(/data/anr)下包括多个跟踪文件(traces.txt)，每个跟踪文件对应一个应用程序发生的应用无响应事件，跟踪文件(traces.txt)中的跟踪(trace)数据通常包括应用程序的所有线程的名称、状态和各自调用栈信息等，通过查看跟踪文件(traces.txt)获取应用程序的，名称以及所有线程的调用栈信息，可以更全面地分析应用无响应事件的发生原因，即也可以确定发生应用无响应事件的应用程序是否为目标应用程序。

步骤S24：客户端在判定发生应用无响应事件的应用程序为目标应用程序时，获取目标应用程序中各个功能模块的日志信息，得到目标应用程序的日志文件，并将目标应用程序的日志文件发送给服务器。

在本步骤中，日志信息可以用于记录程序的状态、事件、错误等信息，可以帮助开发者了解程序的执行情况、诊断问题和跟踪错误。在记录目标应用程序的日志信息时，可以通过调用相应的接口(API)获取各个功能模块的线程堆栈信息，并将其添加到对应的模块日志当中。

步骤S25：服务器基于目标应用程序的日志文件分析目标应用程序中发生应用无响应事件的功能模块。

在本步骤中，服务器可以通过分析日志信息可以明确各功能模块中的业务执行逻辑，快速查找到导致目标应用程序发生应用无响应事件的操作业务，从而帮助开发者对目标应用程序进行优化，可以提高开发者的工作效率。

通过上述方法，客户端可以快速得知目标应用程序是否发生应用无响应事件时，并向服务器发送记录各个功能模块的日志信息的日志文件。服务器通过分析日志文件可以明确各功能模块中的业务执行逻辑，快速查找到导致目标应用程序发生应用无响应事件的操作业务。从而帮助开发者对目标应用程序进行优化，提高开发者的开发效率。

进一步地，请参阅图7，步骤S25可以通过以下方法实现。

子步骤S251：对目标应用程序中各个功能模块的日志信息进行检测，得到在时间戳前写入日志信息的目标功能模块。

子步骤S252：对目标功能模块的日志信息进行检测，将目标功能模块在时间戳时执行的操作作为导致目标应用程序发生应用无响应事件的执行操作。

在本实施例中，服务器可以通过分析文件名称得到时间戳，而后对日志文件进行解压，根据解压后的日志信息得到在时间戳前写入日志信息的目标功能模块，而后根据目标功能模块的模块日志信息明确目标功能模块中的业务执行逻辑，得到与时间戳对应的操作业务，将该操作视为导致目标应用程序发生应用无响应事件的操作业务。

第三实施例

基于相同的发明构思，本申请实施还提供一种应用程序的监测装置400，请参照图8，图8为本申请实施例提供的应用程序的监测装置400的一种功能模块示意图。本申请实施例可以根据客户端执行的方法实施例对应用程序的监测装置400进行功能模块的划分，也即该应用程序的监测装置400所对应的以下各个功能模块可以用于执行上述各个方法实施例。其中，该应用程序的监测装置400可以包括检测模块410、事件发生判定模块420、目标程序判定模块430、日志获取模块440及分析模块450，下面分别对该应用程序的监测装置400的各个功能模块的功能进行详细阐述。

检测模块410，用于对运行于客户端的应用程序进行监测，得到对应用程序进行操作的响应时长。

以安卓系统为例，可以由安卓系统中的Activity Manager和Window Manager系统服务对应用程序进行监测，得到对应用程序进行操作的响应时长。需要说明的是，在本申请实施例中不对监测应用程序获取响应时长的具体实现方式进行限定。

本实施例中，检测模块410可以用于执行上述的步骤S11，关于检测模块410的详细实现方式可以参照上述针对步骤S11的详细描述。

事件发生判定模块420，用于基于响应时长判定应用程序是否发生应用无响应事件。

当响应时长过长时，即当运行应用程序的主线程出现响应耗时过长时，则可以认为应用程序出现应用无响应事件。

本实施例中，事件发生判定模块420可以用于执行上述的步骤S12，关于事件发生判定模块420的详细实现方式可以参照上述针对步骤S12的详细描述。

目标程序判定模块430，用于在应用程序发生应用无响应事件时，判定发生应用无响应事件的应用程序是否为目标应用程序。

以安卓系统为例，当任意一个应用程序发生应用无响应事件时，系统都会将应用程序当前的跟踪(trace)数据写入监听的文件目录(/data/anr)下，因此当监听到该文件目录的变动，只能确定该安卓系统中的存在应用程序发生了应用无响应事件，而无法确定发生应用无响应事件的应用程序是否为开发者关注的目标应用程序程序。其中，文件目录(/data/anr)下包括多个跟踪文件(traces.txt)，每个跟踪文件对应一个应用程序发生的应用无响应事件，跟踪文件(traces.txt)中的跟踪(trace)数据通常包括应用程序的所有线程的名称、状态和各自调用栈信息等，通过查看跟踪文件(traces.txt)获取应用程序的，名称以及所有线程的调用栈信息，可以更全面地分析应用无响应事件的发生原因，即也可以确定发生应用无响应事件的应用程序是否为目标应用程序。

本实施例中，目标程序判定模块430可以用于执行上述的步骤S13，关于目标程序判定模块430的详细实现方式可以参照上述针对步骤S13的详细描述。

日志获取模块440，用于在判定发生应用无响应事件的应用程序为目标应用程序时，获取目标应用程序中各个功能模块的日志信息，得到目标应用程序的日志文件。

日志信息可以用于记录程序的状态、事件、错误等信息，可以帮助开发者了解程序的执行情况、诊断问题和跟踪错误。在记录目标应用程序的日志信息时，可以通过调用相应的接口(API)获取各个功能模块的线程堆栈信息，并将其添加到对应的模块日志当中。

本实施例中，日志获取模块440可以用于执行上述的步骤S14，关于日志获取模块440的详细实现方式可以参照上述针对步骤S14的详细描述。

分析模块450，用于基于目标应用程序的日志文件分析目标应用程序中发生应用无响应事件的功能模块中的操作业务。

通过分析日志信息可以明确各功能模块中的业务执行逻辑，快速查找到导致目标应用程序发生应用无响应事件的操作业务，从而帮助开发者对目标应用程序进行优化，可以提高开发者的工作效率。

本实施例中，分析模块450可以用于执行上述的步骤S15，关于分析模块450的详细实现方式可以参照上述针对步骤S15的详细描述。

除上述模块外，应用程序的监测装置400还可以包块发送模块，用于根据导致目标应用程序发生应用无响应事件的操作业务生成无响应事件日志，并将该无响应事件日志上传至服务器，以便于开发者对目标应用程序进行优化。

需要说明的是，应理解以上装置或系统中的各个模块的划分仅仅是一种逻辑功能的划分，实际实现时可以全部或部分集成到一个物理实体上，也可以在物理上分开。且这些模块可以全部以软件(比如，开源软件)可以通过处理器调用的形式实现；也可以全部以硬件的形式实现；还可以部分模块通过处理器调用软件的形式实现，部分模块通过硬件的形式实现。作为一种示例，日志获取模块440可以由单独处理器运行实现，可以以程序代码的形式存储于上述装置或系统的存储器中，由上述装置或系统的某一个处理器调用并执行以上日志获取模块440的功能，其它模块的实现与之类似，在此就不再赘述。此外这些模块可以全部或部分集成在一起，也可以独立实现。这里所描述的处理器可以是一种具有信号的处理能力的集成电路，在实现过程中，上述技术方案中的各步骤或各个模块可以通过处理器中的集成逻辑电路或者执行软件程序的形式完成。

请参照图9，图9示出了本公开实施例提供的用于实现上述的应用程序的监测方法的客户端的硬件结构示意图。如图9所示，客户端200可包括处理器201、计算机可读存储介质202、总线203及通信单元204。

在具体实现过程中，处理器201执行计算机可读存储介质202存储的计算机执行指令(例如图8中所示的应用程序的监测装置400中的各个模块)，使得处理器201可以执行如上方法实施例的应用程序的监测方法，其中，处理器201、计算机可读存储介质202以及通信单元204可以通过总线203连接。

处理器201的具体实现过程可参见上述客户端200执行的各个方法实施例，其实现原理和技术效果类似，本申请实施例此处不再赘述。

计算机可读存储介质202可以是，但不限于，随机存取存储器(Random AccessMemory，RAM)，只读存储器(Read Only Memory，ROM)，可编程只读存储器(ProgrammableRead-Only Memory，PROM)，可擦除只读存储器(Erasable Programmable Read-OnlyMemory，EPROM)，电可擦除只读存储器(Electric Erasable Programmable Read-OnlyMemory，EEPROM)等。其中，存储器用于存储程序或者数据。

总线203可以分为地址总线、数据总线、控制总线等。为便于表示，本申请附图中的总线并不限定仅有一根总线或一种类型的总线。

在本申请实施例提供的交互场景中，通信单元204可用于与服务器通信，以实现服务器与客户端200之间的数据交互。

此外，本申请实施例还提供一种可读存储介质，可读存储介质中存储有计算机执行指令，当处理器执行计算机执行指令时，实现如上的应用程序的监测方法。

综上所述，本申请提供一种应用程序的监测方法、装置及可读存储介质，采用该应用程序的监测方法不仅可以快速得知目标应用程序是否发生应用无响应事件时，还可以通过分析目标应用程序中各个功能模块的日志信息明确各功能模块中的业务执行逻辑，快速查找到导致目标应用程序发生应用无响应事件的操作业务。从而帮助开发者对目标应用程序进行优化，提高开发者的开发效率。

以上所述仅为本申请的优选实施例而已，并不用于限制本申请，对于本领域的技术人员来说，本申请可以有各种更改和变化。凡在本申请的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本申请的保护范围之内。