CN109032828A

CN109032828A - 应用异常处理方法及终端

Info

Publication number: CN109032828A
Application number: CN201810800990.5A
Authority: CN
Inventors: 苏晓强
Original assignee: Wangsu Science and Technology Co Ltd
Current assignee: Wangsu Science and Technology Co Ltd
Priority date: 2018-07-20
Filing date: 2018-07-20
Publication date: 2018-12-18

Abstract

本发明实施方式涉及计算机技术领域，公开了一种应用异常处理方法及终端。本发明实施方式中，应用异常处理方法包括：应用程序满足预设异常条件时，应用程序暂停访问缓存文件，并向预设服务器上报异常信息；其中，预设异常条件用于指示应用程序的缓存文件异常；接收到预设服务器下发的补救信息时，执行补救信息。本发明实施方式提升了应用程序的异常处理能力，使得应用程序在陷入重复崩溃的场景时也能够将异常信息进行上报，并能够接收服务器下发的补救信息进行修复，以保证应用程序的稳定性。

Description

应用异常处理方法及终端

技术领域

本发明实施方式涉及计算机技术领域，特别涉及应用异常处理方法及终端。

背景技术

随着终端硬件配置的不断发展，终端上可以运行种类繁多、可实现各种功能的应用程序，比如拍照应用程序、视频应用程序、音乐应用程序或者游戏应用程序等。应用程序在使用过程中，或多或少会出现一些异常崩溃的场景，大多数异常崩溃的场景都只是造成应用程序闪退，用户只需重启即可恢复正常使用。因此，大部分开发人员只对这种异常崩溃的场景做了处理，即，应用程序将发生异常时产生的异常信息保存下来，通过某种渠道反馈给开发人员，以便于开发人员根据该异常信息开发新版本的应用程序，以克服旧版本的应用程序所存在的问题。

但是，本专利申请的发明人发现：上述技术方案是基于开发人员能够接收到异常崩溃相关信息后及时采取相关措施来解决的。如果应用程序异常崩溃后，用户重新启动应用程序还是发生异常崩溃，即，应用程序反复启动、崩溃时，应用程序就处于瘫痪状态，此时的应用程序是无法正常的上报异常相关信息给服务器来告知开发人员的，也无法接收服务器下发的补救信息进行修复，这种情况严重地影响到了用户的使用体验。

发明内容

本发明实施方式的目的在于提供一种应用异常处理方法及终端，旨在提升应用程序的异常处理能力，使得应用程序在陷入重复崩溃的场景时也能够将异常信息进行上报，并能够接收服务器下发的补救信息进行修复，以保证应用程序的稳定性。

为解决上述技术问题，本发明的实施方式提供了一种应用异常处理方法，包括：

应用程序满足预设异常条件时，应用程序暂停访问缓存文件，并向预设服务器上报异常信息；

接收到预设服务器下发的补救信息时，执行补救信息。

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

至少一个处理器；以及，

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

存储器存储有可被至少一个处理器执行的指令，指令被至少一个处理器执行，以使至少一个处理器能够执行上述的应用异常处理方法。

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

本发明实施方式相对于现有技术而言，在应用程序满足预设异常条件时，判定应用程序陷入了由于缓存文件异常所导致的重复崩溃场景，此时中断应用程序的正常行为—令应用程序暂停访问缓存文件，以避免应用程序再次因访问缓存文件而崩溃，同时，应用程序向预设服务器上报异常信息，以便于开发人员根据异常信息进行补救，令应用程序在接收到预设服务器下发的补救信息时，及时地执行补救信息，从而实现应用异常处理。这样，应用程序在陷入重复崩溃的场景时也能够将异常信息进行上报，并能够接收服务器下发的补救信息进行修复，有效地保证了应用程序的稳定性。通过这种方式，增加了依靠服务器进行异常修复的可能性，避免了用户手动进行修复所导致的缓存数据被全部清除的情况，应用程序的服务质量与用户需求的匹配度较高。

另外，预设异常条件为以下条件的其中之一：崩溃频率大于预设频率、崩溃次数大于预设次数。这样，提供了预设异常条件的几种具体实现形式，增加了本发明实施方式的灵活性。

