CN113254056A - 一种更新预警及故障修复的方法及设备 - Google Patents

Abstract

本申请实施例公开了一种更新预警及故障修复的方法及设备，涉及电子设备领域，解决了电子设备软件更新后软件存在异常问题时无法及时发现并修复的问题。具体方案为：当第一电子设备的第一软件更新后第一软件出现异常时，第一电子设备向故障监控装置发送异常信息；故障监控装置在根据异常信息确定第一软件存在异常时，向更新服务端发送预警信息；更新服务端根据预警信息对第一软件进行处理。

Description

一种更新预警及故障修复的方法及设备

技术领域

本申请实施例涉及电子设备领域，尤其涉及一种更新预警及故障修复的方法及设备。

背景技术

在手机使用过程中，经常为了增加应用程序的新特性或修复应用程序的漏洞，应用厂家经常会对应用程序的版本进行更新，相应地手机会更新相应的应用程序。通常，手机更新应用程序是在应用市场中进行更新。即当应用市场上架了新版本的应用程序后，手机便可以自动，或者根据用户更新应用程序的操作，从应用市场下载和安装相应的新版本的应用程序。

由于手机平台有很多，并且系统版本也有很多，上架应用市场的应用程序通常很难兼容到所有手机平台和系统版本。所以应用程序上架应用市场后，手机更新的应用程序可能会出现稳定性问题（即应用程序异常），如闪退，崩溃，卡顿，无响应等。一般，为了能够及时发现影响手机用户使用和体验的问题，手机厂家会对应用程序的稳定性等问题和使用情况，进行异常故障和舆情人工监控。即当人工监控到很多用户反馈手机应用程序出现稳定性等问题无法正常使用后，手机厂家会进行排查分析，从而发现是应用程序存在更新了版本后导致的稳定性问题时，即应用程序的新版本存在稳定性问题。此时，可以通知应用厂家对该应用程序进行修复。因此，目前只有在应用市场上架新版本的应用程序较长一段时间后，收到了大量的用户反馈，人工才能根据用户反馈发现相关应用程序存在稳定性问题。该过程，需要依靠人工监控，以及用户自行反馈，耗时较长。

发明内容

本申请实施例提供一种更新预警及故障修复的方法及设备，解决了电子设备软件更新后软件存在异常问题时无法及时发现并修复的问题。

第一方面，本申请实施例提供一种更新预警及故障修复的方法，该方法可以应用于更新预警及故障修复系统，该更新预警及故障修复系统可以包括第一电子设备、故障监控装置和更新服务端，该方法可以包括：当第一电子设备的第一软件更新后第一软件出现异常时，第一电子设备向故障监控装置发送异常信息，异常信息用于指示第一软件更新后出现异常；故障监控装置在根据异常信息确定第一软件存在异常时，向更新服务端发送预警信息，预警信息用于指示第一软件存在异常；更新服务端根据预警信息向第二电子设备发送第一指示，第一指示用于指示第二电子设备停止第一软件的更新；和/或更新服务端根据预警信息替换推送的第一软件到上一版本。

其中，上述的第一软件的更新可以是应用程序或系统的版本更新，冷补丁或热补丁更新，参数或配置文件更新等。

基于第一方面的方法，能够通过故障监控装置对电子设备进行自动监控，当电子设备更新了应用程序或系统之后，应用程序或系统存在问题而发生异常时，故障监控装置能够及时发现异常，时间周期较短。并且能够使应用市场及时做出相应的处理，以避免存在问题的应用程序或者系统的更新继续在众多用户中扩散，减小受到更新影响的用户数量。

结合第一方面，在一种可能的设计方式中，第一软件包括操作系统和/或应用程序。其中，上述的第一软件的更新可以是应用程序或系统的版本更新，冷补丁或热补丁更新，参数或配置文件更新等。

结合第一方面，在另一种可能的设计方式中，异常信息包括第一软件的属性信息。

基于该可能的设计方式，在异常信息中包括第一软件的属性信息，能够便于后续故障监控装置确定发生异常的软件为第一软件。

结合第一方面，在另一种可能的设计方式中，第一软件为应用程序，属性信息包括以下至少一个：应用名称、应用包名、应用版本号、应用分类、应用异常次数、异常进程的应用进程名、异常进程的应用进程信息、第一软件出现异常时的应用生命周期。

基于该可能的设计方式，能够通过属性信息包括的上述信息指示发生异常的第一软件具体的异常进程和异常进程相关的信息，便于后续故障监控装置对根据属性信息准确确定是否对第一软件发生异常进行预警。

结合第一方面，在另一种可能的设计方式中，异常信息还包括第一软件出现的异常的异常类型。

基于该可能的设计方式，通过在异常信息中包括异常类型，能够便于后续故障监控装置根据异常类型确定第一软件发生的具体异常。

结合第一方面，在另一种可能的设计方式中，异常类型包括闪退、崩溃、卡顿、无响应、冻屏中的至少一个。

结合第一方面，在另一种可能的设计方式中，故障监控装置根据异常信息确定第一软件存在异常，包括：故障监控装置根据包含第一软件的属性信息的异常信息的数量确定第一软件的异常次数；当异常次数大于起报阈值时，故障监控装置确定第一软件存在异常。

基于该可能的设计方式，通过第一软件的异常次数与起报阈值的大小来确定第一软件存在异常，相对便捷，能够简化系统设计。

结合第一方面，在另一种可能的设计方式中，起报阈值包括对应于不同预警等级的多个起报阈值；在向更新服务端发送预警信息之前，方法还包括：当异常次数大于起报阈值时，故障监控装置根据异常次数和多个起报阈值确定对第一软件的预警等级；预警信息包括预警等级。

基于该可能的设计方式，将起报阈值设置多个，以根据不同起报阈值确定对第一软件发生异常进行预警的预警等级，能够便于后续更新服务端根据不同的预警等级对第一软件采用不同的方式进行处理。

结合第一方面，在另一种可能的设计方式中，起报阈值为预先设置的；或在故障监控装置确定第一软件存在异常之前，方法还包括：故障监控装置确定第一软件发生异常的平均异常次数；故障监控装置根据平均异常次数和起报倍率确定起报阈值。

基于该可能的设计方式，预设起报阈值相对简单，便于实施。而使故障监控装置根据平均异常次数和起报倍率确定起报阈值，能够使起报阈值根据不同的软件调整不同的起报阈值，从而提高对第一软件发生异常进行预警的准确性。

结合第一方面，在另一种可能的设计方式中，在故障监控装置根据平均异常次数和起报倍率确定起报阈值之前，方法还包括：故障监控装置根据平均异常次数和预设的平均异常次数与起报倍率间的对应关系，确定起报倍率；平均异常次数与起报倍率间的对应关系为反比例关系。

基于该可能的设计方式，通过上述步骤能够使故障监控装置根据不同平均异常次数调整起报倍率，从而避免由于平均异常次数的增大而导致起报阈值大幅增加，出现对第一软件发生异常进行预警漏报的情况。

结合第一方面，在另一种可能的设计方式中，第一软件的属性信息对应设有权重；故障监控装置根据平均异常次数和预设的平均异常次数与起报倍率间的对应关系，确定起报倍率，包括：故障监控装置根据权重调整平均异常次数；故障监控装置根据调整后的平均异常次数和预设的平均异常次数与起报倍率间的对应关系，确定起报倍率。

