CN115934390A - 处理应用程序崩溃的方法、***和运行应用程序的设备 - Google Patents

Abstract

本发明涉及一种用于处理应用程序崩溃的方法，其包括：监测是否发生应用程序崩溃；如果监测到崩溃，则获取应用程序的崩溃信息；判断在应用程序崩溃处理策略的配置表中是否存在所述应用程序的崩溃信息，该配置表包括所存储的应用程序的崩溃信息与崩溃处理策略之间的映射关系；如果存在应用程序的崩溃信息，则基于配置表中与应用程序的崩溃信息相对应的崩溃处理策略进行崩溃处理。本发明还涉及一种用于运行应用程序的设备，一种用于处理应用程序崩溃的***和一种计算机程序产品。根据本发明，能够根据应用程序的崩溃信息自动地匹配并执行崩溃处理策略，而无需用户的参与，由此提高了应用程序崩溃处理的效率和应用程序运行的稳定性。

Description

处理应用程序崩溃的方法、***和运行应用程序的设备

技术领域

本发明涉及计算机技术领域，尤其涉及一种用于处理应用程序崩溃的方法，一种用于运行应用程序的设备，一种用于处理应用程序崩溃的***以及一种用于执行所述方法的步骤的计算机程序产品。

背景技术

越来越多的应用程序(App)被开发和部署在智能终端(例如电脑、移动终端、智能联网汽车的车机***等)上。例如，随着智能联网汽车的发展，在用户的移动终端和/或车辆(车机)上开发和部署了越来越多的应用程序用以提供或支持与车辆相关的各种功能或服务。在这些应用程序的使用过程中，可能会由于不同的原因导致应用程序发生崩溃。这给应用程序的稳定性带来了挑战。

现有技术中提出的应用程序崩溃的解决方案主要通过某种单一或固定的方式来处理应用程序崩溃：例如，在监测到程序崩溃后，清除用户数据以进行恢复或重启。然而，单一或固定的处理方式(例如清除用户数据并重启应用程序)并不能灵活有效地解决不同种类的应用程序崩溃问题，具有很大的应用局限性，尤其是在反复地清除用户数据并重新启动程序、甚至卸载重装后仍无法消除程序崩溃的情况下。

因此，如何灵活有效地处理各种应用程序崩溃问题成为目前需要解决的技术难题。

发明内容

本发明的目的在于提供一种用于处理应用程序崩溃的方法，一种用于运行应用程序的设备，一种用于处理应用程序崩溃的***以及一种用于执行所述方法的步骤的计算机程序产品，以至少部分地解决现有技术中的问题。本发明基于以下基本构思：在客户端设备本地存储的配置表中预先存储有在应用程序崩溃处理策略的配置表，通过持续地监测应用程序崩溃的发生，在监测到应用程序崩溃时选择并执行与所发生的应用程序崩溃相匹配的崩溃处理策略。根据本发明的某些实施例，能够根据应用程序的崩溃信息自动地匹配并执行崩溃处理策略，而无需用户的参与，由此提高了应用程序崩溃处理的效率和应用程序运行的稳定性。

根据本发明的第一方面，提供了一种处理应用程序崩溃的方法，所述方法包括：

监测是否发生应用程序崩溃；

如果监测到发生应用程序崩溃，则获取所述应用程序的崩溃信息；

判断在应用程序崩溃处理策略的配置表中是否存在所述应用程序的崩溃信息，其中，所述配置表包括所存储的应用程序的崩溃信息与崩溃处理策略之间的映射关系；和

如果在所述配置表中存在所述应用程序的崩溃信息，则基于所述配置表中与所述应用程序的崩溃信息相对应的崩溃处理策略进行崩溃处理。

根据本发明的可选实施例，尤其可以不基于用户的输入，自动地基于所述配置表中与所述应用程序的崩溃信息相对应的崩溃处理策略执行所述崩溃处理。

根据本发明的可选实施例，所述应用程序崩溃处理策略的配置表可以存储在运行所述应用程序的客户端设备本地，并可选地可以通过后端服务器远程更新所述配置表。

根据本发明的可选实施例，在应用程序启动后和/或当存储在客户端本地存储模块中的应用程序崩溃处理策略的配置表中不存在所述应用程序的崩溃信息时，可以查询后端服务器是否有更新的应用程序崩溃处理策略的配置表。如果查询到后端服务器有更新的应用程序崩溃处理策略的配置表，则可以从后端服务器下载更新的配置表并更新应用程序所在客户端设备本地的配置表。通过这种方式可以确保参与所述匹配的是最新的配置表，从而避免因未及时更新配置表导致的崩溃处理策略匹配失败。

根据本发明的可选实施例，所述应用程序的崩溃信息例如可以包括应用程序崩溃的类型信息和/或标识信息，其中，所述类型信息例如包括崩溃类型，所述标识信息例如包括全类名，方法名和/或文件名，其中，所述全类名包括类名和/或包名。

根据本发明的可选实施例，所述方法还可以包括：

在对所述应用程序崩溃进行崩溃处理后，监测在预设的时间段内是否发生预设次数的应用程序崩溃；和

如果在预设的时间段内发生预设次数的应用程序崩溃，则停止执行所述崩溃处理并报告给后端服务器。

根据本发明的可选实施例，所获取的应用程序的崩溃信息与所述配置表中的应用程序的崩溃信息的匹配可以通过模糊判断来执行，其中，所述模糊判断基于的判断依据参数能够根据所获取的应用程序的崩溃信息和/或所述配置表中的应用程序的崩溃信息进行动态地调整、尤其是添加和/或移除，由此提高了所述匹配的灵活性和可靠性。

根据本发明的可选实施例，所述崩溃处理策略例如可以包括以下策略中的一个或多个：

不做任何操作；

显示错误页面并引导用户清理用户数据；

