CN111984532A

CN111984532A - 一种基于小程序的异常处理方法及装置

Info

Publication number: CN111984532A
Application number: CN202010769248.XA
Authority: CN
Inventors: 赵炳琦; 丁艳平; 张佳佳
Original assignee: Wuba Co Ltd
Current assignee: Wuba Co Ltd
Priority date: 2020-07-31
Filing date: 2020-07-31
Publication date: 2020-11-24

Abstract

本申请示出了一种基于小程序的异常处理方法及装置。通过本申请，在小程序出现异常的情况下，可以将与该异常相关的信息上报给后台服务端，以使小程序的开发者在后台服务端可以根据与该异常相关的信息消除该异常，进而使得小程序之后不再出现该异常，从而可以避免流失客户，进而避免给小程序的开发者带来损失。在本申请中，在基于预设可配置文件中的信息获取函数获取候选上报信息之后，可以在候选上报信息中筛选与该异常相关的信息，然后向后台服务端上报筛选的信息，不再向后台服务端上报与该异常无关的信息，从而可以节省网络资源。

Description

一种基于小程序的异常处理方法及装置

技术领域

本申请涉及计算机技术领域，特别是涉及一种基于小程序的异常处理方法及装置。

背景技术

小程序(Mini Program)是一种不需要下载安装即可使用的应用，它实现了应用“触手可及”的梦想，用户扫一扫或搜一下即可打开小程序。

目前，在用户使用设备中的应用程序的过程中，用户可根据需求在应用程序中添加自己所需要使用的小程序，并可以在应用程序中使用该小程序所提供的功能。

然而，有时候小程序在运行过程中，会由于硬件或软件问题导致小程序出现异常，例如，导致小程序卡顿、闪退或者停止运行等，这会给用户带来很差的体验。

且如果用户在使用其他小程序时若不存在上述问题，则会导致用户以为是这个小程序自身出问题而不再使用这个小程序，这样会给这个小程序的开发者带来极大的损失。

发明内容

为了避免给小程序的开发者带来损失，在小程序出现异常之后，需要尽快消除小程序的异常，例如，可以尽快给小程序的开发者提供与小程序异常相关的信息，以供开发者根据与小程序异常相关的信息尽快消除异常，以优化小程序。

其中，为了给小程序的开发者提供与小程序异常相关的信息，本申请示出了一种基于小程序的异常处理方法及装置。

第一方面，本申请示出了一种基于小程序的异常处理方法，所述方法包括：

检测小程序是否出现异常；

在所述小程序出现异常的情况下，基于预设可配置文件中的信息获取函数获取候选上报信息；

在所述候选上报信息中筛选与所述异常相关的信息；

向后台服务端上报筛选的信息。

在一个可选的实现方式中，所述检测小程序是否出现异常，包括：

检测在所述小程序发出超文本传输协议HTTP请求之后的预设时长内，是否接收到根据HTTP请求返回的HTTP响应；

在预设时长内未接收到所述HTTP响应的情况下，确定所述小程序出现HTTP异常；

在预设时长内接收到所述HTTP响应的情况下，判断所述HTTP响应中携带的状态码是否为预设状态码；

在所述HTTP响应中携带的状态码不为预设状态码的情况下，确定所述小程序出现HTTP异常；

在所述HTTP响应中携带的状态码为预设状态码的情况下，判断所述HTTP响应携带的校验码与所述HTTP请求中携带的校验码是否相同；

在所述HTTP响应携带的校验码与所述HTTP请求中携带的校验码不同的情况下，确定所述小程序出现HTTP异常。

在所述小程序中基于JS脚本渲染页面数据的过程中，检测小程序的控制台是否输出异常提示；

在所述控制台输出异常提示的情况下，确定所述小程序出现JS异常。

检测承载所述小程序的应用程序的上传函数对应的fail回调函数是否被触发以及所述应用程序的下载函数对应的fail回调函数是否被触发；

在所述上传函数对应的fail回调函数或所述下载函数对应的fail回调函数被触发的情况下，确定所述小程序出现上传下载异常。

在一个可选的实现方式中，所述向后台服务端上报筛选的信息，包括：

在筛选的信息的数量大于预设数量的情况下，向所述后台服务端分批次上报筛选的信息，每一批次上报的筛选的信息的数量小于或等于所述预设数量。

在筛选的信息的数量小于预设数量的情况下，缓存筛选的信息；

判断缓存的筛选的信息的数量是否达到预设数量；

在达到预设数量的情况下，基于一个消息载体向后台服务端上报缓存的筛选的信息。

第二方面，本申请示出了一种基于小程序的异常处理装置，所述装置包括：

检测模块，用于检测小程序是否出现异常；

获取模块，用于在所述小程序出现异常的情况下，基于预设可配置文件中的信息获取函数获取候选上报信息；

筛选模块，用于在所述候选上报信息中筛选与所述异常相关的信息；

上报模块，用于向后台服务端上报筛选的信息。

在一个可选的实现方式中，所述检测模块包括：