另外，应用程序满足预设异常条件时，应用程序展示用户交互界面。这样，用户能够通过用户交互界面及时地获知较多的有效信息，用户体验较好。

另外，应用程序展示用户交互界面具体包括：应用程序在用户交互界面中展示提示信息；若预设时长内未接收到预设服务器下发的补救信息，则在用户交互界面中展示预设控件；其中，预设控件用于引导用户手动清空所述缓存文件。这样，应用程序在长时间未接收到预设服务器下发的补救信息时，能够通过预设控件给用户进行操作引导，以便于用户手动控制应用程序进行异常修复，从而令应用程序有多种可修复方案，进一步地提升了应用程序的稳定性。

另外，补救信息为运维人员发布的数据；执行补救信息具体包括：获取缓存文件中的异常数据；利用运维人员发布的数据覆盖异常数据。这样，提供了补救信息一种具体实现形式，增加了本发明实施方式的灵活性。

另外，补救信息为开发人员发布的补丁包；执行补救信息具体包括：利用补丁包对应用程序进行升级修复。这样，提供了补救信息一种具体实现形式，增加了本发明实施方式的灵活性。

附图说明

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

图1是本发明第一实施方式提供的应用异常处理系统的结构示意图；

图2是本发明第一实施方式提供的应用异常处理方法的实现流程示意图；

图3是本发明第一实施方式提供的应用程序实现自身异常修复的功能模块示意图；

图4是本发明第二实施方式提供的应用异常处理方法的流程示意图；

图5是本发明第三实施方式提供的终端的结构示意图。

具体实施方式

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

本发明第一实施方式提出了一种应用异常处理系统(如图1所示)以及一种应用异常处理方法(具体流程如图2所示)。本实施方式中的应用异常处理系统包括电子设备1以及预设服务器2，电子设备1上运行有应用程序，该应用程序能够执行上述的应用异常处理方法，将异常信息上传给预设服务器2，以便于预设服务器2能够将接收到的异常信息传输给相关技术人员进行查看，令相关技术人员提出解决方案，并通过预设服务器2下发补救信息，从而令应用程序能够根据该补救信息，实现自身异常的修复，保证后续的正常运行。其中，电子设备1可以是手机、平板电脑等移动终端。

以下对本实施方式中应用异常处理方法进行具体说明，步骤如下：

步骤101，应用程序满足预设异常条件时，应用程序暂停访问缓存文件，并向预设服务器上报异常信息。

具体地说，预设异常条件可以由开发人员预先设置并保存在应用程序中。其中，预设异常条件用于指示应用程序的缓存文件异常。如，本发明发明人发现，应用程序会陷入重复崩溃的场景的主要原因为代码问题或缓存文件异常。

(1)代码问题：应用程序启动，运行到该段代码时就崩溃。也就是说，应用程序陷入重复崩溃将会是必现的场景，因而开发人员在应用程序的开发过程中或者测试人员在对应用程序测试时会很容易发现这一情况，因此，因代码问题所导致的应用异常会被开发人员及时解决，并不会带到正式发布的应用程序中。

(2)缓存文件异常：由于开发人员以及测试人员基本都是基于应用程序与服务器正常交互行为的前提下进行开发和测试的，即使测试用例有涉及服务器下发不规范数据的场景，也仅仅会对一些重要字段进行测试，要做到对服务器下发的数据不规范场景进行用例全覆盖测试，工作量非常巨大，不够现实。因而，缓存文件异常所导致的应用异常很难在开发过程或者测试过程中被发现，缓存文件异常所导致的应用程序重复崩溃的情况很难被完全杜绝。

并且，本发明发明人发现，缓存文件异常之所以会导致的应用程序重复崩溃的原因在于：应用程序启动后会优先拉取缓存文件中的数据进行使用(如，根据缓存文件中的数据进行页面布局)，以保证用户的良好使用体验。一旦缓存文件中存在异常数据，则应用程序启动后拉取缓存文件中的数据进行使用就会出现异常，从而出现应用程序崩溃，用户重新启动应用还是异常崩溃的场景。因此，基于上述内容，预设异常条件可以为崩溃频率大于预设频率或者崩溃次数大于预设次数，从而能够判断出应用程序是否陷入由于缓存文件异常所导致的异常崩溃的场景。

