CN107436777B - 移动终端、应用程序崩溃处理方法及装置 - Google Patents

Abstract

本公开是关于一种移动终端、应用程序崩溃处理方法及装置。该应用程序崩溃处理方法包括：在应用程序启动时，初始化一任务栈以保存当前页面组件与后台页面组件；进行应用程序崩溃捕获监听；当捕获到一应用程序崩溃时，根据位于任务栈栈顶的页面组件判断所述应用程序是在前台运行或是在后台运行；如果判断崩溃的所述应用程序是在后台运行，则收集所述应用程序的崩溃信息，并将所述崩溃信息上传至服务器。本公开可以提升用户体验。

Description

移动终端、应用程序崩溃处理方法及装置

技术领域

本公开涉及移动终端技术领域，具体而言，涉及一种应用程序崩溃处理方法、应用程序崩溃处理装置以及应用该应用程序崩溃处理方法及装置的移动终端。

背景技术

随着集成电路技术以及通信网络技术的飞速发展，移动终端逐渐拥有了强大的处理能力和通信功能。目前，移动终端已经从简单的通话工具变为一个综合信息处理平台，成为渗透广泛、普及迅速、影响巨大、深入至人类社会生活方方面面的终端产品。

在移动终端使用过程中，部分情况下可能会由于应用程序自身代码或操作系统等原因引起应用程序的崩溃，进而无法继续使用；例如，运行时异常、执行错误(如内存溢出等)以及子线程抛出的异常等都有可能引起的应用程序的崩溃。

现有技术中，当移动终端中的应用程序崩溃后，系统会捕获到崩溃以及将崩溃信息提交至服务器并进行崩溃处理；但一方面，现有技术中的崩溃处理方案都只处理了应用程序在前台使用时的崩溃，而在应用程序在后台未使用时的崩溃并没有进行处理；另一方面，现有技术中对同一应用程序的多次崩溃会均做出同样的处理，难以解决崩溃问题，用户体验较差。

因此，现有技术中的技术方案还存在有待改进之处。

需要说明的是，在上述背景技术部分公开的信息仅用于加强对本公开的背景的理解，因此可以包括不构成对本领域普通技术人员已知的现有技术的信息。

发明内容

本公开的目的在于提供一种应用程序崩溃处理方法、应用程序崩溃处理装置以及应用该应用程序崩溃处理方法及装置的移动终端，进而至少在一定程度上克服由于相关技术的限制和缺陷而导致的一个或者多个问题。

本公开的其他特性和优点将通过下面的详细描述变得清晰，或者部分地通过本公开的实践而习得。

根据本公开实施例的第一方面，提供一种应用程序崩溃处理方法，所述方法包括：

在应用程序启动时，初始化一任务栈以保存当前页面组件与后台页面组件；

进行应用程序崩溃捕获监听；

当捕获到一应用程序崩溃时，根据位于任务栈栈顶的页面组件判断所述应用程序是在前台运行或是在后台运行；

如果判断崩溃的所述应用程序是在后台运行，则收集所述应用程序的崩溃信息，并将所述崩溃信息上传至服务器。

在本公开的一种示例性实施例中，所述应用程序崩溃处理方法还包括：

当捕获到所述应用程序崩溃时，查询所述应用程序的崩溃次数，并比较所述崩溃次数是否大于预设值；

当所述崩溃次数不大于所述预设值时，执行第一处理过程；

当所述崩溃次数大于所述预设值时，执行第二处理过程；所述第二处理过程不同于所述第一处理过程。

在本公开的一种示例性实施例中，其中，如果判断崩溃的所述应用程序是在后台运行：

所述第一处理过程包括，重新启动所述应用程序并在后台运行；

所述第二处理过程包括，初始化所述应用程序配置，并重新启动所述应用程序且在后台运行。

在本公开的一种示例性实施例中，其中，如果判断崩溃的所述应用程序是在前台运行：

所述第一处理过程包括，向前台提供第一选项，并根据所述第一选项的返回结果重新启动所述应用程序；

所述第二处理过程包括，向前台提供第二选项，并根据所述第二选项的返回结果初始化所述应用程序配置或者重新安装所述应用程序。

在本公开的一种示例性实施例中，所述第二处理过程还包括：

后台下载所述应用程序的最新版本，并且在所述应用程序被再次启动时，向前台提供第三选项，并根据所述第三选项的返回结果重新安装所述应用程序。

在本公开的一种示例性实施例中，所述应用程序崩溃处理方法还包括：

在满足预设条件时，将所述崩溃信息上传至服务器；