基于该可能的设计方式，通过根据第一软件的不同属性信息设置的不同权重，对起报倍率进行调整最终起到调整起报阈值的作用，能够使故障监控装置可根据第一软件发生异常的重要程度调整起报阈值，从而提高对第一软件发生异常进行预警的准确性。

结合第一方面，在另一种可能的设计方式中，起报倍率为预先设置的。

结合第一方面，在另一种可能的设计方式中，在故障监控装置在根据异常信息确定第一软件存在异常时，向更新服务端发送预警信息之后，方法还包括：更新服务端根据预警信息向第一软件的厂家发送邮件，邮件用于通知第一软件的厂家第一软件存在异常。

基于该可能的设计方式，通过邮件通知第一软件的厂家第一软件存在异常，能够便于厂家及时发现第一软件存在问题及时修复。

第二方面，本申请实施例提供一种更新预警及故障修复系统，该系统可以包括第一电子设备、故障监控装置和更新服务端；第一电子设备，用于当第一电子设备的第一软件更新后第一软件出现异常时，向故障监控装置发送异常信息，异常信息用于指示第一软件更新后出现异常；故障监控装置，用于在根据异常信息确定第一软件存在异常时，向更新服务端发送预警信息，预警信息用于指示第一软件存在异常；更新服务端，用于根据预警信息向第二电子设备发送第一指示，第一指示用于指示第二电子设备停止第一软件的更新；和/或，根据预警信息替换推送的第一软件到上一版本。

结合第二方面，在一种可能的设计方式中，第一软件包括操作系统和/或应用程序。

结合第二方面，在另一种可能的设计方式中，异常信息包括第一软件的属性信息。

结合第二方面，在另一种可能的设计方式中，第一软件为应用程序，属性信息包括以下至少一个：应用名称、应用包名、应用版本号、应用分类、应用异常次数、异常进程的应用进程名、异常进程的应用进程信息、第一软件出现异常时的应用生命周期。

结合第二方面，在另一种可能的设计方式中，异常信息还包括第一软件出现的异常的异常类型。

结合第二方面，在另一种可能的设计方式中，异常类型包括闪退、崩溃、卡顿、无响应、冻屏中的至少一个。

结合第二方面，在另一种可能的设计方式中，故障监控装置，具体用于根据包含第一软件的属性信息的异常信息的数量确定第一软件的异常次数；当异常次数大于起报阈值时，故障监控装置确定第一软件存在异常。

结合第二方面，在另一种可能的设计方式中，起报阈值包括对应于不同预警等级的多个起报阈值；故障监控装置，还用于当异常次数大于起报阈值时，根据异常次数和多个起报阈值确定对第一软件的预警等级；预警信息包括预警等级。

结合第二方面，在另一种可能的设计方式中，起报阈值为预先设置的；或故障监控装置，还用于确定第一软件发生异常的平均异常次数；根据平均异常次数和起报倍率确定起报阈值。

结合第二方面，在另一种可能的设计方式中，故障监控装置，还用于根据平均异常次数和预设的平均异常次数与起报倍率间的对应关系，确定起报倍率；平均异常次数与起报倍率间的对应关系为反比例关系。

结合第二方面，在另一种可能的设计方式中，第一软件的属性信息对应设有权重；故障监控装置，具体用于根据权重调整平均异常次数；根据调整后的平均异常次数和预设的平均异常次数与起报倍率间的对应关系，确定起报倍率。

结合第二方面，在另一种可能的设计方式中，起报倍率为预先设置的。

结合第二方面，在另一种可能的设计方式中，更新服务端，还用于根据预警信息向第一软件的厂家发送邮件，邮件用于通知第一软件的厂家第一软件存在异常。

第三方面，本申请实施例提供一种电子设备，包括：处理器，用于存储该处理器可执行指令的存储器。该处理器被配置为执行上述指令时，使得该电子设备实现如第一方面中任一项的更新预警及故障修复的方法中第一电子设备的功能。

第四方面，本申请实施例提供一种故障监控装置，包括：处理器，用于存储该处理器可执行指令的存储器。该处理器被配置为执行上述指令时，使得该故障监控装置实现如第一方面中任一项的更新预警及故障修复的方法中故障监控装置的功能。

第五方面，本申请实施例提供一种更新服务端，包括：处理器，用于存储该处理器可执行指令的存储器。该处理器被配置为执行上述指令时，使得该更新服务端实现如第一方面中任一项的更新预警及故障修复的方法中更新服务端的功能。

第六方面，本申请实施例提供一种计算机可读存储介质，用于存储上述第三方面的电子设备、第四方面的故障监控装置或第五方面的更新服务端的可执行指令。

第七方面，本申请实施例提供一种计算机程序产品，包括上述第三方面的电子设备、第四方面的故障监控装置或第五方面的更新服务端的可执行指令。

应当理解的是，上述第二方面至第七方面的有益效果可以参见上述第一方面中的相关描述，在此不再赘述。

附图说明

图1为相关技术提供的一种更新预警及故障修复的方法的流程示意图；

图2为本申请实施例提供的一种电子设备的结构示意图；

图3为本申请实施例提供的一种更新预警及故障修复的方法的流程示意图；

图4为本申请实施例提供的一种更新应用程序的界面示意图；

图5为本申请实施例提供的另一种更新应用程序的界面示意图；

图6为本申请实施例提供的一种起报倍率与基线数量的对应关系的示意图。

具体实施方式

电子设备，如手机，可穿戴设备等，一般通过内部安装的各种应用程序（application，APP）来实现丰富的功能。为了增加应用程序的新特性或修复应用程序的漏洞等，应用厂家经常会对应用程序的版本进行更新，会在应用市场上架该新版本的应用程序。手机可以自动或者根据用户更新应用程序的操作，从应用市场下载和安装相应的新版本的应用程序。

其中，应用程序，尤其第三方应用程序，由于涉及到不同手机平台，多种系统版本，在上架应用市场前，则无法做到彻底兼容，仅能进行基本测试，对于大量的功能业务和场景无法在不同手机平台和各种系统版本上进行充分验证。因此，上架应用市场的新版本应用程序，在手机更新后可能会存在稳定性问题（即应用程序异常）。例如，闪退，崩溃，卡顿，无响应等。