第一检测单元，用于检测在所述小程序发出超文本传输协议HTTP请求之后的预设时长内，是否接收到根据HTTP请求返回的HTTP响应；

第一确定单元，用于在预设时长内未接收到所述HTTP响应的情况下，确定所述小程序出现HTTP异常；

第一判断单元，用于在预设时长内接收到所述HTTP响应的情况下，判断所述HTTP响应中携带的状态码是否为预设状态码；

所述第一确定单元还用于：在所述HTTP响应中携带的状态码不为预设状态码的情况下，确定所述小程序出现HTTP异常；

第二判断单元，用于在所述HTTP响应中携带的状态码为预设状态码的情况下，判断所述HTTP响应携带的校验码与所述HTTP请求中携带的校验码是否相同；

所述第一确定单元还用于：在所述HTTP响应携带的校验码与所述HTTP请求中携带的校验码不同的情况下，确定所述小程序出现HTTP异常。

在一个可选的实现方式中，所述检测模块包括：

第二检测单元，用于在所述小程序中基于JS脚本渲染页面数据的过程中，检测小程序的控制台是否输出异常提示；

第二确定单元，用于在所述控制台输出异常提示的情况下，确定所述小程序出现JS异常。

在一个可选的实现方式中，所述检测模块包括：

第三检测单元，用于检测承载所述小程序的应用程序的上传函数对应的fail回调函数是否被触发以及所述应用程序的下载函数对应的fail回调函数是否被触发；

第三确定单元，用于在所述上传函数对应的fail回调函数或所述下载函数对应的fail回调函数被触发的情况下，确定所述小程序出现上传下载异常。

在一个可选的实现方式中，所述上报模块包括：

第一上报单元，用于在筛选的信息的数量大于预设数量的情况下，向所述后台服务端分批次上报筛选的信息，每一批次上报的筛选的信息的数量小于或等于所述预设数量。

在一个可选的实现方式中，所述上报模块包括：

缓存单元，用于在筛选的信息的数量小于预设数量的情况下，缓存筛选的信息；

第三判断单元，用于判断缓存的筛选的信息的数量是否达到预设数量；

第二上报单元，用于在达到预设数量的情况下，基于一个消息载体向后台服务端上报缓存的筛选的信息。

第三方面，本申请示出了一种电子设备，所述电子设备包括：

处理器；

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

其中，所述处理器被配置为执行如第一方面所述的基于小程序的异常处理方法。

第四方面，本申请示出了一种非临时性计算机可读存储介质，当所述存储介质中的指令由电子设备的处理器执行时，使得电子设备能够执行如第一方面所述的基于小程序的异常处理方法。

第五方面，本申请示出了一种计算机程序产品，当所述计算机程序产品中的指令由电子设备的处理器执行时，使得电子设备能够执行如第一方面所述的基于小程序的异常处理方法。

本申请提供的技术方案可以包括以下有益效果：

通过本申请，在小程序出现异常的情况下，可以将与该异常相关的信息上报给后台服务端，以使小程序的开发者在后台服务端可以根据与该异常相关的信息消除该异常，进而使得小程序之后不再出现该异常，从而可以避免流失客户，进而避免给小程序的开发者带来损失。

其次，在获取与该异常相关的信息时可以是通过预设可配置文件中的信息获取函数来获取，但是通过一种信息获取函数可以获取多种候选上报信息，在多种候选上报信息中有一些信息可能是与该异常有关的，另一些信息可能是与该异常无关的，也即，通过一个信息获取函数获取到的信息中有时候仅有部分信息是与该异常相关的，如果将一个通过信息获取函数获取到的全部信息上报至后台服务端，虽然使得后台服务端可以得到与该异常相关的信息，但是也会得到与该异常无关的信息，与该异常无关的信息对小程序的开发者消除该异常往往不起参考作用，因此，上报与该异常无关的信息会浪费网络资源。

而在本申请中，在基于预设可配置文件中的信息获取函数获取候选上报信息之后，可以在候选上报信息中筛选与该异常相关的信息，然后向后台服务端上报筛选的信息，而可以不向后台服务端上报与该异常无关的信息，从而可以节省网络资源。

附图说明

图1是本申请的一种基于小程序的异常处理方法的步骤流程图。

图2是本申请的一种检测异常的方法的步骤流程图。

图3是本申请的一种检测异常的方法的步骤流程图。

图4是本申请的一种检测异常的方法的步骤流程图。

图5是本申请的一种上报信息方法的步骤流程图。

图6是本申请的一种基于小程序的异常处理装置的结构框图。

图7是本申请示出的一种电子设备的框图。

图8是本申请示出的一种电子设备的框图。

具体实施方式

为使本申请的上述目的、特征和优点能够更加明显易懂，下面结合附图和具体实施方式对本申请作进一步详细的说明。

参照图1，示出了本申请的一种基于小程序的异常处理方法的步骤流程图，该方法可以应用于在小程序中加载的SDK(Software Development Kit，软件开发工具包)中，该方法具体可以包括如下步骤：

