APP异常处理方法、装置以及存储介质与流程

本申请涉及计算机技术领域，特别是涉及一种app异常处理方法、装置以及存储介质。

背景技术：

灰度发布是指在软件版本发布过程中，能够平滑过渡的一种发布方式。假设当前软件版本是a，新的软件版本是b，当用户通过客户端向服务器发送针对该软件的请求消息时，服务器控制一部分用户继续使用版本a，另一部分用户开始使用版本b。如果用户在使用版本b的过程中没有出现异常，则逐步将所有用户都迁移到版本b。

因此，在app灰度发布后，开发人员需要时刻关注线上情况，通过各个渠道去获取app运行信息，判断app是否出现异常。在出现异常的情况下，需要立即停止向其他用户发布。其中，获取信息渠道有论坛、在线客服以及第三方统计平台。如果借助第三方统计平台，则需要开发人员手动刷新页面来获取异常信息。

针对上述的现有技术中存在的在app灰度发布后需要开发人员手动获取异常信息并时刻关注app的运行是否异常，从而花费大量的人力资源的技术问题，目前尚未提出有效的解决方案。

技术实现要素：

本公开的实施例提供了一种app异常处理方法、装置以及存储介质，以至少解决现有技术中存在的在app灰度发布后需要开发人员手动获取异常信息并时刻关注app的运行是否异常，从而花费大量的人力资源的技术问题。

根据本公开实施例的一个方面，提供了一种app异常处理方法，包括：由服务器从接口接收与app运行异常相关的异常信息，其中app已被预先灰度发布至一测试用户群；根据异常信息，由服务器基于预设的判定规则自动判定app的异常是否属于偶然异常；以及在app的异常不属于偶然异常的情况下，由服务器产生一警告信息。

根据本公开实施例的另一方面，还提供了一种app异常处理方法，包括：在终端设备上的app运行异常的情况下，由终端设备响应于用户输入的将异常信息上报的指令，获取与app运行异常相关的异常信息；以及由终端设备通过接口将异常信息发送至远程的服务器。

根据本公开实施例的另一个方面，还提供了一种存储介质，存储介质包括存储的程序，其中，在程序运行时由处理器执行以上任意一项所述的方法。

根据本公开实施例的另一个方面，还提供了一种app异常处理装置，包括：接收模块，用于从接口接收与app运行异常相关的异常信息，其中app已被预先灰度发布至一测试用户群；判定模块，用于根据异常信息，基于预设的判定规则自动判定app的异常是否属于偶然异常；以及产生模块，用于在app的异常不属于偶然异常的情况下，产生一警告信息。

根据本公开实施例的另一个方面，还提供了一种app异常处理装置，包括：获取模块，用于在app运行异常的情况下，响应于用户输入的将异常信息上报的指令，获取与app运行异常相关的异常信息；以及发送模块，用于通过接口将异常信息发送至远程的服务器。

根据本公开实施例的另一个方面，还提供了一种app异常处理装置，包括：第一处理器；以及第一存储器，与第一处理器连接，用于为第一处理器提供处理以下处理步骤的指令：从接口接收与app运行异常相关的异常信息，其中app已被预先灰度发布至一测试用户群；根据异常信息，基于预设的判定规则自动判定app的异常是否属于偶然异常；以及在app的异常不属于偶然异常的情况下，产生一警告信息。

根据本公开实施例的另一个方面，还提供了一种app异常处理装置，包括：第二处理器；以及第二存储器，与第二处理器连接，用于为第二处理器提供处理以下处理步骤的指令：在app运行异常的情况下，响应于用户输入的将异常信息上报的指令，获取与app运行异常相关的异常信息；以及通过接口将异常信息发送至远程的服务器。