一般，为了能够及时发现更新后的新版本应用程序存在稳定性问题，需要对手机更新后的相关应用程序的运行情况进行人工监控。例如，用户在更新了新版本的应用程序后，该应用程序出现了稳定性问题，用户可能会通过热线，互联网，门店等方式进行对应用程序出现的稳定性问题进行反馈。当大量用户对更新后的应用程序存在稳定性问题进行了反馈爆发舆情后，通过人工监控则可确定该新版本的应用程序存在稳定性问题。即当人工监控到很多用户反馈手机更新了应用程序后，相应的应用程序出现稳定性问题时，则可以说明更新后的应用程序存在稳定性问题。此时，可以通知应用厂家对该应用程序进行修复。示例地，图1示出了相关技术提供的一种更新预警及故障修复的方法的流程示意图。如图1所示，该更新预警及故障修复的方法可以包括：应用厂家发布新版本的应用程序。之后，新版本的应用程序上架到应用市场。电子设备从应用市场更新新版本的应用程序（例如，自动更新，响应于用户更新应用程序的操作进行更新等）。当电子设备上更新后的该应用程序在使用过程中发生异常（即出现稳定性问题）时，用户通过互联网、门店、热线等方式反馈该应用程序存在的稳定性问题。随着用户反馈的增多，该应用程序存在稳定性问题的舆情爆发，电子设备厂家监控到相关舆情可以将相关问题传递到研发部门。研发可以获取该应用程序相应的信息、日志等来分析定位稳定性问题（即分析异常）。然后可以将稳定性问题的分析传递到应用厂家，以推动解决问题。当应用厂家修复问题后，可以重新打包发布修复好的新版本应用程序，并上架应用市场供用户更新，以解决手机更新应用程序后出现的应用程序异常。

由此可以看出，目前只有在应用市场上架新版本的应用程序较长一段时间后，收到了大量的用户反馈，人工才能根据用户反馈发现相关应用程序存在稳定性问题。该过程，需要依靠人工监控，以及用户自行反馈，耗时较长。

为解决上述问题，本申请实施例提供了一种更新预警及故障修复的方法，该方法可以应用于电子设备更新系统或应用程序的版本，或者推送系统或应用程序的补丁等更新推送场景中。示例地，该场景中可以包括更新预警及故障修复系统，该系统包括电子设备，故障监控装置和更新服务端（如，更新应用程序的应用市场服务端，更新系统的系统更新服务端等）

在本申请实施例中，上述的更新预警及故障修复的方法可以包括：电子设备（如第一电子设备）更新软件（如，更新应用程序和/或更新操作系统）后，若电子设备的系统（即操作系统）发生异常，或相应的应用程序发生异常，则电子设备可以将系统或应用程序发生异常时的异常信息上报到故障监控装置（或者称为故障大数据系统）。故障监控装置可以根据接收到的异常信息向应用市场服务端（即应用市场的服务器等）或系统更新服务端发送异常预警。应用市场服务端可以根据异常预警对相应的应用程序进行处理，如停止该应用程序的更新推送，或者向其他电子设备（如第二电子设备），如其他电子设备的应用市场客户端（即电子设备上安装的应用市场应用程序）发送指示停止相应应用程序的自动更新的指示，又或者回退相应应用程序到之前的版本等。系统更新服务端可以根据异常预警对相应的更新推送进行处理，如停止该更新推送，或回退到之前版本等。其中，应用市场服务端和系统更新服务端均可称为更新服务端。

如此，能够通过故障监控装置对电子设备进行自动监控，当电子设备更新了应用程序或系统之后，应用程序或系统存在问题而发生异常时，故障监控装置能够及时发现异常，时间周期较短。并且能够使应用市场及时做出相应的处理，以避免存在问题的应用程序或者系统的更新继续在众多用户中扩散，减小受到更新影响的用户数量。

需要说明的是，上述的应用程序或系统的更新可以是应用程序或系统的版本更新，冷补丁或热补丁更新，参数或配置文件更新等此处不做限制。

以下，将结合附图对本申请实施例提供的设备间应用协同工作的方法进行说明。

在本申请实施例中，上述电子设备，可以是手机、平板电脑、手持计算机，PC，蜂窝电话，个人数字助理（personal digital assistant，PDA），可穿戴式设备（如：智能手表、智能手环），智能家居设备（如：电视机），车机（如：车载电脑），智慧屏，游戏机，智能音箱，智能投影仪，智能电视盒，以及增强现实（augmented reality，AR）/虚拟现实（virtualreality，VR）设备等。本申请实施例对于电子设备的具体设备形态不作特殊限制。

示例地，以电子设备为手机为例，图2示出了本申请实施例提供的一种电子设备的结构示意图。也即，示例性的，图2所示的电子设备可以是手机。

如图2所示，电子设备可以包括处理器210，外部存储器接口220，内部存储器221，通用串行总线（universal serial bus，USB）接口230，充电管理模块240，电源管理模块241，电池242，天线1，天线2，移动通信模块250，无线通信模块260，音频模块270，扬声器270A，受话器270B，麦克风270C，耳机接口270D，传感器模块280，按键290，马达291，指示器292，摄像头293，显示屏294，以及用户标识模块（subscriber identification module，SIM）卡接口295等。其中，传感器模块280可以包括压力传感器280A，陀螺仪传感器280B，气压传感器280C，磁传感器280D，加速度传感器280E，距离传感器280F，接近光传感器280G，指纹传感器280H，温度传感器280J，触摸传感器280K，环境光传感器280L，骨传导传感器280M等。

可以理解的是，本实施例示意的结构并不构成对电子设备的具体限定。在另一些实施例中，电子设备可以包括比图示更多或更少的部件，或者组合某些部件，或者拆分某些部件，或者不同的部件布置。图示的部件可以以硬件，软件或软件和硬件的组合实现。

处理器210可以包括一个或多个处理单元，例如：处理器210可以包括应用处理器（application processor，AP），调制解调处理器，图形处理器（graphics processingunit，GPU），图像信号处理器（image signal processor，ISP），控制器，存储器，视频编解码器，数字信号处理器（digital signal processor，DSP），基带处理器，和/或神经网络处理器（neural-network processing unit，NPU）等。其中，不同的处理单元可以是独立的器件，也可以集成在一个或多个处理器中。

控制器可以是电子设备的神经中枢和指挥中心。控制器可以根据指令操作码和时序信号，产生操作控制信号，完成取指令和执行指令的控制。

处理器210中还可以设置存储器，用于存储指令和数据。在一些实施例中，处理器210中的存储器为高速缓冲存储器。该存储器可以保存处理器210刚用过或循环使用的指令或数据。如果处理器210需要再次使用该指令或数据，可从所述存储器中直接调用。避免了重复存取，减少了处理器210的等待时间，因而提高了系统的效率。

在一些实施例中，处理器210可以包括一个或多个接口。接口可以包括集成电路（inter-integrated circuit，I2C）接口，集成电路内置音频（inter-integrated circuitsound，I2S）接口，脉冲编码调制（pulse code modulation，PCM）接口，通用异步收发传输器（universal asynchronous receiver/transmitter，UART）接口，移动产业处理器接口（mobile industry processor interface，MIPI），通用输入输出（general-purposeinput/output，GPIO）接口，用户标识模块（subscriber identity module，SIM）接口，和/或通用串行总线（universal serial bus，USB）接口等。

充电管理模块240用于从充电器接收充电输入。其中，充电器可以是无线充电器，也可以是有线充电器。在一些有线充电的实施例中，充电管理模块240可以通过USB接口230接收有线充电器的充电输入。在一些无线充电的实施例中，充电管理模块240可以通过电子设备的无线充电线圈接收无线充电输入。充电管理模块240为电池242充电的同时，还可以通过电源管理模块241为电子设备供电。