在步骤S101中，检测小程序是否出现异常。

在本申请中，小程序在运行的过程中可能会出现异常。需要说明的是，本申请中的小程序出现异常的理解方式包括但不限于：小程序在运行的过程中无法实现其应有的功能，例如，包括但不限于：卡顿、黑屏、闪退、无法展示用户需要查看的页面，无法使得用户在小程序上登录小程序的后台服务端，小程序无法从后台服务端上下载数据以及小程序无法向后台服务端上传数据等等。

小程序无法实现其应有的功能的原因包括：小程序本身的原因导致小程序无法实现其应有的功能。以及，不是小程序本身的原因，而是诸如网络或者后台服务端等的原因导致小程序无法实现其应有的功能等。

其中，小程序运行的过程中可能会出现多种异常。在一个例子中，小程序在与小程序的后台服务端之间基于HTTP(HyperText Transfer Protocol，超文本传输协)消息交互的过程中出现HTTP异常，例如，在小程序向后台服务端发送HTTP请求之后未接收到后台服务端返回的HTTP响应。或者，在小程序向后台服务端发送HTTP请求之后，虽然接收到后台服务端返回的HTTP响应，但是HTTP响应并不是后台服务端基于该HTTP请求返回的。或者，小程序向后台服务端发送的HTTP请求中的请求参数或者语义有误，导致HTTP请求无法被后台服务端理解等。

其中，具体如何检测小程序是否出现异常可以参见之后如图2-4所示的实施例，在此不做详述。

在小程序未出现异常的情况下，返回继续执行步骤S101，其中，可以立刻返回执行步骤S101，也可以在间隔一段时长之后返回执行步骤S101。这段时长具体可根据实际需求设定，本申请对此不加以限定。

在小程序出现异常的情况下，在步骤S102中，基于预设可配置文件中的信息获取函数获取候选上报信息。

在本申请中，小程序的开发者在对外发布小程序之前，可以为小程序设置预设可配置文件，预设可配置文件可以设置在小程序内部，被小程序单独使用。

开发者可以在预设可配置文件设置至少一个信息获取函数。信息获取函数至少包括：用于获取小程序的网络状态的函数、用于获取使用小程序的用户的基本资料的函数、用于获取小程序的基本资料的函数、用于获取承载小程序的应用程序的基本资料的函数以及用于获取该应用程序所在的物理设备的基本资料的函数等。

其中，用户的基本资料至少包括用户的登录状态、用户的账号、昵称、头像、手机号、年龄、性别、位置、用户的登录频率以及登录持续时长等。

小程序的基本资料至少包括小程序的名称、小程序的版本、小程序的端口号、小程序的基础库的版本、小程序的堆栈信息、小程序最近几次执行的函数的顺序、小程序当前所在页面的URL(Uniform Resource Locator，统一资源定位系统)、用户在小程序上的操作记录等。

应用程序的基本资料至少包括应用程序适配的操作系统、应用程序的名称、应用程序的版本、应用程序所使用的基础库的版本等。操作系统包括Android操作系统或IOS操作系统等。

物理设备的基本资料至少包括物理设备的操作系统的种类、操作系统的版本、物理设备的屏幕的尺寸、物理设备的当前时刻、物理设备的型号、IP(Internet Protocol，互联网协议)地址、端口号、IMEI(International Mobile Equipment Identity，国际移动设备识别码)、位置、使用的网络的运营商的名称、使用的网络类型以及使用的网络的带宽大小等。

网络类型包括2G(第2代移动通信技术)、3G(第3代移动通信技术)、4G(第4代移动通信技术)、5G(第5代移动通信技术)以及WiFi(Wireless Fidelity，无线保真)等。

在小程序上线之后，开发者还可以根据实际需求在预设可配置文件中更新信息获取函数，例如，在预设可配置文件中删除某不再需要的信息获取函数，或者在预设可配置文件中添加新的信息获取函数等。

因此，在本步骤中，预设可配置文件具有哪些信息获取函数，则就基于哪些信息获取函数获取信息，并作为候选上报信息，然后执行步骤S103。

在步骤S103中，在候选上报信息中筛选与该异常相关的信息。

在本申请中，参见步骤S102中的描述，通过一种信息获取函数可以获取多种候选上报信息。

其中，小程序的开发者事先可以预测小程序可能会出现的各种异常，然后，分析在出现任意一种可能的异常时，为了消除该异常所需要参考哪些种类的信息，然后存储该异常与该种类之间的对应关系，通常情况下，这些种类的信息对小程序的开发者消除该异常时往往具有参考作用，其他种类的信息对小程序的开发者消除该异常时往往不具有参考作用。

对于其他每一种可能会出现的异常，同样执行上述操作。

例如，在一个示例中，小程序在与后台服务端之间基于HTTP消息交互的过程中出现了状态码“500Internal Server Error”指示的异常，该异常可以为：后台服务端遇到了一个未曾预料的状况，导致后台服务端无法完成对小程序发送的HTTP请求的处理。其中，该异常通常是由于后台服务端引起的。