显示升级页面并引导用户进行应用程序升级；

显示页面以展示推荐的解决方案；

执行自动重启；

执行自动重启并清理本地用户数据；

显示页面以展示应用崩溃报告；

退出并重新登录应用程序；

在不重启应用程序的情况下重新初始化软件开发工具包；

第一降级策略和与所述第一降级策略对应的第一升级策略；和

第二降级策略和与所述第二降级策略对应的第二升级策略。

根据本发明的可选实施例，可以基于所述应用程序的崩溃信息确定所述应用程序的发生崩溃的子功能，并基于所述第一降级策略关闭所述应用程序的发生崩溃的子功能，直至重新启动所述应用程序和/或停止执行所述第一降级策略后，基于所述第一升级策略重新开启所关闭的子功能。通过关闭所述应用程序的发生崩溃的子功能对应用程序进行降级处理，由此用户可以继续使用未发生崩溃的其他子功能。

根据本发明的可选实施例，判断在预设时间段内出现相同类型的应用程序崩溃的次数是否超过预设阈值；如果在预设时间段内出现相同类型的应用程序崩溃的次数超过预设阈值，则基于所述应用程序的崩溃信息判断所确定的子功能是否属于预给定的子功能；如果所确定的子功能属于预给定的子功能，则基于所述第二降级策略关闭所述应用程序的发生崩溃的子功能，直至所述应用程序完成升级或后端服务器提供的后端服务完成更新后，基于所述第二升级策略重新开启所关闭的子功能。在此，对所述应用程序的各子功能进行分级，并在监测到频繁发生重要子功能的崩溃时关闭该重要子功能，直至所述应用程序完成升级或后端服务器提供的后端服务完成更新，而用户可以继续使用未发生崩溃的其他重要子功能。

根据本发明的可选实施例，所述方法还可以包括：基于客户端的参数从后端服务器获取适配于所述参数的应用程序崩溃处理策略的配置表，并对存储在客户端本地的配置表进行同步更新；其中，所述客户端的参数例如包括所述客户端的操作***类型、操作***版本、应用程序版本和/或设备型号等。

根据本发明的可选实施例，所述方法还可以包括：

基于监测到的应用程序崩溃的线程信息判断所述应用程序崩溃是主线程崩溃还是子线程崩溃；

如果所述应用程序崩溃是子线程崩溃，则记录所述子线程的崩溃信息；

如果所述应用程序是主线程崩溃，则对所述主线程崩溃进行所述崩溃处理。

根据本发明的第二方面，提供了一种用于运行应用程序的设备。所述设备可以包括以下构件：

应用程序崩溃监测模块，其被配置为监测应用程序崩溃的发生，以及获取应用程序的崩溃信息；

应用程序崩溃保护管理模块，其被配置为基于所述应用程序的崩溃信息和应用程序崩溃处理策略的配置表启用和/或停用相应的应用程序崩溃处理功能，以及启用和/或停用所述配置表的远程更新功能；

崩溃处理模块，其被配置为基于与所获取的应用程序程序的崩溃信息相对应的崩溃处理策略对所述应用程序崩溃进行处理；和

客户端本地存储模块，其被配置为在本地存储所述配置表，所述配置表包括应用程序的崩溃信息与崩溃处理策略之间的映射关系。

根据本发明的可选实施例，所述崩溃处理模块可以被配置为不基于用户的输入，自动地基于所述配置表中与所述应用程序的崩溃信息相对应的崩溃处理策略执行所述崩溃处理。

根据本发明的可选实施例，在所述客户端本地存储模块中可以存储有所述应用程序崩溃处理策略的配置表，并可选地可以通过后端服务器远程更新存储的配置表。

根据本发明的可选实施例，所述应用程序崩溃保护管理模块可以被配置为在应用程序启动后和/或当存储在所述客户端本地存储模块中的应用程序崩溃处理策略的配置表中不存在所述应用程序的崩溃信息时，查询后端服务器是否有更新的应用程序崩溃处理策略的配置表；如果查询后端服务器有更新的应用程序崩溃处理策略的配置表，则从后端服务器下载更新的配置表并更新所述客户端本地存储模块中存储的配置表。

根据本发明的可选实施例，所述应用程序的崩溃信息可以包括应用程序崩溃的类型信息和/或标识信息，其中，所述类型信息例如包括崩溃类型，所述标识信息包括全类名，方法名和/或文件名，其中，所述全类名例如包括类名和/或包名。

根据本发明的可选实施例，所述应用程序崩溃保护管理模块可以被配置为监测在预设的时间段内是否发生预设次数的应用程序崩溃，并在预设的时间段内发生预设次数的应用程序崩溃时停止执行所述崩溃处理并报告给后端服务器。

根据本发明的可选实施例，所述应用程序崩溃保护管理模块可以被配置为，通过模糊判断来执行所获取的应用程序的崩溃信息与所述配置表中的应用程序的崩溃信息的匹配，其中，所述模糊判断基于的判断依据参数能够根据所获取的应用程序的崩溃信息和/或所述配置表中的应用程序的崩溃信息进行动态地调整、尤其是添加和/或移除，由此提高了所述匹配的灵活性和可靠性。

根据本发明的可选实施例，所述崩溃处理策略可以包括以下策略中的一个或多个：

不做任何操作；

显示错误页面并引导用户清理用户数据；

显示升级页面并引导用户进行应用程序升级；

显示页面以展示推荐的解决方案；

执行自动重启；

执行自动重启并清理本地用户数据；

显示页面以展示应用崩溃报告；

退出并重新登录应用程序；

在不重启应用程序的情况下重新初始化软件开发工具包；

第一降级策略和与所述第一降级策略对应的第一升级策略；和

第二降级策略和与所述第二降级策略对应的第二升级策略。