在不满足所述预设条件时，将所述崩溃信息保存于本地，并监听是否满足所述预设条件且在满足所述预设条件时将所述崩溃信息上传至所述服务器。

在本公开的一种示例性实施例中，在不满足所述预设条件时，仅在本地保存最新的预设数量的所述崩溃信息。

根据本公开实施例的第二方面，提供一种应用程序崩溃处理装置，所述装置包括：

任务栈启动模块，用于在应用程序启动时，初始化一任务栈以保存当前页面组件与后台页面组件；

崩溃监听模块，用于进行应用程序崩溃捕获监听；

运行判断模块，用于当捕获到一应用程序崩溃时，根据位于任务栈栈顶的页面组件判断所述应用程序是在前台运行或是在后台运行；

信息反馈模块，用于在判断崩溃的所述应用程序是在后台运行时，收集所述应用程序的崩溃信息，并将所述崩溃信息上传至服务器。

在本公开的一种示例性实施例中，所述应用程序崩溃处理装置还包括：

计数比较模块，用于当捕获到所述应用程序崩溃时，查询所述应用程序的崩溃次数，并比较所述崩溃次数是否大于预设值；

第一执行模块，用于当所述崩溃次数不大于所述预设值时，执行第一处理过程；

第二执行模块，用于在判断所述崩溃次数大于所述预设值时，执行第二处理过程；所述第二处理过程不同于所述第一处理过程。

在本公开的一种示例性实施例中，其中，如果崩溃的所述应用程序是在后台运行：

所述第一处理过程包括，重新启动所述应用程序并在后台运行；

所述第二处理过程包括，初始化所述应用程序配置，并重新启动所述应用程序且在后台运行。

在本公开的一种示例性实施例中，其中，如果崩溃的所述应用程序是在前台运行：

所述第一处理过程包括，向前台提供第一选项，并根据所述第一选项的返回结果重新启动所述应用程序；

所述第二处理过程包括，向前台提供第二选项，并根据所述第二选项的返回结果初始化所述应用程序配置或者重新安装所述应用程序。

在本公开的一种示例性实施例中，所述第二处理过程还包括：

后台下载所述应用程序的最新版本，并且在所述应用程序被再次启动时，向前台提供第三选项，并根据所述第三选项的返回结果重新安装所述应用程序。

在本公开的一种示例性实施例中，所述应用程序崩溃处理装置还包括：

所述信息反馈模块还用于，在满足预设条件时，将所述崩溃信息上传至服务器；以及，在不满足所述预设条件时，将所述崩溃信息保存于本地，并监听是否满足所述预设条件且在满足所述预设条件时将所述崩溃信息上传至所述服务器。

在本公开的一种示例性实施例中，在不满足所述预设条件时，仅在本地保存最新的预设数量的所述崩溃信息。

根据本公开实施例的第三方面，提供一种移动终端，包括：

处理器；以及

存储器，用于存储所述处理器的可执行指令；

其中所述处理器配置为经由执行所述可执行指令来执行以下操作：

在应用程序启动时，初始化一任务栈以保存当前页面组件与后台页面组件；

进行应用程序崩溃捕获监听；

当捕获到一应用程序崩溃时，根据位于任务栈栈顶的页面组件判断所述应用程序是在前台运行或是在后台运行；

如果判断崩溃的所述应用程序是在后台运行，则收集所述应用程序的崩溃信息，并将所述崩溃信息上传至服务器。

本公开的一种实施例中的技术方案中，除了对应用程序在前台使用时的崩溃进行处理之外，还可以对应用程序在后台未使用时的崩溃进行处理，一方面可以及时智能的处理更多的崩溃，进一步提升用户体验；另一方面，可以让开发人员及时的获取崩溃信息，从而进一步改善所提供的服务，让用户有更好的体验。在另一示例性实施例中，随着应用程序崩溃次数的增加，可以采用不同的处理过程；相比于现有技术中始终采用单一处理过程进行崩溃处理的技术方案，可以提升该应用程序崩溃问题被解决的可能性，从而可以提升用户体验。

应当理解的是，以上的一般描述和后文的细节描述仅是示例性和解释性的，并不能限制本公开。

附图说明

此处的附图被并入说明书中并构成本说明书的一部分，示出了符合本公开的实施例，并与说明书一起用于解释本公开的原理。显而易见地，下面描述中的附图仅仅是本公开的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1示出本公开示例性实施例中一种应用程序崩溃处理方法的流程示意图。

图2示出本公开示例性实施例中一种应用程序崩溃处理方法的流程示意图。