因此，在出现该异常时，获取关于小程序侧的每一个信息是没有必要的，与该异常相关的信息可以包括小程序与后台服务端之间的网络状态以及小程序侧的部分关键信息等，部分关键信息包括：小程序的版本、承载小程序的应用程序的版本以及用户的账号等。如此，可以存储状态码“500Internal Server Error”指示的该异常与该异常相关的信息的种类之间的对应关系等。

因此，在本步骤中，可以基于存储的上述对应关系，来获取该异常相关的信息的种类，然后在候选上报信息中筛选这些种类对应的信息，并作为与该异常相关的信息，然后执行步骤S104。

在步骤S104中，向后台服务端上报筛选的信息。

本步骤具体可以参见之后的实施例，在此不做详述。

后台服务端接收上报的信息，可以存储上报的信息，其中，可以按照特定的规则存储上报的信息，例如，不同的小程序分别对应的文件夹不同，可以在小程序对应的文件夹中存储小程序对应的信息。

进一步地，对于任意一个小程序而言，该小程序对应的文件夹中包括多个子文件夹，不同的文件夹中用于存储不同种类的异常对应的信息。因此，后台服务端在接收到上报的信息之后，可以在该异常的种类对应的文件夹中存储上报的信息。

其中，后台服务端在存储上报的信息时，可以基于MongoDB数据库存储上报的信息。

之后，在小程序的开发者需要查看上报的信息时，后台服务短可以按照“小程序-异常的种类”的结构分组展示上报的信息，以方便小程序的开发者查看。

另外，在后台服务端存储的某一种类的异常的上报的信息超过预设阈值的情况下，可以直接向小程序的开发者发送提示信息，例如，通过邮件、短信或其他社交方式向小程序的开发者发送提示信息等，以对小程序的开发者报警，以使小程序的开发者根据上报的信息消除异常。

其中，预设阈值可以根据实际需求设置，例如可以为10、20或50等，本申请对此不加以限定。

另外，后台服务端还可以统计一段时间内小程序出现异常的总次数、不同种类的异常在全部异常中的占比以及不同时间段内的小程序出现异常的总次数的走势图等。

其中，在本申请另一个实施例中，参见图2，步骤S101包括：

在步骤S201中，检测在小程序发出HTTP请求之后的预设时长内，是否接收到根据HTTP请求返回的HTTP响应。

在本申请中，根据用户的实际需求，小程序可以与小程序对应的后台服务端之间进行数据交互。

例如，在一个场景中，小程序可以从后台服务端中获取页面数据并显示，以供用户查看。

具体地，小程序可以向后台服务端发送HTTP请求，以请求从后台服务端中获取用户需要查看的页面数据。后台服务端接收到HTTP请求之后，可以根据HTTP请求获取用户需要查看的页面数据，然后生成至少包括用户需要查看的页面数据的HTTP响应，并向小程序发送HTTP响应。小程序接收HTTP响应，渲染HTTP响应中的页面数据，以供用户查看。

然而，如果出现异常，则一个体现可以是小程序在发出HTTP请求之后的预设时长内无法得到HTTP响应，这样就无法得到页面数据，也就无法渲染页面数据以供用户查看。

异常的原因可以包括：小程序与后台服务端之间的网络断开，或者网络不稳定，或者后台服务端宕机、或者后台服务端负荷较大导致后台服务端无法及时处理HTTP响应等。

这样，在小程序向后台服务端发送HTTP请求之后的预设时长内，则往往就接收不到后台服务端根据HTTP请求返回的HTTP响应。

因此，在预设时长内未接收到根据HTTP请求返回的HTTP响应的情况下，可以执行步骤S202。

然而，在预设时长内接收到根据HTTP请求返回的HTTP响应的情况下，也未必就可以确定小程序一定正常，也即，未必就可以确定小程序一定能够实现其应有的功能，为了更加准确地确定出小程序是否出现异常，此时需要执行步骤S203。

其中，预设时长可以根据实际需求设置，例如，可以包括1秒、1.5秒或2秒等，本申请对此不加以限定。

在预设时长内未接收到根据HTTP请求返回的HTTP响应的情况下，在步骤S202中，确定小程序出现HTTP异常。

在本申请一个实施例中，在预设时长内未接收到根据HTTP请求返回的HTTP响应的情况下，小程序往往会触发HTTP请求对应的fail回调函数，因此，可以在小程序发出HTTP请求之后，检测HTTP请求对应的fail回调函数是否被触发，HTTP请求对应的fail回调函数被触发的情况下，则说明在预设时长内未接收到根据HTTP请求返回的HTTP响应。

在预设时长内接收到根据HTTP请求返回的HTTP响应的情况下，在步骤S203中，判断HTTP响应中携带的状态码是否为预设状态码。

在本申请中，在小程序与后台服务端之间进行HTTP交互的过程中，相互向对方发送的HTTP消息中可以携带状态码。