根据本发明的可选实施例，所述崩溃处理模块可以被配置为，基于所述应用程序的崩溃信息确定所述应用程序的发生崩溃的子功能，并基于所述第一降级策略关闭所述应用程序的发生崩溃的子功能，直至重新启动所述应用程序和/或停止执行所述第一降级策略后，基于所述第一升级策略重新开启所关闭的子功能。

根据本发明的可选实施例，所述崩溃处理模块可以被配置为，判断在预设时间段内出现相同类型的应用程序崩溃的次数是否超过预设阈值；如果在预设时间段内出现相同类型的应用程序崩溃的次数超过预设阈值，则基于所述应用程序的崩溃信息判断所确定的子功能是否属于预给定的子功能；如果所确定的子功能属于预给定的子功能，则基于所述第二降级策略关闭所述应用程序的发生崩溃的子功能，直至所述应用程序完成升级或后端服务器提供的后端服务完成更新后，基于所述第二升级策略重新开启所关闭的子功能。

根据本发明的可选实施例，所述崩溃处理模块可以被配置为，基于客户端的参数从后端服务器获取适配于所述参数的应用程序崩溃处理策略的配置表，并对存储在客户端本地的配置表进行同步更新；其中，所述客户端的参数例如包括所述客户端的操作***类型、操作***版本、应用程序版本和/或设备型号等。

根据本发明的可选实施例，应用程序崩溃监测模块基于监测到的应用程序崩溃的线程信息判断所述应用程序崩溃是主线程崩溃还是子线程崩溃；如果所述应用程序是主线程崩溃，则对所述主线程崩溃进行所述崩溃处理。

根据本发明的第三方面，提供了一种用于处理应用程序崩溃的***，所述***用于执行根据本发明的方法。所述***可以包括以下构件：

应用程序崩溃监测模块，其被配置为监测应用程序崩溃的发生，以及获取应用程序的崩溃信息；

应用程序崩溃保护管理模块，其被配置为基于所述应用程序的崩溃信息和应用程序崩溃处理策略的配置表启用和/或停用相应的应用程序崩溃处理功能，以及启用和/或停用所述配置表的远程更新功能；

崩溃处理模块，其被配置为基于与所获取的应用程序程序的崩溃信息相对应的崩溃处理策略对所述应用程序崩溃进行处理；

客户端本地存储模块，其被配置为在运行所述应用程序的客户端本地存储所述配置表，所述配置表包括程序崩溃的信息与降级策略之间的映射关系；和

后端服务器，其被配置为能够远程更新所述客户端本地存储模块中的所述配置表。

根据本发明的第四方面，提供了一种计算机程序产品、例如计算机可读的程序载体，包含计算机程序指令，所述计算机程序指令被处理器执行时至少辅助地实现根据本发明的方法的步骤。

附图说明

下面通过参照附图更详细地描述本发明可以更好地理解本发明的原理、特点和优点。附图示出：

图1示出根据本发明的一个示例性实施例的用于处理应用程序崩溃的方法的工作流程图；

图2示出根据本发明的另一示例性实施例的用于处理应用程序崩溃的方法的工作流程图；

图3示出根据本发明的另一示例性实施例的用于处理应用程序崩溃的方法的工作流程图；

图4示出根据本发明的另一示例性实施例的用于处理应用程序崩溃的方法的工作流程图；

图5示出根据本发明的另一示例性实施例的用于处理应用程序崩溃的方法的工作流程图；

图6示出根据本发明的另一示例性实施例的用于处理应用程序崩溃的方法的工作流程图；

图7示出根据本发明的另一示例性实施例的用于处理应用程序崩溃的方法的工作流程图；

图8示出根据本发明的一个示例性实施例的用于运行应用程序的设备的框图；

图9示出根据本发明的一个示例性实施例的用于处理应用程序崩溃的***的框图；和

图10示出根据本发明的一个示例性实施例的用于阐述程序崩溃处理过程的时序图。

具体实施方式

为了使本发明所要解决的技术问题、技术方案以及有益的技术效果更加清楚明白，以下将结合附图以及多个示例性实施例对本发明进行进一步详细说明。应当理解，此处所描述的具体实施例仅用于解释本发明，而不是用于限定本发明的保护范围。

图1示出根据本发明的示例性实施例的用于处理应用程序崩溃的方法的工作流程图。

所述方法可以包括步骤S1至S4。在步骤S1中，监测是否发生应用程序崩溃。在本发明的当前实施例中，所述应用程序可以包括一个主线程程序。可选地还可以包括至少一个子线程程序。在此，可以通过调用Thread.setDefaultUncaughtExceptionHandler()函数监测主线程程序和/或子线程程序的崩溃发生，并在应用程序发生主线程崩溃和/或子线程崩溃时捕获到该崩溃。

如果监测到发生应用程序崩溃，则在步骤S2中获取所述应用程序的崩溃信息。在这个主线程程序中，可以通过应用程序崩溃监测模块11执行一个轮询任务，其例如通过调用Looper.loop()函数实现且可以循环地执行，由此实现持续地监测主线程程序的运行状态。在监测到主线程程序发生崩溃后，可以及时地调用try catch()函数，通过该函数可以捕捉该主线程崩溃的崩溃信息。在此，应用程序的崩溃信息例如可以包括应用程序崩溃的类型信息，所述类型信息例如包括崩溃类型；应用程序的崩溃信息还例如可以包括应用程序崩溃的标识信息，所述标识信息例如包括全类名，方法名和/或文件名等。在此，通过方法名可以指示用于执行应用程序的各子功能的程序区段。全类名可以包括类名和/或包名，通过所述类名和/或包名可以确定应用程序崩溃影响的子功能。

