CN115827373A - 应用程序崩溃类问题的记录及定位方法、系统、终端设备及存储介质 - Google Patents

Abstract

本发明提供了一种应用程序崩溃类问题的记录及定位方法、系统、终端设备及存储介质，涉及计算机系统领域，其系统包括运行记录装置，异常捕获装置，异常信息持久化装置；运行记录装置，用于应用程序运行过程中，时刻记录四部分信息：用户的账户信息、设备类型信息、api接口返回的响应信息、应用程序前台的页面信息；本发明可在出现异常信息秒级上报至服务器并通知相关人员，上报精确的现场情况，包括异常页面、用户信息、接口数据情况，供测试人员复现问题，无需专门工具和特殊脚本，直接分析现场接口情况，供开发和测试人员立刻着手分析问题，有效减少应用程序体积和三方SDK隐患。

Description

应用程序崩溃类问题的记录及定位方法、系统、终端设备及存 储介质

技术领域

本发明涉及计算机系统领域，具体而言，涉及一种应用程序崩溃类问题的记录及定位方法、系统、终端设备及存储介质。

背景技术

目前对于app崩溃等异常业内普遍是一下几种方案

1、接入bugly平台的SDK进行crash上报，结合符号表分析错误的堆栈信息，从而找到出错的地方进行代码处理

2、接入umeng平台的SDK进行异常上报，使用专门的工具进行崩溃分析。

但上述方案存在缺陷，具体的：

1、上报时间不及时，umeng平台发生崩溃时，异常信息上报长达几个小时，bugly异常信息上报也需要分钟级别。

2、上报的异常信息太底层，只有开发人员才能使用异常信息定位分析，测试人员无法参与复现及分析。

3、需要专门的分析工具或者符号表进行分析，对于封闭系统如银行相关无法上传符号表进行分析，导致上报的异常信息无法进行问题定位。

4、引入三方SDK可能导致的其他不可预知、不可控的问题。

5、应用程序本身体积增大。

发明内容

本发明旨在解决应用程序出现异常时，秒级时间内迅速捕获此异常，并将详细步骤及现场情况记录和同步至服务器，以此方便和准确地供开发和测试人员快速复现、分析定位、修复此异常。

具体的，一种应用程序崩溃类问题的记录及定位方法，具体步骤包括：

S1：用户启动应用程序，运行记录装置开始持续工作，记录应用程序的 api接口日志和应用程序的前台页面信息。

S2：异常捕获装置持续运行，检测当前是否发生崩溃情况，如果是，进入S3，如果否进入S2。

S3：异常信息持久化装置将运行记录装置记录的四部分内容打包发送到系统后端服务中。

S4：系统后端服务将上报的异常信息存储到数据库中，并发送邮件通知应用负责人等相关人员。

进一步的：在上述S1步骤中记录前台页面信息时，当刚进入页面需要截取应用程序界面的图形，用户在页面上进行操作，如点击某一个tab后，再次截取界面上的图形，并用箭头标记出用户具体点击的位置坐标。当分析异常信息时，看到同一个页面如果没有点击行为的截图，说明大概率是由这个页面的某个接口的数据未被正确处理所导致的崩溃问题。

进一步的：在上述S1步骤中记录应用程序的api接口日志时和前台页面信息时，需要保留最新的20个接口和10个页面信息，因为应用运行过程中会有大量的信息被记录下来，而真正需要关注的只是发生崩溃时最新的一些数据，同时也可以有效减少对应用程序本身运行性能的影响和传输异常信息时所用到的资源和时间数量。

进一步的：在上述S4步骤中系统后端发送邮件通知应用负责人等相关人员时，可以更加灵活的采用即时通信方案进行通知，如介入企业微信或者通过钉钉机器人等方式更加及时得通知发送到相关人员。

进一步的：一种应用程序崩溃类问题的记录及定位的系统，包括运行记录装置，异常捕获装置，异常信息持久化装置。

应用程序运行过程中，运行记录装置时刻记录四部分信息：用户的账户信息(或游客信息)、设备类型信息、api接口返回的响应信息、应用程序前台的页面信息。

