检测消息通知故障的方法、装置、设备及介质与流程

1.本公开涉及计算机技术领域，尤其涉及一种检测消息通知故障的方法、装置、设备及介质。


背景技术：

2.在诸如手机等终端设备上通常会安装有应用软件，例如通讯类软件、协同办公软件等一些软件应用具有离线推送通知功能，即便终端设备当前未启用应用软件，也可以在接收到应用软件的消息时在终端设备的界面上推送消息提醒通知。
3.然而，倘若用户发现离线推送通知功能出现问题，则需要联系软件应用的客服，客服与用户沟通了解所需信息，以便排查出现故障的原因，在很多情况下客服可能还需要联系技术人员，排查到问题后再由客服联系用户进行修复。这种故障解决方式非常繁琐复杂，需要的人力成本和时间成本均较高，且用户体验较差。


技术实现要素：

4.为了解决上述技术问题或者至少部分地解决上述技术问题，本公开提供了一种检测消息通知故障的方法、装置、设备及介质。
5.本公开实施例提供了一种检测消息通知故障的方法，包括：响应于接收到故障诊断指令，基于预设的多个故障检测项中的第一类故障检测项进行检测，得到每个所述第一类故障检测项对应的第一检测结果；其中，所述故障诊断指令用于指示对离线通知推送功能的故障原因进行诊断；在所述第一类故障检测项中的目标故障检测项对应的检测结果指示无故障的情况下，基于所述多个故障检测项中的第二类故障检测项进行检测，得到每个所述第二类故障检测项对应的第二检测结果；将所述第一检测结果和所述第二检测结果按照指定方式进行展示，并展示故障原因和/或故障解决方案。
6.可选的，所述第一类故障检测项包括网络连接检测项和本地设置检测项；其中，所述目标故障检查项包括网络连接检测项。
7.可选的，基于预设的多个故障检测项中的第一类故障检测项进行检测，得到每个所述第一类故障检测项对应的第一检测结果的步骤，包括：基于所述网络连接检测项，检测所述终端设备是否未接入网络，在检测到未接入网络的情况下，确定所述网络连接检测项的第一检测结果为存在网络连接故障；基于所述本地设置检测项，检测所述终端设备是否关闭所述客户端的设备通知权限，在检测到所述设备通知权限均处于关闭状态的情况下，确定所述本地设置检测项的第一检测结果为存在设备权限设置故障。
8.可选的，所述第二类故障检测项包括服务端设置检测项以及终端设备的通道配置检测项。
9.可选的，基于所述多个故障检测项中的第二类故障检测项进行检测，得到每个所述第二类故障检测项对应的第二检测结果的步骤，包括：基于所述服务端设置检测项，通过服务端检测是否存在所述客户端禁止所述服务端下发所有通知的设置，在检测到存在所述
客户端禁止所述服务端下发所有通知的设置的情况下，确定所述服务端设置检测项的第二检测结果为存在通知下发设置故障；基于所述终端设备的通道配置检测项，通过服务端检测在所述终端设备上配置的为所述客户端下发通知的通道是否与所述客户端对应的目标通道匹配，根据匹配结果得到所述终端设备的通道配置检测项对应的第二检测结果。
10.可选的，通过服务端检测是否存在所述客户端禁止所述服务端下发所有通知的设置的步骤，包括：向通知服务器发送通知设置检测请求；所述通知设置检测请求用于指示所述通知服务器获取所述终端设备的应用内通知权限设置信息和所述终端设备的个人状态设置信息；在通过所述通知服务器检测到所述应用内通知权限均处于关闭状态或者所述个人状态设置信息包括免打扰设置的情况下，确定存在所述客户端禁止所述服务端下发所有通知的设置。
11.可选的，通过服务端检测在所述终端设备上配置的为所述客户端下发通知的通道是否与所述客户端对应的目标通道匹配的步骤，包括：向通知服务器发送通道设置检测请求，以使所述通知服务器执行如下步骤：通过所述终端设备获取在所述终端设备上配置的为所述客户端下发通知的通道；获取指定信息，根据所述指定信息得到与所述客户端对应的目标通道；所述指定信息包括所述客户端的标识信息和/或所述终端设备的设备信息；如果在所述终端设备上配置的为所述客户端下发通知的通道属于所述目标通道，确定在所述终端设备上配置的为所述客户端下发通知的通道与所述客户端对应的目标通道匹配。
12.可选的，根据所述客户端的指定信息得到与所述客户端对应的目标通道的步骤，包括：根据所述客户端的标识信息确定所述客户端的品牌类型属于第一类型的情况下，根据所述终端设备的设备信息确定所述客户端对应的目标通道；根据所述客户端的标识信息确定所述客户端的品牌类型属于第二类型的情况下，确定所述客户端对应的目标通道为指定通道；根据所述客户端的标识信息确定所述客户端的品牌类型属于第三类型的情况下，确定所述客户端对应的目标通道为任意通道。
13.可选的，根据匹配结果得到所述终端设备的通道配置检测项对应的第二检测结果的步骤，包括：在检测到不匹配的情况下，确定所述终端设备的通道配置检测项的第二检测结果为存在通道配置故障；在检测到匹配的情况下，检测所述客户端对应的通道令牌是否无效，在检测到无效的情况下，确定所述终端设备的通道配置检测项的第二检测结果为存在通道配置故障。
14.可选的，所述客户端对应的目标通道与所述客户端的品牌类型和/或所述终端设备的品牌类型相关。
15.可选的，所述方法还包括：在所述第一检查结果和所述第二检查结果均无故障的情况下，通过服务端发送离线测试通知；在离线测试通知发送失败的情况下，为用户展示问题解决渠道的渠道信息。
16.可选的，所述方法还包括：通过所述服务端发送在线测试通知；在所述在线测试通知发送成功以及所述离线测试通知发送成功的情况下，为用户展示当前的通知检测结果均正常。
17.可选的，将所述第一检测结果和所述第二检测结果按照指定方式进行展示的步骤，包括：将所述第一检测结果和所述第二检测结果中存在故障的检测结果展示在界面上；或者，将所述第一检测结果和所述第二检测结果均展示在界面上，且存在故障的检测结果
与不存在故障的检测结果的标识方式不同。
18.可选的，所述方法还包括：在所述第一检测结果或所述第二检测结果指示存在待优化的设置信息的情况下，展示优化建议；其中，所述优化建议是基于所述待优化的设置信息生成的。
19.可选的，所述故障解决方案与所述优化建议的标识方式不同，和/或，所述故障解决方案的展示优先级高于所述优化建议的展示优先级。
20.可选的，所述故障解决方案在界面中的展示位置优于所述优化建议在界面中的展示位置；和/或，展示所述故障解决方案时不展示所述优化建议，且所述优化建议是在不存在所述故障解决方案的情况下进行展示。
21.可选的，所述方法还包括：基于所述第一检测结果或所述第二检测结果执行上报操作。
22.本公开实施例还提供了一种检测消息通知故障的装置，应用于客户端，包括：第一检测模块，用于响应于接收到故障诊断指令，基于预设的多个故障检测项中的第一类故障检测项进行检测，得到每个所述第一类故障检测项对应的第一检测结果；其中，所述故障诊断指令用于指示对离线通知推送功能的故障原因进行诊断；第二检测模块，用于在所述第一类故障检测项中的目标故障检测项对应的检测结果指示无故障的情况下，基于所述多个故障检测项中的第二类故障检测项进行检测，得到每个所述第二类故障检测项对应的第二检测结果；结果展示模块，用于将将所述第一检测结果和所述第二检测结果按照指定方式进行展示，并展示故障原因和/或故障解决方案。
23.本公开实施例还提供了一种电子设备，所述电子设备包括：处理器；用于存储所述处理器可执行指令的存储器；所述处理器，用于从所述存储器中读取所述可执行指令，并执行所述指令以实现如本公开实施例提供的故障处理方法。
24.本公开实施例还提供了一种计算机可读存储介质，所述存储介质存储有计算机程序，所述计算机程序用于执行如本公开实施例提供的故障处理方法。
25.本公开实施例提供的上述技术方案，可以基于预设的多个故障检测项进行自动化故障检测，有效缩减人工成本和耗时成本；而且还会将故障检测项进行分类，第二类故障检测项检测与否依赖于第一类故障检测项的检测结果，也进一步提高了检测效率；另外，上述方式还能够基于检测结果进行展示，并提供故障原因和/或故障解决方案，以便于用户清楚获知故障原因以及故障处理方式。综上，上述方式可以实现高效的离线通知推送功能的故障自动检测，有效降低故障处理成本，并为用户提供良好的故障处理体验。
26.应当理解，本部分所描述的内容并非旨在标识本公开的实施例的关键或重要特征，也不用于限制本公开的范围。本公开的其它特征将通过以下的说明书而变得容易理解。
附图说明
27.此处的附图被并入说明书中并构成本说明书的一部分，示出了符合本公开的实施例，并与说明书一起用于解释本公开的原理。
28.为了更清楚地说明本公开实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，对于本领域普通技术人员而言，在不付出创造性劳动性的前提下，还可以根据这些附图获得其他的附图。
29.图1为本公开实施例提供的一种离线推送通知的流程示意图；
30.图2为本公开实施例提供的一种检测消息通知故障的方法的流程示意图；
31.图3为本公开实施例提供的一种界面示意图；
32.图4为本公开实施例提供的一种界面示意图；
33.图5为本公开实施例提供的一种界面示意图；
34.图6为本公开实施例提供的一种界面示意图；
35.图7为本公开实施例提供的一种界面示意图；
36.图8为本公开实施例提供的一种界面示意图；
37.图9为本公开实施例提供的一种界面示意图；
38.图10为本公开实施例提供的一种界面示意图；
39.图11为本公开实施例提供的一种通道配置检测方法流程图；
40.图12为本公开实施例提供的一种界面示意图；
41.图13为本公开实施例提供的一种界面示意图；
42.图14为本公开实施例提供的一种界面示意图；
43.图15为本公开实施例提供的一种检测消息通知故障的装置的结构示意图；
44.图16为本公开实施例提供的一种电子设备的结构示意图。
具体实施方式
45.为了能够更清楚地理解本公开的上述目的、特征和优点，下面将对本公开的方案进行进一步描述。需要说明的是，在不冲突的情况下，本公开的实施例及实施例中的特征可以相互组合。
46.在下面的描述中阐述了很多具体细节以便于充分理解本公开，但本公开还可以采用其他不同于在此描述的方式来实施；显然，说明书中的实施例只是本公开的一部分实施例，而不是全部的实施例。
47.如果终端设备未启用某应用软件的客户端，应用软件的客户端未与服务端建立长链接，则视为离线状态。离线推送通知功能可以使终端设备即便未启用某应用软件，也能够在接收到该应用软件的消息时在终端设备的界面上推送消息提醒通知。
48.为便于理解，本公开实施例提供了如图1所示的一种离线推送通知的流程示意图，以设备a为例，设备a上设置有应用软件(以下称为目标app)，设备a通过步骤1～4与通知中台(由目标app的开发商设置)和通道服务器(诸如手机厂商的服务器)进行交互，从而实现设备a的初始化。该初始化过程通常会发生在目标app冷启动或者重新登录等情形。示例性地，设备a在步骤1可向通知中台发送通道更新请求，通知中台在步骤2可根据目标app能够集成的通知推送通道类型以及设备a的机型等信息向设备a返回设备a对应的通知推送通道(也可称为离线通道)；设备a在步骤3中可向通知推送通道对应的通道服务器注册申请通道令牌，通道服务器在步骤4中可向设备a返回有效的通道令牌，至此设备a完成初始化。假设用户b通过设备b上安装的目标app向用户a发送消息，具体而言，设备b上的目标app首先在步骤6中将消息发送至消息服务器(由目标app的开发商设置)，消息服务器会根据消息接收方的账号信息、设备信息等信息判断接收方(用户a)是否在设备上登录有目标app，如果用户a当前通过设备a登录有目标app，则直接向设备a进行长链接推送通知(此时设备a接收到
在线消息通知)，假设用户a未登录目标app，也即用户a的目标app处于离线状态，则需要走离线推送通知的链路，此时需要通过步骤7将消息发送给通知中台，通知中台可以根据设备a注册的离线通道以及通道令牌在步骤8中将消息推送至设备a对应的通道服务器中，通道服务器可根据通道令牌在步骤9中将消息通知给设备a(此时设备a接收到离线消息通知)，此时用户a虽然未在设备a上登录目标app，也即目标app未启用，但设备a仍旧可以在屏幕上发起通知提示，以提醒用户a接收到新消息。
49.简而言之，倘若用户b向用户a发送消息，且用户a在设备a中登录有目标app，则通过在线通知链路实现在线消息通知，该在线通知链路从前至后依次为：设备b、消息服务器至设备a。如果用户a未在设备a中登录目标app，则通过离线通知链路实现离线消息通知，该离线通知链路从前至后依次为：设备b、消息服务器、通知中台、通道服务器至设备a。离线通知链路比在线通知链路更复杂，也更容易出现故障。应当说明的是，图1仅为一种示例性说明，不应当被视为限制，诸如，在实际应用中，一些app的开发商也可能并未设置通知中台，由app的指定服务端直接实现图1中通知中台和/或消息服务器的功能。
50.如图1所示，离线推送通知的整个流程涉及的链路较多，且较为复杂。相关技术仅通过人力解决的方式所需成本较高，且效率低下。另外，人工交互过程也容易出现信息错误等情况，导致检测可靠性较差。为改善以上问题至少之一，本公开实施例提供了一种检测消息通知故障的方法、装置、设备及介质，以下进行详细阐述说明。
51.图2为本公开实施例提供的一种检测消息通知故障的方法的流程示意图，该方法可以由检测消息通知故障的装置执行，其中该装置可以采用软件和/或硬件实现，一般可集成在电子设备中，该方法可应用于客户端，客户端可安装于电子设备上，电子设备可以为手机、电脑、可穿戴设备等终端设备，在此不进行限制，客户端具体为软件应用(app)的客户端，在此对软件应用的类型不进行限制，任何具有离线通知推送功能的软件应用均可。如图2所示，该方法主要包括如下步骤s202～步骤s206：
52.步骤s202，响应于接收到故障诊断指令，基于预设的多个故障检测项中的第一类故障检测项进行检测，得到每个第一类故障检测项对应的第一检测结果；其中，故障诊断指令用于指示对离线通知推送功能的故障原因进行诊断；不同的故障检测项用于检测的故障不同；故障检测项基于离线通知推送功能的影响因素确定。
53.在实际应用中，理论上用户在接收新消息时也会收到一条提示接收到新消息的通知。示例性的，虽然在应用软件的客户端处于离线状态下(应用软件的客户端与服务端之间无长连接时)无法接收到消息，只有在用户登录应用软件的客户端之后才会看到消息的具体内容，但离线通知推送功能可以使用户在应用软件的客户端处于离线状态下仍旧可以接收到用于提示接收到新消息的通知。倘若用户登录应用软件的客户端后发现有很多新消息，但在此期间却并未接收到新消息对应的通知，则说明离线推送通知出现故障，此时用户可发起故障诊断指令。具体实现时，客户端可以设置故障诊断按键，如果检测到故障诊断按键被触发，则认为接收到用户下发的故障诊断指令。
54.本公开实施例可以根据离线通知推送功能的影响因素设置多个故障检测项，影响因素可根据离线通知推送功能的实现链路确定，将链路中可能出现问题的节点作为推送功能的影响因素，示例性地，影响因素包括但不限于网络连接因素、用户设置因素及通道配置因素等，用户设置因素又可分为本地设置和服务端设置，诸如，诸如设备通知权限可视为本
地设置、应用内的通知权限可视为服务端设置。
55.本公开实施例对故障检测项的具体检测内容不进行限制，任何可能引起离线通知推送功能异常的检测项均可。但是，本公开实施例会将故障检测项划分为多个类别，诸如划分为第一类故障检测项和第二类故障检测项，第一类故障检测项可以为不需要依赖网络的检测项，也即为客户端进行本地检测的检测项；第二类故障检测项可以为需要依赖网络的检测项，也即为客户端需要通过服务端进行检测的检测项。
56.在一些具体的实施示例中，第一类故障检测项包括网络连接检测项和本地设置检测项。网络连接检测项主要目的在于检测终端设备是否连接网络，本地设置检测项的主要目的在于检测与离线通知推送功能相关的本地设置是否存在异常，诸如是否关闭有客户端的设备通知权限。
57.检测结果可用于指示相应的检测项是否存在故障(也可称为问题或异常)，进一步还可以标明问题原因，本公开实施例对检测结果的具体形式不进行限制。
58.步骤s204，在第一类故障检测项中的目标故障检测项对应的检测结果指示无故障的情况下，基于多个故障检测项中的第二类故障检测项进行检测，得到每个第二类故障检测项对应的第二检测结果。应当说明的是，在本公开实施例中，为便于描述及区分，每个第一类故障检测项对应的检测结果在此可称为第一检测结果，每个第二类故障检测项对应的检测结果在此可称为第二检测结果。
59.第二类故障检测项检测与否依赖于第一类故障检测项的检测结果，具体而言，依赖第一类故障检测项中的目标故障检测项的检测结果，倘若目标故障检测项检测无故障，才会对第二类故障检测项进行检测，否则不会再对第二类故障检测项进行检测，这种方式可以有效提升检测效率，避免无用尝试。在一些具体的实施示例中，目标故障检测项可以为网络连接检测项，第二类故障检测项为需要依赖网络的检测项，可以理解的是，在网络连接检测项指示存在故障的情况下，则不再对第二类故障检测项进行检测。另外应当说明的是，第一类故障检测项中除了目标故障检测项之外的其它故障检测项的检测结果不会对第二类故障检测项是否检测造成影响。
60.在一些具体的实施示例中，第二类故障检测项包括服务端设置检测项以及终端设备的通道配置检测项；其中，终端设备为安装客户端的设备。服务端设置检测项主要目的在于检测与离线通知推送功能相关的服务端设置是否存在异常，该服务端主要为应用软件对应的服务端。诸如是否禁止服务端下发通知，诸如关闭应用内的通知权限或者用户在应用内设置个人状态，标明静音免打扰，此时服务端不会再下发消息通知，具体而言，应用软件的服务端不会再给通道服务器发送消息通知。
61.步骤s206，将第一检测结果和第二检测结果按照指定方式进行展示，并展示故障原因和/或故障解决方案。
62.本公开实施例对指定方式不进行限制，在一些实施示例中，可以将第一检测结果和第二检测结果中存在故障的检测结果展示在界面上，以便于用户直接获知出现故障的原因；在另一些实施示例中，可以将第一检测结果和第二检测结果均展示在界面上，以便于用户清楚全面地获知每个检测项的检测结果，且存在故障的检测结果与不存在故障的检测结果的标识方式不同，以便于用户快速高效地从多个检测结果中识别出存在故障的检测结果，从而采取相应措施。
63.除了展示检测结果，还可以进一步根据检测结果提供故障原因和/或故障解决方案，具体实现时，如果多个检测结果中存在有指示有故障的检测结果时(也即存在异常的检测结果时)，则提供故障原因和/或故障解决方案，在一些实施示例中，将存在故障的检测结果对应的故障原因和/或故障解决方案展示在界面指定位置，故障原因可以使用户清楚获知离线通知推送功能的故障原因，故障解决方案可以使用户清楚获知如何解决该故障，从而进一步提升故障解决效率。另外应当说明的是，假设第一类故障检测项中的目标故障检测项对应的检测结果指示存在故障，则第二类故障检测项不再检测，相应的第二检测结果可以为未检测，还可以进一步给出未检测的理由是目标故障检测项的检测结果异常所致。
64.本公开实施例提供的上述技术方案，可以基于预设的多个故障检测项进行自动化故障检测，有效缩减人工成本和耗时成本；而且还会将故障检测项进行分类，第二类故障检测项检测与否依赖于第一类故障检测项的检测结果，也进一步提高了检测效率；另外，上述方式还能够基于检测结果进行展示，并提供故障原因和/或故障解决方案，以便于用户清楚获知故障原因以及故障处理方式。综上，上述方式可以实现高效的离线通知推送功能的故障自动检测，有效降低故障处理成本，并为用户提供良好的故障处理体验。
65.在一些具体的实施示例中，基于预设的多个故障检测项中的第一类故障检测项进行检测，得到每个第一类故障检测项对应的第一检测结果的步骤，包括如下步骤a和步骤b：
66.步骤a，基于网络连接检测项，检测终端设备是否未接入网络，在检测到未接入网络的情况下，确定网络连接检测项的第一检测结果为存在网络连接故障。
67.网络连接异常是最常见的离线通知推送功能的故障原因，而且也会影响大多其它依赖网络的检测项，因此可以首先对网络连接检测项进行检测。具体检测网络是否连接的方式可参照相关技术，在此不进行限制。
68.步骤b，基于本地设置检测项，检测终端设备是否关闭客户端的设备通知权限，在检测到设备通知权限均处于关闭状态的情况下，确定本地设置检测项的第一检测结果为存在设备权限设置故障。
69.可以理解的是，用户可以直接在终端设备的设置页中设置是否关闭客户端的设备通知权限，在一些具体的实施示例中，设备通知权限可能有一个或多个，不同权限对应不同的消息通知，诸如紧急消息通知、指定联系人的消息通知等，如果所有通知权限均处于关闭状态，则会导致用户始终无法收到离线通知，因此可认为设备权限设置故障。在实际应用中，可以设置分别的通知权限，不同通知权限对应的消息类型不同，也可以额外设置一个总的通知权限，倘若该总通知权限被关闭，也代表所有通知权限均被关闭，也即所有类型的消息通知都不会到达终端设备。应当说明的是，用户在终端设备本地设置了设备通知权限后，虽然客户端对应的消息服务器仍旧会给通道服务器发送消息通知，但是通道服务器不会再给终端设备下发该消息通知。
70.在一些具体的实施示例中，基于多个故障检测项中的第二类故障检测项进行检测，得到每个第二类故障检测项对应的第二检测结果的步骤，包括如下步骤c和步骤d：
71.步骤c，基于服务端设置检测项，通过服务端检测是否存在客户端禁止服务端下发所有通知的设置，在检测到存在客户端禁止服务端下发所有通知的设置的情况下，确定服务端设置检测项的第二检测结果为存在通知下发设置故障。
72.在一些实施示例中，可以向通知服务器发送通知设置检测请求；通知设置检测请
求用于指示通知服务器获取终端设备的应用内通知权限设置信息和终端设备的个人状态设置信息；在通过通知服务器检测到应用内通知权限均处于关闭状态或者个人状态设置信息包括免打扰设置的情况下，确定存在客户端禁止服务端下发所有通知的设置。
73.其中，应用内通知权限即为用户在客户端内(也即软件应用内)针对通知权限进行的设置，诸如用户在应用内设置全部消息均不通知。个人状态设置信息可以为用户在应用内设置的具体个人状态，诸如用户设置的个人状态为免打扰状态，或者用户设置的个人状态指示某段时间静音(也意味免打扰)，则均指示个人状态设置信息包括免打扰设置，在此情况下，则确定存在客户端禁止服务端下发所有通知的设置。
74.应当说明的是，本公开实施例对客户端禁止服务端下发所有通知的设置方式不进行限制，以上仅为示例，不同应用的设置方式不同，在此不进行限制。
75.可以理解的是，如果禁止服务端下发所有通知的设置，也即软件应用的服务端不会再下发消息通知，则用户始终无法接收到离线消息通知，此时则可认为通知下发设置故障，该问题导致离线通知推送功能无法正常使用。
76.另外，本公开实施例充分考虑到客户端可能存在设置信息记录异常等问题，因此直接通过服务端来检测是否存在客户端禁止服务端下发所有通知的设置的方式，与直接通过客户端判别是否存在禁止服务端下发所有通知的设置相比，更为准确可靠。
77.步骤d，基于终端设备的通道配置检测项，通过服务端检测在终端设备上配置的为客户端下发通知的通道是否与客户端对应的目标通道匹配，根据匹配结果得到终端设备的通道配置检测项对应的第二检测结果。
78.如图1所示，在离线通知推送功能的实现链路中涉及到通道配置，如果为客户端下发通知的通道与客户端对应的目标通道不匹配，也会导致终端设备无法正常接收到离线消息通知。示例性地，假设设备a为手机品牌a，其对应的目标通道应为手机品牌a的厂商通道a，但假设终端设备上配置的为客户端下发通知的通道是手机品牌b的厂商通道b，则也会导致设备a无法正常接收到离线消息通知。
79.在一些实施例中，通过服务端检测在终端设备上配置的为客户端下发通知的通道是否与客户端对应的目标通道匹配的步骤，包括：向通知服务器发送通道设置检测请求，以使通知服务器执行如下步骤d1～d3：
80.步骤d1，通过终端设备获取在终端设备上配置的为客户端下发通知的通道。
81.在实际应用中，终端设备可以向服务端上报其为客户端配置的下发通知的通道类型。
82.步骤d2，获取指定信息，根据指定信息得到与客户端对应的目标通道；指定信息包括客户端的标识信息和/或终端设备的设备信息。
83.在实际应用中，可以基于客户端的标识信息判别客户端的品牌类型，进而确定客户端对应的目标通道，示例性地，可以将客户端的品牌类型划分为三类：
84.(一)根据客户端的标识信息确定客户端的品牌类型属于第一类型的情况下，根据终端设备的设备信息确定客户端对应的目标通道。也即，在客户端属于第一类型时，则目标通道与设备信息相关，具体而言，该设备信息包括终端设备的品牌类型。换言之，属于第一类型的客户端所安装的终端设备品牌类型不同，则该客户端对应的目标通道不同，可以理解的是，不同的终端设备生产商都配置有相应的通道，此时则将该通道作为客户端对应的
目标通道。
85.(二)根据客户端的标识信息确定客户端的品牌类型属于第二类型的情况下，确定客户端对应的目标通道为指定通道。也即，当客户端属于第二类型的情况下，则不再考虑终端设备是何种品牌，而直接将指定通道作为客户端的目标通道。示例性地，该指定通道为gcm通道。
86.(三)根据客户端的标识信息确定客户端的品牌类型属于第三类型的情况下，确定客户端对应的目标通道为任意通道。也即，当客户端属于第三类型的情况下，为客户端配置的任意通道均可支持为客户端下发离线消息通知。
87.通过将基于客户端的标识信息确定客户端的品牌类型，从而确定相应的通道，相对准确可靠，而且具有普适性，可较好适用于大多数客户端，以上仅为示例，具体可根据需求进行设置，在此不进行限制。
88.步骤d3，如果在终端设备上配置的为客户端下发通知的通道属于目标通道，确定在终端设备上配置的为客户端下发通知的通道与客户端对应的目标通道匹配。
89.诸如，对于客户端的品牌类型属于第一类型或第二类型的情况下，如果在终端设备上配置的为客户端下发通知的通道与客户端对应的目标通道一致，则确定匹配。对于客户端的品牌类型属于第三类型的情况下，无论在终端设备上配置的为客户端下发通知的通道是何种通道，都属于目标通道(也即任意通道)，也即与目标通道匹配。
90.本公开实施例充分考虑到离线通知故障可能是因为通道不匹配导致，通过上述方式可以对通道的匹配性进行准确可靠地检测。
91.在检测到终端设备上配置的为客户端下发通知的通道与客户端对应的目标通道是否匹配的结果后，在一些具体的实施示例中，根据匹配结果得到终端设备的通道配置检测项对应的第二检测结果的步骤，包括如下(1)～(2)：
92.(1)在检测到不匹配的情况下，确定终端设备的通道配置检测项的第二检测结果为存在通道配置故障。也即，倘若不匹配，则直接认为当前存在通道配置故障。
93.(2)在检测到匹配的情况下，检测客户端对应的通道令牌是否无效，在检测到无效的情况下，确定终端设备的通道配置检测项的第二检测结果为存在通道配置故障。也即，倘若匹配，则会进一步检测通道令牌是否有效，通常而言，通道令牌都附带有效期，如果客户端对应的通道令牌不在有效期内，则通道令牌无效，如图1相关内容可知，此时也会导致客户端所在的终端设备无法接收到离线消息通知。
94.综上，通过上述步骤a～步骤d，可以将影响离线通知推送功能的多个主要因素都进行排查，从而较为准确可靠地查找到离线通知推送功能的故障原因。
95.为了进一步确保离线通知推送功能的可用性，在前述基础上，上述方法还包括步骤e：在第一检查结果和第二检查结果均无故障的情况下，通过服务端发送离线测试通知；在离线测试通知发送失败的情况下，为用户展示问题解决渠道的渠道信息。也即，可以给用户模拟推送一条离线消息通知，该离线消息通知的发送链路可参见图1所示的离线通知链路，在此不再赘述。如果可以顺利推送，则代表检测结果均正常；而如果无法顺利推送，则代表检测结果有问题，可能还需要更专业的技术人员进行排查，因此可为用户提供问题解决渠道的渠道信息，诸如为用户提供联系it服务的联系通道的信息。
96.进一步地，还可以通过服务端发送在线测试通知；在线消息通知的发送链路可参
见图1所示的在线通知链路，在此不再赘述。在所述在线测试通知发送成功以及所述离线测试通知发送成功的情况下，为用户展示当前的通知检测结果均正常。也即，本公开实施例还可以进一步对在线通知功能进行检测，为用户展示更为全面的检测结果，通过测试的方式判别用户当前是否可以正常接收离线消息通知及在线消息通知，测试结果有助于用户清楚了解当前是否还存在问题或者是否还需要进一步采取其它措施，有效提升用户感受。
97.此外，在本公开实施例中，在第一检测结果或第二检测结果指示存在待优化的设置信息的情况下，展示优化建议；其中，优化建议是基于待优化的设置信息生成的。在设备通知权限的设置中，可能存在部分消息类型的通知权限未被开启，或者部分通知提示音未被开启的情况，这些虽然不被视为检测结果异常，但由于会导致用户无法接收到部分离线消息通知，因此可建议用户对该类设置信息进行优化，诸如开启所有通知权限，以此确保离线通知推送功能可以完全正常使用，避免遗漏离线消息通知。
98.在一些具体的实施示例中，故障解决方案与优化建议的标识方式不同，和/或，故障解决方案的展示优先级高于优化建议的展示优先级。
99.故障解决方案与优化建议的标识方式不同，从而可以使用户清楚区分二者的重要程度，诸如故障解决方案的标识更为明显，可以为红色标识等，指示用户需要基于故障解决方案解决故障才可使离线通知推送功能恢复正常，而相比之下，优化建议的标识可以为蓝色标识，只给出用户提示即可。另外，故障解决方案的展示优先级可以高于优化建议的展示优先级，在一些实施方式中，展示故障解决方案时不展示所述优化建议，且优化建议是在不存在所述故障解决方案的情况下进行展示。也即，在存在故障的检测结果时，优先将故障解决方案展示在界面指定位置(诸如界面顶部)，只有所有检测结果均正常时，再将优化建议展示在界面指定位置。在一些实施方式中，故障解决方案在界面中的展示位置优于优化建议在界面中的展示位置，诸如，故障解决方案可以展示在界面的醒目位置，该醒目位置诸如是界面的顶端位置或者中心位置等，而优化建议可以展示在界面的其它非重要位置。通过上述方式，可以使用户直观便捷地区分故障解决方案与优化建议，并采取相应的措施。
100.为便于理解，在上述基础上，本公开实施例进一步给出一种具体实施示例，检测消息通知故障的方法可以主要执行如下主要步骤一～步骤六：
101.步骤一，检查网络连接，该步骤对应上述步骤a。
102.步骤二，检查设备通知权限，该步骤对应上述步骤b。
103.步骤三，检查应用内的通知设置，该步骤对应上述步骤c。
104.步骤四，检查用户个人状态，该步骤对应上述步骤c。
105.步骤五，检查其他相关配置，该步骤对应上述步骤d。
106.步骤六，发送测试消息，该步骤对应上述步骤e。
107.应当说明的是，上述步骤三～步骤六由于依赖步骤一，因此需要在步骤一之后执行，步骤六需要在步骤一到五之后再执行，但步骤三～步骤五之间无执行先后顺序，可以根据需求进行设置，诸如从步骤三至步骤五依次执行或者同时执行均可，步骤一和步骤二之间也无关联性，可以依次执行也可以同时执行，在此均不进行限制。
108.在本公开实施例中，在每个检测项检测结束后，检测结果可以按照指定方式进行展示，同时还可以进一步在界面的指定位置展示故障原因和故障解决方案，示例性地，可以参照图3所示的一种界面示意图，在检测界面的顶部以横幅的形式展示故障原因和故障解
决方案，图3示意出：在“检查应用内的通知设置”的右侧通过感叹号标识的方式指示该检测项存在故障，在“检查你的网络连接”、“检查设备通知权限”等检测项的右侧通过对勾标识的方式指示该检测项正常，不存在故障；在“发送测试消息”的检测项的右侧通过问号标识的方式指示该检测项未能进行检测。在实际应用中，只有在前五个检测项都检测完成确认无故障的情况下，才会执行发送测试消息的操作。另外，感叹号、对勾以及问号标识的颜色可以不同，诸如，可以令感叹号为红色，以提醒用户该检测项存在故障，问号标识为灰色，以提醒用户该项未能检测等。在图3中，检测到应用内的通知设置存在问题，因此可以在界面顶部以横幅形式指明故障原因“你已设置不接收新消息通知”，以及指明故障解决方案“请前往当前应用的“设置＞通知”中调整允许通知的消息类型”，以便于用户清楚获知故障原因以及如何解决，从而提升故障处理效率。
109.倘若所有检测项的检测结果均无误，且在检测结果指示存在待优化的设置信息的情况下，则可以基于待优化的设置信息提供优化建议。如图4所示，假设在检查应用内的通知设置时发现用户关闭了部分消息类型的通知权限，则可以在界面顶部以横幅形式给出优化建议，指示用户已设置仅接收部分新消息通知，并给出优化建议为“前往当前应用的“设置＞通知”中调整允许通知的消息类型”。
110.应当说明的是，图3和图4只是对检测结果、故障原因、故障解决方案和优化建议进行的示例性说明，不应当被视为限制。
111.为便于理解，以下对上述六个步骤(步骤一～步骤六)的具体实现方式进行具体阐述：
112.(一)检查网络连接。
113.具体而言，可检查终端设备是否连接有网络，在实际应用中，任何检查网络连接的方式均可，在此不进行限制。示例性地，客户端可以通过预设接口获取网络检查结果，在网络检查结果中出现指定标识时则认为检测结果异常(也即网络连接异常)，若未出现指定标识则认为检测结果正常(也即网络连接正常)。
114.在得到网络连接的检查结果后，可参见图5所示的界面示意图，倘若检测到网络连接异常，则针对网络连接的检测项发起异常提示，并在界面顶部通过横幅形式指示故障原因为当前无网络连接，解决方案为请检查你的网络设置，并且还可以指引用户点击跳转至网络设置页面，进行诸如wlan等设置。
115.应当说明的是，在本公开实施例中，由于检查应用内的通知设置、检查你的个人状态、检查其他相关设置和发送测试消息等检测项需依赖网络，因此在确认网络连接异常后，后续检测项不再执行。
116.(二)检查设备通知权限。
117.在实际应用中，用户可以直接在终端设备上设置是否开启设备通知权限。在具体检查时，可以首先检查用户是否在终端设备的通知设置中关闭客户端的通知总开关，如果关闭，则说明设备通知权限均处于关闭状态，此时则认为检测结果异常；而如果总开关开启，且存在部分设备通知权限未开启，虽然会认为检测结果正常，但可为用户提供优化建议，诸如建议用户将已关闭的部分设备通知权限开启。
118.在得到设备通知权限的检查结果后，可参见图6所示的界面示意图，虽然所有检查结果均正常，但由于并非所有设备通知权限均被关闭，因此仍旧存在优化建议，具体而言可
在界面顶部横幅中指明现有的设置信息中存在未开启的部分通知类别，且提供的优化建议为：请在系统设置中开启本应用的通知权限，并开启全部通知类别和通知提示音。
119.(三)检查应用内的通知设置。
120.在实际应用中，可以检查客户端的应用内设置页中所有与通知相关的开关状态，诸如用户设置了“全部不通知”、“关闭手机通知”等，说明客户端禁止服务端下发所有通知，此时认为检测结果异常，而如果只有部分通知开关处于关闭状态，此时虽然认为检测结果正常，但可为用户提供优化建议，诸如将已关闭的部分通知开关开启。
121.在得到应用内的通知设置的检查结果后，可参见图7所示的界面示意图，在检查到存在诸如“全部不通知”、“关闭手机通知”等应用内的设置时，则“检测应用内的通知设置”的右侧叹号标识指示该检测结果异常，并在界面顶部指明当前故障原因为：已设置不接收新消息通知；并给出故障解决方案为：请前往当前应用的“设置＞通知”中调整允许通知的消息类型。示例性地，图8所示的界面示意图展示出应用内的通知设置，如图8所示，有多个关于通知的开关，如果用户选择“全部不通知”或者“关闭手机通知”，则说明客户端禁止服务端下发所有通知，此时则认为检测结果异常，而如果用户只是选择“通话与会议中关闭消息通知”或“部分新消息”等，则认为检测结果正常，但是可以提醒用户开启所有开关，避免遗漏通知。
122.(四)检查用户个人状态。
123.在本公开实施示例中，用户可以在客户端中设置个人状态，如果个人状态指示用户在某时间段内禁止服务端下发所有通知，则认为检测结果异常。示例性地，用户设置了某时间段的个人状态为开会状态，且开启静音，则意味着客户不希望在该时间段内再接收到所有消息通知，因此该项设置会导致离线通知推送功能无法正常使用。
124.在得到用户个人状态的检查结果后，可参见图9所示的界面示意图，“检测你的个人状态”的右侧叹号标识指示该检测结果异常，并在界面顶部指明当前故障原因为：因为当前开启的个人状态，消息通知已暂停；并给出故障解决方案为：如果希望收到消息通知，请前往“我的状态”页面，关闭当前状态。为便于理解，可参见图10所示的界面示意图，示意出用户的状态为请勿打扰，且用户指明在18:00之前需要会议，并设置了静音，说明用户需要在此期间禁止服务端下发所有通知，此时用户在此期间不会接收到离线消息通知。
125.应当说明的是，上述检查应用内的通知设置中的“全部不通知”或者“关闭手机通知”，与本项中的个人状态中针对某状态设置静音，均是用户禁止服务端下发所有通知的可实现方式，只是设置途径不同，在实际应用中，还可以采用其它途径，在此不进行限制。
126.(五)检查其他相关配置。
127.在实际应用中，可以检查通道配置；具体而言，通过服务端检测在终端设备上配置的为客户端下发通知的通道是否与客户端对应的目标通道匹配，根据匹配结果得到终端设备的通道配置检测项对应的检测结果。其中，客户端对应的目标通道与客户端的品牌类型和/或终端设备的品牌类型相关，为便于理解，可以参照如图11所示的一种通道配置检测方法流程图，该方法流程可以由软件应用的服务端执行，主要包括如下步骤:
128.步骤s1102，获取客户端的品牌信息、终端设备的品牌信息，以及在终端设备上配置的为客户端下发通知的通道的信息。在实际应用中，软件应用的服务端可以获取客户端的appid、品牌等相关信息，还可以进一步获取客户端当前对应的通知下发通道的信息(通
道类型)，以及终端设备的品牌信息，诸如终端设备是手机，则获取手机品牌名称。
129.步骤s1104，根据客户端的品牌信息以及终端设备信息，确定客户端对应的目标通道。
130.步骤s1106，判断在终端设备上配置的为客户端下发通知的通道是否与客户端对应的目标通道匹配。如果匹配，执行步骤s1108，如果不匹配，执行步骤s1110。
131.其中，客户端对应的目标通道与客户端的品牌类型和/或终端设备的品牌类型相关。示例性地，假设客户端的品牌类型为第一类型，则客户端对应的目标通道为终端设备的品牌类型(也可称为生产商类型)对应的通道；假设客户端的品牌类型为第二类型，则客户端对应的目标通道为指定通道，诸如为gcm通道；假设客户端的品牌类型为第三类型，则客户端对应的目标通道可以为任意通道。以上仅为示例，在此不进行限制,在实际应用中，假设软件应用的生产商有多个客户端品牌，则可以首先获取客户端的appid，以此获知客户端的品牌类型，从而选择相应的目标通道；如果软件应用的生产商只有一个客户端品牌，则只需判别终端设备为该客户端当前配置的通道与预设的目标通道是否匹配即可。具体可灵活设置，在此不再赘述。
132.步骤s1108，检测客户端对应的通道令牌是否有效。如果无效，执行步骤s1110，如果有效，执行步骤s1112。
133.步骤s1110，确认检测结果异常。
134.步骤s1112，确认检测结果正常。通过上述方式，可以将通道类型和通道令牌进行检测，只有均没问题的情况下，才可认为其他相关配置的检测结果正常。
135.在得到其他相关配置的检查结果后，可参见图12所示的界面示意图，“检查其他相关配置”的右侧叹号标识指示该检测结果异常，并在界面顶部指明当前故障原因为：其他相关配置错误；并给出故障解决方案为：服务配置出错，请联系客服或你所在企业的it部门。
136.(六)发送测试消息。
137.只有在上述步骤一至步骤五的检测结果均正常时，才会发送测试消息，用以模拟推送离线消息通知，以便于测试离线通知推送功能能否正常使用。在一些实施示例中，除了发送离线消息通知，还可以模拟给用户推送在线消息通知，以便进一步核查在线消息通知能否正常推送，以便充分保障所有消息通知均可正常接收。
138.在得到发送测试消息的检查结果后，可参见图13所示的界面示意图，示意出所有检测结果均正常；但考虑到特殊情况，倘若用户仍旧无法正常接收到离线消息通知，仍旧给用户提供了诸如联系客服等解决渠道。此外，还可以进一步引导用户开启保持客户端在线的设置，以便用户可以在线接收消息通知。如果发送测试消息失败，则可以参见图14所示的界面示意图，“发送测试消息”的右侧叹号标识指示该检测结果异常，并在界面顶部指明当前故障原因为：测试消息发送失败；并给出故障解决方案为：请联系客服或你所在企业的it部门。
139.上述步骤一和步骤六的可实现方式均可参照前述步骤a～步骤e的相关内容，在此不再赘述。
140.在实际应用中，还可以基于第一检测结果或第二检测结果执行上报操作。诸如，将所有检测结果均上报至软件应用的服务端，以使软件应用的相关人员对检测结果进行分析，对出现故障的常见问题进行改进，从而降低此类问题的发生频率，进一步提升用户的使
用体验等。另外，检测结果的上报也有助于研发同学进一步研究分析，提示研发效率。
141.综上所述，本公开实施例提供的上述检测消息通知故障的方法，可以对离线通知推送功能涉及的整个链路(通知推送链路)进行自动化检测，节约人力成本的基础上也可以保障检测过程中获取的信息是准确的，避免人工获取错误信息等问题，从而有效保障故障检测的准确性。另外，可以将检测结果、故障原因和故障解决方案均提供给用户，用户可以清楚了解当前故障情况，以及可以自行解决大部分故障，有效提升故障处理效率。此外，通过上报检测结果，还便于软件应用的生产商进行数据分析及改进，从而可以提前规避部分问题，降低问题发生概率。另外，检测结果的上报也有助于软件应用的研发同学进一步研究分析，提升研发效率。
142.对应于前述检测消息通知故障的方法，本公开实施例提供了一种检测消息通知故障的装置，图15为本公开实施例提供的一种检测消息通知故障的装置的结构示意图，该装置可由软件和/或硬件实现，一般可集成在电子设备中，该方法具体可应用于客户端，如图15所示，包括：
143.第一检测模块1502，用于响应于接收到故障诊断指令，基于预设的多个故障检测项中的第一类故障检测项进行检测，得到每个第一类故障检测项对应的检测结果；其中，故障诊断指令用于指示对离线通知推送功能的故障原因进行诊断。
144.第二检测模块1504，用于在第一类故障检测项中的目标故障检测项对应的检测结果指示无故障的情况下，基于多个故障检测项中的第二类故障检测项进行检测，得到每个第二类故障检测项对应的第二检测结果；
145.结果展示模块1506，用于将第一检测结果和第二检测结果按照指定方式进行展示，并展示故障原因和/或故障解决方案。
146.本公开实施例提供的上述技术方案，可以基于预设的多个故障检测项进行自动化故障检测，有效缩减人工成本和耗时成本；而且还会将故障检测项进行分类，第二类故障检测项检测与否依赖于第一类故障检测项的检测结果，也进一步提高了检测效率；另外，上述方式还能够基于检测结果进行展示，并提供故障原因和/或故障解决方案，以便于用户清楚获知故障原因以及故障处理方式。综上，上述方式可以实现高效的离线通知推送功能的故障自动检测，有效降低故障处理成本，并为用户提供良好的故障处理体验。
147.在一些实施方式中，所述第一类故障检测项包括网络连接检测项和本地设置检测项；其中，所述目标故障检查项包括网络连接检测项。
148.在一些实施方式中，所述第二类故障检测项包括服务端设置检测项以及终端设备的通道配置检测项；其中，所述终端设备为安装所述客户端的设备。
149.在一些实施方式中，第一检测模块1502具体用于：基于所述网络连接检测项，检测所述终端设备是否未接入网络，在检测到未接入网络的情况下，确定所述网络连接检测项的第一检测结果为存在网络连接故障；
150.基于所述本地设置检测项，检测所述终端设备是否关闭所述客户端的设备通知权限，在检测到所述设备通知权限均处于关闭状态的情况下，确定所述本地设置检测项的第一检测结果为存在设备权限设置故障。
151.在一些实施方式中，第二检测模块1504具体用于：基于所述服务端设置检测项，通过服务端检测是否存在所述客户端禁止所述服务端下发所有通知的设置，在检测到存在所
述客户端禁止所述服务端下发所有通知的设置的情况下，确定所述服务端设置检测项的第二检测结果为存在通知下发设置故障；基于所述终端设备的通道配置检测项，通过服务端检测在所述终端设备上配置的为所述客户端下发通知的通道是否与所述客户端对应的目标通道匹配，根据匹配结果得到所述终端设备的通道配置检测项对应的第二检测结果。
152.在一些实施方式中，第二检测模块1504具体用于：向通知服务器发送通知设置检测请求；所述通知设置检测请求用于指示所述通知服务器获取所述终端设备的应用内通知权限设置信息和所述终端设备的个人状态设置信息；在通过所述通知服务器检测到所述应用内通知权限均处于关闭状态或者所述个人状态设置信息包括免打扰设置的情况下，确定存在所述客户端禁止所述服务端下发所有通知的设置。
153.在一些实施方式中，第二检测模块1504具体用于：向通知服务器发送通道设置检测请求，以使所述通知服务器执行如下步骤：通过所述终端设备获取在所述终端设备上配置的为所述客户端下发通知的通道；获取指定信息，根据所述指定信息得到与所述客户端对应的目标通道；所述指定信息包括所述客户端的标识信息和/或所述终端设备的设备信息；如果在所述终端设备上配置的为所述客户端下发通知的通道属于所述目标通道，确定在所述终端设备上配置的为所述客户端下发通知的通道与所述客户端对应的目标通道匹配。
154.在一些实施方式中，第二检测模块1504具体用于：根据所述客户端的标识信息确定所述客户端的品牌类型属于第一类型的情况下，根据所述终端设备的设备信息确定所述客户端对应的目标通道；根据所述客户端的标识信息确定所述客户端的品牌类型属于第二类型的情况下，确定所述客户端对应的目标通道为指定通道；根据所述客户端的标识信息确定所述客户端的品牌类型属于第三类型的情况下，确定所述客户端对应的目标通道为任意通道。
155.在一些实施方式中，第二检测模块1504具体用于：在检测到不匹配的情况下，确定所述终端设备的通道配置检测项的检测结果为存在通道配置故障；在检测到匹配的情况下，检测所述客户端对应的通道令牌是否无效，在检测到无效的情况下，确定所述终端设备的通道配置检测项的检测结果为存在通道配置故障。
156.在一些实施方式中，所述客户端对应的目标通道与所述客户端的品牌类型和/或所述终端设备的品牌类型相关。
157.在一些实施方式中，所述装置还包括离线测试模块，用于：在所述第一检查结果和所述第二检查结果均无故障的情况下，通过服务端发送离线测试通知；在离线测试通知发送失败的情况下，为用户展示问题解决渠道的渠道信息。
158.在一些实施方式中，所述装置还包括在线测试模块，用于：通过所述服务端发送在线测试通知；在所述在线测试通知发送成功以及所述离线测试通知发送成功的情况下，为用户展示当前的通知检测结果均正常。
159.在一些实施方式中，结果展示模块1506具体用于：将所述第一检测结果和所述第二检测结果中存在故障的检测结果展示在界面上；或者，将所述第一检测结果和所述第二检测结果均展示在界面上，且存在故障的检测结果与不存在故障的检测结果的标识方式不同。
160.在一些实施方式中，所述装置还包括建议模块，用于：在所述第一检测结果或所述
第二检测结果指示存在待优化的设置信息的情况下，展示优化建议；其中，所述优化建议是基于所述待优化的设置信息生成的。
161.在一些实施方式中，所述故障解决方案与所述优化建议的标识方式不同，和/或，所述故障解决方案的展示优先级高于所述优化建议的展示优先级。
162.在一些实施方式中，所述故障解决方案在界面中的展示位置优于所述优化建议在界面中的展示位置；和/或，展示所述故障解决方案时不展示所述优化建议，且所述优化建议是在不存在所述故障解决方案的情况下进行展示。
163.在一些实施方式中，所述装置还包括上报模块，用于基于所述第一检测结果或所述第二检测结果执行上报操作。
164.本公开实施例所提供的检测消息通知故障的装置可执行本公开任意实施例所提供的检测消息通知故障的方法，具备执行方法相应的功能模块和有益效果。
165.所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，上述描述的装置实施例的具体工作过程，可以参考方法实施例中的对应过程，在此不再赘述。
166.本公开实施例提供了一种电子设备，电子设备包括：处理器；用于存储处理器可执行指令的存储器；处理器，用于从存储器中读取可执行指令，并执行指令以实现上述任一检测消息通知故障的方法。
167.图16为本公开实施例提供的一种电子设备的结构示意图。如图16所示，电子设备1600包括一个或多个处理器1601和存储器1602。
168.处理器1601可以是中央处理单元(cpu)或者具有数据处理能力和/或指令执行能力的其他形式的处理单元，并且可以控制电子设备1600中的其他组件以执行期望的功能。
169.存储器1602可以包括一个或多个计算机程序产品，所述计算机程序产品可以包括各种形式的计算机可读存储介质，例如易失性存储器和/或非易失性存储器。所述易失性存储器例如可以包括随机存取存储器(ram)和/或高速缓冲存储器(cache)等。所述非易失性存储器例如可以包括只读存储器(rom)、硬盘、闪存等。在所述计算机可读存储介质上可以存储一个或多个计算机程序指令，处理器1601可以运行所述程序指令，以实现上文所述的本公开的实施例的检测消息通知故障的方法以及/或者其他期望的功能。在所述计算机可读存储介质中还可以存储诸如输入信号、信号分量、噪声分量等各种内容。
170.在一个示例中，电子设备1600还可以包括：输入装置1603和输出装置1604，这些组件通过总线系统和/或其他形式的连接机构(未示出)互连。
171.此外，该输入装置1603还可以包括例如键盘、鼠标等等。
172.该输出装置1604可以向外部输出各种信息，包括确定出的距离信息、方向信息等。该输出装置1604可以包括例如显示器、扬声器、打印机、以及通信网络及其所连接的远程输出设备等等。
173.当然，为了简化，图16中仅示出了该电子设备1600中与本公开有关的组件中的一些，省略了诸如总线、输入/输出接口等等的组件。除此之外，根据具体应用情况，电子设备1600还可以包括任何其他适当的组件。
174.除了上述方法和设备以外，本公开的实施例还可以是计算机程序产品，其包括计算机程序指令，所述计算机程序指令在被处理器运行时使得所述处理器执行本公开实施例所提供的检测消息通知故障的方法。
175.所述计算机程序产品可以以一种或多种程序设计语言的任意组合来编写用于执行本公开实施例操作的程序代码，所述程序设计语言包括面向对象的程序设计语言，诸如java、c 等，还包括常规的过程式程序设计语言，诸如“c”语言或类似的程序设计语言。程序代码可以完全地在用户计算设备上执行、部分地在用户设备上执行、作为一个独立的软件包执行、部分在用户计算设备上部分在远程计算设备上执行、或者完全在远程计算设备或服务器上执行。
176.此外，本公开的实施例还可以是计算机可读存储介质，其上存储有计算机程序指令，所述计算机程序指令在被处理器运行时使得所述处理器执行本公开实施例所提供的检测消息通知故障的方法。
177.所述计算机可读存储介质可以采用一个或多个可读介质的任意组合。可读介质可以是可读信号介质或者可读存储介质。可读存储介质例如可以包括但不限于电、磁、光、电磁、红外线、或半导体的系统、装置或器件，或者任意以上的组合。可读存储介质的更具体的例子(非穷举的列表)包括：具有一个或多个导线的电连接、便携式盘、硬盘、随机存取存储器(ram)、只读存储器(rom)、可擦式可编程只读存储器(eprom或闪存)、光纤、便携式紧凑盘只读存储器(cd-rom)、光存储器件、磁存储器件、或者上述的任意合适的组合。
178.本公开实施例还提供了一种计算机程序产品，包括计算机程序/指令，该计算机程序/指令被处理器执行时实现本公开实施例中的检测消息通知故障的方法。
179.需要说明的是，在本文中，诸如“第一”和“第二”等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个
……”
限定的要素，并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。
180.以上所述仅是本公开的具体实施方式，使本领域技术人员能够理解或实现本公开。对这些实施例的多种修改对本领域的技术人员来说将是显而易见的，本文中所定义的一般原理可以在不脱离本公开的精神或范围的情况下，在其它实施例中实现。因此，本公开将不会被限制于本文所述的这些实施例，而是要符合与本文所公开的原理和新颖特点相一致的最宽的范围。