示例性地，可以通过应用程序崩溃监测模块11提取发生应用程序崩溃的主线程程序的堆栈信息，并借助解析单元16将所述堆栈信息解析成应用程序的崩溃信息B，所述崩溃信息B被传递给应用程序崩溃保护管理模块12，如图10的时序图所示的那样。

在步骤S3中，判断在应用程序崩溃处理策略的配置表中是否存在所述程序的崩溃信息B，其中，所述配置表可以包括所存储的应用程序的崩溃信息A与崩溃处理策略之间的映射关系。在此，所述应用程序崩溃处理策略的配置表可以存储在运行所述应用程序的客户端设备本地，所述应用程序崩溃保护管理模块12可以从客户端本地存储模块14获取本地存储的配置表，并借助解析单元16将所述配置表解析成配置表所包含的应用程序的崩溃信息A。通过遍历所述配置表中的应用程序的崩溃信息A，将所获取的应用程序的崩溃信息B与配置表中的应用程序的崩溃信息A进行匹配，由此判断在所述配置表中是否存在所获取的应用程序的崩溃信息B，其判断结果例如可以由判断真值来表示。

如表1示例性地示出的那样，所述配置表可以包括以下崩溃处理策略中的一种或多种：

策略序号	崩溃处理策略
		1	不做任何操作
2	显示错误页面并引导用户清理用户数据
		3	显示升级页面并引导用户进行应用程序升级
4	显示页面以展示推荐的解决方案
		5	执行自动重启
6	执行自动重启并清理本地用户数据
		7	显示页面以展示应用崩溃报告
8	退出并重新登录应用程序
		9	在不重启应用程序的情况下重新初始化软件开发工具包
10	第一降级策略和与第一降级策略对应的第一升级策略
		11	第二降级策略和与第二降级策略对应的第二升级策略

表1示出配置表所包含的崩溃处理策略

在本发明可选的实施例中，所获取的应用程序的崩溃信息B与所述配置表中的应用程序的崩溃信息A的匹配可以通过模糊判断来执行。在此，所述模糊判断的匹配依据参数可以包括崩溃类型、全类名、方法名和文件名中的一个或多个。以下示例性地示出了用于执行所述匹配过程的程序代码。在此，所述匹配依据参数包括崩溃类型(exceptionType)，类名(className)和文件名(fileName)，基于所述匹配依据参数通过模糊判断可以求取关于配置表中是否存在匹配的崩溃处理策略的真值信息(isNativeMethod)，并在真值信息为真的情况下获取所匹配的策略序号。

此外，所述匹配依据参数可以根据所获取的应用程序的崩溃信息B和/或所述配置表中的应用程序的崩溃信息A进行动态地调整、尤其是添加和/或移除，由此提高了所述匹配的灵活性和可靠性。在所述匹配依据参数中例如还可以添加方法名，借助所述方法名可以指示出现崩溃的程序区段。

如果在所述配置表中存在所述应用程序的崩溃信息B(即所述判断真值信息为真)，则在步骤S4中基于所述配置表中与所述应用程序的崩溃信息B相对应的崩溃处理策略进行崩溃处理。在此，可以不基于用户的输入而自动地基于所述配置表中与所述应用程序的崩溃信息B相对应的崩溃处理策略执行所述崩溃处理。相比之下，在现有技术中需要通知用户关于应用程序崩溃的消息，并由用户自行选择适配的崩溃处理策略，这不仅降低了应用程序崩溃的处理效率，而且需要用户具有一定的处理经验。

在此，表1所示的崩溃处理策略中的大部分(例如崩溃处理策略2至6以及8、9等)都是通过清理用户数据、重新登录应用程序、自动重启应用程序、重新初始化软件开发工具包等方式处理应用程序崩溃。这些应用程序崩溃通常出现在启动经更新的应用程序的过程中，在这种应用程序崩溃下用户无法使用该应用程序中的任何子功能，而在执行这样的崩溃处理策略后通过就可以正常使用该应用程序。

示例性地，应用程序中的部分子功能出现异常、尤其是展示异常，这可能是由于应用程序崩溃导致该子功能对应的程序代码未被执行而导致的。如果该异常的子功能对应用程序的影响较小，例如页面中与异常子功能相关的内容显示异常，用户只是不能够看到该部分内容，而页面中的其他内容仍显示正常，尤其是该应用程序的其他子功能仍能够正常投入使用，则可以采取崩溃处理策略1不做任何操作。

例如还可以借助崩溃处理策略7显示页面以展示崩溃报告，所述崩溃报告可以通过电子邮件发送给开发和测试人员以进行分析和报告。

所述崩溃处理策略还包括降级策略和与该降级策略对应的升级策略。在本发明的意义中，“降级”可以理解如下：在应用程序出现异常时，为了控制异常的影响范围，关闭应用程序中的部分(例如非重要的)子功能，由此保证应用程序的重要子功能正常运行。所述应用程序的子功能可以基于子功能的优先级和/或依赖性进行分级，例如如果一个子功能具有高优先级和/或与其他子功能的强依赖关系，则可以将该子功能划分为重要子功能，例如远程操控车辆的功能。

在本发明的另一可选实施例中，对于第一降级策略和与所述第一降级策略对应的第一升级策略，所述步骤S4可以包括步骤S411至S413，如图2所示的那样。在步骤S411中，基于所述应用程序的崩溃信息B确定所述应用程序的发生崩溃的子功能。以下示出了根据本发明的另一可选实施例的程序代码，可以根据应用程序的崩溃信息B中的方法名(methodName)确定应用程序中出现崩溃的程序区段，并根据应用程序的崩溃信息B中的类名(fileName)确定该崩溃影响的子功能，然后将该子功能对应的开关(toggle)名称下发给客户端，通过该开关的状态可以设置该功能的开启和/或关闭。