电源管理模块241用于连接电池242，充电管理模块240与处理器210。电源管理模块241接收电池242和/或充电管理模块240的输入，为处理器210，内部存储器221，外部存储器，显示屏294，摄像头293，和无线通信模块260等供电。电源管理模块241还可以用于监测电池容量，电池循环次数，电池健康状态（漏电，阻抗）等参数。在其他一些实施例中，电源管理模块241也可以设置于处理器210中。在另一些实施例中，电源管理模块241和充电管理模块240也可以设置于同一个器件中。

电子设备的无线通信功能可以通过天线1，天线2，移动通信模块250，无线通信模块260，调制解调处理器以及基带处理器等实现。

天线1和天线2用于发射和接收电磁波信号。电子设备中的每个天线可用于覆盖单个或多个通信频带。不同的天线还可以复用，以提高天线的利用率。例如：可以将天线1复用为无线局域网的分集天线。在另外一些实施例中，天线可以和调谐开关结合使用。

移动通信模块250可以提供应用在电子设备上的包括2G/3G/4G/5G等无线通信的解决方案。移动通信模块250可以包括至少一个滤波器，开关，功率放大器，低噪声放大器（low noise amplifier，LNA）等。移动通信模块250可以由天线1接收电磁波，并对接收的电磁波进行滤波，放大等处理，传送至调制解调处理器进行解调。移动通信模块250还可以对经调制解调处理器调制后的信号放大，经天线1转为电磁波辐射出去。在一些实施例中，移动通信模块250的至少部分功能模块可以被设置于处理器210中。在一些实施例中，移动通信模块250的至少部分功能模块可以与处理器210的至少部分模块被设置在同一个器件中。

无线通信模块260可以提供应用在电子设备上的包括无线局域网（wirelesslocal area networks，WLAN）（如无线保真（wireless fidelity，Wi-Fi）网络），蓝牙（bluetooth，BT），全球导航卫星系统（global navigation satellite system，GNSS），调频（frequency modulation，FM），近距离无线通信技术（near field communication，NFC），红外技术（infrared，IR）等无线通信的解决方案。无线通信模块260可以是集成至少一个通信处理模块的一个或多个器件。无线通信模块260经由天线2接收电磁波，将电磁波信号调频以及滤波处理，将处理后的信号发送到处理器210。无线通信模块260还可以从处理器210接收待发送的信号，对其进行调频，放大，经天线2转为电磁波辐射出去。

在一些实施例中，电子设备的天线1和移动通信模块250耦合，天线2和无线通信模块260耦合，使得电子设备可以通过无线通信技术与网络以及其他设备通信。所述无线通信技术可以包括全球移动通讯系统（global system for mobile communications，GSM），通用分组无线服务（general packet radio service，GPRS），码分多址接入（code divisionmultiple access，CDMA），宽带码分多址（wideband code division multiple access，WCDMA），时分码分多址（time-division code division multiple access，TD-SCDMA），长期演进（long term evolution，LTE），BT，GNSS，WLAN，NFC，FM，和/或IR技术等。所述GNSS可以包括全球卫星定位系统（global positioning system，GPS），全球导航卫星系统（globalnavigation satellite system，GLONASS），北斗卫星导航系统（beidou navigationsatellite system，BDS），准天顶卫星系统（quasi-zenith satellite system，QZSS）和/或星基增强系统（satellite based augmentation systems，SBAS）。

NPU为神经网络（neural-network，NN）计算处理器，通过借鉴生物神经网络结构，例如借鉴人脑神经元之间传递模式，对输入信息快速处理，还可以不断的自学习。通过NPU可以实现电子设备的智能认知等应用，例如：运动轨迹预测，图像识别，人脸识别，语音识别，文本理解等。

内部存储器221可以用于存储计算机可执行程序代码，所述可执行程序代码包括指令。处理器210通过运行存储在内部存储器221的指令，从而执行电子设备的各种功能应用以及数据处理。内部存储器221可以包括存储程序区和存储数据区。其中，存储程序区可存储操作系统，至少一个功能所需的应用程序（比如定位功能，图像播放功能等）等。存储数据区可存储电子设备使用过程中所创建的数据（比如位置数据等）等。此外，内部存储器221可以包括高速随机存取存储器，还可以包括非易失性存储器，例如至少一个磁盘存储器件，闪存器件，通用闪存存储器（universal flash storage，UFS）等。

当然，可以理解的，上述图2所示仅仅为电子设备的形态为手机时的示例性说明。若电子设备是平板电脑，手持计算机，PC，PDA，可穿戴式设备（如：智能手表、智能手环），智能家居设备（如：电视机），车机（如：车载电脑），智慧屏，游戏机以及AR/VR设备等其他设备形态时，电子设备的结构中可以包括比图2中所示更少的结构，也可以包括比图2中所示更多的结构，在此不作限制。

以下实施例中的方法均可以在具有上述硬件结构的电子设备中实现。下面将结合附图对本申请实施例进行举例说明。

以电子设备为手机，电子设备更新的软件为应用程序，且更新应用程序的版本为例，图3为本申请实施例提供的一种更新预警及故障修复的方法的流程示意图。如图3所示，该更新预警及故障修复的方法可以包括以下S301-S305。

应用厂家发布应用程序的新版本后，该新版本的应用程序可以上架应用市场。此时，手机可以执行以下步骤。

S301、手机更新应用程序（如第一应用程序）的新版本。

其中，用户可以手动操作手机更新应用程序的新版本，还可以设置手机自动更新应用程序的新版本，当然，手机也可以默认为自动更新应用程序的新版本，此处不做限制。

例如，如图4所示，用户可以打开手机安装的应用市场APP，然后在应用市场APP中选择相应的应用程序（如，图中所示的第一应用程序401）进行更新。手机响应于上述用户更新应用程序的操作，便能够下载并安装相应的应用程序的新版本。

又例如，如图5中的（a）所示，用户可以在手机安装的应用市场APP中的“我的”页面，通过点击“设置”，以使手机跳转到应用市场的设置界面。如图5中的（b）所示，用户可以在设置界面选择“WLAN闲时自动更新”，从而开启自动更新应用程序，以使手机能够自动下载并安装相应应用程序的新版本。

在手机使用该应用程序的新版本的过程中，应用程序若发生异常，则手机可以执行以下步骤。

S302、手机向故障监控装置上报应用程序（如第一应用程序）的异常信息。

需要说明的是，应用程序发生的异常可以包括闪退，崩溃，卡顿，无响应，冻屏等。其中，常见的闪退异常有：运行时异常（如，类型转换异常、空指针异常、数组下标越界异常、字符串下标越界异常、算术异常、找不到类异常等），输入输出（input output，IO）流异常（如，找不到文件异常等），结构化查询语言（structured query language，SQL）异常，其他资源异常（如，数据库异常、传输的数据太大异常、游标（Cursor）内存不足、窗体异常、类加载异常、并发操作异常，内存异常等）。常见的崩溃异常有：进程自己检测到不可恢复的错误或IO异常之后主动调用不正常进程的终止（abort）退出（即SIGABRT）；进程执行了一个无效的内存引用或发生段错误退出，比如访问没有读权限的内存，向没有写权限的地址写数据（即SIGSEGV）；进程访问内存的时候出错异常，比如访问一个4字节的整数，但其地址不是4的倍数（即SIGBUS）；执行了非法指令，或者试图执行数据段，堆栈溢出（即SIGILL）。其中，无响应异常是指应用程序在特定时间无法响应屏幕触摸或键盘输入时，或特定事件没有处理完毕时应用程序的卡顿无响应。例如，5秒内无法响应屏幕触摸事件或键盘输入事件（即InputDispatching Timeout）；在执行前台广播的onReceive()函数时10秒没有处理完成（即BroadcastQueue Timeout）；前台服务20秒内，后台服务在200秒内没有执行完毕（即Service Timeout）；内容提供者（ContentProvider）的发布（publish）在10s内没进行完（即ContentProvider Timeout）等触发的无响应。