图3示出本公开示例性实施例中一种应用程序崩溃处理装置的方框示意图。

图4示出本公开示例性实施例中一种应用上述应用程序崩溃处理方法或应用程序崩溃处理装置的移动终端的方框示意图。

具体实施方式

现在将参考附图更全面地描述示例实施方式。然而，示例实施方式能够以多种形式实施，且不应被理解为限于在此阐述的范例；相反，提供这些实施方式使得本公开将更加全面和完整，并将示例实施方式的构思全面地传达给本领域的技术人员。所描述的特征、结构或特性可以以任何合适的方式结合在一个或更多实施方式中。在下面的描述中，提供许多具体细节从而给出对本公开的实施方式的充分理解。然而，本领域技术人员将意识到，可以实践本公开的技术方案而省略所述特定细节中的一个或更多，或者可以采用其它的方法、组元、装置、步骤等。在其它情况下，不详细示出或描述公知技术方案以避免喧宾夺主而使得本公开的各方面变得模糊。

此外，附图仅为本公开的示意性图解，并非一定是按比例绘制。图中相同的附图标记表示相同或类似的部分，因而将省略对它们的重复描述。附图中所示的一些方框图是功能实体，不一定必须与物理或逻辑上独立的实体相对应。可以采用软件形式来实现这些功能实体，或在一个或多个硬件模块或集成电路中实现这些功能实体，或在不同网络和/或处理器装置和/或微控制器装置中实现这些功能实体。

本示例实施方式中首先提供了一种应用程序崩溃处理方法，可以应用于移动终端中的应用程序崩溃处理。本示例实施方式中，所述移动终端例如可以为手机、平板电脑以及PDA等。所述移动终端的可以为Android操作系统、也可以为IOS操作系统、Window Mobile操作系统等其他操作系统；本示例实施方式中将以Android操作系统为例进行说明，但对应于其他操作系统的技术方案同样属于本公开的保护范围，本示例性实施例中对此不做特殊限定。

参考图1中所示，本示例实施方式中，所述应用程序崩溃处理方法可以包括以下步骤：

步骤S1.在应用程序启动时，初始化一任务栈以保存当前页面组件与后台页面组件。

通过所述步骤S1，可以判断判断所述应用程序是在前台运行或是在后台运行，再根据所述应用程序是在前台运行或是在后台运行而执行不同的处理。举例而言：

以Android操作系统为例，本示例实施方式中可以在应用程序启动时初始化一个只保存两个元素的任务栈用来存储当前页面组件(activity)与上一页面组件(activity)；其中，当前页面组件为前台运行的应用程序的组件或者由前台运行的应用程序的组件激活的其他应用程序的组件；当前页面组件之外的其他页面组件则为后台运行的应用程序的组件。但在本公开的其他示例性实施例中，所述任务栈也可以不局限于保存当前页面组件与上一页面组件，而可以保存更多的页面组件，本示例实施方式中对此不做特殊限定。

步骤S2.进行应用程序崩溃捕获监听。

本示例实施方式中可以通过移动终端操作系统中特定的接口或者调用特定的函数进行应用程序崩溃捕获监听。例如，在Android操作系统中，在某一应用程序启动时，可以重写并注册Java所提供的UncaughtExceptionHandler接口从而捕获应用程序的异常或崩溃。又例如，在IOS操作系统中，当应用程序启动时，可以通过调用InitCrashReport()函数来进行应用程序的崩溃捕获。当然，在本公开的其他示例性实施例或者其他操作系统中，也可能采用其他方式进行应用程序崩溃捕获监听，因此并不局限于本示例实施方式中所列举的实现方式。

步骤S3.当捕获到一应用程序崩溃时，根据位于任务栈栈顶的页面组件判断所述应用程序是在前台运行或是在后台运行。

以Android操作系统为例，当所述应用程序发生崩溃时，可以通过调用界面管理器(ActivityManager)来获取当前的任务栈的相关信息(RunningTaskInfo)，并根据RunningTaskInfo获取任务栈中位于栈顶的页面组件，并通过页面组件的包名判断是否属于当前崩溃的应用程序；如果属于当前崩溃的应用程序，则说明崩溃的应用程序是在前台运行，否则，则说明崩溃的应用程序是在后台运行。当然，在本公开的其他示例性实施例或者其他操作系统中，也可能采用其他方式判断应用程序是在前台运行或是在后台运行，因此并不局限于本示例实施方式中所列举的实现方式。

步骤S4.如果判断崩溃的所述应用程序是在后台运行，则收集所述应用程序的崩溃信息，并将所述崩溃信息上传至服务器。