例如，在小程序向后台服务端发送HTTP请求之后，后台服务端如果接收到HTTP请求，则会基于HTTP请求向小程序返回HTTP响应，其中，HTTP响应中就会携带状态码，状态码包括：100、101、102、200、403、404以及502等等，不同的状态码代表的含义不同。

其中，有些状态码用于指示当前HTTP交互异常，有些状态码用于指示当前HTTP交互正常。

在本申请中，事先可以设置预设状态码，预设状态码包括用于指示当前HTTP交互正常的状态码。

例如，预设状态码可以包括200等状态码，其用于表征：HTTP请求已成功发送至后台服务端，HTTP请求所希望请求的数据将随此HTTP响应返回，此时的HTTP交互处于正常状态。

因此，在HTTP响应中携带的状态码为不预设状态码的情况下，则说明HTTP请求未成功发送至后台服务端，或者，HTTP请求已成功发送至后台服务端但是HTTP请求所希望请求的数据未随此HTTP响应返回，此时的HTTP交互处于异常状态，从而可以执行步骤S204。

然而，在HTTP响应中携带的状态码为预设状态码的情况下，也未必就可以确定小程序一定未出现HTTP异常，也即，未必就可以确定小程序一定能够实现其应有的功能，为了更加准确地确定出小程序是否出现HTTP异常，此时需要执行步骤S204。

在HTTP响应中携带的状态码不为预设状态码的情况下，执行步骤S202：确定小程序出现HTTP异常。

在HTTP响应中携带的状态码为预设状态码的情况下，在步骤S204中，判断HTTP响应携带的校验码与HTTP请求中携带的校验码是否相同。

在本申请中，小程序事先可以与其对应的后台服务端之间协商校验码，校验码可以携带在二者进行交互时的HTTP消息中的特定的字段中。例如，携带在HTTP请求的特定的字段中，以及，可以携带在HTTP响应的特定的字段中等。

在本申请中，通常情况下，小程序在与后台服务端之间进行数据交互时，任意一方向对方发送的HTTP消息中需要在特定的字段中携带事先协商的校验码，如此，对方接收到HTTP消息中的特定的字段中会携带事先协商的校验码。

例如，小程序向后台服务端发送的HTTP请求中的特定的字段中会携带事先协商的校验码，后台服务端基于HTTP消息向小程序返回的HTTP响应中的特定的字段中也会携带事先协商的校验码。

然而，有时候可能任意一方向对方发送的HTTP消息中的特定的字段中并未携带事先协商的校验码，或者，虽然携带了校验码，但并不是事先协商的校验码。这样，对方接收到HTTP消息中的特定的字段中就不会携带事先协商的校验码，或者，虽然携带了校验码，但并不是事先协商的校验码。这就属于异常情况，或者是由于小程序本身出现异常导致的，或者是由于后台服务端出现异常导致的，或者是由于二者之间的网络出问题而导致的。

例如，小程序向后台服务端发送的HTTP请求中的特定的字段中会携带事先协商的校验码，但是后台服务端基于HTTP消息向小程序返回的HTTP响应中的特定的字段中未携带事先协商的校验码，或者，虽然携带了校验码，但并不是事先协商的校验码。

这种情况往往是由于后台服务端出现异常导致的，或者是由于二者之间的网络出问题而导致的。例如，后台服务端被不法分子攻击篡改，或者，出现网络抖动而导致HTTP响应丢包等。

因此，在HTTP响应中携带的状态码为预设状态码的情况下，可以判断HTTP响应携带的校验码与HTTP请求中携带的校验码是否相同，在HTTP响应携带的校验码与HTTP请求中携带的校验码相同的情况下，则可以执行步骤S205，在HTTP响应携带的校验码与HTTP请求中携带的校验码不同的情况下，则可以执行步骤S202。

在HTTP响应携带的校验码与HTTP请求中携带的校验码相同的情况下，在步骤S205中，确定小程序未出现HTTP异常。

在HTTP响应携带的校验码与HTTP请求中携带的校验码不同的情况下，执行步骤S202：确定小程序出现HTTP异常。

本申请通过“是否接收到HTTP响应”、“HTTP响应中携带的状态码是否为预设状态码”以及“HTTP响应携带的校验码与HTTP请求中携带的校验码是否相同”等三重确定方式来确定小程序是否出现HTTP异常，可以提高确定小程序是否出现HTTP异常的准确性。

进一步地，在出现HTTP异常时，还可以获取堆栈信息，堆栈信息包括HTTP请求的堆栈信息以及小程序所调用过的函数的堆栈信息，HTTP请求的堆栈信息包括HTTP请求的生成路径等，以及还可以获取HTTP请求的请求信息，请求信息包括HTTP请求的请求头部、请求方式、请求参数以及请求地址等等，还可以获取HTTP请求的入场参数，入场参数包括HTTP请求的来源、来源包括分享、搜索、收藏，点击等，然后可以将堆栈信息、请求信息以及入场参数上报至后台服务端，以使小程序的开发者在后台服务端可以根据堆栈信息、请求信息以及入场参数分析出现HTTP异常的原因，并消除HTTP异常。