在本公开实施例中，在app异常的情况下，用户可以通过接口上报的形式由终端设备将异常信息发送至服务器，再由服务器通过接口接收异常数据，使得开发人员不再需要手动采集数据。然后由服务器根据接收到的异常信息，自动判定本次异常是否属于偶然异常。只有在属于非偶然异常的情况下，服务器才会生成产生警告信息，用以提示相关的工作人员。使得开发人员并不需要时刻关注app的运行情况，而是由服务器基于预设的判定规则自动对app的运行情况进行监控和判定，只有在异常属于非偶然异常的情况下，即服务器产生一警告信息的情况下，工作人员才需要进行相关的异常处理。从而达到了在app灰度发布后不再需要开发人员手动获取异常信息，也不需要时刻关注app的运行是否异常，节省了大量的人力资源的技术效果。进而解决了在app灰度发布后需要开发人员手动获取异常信息并时刻关注app的运行是否异常，从而花费大量的人力资源的技术问题。

附图说明

此处所说明的附图用来提供对本公开的进一步理解，构成本申请的一部分，本公开的示意性实施例及其说明用于解释本公开，并不构成对本公开的不当限定。在附图中：

图1是用于实现根据本公开实施例1所述的方法的计算设备的硬件结构框图；

图2是根据本公开实施例1所述的app异常处理系统的示意图；

图3是根据本公开实施例1的第一个方面所述的app异常处理方法的流程示意图；

图4是根据本公开实施例1的第一个方面所述的app异常处理流程的示意图；

图5是根据本公开实施例1的第二个方面所述的app异常处理方法的流程示意图；

图6是根据本公开实施例2的第一个方面所述的app异常处理装置的示意图；

图7是根据本公开实施例2的第二个方面所述的app异常处理装置的示意图；

图8是根据本公开实施例3的第一个方面所述的app异常处理装置的示意图；以及

图9是根据本公开实施例3的第二个方面所述的app异常处理装置的示意图。

具体实施方式

为了使本技术领域的人员更好地理解本公开的技术方案，下面将结合本公开实施例中的附图，对本公开实施例中的技术方案进行清楚、完整地描述。显然，所描述的实施例仅仅是本公开一部分的实施例，而不是全部的实施例。基于本公开中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都应当属于本公开保护的范围。

需要说明的是，本公开的说明书和权利要求书及上述附图中的术语“第一”、“第二”等是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的本公开的实施例能够以除了在这里图示或描述的那些以外的顺序实施。此外，术语“包括”和“具有”以及他们的任何变形，意图在于覆盖不排他的包含，例如，包含了一系列步骤或单元的过程、方法、系统、产品或设备不必限于清楚地列出的那些步骤或单元，而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或单元。

首先，在对本公开实施例进行描述的过程中出现的部分名词或术语适用于如下解释：

app：本申请中所述的app为“客户端应用程序”的英文翻译。

实施例1

根据本实施例，提供了一种app异常处理方法的实施例，需要说明的是，在附图的流程图示出的步骤可以在诸如一组计算机可执行指令的计算机系统中执行，并且，虽然在流程图中示出了逻辑顺序，但是在某些情况下，可以以不同于此处的顺序执行所示出或描述的步骤。

本实施例所提供的方法实施例可以在移动终端、计算机终端、服务器或者类似的计算设备中执行。图1示出了一种用于实现app异常处理方法的计算设备的硬件结构框图。如图1所示，计算设备可以包括一个或多个处理器(处理器可以包括但不限于微处理器mcu或可编程逻辑器件fpga等的处理装置)、用于存储数据的存储器、以及用于通信功能的传输装置。除此以外，还可以包括：显示器、输入/输出接口(i/o接口)、通用串行总线(usb)端口(可以作为i/o接口的端口中的一个端口被包括)、网络接口、电源和/或相机。本领域普通技术人员可以理解，图1所示的结构仅为示意，其并不对上述电子装置的结构造成限定。例如，计算设备还可包括比图1中所示更多或者更少的组件，或者具有与图1所示不同的配置。

应当注意到的是上述一个或多个处理器和/或其他数据处理电路在本文中通常可以被称为“数据处理电路”。该数据处理电路可以全部或部分的体现为软件、硬件、固件或其他任意组合。此外，数据处理电路可为单个独立的处理模块，或全部或部分的结合到计算设备中的其他元件中的任意一个内。如本公开实施例中所涉及到的，该数据处理电路作为一种处理器控制(例如与接口连接的可变电阻终端路径的选择)。