例如，移动终端中的崩溃信息主要以日志(log)的形式体现；一般而言，移动终端log系统的系统应用层log中的mobilelog为系统应用层的日志，例如，应用程序无响应或强行关闭、kernel相关的日志等。mobilelog包括mainlog、eventslog、kernellog等。mainlog记录有移动终端上层应用程序以及框架层(framework)相关的日志信息。在应用程序崩溃后，可以收集所述日志以及崩溃时的异常堆栈等崩溃信息，还可以包括设备型号、设备ID、软件版本号、异常发生位置、异常发生时间、异常类别、异常事件发生次数以及发生频率等其他信息。所述崩溃信息将会被不断的写入移动终端本地缓存中。

在收集所述应用程序的崩溃信息后，可以直接将所述崩溃信息上传至服务器，也可以在首先进行一判断，在满足预设条件时，将所述崩溃信息上传至服务器。例如：

本示例实施方式中，所述预设条件例如可以为用户在WiFi等无线环境中或者处于蜂窝网络中但所述崩溃信息小于预设大小等。例如，当通过WiFi模块查询到用户在WiFi等无线环境中时，如果发生应用程序崩溃，则可以在后台进程中启动Service组件，通过Service组件将崩溃信息打包上传到预设IP的服务器。在崩溃信息提交上传完毕后，则可以关闭Service组件，并杀死进行崩溃处理的后台进程。

在不满足所述预设条件时，将所述崩溃信息保存于本地，并监听是否满足所述预设条件且在满足所述预设条件时将所述崩溃信息上传至所述服务器。

例如，如果不在WiFi等无线环境中时或者由于其他任何原因无法将所述崩溃信息上传至所述服务器时，则可以将所述崩溃信息保存于本地，并监听用户是否已经在WiFi等无线环境中，当监听到用户已经在WiFi等无线环境中时，可以在后台进程中启动Service组件，通过Service组件将崩溃信息打包上传到预设IP的服务器。在崩溃信息提交上传完毕后，则可以关闭Service组件，并杀死进行崩溃处理的后台进程。此外，为了避免用户因为崩溃次数多导致的上报流量问题，本示例实施方式中可以仅在本地保存最新的预设数量的所述崩溃信息，例如仅在本地保存最新的10条所述崩溃信息。

在上述示例性实施例中，除了对应用程序在前台使用时的崩溃进行处理之外，还可以对应用程序在后台未使用时的崩溃进行处理，一方面可以及时智能的处理更多的崩溃，进一步提升用户体验；另一方面，可以让开发人员及时的获取崩溃信息，从而进一步改善所提供的服务，让用户有更好的体验。

进一步的，本示例实施方式中的应用程序崩溃处理方法还可以包括以下步骤：

步骤S5.当捕获到一应用程序崩溃时，查询所述应用程序的崩溃次数，并比较所述崩溃次数是否大于预设值。

本示例实施方式中，当所述应用程序安装后，可以通过例如计数器等方式记录所述应用程序的崩溃次数，所述崩溃次数可以是累计崩溃次数，也可以是连续崩溃次数等，本领域技术人员可以根据具体的应用程序而设定；所述预设值的大小同样可以由本领域技术人员根据具体的应用程序而设定，例如可以为3次、5次或者10次等。当通过上述步骤S1捕获到应用程序崩溃后，可以首先将所述计数器加1，得到所述应用程序的崩溃次数，再将所述崩溃次数与所述预设值进行比较。

步骤S6.当所述崩溃次数不大于所述预设值时，执行第一处理过程；以及，当所述崩溃次数大于所述预设值时，执行第二处理过程。

本示例实施方式中，所述第二处理过程不同于所述第一处理过程；例如，所述第一处理过程可以为重新启动应用程序或者直接关闭所述应用程序；所述第二处理过程可以为初始化所述应用程序并重新启动所述应用程序或者重新安装所述应用程序等。同时，在不同的应用程序中，所述第一处理过程也可能有所不同，在不同的应用程序中，所述第二处理过程也可能有所不同；同一应用程序在前台及后台运行时，所述第一处理过程也可能有所不同，同一应用程序在前台即后台运行时，所述第二处理过程也可能有所不同；关于此将在后续进行进一步的详细描述。

通过本示例实施方式中的技术方案，随着应用程序崩溃次数的增加，可以采用不同的处理过程；相比于现有技术中始终采用单一处理过程进行崩溃处理的技术方案，可以提升该应用程序崩溃问题被解决的可能性，从而可以提升用户体验。