在一个例子中，小程序可以从后台服务端中获取页面数据，然后渲染页面数据，以供用户查看。

其中，页面开发人员事先在开发页面时，可以编写页面对应的计算机程序代码，然后编译计算机代码，得到编译文件，编译文件即为页面的页面数据，页面数据可以存储在后台服务端中，以供前端各种服务调用。

其中，如果开发人员编写的计算机程序代码不存在错误，则编译文件即往往不存在错误，小程序渲染编译文件可以顺利地渲染成功，用户可以正常查看到页面中的内容。

然而，如果开发人员编写的计算机程序代码存在错误，则编译文件往往存在错误，小程序渲染编译文件通常无法顺利地渲染成功，例如，出现页面阻塞、或者页面内容缺失的情况，影响用户查看页面中的内容。

因此，在小程序无法顺利渲染页面数据的情况下，则说明小程序出现JS(JavaScript，脚本语言)异常。

所以，在本申请另一实施例中，参见图3，步骤S101包括：

在步骤S301中，在小程序中基于JS脚本渲染页面数据的过程中，检测小程序的控制台是否输出异常提示。

在本申请中，发明人发现，开发人员编写的计算机程序代码存在错误通常包括但不限于：语法错误、引用错误、类型错误、范围越界错误以及超链接错误等。

在一个例子中，语法错误包括计算机程序代码中缺少符号，例如，计算机程序代码包括：

console.log(｀hello＇。

在这个例子中，缺少了在｀hello＇之后的括号“)”。

在另一个例子中，引用错误包括计算机程序代码中引用的变量不存在，例如，计算机程序代码包括：

“var t＝test。

在这个例子中，上述语句的含义为对t的赋值为对象test，然而对象test在之前并未被定义，从而影响了t的赋值，此次赋值无效。

在又一个例子中，类型错误包括计算机程序代码中引用的属性不存在，例如，计算机程序代码包括：

var test＝null

var t＝test.a

在这个例子中，null实际上并没有a这个属性，从而影响了t的赋值，此次赋值无效。

其中，在小程序基于JS脚本渲染页面数据的过程中，小程序的控制台会遍历页面数据，然后检测页面数据是否出现至少上述几种错误的至少一种，在页面数据出现至少上述几种错误的至少一种的情况下，页面数据通常就无法顺利地被渲染成功，例如，出现页面阻塞、或者页面内容缺失的情况，影响用户查看页面中的内容，使得小程序出现JS异常，如此，小程序的控制台可以输出提示信息，以提示出现异常的页面数据在整个页面数据中的位置索引等。

在页面数据未出现至少上述几种错误的情况下，页面数据通常可以顺利地被渲染成功，不影响用户查看页面中的内容，小程序未出现JS异常，如此，小程序的控制台可以不输出上述提示信息。

在控制台输出异常提示的情况下，在步骤S302中，确定小程序出现JS异常。

在控制台未输出异常提示的情况下，在步骤S303中，确定小程序未出现JS异常。

在一种方式中，承载小程序的应用程序的开发者可以开发“onerror函数”来检测页面数据是否出现错误，在出现至少一个错误的情况下，可以确定小程序出现JS异常。

然而，通常情况下，基于“onerror函数”检测的错误的种类少，覆盖面小。

例如，实际上，页面数据可能会出现一些错误，这些错误会使得小程序出现JS异常，但是基于“onerror函数”检测不出这些错误，而不会确认小程序出现异常。

而在本申请中，小程序的控制台可以检测的错误的种类和覆盖面大于基于“onerror”函数可以检测的错误的种类和覆盖面，

如此，相比于上述方式，本申请实施例通过检测小程序的控制台是否输出提示信息可以检测出更多的JS异常，避免出现遗漏，从而可以提高确定小程序是否出现JS异常的准确率。

进一步地，小程序可以将异常的页面数据在整个页面数据中的位置索引上报给后台服务端，以供小程序的开发者在后台服务端上基于位置索引定位出异常的页面数据，并对异常的页面数据修改，以消除JS异常。

在本申请中，有时候用户在使用小程序的过程中，会控制小程序从外部下载数据，或者控制小程序向外部上传数据。

例如，在需要基于承载小程序的应用程序向其他人分享小程序时，通常无法直接基于应用程序分享，而需要绘制包括小程序的二维码的图片，然后保存在本地，再基于应用程序将图片分享给其他人，以使其他人通过扫描图片得到分享的小程序。其中，基于应用程序将图片分享给其他人的过程包括，将图片分享至其他人。

在一个例子中，在控制小程序向外部上传数据时，小程序往往需要借助承载小程序的应用程序来向外部上传数据，例如，需要借助应用程序的上传函数(XXX.upload.File)来向外部上传数据，其中“XXX”包括应用程序的名称等。