页面信息包含用户在应用程序上的行为记录的标记，如用户在页面进行点击tab操作，需要在记录页面信息时，用箭头标记出用户的具体点击位置。为保证不影响应用程序运行性能，只保留最新的20个接口和10个页面信息。

异常捕获装置在应用运行过程中检测崩溃情况，出现崩溃时，捕获到此异常，将记录装置记录的最新信息通知给异常信息持久化装置。

异常信息持久化装置接收到崩溃信息后，将运行记录装置记录的三部分信息打包发送到服务器中，由服务器后端记录保存到数据库中存储，并同时邮件发送给应用负责人。

进一步的：终端设备可以包括：处理器、存储介质和总线，存储介质存储有处理器可执行的机器可读指令，当终端设备运行时，处理器与存储介质之间通过总线通信，处理器执行机器可读指令，以执行时执行如前述实施例中所述的深度学习模型训练方法的步骤。

进一步的：一种存储介质，该存储有计算机程序，所述计算机程序被处理器运行时执行上述的方法的步骤。

本发明的有益效果：本发明可在出现异常信息秒级上报至服务器并通知相关人员，上报精确的现场情况，包括异常页面、用户信息、接口数据情况，供测试人员复现问题，无需专门工具和特殊脚本，直接分析现场接口情况，供开发和测试人员立刻着手分析问题，有效减少应用程序体积和三方 SDK隐患。

附图说明

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

图1示出了本发明方法的流程示意图。

图2示出了本发明系统的组成示意图。

图3示出了本发明终端设备的组成示意图。

具体实施方式

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

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

需要说明的是，本发明实施例中将会用到术语“包括”，用于指出其后所声明的特征的存在，但并不排除增加其它的特征。还应注意到：相似的标号和字母在下面的附图中表示类似项，因此，一旦某一项在一个附图中被定义，则在随后的附图中不需要对其进行进一步定义和解释。在本发明的描述中，还需要说明的是，术语“第一”、“第二”、“第三”等仅用于区分描述，而不能理解为指示或暗示相对重要性。

图1示出了本发明方法的步骤流程图。

本发明所述的方法，具体步骤包括：

S1：用户启动应用程序，运行记录装置开始持续工作，记录应用程序的 api接口日志和应用程序的前台页面信息。

S2：异常捕获装置持续运行，检测当前是否发生崩溃情况，如果是，进入S3，如果否进入S2。

S3：异常信息持久化装置将运行记录装置记录的四部分内容打包发送到系统后端服务中。

S4：系统后端服务将上报的异常信息存储到数据库中，并发送邮件通知应用负责人等相关人员。

在上述S1步骤中记录前台页面信息时，当刚进入页面需要截取应用程序界面的图形，用户在页面上进行操作，如点击某一个tab后，再次截取界面上的图形，并用箭头标记出用户具体点击的位置坐标。当分析异常信息时，看到同一个页面如果没有点击行为的截图，说明大概率是由这个页面的某个接口的数据未被正确处理所导致的崩溃问题。

在上述S1步骤中记录应用程序的api接口日志时和前台页面信息时，需要保留最新的20个接口和10个页面信息，因为应用运行过程中会有大量的信息被记录下来，而真正需要关注的只是发生崩溃时最新的一些数据，同时也可以有效减少对应用程序本身运行性能的影响和传输异常信息时所用到的资源和时间数量。

在上述S4步骤中系统后端发送邮件通知应用负责人等相关人员时，可以更加灵活的采用即时通信方案进行通知，如介入企业微信或者通过钉钉机器人等方式更加及时得通知发送到相关人员。

本方案对于应用程序得崩溃捕获不管在测试环境还是应用的生产环境均适用。

使用本方案提供的捕获到打包后的及部分信息结合使用，能非常方便的定位到崩溃发生的原因，降低问题定位的门槛，开发和测试人员能直接看截图和日志信息定位崩溃原因。如无法直接定位的，也能根据10个界面截图信息很方便的按操作步骤复现此问题。

如图2所示，本发明所述的系统，包括运行记录装置，异常捕获装置，异常信息持久化装置。