进一步的，根据崩溃的所述应用程序是在前台运行或是在后台运行，可以执行对应的第一处理过程和第二处理过程。举例而言：

本示例实施方式中，如果判断崩溃的所述应用程序是在前台运行，所述第一处理过程可以包括：向前台提供第一选项，并根据所述第一选项的返回结果重新启动所述应用程序。

例如，如果应用程序是在前台运行，可以弹出应用程序崩溃提醒页面，并向前台提供反馈窗口，在反馈窗口提供第一选项让用户选择是关闭应用程序还是重新启动应用程序。在用户输入后，所述第一选项将返回用户的选择结果，根据所述第一选项的返回结果可以确定是直接关闭所述应用程序或者重新启动所述应用程序。

如果判断崩溃的所述应用程序是在前台运行，所述第二处理过程包括：向前台提供第二选项，并根据所述第二选项的返回结果初始化所述应用程序配置或者重新安装所述应用程序。

例如，在所述应用程序崩溃次数大于预设次数后，可以向前台提供反馈窗口，在反馈窗口提供第二选项让用户选择是初始化所述应用程序配置或者重新安装所述应用程序。在用户输入后，所述第二选项将返回用户的选择结果，根据所述第二选项的返回结果可以确定是初始化所述应用程序配置或者重新安装所述应用程序。如果用户选择初始化所述应用程序配置，则重置所述应用程序的配置参数，并重新启动所述应用程序。如果用户选择重新启动所述应用程序，则可以通过应用商店或者其他途径下载所述应用程序并重新安装。

此外，本示例实施方式中，所述第二处理过程还可以包括：

如果用户在WiFi等无线环境中时，还可以在应用程序崩溃次数大于预设次数后，后台下载所述应用程序的最新版本，并且在所述应用程序被再次启动时，向前台提供第三选项，提示用户安装；如果所述第三选项的返回结果为确认重新安装，则可以直接安装已经后台下载的应用程序，无需用户等待。

本示例实施方式中，如果判断崩溃的所述应用程序是在后台运行，所述第一处理过程可以包括：重新启动所述应用程序并在后台运行。例如，如果应用程序是在后台运行，在所述应用程序崩溃后而且崩溃次数不大于预设次数时，则可以直接重新启动所述应用程序而无需提醒用户，并且所述应用程序仍在后台运行。

如果判断崩溃的所述应用程序是在后台运行，所述第二处理过程包括：初始化所述应用程序配置，并重新启动所述应用程序且在后台运行。例如，在所述应用程序崩溃次数大于预设次数后，可以直接重置所述应用程序的配置参数，并重新启动所述应用程序而无需提醒用户，并且所述应用程序仍在后台运行。

此外，本示例实施方式中，所述第二处理过程还可以包括：

如果用户在WiFi等无线环境中时，还可以在应用程序崩溃次数大于预设次数后，后台下载所述应用程序的最新版本，并且在所述应用程序被再次启动时，向后台提供第三选项，提示用户安装；如果所述第三选项的返回结果为确认重新安装，则可以直接安装已经后台下载的应用程序，无需用户等待。

进一步的，本示例实施方式中还提供了一种应用程序崩溃处理装置，参考图3中所示，所述应用程序崩溃处理装置1可以包括任务栈启动模块10、崩溃监听模块20、运行判断模块30以及信息反馈模块40。其中：

任务栈启动模块10可以用于在应用程序启动时，初始化一任务栈以保存当前页面组件与后台页面组件。

崩溃监听模块20可以用于进行应用程序崩溃捕获监听。

运行判断模块30可以用于当捕获到一应用程序崩溃时，根据位于任务栈栈顶的页面组件判断所述应用程序是在前台运行或是在后台运行。

信息反馈模块40可以用于在判断崩溃的所述应用程序是在后台运行时，收集所述应用程序的崩溃信息，并将所述崩溃信息上传至服务器。

本示例实施方式中，所述应用程序崩溃处理装置还可以包括计数比较模块、第一执行模块以及第二执行模块。其中：

计数比较模块可以用于当捕获到所述应用程序崩溃时，查询所述应用程序的崩溃次数，并比较所述崩溃次数是否大于预设值。

第一执行模块可以用于当所述崩溃次数不大于所述预设值时，执行第一处理过程。

第二执行模块可以用于在判断所述崩溃次数大于所述预设值时，执行第二处理过程。所述第二处理过程不同于所述第一处理过程。

本示例实施方式中，其中，如果崩溃的所述应用程序是在后台运行：