具体地，在小程序接收到用户输入的上传数据的指令之后，小程序可以将数据传递至承载小程序的应用程序，应用程序会根据该数据生成临时文件，然后向外部上传临时文件。

通常情况下，只要能生成临时文件，则往往就能够成功地向外部上传临时文件，出现异常的情况往往是在根据该数据生成临时文件的过程中，例如，无法根据该数据生成临时文件等。一旦在根据该数据生成临时文件的过程中问题，礼物无法生成临时文件，则会触发上传函数对应的fail回调函数。

因此，在上传函数对应的fail回调函数被触发的情况下，可以确定小程序出现上传下载异常。

相应地，在下载函数对应的fail回调函数被触发的情况下，可以确定小程序出现上传下载异常。

因此，在本申请另一实施例中，参见图4，步骤S101包括：

在步骤S401中，检测上传函数对应的fail回调函数是否被触发以及下载函数对应的fail回调函数是否被触发。

在上传函数对应的fail回调函数或下载函数对应的fail回调函数被触发的情况下，在步骤S402中，确定小程序出现上传下载异常。

在上传函数对应的fail回调函数以及下载函数对应的fail回调函数均未被触发的情况下，在步骤S403中，确定小程序未出现上传下载异常。

在本申请一个实施例中，在步骤S103中向后台服务端上报筛选的信息时，在筛选的信息为多个的情况下，可以一次性地将筛选的信息全部发送给后台服务端。

然而，对于后台服务端而言，与后台服务端直接对接的前端有很多，例如，对接有很多小程序、很多客户端以及很多web端等。

如果各个前端都是一次性地向后台服务端上传大量的信息，则会大大增加后台服务端的负荷，增大后台服务端的压力，会给后台服务端的安全性带来隐患，且在大量的前端向后台服务端上传信息的数量超过后台服务端的接收能力的情况下，可能会导致信息丢失。

因此，为了避免给后台服务端的安全性带来隐患以及为了避免丢失信息，则可以避免增加后台服务端在短时间内需要接收的信息的数量，为了避免增加后台服务端在短时间内需要接收的信息的数量，则可以降低各个前端每一次向后台服务端上传信息的数量。

例如，可以限制各个前端每一次向后台服务端上传信息的数量，例如限制为预设数量等。

具体地，对于小程序而言，在筛选的信息的数量大于预设数量的情况下，则向后台服务端分批次上报筛选的信息，每一批次上报的筛选的信息的数量可以小于或等于预设数量。

在本申请一个实施例中，在向后台服务端分批次上报筛选的信息时，可以一个一个地串行向后台服务端依次上报筛选的信息，每一个筛选的信息都会基于一个消息载体承载，例如，HTTP消息等。

然而，对于后台服务端而言，其需要一个一个串行地接收小程序上传的信息，每一个筛选的信息都会基于一个消息载体承载，例如，HTTP消息等。消息载体中除了携带信息本身，还需要携带其他与信息无关但在传输过程中需要使用的参数，例如，源IP地址、目的IP地址、源端口号、目的端口号、传输协议等各种参数。

这样，上报每一个信息的过程都需要上报一次上述参数，上述参数在上报过程中会占用一定量的网络资源。如此，上报几个信息就需要上报几次上述参数，在上报的信息较多时，就需要上报较多次上述参数，从而会占用较多的网络资源。

因此，为了节省网络资源，在本申请另一实施例中，参见图5，步骤S104包括：

在步骤S501中，在筛选的信息的数量小于预设数量的情况下，缓存筛选的信息。

在步骤S502中，判断缓存的筛选的信息的数量是否达到预设数量。

在一个可能的实现方式中，步骤S501和步骤S502可以是两个线程异步执行的。在步骤S502中可以周期性地判断缓存的筛选的信息的数量是否达到预设数量。

在达到预设数量的情况下，在步骤S503中，基于一个消息载体向后台服务端上报缓存的筛选的信息。

在未达到预设数量的情况下，返回继续执行步骤S502，其中，可以立刻返回执行步骤S502，也可以在间隔一段时长之后返回执行步骤S502。这段时长具体可根据实际需求设定，本申请对此不加以限定。

这样，需要上报的预设数量个信息可以同时基于一个消息载体承载，如此，上报多个信息的过程至需要上报一次上述参数即可，不需要重复上报多次上述参数，从而可以节省网络资源。

进一步地，为了节省存储空间，还可以在向后台服务端上报缓存的筛选的信息之后，还可以删除缓存的筛选的信息。

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

参照图6，示出了本申请的一种基于小程序的异常处理装置的结构框图，该装置具体可以包括如下模块：

检测模块11，用于检测小程序是否出现异常；

获取模块12，用于在所述小程序出现异常的情况下，基于预设可配置文件中的信息获取函数获取候选上报信息；

筛选模块13，用于在所述候选上报信息中筛选与所述异常相关的信息；

上报模块14，用于向后台服务端上报筛选的信息。

在一个可选的实现方式中，所述检测模块包括：

在一个可选的实现方式中，所述上报模块包括：