在一些可能的实施方式中，应用程序（如第一应用程序）的异常信息可以包括应用程序的异常类型（即应用程序发生的具体异常，如，闪退，崩溃，卡顿、无响应或冻屏等）和/或属性信息。故障监控装置能够根据属性信息确定发生异常的应用程序具体信息（如根据属性信息确定发生异常的应用程序为第一应用程序）。

示例地，应用程序的属性信息具体可以如以下表1所示。

表1

其中，应用名称即上报的出现异常的应用程序的名称，如“备忘录”。应用进程名，即该应用程序出现异常的具体进程的名称。应用版本号即上报的应用程序出现的异常的版本的版本号。应用分类即该应用程序提供的功能所属的类型，如，通讯、影音娱乐、工具等。应用进程信息1用于指示上报的该应用程序出现异常的进程为前台进程还是后台进程。应用进程信息2用于指示上报的该应用程序出现异常的进程为主进程还是子进程。应用异常次数，则用于指示上报的该应用程序在用户多次打开时出现异常的次数，例如，以每个设备每小时多少次进行表示。应用生命周期，则用于指示该上报的应用程序在用户打开到发生异常所经历的时间，即应用在前台存活的时间，或者说应用存活时长。需要说明的是，属性信息具体包括的内容可以根据表1所示进行选择设置，当然表1仅为示例，还可以设置应用程序的其他属性信息，此处不做限制。

当故障监控装置接收到来自不同手机上报的异常信息后，故障监控装置可以根据接收到应用程序的异常信息分析得到相应应用程序的预警信息，以预警相应应用程序存在运行异常的问题。例如，故障监控装置可以执行以下步骤。

S303、故障监控装置根据异常信息，生成用于指示某个应用程序的新版本（如，第一应用程序）存在异常的预警信息。

在一些可能的实施方式中，来自不同用户的手机，即不同手机，上报的异常信息通常包括各种应用程序对应的异常信息。因此，故障监控装置可以根据接收到的所有异常信息，对包含相应的应用程序（如第一应用程序）的异常信息的数量进行统计得到相应应用程序的异常次数。例如，根据接收到的异常信息，统计各应用程序被上报的次数，即异常次数。当某个应用程序（如第一应用程序）被上报的次数（即异常次数）增加到起报阈值（如，基线数量与起报倍率的乘积，即以基线数量和起报倍率的乘积作为起报阈值）时，或者在较短时间内，即一个统计周期内（如，一天、半天、一个小时等）增加到或大于起报阈值（如，基线数量与起报倍率的乘积）时，则故障监控装置可以生成对该应用程序的预警信息，即预警信息中可以包括该相应应用程序的信息。通过预警信息可以指示某个应用程序（如第一应用程序）存在问题导致其在很多手机上运行时出现异常，即指示某个应用程序存在异常。其中，起报阈值可以为预先设置的，也可以为根据预先设置的基线数量和起报倍率计算得到。起报倍率可以预先设置，也可以根据起报倍率和基线数量间的对应关系得到，此处不做限制。故障监控装置可以根据起报阈值来确定是否需要向更新服务端（如，应用市场服务端）上报（或称为发送）对第一软件（如，第一应用程序）存在异常进行预警的预警信息。

需要说明的是，基线数量是指应用程序在固定时长（如，一个月或一个季度等）内平均被上报异常的次数，或平均被上报的某类异常的次数（即基线数量为应用程序的平均异常次数）。即通过基线数量可以表征该应用程序在正常情况下发生异常的次数。

其中，起报倍率可以是预设的固定倍率，例如起报倍率为50，即当某个应用程序被上报异常的次数大于该应用程序的基线数量的50倍时，故障监控装置可以生成对该应用程序的预警信息。可选地，起报倍率还可以设置为动态倍率。例如，将起报倍率按照预设的起报倍率和基线数量的对应关系进行动态调整，以使基线数量越大时起报倍率越小（即基线数量与起报倍率间的对应关系为反比例关系）。其中预设的起报倍率和基线数量的对应关系，可以根据实际情况进行设置此处不做限制，例如可以根据一段时间内的应用程序的异常信息上报情况对上述对应关系进行设置。示例地，起报倍率和基线数量间的对应关系可以为：

x<50，f(x)=50

50≤x≤5000，f(x)=-8.686ln(x)+84

5000<x，f(x)=10

其中，x为基线数量，f(x)为起报倍率。即根据应用程序的基线数量的不同，起报倍率不同。从而使起报倍率能够根据基线数量动态调整，避免出现基线数量较低时应用程序被上报的次数容易达到门限而误报，或基线数量较高时应用程序被上报次数不容易达到门限而漏报的情况。

可选地，在本申请实施例中，起报倍率还可以设置为多个（即起报阈值具有多个），从而使故障监控装置可以根据应用程序被上报的次数和不同的起报倍率将该应用程序的异常预警划分不同的预警等级，并将该预警等级包括在预警信息中，从而便于后续应用市场服务端根据预警等级对相应的应用程序采用不同的方式处理。

例如，起报倍率为固定倍率时，可以设置预警等级为A级时对应的起报倍率为2000（即以基线数量的2000倍作为对应于预警等级A级的起报阈值），预警等级为B级时对应的起报倍率为500（即以基线数量的500倍作为对应于预警等级B级的起报阈值），预警等级为C级时对应的起报倍率为50（即以基线数量的50作为对应于预警等级C级的起报阈值）。当故障监控装置统计到的某个应用程序（如第一应用程序）被上报的次数（即异常次数）大于该应用程序的基线数量的50倍（即预警等级C级对应的起报阈值）而小于基线数量的500倍（即预警等级B级对应的起报阈值）时，则可以生成对该应用程序可能存在问题而进行预警的预警信息，且预警等级为C级。当故障监控装置统计到的某个应用程序被上报的次数大于该应用程序的基线数量的500倍而小于基线数量的2000倍（即预警等级A即对应的起报阈值）时，则可以生成对该应用程序可能存在问题而进行预警的预警信息，且预警等级为B级。当故障监控装置统计到的某个应用程序被上报的次数大于该应用程序的基线数量的2000倍时，则可以生成对该应用程序可能存在问题而进行预警的预警信息，且预警等级为A级。其中，当应用程序被上报的次数等于基线数量的50倍时，可以不生成对该应用程序进行预警的预警信息，也可以生成预警信息并将预警等级划分为C级。当应用程序被上报的次数等于基线数量的500倍时，可以将对该应用程序进行预警的预警等级划分为B级，也可以划分为C级。当应用程序被上报的次数等于基线数量的2000倍时，可以将对该应用程序进行预警的预警等级划分为A级。