所述第一处理过程可以包括，重新启动所述应用程序并在后台运行。

所述第二处理过程可以包括，初始化所述应用程序配置，并重新启动所述应用程序且在后台运行。

本示例实施方式中，其中，如果崩溃的所述应用程序是在前台运行：

所述第一处理过程可以包括，向前台提供第一选项，并根据所述第一选项的返回结果重新启动所述应用程序。

所述第二处理过程可以包括，向前台提供第二选项，并根据所述第二选项的返回结果初始化所述应用程序配置或者重新安装所述应用程序。

本示例实施方式中，所述第二处理过程还可以包括：

后台下载所述应用程序的最新版本，并且在所述应用程序被再次启动时，向前台提供第三选项，并根据所述第三选项的返回结果重新安装所述应用程序。

本示例实施方式中，所述信息反馈模块还可以用于，在满足预设条件时，将所述崩溃信息上传至服务器。以及，在不满足所述预设条件时，将所述崩溃信息保存于本地，并监听是否满足所述预设条件且在满足所述预设条件时将所述崩溃信息上传至所述服务器。

本示例实施方式中，在不满足所述预设条件时，仅在本地保存最新的预设数量的所述崩溃信息。

本示例实施方式中，在不满足所述预设条件时，仅在本地保存最新的预设数量的所述崩溃信息。

上述应用程序崩溃处理装置中各模块/单元的具体细节已经在对应的应用程序崩溃处理方法中进行了详细的描述，因此此处不再赘述。

应当注意，尽管在上文详细描述中提及了用于动作执行的设备的若干模块或者单元，但是这种划分并非强制性的。实际上，根据本公开的实施方式，上文描述的两个或更多模块或者单元的特征和功能可以在一个模块或者单元中具体化。反之，上文描述的一个模块或者单元的特征和功能可以进一步划分为由多个模块或者单元来具体化。

此外，尽管在附图中以特定顺序描述了本公开中方法的各个步骤，但是，这并非要求或者暗示必须按照该特定顺序来执行这些步骤，或是必须执行全部所示的步骤才能实现期望的结果。附加的或备选的，可以省略某些步骤，将多个步骤合并为一个步骤执行，以及/或者将一个步骤分解为多个步骤执行等。

参照图4，应用上述应用程序崩溃处理方案的移动终端300可以包括以下一个或多个组件：处理组件302，存储器304，电源组件306，多媒体组件308，音频组件310，输入/输出(I/O)的接口312，传感器组件314，以及通信组件316。

处理组件302通常控制移动终端300的整体操作，诸如与显示，电话呼叫，数据通信，相机操作和记录操作相关联的操作。处理组件302可以包括一个或多个处理器320来执行指令，以完成上述的方法的全部或部分步骤。此外，处理组件302可以包括一个或多个模块，便于处理组件302和其他组件之间的交互。例如，处理组件302可以包括多媒体模块，以方便多媒体组件304和处理组件302之间的交互。

存储器304被配置为存储各种类型的数据以支持在设备300的操作。这些数据的示例包括用于在移动终端300上操作的任何应用程序或方法的指令，联系人数据，电话簿数据，消息，图片，视频等。存储器304可以由任何类型的易失性或非易失性存储设备或者它们的组合实现，如静态随机存取存储器(SRAM)，电可擦除可编程只读存储器(EEPROM)，可擦除可编程只读存储器(EPROM)，可编程只读存储器(PROM)，只读存储器(ROM)，磁存储器，快闪存储器，磁盘或光盘。

电源组件306为移动终端300的各种组件提供电力。电源组件306可以包括电源管理系统，一个或多个电源，及其他与为移动终端300生成、管理和分配电力相关联的组件。

多媒体组件308包括在所述移动终端300和用户之间的提供一个输出接口的屏幕。在一些实施例中，屏幕可以包括液晶显示器(LCD)和触摸面板(TP)。如果屏幕包括触摸面板，屏幕可以被实现为触摸屏，以接收来自用户的输入信号。触摸面板包括一个或多个触摸传感器以感测触摸、滑动和触摸面板上的手势。所述触摸传感器可以不仅感测触摸或滑动动作的边界，而且还检测与所述触摸或滑动操作相关的持续时间和压力。在一些实施例中，多媒体组件308包括一个前置摄像头和/或后置摄像头。当设备300处于操作模式，如拍摄模式或视频模式时，前置摄像头和/或后置摄像头可以接收外部的多媒体数据。每个前置摄像头和后置摄像头可以是一个固定的光学透镜系统或具有焦距和光学变焦能力。