更具体地说，应用程序满足预设异常条件时，说明应用程序陷入了由于缓存文件异常所导致的异常崩溃的场景。此时，应用程序暂停访问缓存文件，以避免应用程序再次去缓存文件拉取数据，造成应用程序再次崩溃、无法上报信息的情况。并且，应用程序还在异常崩溃时，收集相关信息、分析崩溃原因，并将这些信息作为异常信息上报给预设服务器，为后续及时接收服务器下发的补救信息提供数据基础。如，应用程序可以在满足预设异常条件时，利用两条并行的线程分别处理：暂停访问缓存文件的事件、向预设服务器上报异常信息的事件，或者，应用程序可以优先令某一线程执行暂停访问缓存文件的事件，而后再执行向预设服务器上报异常信息的事件，对此，本实施方式并不对此做任何限定。

步骤102，接收到预设服务器下发的补救信息时，执行补救信息。

具体地说，缓存文件之所以会出现问题，一般是由于运维人员操作不当，或者由于预设服务器的一些状态导致下发的数据出现异常。因此，补救信息可以为运维人员发布的数据。这样，应用程序便可以利用运维人员发布的正确数据来覆盖缓存文件中的异常数据，从而实现缓存文件异常的修复。或者，补救信息可以为开发人员发布的补丁包，以便于应用程序及时地利用补丁包进行升级修复，实现异常崩溃问题的解决。

不难看出，上述内容都是从方法的角度对应用程序执行应用异常处理方法，实现自身的异常修复进行说明，为了使读者更好地理解本申请，以下从功能模块的角度，对本实施方式中应用程序实现自身的异常修复进行说明：

具体地说，应用程序可以通过四个功能模块实现自身的异常修复功能，如图3所示，分别为异常捕获模块201、采集模块202、中断模块203以及修复模块204。其中，异常捕获模块201用于捕获应用程序出现异常的场景，采集模块202用于在应用程序出现异常时，采集相关信息、分析崩溃原因，获取异常信息，中断模块203用于根据异常捕获模块201所捕获的应用程序出现异常的场景，判断应用程序是否满足预设异常条件，并在应用程序满足预设异常条件时，令应用程序暂停访问缓存文件。修复模块204用于将采集模块202所获取的异常信息进行上报，并在接收到预设服务器2下发的补救信息时，执行补救信息，从而实现应用程序的修复。

需要注意的是，上述涉及到的各模块均为逻辑模块，在实际应用中，一个逻辑单元可以是一个物理单元，也可以是一个物理单元的一部分，还可以以多个物理单元的组合实现。此外，为了突出本发明的创新部分，本实施方式中并没有将与解决本发明所提出的技术问题关系不太密切的单元引入，但这并不表明本实施方式中不存在其它的单元。

本发明实施方式相对于现有技术而言，应用程序满足预设异常条件时，判定自身陷入了由于缓存文件异常所导致的重复崩溃场景，此时应用程序中断正常行为—暂停访问缓存文件，以避免再次因访问缓存文件而崩溃，并且，应用程序还向预设服务器上报异常信息，以便于开发人员根据异常信息进行补救，令应用程序在接收到预设服务器下发的补救信息时，及时地执行补救信息，从而实现应用异常处理。这样，应用程序在陷入重复崩溃的场景时也能够将异常信息进行上报，并能够接收服务器下发的补救信息进行修复，有效地保证了应用程序的稳定性。通过这种方式，增加了依靠服务器进行异常修复的可能性，尽可能地避免了用户手动进行修复所导致的缓存数据被全部清除的情况，应用程序的服务质量与用户需求的匹配度较高。

本发明的第二实施方式涉及一种应用异常处理方法，具体流程如图4所示。第二实施方式在第一实施方式的基础上加以改进，主要改进之处在于：在本发明第二实施方式中，应用程序在满足预设异常条件时，还展示用户交互界面，以便于及时地将相关信息告知给用户。以下进行具体说明：

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

步骤301，应用程序满足预设异常条件时，应用程序暂停访问缓存文件，向预设服务器上报异常信息，并展示用户交互界面。