{"data":[{"exceptionType":"java.lang.RuntimeException",

"className":"io_realm_internal_OsSharedRealm",

"fileName":"io_realm_internal_OsSharedRealm.cpp",

"isNativeMethod":true,

"methodName":"nativeGetSharedRealm",

"downgradeStrategy":10,

"toggle":["ris-mystar-camera"],

"matchRules":["exceptionType","fileName","isNativeMethod",

"methodName"]}]}

在步骤S412中，基于所述第一降级策略可以关闭所述应用程序的发生崩溃的子功能。在本发明的当前实施例中，基于所解析的应用程序的崩溃信息可以确定要采取崩溃处理策略10，将该该子功能对应的开关状态设置为关闭状态，使得在应用程序的显示页面中不再展示该子功能的用户入口，由此关闭所述应用程序的发生崩溃的子功能，而用户可以继续使用未发生崩溃的其他子功能。

直至重新启动所述应用程序和/或停止执行所述第一降级策略后，可以在步骤S413中基于与所述第一降级策略对应的第一升级策略重新开启所关闭的子功能，从而该应用程序的所有子功能恢复正常。

在本发明的另一可选实施例中，对于第二降级策略和与所述第二降级策略对应的第二升级策略，所述步骤S4可以包括步骤S421至S425，如图3所示的那样。在步骤S421中，判断在预设时间段内出现相同类型的应用程序崩溃的次数是否超过预设阈值。在此，基于所述应用程序的崩溃信息B可以确定应用程序崩溃类型，并检索在预设时间段内出现该应用程序崩溃类型的次数。如果未检索到该应用程序崩溃类型，则可以创建关于该应用程序崩溃类型的崩溃记录，从而可以在下一出现该类型的应用程序崩溃时查询到该崩溃记录。

如果在预设时间段内出现相同类型的应用程序崩溃的次数超过预设阈值，这意味着该类型的应用程序崩溃频繁地出现，则在步骤S422中基于所述应用程序的崩溃信息B可以确定所述应用程序的发生崩溃的子功能。同样地，可以根据应用程序的崩溃信息B中的方法名确定应用程序中出现崩溃的程序区段，并根据应用程序的崩溃信息B中的类名和/或包名确定该崩溃影响的子功能，然后将该子功能对应的开关名称下发给客户端。

在确定所述子功能后，在步骤S423中判断所确定的子功能是否属于预给定的子功能，所述预给定的子功能例如包括远程操控车辆的功能。如果所确定的子功能属于预给定的子功能，则可以确定要采取崩溃处理策略11，那么在步骤S424中基于所述第二降级策略关闭所述应用程序的发生崩溃的子功能。在此，可以将该子功能对应的开关状态设置为关闭状态，从而关闭所述应用程序的发生崩溃的重要子功能(例如远程操控车辆的功能)，而用户可以继续使用未发生崩溃的其他重要子功能。在关闭该子功能的同时，可选地还可以通过后端服务器15向用户发送关于当前子功能不可用的提示信息。

直至所述应用程序完成升级或后端服务器15提供的后端服务完成更新后，在步骤S425中基于与所述第二降级策略对应的第二升级策略重新开启所关闭的子功能。这与直至重新启动所述应用程序和/或停止执行所述第一降级策略后就执行第一升级策略存在差异，这是因为该类型的应用程序崩溃频繁地出现，尤其是在重新启动应用程序后可能继续出现该类型的应用程序崩溃，因此在通过应用程序的升级或后端服务的更新完成应用程序的修复后才执行第二升级策略。

可以理解的是，所述崩溃处理策略可以根据需要进行调整，而不局限于上述列举的策略。

根据本发明的当前实施例，能够根据应用程序的崩溃信息自动地匹配并执行崩溃处理策略，而无需用户的参与，由此提高了应用程序崩溃处理的效率，并尽可能地确保了应用程序的未发生崩溃的子功能仍可供使用。

图4示出了根据本发明的另一示例性实施例的用于处理应用程序崩溃的方法的工作流程图。以下仅阐述与图1中所示的实施例的区别，而相同的步骤为了简洁起见而不再重复描述。

所述方法还可以包括步骤S110和S11。在步骤S110中，判断所述应用程序崩溃处理的功能是否开启。如果所述应用程序崩溃处理的功能开启，则在步骤S11中通过后端服务器15远程更新所述应用程序崩溃处理策略的配置表。在本发明的另一可选实施例中，在后端服务器15中存储有可根据实际需求实时调整的配置表，基于客户端的参数可以从后端服务器15获取适配于所述参数的应用程序崩溃处理策略的配置表，并对存储在客户端本地的配置表进行同步更新，其中，所述客户端的参数例如可以包括所述客户端的操作***类型、操作***版本、应用程序版本和/或设备型号等。可以理解的是，客户端的不同的操作***类型、操作***版本、应用程序版本和/或设备型号所需的配置表信息可能彼此不同。

需要说明的是，可以在启动应用程序后将存储在本地的配置表同步更新到最新状态，还可以在步骤S3之后执行所述同步更新。如图5所示的那样，所述方法还可以包括步骤S10和S11。如果在步骤S3中判断出存储在客户端本地存储模块中的应用程序崩溃处理策略的配置表中不存在所述应用程序的崩溃信息B，在步骤S10中查询后端服务器15是否有更新的应用程序崩溃处理策略的配置表。如果查询到后端服务器15有更新的应用程序崩溃处理策略的配置表，则在步骤S11中从后端服务器15下载更新的配置表并更新应用程序所在客户端设备本地的配置表。通过这种方式可以确保参与所述匹配的是最新的配置表，从而避免因未及时更新配置表导致的崩溃处理策略匹配失败。

图6示出了根据本发明的另一示例性实施例的用于处理应用程序崩溃的方法的工作流程图。以下仅阐述与图1中所示的实施例的区别，而相同的步骤为了简洁起见而不再重复描述。