对于装置实施例而言，由于其与方法实施例基本相似，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。

图7是本申请示出的一种电子设备800的框图。例如，电子设备800可以是移动电话，计算机，数字广播终端，消息收发设备，游戏控制台，平板设备，医疗设备，健身设备，个人数字助理等。

参照图7，电子设备800可以包括以下一个或多个组件：处理组件802，存储器804，电力组件806，多媒体组件808，音频组件810，输入/输出(I/O)的接口812，传感器组件814，以及通信组件816。

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

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

电源组件806为电子设备800的各种组件提供电力。电源组件806可以包括电源管理系统，一个或多个电源，及其他与为电子设备800生成、管理和分配电力相关联的组件。

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

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

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

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

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

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

在示例性实施例中，还提供了一种包括指令的非临时性计算机可读存储介质，例如包括指令的存储器804，上述指令可由电子设备800的处理器820执行以完成上述方法。例如，所述非临时性计算机可读存储介质可以是ROM、随机存取存储器(RAM)、CD-ROM、磁带、软盘和光数据存储设备等。

图8是本申请示出的一种电子设备1900的框图。例如，电子设备1900可以被提供为一服务器。

参照图8，电子设备1900包括处理组件1922，其进一步包括一个或多个处理器，以及由存储器1932所代表的存储器资源，用于存储可由处理组件1922的执行的指令，例如应用程序。存储器1932中存储的应用程序可以包括一个或一个以上的每一个对应于一组指令的模块。此外，处理组件1922被配置为执行指令，以执行上述方法。

电子设备1900还可以包括一个电源组件1926被配置为执行电子设备1900的电源管理，一个有线或无线网络接口1950被配置为将电子设备1900连接到网络，和一个输入输出(I/O)接口1958。电子设备1900可以操作基于存储在存储器1932的操作系统，例如Windows ServerTM，Mac OS XTM，UnixTM,LinuxTM，FreeBSDTM或类似。

本说明书中的各个实施例均采用递进的方式描述，每个实施例重点说明的都是与其他实施例的不同之处，各个实施例之间相同相似的部分互相参见即可。

本领域内的小程序的开发者应明白，本申请的实施例可提供为方法、装置、或计算机程序产品。因此，本申请可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本申请可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。

本申请是参照根据本申请的方法、终端设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理终端设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理终端设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。

这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理终端设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。

这些计算机程序指令也可装载到计算机或其他可编程数据处理终端设备上，使得在计算机或其他可编程终端设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程终端设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。

尽管已描述了本申请的优选实施例，但本领域内的小程序的开发者一旦得知了基本创造性概念，则可对这些实施例做出另外的变更和修改。所以，所附权利要求意欲解释为包括优选实施例以及落入本申请范围的所有变更和修改。

最后，还需要说明的是，在本文中，诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者终端设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者终端设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、物品或者终端设备中还存在另外的相同要素。

以上对本申请所提供的一种基于小程序的异常处理方法及装置，进行了详细介绍，本文中应用了具体个例对本申请的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本申请的方法及其核心思想；同时，对于本领域的一般小程序的开发者，依据本申请的思想，在具体实施方式及应用范围上均会有改变之处，综上所述，本说明书内容不应理解为对本申请的限制。

Claims

1.一种基于小程序的异常处理方法，其特征在于，所述方法包括：

检测小程序是否出现异常；

在所述候选上报信息中筛选与所述异常相关的信息；

向后台服务端上报筛选的信息。

2.根据权利要求1所述的方法，其特征在于，所述检测小程序是否出现异常，包括：

3.根据权利要求1所述的方法，其特征在于，所述检测小程序是否出现异常，包括：

4.根据权利要求1所述的方法，其特征在于，所述检测小程序是否出现异常，包括：

5.根据权利要求1所述的方法，其特征在于，所述向后台服务端上报筛选的信息，包括：

6.根据权利要求1所述的方法，其特征在于，所述向后台服务端上报筛选的信息，包括：

判断缓存的筛选的信息的数量是否达到预设数量；

7.一种基于小程序的异常处理装置，其特征在于，所述装置包括：

检测模块，用于检测小程序是否出现异常；

上报模块，用于向后台服务端上报筛选的信息。

8.根据权利要求7所述的装置，其特征在于，所述检测模块包括：

9.根据权利要求7所述的装置，其特征在于，所述检测模块包括：

10.根据权利要求7所述的装置，其特征在于，所述检测模块包括：

11.根据权利要求7所述的装置，其特征在于，所述上报模块包括：

12.根据权利要求7所述的装置，其特征在于，所述上报模块包括：

13.一种电子设备，其特征在于，所述电子设备包括：

处理器；

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

其中，所述处理器被配置为执行如权利要求1-6任一项所述的基于小程序的异常处理方法。

14.一种非临时性计算机可读存储介质，当所述存储介质中的指令由电子设备的处理器执行时，使得电子设备能够执行如权利要求1-6任一项所述的基于小程序的异常处理方法。