应用程序运行过程中，运行记录装置时刻记录四部分信息：用户的账户信息(或游客信息)、设备类型信息、api接口返回的响应信息、应用程序前台的页面信息。

页面信息包含用户在应用程序上的行为记录的标记，如用户在页面进行点击tab操作，需要在记录页面信息时，用箭头标记出用户的具体点击位置。为保证不影响应用程序运行性能，只保留最新的20个接口和10个页面信息。

异常捕获装置在应用运行过程中检测崩溃情况，出现崩溃时，捕获到此异常，将记录装置记录的最新信息通知给异常信息持久化装置。

异常信息持久化装置接收到崩溃信息后，将运行记录装置记录的三部分信息打包发送到服务器中，由服务器后端记录保存到数据库中存储，并同时邮件发送给应用负责人。

如图3所示，该终端设备6可以包括：处理器601、存储介质602和总线603，存储介质602存储有处理器601可执行的机器可读指令，当终端设备运行时，处理器601与存储介质602之间通过总线603通信，处理器601 执行机器可读指令，以执行时执行如前述实施例中所述的深度学习模型训练方法的步骤。具体实现方式和技术效果类似，在此不再赘述。

为了便于说明，在上述终端设备中仅描述了一个处理器。然而，应当注意，一些实施例中，本发明中的终端设备还可以包括多个处理器，因此本发明中描述的一个处理器执行的步骤也可以由多个处理器联合执行或单独执行。

以上仅为本发明的具体实施方式，但本发明的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本发明揭露的技术范围内，可轻易想到变化或替换，都应涵盖在本发明的保护范围之内。因此，本发明的保护范围应以权利要求的保护范围为准。

Claims (8)

1.一种应用程序崩溃类问题的记录及定位方法，其特征在于，包括以下步骤：

S1：用户启动应用程序，运行记录装置开始持续工作，记录应用程序的api接口日志和应用程序的前台页面信息；

S2：异常捕获装置持续运行，检测当前是否发生崩溃情况，如果是，进入S3，如果否进入S2；

S3：异常信息持久化装置将运行记录装置记录的四部分内容打包发送到系统后端服务中；

S4：系统后端服务将上报的异常信息存储到数据库中，并发送邮件通知应用负责人。

2.根据权利要求1所述的方法，其特征在于，在上述S1步骤中记录前台页面信息时，当刚进入页面需要截取应用程序界面的图形，用户在页面上进行操作，再次截取界面上的图形，并用箭头标记出用户具体点击的位置坐标。

3.根据权利要求1所述的方法，其特征在于，在上述S1步骤中记录应用程序的api接口日志时和前台页面信息时，保留最新的20个接口和10个页面信息。

4.根据权利要求1所述的方法，其特征在于，在上述S4步骤中系统后端发送邮件通知应用负责人等相关人员时也包括即时通讯形式。

5.一种应用程序崩溃类问题的记录及定位系统，其特征在于，包括运行记录装置，异常捕获装置，异常信息持久化装置；

运行记录装置，用于应用程序运行过程中，时刻记录四部分信息：用户的账户信息、设备类型信息、api接口返回的响应信息、应用程序前台的页面信息；

异常捕获装置，用于在应用运行过程中检测崩溃情况，出现崩溃时，捕获到此异常，将记录装置记录的最新信息通知给异常信息持久化装置；

异常信息持久化装置，用于接收到崩溃信息后，将运行记录装置记录的三部分信息打包发送到服务器中，由服务器后端记录保存到数据库中存储，并同时邮件发送给应用负责人。

6.根据权利要求5所述的系统，其特征在于，页面信息包含用户在应用程序上的行为记录的标记。

7.一种终端设备，其特征在于，包括：处理器、存储介质和总线，所述存储介质存储有所述处理器可执行的机器可读指令，当所述终端设备运行时，所述处理器与所述存储介质之间通过总线通信，所述处理器执行所述机器可读指令，以执行时执行如权利要求1至5任一项所述的方法的步骤。

8.一种存储介质，其特征在于，所述存储介质上存储有计算机程序，所述计算机程序被处理器运行时执行如权利要求1至5任一项所述的方法的步骤。

Images