又例如，如图6所示，起报倍率为动态倍率时，可以设置预警等级为A级时对应的起报倍率与基线数量满足：

x<50，f(x)=2000

50≤x≤5000，f(x)=-325.7209ln(x)+3274.228

5000<x，f(x)=500

其中，x为基线数量，f(x)为起报倍率。

预警等级为B级时对应的起报倍率与基线数量满足：

x<50，f(x)=500

50≤x≤5000，f(x)=-97.71626ln(x)+882.2683

5000<x，f(x)=50

其中，x为基线数量，f(x)为起报倍率。

预警等级为C级时对应的起报倍率与基线数量满足：

x<50，f(x)=50

50≤x≤5000，f(x)=-8.686ln(x)+84

5000<x，f(x)=10

其中，x为基线数量，f(x)为起报倍率。

当故障监控装置统计到某个应用程序（如第一应用程序）被上报的次数（即异常次数）大于该应用程序的基线数量与预警等级C级所对应的起报倍率的乘积（即与预警等级C级对应的起报阈值），而小于基线数量与预警等级B级所对应的起报倍率的乘积（即与预警等级B级对应的起报阈值）时，则可以生成对该应用程序可能存在问题而进行预警的预警信息，且预警等级为C级。当故障监控装置统计到某个应用程序被上报的次数大于该应用程序的基线数量与预警等级B级所对应的起报倍率的乘积，而小于基线数量与预警等级A级所对应的起报倍率的乘积（即与预警等级A级对应的起报阈值）时，则可以生成对该应用程序可能存在问题而进行预警的预警信息，且预警等级为B级。当故障监控装置统计到某个应用程序被上报的次数大于该应用程序的基线数量与预警等级A级所对应的起报倍率的乘积时，则可以生成对该应用程序可能存在问题而进行预警的预警信息，且预警等级为A级。其中，当应用程序被上报的次数等于基线数量与预警等级C级所对应的起报倍率的乘积时，可以不生成对该应用程序进行预警的预警信息，也可以生成预警信息并将预警等级划分为C级。当应用程序被上报的次数等于基线数量与预警等级B级所对应的起报倍率的乘积时，可以将对该应用程序进行预警的预警等级划分为B级，也可以划分为C级。当应用程序被上报的次数等于基线数量与预警等级A级所对应的起报倍率的乘积时，可以将对该应用程序进行预警的预警等级划分为A级。

可选地，在本申请实施例中，故障监控装置在根据基线数量和起报倍率确定是否需要对应用程序进行预警生成预警信息时，还可以根据异常故障的应用场景，加入权重，从而能够对应用程序发生的异常进行更加准确预警，以便于后续应用市场服务端能够更加准确的对相应的应用程序采用相应的方式进行处理。

例如，可以根据表1中所示的手机上报的异常信息中的应用程序的属性信息来设置权重。当起报倍率采用如图6所示的起报倍率和基线数量的对应关系进行动态调整时，故障监控装置可以在应用程序的基线数量的基础上乘以该应用程序对应的权重以作为上述对应关系式中的x，从而得到根据权重调整后的起报倍率。通常权重的数值可以根据应用程序的重要程度，或者发生的异常的严重程度进行设置。如，越重要的应用程序对应的权重越大，或者发生的异常越严重的应用程序对应的权重越大。因此根据按照如图6所示的对应关系权重越低的应用程序调整后的各预警等级对应的起报倍率越高，如此，最终权重低的应用程序其基线数量和起报倍率的乘积会更高，该应用程序相对权重较高的应用程序则不容易达到相应的预警等级。从而使故障监控装置能够根据应用程序的权重进一步的对应用程序进行更加准确的预警。

作为一种示例，应用程序的权重可以按照应用分类进行设置，如，应用分类为工具的应用程序的权重高于应用分类为通讯的应用程序，应用程序分类为通讯的应用程序的权重高于应用程序分类为影音娱乐的应用程序。又或者，应用程序的权重可以按照应用进程信息1进行设置，如，应用进程信息1为前台的应用程序的权重高于应用进程信息1为后台的应用程序。又或者，应用程序的权重可以按照应用进程信息2进行设置，如，应用进程信息2为主进程的应用程序的权重高于应用进程信息2为子进程的应用程序。当然，在其他一些可能的实施方式中，应用程序的权重还可以根据上述示例进行结合来设置，此处不做限制，只要将更重要的应用程序的权重设置的更高即可。例如，后台进程异常权重1，新闻类进程异常权重为10，通讯类前台进程异常权重为20等。

S304、故障监控装置向应用市场服务端发送预警信息。

在一些可能的实施方式中，故障监控装置可以通过互联网等方式将预警信息发送给应用市场服务端，此处不做限制。

S305、应用市场服务端根据预警信息处理相应应用程序的更新。

可选地，应用市场服务端对应用程序的更新所做的处理可以包括：停止对相应应用程序进行更新推送；向应用市场客户端（或者说向其他电子设备，如第二电子设备）发送停止相应应用程序更新的指示（如，第一指示），以使应用市场客户端停止更新相应的应用程序；回退相应应用程序到上一版本（或其他稳定版本）。通过停止对相应应用程序进行更新推送，能够使设置为自动更新应用程序的手机还没有更新相应应用程序的新版本的不再接收更新推送进行更新，从而避免会出现异常的应用程序的新版本继续在众多用户中扩散。通过向应用市场客户端发送停止相应应用程序更新的指示，能够使还没有更新该应用程序的新版本的手机不再自动或根据用户的更新应用操作更新该应用程序，从而避免会出现异常的应用程序的新版本继续在众多用户中扩散。通过应用市场服务端回退相应应用程序到上一版本或其他稳定版本，能够使手机可以通过卸载应用程序在重新由应用市场下载安装该应用程序的方式解决应用程序的新版本带来的异常。从而在避免会出现异常的应用程序的新版本继续在众多用户中扩散的同时，使用户能够方便的解决应用程序的新版本带来的异常问题。需要说明的是，上述应用市场服务端对应用程序的更新所做的处理的示例，还可以任意两个或以上相结合，此处不做限制。

作为一种示例，故障监控装置发送的预警信息可以包括预警的应用程序的应用名称，应用包名等，以便于应用市场服务端确定需要处理的应用程序。预警信息还可以包括应用的版本号，以便于应用市场服务端确定出现异常的应用程序的版本。预警信息还可以包括预警的应用程序所出现的异常的异常类型（如，闪退，崩溃，卡顿，无响应，冻屏等），从而便于应用市场服务端确定应用程序所发生的具体异常。当上述S303中故障监控装置还确定预警等级时，预警信息还可以包括预警等级，从而便于应用市场服务端根据预警等级确定具体处理应用程序的方式（如，停止对相应应用程序进行更新推送；向应用市场客户端发送停止相应应用程序更新的指示，以使应用市场客户端停止更新相应的应用程序；回退相应应用程序到上一版本（或其他稳定版本）等）。可选地，预警信息还可以包括预警的应用程序已经影响的设备数量。即上报给故障监控装置的异常信息中包括该应用程序的设备数量。