存储器可用于存储应用软件的软件程序以及模块，如本公开实施例中的app异常处理方法对应的程序指令/数据存储装置，处理器通过运行存储在存储器内的软件程序以及模块，从而执行各种功能应用以及数据处理，即实现上述的应用程序的app异常处理方法。存储器可包括高速随机存储器，还可包括非易失性存储器，如一个或者多个磁性存储装置、闪存、或者其他非易失性固态存储器。在一些实例中，存储器可进一步包括相对于处理器远程设置的存储器，这些远程存储器可以通过网络连接至计算设备。上述网络的实例包括但不限于互联网、企业内部网、局域网、移动通信网及其组合。

传输装置用于经由一个网络接收或者发送数据。上述的网络具体实例可包括计算设备的通信供应商提供的无线网络。在一个实例中，传输装置包括一个网络适配器(networkinterfacecontroller，nic)，其可通过基站与其他网络设备相连从而可与互联网进行通讯。在一个实例中，传输装置可以为射频(radiofrequency，rf)模块，其用于通过无线方式与互联网进行通讯。

显示器可以例如触摸屏式的液晶显示器(lcd)，该液晶显示器可使得用户能够与计算设备的用户界面进行交互。

此处需要说明的是，在一些可选实施例中，上述图1所示的计算设备可以包括硬件元件(包括电路)、软件元件(包括存储在计算机可读介质上的计算机代码)、或硬件元件和软件元件两者的结合。应当指出的是，图1仅为特定具体实例的一个实例，并且旨在示出可存在于上述计算设备中的部件的类型。

图2是根据本实施例所述的app异常处理系统的示意图。参照图2所示，该系统包括：服务器200、终端设备100以及终端设备300。其中，服务器200具有自动判定app的异常是否为偶然异常的功能，终端设备100为负责关注app上线状态的开发人员或者工作人员(即，用户110)的终端设备，终端设备300上运行有app(客户端应用程序)，为app的用户(即，用户120)的终端设备。需要说明的是，系统中的服务器200、终端设备100以及终端设备300均可适用上面所述的硬件结构。

在上述运行环境下，根据本实施例的第一个方面，提供了一种app异常处理方法，该方法由图2中所示的服务器200实现。图3示出了该方法的流程示意图，参考图3所示，该方法包括：

s302：由服务器从接口接收与app运行异常相关的异常信息，其中app已被预先灰度发布至一测试用户群；

s304：根据异常信息，由服务器基于预设的判定规则自动判定app的异常是否属于偶然异常；以及

s306：在app的异常不属于偶然异常的情况下，由服务器产生一警告信息。

正如前面背景技术中所述的，灰度发布是指在软件版本发布过程中，能够平滑过渡的一种发布方式。假设当前软件版本是a，新的软件版本是b，当用户通过客户端向服务器发送针对该软件的请求消息时，服务器控制一部分用户继续使用版本a，另一部分用户开始使用版本b。如果用户在使用版本b的过程中没有出现异常，则逐步将所有用户都迁移到版本b。因此，在app灰度发布后，开发人员需要时刻关注线上情况，通过各个渠道去获取app运行信息，判断app是否出现异常。在出现异常的情况下，需要立即停止向其他用户发布。其中，获取信息渠道有论坛、在线客服以及第三方统计平台。如果借助第三方统计平台，则需要开发人员手动刷新页面来获取异常信息。

针对上述背景技术中存在的问题，结合图2所示，用户120在使用app的过程中出现异常状况(例如，异常闪退)的情况下，用户120可以通过终端设备300以接口上报的形式将与异常闪退相关的异常信息发送至服务器200。此时，服务器200从接口接收从app上报的与app运行异常(异常闪退)相关的异常信息。其中所述app已被预先灰度发布至一测试用户群。然后，服务器200根据所述异常信息，基于预设的判定规则自动判定所述app的异常是否属于偶然异常。最后，服务器200在判定所述app的异常不属于偶然异常的情况下，产生一警告信息。