所述方法还可以包括步骤S5和S6。在步骤S5中，在对所述应用程序崩溃进行崩溃处理后，监测在预设的时间段内是否发生预设次数的应用程序崩溃。如果在预设的时间段内发生预设次数的应用程序崩溃，则在步骤S6中停止执行所述崩溃处理并报告给后端服务器15。在本发明的另一可选实施例中，例如在一分钟的时间段内发生三次应用程序崩溃，则意味着该应用程序崩溃难以通过当前的配置表中的崩溃处理策略来修复，因此可以向后端服务器15报告，从而后端的开发人员和/或维护人员可以根据所述报告的内容向所述配置表添加适配于该应用程序崩溃的崩溃处理策略。通过这种方式可以向后端人员及时地报告无法解决的应用程序崩溃，从而提高崩溃处理策略的适用性。

图7示出了根据本发明的另一示例性实施例的用于处理应用程序崩溃的方法的工作流程图。以下仅阐述与图1中所示的实施例的区别，而相同的步骤为了简洁起见而不再重复描述。

所述方法还可以包括步骤S12和S13。在步骤S12中，基于监测到的应用程序崩溃的线程信息判断所述应用程序崩溃是主线程崩溃还是子线程崩溃。如果所述应用程序崩溃是子线程崩溃，则在步骤S13中记录所述子线程崩溃的崩溃信息，基于所述崩溃信息例如可以求取埋点和日志信息，而不对所述子线程程序进行崩溃处理；如果所述应用程序是主线程崩溃，则进入步骤S2对所述主线程崩溃进行根据本发明的崩溃处理。通过同时使用两种或更多种的应用程序崩溃监测方式可以有效地提高应用程序崩溃监测的可靠性，并记录子线程程序中出现的崩溃。

另外，应注意到，在此描述的步骤序号并不必然代表先后顺序，而仅仅是一种附图标记，根据具体情况，顺序可以更改，只要能够实现本发明的技术目的即可。

图8示出了根据本发明的一个示例性实施例的用于运行应用程序的设备的框图。

如图8所示的那样，所述设备1可以包括以下构件：应用程序崩溃监测模块11，其被配置为监测应用程序崩溃的发生，以及获取应用程序的崩溃信息；应用程序崩溃保护管理模块12，其被配置为基于所述应用程序的崩溃信息和应用程序崩溃处理策略的配置表启用和/或停用相应的应用程序崩溃处理功能，以及启用和/或停用所述配置表的远程更新功能；崩溃处理模块13，其被配置为基于与所获取的应用程序程序的崩溃信息相对应的崩溃处理策略对所述应用程序崩溃进行处理；和客户端本地存储模块14，其被配置为在本地存储所述配置表，所述配置表包括应用程序的崩溃信息A与崩溃处理策略之间的映射关系。可选地，所述设备1还包括解析单元16，其被配置用于将发生崩溃的应用程序的堆栈信息解析成应用程序的崩溃信息B和/或将所述配置表解析成配置表所包含的应用程序的崩溃信息A。

图9示出了根据本发明的一个示例性实施例的用于处理应用程序崩溃的***的框图。所述***10可以包括所述设备1和后端服务器15，所述后端服务器被配置为能够远程更新所述客户端本地存储模块中的所述配置表。在此，所述设备1同样可以包括应用程序崩溃监测模块11、应用程序崩溃保护管理模块12、崩溃处理模块13和客户端本地存储模块14，如图8所示的实施例那样，在此不再进行重复描述。

以下结合图10所示的根据本发明的一个示例性实施例的用于阐述应用程序崩溃处理过程的时序图。

在启动应用程序后，在步骤S1中监测是否发生应用程序崩溃，同时在步骤S110中判断所述应用程序崩溃处理的功能是否开启。如果所述应用程序崩溃处理的功能开启，则应用程序崩溃保护管理模块12可以向应用程序崩溃监测模块11发送开启信号。在接收到该开启信号后，应用程序崩溃监测模块11可以监测到应用程序崩溃的发生，以及执行步骤S2用以获取应用程序的崩溃信息B，并将所获取的崩溃信息发送给应用程序崩溃保护管理模块12。在应用程序崩溃保护管理模块12接收到应用程序的崩溃信息B后，可以在步骤S3中判断在存储在客户端本地存储模块14中的应用程序崩溃处理策略的配置表中是否存在所述应用程序的崩溃信息B，并在存在所述崩溃信息B时由崩溃处理模块13执行步骤S4，即基于所述配置表中与所述应用程序的崩溃信息B相对应的崩溃处理策略进行崩溃处理。

同时，如果在步骤S110中判断出所述应用程序崩溃处理的功能开启，则在步骤S11中通过后端服务器15远程更新所述应用程序崩溃处理策略的配置表。在此，可以向应用程序崩溃保护管理模块12发送远程更新功能的启用信号，所述应用程序崩溃保护管理模块12在接收到所述启用信号后基于客户端的参数从后端服务器15获取适配于所述参数的应用程序崩溃处理策略的配置表，并对存储在客户端本地存储模块14的配置表进行同步更新，其中，所述客户端的参数例如可以包括所述客户端的操作***类型、操作***版本、应用程序版本和/或设备型号等。解析单元16可以将经更新的配置表解析成配置表所包含的应用程序的崩溃信息A，并将所解析的崩溃信息A发送给应用程序崩溃保护管理模块12，由此可以在应用程序崩溃保护管理模块12中对所述应用程序的崩溃信息B和所解析的崩溃信息A进行匹配。

尽管在此详细描述了本发明的特定实施方式，但它们仅仅是为了解释的目的而给出的，而不应认为它们对本发明的范围构成限制。在不偏离本发明的核心和范围的前提下，可以提出各种替换方案和修改方案。

Claims (26)