音频组件310被配置为输出和/或输入音频信号。例如，音频组件310包括一个麦克风(MIC)，当移动终端300处于操作模式，如呼叫模式、记录模式和语音识别模式时，麦克风被配置为接收外部音频信号。所接收的音频信号可以被进一步存储在存储器304或经由通信组件316发送。在一些实施例中，音频组件310还包括一个扬声器，用于输出音频信号。

I/O接口312为处理组件302和外围接口模块之间提供接口，上述外围接口模块可以是键盘，点击轮，按钮等。这些按钮可包括但不限于：主页按钮、音量按钮、启动按钮和锁定按钮。

传感器组件314包括一个或多个传感器，用于为移动终端300提供各个方面的状态评估。例如，传感器组件314可以检测到设备300的打开/关闭状态，组件的相对定位，例如所述组件为移动终端300的显示器和小键盘，传感器组件314还可以检测移动终端300或移动终端300一个组件的位置改变，用户与移动终端300接触的存在或不存在，移动终端300方位或加速/减速和移动终端300的温度变化。传感器组件314可以包括接近传感器，被配置用来在没有任何的物理接触时检测附近物体的存在。传感器组件314还可以包括光传感器，如CMOS或CCD图像传感器，用于在成像应用中使用。在一些实施例中，该传感器组件314还可以包括加速度传感器，陀螺仪传感器，磁传感器，压力传感器或温度传感器。

通信组件316被配置为便于移动终端300和其他设备之间有线或无线方式的通信。移动终端300可以接入基于通信标准的无线网络，如WiFi，2G或3G，或它们的组合。在一个示例性实施例中，通信组件316经由广播信道接收来自外部广播管理系统的广播信号或广播相关信息。在一个示例性实施例中，所述通信组件316还包括近场通信(NFC)模块，以促进短程通信。例如，在NFC模块可基于射频识别(RFID)技术，红外数据协会(IrDA)技术，超宽带(UWB)技术，蓝牙(BT)技术和其他技术来实现。

在示例性实施例中，移动终端300可以被一个或多个应用专用集成电路(ASIC)、数字信号处理器(DSP)、数字信号处理设备(DSPD)、可编程逻辑器件(PLD)、现场可编程门阵列(FPGA)、控制器、微控制器、微处理器或其他电子元件实现，用于执行上述方法。

在示例性实施例中，还提供了一种包括指令的非临时性计算机可读存储介质，例如包括指令的存储器304，上述指令可由移动终端300的处理器320执行以完成本示例实施方式中的上述技术方案。例如，所述非临时性计算机可读存储介质可以是ROM、随机存取存储器(RAM)、CD-ROM、磁带、软盘和光数据存储设备等。

本领域技术人员在考虑说明书及实践这里公开的发明后，将容易想到本公开的其它实施方案。本申请旨在涵盖本公开的任何变型、用途或者适应性变化，这些变型、用途或者适应性变化遵循本公开的一般性原理并包括本公开未公开的本技术领域中的公知常识或惯用技术手段。说明书和实施例仅被视为示例性的，本公开的真正范围和精神由所附的权利要求指出。

Claims (11)

1.一种应用程序崩溃处理方法，其特征在于，所述方法包括：

在应用程序启动时，初始化一任务栈以保存当前页面组件与后台页面组件；

进行应用程序崩溃捕获监听；

当捕获到一应用程序崩溃时，根据位于任务栈栈顶的页面组件判断所述应用程序是在前台运行或是在后台运行；

如果判断崩溃的所述应用程序是在后台运行，则收集所述应用程序的崩溃信息，并将所述崩溃信息上传至服务器；

当捕获到所述应用程序崩溃时，查询所述应用程序的崩溃次数，并比较所述崩溃次数是否大于预设值；

当所述崩溃次数不大于所述预设值时，执行第一处理过程；

当所述崩溃次数大于所述预设值时，执行第二处理过程；所述第二处理过程不同于所述第一处理过程；

其中，如果判断崩溃的所述应用程序是在后台运行：

所述第一处理过程包括，重新启动所述应用程序并在后台运行；

所述第二处理过程包括，初始化所述应用程序配置，并重新启动所述应用程序且在后台运行。

2.根据权利要求1所述的应用程序崩溃处理方法，其特征在于，其中，如果判断崩溃的所述应用程序是在前台运行：

所述第一处理过程包括，向前台提供第一选项，并根据所述第一选项的返回结果重新启动所述应用程序；

所述第二处理过程包括，向前台提供第二选项，并根据所述第二选项的返回结果初始化所述应用程序配置或者重新安装所述应用程序。