从而，通过接口接收异常数据的方式，使得开发人员不再需要手动采集数据。然后由服务器200根据接收到的异常信息，自动判定本次异常是否属于偶然异常。只有在属于非偶然异常的情况下，服务器200才会生成产生警告信息，用以提示相关的工作人员。使得开发人员并不需要时刻关注app的运行情况，而是由服务器200基于预设的判定规则自动对app的运行情况进行监控和判定，只有在异常属于非偶然异常的情况下，即服务器200产生一警告信息的情况下，工作人员才需要进行相关的异常处理。从而达到了在app灰度发布后不再需要开发人员手动获取异常信息，也不需要时刻关注app的运行是否异常，节省了大量的人力资源的技术效果。进而解决了在app灰度发布后需要开发人员手动获取异常信息并时刻关注app的运行是否异常，从而花费大量的人力资源的技术问题。

可选地，判定规则包括：测试用户群中发送同类的异常信息的用户数量或用户比例是否大于预设的阈值；其中，在判定规则的结果为是时，服务器判定该同类的异常信息为非偶然异常。

具体地，图4示出了app异常处理流程的示意图。参照图4所示，判定规则包括：测试用户群中发送同类的异常信息的用户数量或用户比例是否大于预设的阈值。例如：服务器200首先判定上报app运行异常相关的异常信息的用户是否为测试用户群(即，app灰度发布对象的灰度用户)，然后判定是否接收到同类的异常信息(即，判定是否有同类异常用户)，最后判定同类异常用户的用户数量或用户比例是否大于(超过)预设的阈值。此外，在判定规则的结果为是时，服务器200判定该同类的异常信息为非偶然异常。从而，通过这种方式，由服务器200根据接收到的异常信息，自动基于上述的判定规则，完成对该异常信息是否属于偶然异常的判定。

进一步地，判定规则还包括：异常信息的等级是否大于预设的异常等级；其中，在判定规则的结果为是时，服务器判定该同类的异常信息为非偶然异常。

具体地，可以根据异常信息的异常程度，预先对异常信息进行等级的划分。例如但不限于，将与异常闪退相关的异常信息划分为a级，将与异常闪屏、黑屏等相关的异常信息划分为b级，将与异常卡顿相关的异常信息划分为c级。然后，服务器200首先判定接收到的异常信息的等级是否大于预设的异常等级(例如：b级)。在判定规则的结果为是时，服务器200判定该同类的异常信息为非偶然异常。

此外，服务器200还可以根据不同等级的异常信息，配置不同的报警方式以及进行不同频次的报警。例如：在判定异常信息的等级为a级时，服务器200可以选择立即鸣笛+大写显示异常信息的方式进行报警，同时还以邮件的方式将异常信息发送至相关人员的邮箱。在判定异常信息的等级为b级时，服务器200以邮件的方式将异常信息发送至相关人员的邮箱。在判定异常信息的等级为c级时，服务器200以微信推送的方式将异常信息发送至相关人员的微信上。同样的，服务器200可以根据异常信息的等级的高低，进行不同频次的报警操作。例如：异常信息的等级越高，服务器200的报警频次越高，反之则否。

可选地，判定规则包括：测试用户群中在规定时间段内发送同类的异常信息的用户数量或用户比例是否大于预设的阈值；其中，在判定规则的结果为是时，服务器判定该同类的异常信息为非偶然异常。

具体地，由于不同规模等级的app，在灰度发布时，灰度发布的对象(即，测试用户群)的大小各有不用，同时用户的使用频率也具有很大的差异性。在所灰度发布的app规模等级较大，测试用户群的量级较高以及用户使用频率较高时判定规则包括：测试用户群中在规定时间段内发送同类的异常信息的用户数量或用户比例是否大于预设的阈值。通过这种方式，使得服务器200基于该判定规则判定得到的结果更加的准确和有效。

可选地，判定规则由服务器按照预定的周期进行调用。通过这种方式，服务器200会按照预定的周期调用判定规则，自动判定测试用户群中发送同类的异常信息的用户数量或用户比例是否大于预设的阈值。