具体地说，应用程序在满足预设异常条件时，应用程序可以利用三条并行的线程分别处理：暂停访问缓存文件的事件、向预设服务器上报异常信息的事件以及展示用户交互界面的事件。或者，应用程序可以优先令某一线程执行暂停访问缓存文件的事件，而后再执行向预设服务器上报异常信息的事件以及展示用户交互界面的事件，本实施方式中并不对此做任何限定。

更具体地说，用户交互界面可以包括提示信息，该提示信息用于提示用户应用程序正在积极修复中，从而能够降低用户强制退出应用程序，造成应用异常处理中断的可能性。在实际操作时，用户交互界面还可以展示预设控件，以便于引导用户手动清空缓存文件。如，预设控件可以为按键，该按键被选中时，则应用程序自动清空缓存文件。这样，应用程序的缓存文件被清空时，应用程序就会自动地向预设服务器拉取正确的缓存数据，以解决应用程序反复崩溃的问题。通过这种方式，利用预设控件给用户进行操作引导，以便于用户手动控制应用程序进行异常修复，从而令应用程序有多种可修复方案，进一步地提升了应用程序的稳定性。

本实施方式中，应用程序在展示用户交互界面时，应用程序优先在用户交互界面中展示提示信息。若应用程序在预设时长内未接收到预设服务器下发的补救信息，则应用程序再在用户交互界面展示预设控件，以避免用户根据预设控件的引导，直接控制应用程序删除缓存文件，从而令历史操作、用户习惯之类的有用缓存数据也被一并清除，进一步地提升了依靠服务器进行异常修复的可能性，有效地保证了应用程序的服务质量与用户需求的高匹配度。其中，预设时长可以由开发人员预先设置并保存在应用程序中。

本实施方式相对于第一实施方式而言，应用程序具有更多的可修复方案，进一步地提高了应用程序的稳定性。

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

本发明第三实施方式涉及一种终端，如图5所示。本实施方式中的终端可以理解为第一实施方式中的电子设备1，该终端包括至少一个处理器401；以及，与至少一个处理器401通信连接的存储器402；其中，用户在终端上成功安装能够执行上述方法实施方式中的应用程序时，终端的存储器402存储有可被至少一个处理器401执行的指令，以便于在指令被至少一个处理器401执行时，能够实现上述方法实施方式中的应用异常处理方法。

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

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

本发明实施方式相当于现有技术而言，能够提升应用程序的异常处理能力，使得应用程序在陷入重复崩溃的场景时也能够将异常信息进行上报，并能够接收服务器下发的补救信息进行修复，以保证应用程序的稳定性。

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

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

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

Claims

1.一种应用异常处理方法，其特征在于，包括：

应用程序满足预设异常条件时，所述应用程序暂停访问缓存文件，并向预设服务器上报异常信息；其中，所述预设异常条件用于指示所述应用程序的缓存文件异常；

接收到所述预设服务器下发的补救信息时，执行所述补救信息。

2.根据权利要求1所述的应用异常处理方法，其特征在于，所述预设异常条件为以下条件的其中之一：崩溃频率大于预设频率、崩溃次数大于预设次数。

3.根据权利要求1所述的应用异常处理方法，其特征在于，还包括：

应用程序满足预设异常条件时，所述应用程序展示用户交互界面。

4.根据权利要求3所述的应用异常处理方法，其特征在于，所述应用程序展示用户交互界面具体包括：

在所述用户交互界面中展示提示信息；

若预设时长内未接收到所述预设服务器下发的补救信息，则在所述用户交互界面中展示预设控件；其中，所述预设控件用于引导用户手动清空所述缓存文件。

5.根据权利要求1所述的应用异常处理方法，其特征在于，所述补救信息为运维人员发布的数据；

所述执行所述补救信息具体包括：

获取所述缓存文件中的异常数据；

利用所述运维人员发布的数据覆盖所述异常数据。

6.根据权利要求1所述的应用异常处理方法，其特征在于，所述补救信息为开发人员发布的补丁包；

所述执行所述补救信息具体包括：

利用所述补丁包对所述应用程序进行升级修复。

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

至少一个处理器；以及，

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

所述存储器存储有可被所述至少一个处理器执行的指令，所述指令被所述至少一个处理器执行，以使所述至少一个处理器能够执行如权利要求1至6中任一所述的应用异常处理方法。

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