1.一种处理应用程序崩溃的方法，所述方法包括：

监测是否发生应用程序崩溃；

如果监测到发生应用程序崩溃，则获取所述应用程序的崩溃信息(B)；

判断在应用程序崩溃处理策略的配置表中是否存在所述应用程序的崩溃信息(B)，其中，所述配置表包括所存储的应用程序的崩溃信息(A)与崩溃处理策略之间的映射关系；和

如果在所述配置表中存在所述应用程序的崩溃信息(B)，则基于所述配置表中与所述应用程序的崩溃信息(B)相对应的崩溃处理策略进行崩溃处理。

2.根据权利要求1所述的方法，其特征在于，不基于用户的输入，自动地基于所述配置表中与所述应用程序的崩溃信息(B)相对应的崩溃处理策略执行所述崩溃处理。

3.根据权利要求1或2所述的方法，其特征在于，所述应用程序崩溃处理策略的配置表存储在运行所述应用程序的客户端设备本地，并通过后端服务器(15)远程更新所述配置表。

4.根据权利要求1至3中任一项所述的方法，其特征在于，在应用程序启动后和/或当在存储在客户端本地存储模块中的应用程序崩溃处理策略的配置表中不存在所述应用程序的崩溃信息(B)时，查询后端服务器(15)是否有更新的应用程序崩溃处理策略的配置表；如果有更新，则从后端服务器(15)下载更新的配置表并更新应用程序所在客户端设备本地的配置表。

5.根据权利要求1至4中任一项所述的方法，其特征在于，所述应用程序的崩溃信息(A，B)包括应用程序崩溃的类型信息和/或标识信息，其中，所述类型信息包括崩溃类型，所述标识信息包括全类名，方法名和/或文件名，其中，所述全类名包括类名和/或包名。

6.根据权利要求1至5中任一项所述的方法，其特征在于，所述方法还包括：

在对所述应用程序崩溃进行崩溃处理后，监测在预设的时间段内是否发生预设次数的应用程序崩溃；和

如果在预设的时间段内发生预设次数的应用程序崩溃，则停止执行所述崩溃处理并报告给后端服务器(15)。

7.根据权利要求1至6中任一项所述的方法，其特征在于，所获取的应用程序的崩溃信息(B)与所述配置表中的应用程序的崩溃信息(A)的匹配通过模糊判断来执行，其中，所述模糊判断基于的判断依据参数能够根据所获取的应用程序的崩溃信息(B)和/或所述配置表中的应用程序的崩溃信息(A)进行动态地调整。

8.根据权利要求1至7中任一项所述的方法，其特征在于，所述崩溃处理策略包括以下策略中的一个或多个：

不做任何操作；

显示错误页面并引导用户清理用户数据；

显示升级页面并引导用户进行应用程序升级；

显示页面以展示推荐的解决方案；

执行自动重启；

执行自动重启并清理本地用户数据；

显示页面以展示应用崩溃报告；

退出并重新登录应用程序；

在不重启应用程序的情况下重新初始化软件开发工具包；

第一降级策略和与所述第一降级策略对应的第一升级策略；和

第二降级策略和与所述第二降级策略对应的第二升级策略。

9.根据权利要求1至8中任一项所述的方法，其特征在于，基于所述应用程序的崩溃信息(B)确定所述应用程序的发生崩溃的子功能，并基于所述第一降级策略关闭所述应用程序的发生崩溃的子功能，直至重新启动所述应用程序和/或停止执行所述第一降级策略后，基于所述第一升级策略重新开启所关闭的子功能。

10.根据权利要求1至9中任一项所述的方法，其特征在于，判断在预设时间段内出现相同类型的应用程序崩溃的次数是否超过预设阈值；如果在预设时间段内出现相同类型的应用程序崩溃的次数超过预设阈值，则基于所述应用程序的崩溃信息(B)判断所确定的子功能是否属于预给定的子功能；如果所确定的子功能属于预给定的子功能，则基于所述第二降级策略关闭所述应用程序的发生崩溃的子功能，直至所述应用程序完成升级或后端服务器(15)提供的后端服务完成更新后，基于所述第二升级策略重新开启所关闭的子功能。

11.根据权利要求1至10中任一项所述的方法，其特征在于，所述方法还包括：基于客户端的参数从后端服务器(15)获取适配于所述参数的应用程序崩溃处理策略的配置表，并对存储在客户端本地的配置表进行同步更新；其中，所述客户端的参数包括所述客户端的操作***类型、操作***版本、应用程序版本和/或设备型号。

12.根据权利要求1至11中任一项所述的方法，其特征在于，所述方法还包括：

基于监测到的应用程序崩溃的线程信息判断所述应用程序崩溃是主线程崩溃还是子线程崩溃；

如果所述应用程序崩溃是子线程崩溃，则记录所述子线程的崩溃信息；

如果所述应用程序是主线程崩溃，则对所述主线程崩溃进行所述崩溃处理。

13.一种用于运行应用程序的设备(1)，其特征在于，所述设备(1)包括以下构件：

应用程序崩溃监测模块(11)，其被配置为监测应用程序崩溃的发生，以及获取应用程序的崩溃信息；

应用程序崩溃保护管理模块(12)，其被配置为基于所述应用程序的崩溃信息和应用程序崩溃处理策略的配置表启用和/或停用相应的应用程序崩溃处理功能，以及启用和/或停用所述配置表的远程更新功能；

崩溃处理模块(13)，其被配置为基于与所获取的应用程序程序的崩溃信息相对应的崩溃处理策略对所述应用程序崩溃进行处理；和

客户端本地存储模块(14)，其被配置为在本地存储所述配置表，所述配置表包括应用程序的崩溃信息(A)与崩溃处理策略之间的映射关系。