可选地，还包括：由服务器存储异常信息，并更新该同类的异常信息。通过这种方式，服务器200不断的对同类的异常信息进行更新，进而在接收到下一个异常信息时，保障了服务器200在判定的过程中使用的同类的异常信息的完整性以及最新性，进而保障了判定结果的准确性。

可选地，还包括：由服务器将警告信息通过邮件的方式发送至相关的工作人员的终端设备。具体地，服务器200在产生一警告信息之后，可以通过邮件的方式发送至相关的工作人员的终端设备。例如：通过邮件的方式将该警告信息发送至用户110的终端设备300。使得相关的工作人员能够及时的对app的异常进行处理。

此外，根据本实施例的第二个方面，提供了一种app异常处理方法，该方法由图2中所示的终端设备300实现。图5示出了该方法的流程示意图，参考图5所示，该方法包括：

s502：在终端设备上的app运行异常的情况下，由终端设备响应于用户输入的将异常信息上报的指令，获取与app运行异常相关的异常信息；以及

s504：由终端设备通过接口将异常信息发送至远程的服务器。

具体地，参照图2以及图5所示，终端设备300上运行有一个app，在app运行异常的情况下，终端设备300响应于用户120输入的将异常信息上报的指令，获取与app运行异常相关的异常信息。然后通过接收上报的形式，将异常信息发送至远程的服务器200。使得服务器200可以根据接收到的异常信息，基于预设的判定规则自动判定所述app的异常是否属于偶然异常，从而进行相应的异常警告处理。从而达到了在app灰度发布后不再需要开发人员手动获取异常信息，也不需要时刻关注app的运行是否异常，节省了大量的人力资源的技术效果。进而解决了在app灰度发布后需要开发人员手动获取异常信息并时刻关注app的运行是否异常，从而花费大量的人力资源的技术问题。

可选地，获取与app运行异常相关的异常信息的操作，包括：由终端设备获取与app运行异常相关的异常堆栈信息；以及利用预设的筛选规则，由终端设备对异常堆栈信息进行筛选，得到异常信息。

具体地，终端设备300首先获取与app运行异常相关的异常堆栈信息，然后利用预设的筛选规则，对异常堆栈信息进行筛选，得到异常信息。其中，预设的筛选规则例如但不限于为：仅筛选出程序包内的异常信息。通过这种将筛选好的异常信息发送至服务器200的方式，可以减轻服务器的工作负担。

可选地，由终端设备通过接口将异常信息发送至远程的服务器的操作之前，还包括：由终端设备基于预设的加密算法，对异常信息进行加密；其中，加密算法包括信息摘要算法。

具体地，终端设备300在将异常信息发送至服务器200之前，基于信息摘要算法，对该异常信息进行加密。通过这种方式，保障了发送至服务器200的异常信息的安全性。

此外，参考图1所示，根据本实施例的第三个方面，提供了一种存储介质。存储介质包括存储的程序，其中，在程序运行时由处理器执行以上任意一项所述的方法。

从而根据本实施例，在app异常的情况下，用户120可以通过接口上报的形式由终端设备300将异常信息发送至服务器200，再由服务器200通过接口接收异常数据，使得开发人员不再需要手动采集数据。然后由服务器200根据接收到的异常信息，自动判定本次异常是否属于偶然异常。只有在属于非偶然异常的情况下，服务器200才会生成产生警告信息，用以提示相关的工作人员。使得开发人员并不需要时刻关注app的运行情况，而是由服务器200基于预设的判定规则自动对app的运行情况进行监控和判定，只有在异常属于非偶然异常的情况下，即服务器200产生一警告信息的情况下，工作人员才需要进行相关的异常处理。从而达到了在app灰度发布后不再需要开发人员手动获取异常信息，也不需要时刻关注app的运行是否异常，节省了大量的人力资源的技术效果。进而解决了在app灰度发布后需要开发人员手动获取异常信息并时刻关注app的运行是否异常，从而花费大量的人力资源的技术问题。