示例地，当预警信息中包括第一应用的应用包名和应用名称，以及应用程序的预警等级为A级时，应用市场服务端可以回退第一应用到上一版本。从而及时避免用户继续更新第一应用的新版本，并便于已经更新第一应用的用户从应用市场下载第一应用的上一版本以解决第一应用的新版本带来的异常问题。可选地，应用市场服务端在回退第一应用的版本之后，还可以向应用市场客户端发送自动下载和安装第一应用的指示，从而使已经安装了第一应用的新版本的应用程序能够自动恢复第一应用到上一版本，从而解决第一应用的新版本带来的异常问题。

示例地，当预警信息中包括第一应用的应用包名和应用名称，以及应用程序的预警等级为C级时，应用市场服务端可以向应用市场客户端发送停止应用程序更新的指示。从而使设置为自动更新应用程序的手机还没有更新相应应用程序的新版本的不再接收更新推送进行更新，从而避免会出现异常的应用程序的新版本继续在众多用户中扩散。

需要说明的是，在本申请的实施例中，当应用市场服务端接收到预警信息后，还可以通过邮件形式自动邮件通知应用程序的应用厂家相应的应用程序存在问题会出现运行异常，以便于应用厂家及时修复应用程序的新版本。

可选地，在一些其他实施例中，上述故障监控装置可以是虚拟装置，设置在电子设备（如手机等），或者集成在应用市场服务端。故障监控装置还可以是实体装置，独立设置，此处对故障监控装置的实现形式不做限制，只要能够实现上述功能即可。

在本申请实施例中，当电子设备更新的是系统时，更新预警及故障修复的方法与上述图3所示的方法类似，区别在于应用市场服务端变为系统更新服务端，此处不做赘述。例如，手机更新系统版本后，发生异常，手机便向故障监控装置上报异常信息，故障监控装置可以根据异常信息生成用于指示系统的新版本存在异常的预警信息，并将预警信息发送给系统更新服务端。系统更新服务端可以根据预警信息对手机发送停止更新系统的指令，或者回退系统的上一版本等。

采用以上实施例中的方法，能够通过故障监控装置对电子设备进行自动监控，当电子设备更新了应用程序或系统之后，应用程序或系统存在问题而发生异常时，故障监控装置能够及时发现异常，时间周期较短。并且能够使应用市场及时做出相应的处理，以避免存在问题的应用程序或者系统的更新继续在众多用户中扩散，减小受到更新影响的用户数量。

对应于前述实施例中的方法，本申请实施例还提供一种更新预警及故障修复系统。该更新预警及故障修复系统可以包括第一电子设备、故障监控装置和更新服务端。其中，第一电子设备，用于当第一电子设备的第一软件更新后第一软件出现异常时，向故障监控装置发送异常信息，异常信息用于指示第一软件更新后出现异常；故障监控装置，用于在根据异常信息确定第一软件存在异常时，向更新服务端发送预警信息，预警信息用于指示第一软件存在异常；更新服务端，用于根据预警信息向第二电子设备发送第一指示，第一指示用于指示第二电子设备停止第一软件的更新；和/或，根据预警信息替换推送的第一软件到上一版本。

在一种可能的设计方式中，第一软件包括操作系统和/或应用程序。

在另一种可能的设计方式中，异常信息包括第一软件的属性信息。

在另一种可能的设计方式中，第一软件为应用程序，属性信息包括以下至少一个：应用名称、应用包名、应用版本号、应用分类、应用异常次数、异常进程的应用进程名、异常进程的应用进程信息、第一软件出现异常时的应用生命周期。

在另一种可能的设计方式中，异常信息还包括第一软件出现的异常的异常类型。

在另一种可能的设计方式中，异常类型包括闪退、崩溃、卡顿、无响应、冻屏中的至少一个。

在另一种可能的设计方式中，故障监控装置，具体用于根据包含第一软件的属性信息的异常信息的数量确定第一软件的异常次数；当异常次数大于起报阈值时，故障监控装置确定第一软件存在异常。

在另一种可能的设计方式中，起报阈值包括对应于不同预警等级的多个起报阈值；故障监控装置，还用于当异常次数大于起报阈值时，根据异常次数和多个起报阈值确定对第一软件的预警等级；预警信息包括预警等级。

在另一种可能的设计方式中，起报阈值为预先设置的；或故障监控装置，还用于确定第一软件发生异常的平均异常次数；根据平均异常次数和起报倍率确定起报阈值。

在另一种可能的设计方式中，故障监控装置，还用于根据平均异常次数和预设的平均异常次数与起报倍率间的对应关系，确定起报倍率；平均异常次数与起报倍率间的对应关系为反比例关系。

在另一种可能的设计方式中，第一软件的属性信息对应设有权重；故障监控装置，具体用于根据权重调整平均异常次数；根据调整后的平均异常次数和预设的平均异常次数与起报倍率间的对应关系，确定起报倍率。

在另一种可能的设计方式中，起报倍率为预先设置的。

在另一种可能的设计方式中，更新服务端，还用于根据预警信息向第一软件的厂家发送邮件，邮件用于通知第一软件的厂家第一软件存在异常。

本申请另一些实施例提供了一种电子设备，该电子设备可以包括：存储器和一个或多个处理器。该存储器和处理器耦合。该存储器用于存储计算机程序代码，该计算机程序代码包括计算机指令。当处理器执行计算机指令时，电子设备可执行上述方法实施例中电子设备（如第一电子设备）执行的各个功能或者步骤。当然，该电子设备包括但不限于上述存储器和一个或多个处理器。例如，该电子设备的结构可以参考图2所示的电子设备的结构。

本申请另一些实施例提供了一种故障监控装置，该故障监控装置可以包括：处理器，用于存储该处理器可执行指令的存储器。当处理器执行计算机指令时，该故障监控装置可执行上述方法实施例中故障监控装置执行的各个功能或者步骤。

本申请另一些实施例提供了一种更新服务端，该更新服务端可以包括：处理器，用于存储该处理器可执行指令的存储器。当处理器执行计算机指令时，该更新服务端可执行上述方法实施例中更新服务端执行的各个功能或者步骤。

本申请实施例还提供一种计算机可读存储介质，用于存储上述电子设备、故障监控装置或更新服务端运行的计算机指令。

本申请实施例还提供一种计算机程序产品，包括上述电子设备、故障监控装置或更新服务端运行的计算机指令。

通过以上实施方式的描述，所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，仅以上述各功能模块的划分进行举例说明，实际应用中，可以根据需要而将上述功能分配由不同的功能模块完成，即将装置的内部结构划分成不同的功能模块，以完成以上描述的全部或者部分功能。

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

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

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

所述集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个可读取存储介质中。基于这样的理解，本申请实施例的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出来，该软件产品存储在一个存储介质中，包括若干指令用以使得一个设备（可以是单片机，芯片等）或处理器（processor）执行本申请各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器（read only memory，ROM）、随机存取存储器（random access memory，RAM）、磁碟或者光盘等各种可以存储程序代码的介质。

以上内容，仅为本申请的具体实施方式，但本申请的保护范围并不局限于此，任何在本申请揭露的技术范围内的变化或替换，都应涵盖在本申请的保护范围之内。因此，本申请的保护范围应以所述权利要求的保护范围为准。