14.根据权利要求13所述的设备(1)，其特征在于，所述崩溃处理模块(13)被配置为不基于用户的输入，自动地基于所述配置表中与所述应用程序的崩溃信息(B)相对应的崩溃处理策略执行所述崩溃处理。

15.根据权利要求13或14所述的设备(1)，其特征在于，在所述客户端本地存储模块(14)中存储有所述应用程序崩溃处理策略的配置表，并通过后端服务器(15)远程更新存储的配置表。

16.根据权利要求13至15中任一项所述所述的设备(1)，其特征在于，所述应用程序崩溃保护管理模块(12)被配置为在应用程序启动后和/或当存储在所述客户端本地存储模块中的应用程序崩溃处理策略的配置表中不存在所述应用程序的崩溃信息(B)时，查询后端服务器(15)是否有更新的应用程序崩溃处理策略的配置表；如果有更新，则从后端服务器(15)下载更新的配置表并更新所述客户端本地存储模块(14)中存储的配置表。

17.根据权利要求13至16中任一项所述所述的设备(1)，其特征在于，所述应用程序的崩溃信息包括应用程序崩溃的类型信息和/或标识信息，其中，所述类型信息包括崩溃类型，所述标识信息包括全类名，方法名和/或文件名，其中，所述全类名包括类名和/或包名。

18.根据权利要求13至17中任一项所述所述的设备(1)，其特征在于，所述应用程序崩溃保护管理模块(12)被配置为监测在预设的时间段内是否发生预设次数的应用程序崩溃，并在预设的时间段内发生预设次数的应用程序崩溃时停止执行所述崩溃处理并报告给后端服务器(15)。

19.根据权利要求13至18中任一项所述所述的设备(1)，其特征在于，所述应用程序崩溃保护管理模块(12)被配置为，通过模糊判断来执行所获取的应用程序的崩溃信息(B)与所述配置表中的应用程序的崩溃信息(A)的匹配，其中，所述模糊判断基于的判断依据参数能够根据所获取的应用程序的崩溃信息(B)和/或所述配置表中的应用程序的崩溃信息(A)进行动态地调整。

20.根据权利要求13至19中任一项所述所述的设备(1)，其特征在于，所述崩溃处理策略包括以下策略中的一个或多个：

不做任何操作；

显示错误页面并引导用户清理用户数据；

显示升级页面并引导用户进行应用程序升级；

显示页面以展示推荐的解决方案；

执行自动重启；

执行自动重启并清理本地用户数据；

显示页面以展示应用崩溃报告；

退出并重新登录应用程序；

在不重启应用程序的情况下重新初始化软件开发工具包；

第一降级策略和与所述第一降级策略对应的第一升级策略；和

第二降级策略和与所述第二降级策略对应的第二升级策略。

21.根据权利要求13至20中任一项所述所述的设备(1)，其特征在于，所述崩溃处理模块(13)被配置为，基于所述应用程序的崩溃信息(B)确定所述应用程序的发生崩溃的子功能，并基于所述第一降级策略关闭所述应用程序的发生崩溃的子功能，直至重新启动所述应用程序和/或停止执行所述第一降级策略后，基于所述第一升级策略重新开启所关闭的子功能。

22.根据权利要求13至21中任一项所述所述的设备(1)，其特征在于，所述崩溃处理模块(13)被配置为，判断在预设时间段内出现相同类型的应用程序崩溃的次数是否超过预设阈值；如果在预设时间段内出现相同类型的应用程序崩溃的次数超过预设阈值，则基于所述应用程序的崩溃信息(B)判断所确定的子功能是否属于预给定的子功能；如果所确定的子功能属于预给定的子功能，则基于所述第二降级策略关闭所述应用程序的发生崩溃的子功能，直至所述应用程序完成升级或后端服务器(15)提供的后端服务完成更新后，基于所述第二升级策略重新开启所关闭的子功能。

23.根据权利要求13至22中任一项所述所述的设备(1)，其特征在于，所述崩溃处理模块(13)被配置为，基于客户端的参数从后端服务器(15)获取适配于所述参数的应用程序崩溃处理策略的配置表，并对存储在客户端本地的配置表进行同步更新；其中，所述客户端的参数包括所述客户端的操作***类型、操作***版本、应用程序版本和/或设备型号。

24.根据权利要求13至23中任一项所述所述的设备(1)，其特征在于，应用程序崩溃监测模块(11)基于监测到的应用程序崩溃的线程信息判断所述应用程序崩溃是主线程崩溃还是子线程崩溃；如果所述应用程序是主线程崩溃，则对所述主线程崩溃进行所述崩溃处理。

25.一种用于处理应用程序崩溃的***(10)，所述***(10)用于执行根据权利要求1至12中任一项所述的方法，其特征在于，所述***(100)包括以下构件：

应用程序崩溃监测模块(11)，其被配置为监测应用程序崩溃的发生，以及获取应用程序的崩溃信息(B)；

应用程序崩溃保护管理模块(12)，其被配置为基于所述应用程序的崩溃信息(B)和应用程序崩溃处理策略的配置表启用和/或停用相应的应用程序崩溃处理功能，以及启用和/或停用所述配置表的远程更新功能；

崩溃处理模块(13)，其被配置为基于与所获取的应用程序程序的崩溃信息(B)相对应的崩溃处理策略对所述应用程序崩溃进行处理；

客户端本地存储模块(14)，其被配置为在运行所述应用程序的客户端本地存储所述配置表，所述配置表包括程序崩溃的信息(A)与降级策略之间的映射关系；和

后端服务器(15)，其被配置为能够远程更新所述客户端本地存储模块中的所述配置表。

26.一种计算机程序产品、例如计算机可读的程序载体，包含计算机程序指令，所述计算机程序指令被处理器执行时至少辅助地实现根据权利要求1至12中任一项所述的方法的步骤。

Images