需要说明的是，对于前述的各方法实施例，为了简单描述，故将其都表述为一系列的动作组合，但是本领域技术人员应该知悉，本发明并不受所描述的动作顺序的限制，因为依据本发明，某些步骤可以采用其他顺序或者同时进行。其次，本领域技术人员也应该知悉，说明书中所描述的实施例均属于优选实施例，所涉及的动作和模块并不一定是本发明所必须的。

通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到根据上述实施例的方法可借助软件加必需的通用硬件平台的方式来实现，当然也可以通过硬件，但很多情况下前者是更佳的实施方式。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质(如rom/ram、磁碟、光盘)中，包括若干指令用以使得一台终端设备(可以是手机，计算机，服务器，或者网络设备等)执行本发明各个实施例所述的方法。

实施例2

图6示出了根据本实施例的第一个方面所述的app异常处理装置600，该装置600与根据实施例1的第一个方面所述的方法相对应。参考图6所示，该装置600包括：接收模块610，用于从接口接收与app运行异常相关的异常信息，其中app已被预先灰度发布至一测试用户群；判定模块620，用于根据异常信息，基于预设的判定规则自动判定app的异常是否属于偶然异常；以及产生模块630，用于在app的异常不属于偶然异常的情况下，产生一警告信息。

可选地，判定规则包括：测试用户群中发送同类的异常信息的用户数量或用户比例是否大于预设的阈值；其中，在判定规则的结果为是时，判定模块620判定该同类的异常信息为非偶然异常。

可选地，判定规则包括：测试用户群中在规定时间段内发送同类的异常信息的用户数量或用户比例是否大于预设的阈值；其中，在判定规则的结果为是时，判定模块620判定该同类的异常信息为非偶然异常。

可选地，判定规则由判定模块620按照预定的周期进行调用。

可选地，还包括：存储及更新模块，用于存储异常信息，并更新该同类的异常信息。

可选地，还包括：邮件发送模块，用于将警告信息通过邮件的方式发送至相关的工作人员的终端设备。

此外，图7示出了根据本实施例的第二个方面所述的app异常处理装置700，该装置700与根据实施例1的第二个方面所述的方法相对应。参考图7所示，该装置700包括：获取模块710，用于在app运行异常的情况下，响应于用户输入的将异常信息上报的指令，获取与app运行异常相关的异常信息；以及发送模块720，用于通过接口将异常信息发送至远程的服务器。

可选地，获取模块710包括：获取子模块，用于获取与app运行异常相关的异常堆栈信息；以及筛选子模块，用于利用预设的筛选规则，对异常堆栈信息进行筛选，得到异常信息。

可选地，还包括：加密模块，用于在发送模块通过接口将异常信息发送至远程的服务器的操作之前，基于预设的加密算法，对异常信息进行加密；其中，加密算法包括信息摘要算法。

从而根据本实施例，在app异常的情况下，用户可以通过接口上报的形式由装置700将异常信息发送至装置600，再由装置600通过接口接收异常数据，使得开发人员不再需要手动采集数据。然后由装置600根据接收到的异常信息，自动判定本次异常是否属于偶然异常。只有在属于非偶然异常的情况下，装置600才会生成产生警告信息，用以提示相关的工作人员。使得开发人员并不需要时刻关注app的运行情况，而是由装置600基于预设的判定规则自动对app的运行情况进行监控和判定，只有在异常属于非偶然异常的情况下，即装置600产生一警告信息的情况下，工作人员才需要进行相关的异常处理。从而达到了在app灰度发布后不再需要开发人员手动获取异常信息，也不需要时刻关注app的运行是否异常，节省了大量的人力资源的技术效果。进而解决了在app灰度发布后需要开发人员手动获取异常信息并时刻关注app的运行是否异常，从而花费大量的人力资源的技术问题。

实施例3