Claims (26)

1.一种更新预警及故障修复的方法，其特征在于，应用于更新预警及故障修复系统，所述更新预警及故障修复系统包括第一电子设备、故障监控装置和更新服务端，所述方法包括：

当所述第一电子设备的第一软件更新后所述第一软件出现异常时，所述第一电子设备向所述故障监控装置发送异常信息，所述异常信息用于指示所述第一软件更新后出现异常；

所述故障监控装置在根据所述异常信息确定所述第一软件存在异常时，向所述更新服务端发送预警信息，所述预警信息用于指示所述第一软件存在异常；

所述更新服务端根据所述预警信息向第二电子设备发送第一指示，所述第一指示用于指示所述第二电子设备停止所述第一软件的更新；和/或

所述更新服务端根据所述预警信息替换推送的所述第一软件到上一版本。

2.根据权利要求1所述的方法，其特征在于，所述第一软件包括操作系统和/或应用程序。

3.根据权利要求2所述的方法，其特征在于，所述异常信息包括所述第一软件的属性信息。

4.根据权利要求3所述的方法，其特征在于，所述第一软件为应用程序，所述属性信息包括以下至少一个：应用名称、应用包名、应用版本号、应用分类、应用异常次数、异常进程的应用进程名、异常进程的应用进程信息、所述第一软件出现异常时的应用生命周期。

5.根据权利要求3或4所述的方法，其特征在于，所述异常信息还包括所述第一软件出现的异常的异常类型。

6.根据权利要求5所述的方法，其特征在于，所述异常类型包括闪退、崩溃、卡顿、无响应、冻屏中的至少一个。

7.根据权利要求3所述的方法，其特征在于，所述故障监控装置根据所述异常信息确定所述第一软件存在异常，包括：

所述故障监控装置根据包含所述第一软件的属性信息的异常信息的数量确定所述第一软件的异常次数；

当所述异常次数大于起报阈值时，所述故障监控装置确定所述第一软件存在异常。

8.根据权利要求7所述的方法，其特征在于，所述起报阈值包括对应于不同预警等级的多个起报阈值；

在所述向所述更新服务端发送预警信息之前，所述方法还包括：

当所述异常次数大于所述起报阈值时，所述故障监控装置根据所述异常次数和多个所述起报阈值确定对所述第一软件的预警等级；

所述预警信息包括所述预警等级。

9.根据权利要求7或8所述的方法，其特征在于，

所述起报阈值为预先设置的；或

在所述故障监控装置确定所述第一软件存在异常之前，所述方法还包括：

所述故障监控装置确定所述第一软件发生异常的平均异常次数；

所述故障监控装置根据所述平均异常次数和起报倍率确定所述起报阈值。

10.根据权利要求9所述的方法，其特征在于，在所述故障监控装置根据所述平均异常次数和起报倍率确定所述起报阈值之前，所述方法还包括：

所述故障监控装置根据所述平均异常次数和预设的平均异常次数与起报倍率间的对应关系，确定所述起报倍率；所述平均异常次数与起报倍率间的对应关系为反比例关系。

11.根据权利要求10所述的方法，其特征在于，所述第一软件的属性信息对应设有权重；所述故障监控装置根据所述平均异常次数和预设的平均异常次数与起报倍率间的对应关系，确定所述起报倍率，包括：

所述故障监控装置根据所述权重调整所述平均异常次数；

所述故障监控装置根据调整后的平均异常次数和所述预设的平均异常次数与起报倍率间的对应关系，确定所述起报倍率。

12.根据权利要求9所述的方法，其特征在于，所述起报倍率为预先设置的。

13.根据权利要求1所述的方法，其特征在于，在所述故障监控装置在根据所述异常信息确定所述第一软件存在异常时，向所述更新服务端发送预警信息之后，所述方法还包括：

所述更新服务端根据所述预警信息向所述第一软件的厂家发送邮件，所述邮件用于通知所述第一软件的厂家所述第一软件存在异常。

14.一种更新预警及故障修复系统，其特征在于，包括第一电子设备、故障监控装置和更新服务端；

所述第一电子设备，用于当所述第一电子设备的第一软件更新后所述第一软件出现异常时，向所述故障监控装置发送异常信息，所述异常信息用于指示所述第一软件更新后出现异常；

所述故障监控装置，用于在根据所述异常信息确定所述第一软件存在异常时，向所述更新服务端发送预警信息，所述预警信息用于指示所述第一软件存在异常；

所述更新服务端，用于根据所述预警信息向第二电子设备发送第一指示，所述第一指示用于指示所述第二电子设备停止所述第一软件的更新；和/或，根据所述预警信息替换推送的所述第一软件到上一版本。

15.根据权利要求14所述的系统，其特征在于，所述第一软件包括操作系统和/或应用程序。

16.根据权利要求15所述的系统，其特征在于，所述异常信息包括所述第一软件的属性信息。

17.根据权利要求16所述的系统，其特征在于，所述第一软件为应用程序，所述属性信息包括以下至少一个：应用名称、应用包名、应用版本号、应用分类、应用异常次数、异常进程的应用进程名、异常进程的应用进程信息、所述第一软件出现异常时的应用生命周期。

18.根据权利要求16或17所述的系统，其特征在于，所述异常信息还包括所述第一软件出现的异常的异常类型。

19.根据权利要求18所述的系统，其特征在于，所述异常类型包括闪退、崩溃、卡顿、无响应、冻屏中的至少一个。

20.根据权利要求16所述的系统，其特征在于，所述故障监控装置，具体用于根据包含所述第一软件的属性信息的异常信息的数量确定所述第一软件的异常次数；当所述异常次数大于起报阈值时，所述故障监控装置确定所述第一软件存在异常。

21.根据权利要求20所述的系统，其特征在于，所述起报阈值包括对应于不同预警等级的多个起报阈值；所述故障监控装置，还用于当所述异常次数大于所述起报阈值时，根据所述异常次数和多个所述起报阈值确定对所述第一软件的预警等级；所述预警信息包括所述预警等级。

22.根据权利要求20或21所述的系统，其特征在于，

所述起报阈值为预先设置的；或

所述故障监控装置，还用于确定所述第一软件发生异常的平均异常次数；根据所述平均异常次数和起报倍率确定所述起报阈值。

23.根据权利要求22所述的系统，其特征在于，所述故障监控装置，还用于根据所述平均异常次数和预设的平均异常次数与起报倍率间的对应关系，确定所述起报倍率；所述平均异常次数与起报倍率间的对应关系为反比例关系。

24.根据权利要求23所述的系统，其特征在于，所述第一软件的属性信息对应设有权重；所述故障监控装置，具体用于根据所述权重调整所述平均异常次数；根据调整后的平均异常次数和所述预设的平均异常次数与起报倍率间的对应关系，确定所述起报倍率。

25.根据权利要求22所述的系统，其特征在于，所述起报倍率为预先设置的。

26.根据权利要求14所述的系统，其特征在于，所述更新服务端，还用于根据所述预警信息向所述第一软件的厂家发送邮件，所述邮件用于通知所述第一软件的厂家所述第一软件存在异常。

Images