3.根据权利要求1或2所述的应用程序崩溃处理方法，其特征在于，所述第二处理过程还包括：

后台下载所述应用程序的最新版本，并且在所述应用程序被再次启动时，向前台提供第三选项，并根据所述第三选项的返回结果重新安装所述应用程序。

4.根据权利要求1所述的应用程序崩溃处理方法，其特征在于，所述应用程序崩溃处理方法还包括：

在满足预设条件时，将所述崩溃信息上传至服务器；

在不满足所述预设条件时，将所述崩溃信息保存于本地，并监听是否满足所述预设条件且在满足所述预设条件时将所述崩溃信息上传至所述服务器。

5.根据权利要求4所述的应用程序崩溃处理方法，其特征在于，在不满足所述预设条件时，仅在本地保存最新的预设数量的所述崩溃信息。

6.一种应用程序崩溃处理装置，其特征在于，所述装置包括：

任务栈启动模块，用于在应用程序启动时，初始化一任务栈以保存当前页面组件与后台页面组件；

崩溃监听模块，用于进行应用程序崩溃捕获监听；

运行判断模块，用于当捕获到一应用程序崩溃时，根据位于任务栈栈顶的页面组件判断所述应用程序是在前台运行或是在后台运行；

信息反馈模块，用于在判断崩溃的所述应用程序是在后台运行时，收集所述应用程序的崩溃信息，并将所述崩溃信息上传至服务器；

计数比较模块，用于当捕获到所述应用程序崩溃时，查询所述应用程序的崩溃次数，并比较所述崩溃次数是否大于预设值；

第一执行模块，用于当所述崩溃次数不大于所述预设值时，执行第一处理过程；

第二执行模块，用于在判断所述崩溃次数大于所述预设值时，执行第二处理过程；所述第二处理过程不同于所述第一处理过程；

其中，如果崩溃的所述应用程序是在后台运行：

所述第一处理过程包括，重新启动所述应用程序并在后台运行；

所述第二处理过程包括，初始化所述应用程序配置，并重新启动所述应用程序且在后台运行。

7.根据权利要求6所述的应用程序崩溃处理装置，其特征在于，其中，如果崩溃的所述应用程序是在前台运行：

所述第一处理过程包括，向前台提供第一选项，并根据所述第一选项的返回结果重新启动所述应用程序；

所述第二处理过程包括，向前台提供第二选项，并根据所述第二选项的返回结果初始化所述应用程序配置或者重新安装所述应用程序。

8.根据权利要求6或7所述的应用程序崩溃处理装置，其特征在于，所述第二处理过程还包括：

后台下载所述应用程序的最新版本，并且在所述应用程序被再次启动时，向前台提供第三选项，并根据所述第三选项的返回结果重新安装所述应用程序。

9.根据权利要求6所述的应用程序崩溃处理装置，其特征在于，所述应用程序崩溃处理装置还包括：

所述信息反馈模块还用于，在满足预设条件时，将所述崩溃信息上传至服务器；以及，在不满足所述预设条件时，将所述崩溃信息保存于本地，并监听是否满足所述预设条件且在满足所述预设条件时将所述崩溃信息上传至所述服务器。

10.根据权利要求9所述的应用程序崩溃处理装置，其特征在于，在不满足所述预设条件时，仅在本地保存最新的预设数量的所述崩溃信息。

11.一种移动终端，其特征在于，包括

处理器；以及

存储器，用于存储所述处理器的可执行指令；

其中所述处理器配置为经由执行所述可执行指令来执行以下操作：

在应用程序启动时，初始化一任务栈以保存当前页面组件与后台页面组件；

进行应用程序崩溃捕获监听；

当捕获到一应用程序崩溃时，根据位于任务栈栈顶的页面组件判断所述应用程序是在前台运行或是在后台运行；

如果判断崩溃的所述应用程序是在后台运行，则收集所述应用程序的崩溃信息，并将所述崩溃信息上传至服务器；

当捕获到所述应用程序崩溃时，查询所述应用程序的崩溃次数，并比较所述崩溃次数是否大于预设值；

当所述崩溃次数不大于所述预设值时，执行第一处理过程；

当所述崩溃次数大于所述预设值时，执行第二处理过程；所述第二处理过程不同于所述第一处理过程；

其中，如果判断崩溃的所述应用程序是在后台运行：

所述第一处理过程包括，重新启动所述应用程序并在后台运行；

所述第二处理过程包括，初始化所述应用程序配置，并重新启动所述应用程序且在后台运行。