图8示出了根据本实施例的第一个方面所述的app异常处理装置800，该装置800与根据实施例1的第一个方面所述的方法相对应。参考图8所示，该装置800包括：第一处理器810；以及第一存储器820，与第一处理器810连接，用于为第一处理器810提供处理以下处理步骤的指令：从接口接收与app运行异常相关的异常信息，其中app已被预先灰度发布至一测试用户群；根据异常信息，基于预设的判定规则自动判定app的异常是否属于偶然异常；以及在app的异常不属于偶然异常的情况下，产生一警告信息。

可选地，判定规则包括：测试用户群中发送同类的异常信息的用户数量或用户比例是否大于预设的阈值；其中，在判定规则的结果为是时，判定该同类的异常信息为非偶然异常。

可选地，判定规则包括：测试用户群中在规定时间段内发送同类的异常信息的用户数量或用户比例是否大于预设的阈值；其中，在判定规则的结果为是时，判定该同类的异常信息为非偶然异常。

可选地，判定规则由装置800按照预定的周期进行调用。

可选地，第一存储器820还用于为第一处理器810提供处理以下处理步骤的指令：存储异常信息，并更新该同类的异常信息。

可选地，第一存储器820还用于为第一处理器810提供处理以下处理步骤的指令：将警告信息通过邮件的方式发送至相关的工作人员的终端设备。

此外，图9示出了根据本实施例的第二个方面所述的app异常处理装置900，该装置900与根据实施例1的第二个方面所述的方法相对应。参考图9所示，该装置900包括：第二处理器910；以及第二存储器920，与第二处理器910连接，用于为第二处理器910提供处理以下处理步骤的指令：在app运行异常的情况下，响应于用户输入的将异常信息上报的指令，获取与app运行异常相关的异常信息；以及通过接口将异常信息发送至远程的服务器。

可选地，获取与app运行异常相关的异常信息的操作，包括：获取与app运行异常相关的异常堆栈信息；以及利用预设的筛选规则，对异常堆栈信息进行筛选，得到异常信息。

可选地，第二存储器920还用于为第二处理器910提供处理以下处理步骤的指令：通过接口将异常信息发送至远程的服务器的操作之前，基于预设的加密算法，对异常信息进行加密；其中，加密算法包括信息摘要算法。

从而根据本实施例，在app异常的情况下，用户可以通过接口上报的形式由装置900将异常信息发送至装置800，再由装置800通过接口接收异常数据，使得开发人员不再需要手动采集数据。然后由装置800根据接收到的异常信息，自动判定本次异常是否属于偶然异常。只有在属于非偶然异常的情况下，装置800才会生成产生警告信息，用以提示相关的工作人员。使得开发人员并不需要时刻关注app的运行情况，而是由装置800基于预设的判定规则自动对app的运行情况进行监控和判定，只有在异常属于非偶然异常的情况下，即装置800产生一警告信息的情况下，工作人员才需要进行相关的异常处理。从而达到了在app灰度发布后不再需要开发人员手动获取异常信息，也不需要时刻关注app的运行是否异常，节省了大量的人力资源的技术效果。进而解决了在app灰度发布后需要开发人员手动获取异常信息并时刻关注app的运行是否异常，从而花费大量的人力资源的技术问题。

上述本发明实施例序号仅仅为了描述，不代表实施例的优劣。

在本发明的上述实施例中，对各个实施例的描述都各有侧重，某个实施例中没有详述的部分，可以参见其他实施例的相关描述。

在本申请所提供的几个实施例中，应该理解到，所揭露的技术内容，可通过其它的方式实现。其中，以上所描述的装置实施例仅仅是示意性的，例如所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，单元或模块的间接耦合或通信连接，可以是电性或其它的形式。

所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。

另外，在本发明各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。

所述集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可为个人计算机、服务器或者网络设备等)执行本发明各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：u盘、只读存储器(rom，read-onlymemory)、随机存取存储器(ram，randomaccessmemory)、移动硬盘、磁碟或者光盘等各种可以存储程序代码的介质。

以上所述仅是本发明的优选实施方式，应当指出，对于本技术领域的普通技术人员来说，在不脱离本发明原理的前提下，还可以做出若干改进和润饰，这些改进和润饰也应视为本发明的保护范围。