远程诊断方法、装置、存储介质及电子设备与流程

本申请涉及计算机技术领域，尤其涉及一种远程诊断方法、装置、存储介质及电子设备。

背景技术：

随着通信技术的发展，手机、电脑、智能穿戴设备等电子设备快速普及，极大的便利了用户的日常生活。在电子设备使用一段时间后，常会由于机械损坏、人为因素等原因出现一些故障问题，如电子设备出现硬件方面的故障问题，如电子主设备出现软件方面的故障问题，又如电子设备出现操作上的故障问题。

在电子设备出现故障的情况下，就涉及到电子设备的故障诊断。

技术实现要素：

本申请实施例提供了一种远程诊断方法、装置、存储介质及电子设备，可以降低远程诊断时的资源开销，提升远程诊断的容灾性能。本申请实施例的技术方案如下：

第一方面，本申请实施例提供了一种远程诊断方法，应用于客户端，所述方法包括：

接收所输入的诊断操作，建立与服务平台的短连接；

获取所述客户端的埋点诊断信息，基于所述短连接向所述服务平台发送所述埋点诊断信息；

接收所述服务平台基于所述埋点诊断信息返回的远程诊断结果。

第二方面，本申请实施例提供了一种远程诊断方法，应用于服务平台，所述方法包括：

用于在客户端接收到所输入的诊断操作时，建立与所述客户端的短连接；

用于基于所述短连接，获取所述客户端的埋点诊断信息；

基于所述埋点诊断信息向所述客户端返回远程诊断结果。

第三方面，本申请实施例提供了一种远程诊断方法，应用于客服端，所述方法包括：

接收客户端的呼叫操作，基于所述呼叫操作生成诊断指令；

将所述诊断指令发送至服务平台；所述诊断指令用于指示所述服务平台建立与所述客户端的短连接，并基于所述短连接向所述客户端返回埋点诊断信息对应的远程诊断结果，所述埋点诊断信息为所述客户端的所述埋点诊断信息。

第四方面，本申请实施例提供了一种远程诊断装置，所述装置包括：

连接建立模块，用于接收所输入的诊断操作，建立与服务平台的短连接；

信息发送模块，用于获取所述客户端的埋点诊断信息，基于所述短连接向所述服务平台发送所述埋点诊断信息；

结果接收模块，用于接收所述服务平台基于所述埋点诊断信息返回的远程诊断结果。

第五方面，本申请实施例提供了一种远程诊断装置，所述装置包括：

连接建立模块，用于在客户端接收到所输入的诊断操作时，建立与所述客户端的短连接；

信息获取模块，用于基于所述短连接，获取所述客户端的埋点诊断信息；

结果返回模块，用于基于所述埋点诊断信息向所述客户端返回远程诊断结果。

第六方面，本申请实施例提供了一种远程诊断装置，所述装置包括：

指令生成模块，用于接收客户端的呼叫操作，基于所述呼叫操作生成诊断指令；

指令发送模块，用于将所述诊断指令发送至服务平台；所述诊断指令用于指示所述服务平台建立与所述客户端的短连接，并基于所述短连接向所述客户端返回埋点诊断信息对应的远程诊断结果，所述埋点诊断信息为所述客户端的所述埋点诊断信息。

第七方面，本申请实施例提供一种计算机存储介质，所述计算机存储介质存储有多条指令，所述指令适于由处理器加载并执行上述任意的方法步骤。

第八方面，本申请实施例提供一种电子设备，可包括：处理器和存储器；其中，所述存储器存储有计算机程序，所述计算机程序适于由所述处理器加载并执行上述任意的方法步骤。

本申请一些实施例提供的技术方案带来的有益效果至少包括：

在本申请一个或多个实施例中，客户端可以接收用户所输入的诊断操作，从而建立与服务平台的短连接，然后获取所述客户端的埋点诊断信息，基于短连接向所述服务平台发送所述埋点诊断信息；客户端只需接收所述服务平台基于所述埋点诊断信息返回的远程诊断结果即可完成整个远程诊断过程。在整个远程诊断过程中，只需要客户端建立与服务平台的短连接，基于诊断开销较小的短连接，通过上传用于远程诊断的埋点诊断信息就可以实现服务平台对客户端的远程诊断，无需客户端与服务平台建立双向长连接，降低远程诊断时的资源开销；以及，服务平台在同时远程诊断多个客户端时，采用上述方式，可以兼容远程诊断业务高并发量的诊断需求，进而提升了远程诊断的容灾性能。

附图说明

为了更清楚地说明本申请实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图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是图25中安卓操作系统的架构图；

图28是图25中ios操作系统的架构图。

具体实施方式

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

在本申请的描述中，需要理解的是，术语“第一”、“第二”等仅用于描述目的，而不能理解为指示或暗示相对重要性。在本申请的描述中，需要说明的是，除非另有明确的规定和限定，“包括”和“具有”以及它们任何变形，意图在于覆盖不排他的包含。例如包含了一系列步骤或单元的过程、方法、系统、产品或设备没有限定于已列出的步骤或单元，而是可选地还包括没有列出的步骤或单元，或可选地还包括对于这些过程、方法、产品或设备固有的其他步骤或单元。对于本领域的普通技术人员而言，可以具体情况理解上述术语在本申请中的具体含义。此外，在本申请的描述中，除非另有说明，“多个”是指两个或两个以上。“和/或”，描述关联对象的关联关系，表示可以存在三种关系，例如，a和/或b，可以表示：单独存在a，同时存在a和b，单独存在b这三种情况。字符“/”一般表示前后关联对象是一种“或”的关系。

在相关技术中，故障诊断可以是采用远程诊断的方式进行时，通常进行诊断的设备会与电子设备(如用户使用的客户端)建立双向长连接，如建立后端诊断专家与客户端的音视频的实时连接，从而方便实时对客户端当前的故障进行诊断，然而采用这种方式需要实时且长期占用服务平台的一路通信连接，且这种阻塞式的双向长连接通常诊断开销也较大，这无疑会消耗大量的通信资源。

下面结合具体的实施例对本申请进行详细说明。

在一个实施例中，如图1所示，特提出了一种远程诊断方法，应用于客户端，该方法可依赖于计算机程序实现，可运行于基于冯诺依曼体系的远程诊断装置上。该计算机程序可集成在应用中，也可作为独立的工具类应用运行。

具体的，该远程诊断方法包括：

步骤s101：接收所输入的诊断操作，建立与服务平台的短连接。

在实际应用中，随着客户端的快速普及，在客户端使用一段时间后，常会由于机械损坏、人为因素等原因，随之出现客户端的售后诊断问题，在本申请实施例中，为了方便的解决上述问题，可以通过所述远程诊断方法实现快速便捷的对客户端出现的故障问题、使用问题等进行诊断。

所述诊断操作可以理解为用户在使用客户端的过程中，客户端出现相应故障，用户在客户端上所输入的用于对当前客户端进行远程诊断的操作。所述诊断操作为指挥客户端工作的指示或相应的命令，可以理解为用户所输入的诊断操作在客户端进行响应时，会执行所述诊断操作对应的某种运算或功能实现的某种控制的代码，可以理解的是，客户端在检测到用户所输入的诊断操作之后，可以响应于诊断操作对应的机器可执行代码，从而执行所述建立与服务平台的短连接的步骤。

具体的，客户端具有对用户在当前显示界面上的输入操作(如诊断操作)进行检测的功能，当用户在使用客户端(如手机)的过程中，由于人为损坏、机械磨损等原因造成客户端故障(如硬件故障、软件故障)时，用户无需携带客户端达到指定售后网点进行故障诊断，可以通过操作客户单输入相应的诊断操作进行远程诊断；示意性的，对于客户端而言：

客户端可以实时或相隔一定周期对用户在当前人机交界面上的输入操作进行监测，当客户端检测到用户针对远程诊断(功能或服务)输入诊断操作时，客户端识别到所述诊断操作，执行“建立与服务平台的短连接”运算或功能实现的某种控制的代码，从而进行“建立与服务平台的短连接”。

可选的，所述用户针对远程诊断(功能或服务)输入诊断操作可以是通过外部设备完成的，例如，用户可以通过连接客户端的鼠标选中客户端的显示界面上相应的远程诊断选项；可以是用户通过连接客户端的键盘或者触摸板输入相应的“远程诊断(功能或服务)”对应的指令进行的，如输入自定义或默认的用于远程诊断(功能或服务)开启的字符串；可以是用户通过语音输入针对远程诊断(功能或服务)的开启指令(例如语音输入“开启远程诊断”等)；可以是用户通过摄像头采集手势控制指令完成特定的远程诊断(功能或服务)的开启操作，还可以是通过按压客户端的物理按键触发的对远程诊断(功能或服务)的开启操作等。还可以是用户通过客户端呼叫相应的客服端，以通过该客户端请求服务平台进行远程诊断，从而首先建立客户端与服务平台的短连接。

在相关技术中，在进行远程诊断时，通常进行诊断的设备会与客户端建立双向长连接，如建立后端诊断专家与客户端的音视频的实时连接，从而方便实时对客户端当前的故障进行诊断，采用这种方式需要实时长期占用服务平台的一路通信连接(通信长连接)，消耗大量的通信资源，阻塞式进行诊断通常开销大；在本申请中，客户端接收到用户所输入的诊断操作之后，对所述诊断操作进行响应，从而尝试建立与服务平台的短连接。

进一步的，用户的客户端与服务平台之间的通信连接通常为采用预设通信架构建立的通信连接服务，所述通信架构是指进行数据通信的一种通信结构，通信架构定义了数据网络通信系统的各个方面，包含通信的接口类型、使用的网络协议、实现的数据框架、通信布线的类型等。常用的通信架构可以是tcp/ip架构，netty架构、c/s架构、soa架构等。如，一种所述通信架构可以是为采用基于java开源的netty框架，并配合websocket技术从而实现通信网络中服务平台与用户客户端之间建立一种通信连接，并基于通信连接实现两端之间的通信数据的交互。其中，在不同的实施场景下通信连接的类型不一样，如一些实施场景下可以建立通信长连接，一些实施场景下可以建立通信短连接；优选的，在本申请中，客户端在远程诊断场景下与服务平台之间的通信连接为短连接。

以下将对基于长连接的通信链路以及基于短连接的通信连接进行详细释义，如下：

其中，所述所建立的通信连接可以为http长连接的通信链路或http短连接的通信链路。

长连接，指在一个连接上可以连续发送多个数据包，在连接保持期间，如果没有数据包发送，需要双方发链路检测包。

长连接的操作步骤是：建立连接——数据传输...(保持连接)...数据传输——关闭连接。

短连接是指通讯双方有数据交互时，就建立一个连接，数据发送完成后，则断开此连接，即每次连接只完成一项业务的发送。

短连接的操作步骤是：建立连接——数据传输——关闭连接...建立连接——数据传输——关闭连接。

长连接多用于操作频繁，点对点的通讯。每个通信连接(如tcp连接)都需要三步握手，这需要时间，如果每个操作都是短连接，再操作的话那么处理速度会降低很多，所以每个操作完后都不断开，下次处理时直接发送数据包就ok了，不用建立tcp连接。例如：数据库的连接用长连接，如果用短连接频繁的通信会造成socket错误，而且频繁的socket创建也是对资源的浪费。

而像web网站的http服务一般都用短链接，因为长连接对于服务端来说会耗费一定的资源，而像web网站这么频繁的成千上万甚至上亿客户端的连接用短连接会更省一些资源，如果用长连接，而且同时有成千上万的用户，如果每个用户都占用一个连接的话，那可想而知吧。所以并发量大，但每个用户无需频繁操作情况下需用短链接好。

长连接可以省去较多的tcp建立和关闭的操作，减少浪费，节约时间。在实际应用中，当通信链路传输的通信数据为对通信传输质量要求高的实时在线场景时，可以采用基于长连接的通信链路，此时，长连接对于服务平台来说管理较为简单，存在的连接都是有用的连接，不需要额外的控制手段。

但如果客户请求频繁，如当客户端数量较多时，且用于提供诊断服务的服务平台需要同时为大量的客户端提供远程诊断服务时，基于实际通信诊断数据传输的环境，为了降低连接开销、资源消耗，本申请中，客户端可以响应诊断操作，从而采用合适的短连接方式来建立服务平台与用户的客户端之间的通信连接。

步骤s102：获取所述客户端的埋点诊断信息，基于所述短连接向所述服务平台发送所述埋点诊断信息。

在本申请中，埋点诊断是一种将埋点技术应用在远程诊断场景中的用于获取数据信息方式，埋点诊断信息的获取过程在本申请中也可以理解为相应诊断文件、相应诊断数据、相应日志等数据的采集过程。

所述埋点诊断信息来源于客户端本端，采用预先或实时埋点的方式，获取用于远程诊断的故障诊断信息或故障诊断数据，如客户端硬件故障时，可以是是用于远程硬件诊断的故障硬件信息或数据，如客户端软件故障时，可以是用于远程软件诊断的故障硬软件信息或数据。通俗点讲，就是在相应诊断服务、诊断app、诊断web等产品中植入一段代码，监控用户行为事件(例如某个页面的曝光)、系统行为事件、硬件行为事件等。用户一旦主动触发或被动触发了该事件，就会上传或收集埋点代码中定义的、需要上传的有关该事件的埋点诊断信息。常见的埋点诊断信息包括：(软硬件)故障id信息、软硬件接口信息、用户会话id信息，用户id信息，当前页面编码信息，当前事件编码信息，触发时间信息，用户设备id信息，ip信息等一种或多种的拟合。

在本申请中，通过将埋点的方法应用于远程诊断场景中，通常可以使客户端与服务平之间的连接无需采用通信长连接，客户端可以只需预先或实时获取本端的埋点诊断信息，然后基于所述短连接向所述服务平台发送所述埋点诊断信息即可，极大的降低远程诊断的资源开销，避免了长时间的诊断占用现象。

进一步的，客户端可以结合实际应用场景采用相应的埋点方式进行采集埋点诊断信息前的埋点，其中所述埋点的方式包括但不限于手动埋点、半自动埋点以及全自动埋点的方式。

所述手动埋点的方式，简而言之，可参见图2，图2是一种埋点的场景示意图：(远程诊断业务)产品经理(pm)在提埋点需求，需要在客户端上单独针对某一诊断像对应的诊断事件进行埋点，如接口诊断点、软件运行诊断点、硬件诊断点、app某个页面的某个事件诊断点等等，在这个过程中，产品会对该监测页面、监测事件按照一套规则进行编码命名(若事件数不多，页面编码命名这一层也可以省略)，以便后续通过该编码对上传或获取上来的信息进行辨认；同时，产品也会将这一埋点需要上传的参数告知前端开发。(远程诊断业务)开发人员明确需求后就会在客户端出厂前或客户端操作系统初始化以及更新时进行埋点。

所述半自动埋点的方式，不需要预先手动编写埋点信息采集或上传规则以及预先手动进行埋点，而是对相应人工针对监测事件的规则进行标准化，集成为sdk，pm提埋点需求时候，直接将申请的埋点进行注册，调用符合埋点需求的埋点sdk，并进行下发，那么客户端上的诊断服务、诊断app、诊断web等诊断产品中就会集成该段埋点代码，而不再需要沟通前端开发进行埋点。

所述全自动埋点的方式无需基于需求方需求进行部分埋点或部分埋点下发，全自动埋点则是无需基于需求方需求，将所有的可监测诊断点都进行埋点。通常这种埋点也是通过sdk实现的，这种sdk无需调用，已经直接嵌入在诊断服务、诊断app、诊断web等诊断产品中。因为全自动埋点都是自动生成的，用于对每一个埋点进行标识的埋点编码也是按照既定规则进行生成。通常这种标识是不可读的，需要pm和开发沟通，对埋点编码进行和业务含义上的映射。

进一步的，埋点诊断数据基本可以从各诊断点收集到的原材料状态变为可以为业务服务的有用数据(也即上传前获取到加工完成的埋点诊断数据)的过程中，埋点诊断点的数据都是一条一条，是用户或客户端运行过程中触发埋点对应事件时采集到的。这些数据可能包括：(软硬件)故障id信息、软硬件接口信息、用户会话id信息，用户id信息，当前页面编码信息，当前事件编码信息，触发时间信息，用户设备id信息，ip信息等一种或多种的拟合，这些零散的信息需要通过加工处理进行聚合，变成更加通用常用的数据，便于后续调用，加工完成的数据，也即埋点诊断数据。

步骤s103：接收所述服务平台基于所述埋点诊断信息返回的远程诊断结果。

具体的，客户端获取到所述客户端本端的埋点诊断信息之后，可以基于与所述服务平台之前的短连接，向所述服务平台发送所述埋点诊断信息；服务平台接收到埋点诊断信息，然后基于埋点诊断信息进行分析诊断，从而生成远程诊断结果。最后，服务平台基于与客户端之间的短连接将远程诊断结果返回至客户端，此时客户端即可接收到该远程诊断结果。

在本申请实施例中，客户端可以接收用户所输入的诊断操作，从而建立与服务平台的短连接，然后获取所述客户端的埋点诊断信息，基于短连接向所述服务平台发送所述埋点诊断信息；客户端只需接收所述服务平台基于所述埋点诊断信息返回的远程诊断结果即可完成这个远程诊断过程。在整个远程诊断过程中，只需要客户端建立与服务平台的短连接，基于诊断开销较小的短连接，通过上传用于远程诊断的埋点诊断信息就可以实现服务平台对客户端的远程诊断，无需客户端与服务平台建立双向长连接，降低远程诊断时的资源开销；以及，服务平台在同时远程诊断多个客户端时，采用上述方式，可以兼容远程诊断业务高并发量的诊断需求，进而提升了远程诊断的容灾性能。

请参见图3，图3是本申请提出的一种远程诊断方法的另一种实施例的流程示意图。具体的：

步骤s201：接收所输入的诊断操作，向所述服务平台获取诊断验证码。

所述诊断验证码用于服务平台于客户端在远程诊断时进行鉴权认证。在本申请中，诊断验证码在服务平台生成，并由服务平台发送至客户端，客户端接收到该诊断验证码之后可以基于诊断验证码建立与服务平台之间的短连接，如客户端可以基于接收到的诊断验证码成包含诊断验证码的诊断验证请求，将诊断验证请求发送至服务平台，服务平台在对诊断验证码验证通过之后，即可建立与客户端之间的短连接。

在一种可行的实施方式中，客户端可直接向服务平台获取用于远程诊断的诊断验证码，如图4所示，图4是一种诊断验证码获取的场景示意图，在图4中，客户端可在本端调起相应的远程诊断服务，基于远程诊断服务访问服务平台的服务接口，从而向服务平台发起获取诊断验证码的获取请求；客户端可在本端打开远程诊断应用，基于远程诊断应用访问服务平台，从而向服务平台发起获取诊断验证码；又如，客户端可直接通过相应的诊断网页(web)远程访问服务平台，从而获取远程诊断验证码。

在一种可行的实施方式中，所述远程诊断方法可以引入客服端，客服端用于对客户端进行维护以及提供相应的客户服务，如为客户端上的客户提供远程诊断咨询服务，客服端作为远程诊断的前置部分，可以预先对客户端上的可能存在的故障问题进行相应诊断项目或诊断服务(如某硬件诊断服务、某软件诊断服务)的判决，然后在指示或请求服务平台生成诊断验证码，如基于预先判决的目标诊断项目或诊断服务生成诊断验证码，从而便于后期服务平台快速定位故障问题，便捷解决故障问题，提高远程诊断的效率。

具体的，客户端上的用户在使用客户端过程中，若出现故障问题，如硬件问题、软件问题，用户可以基于客户端向远程诊断的客服端进行呼叫，如发起语音通话、视频通话等。

具体的，客户端可以接收用户向客服端输入的呼叫操作，通常所述呼叫操作可以用于所述客服端指示所述服务平台生成诊断验证码，如，客服端接收到客户端的呼叫，然后可以在相应呼叫场景下生成诊断指令并发送至服务平台，从而服务平台可以响应于该诊断指令，生成诊断验证码然后将诊断验证码发送至客户端，也即客户端可以在呼叫操作之后，接收到服务平台发送的诊断验证码；

对于客户端而言，客户端可以实时或相隔一定周期对用户在当前人机交界面上的输入操作进行监测，如图5所示，图5是一种涉及客户端呼叫场景的界面示意图，当用户在使用客户端(如手机)的过程中，由于人为损坏、机械磨损等原因造成客户端故障(如硬件故障、软件故障)时，用户可以通过语音呼叫的方式向客服端进行呼叫，用户通过手指触控方式选中客户端人机交互界面中的拨号图标时，具体通过触控客户端触控屏的屏幕玻璃层，客户端所包含的触控屏通过传感器薄膜中的位置传感器获取其触控拨号图标的位置参数，然后对所述位置参数进行处理，识别到用户输入的打开“拨号”应用的指令，此时，客户端即检测到用户针对当前显示界面上开启拨号应用的输入指令。通过读取并执行“开启拨号应用”的控制逻辑对应的机器可执行指令，执行在当前客户端显示界面上显示拨号界面的操作。可参考图5，用户可以在如图5所示的客户端拨号界面中的拨号键盘依次输入待拨出的拨号号码(客服端对应的电话号码)。如，用户具体通过手指触控的方式依次触控拨号键盘上的数字4、数字0.....的位置参数，然后对所述位置参数进行处理，即可识别并获取到用户在客户端输入的“客服端对应的电话号码”，在用户输入“客服端对应的电话号码”的过程中，客户端可以将各号码数字实时显示在如图5所示的拨号界面对应的号码显示框中。当用户输入完客服端的电话号码，通过手指触控的方式点击图5中所示的“拨出”图标时，客户端此时即检测并接收到用户针对客服端的呼叫操作。

进一步的，当客户端检测到用户针对客服端输入呼叫操作时，客户端识别到所述呼叫操作，执行“向客服端呼叫”运算或功能实现的某种控制的代码，从而建立与客服端的呼叫连接，可以理解的是，客户端与客服端建立呼叫连接之后，可以理解的是，客户端上的用户可以基于呼叫连接向客服端输出或说明当前遇到的故障问题信息，以基于故障问题信息通过客服端请求服务平台的，客服端此时可以基于故障问题信息预先选择对客户端上的可能存在的故障问题进行相应诊断项目或诊断服务(如某硬件诊断服务、某软件诊断服务)的判决或选择。以辅助服务平台生成相应诊断项目或诊断服务的诊断验证码，从而将该诊断验证码发送至客户端。

具体的，客户端可以接收用户向客服端输入的呼叫操作，通常所述呼叫操作可以用于所述客服端指示所述服务平台生成诊断验证码，从而服务平台可以将诊断验证码发送至客户端，也即客户端可以在呼叫操作之后，接收到服务平台发送的诊断验证码；

可选的，在另一种可行的实施方式中，客户端接收用户向所述客服端输入的呼叫操作，客户端以建立与客服端之间的呼叫连接，然后所述客服端可以指示所述服务平台生成诊断验证码；服务平台可以将所述诊断验证码发送至客服端，由客服端转发至客户端。具体实施中，对于客户端而言，所述诊断验证码由所述服务平台发送至所述客服端，客服端向客户端输出该诊断验证码，如以语音播报的方式向客户端上的用户进行语音告知。

进一步的，客户端在接收到服务平台生成的诊断验证码之后，如客户端直接接收到服务平台以消息通知的形式发送的诊断验证码，又如客户端可以接收到由服务平台生成客服端输出的诊断验证码；进而可以基于所述诊断验证码建立与服务平台的短连接。具体释义可参见下述步骤。

步骤s202：生成包含所述诊断验证码的通信诊断请求，将所述通信诊断请求发送至所述服务平台，所述通信诊断请求用于指示所述服务平台对所述诊断验证码进行连接验证。

其中，所述诊断验证码可以是服务平台基于随机数生成规则随机生成的验证码，也可以是相应的加密算法的生成规则生成的加密验证码。另外，所述诊断验证码的类型可以是多种形式，包括但不限于：语音验证码形式、字符验证码形式、图像验证码形式等等。

所述请求是指挥服务平台工作的指示和请求，可以理解为请求服务平台执行某种运算或功能实现的某种控制的代码。所述通信诊断请求在本申请实施例中可以理解为指挥服务平台执行对客户端远程诊断功能的代码，服务平台通过执行所述代码，可以首先基于通信诊断请求中的诊断验证码进行验证鉴权，以确定是否合规、以及是否为有效请求，防止对服务平台恶意请求浪费资源。在本申请实施例中，服务平台在对通信诊断请求中的诊断验证码验证通过后，才可以成功建立与客户端的短连接。如，服务平台在对通信诊断请求中的诊断验证码验证通过后，向客户端反馈验证通过消息，在客户端通过接收到该验证通过消息时，服务平台于客户端之间的通信短连接成功建立。

在一种具体的实施场景中，客户端上可以搭载有用于与所述服务平台交互的客户端应用，也即交互应用，交互应用中可以集成远程诊断功能，当触发交互应用中的远程诊断功能时，可以在所述交互应用中输入诊断验证码并生成相应的通信诊断请求，以在服务平台基于通信诊断请求中的诊断验证码验证通过之后，可以成功建立与服务平台之间的短连接。

对于客户端而言，客户端会启动交互应用，客户端在检测到在所述交互应用中输入的所述诊断验证码时，可以生成包含所述诊断验证码的通信诊断请求，所述交互应用为与所述服务平台交互的客户端应用。

如，一种方式可以是：客户端获取到服务平台发送的包含诊断验证码的通知信息、通知语音、通知图片等通知媒介，此时，用户可以通过客户端查阅到通知媒介中的诊断验证码，然后在客户端本端手动开启交互应用，如图6所示，图6是一种交互应用的界面示意图，在图6中，用户可以通过手指触控的方式，触控客户端当前显示界面上的“远程诊断应用”的图标，从而开启交互应用-“远程诊断应用”，客户端响应于用户输入的远程诊断应用”的开启操作，显示远程诊断界面，然后用户可将诊断验证码输入至交互应用的相应“远程诊断功能”对应的验证码输入框中，此时，客户端即确定检测到在所述交互应用输入的诊断验证码，继而基于诊断验证码生成通信诊断请求。

如，一种方式可以是：客户端获取到服务平台发送的包含诊断验证码的通知信息、通知语音、通知图片等通知媒介，此时，客户端可以智能对通知媒介进行语义识别，从而可以识别到当前客户端上的用户需要进行远程诊断，此时，客户端可以无需用户操作，智能开启远程诊断功能对应的交互应用，另外，可以智能将通知消息中的诊断验证码自动输入至交互应用的相应“开启远程诊断功能”对应的验证码输入框中，此时，客户端即确定检测到在所述交互应用输入的诊断验证码，继而基于诊断验证码生成通信诊断请求。

步骤s203：接收所述服务平台发送的验证通过信息，建立与所述服务平台的短连接。

服务平台接收到所述通信诊断请求，服务平台对所述通信诊断请求进行响应，然后执行对客户端远程诊断功能的代码，服务平台通过执行所述代码，可以首先基于通信诊断请求中的诊断验证码进行验证鉴权，以确定是否合规、以及是否为有效请求，防止对服务平台恶意请求浪费资源。在本申请实施例中，服务平台在对通信诊断请求中的诊断验证码验证通过后，才可以成功建立与客户端的短连接。进一步的，服务平台在在对通信诊断请求中的诊断验证码验证通过后，向客户端反馈验证通过消息，在客户端通过接收到该验证通过消息时，服务平台与客户端之间的通信短连接成功建立。

其中，所述对诊断验证码的验证过程可以是，服务平台查询为客户端建立短连接随之生成的诊断验证码(以下称作为第一诊断验证码)，服务平台获取接收到的通信诊断请求的诊断验证码(以下称作为第二诊断验证码)；然后判断所述第一诊断验证码与所述第二诊断验证码是否匹配，如第一诊断验证码与第二诊断验证码是否一致，若第一诊断验证码与所述第二诊断验证码相匹配，服务平台生成验证通过信息，将所述验证通过信息基于短连接发送至客户端。此时，客户端在接收到所述服务平台发送的验证通过信息之后，即成功建立与所述服务平台的短连接。

步骤s204：接收所述服务平台发送的验证失败信息，重新建立与所述服务平台的所述短连接。

根据一些实施例中，服务平台查询为客户端建立短连接随之生成的诊断验证码(以下称作为第一诊断验证码)，服务平台获取接收到的通信诊断请求的诊断验证码(以下称作为第二诊断验证码)；然后判断所述第一诊断验证码与所述第二诊断验证码是否匹配，如第一诊断验证码与第二诊断验证码是否一致，若第一诊断验证码与所述第二诊断验证码不匹配，服务平台生成验证失败信息，将所述验证失败信息基于短连接发送至客户端。此时，客户端在接收到所述服务平台发送的验证失败信息之后，客户端可以重新尝试建立与所述服务平台的所述短连接，如客户端可以执行所述步骤s201；或，客户端可以执行步骤s202；或，客户端进行故障分析，分析当前通信网络是否正常，验证通信场景是否存在安全隐患等等。

步骤s205：获取所述客户端的埋点诊断信息，向云端服务器上传所述埋点诊断信息。

其中，所述获取所述客户端的埋点诊断信息的步骤可以参加步骤s102，此处不再赘述。

所述云端服务器为服务平台用于存储各客户端的数据信息而部署的具有数据储存功能的服务器，出于实际远程诊断场景，通常服务平台会对应大量的客户端，为了降低并发处理负荷，较小服务平台的诊断处理压力，可以引入云端服务进行负载均衡，客户端可以将埋点诊断信息不直接上传至服务平台，而是将埋点诊断信息上传是与服务平台相关联的云端服务器，基于云端服务器对埋点诊断信息进行存储。

进一步的，云端服务器在存储客户端上传的埋点诊断信息时，可以向客户端输出或显示该埋点诊断信息的用于文件下载的地址信息，如可以是文件下载地址。

步骤s206：基于所述短连接向所述服务平台发送所述云端服务器对应的地址信息，所述地址信息用于指示所述服务平台从所述云端服务器下载所述埋点诊断信息。

根据一些实施例中，客户端在向云端服务器上传所述埋点诊断信息之后，可以获取云端服务器对应的地址信息，可以理解的是地址信息可以指示服务平台唯一映射下载到客户端上传的埋点诊断信息，上传地址信息一方面可以减轻与服务平台间的传输负荷，提高服务平台的诊断验证的流转效率，服务平台可以基于当前待处理的诊断验证任务，综合判决基于地址信息下载待埋点诊断信息的时机。

具体的，客户端可以基于所述短连接向所述服务平台发送所述云端服务器对应的地址信息。具体实施中，客户端可以通过一些实施例中提及的交互应用向云端服务器上传埋点诊断信息，也可以通过该交互应用向服务平台上传所述云端服务器对应的地址信息，所述地址信息用于指示所述服务平台从所述云端服务器下载所述埋点诊断信息。

步骤s207：接收所述服务平台基于所述埋点诊断信息返回的远程诊断结果。

具体可参见步骤s103，此处不再赘述。

步骤s208：接收所述客服端输出的远程诊断结果，所述远程诊断结果由所述服务平台发送至所述客服端。

根据一些实施例中，服务平台接收到埋点诊断信息，然后基于埋点诊断信息进行分析诊断，从而生成远程诊断结果。最后，服务平台将远程诊断结果发生至用于维护客户端的客服端，由客服端向客户端输出该远程诊断结果，如客服端可以语音播报该远程播报结果；此时，对于客户端而言，就可以接收所述客服端输出的远程诊断结果，所述远程诊断结果由所述服务平台发送至所述客服端。

在本申请实施例中，客户端可以接收用户所输入的诊断操作，从而建立与服务平台的短连接，然后获取所述客户端的埋点诊断信息，基于短连接向所述服务平台发送所述埋点诊断信息；客户端只需接收所述服务平台基于所述埋点诊断信息返回的远程诊断结果即可完成这个远程诊断过程。在整个远程诊断过程中，只需要客户端建立与服务平台的短连接，基于诊断开销较小的短连接，通过上传用于远程诊断的埋点诊断信息就可以实现服务平台对客户端的远程诊断，无需客户端与服务平台建立双向长连接，降低远程诊断时的资源开销；以及，服务平台在同时远程诊断多个客户端时，采用上述方式，可以兼容远程诊断业务高并发量的诊断需求，进而提升了远程诊断的容灾性能；以及，客户端在远程诊断时，可以基于服务平台的诊断验证码建立与服务平台的短连接，连接建立更便捷，基于诊断验证码可以快速实现连接建立前的鉴权验证过程，保障了远程诊断过程的诊断安全；以及，将客服端纳入到远程诊断中，客户端可以借助于客服端实现诊断验证码和/或诊断结果的获取，提升远程诊断的便捷性，以及智能性。

在一个实施例中，如图7所示，特提出了一种远程诊断方法，应用于服务平台，该方法可依赖于计算机程序实现，可运行于基于冯诺依曼体系的远程诊断装置上。该计算机程序可集成在应用中，也可作为独立的工具类应用运行。

具体的，该远程诊断方法包括：

步骤s301，在客户端接收到所输入的诊断操作时，建立与所述客户端的短连接。

根据一些实施例中，客户端可以实时或相隔一定周期对用户在当前人机交界面上的输入操作进行监测，当客户端检测到用户针对远程诊断(功能或服务)输入诊断操作时，客户端识别到所述诊断操作，执行“建立与服务平台的短连接”运算或功能实现的某种控制的代码，从而需要进行“建立与服务平台的短连接”的步骤；示意性的，客户端可以向服务平台发送用于建立通信短连接的请求，服务平台在接收该请求时，可以确定用户在客户端上输入了诊断操作，用于请求服务平台提供远程诊断服务，此时，服务平台响应于该请求，从而可以建立与所述客户端的短连接。

其中，所述建立与所述客户端的短连接的详细释义可参考本申请中的相关实施例，此处不再赘述。

步骤s302，基于所述短连接，获取所述客户端的埋点诊断信息。

根据一些实施例中，用户的客户端与服务平台之间的通信连接通常为采用预设通信架构建立的通信连接服务，所述通信架构是指进行数据通信的一种通信结构，通信架构定义了数据网络通信系统的各个方面，包含通信的接口类型、使用的网络协议、实现的数据框架、通信布线的类型等。常用的通信架构可以是tcp/ip架构，netty架构、c/s架构、soa架构等。如，一种所述通信架构可以是为采用基于java开源的netty框架，并配合websocket技术从而实现通信网络中服务平台与用户客户端之间建立一种通信连接，并基于通信连接实现两端之间的通信数据的交互。其中，在不同的实施场景下通信连接的类型不一样，在本申请中，服务平台在远程诊断场景下与客户端之间的通信连接为短连接。

根据一些实施例中，所述埋点诊断信息为客户端上的用于远程诊断的相应诊断文件、相应诊断数据、相应日志等数据。所述埋点诊断信息来源于客户端本端，采用预先或实时埋点的方式，获取用于远程诊断的故障诊断信息或故障诊断数据，如客户端硬件故障时，可以是是用于远程硬件诊断的故障硬件信息或数据，如客户端软件故障时，可以是用于远程软件诊断的故障硬软件信息或数据。通俗点讲，就是在相应诊断服务、诊断app、诊断web等产品中植入一段代码，监控用户行为事件(例如某个页面的曝光)、系统行为事件、硬件行为事件等。用户一旦主动触发或被动触发了该事件，就会上传或收集埋点代码中定义的、需要上传的有关该事件的埋点诊断信息。常见的埋点诊断信息包括：(软硬件)故障id信息、软硬件接口信息、用户会话id信息，用户id信息，当前页面编码信息，当前事件编码信息，触发时间信息，用户设备id信息，ip信息等一种或多种的拟合。

根据一些实施例中，客户端上搭载有用于与服务平台交互的交互应用，客户端与服务平台可以基于交互应用实现短连接的建立，如客户端或服务平台开启交互应用，从而在交互应用中触发生成通信诊断请求并发送至服务平台，从而服务平台可以基于通信诊断请求建立与客户端之间的短连接；进一步的，客户端可以通过该交互应用向服务平台上传埋点诊断信息，服务平台可以通过与客户端之间的通信短连接，从而可以获取到客户端交互应用上传的埋点诊断信息。

步骤s303，基于所述埋点诊断信息向所述客户端返回远程诊断结果。

具体的，服务平台在获取到客户端的埋点诊断信息之后，然后对埋点诊断信息进行诊断分析，如基于埋点诊断信息对客户端出现的软件(或硬件)故障进行分析，从而基于分析结果生成远程诊断结果，示意性的，所述远程诊断结果可以包括相应故障问题的修复步骤信息。

可选的，所述服务平台对埋点诊断信息的诊断可以是基于维护的专家诊断系统实现的，服务平台可以通过专家诊断系统中的专业人员或专家人员对埋点诊断信息进行自动化分析，从而得到自动化分析的结果，基于分析结果就可以生成远程诊断结果。

可选的，所述服务平台对埋点诊断信息的诊断可以是基于相应的诊断技术实现的，如采用人工神经网络、模糊推理、遗传算法等，在本申请实施例中，所述服务平台可以预先训练有诊断模型，所述诊断模型通过预先获取实际故障诊断环境中的故障样本数据，提取特征信息，并对所述故障样本数据进行标注，标注好故障类型，所述特征信息包含至少一个故障诊断特征，创建诊断模型。所述诊断模型可以是使用大量的干扰样本数据训练出来的，如背光调节模型可以是基于卷积神经网络(convolutionalneuralnetwork，cnn)模型，深度神经网络(deepneuralnetwork，dnn)模型、循环神经网络(recurrentneuralnetworks，rnn)、模型、嵌入(embedding)模型、梯度提升决策树(gradientboostingdecisiontree，gbdt)模型、逻辑回归(logisticregression，lr)模型中的至少一种实现的，基于已经标注故障类型信息的故障样本数据对诊断模型进行训练，可以得到训练好的诊断模型。

在本申请实施例中，所述诊断模型可以采用引入误差反向传播算法的隐马尔可夫模型(dnn-hmm模型)创建初始模型，在提取所述故障样本数据的特征信息之后，将所述特征信息输入到所述dnn-hmm模型中，所述dnn-hmm模型的训练过程通常由正向传播和反向传播两部分组成，在正向传播过程中，服务器输入样本-故障样本数据对应的特征信息从所述神经网络模型的输入层经过隐层神经元(也称节点)的传递函数(又称激活函数、转换函数)运算后，传向输出层，其中每一层神经元状态影响下一层神经元状态，在输出层计算实际输出值-异常信息类型，计算所述实际输出值与期望输出值的期望误差，基于所述期望误差调整所述dnn-hmm模型的参数，所述参数包含每一层的权重值和阈值，训练完成后，生成诊断模型。实际应用中，服务平台将埋点诊断信息输入至故障模型中，就可以输出相应的远程诊断结果。

根据一些实施例中，服务平台在基于埋点故诊断信息，生成对应的远程诊断结果之后，然后将远程诊断结果可以发送至客户端。

在本申请实施例中，服务平台确定客户端接收到用户所输入的诊断操作时，可以建立与所述客户端的短连接，然后基于短连接获取所述客户端的埋点诊断信息，基于所述埋点诊断信息返回的远程诊断结果之客户端即可完成整个远程诊断过程。在整个远程诊断过程中，只需要客户端建立与服务平台的短连接，基于诊断开销较小的短连接，通过上传用于远程诊断的埋点诊断信息就可以实现服务平台对客户端的远程诊断，无需客户端与服务平台建立双向长连接，降低远程诊断时的资源开销；以及，服务平台在同时远程诊断多个客户端时，采用上述方式，可以兼容远程诊断业务高并发量的诊断需求，进而提升了远程诊断的容灾性能；以及，客户端在远程诊断时，可以基于服务平台的诊断验证码建立与服务平台的短连接，连接建立更便捷，基于诊断验证码可以快速实现连接建立前的鉴权验证过程，保障了远程诊断过程的诊断安全；以及，将客服端纳入到远程诊断中，客户端可以借助于客服端实现诊断验证码和/或诊断结果的获取，提升远程诊断的便捷性，以及智能性。

请参见图8，图8是本申请提出的一种远程诊断方法的另一种实施例的流程示意图。具体的：

步骤s401：接收客服端的诊断指令，确定所述客户端发起诊断操作，所述诊断指令为所述客服端基于所述客户端所输入的呼叫操作生成。

根据一些实施例中，客户端上的用户在使用客户端过程中，若出现故障问题，如硬件问题、软件问题，用户可以基于客户端向远程诊断的客服端进行呼叫，如发起语音通话、视频通话等。

客户端可以接收用户向客服端输入的呼叫操作，通常所述呼叫操作可以用于所述客服端指示所述服务平台生成诊断验证码，具体实施中，客服端会接收到客户端的呼叫，然后可以在相应呼叫场景下生成诊断指令并发送至服务平台，如基于用户通过客户端向客服端输出的故障描述信息，客服端可以根据故障描述信息，然后生成诊断指令；客服端将诊断指令发送至服务平台，从而服务平台可以在接收到该诊断指令之后，可以确定用户在客户端上发起了诊断操作，然后服务平台可以响应于该诊断指令，生成诊断验证码然后将诊断验证码发送至客户端。

步骤s402：生成第一诊断验证码。

在本申请中，第一诊断验证码为服务平台上生成的诊断验证码，在生成第一诊断验证码时，可以是服务平台基于随机数生成规则随机生成的验证码，也可以是相应的加密算法的生成规则生成的加密验证码。另外，所述诊断验证码的类型可以是多种形式，包括但不限于：语音验证码形式、字符验证码形式、图像验证码形式等等。

根据一些实施例中，服务平台在生成第一诊断验证码之后，会直接或间接向所述客服端发送第一诊断验证码，从而后续在建立与客户端的通信短连接时，可以接收到所述客户端发送的携带第二诊断验证码的通信诊断请求，并对通信诊断请求中的第二诊断验证码进行验证，并在验证通过之后，继而建立与客户端之间的短连接。

其中，所述第二诊断验证码为通信诊断请求中携带的诊断验证码，为在客户端上产生。

步骤s403：向所述客服端发送第一诊断验证码，接收所述客户端发送的携带第二诊断验证码的通信诊断请求，所述通信诊断请求基于所述第一诊断验证码生成。

根据一些实施例中，服务平台在生成第一诊断验证码之后，可以向所述客服端发送第一诊断验证码，然后由客服端发送或输出至客户端，实际应用中，客户端可以建立与客服端之间的呼叫连接，然后服务平台基于诊断指令生成第一诊断验证码；服务平台可以将所述第一诊断验证码发送至客服端，由客服端转发至客户端。具体实施中，对于客户端而言，所述诊断验证码由所述服务平台发送至所述客服端，客服端向客户端输出该诊断验证码，如以语音播报的方式向客户端上的用户进行语音告知。

根据一些实施例中，客户端接收到服务平台生成由客服端转发输出的第一诊断验证码之后，基于第一诊断验证码生成通信诊断请求，所述通信诊断请求携带第二诊断验证码。如，客户端获取到服务平台发送的包含第一诊断验证码(假设为111222)的通知信息、通知语音、通知图片等通知媒介，用户此时查阅到通知媒介(如短消息)中的第一诊断验证码(假设为111222)，然后在远程诊断服务、远程诊断应用、远程诊断web等远程诊断产品中参照第一诊断验证码人工输入或机器自动输入第二诊断验证码(假设为111223)，然后客户端上的(远程诊断产品)会自动基于所输入的第二诊断验证码生成通信诊断请求，然后将通信诊断请求发送至服务平台；此时，服务平台即可接收到客户端发送的携带第二诊断验证码的通信诊断请求。

步骤s404：基于交互应用接收所述客户端发送的携带第二诊断验证码的通信诊断请求，所述交互应用为与所述客户端交互的客户端应用。

根据一些实施例中，服务平台维护有与客户端进行交互通信的交互应用，同理，客户端上可以搭载有用于与所述服务平台交互的客户端应用，也即所述交互应用，交互应用中可以集成远程诊断功能，当触发交互应用中的远程诊断功能时，可以在所述交互应用中输入第二诊断验证码并生成相应的通信诊断请求，以在服务平台基于通信诊断请求中的诊断验证码验证通过之后，可以成功建立与服务平台之间的短连接。

对于客户端而言，客户端获取到服务平台生成的第一诊断验证码之后，会启动交互应用，客户端在检测到在所述交互应用中输入的所述第二诊断验证码时，可以生成包含所述第二诊断验证码的通信诊断请求，所述交互应用为与所述服务平台交互的客户端应用。

其中，在实际应用中，第一诊断验证码通常与第二诊断验证码一致。

如，一种方式可以是：客户端获取到服务平台直接发送的或由客服端转发包含第一诊断验证码的通知信息、通知语音、通知图片等通知媒介，此时，用户可以通过客户端查阅到通知媒介中的第一诊断验证码，然后在客户端本端手动开启交互应用，然后基于查阅到的第一诊断验证码，将第二诊断验证码输入至交互应用的相应“开启远程诊断功能”对应的验证码输入框中此时，客户端即确定检测到在所述交互应用输入的第二诊断验证码，继而基于第二诊断验证码生成通信诊断请求。

如，一种方式可以是：客户端获取到服务平台发送的包含第一诊断验证码的通知信息、通知语音、通知图片等通知媒介，此时，客户端可以智能对通知媒介进行语义识别，从而可以识别到当前客户端上的用户需要进行远程诊断，此时，客户端可以无需用户操作，智能开启远程诊断功能对应的交互应用，另外，可以智能基于通知消息中的第一诊断验证码自动输入第二诊断验证码至交互应用的相应“开启远程诊断功能”对应的验证码输入框中，此时，客户端即确定检测到在所述交互应用输入的第二诊断验证码，继而基于第二诊断验证码生成通信诊断请求，

进一步的，服务平台则可以基于与服务平台之间的交互应用接收到客户端发送的携带第二诊断验证码的通信诊断请求。

步骤s405：向所述客户端发送第一诊断验证码。

根据一些实施例中，服务平台可以直接向客户端发送第一诊断验证码，如发送的包含第一诊断验证码的通知信息、通知语音、通知图片等通知媒介，这些通知媒介中包含第一诊断验证码。

步骤s406：基于所述交互应用接收所述客户端生成的携带第二诊断验证码的通信诊断请求，所述交互应用为与所述客户端交互的客户端应用。

具体可参见步骤s204，此处不再赘述。

步骤s407：基于所述第二诊断验证码以及所述第一诊断验证码，建立与所述客服端的短连接。

具体的，服务平台在获取第二诊断验证码之后，然后获取生成的第一诊断验证码与第二诊断验证码，进行诊断验证。

1、服务平台判断所述第二诊断验证码与所述第一诊断验证码是否匹配；

当所述第二诊断验证码与所述第一诊断验证码匹配时，通过所述交互应用向所述客户端发送验证通过信息；所述验证通过信息用于建立与所述客户端的所述短连接。

其中，所述匹配可以是基于预先设定的匹配规则进行匹配，一种匹配规则可以是判断第一诊断验证码与第二诊断验证码是否一致；一种匹配规则是：预先建立有第一诊断验证码与参考验证码的配对关系，也即第一诊断验证码与参考验证码唯一映射，其中第一诊断验证码与第二诊断验证码不一致，则服务平台判断参考验证码与第二诊断验证码是否一致，可以理解的是，在客户端侧生会基于相应的验证码生成规则，可以基于第一诊断验证码生成对应的第二诊断验证码；一种匹配规则可以是，计算第二诊断验证码与所述第一诊断验证码的相似度，在所述相似度小于相似度阈值时，确定匹配，反之则不匹配。

2、当所述第二诊断验证码与所述第一诊断验证码不匹配时，通过所述交互应用向所述客户端发送验证失败信息，所述验证失败信息用于指示所述客户端重新建立所述短连接。

例如，在第二诊断验证码与所述第一诊断验证码不一致时，确定所述第二诊断验证码与所述第一诊断验证码不匹配，然后生成验证失败信息，并基于交互应用向客户端发送该验证失败信息。

在实际应用中，服务平台通常会对应多个客户端，也即存在同时为多个客户端提供远程诊断服务的情况，可以理解的是，服务平台会为多个客户端中的每个客户端生成第一诊断验证码，为了便于后续的诊断验证过程，服务平台可以预先建立客户端与第一诊断验证码的唯一映射关系，如可以基于客户端的设备标识建立与第一诊断验证码的映射关系，并将该映射关系以数据列表的形式存在，在对相应的客户端的第二诊断验证码进行验证时，只需获取该客户端的唯一映射关系，从而获取到第一诊断验证码，从而基于上述流程进行验证。

步骤s408：基于所述短连接，获取所述客户端的埋点诊断信息。

根据一些实施例中，服务平台可以至二级基于所述短连接接收所述客户端发送的埋点诊断信息。如客户端可以直接通过交互应用上传埋点诊断信息，然后服务平台即可接收到客户端的埋点诊断信息。

根据一些实施例中，服务平台可以基于所述短连接接收所述客户端发送的云端服务器的地址信息，所述云端服务器用于存储所述客户端的所述埋点诊断信息；然后服务平台基于所述地址信息可以向所述云端服务器下载所述埋点诊断信息。

步骤s409：基于所述埋点诊断信息生成针对所述客户端的远程诊断结果，向所述客服端发送所述远程诊断结果，所述远程诊断结果用于指示所述客服端向所述客服端输出所述远程诊断结果；

所述基于所述埋点诊断信息生成针对所述客户端的远程诊断结果的详细释义可参考步骤s303，此处不再赘述。

根据一些实施例中，服务平台接收到埋点诊断信息，然后基于埋点诊断信息进行分析诊断，从而生成远程诊断结果。最后，服务平台将远程诊断结果发生至用于维护客户端的客服端，由客服端向客户端输出该远程诊断结果，如客服端可以语音播报该远程播报结果；此时，对于客户端而言，就可以接收所述客服端输出的远程诊断结果，所述远程诊断结果由所述服务平台发送至所述客服端。

步骤s410：基于所述埋点诊断信息生成针对所述客户端的所述远程诊断结果，将所述远程诊断结果发送至所述客户端。

所述基于所述埋点诊断信息生成针对所述客户端的远程诊断结果的详细释义可参考步骤s303，此处不再赘述。

根据一些实施例中，服务平台接收到埋点诊断信息，然后基于埋点诊断信息进行分析诊断，从而生成远程诊断结果。最后，服务平台基于与客户端之间的短连接将远程诊断结果返回至客户端，此时客户端即可接收到该远程诊断结果。

在一种可行的实施方式中：所述远程诊断方法可以引入客服端，客服端用于对客户端进行维护以及提供相应的客户服务，具体的，客户端可以接收用户向客服端输入的呼叫操作，通常所述呼叫操作可以用于所述客服端指示所述服务平台生成诊断验证码，如，客服端接收到客户端的呼叫操作，然后建立与客户端的呼叫连接，可以理解的是，客户端上的用户可以基于呼叫连接向客服端输出或说明当前遇到的故障问题信息，以基于故障问题信息通过客服端请求服务平台的，客服端此时可以基于故障问题信息预先选择对客户端上的可能存在的故障问题进行相应诊断项目或诊断服务(如某硬件诊断服务、某软件诊断服务)的判决或选择。也即客服端可以确定客户端所需的诊断项目信息(如相应诊断项目或诊断服务)，客服端此时会生成携带诊断项目信息的诊断指令，将该诊断指令发送至服务平台，以辅助服务平台基于所述诊断项目信息对所述埋点诊断信息进行远程诊断，也即按照诊断项目信息中的各项所需诊断服务或诊断项目对埋点诊断信息进行诊断，从而生成远程诊断结果，最后服务平台在向客户端返回远程诊断结果。

在本申请实施例，服务平台确定客户端接收到用户所输入的诊断操作时，可以建立与所述客户端的短连接，然后基于短连接获取所述客户端的埋点诊断信息，基于所述埋点诊断信息返回的远程诊断结果之客户端即可完成整个远程诊断过程。在整个远程诊断过程中，只需要客户端建立与服务平台的短连接，基于诊断开销较小的短连接，通过上传用于远程诊断的埋点诊断信息就可以实现服务平台对客户端的远程诊断，无需客户端与服务平台建立双向长连接，降低远程诊断时的资源开销；以及，服务平台在同时远程诊断多个客户端时，采用上述方式，可以兼容远程诊断业务高并发量的诊断需求，进而提升了远程诊断的容灾性能；以及，客户端在远程诊断时，可以基于服务平台的诊断验证码建立与服务平台的短连接，连接建立更便捷，基于诊断验证码可以快速实现连接建立前的鉴权验证过程，保障了远程诊断过程的诊断安全；以及，将客服端纳入到远程诊断中，客户端可以借助于客服端实现诊断验证码和/或诊断结果的获取，提升远程诊断的便捷性，以及智能性。

在一个实施例中，如图9所示，特提出了一种远程诊断方法，应用于客服端，该方法可依赖于计算机程序实现，可运行于基于冯诺依曼体系的远程诊断装置上。该计算机程序可集成在应用中，也可作为独立的工具类应用运行。

具体的，该远程诊断方法包括：

步骤s501：接收客户端的呼叫操作，基于所述呼叫操作生成诊断指令；

根据一些实施例中，当客户端检测到用户针对客服端输入呼叫操作时，客户端识别到所述呼叫操作，执行“向客服端呼叫”运算或功能实现的某种控制的代码，从而建立与客服端的呼叫连接，可以理解的是，客户端与客服端建立呼叫连接之后，可以理解的是，客户端上的用户可以基于呼叫连接向客服端输出或说明当前遇到的故障问题信息，以基于故障问题信息通过客服端请求服务平台的，客服端此时可以基于故障问题信息预先选择对客户端上的可能存在的故障问题进行相应诊断项目或诊断服务(如某硬件诊断服务、某软件诊断服务)的判决或选择，从而生成诊断指令。所述诊断指令常用于指示所述服务平台建立与所述客户端的短连接，服务平台并基于所述短连接向所述客户端返回埋点诊断信息对应的远程诊断结果。

步骤s502：将所述诊断指令发送至服务平台。

根据一些实施例中，所述客服端可以预先建立与服务平台的通信连接，客服端在基于用户在客户端上的呼叫操作生成诊断指令之后，即可通过与服务平台之间的通信连接将诊断指令发送至服务平台。其中，所述诊断指令常用于指示所述服务平台建立与所述客户端的短连接，并使服务平台基于所述短连接向所述客户端返回埋点诊断信息对应的远程诊断结果，所述埋点诊断信息为所述客户端的所述埋点诊断信息。

在本申请实施例，客服端接收到客户端的呼叫操作，可以基于所述呼叫操作生成诊断指令，然后将所述诊断指令发送至服务平台。服务平台就可以根据诊断指令确定客户端接收到用户所输入的诊断操作，从而可以建立与所述客户端的短连接，然后基于短连接获取所述客户端的埋点诊断信息，基于所述埋点诊断信息返回的远程诊断结果之客户端即可完成整个远程诊断过程。在整个远程诊断过程中，只需要客户端建立与服务平台的短连接，基于诊断开销较小的短连接，通过上传用于远程诊断的埋点诊断信息就可以实现服务平台对客户端的远程诊断，无需客户端与服务平台建立双向长连接，降低远程诊断时的资源开销；以及，服务平台在同时远程诊断多个客户端时，采用上述方式，可以兼容远程诊断业务高并发量的诊断需求，进而提升了远程诊断的容灾性能；以及，客户端在远程诊断时，可以基于服务平台的诊断验证码建立与服务平台的短连接，连接建立更便捷，基于诊断验证码可以快速实现连接建立前的鉴权验证过程，保障了远程诊断过程的诊断安全；以及，将客服端纳入到远程诊断中，客户端可以借助于客服端实现诊断验证码和/或诊断结果的获取，提升远程诊断的便捷性，以及智能性。

请参见图10，图10是本申请提出的一种远程诊断方法的另一种实施例的流程示意图。具体的：

步骤s601：接收客户端的呼叫操作。

具体可参见步骤s501，此处不再赘述。

步骤s602：获取所述呼叫操作对应的故障信息，基于所述故障信息确定针对所述客户端的诊断项目信息。

根据一些实施例中，客服端用于对客户端进行维护以及提供相应的客户服务，具体的，客户端可以接收用户向客服端输入的呼叫操作，通常所述呼叫操作可以用于所述客服端指示所述服务平台生成诊断验证码，如，客服端接收到客户端的呼叫操作，然后建立与客户端的呼叫连接，可以理解的是，客户端上的用户可以基于呼叫连接向客服端输出或说明当前遇到的故障信息(如硬件故障问题、软件故障问题)，以基于故障信息通过客服端请求服务平台的诊断服务，客服端此时可以基于故障信息预先选择对客户端上的可能存在的故障问题进行相应诊断项目或诊断服务(如某硬件诊断服务、某软件诊断服务)的判决或选择。也即客服端可以确定客户端所需提供的诊断项目信息(如相应诊断项目或诊断服务)。

步骤s603：生成携带所述诊断项目信息的诊断指令，所述诊断项目信息用于所述服务平台对所述埋点诊断信息进行远程诊断，生成远程诊断结果。

根据一些实施例中，客服端基于所述故障信息确定针对所述客户端的诊断项目信息之后，此时会生成携带诊断项目信息的诊断指令，通过与服务平台之间通信连接将该诊断指令发送至服务平台，服务平台会首先基于诊断指令建立与客户端之间的短连接，然后可以基于服务平台中的诊断项目信息以辅助服务平台基于所述诊断项目信息对所述埋点诊断信息进行远程诊断，也即按照诊断项目信息中的各项所需诊断服务或诊断项目对埋点诊断信息进行诊断，从而生成远程诊断结果，最后服务平台在向客户端返回远程诊断结果。

步骤s604：接收所述服务平台发送的诊断验证码，向所述客户端输出所述诊断验证码。

其中，所述诊断验证码为所述服务平台基于所述诊断指令生成。根据一些实施例中，所述诊断验证码常用于指示所述客户端生成包含所述诊断验证码的通信诊断请求并发送至所述服务平台；所述通信诊断请求常用于指示所述服务平台基于所述通信诊断请求建立与所述客户端的短连接。

根据一些实施例中，服务平台可以在接收到该诊断指令之后，可以确定用户在客户端上发起了诊断操作，然后服务平台可以响应于该诊断指令，生成诊断验证码然后将诊断验证码发送至客服端。此时，客服端可以向所述客户端输出所述诊断验证码。

在本申请中，服务平台可以基于随机数生成规则随机生成的验证码，也可以是相应的加密算法的生成规则生成的加密验证码。另外，所述诊断验证码的类型可以是多种形式，包括但不限于：语音验证码形式、字符验证码形式、图像验证码形式等等。

进一步的，客服端可以采用包含诊断验证码的通知信息、通知语音、通知图片等通知媒介向客户端进行输出，以使客户端收到服务平台上生成的诊断验证码。

步骤s605：接收所述服务平台发送的远程诊断结果，向所述客户端输出所述远程诊断结果。

根据一些实施例中，服务平台接收到埋点诊断信息，然后基于埋点诊断信息进行分析诊断，从而生成远程诊断结果。最后，服务平台将远程诊断结果发生至用于维护客户端的客服端；此时，由客服端向客户端输出该远程诊断结果，如客服端可以音频播报该远程播报结果；此时，对于客户端而言，就可以接收所述客服端输出的远程诊断结果，所述远程诊断结果由所述服务平台发送至所述客服端。

在本申请实施例中，客服端接收到客户端的呼叫操作，可以基于所述呼叫操作生成诊断指令，然后将所述诊断指令发送至服务平台。服务平台就可以根据诊断指令确定客户端接收到用户所输入的诊断操作，从而可以建立与所述客户端的短连接，然后基于短连接获取所述客户端的埋点诊断信息，基于所述埋点诊断信息返回的远程诊断结果之客户端即可完成整个远程诊断过程。在整个远程诊断过程中，只需要客户端建立与服务平台的短连接，基于诊断开销较小的短连接，通过上传用于远程诊断的埋点诊断信息就可以实现服务平台对客户端的远程诊断，无需客户端与服务平台建立双向长连接，降低远程诊断时的资源开销；以及，服务平台在同时远程诊断多个客户端时，采用上述方式，可以兼容远程诊断业务高并发量的诊断需求，进而提升了远程诊断的容灾性能；以及，客户端在远程诊断时，可以基于服务平台的诊断验证码建立与服务平台的短连接，连接建立更便捷，基于诊断验证码可以快速实现连接建立前的鉴权验证过程，保障了远程诊断过程的诊断安全；以及，将客服端纳入到远程诊断中，客户端可以借助于客服端实现诊断验证码和/或诊断结果的获取，提升远程诊断的便捷性，以及智能性。

请参见图11，为本申请实施例提供的一种远程诊断系统的架构示意图。如图11所示，所述远程诊断系统10包括客服端110、服务平台120和客户端集群，所述客户端集群可以包括多个客户端，如图1所示，具体包括客户端1、客户端2、…、客户端n，n为大于0的整数；为便于理解，本发明实施例以图11中的客服端110、服务平台120以及客户端1为例进行描述。

所述服务平台120具有远程诊断功能，可以是单独的服务器设备，例如：机架式、刀片、塔式、或者机柜式的服务器设备，或采用工作站、大型计算机等具备较强计算能力硬件设备；也可以是采用多个服务器组成的服务器集群，所述服务集群中的各服务器可以是以对称方式组成的，其中每台服务器在业务链路中功能等价、地位等价，各服务器均可单独对外提供服务，所述单独提供服务可以理解为无需另外的服务器的辅助。

客户端集群中各客户端可以是通信功能的电子设备，该电子设备包括但不限于：可穿戴设备、手持设备、个人电脑、平板电脑、车载设备、智能手机、计算设备或连接到无线调制解调器的其它处理设备等。在不同的网络中电子设备可以叫做不同的名称，例如：用户设备、接入终端、用户单元、用户站、移动站、移动台、远方站、远程终端、移动设备、用户终端、终端、无线通信设备、用户代理或用户装置、蜂窝电话、无绳电话、个人数字处理(personaldigitalassistant，pda)、5g网络或未来演进网络中的终端设备等。

所述客服端110也可以是一种电子设备，该电子设备包括但不限于：个人电脑、平板电脑、智能手机、计算设备或连接到无线调制解调器的其它处理设备等。

所述客服端110、服务平台120以及客户端通过网络进行交互通信，网络可以是无线网络，也可以是有线网络，无线网络包括但不限于蜂窝网络、无线局域网、红外网络或蓝牙网络，有线网络包括但不限于以太网、通用串行总线(universalserialbus，usb)或控制器局域网络。

另外，上述实施例提供的远程诊断系统实施例与一些实施例中的所述远程诊断方法属于同一构思，其体现实现过程详见方法实施例，这里不再赘述。

下述为本申请装置实施例，可以用于执行本申请方法实施例。对于本申请装置实施例中未披露的细节，请参照本申请方法实施例。

请参见图12，其示出了本申请一个示例性实施例提供的远程诊断装置的结构示意图。该远程诊断装置可以通过软件、硬件或者两者的结合实现成为装置的全部或一部分。该装置1包括连接建立模块11、信息发送模块12和结果发送模块13。

连接建立模块11，用于接收所输入的诊断操作，建立与服务平台的短连接；

信息发送模块12，用于获取所述客户端的埋点诊断信息，基于所述短连接向所述服务平台发送所述埋点诊断信息；

结果接收模块13，用于接收所述服务平台基于所述埋点诊断信息返回的远程诊断结果。

可选的，如图13所示，所述连接建立模块11，包括：

验证码获取单元111，用于接收所输入的诊断操作，向所述服务平台获取诊断验证码；

短连接建立单元112，用于基于所述诊断验证码建立与服务平台的短连接。

可选的，如图14所示，所述验证码获取单元111，包括：

操作接收子单元1111，用于接收向客服端输入的呼叫操作，所述呼叫操作用于所述客服端指示所述服务平台生成诊断验证码；

验证码接收子单元1112，用于接收所述服务平台发送的所述诊断验证码。

可选的，所述操作接收子单元1111，具体用于：

接收向所述客服端输入的呼叫操作，所述呼叫操作用于所述客服端指示所述服务平台生成诊断验证码；

所述验证码接收子单元1112，还用于获取所述客服端输出的所述诊断验证码，所述诊断验证码由所述服务平台发送至所述客服端。

可选的，如图15所示，所述短连接建立单元112，包括：

诊断请求发送子单元1121，用于生成包含所述诊断验证码的通信诊断请求，将所述通信诊断请求发送至所述服务平台，所述通信诊断请求用于指示所述服务平台对所述诊断验证码进行连接验证；

通过信息接收子单元1122，用于接收所述服务平台发送的验证通过信息，建立与所述服务平台的短连接。

可选的，所述验证码获取单元111，具体用于

启动交互应用，检测到在所述交互应用中输入的所述诊断验证码，生成包含所述诊断验证码的通信诊断请求，所述交互应用为与所述服务平台交互的客户端应用。

可选的，所述装置1，具体用于：

接收所述服务平台发送的验证失败信息，重新建立与所述服务平台的所述短连接。

可选的，所述信息发送模块12，具体用于：

向云端服务器上传所述埋点诊断信息，基于所述短连接向所述服务平台发送所述云端服务器对应的地址信息，所述地址信息用于指示所述服务平台从所述云端服务器下载所述埋点诊断信息。

可选的，所述结果接收模块13，具体用于：

接收所述客服端输出的远程诊断结果，所述远程诊断结果由所述服务平台发送至所述客服端。

需要说明的是，上述实施例提供的远程诊断装置在执行远程诊断方法时，仅以上述各功能模块的划分进行举例说明，实际应用中，可以根据需要而将上述功能分配由不同的功能模块完成，即将设备的内部结构划分成不同的功能模块，以完成以上描述的全部或者部分功能。另外，上述实施例提供的远程诊断装置与远程诊断方法实施例属于同一构思，其体现实现过程详见方法实施例，这里不再赘述。

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

在本申请实施例中，客户端可以接收用户所输入的诊断操作，从而建立与服务平台的短连接，然后获取所述客户端的埋点诊断信息，基于短连接向所述服务平台发送所述埋点诊断信息；客户端只需接收所述服务平台基于所述埋点诊断信息返回的远程诊断结果即可完成这个远程诊断过程。在整个远程诊断过程中，只需要客户端建立与服务平台的短连接，基于诊断开销较小的短连接，通过上传用于远程诊断的埋点诊断信息就可以实现服务平台对客户端的远程诊断，无需客户端与服务平台建立双向长连接，降低远程诊断时的资源开销；以及，服务平台在同时远程诊断多个客户端时，采用上述方式，可以兼容远程诊断业务高并发量的诊断需求，进而提升了远程诊断的容灾性能；以及，客户端在远程诊断时，可以基于服务平台的诊断验证码建立与服务平台的短连接，连接建立更便捷，基于诊断验证码可以快速实现连接建立前的鉴权验证过程，保障了远程诊断过程的诊断安全；以及，将客服端纳入到远程诊断中，客户端可以借助于客服端实现诊断验证码和/或诊断结果的获取，提升远程诊断的便捷性，以及智能性。

请参见图16，其示出了本申请一个示例性实施例提供的远程诊断装置的结构示意图。该远程诊断装置可以通过软件、硬件或者两者的结合实现成为装置的全部或一部分。该装置2包括连接建立模块21、信息获取模块22和结果返回模块23。

连接建立模块21，用于在客户端接收到所输入的诊断操作时，建立与所述客户端的短连接；

信息获取模块22，用于基于所述短连接，获取所述客户端的埋点诊断信息；

结果返回模块23，用于基于所述埋点诊断信息向所述客户端返回远程诊断结果。

可选的，如图所示，所述连接建立模块21，包括：

操作确定单元211，用于接收客服端的诊断指令，确定所述客户端发起诊断操作，所述诊断指令为所述客服端基于所述客户端所输入的呼叫操作生成；

连接建立单元212，用于生成第一诊断验证码，基于所述第一诊断验证码建立与所述客服端的短连接。

可选的，如图17所示，所述连接建立单元212，包括：

请求接收子单元2121，用于向所述客服端发送第一诊断验证码，接收所述客户端发送的携带第二诊断验证码的通信诊断请求，所述通信诊断请求基于所述第一诊断验证码生成；

连接建立子单元2122，用于基于所述第二诊断验证码以及所述第一诊断验证码，建立与所述客服端的短连接。

可选的，所示请求接收子单元2121，具体用于：

向所述客服端发送第一诊断验证码，所述第一诊断验证码用于指示所述客服端向所述客户端输出所述第一诊断验证码；

基于交互应用接收所述客户端发送的携带第二诊断验证码的通信诊断请求，所述交互应用为与所述客户端交互的客户端应用。

可选的，所示连接建立子单元2122，具体用于：

向所述客户端发送第一诊断验证码；

基于所述交互应用接收所述客户端生成的携带第二诊断验证码的通信诊断请求，所述交互应用为与所述客户端交互的客户端应用。

可选的，所示连接建立子单元2122，具体用于：

判断所述第二诊断验证码与所述第一诊断验证码是否匹配；

当所述第二诊断验证码与所述第一诊断验证码匹配时，通过所述交互应用向所述客户端发送验证通过信息；所述验证通过信息用于建立与所述客户端的所述短连接。

可选的，所示连接建立子单元2122，具体用于：

当所述第二诊断验证码与所述第一诊断验证码不匹配时，通过所述交互应用向所述客户端发送验证失败信息，所述验证失败信息用于指示所述客户端重新建立所述短连接。

可选的，如图18所示，所述信息获取模块22，包括：

第一获取单元221，用于基于所述短连接接收所述客户端发送的埋点诊断信息；

第二获取单元222，用于基于所述短连接接收所述客户端发送的云端服务器的地址信息，所述云端服务器用于存储所述客户端的所述埋点诊断信息；向所述云端服务器下载所述埋点诊断信息。

可选的，如图19所示，所述结果返回模块23，包括：

第一返回单元231，用于基于所述埋点诊断信息生成针对所述客户端的远程诊断结果，向所述客服端发送所述远程诊断结果，所述远程诊断结果用于指示所述客服端向所述客服端输出所述远程诊断结果；

第二返回单元232，用于基于所述埋点诊断信息生成针对所述客户端的所述远程诊断结果，将所述远程诊断结果发送至所述客户端。

可选的，所述结果返回模块23，具体用于：

获取所述诊断指令携带的诊断项目信息，基于所述诊断项目信息对所述埋点诊断信息进行远程诊断，生成远程诊断结果；

向所述客户端返回远程诊断结果。

需要说明的是，上述实施例提供的远程诊断装置在执行远程诊断方法时，仅以上述各功能模块的划分进行举例说明，实际应用中，可以根据需要而将上述功能分配由不同的功能模块完成，即将设备的内部结构划分成不同的功能模块，以完成以上描述的全部或者部分功能。另外，上述实施例提供的远程诊断装置与远程诊断方法实施例属于同一构思，其体现实现过程详见方法实施例，这里不再赘述。

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

在本申请实施例中，服务平台确定客户端接收到用户所输入的诊断操作时，可以建立与所述客户端的短连接，然后基于短连接获取所述客户端的埋点诊断信息，基于所述埋点诊断信息返回的远程诊断结果之客户端即可完成整个远程诊断过程。在整个远程诊断过程中，只需要客户端建立与服务平台的短连接，基于诊断开销较小的短连接，通过上传用于远程诊断的埋点诊断信息就可以实现服务平台对客户端的远程诊断，无需客户端与服务平台建立双向长连接，降低远程诊断时的资源开销；以及，服务平台在同时远程诊断多个客户端时，采用上述方式，可以兼容远程诊断业务高并发量的诊断需求，进而提升了远程诊断的容灾性能；以及，客户端在远程诊断时，可以基于服务平台的诊断验证码建立与服务平台的短连接，连接建立更便捷，基于诊断验证码可以快速实现连接建立前的鉴权验证过程，保障了远程诊断过程的诊断安全；以及，将客服端纳入到远程诊断中，客户端可以借助于客服端实现诊断验证码和/或诊断结果的获取，提升远程诊断的便捷性，以及智能性。

请参见图20，其示出了本申请一个示例性实施例提供的远程诊断装置的结构示意图。该远程诊断装置可以通过软件、硬件或者两者的结合实现成为装置的全部或一部分。该装置3包括指令生成模块31以及指令发送模块32。

指令生成模块31，用于接收客户端的呼叫操作，基于所述呼叫操作生成诊断指令；

指令发送模块32，用于将所述诊断指令发送至服务平台；所述诊断指令用于指示所述服务平台建立与所述客户端的短连接，并基于所述短连接向所述客户端返回埋点诊断信息对应的远程诊断结果，所述埋点诊断信息为所述客户端的所述埋点诊断信息。

可选的，如图21所示，所述指令生成模块31，包括：

信息获取单元311，用于获取所述呼叫操作对应的故障信息，基于所述故障信息确定针对所述客户端的诊断项目信息；

指令生成单元312，用于生成携带所述诊断项目信息的诊断指令，所述诊断项目信息用于所述服务平台对所述埋点诊断信息进行远程诊断，生成远程诊断结果。

可选的，如图22所示，所述装置3，还包括：

验证码接收模块33，用于接收所述服务平台发送的诊断验证码，所述诊断验证码为所述服务平台基于所述诊断指令生成；

验证码发送模块34，用于向所述客户端输出所述诊断验证码，所述诊断验证码用于指示所述客户端生成包含所述诊断验证码的通信诊断请求并发送至所述服务平台；所述通信诊断请求用于指示所述服务平台基于所述通信诊断请求建立与所述客户端的短连接。

可选的，如图22所示，所述装置3，还包括：

结果接收模块35，用于接收所述服务平台发送的远程诊断结果，所述远程诊断结果基于所述埋点诊断信息生成；

结果输出模块36，用于向所述客户端输出所述远程诊断结果。

可选的，所述结果输出模块36，具体用于：

以音频播报的方式向所述客户端输出所述远程诊断结果。

需要说明的是，上述实施例提供的远程诊断装置在执行远程诊断方法时，仅以上述各功能模块的划分进行举例说明，实际应用中，可以根据需要而将上述功能分配由不同的功能模块完成，即将设备的内部结构划分成不同的功能模块，以完成以上描述的全部或者部分功能。另外，上述实施例提供的远程诊断装置与远程诊断方法实施例属于同一构思，其体现实现过程详见方法实施例，这里不再赘述。

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

在本申请实施例中，客服端接收到客户端的呼叫操作，可以基于所述呼叫操作生成诊断指令，然后将所述诊断指令发送至服务平台。服务平台就可以根据诊断指令确定客户端接收到用户所输入的诊断操作，从而可以建立与所述客户端的短连接，然后基于短连接获取所述客户端的埋点诊断信息，基于所述埋点诊断信息返回的远程诊断结果之客户端即可完成整个远程诊断过程。在整个远程诊断过程中，只需要客户端建立与服务平台的短连接，基于诊断开销较小的短连接，通过上传用于远程诊断的埋点诊断信息就可以实现服务平台对客户端的远程诊断，无需客户端与服务平台建立双向长连接，降低远程诊断时的资源开销；以及，服务平台在同时远程诊断多个客户端时，采用上述方式，可以兼容远程诊断业务高并发量的诊断需求，进而提升了远程诊断的容灾性能；以及，客户端在远程诊断时，可以基于服务平台的诊断验证码建立与服务平台的短连接，连接建立更便捷，基于诊断验证码可以快速实现连接建立前的鉴权验证过程，保障了远程诊断过程的诊断安全；以及，将客服端纳入到远程诊断中，客户端可以借助于客服端实现诊断验证码和/或诊断结果的获取，提升远程诊断的便捷性，以及智能性。

本申请实施例还提供了一种计算机存储介质，所述计算机存储介质可以存储有多条指令，所述指令适于由处理器加载并执行如上述图1-图11所示实施例的所述远程诊断方法，具体执行过程可以参见图1-图11所示实施例的具体说明，在此不进行赘述。

本申请还提供了一种计算机程序产品，该计算机程序产品存储有至少一条指令，所述至少一条指令由所述处理器加载并执行如上述图1-图11所示实施例的所述远程诊断方法，具体执行过程可以参见图1-图11所示实施例的具体说明，在此不进行赘述。

请参见图23，为本申请实施例提供了一种电子设备的结构示意图。如图23所示，所述电子设备1000可以包括：至少一个处理器1001，至少一个网络接口1004，用户接口1003，存储器1005，至少一个通信总线1002。

其中，通信总线1002用于实现这些组件之间的连接通信。

其中，用户接口1003可以包括显示屏(display)、摄像头(camera)，可选用户接口1003还可以包括标准的有线接口、无线接口。

其中，网络接口1004可选的可以包括标准的有线接口、无线接口(如wi-fi接口)。

其中，处理器1001可以包括一个或者多个处理核心。处理器1001利用各种借口和线路连接整个服务器1000内的各个部分，通过运行或执行存储在存储器1005内的指令、程序、代码集或指令集，以及调用存储在存储器1005内的数据，执行服务器1000的各种功能和处理数据。可选的，处理器1001可以采用数字信号处理(digitalsignalprocessing，dsp)、现场可编程门阵列(field-programmablegatearray，fpga)、可编程逻辑阵列(programmablelogicarray，pla)中的至少一种硬件形式来实现。处理器1001可集成中央处理器(centralprocessingunit，cpu)、图像处理器(graphicsprocessingunit，gpu)和调制解调器等中的一种或几种的组合。其中，cpu主要处理操作系统、用户界面和应用程序等；gpu用于负责显示屏所需要显示的内容的渲染和绘制；调制解调器用于处理无线通信。可以理解的是，上述调制解调器也可以不集成到处理器1001中，单独通过一块芯片进行实现。

其中，存储器1005可以包括随机存储器(randomaccessmemory，ram)，也可以包括只读存储器(read-onlymemory)。可选的，该存储器1005包括非瞬时性计算机可读介质(non-transitorycomputer-readablestoragemedium)。存储器1005可用于存储指令、程序、代码、代码集或指令集。存储器1005可包括存储程序区和存储数据区，其中，存储程序区可存储用于实现操作系统的指令、用于至少一个功能的指令(比如触控功能、声音播放功能、图像播放功能等)、用于实现上述各个方法实施例的指令等；存储数据区可存储上面各个方法实施例中涉及到的数据等。存储器1005可选的还可以是至少一个位于远离前述处理器1001的存储装置。如图23所示，作为一种计算机存储介质的存储器1005中可以包括操作系统、网络通信模块、用户接口模块以及远程诊断应用程序。

在图23所示的电子设备1000中，用户接口1003主要用于为用户提供输入的接口，获取用户输入的数据；而处理器1001可以用于调用存储器1005中存储的远程诊断应用程序，并具体执行以下操作：

在客户端接收到所输入的诊断操作时，建立与所述客户端的短连接；

基于所述短连接，获取所述客户端的埋点诊断信息；

基于所述埋点诊断信息向所述客户端返回远程诊断结果。

在一个实施例中，所述处理器1001在执行所述在客户端接收到所输入的诊断操作时，建立与所述客户端的短连接时，具体执行以下步骤：

接收客服端的诊断指令，确定所述客户端发起诊断操作，所述诊断指令为所述客服端基于所述客户端所输入的呼叫操作生成；

生成第一诊断验证码，基于所述第一诊断验证码建立与所述客服端的短连接。

在一个实施例中，所述处理器1001在执行所述基于所述第一诊断验证码建立与所述客服端的短连接时，具体执行以下步骤：

向所述客服端发送第一诊断验证码，接收所述客户端发送的携带第二诊断验证码的通信诊断请求，所述通信诊断请求基于所述第一诊断验证码生成；

基于所述第二诊断验证码以及所述第一诊断验证码，建立与所述客服端的短连接。

在一个实施例中，所述处理器1001在执行所述向所述客服端发送第一诊断验证码，接收所述客户端发送的携带第二诊断验证码的通信诊断请求时，具体执行以下步骤：

向所述客服端发送第一诊断验证码，所述第一诊断验证码用于指示所述客服端向所述客户端输出所述第一诊断验证码；

基于交互应用接收所述客户端发送的携带第二诊断验证码的通信诊断请求，所述交互应用为与所述客户端交互的客户端应用。

在一个实施例中，所述处理器1001在执行所述向所述客服端发送第一诊断验证码，接收所述客户端发送的携带第二诊断验证码的通信诊断请求时，具体执行以下步骤：

向所述客户端发送第一诊断验证码；

基于所述交互应用接收所述客户端生成的携带第二诊断验证码的通信诊断请求，所述交互应用为与所述客户端交互的客户端应用。

在一个实施例中，所述处理器1001在执行所述对基于所述第二诊断验证码以及所述第一诊断验证码，建立与所述客服端的短连接时，具体执行以下步骤：

判断所述第二诊断验证码与所述第一诊断验证码是否匹配；

当所述第二诊断验证码与所述第一诊断验证码匹配时，通过所述交互应用向所述客户端发送验证通过信息；所述验证通过信息用于建立与所述客户端的所述短连接。

在一个实施例中，所述处理器1001在执行所述判断所述第一诊断验证码与所述第二诊断验证码是否匹配之后，还执行以下步骤：

当所述第二诊断验证码与所述第一诊断验证码不匹配时，通过所述交互应用向所述客户端发送验证失败信息，所述验证失败信息用于指示所述客户端重新建立所述短连接。

在一个实施例中，所述处理器1001在执行所述基于所述短连接，获取所述客户端的埋点诊断信息时，具体执行以下步骤：

基于所述短连接接收所述客户端发送的埋点诊断信息；

或，

基于所述短连接接收所述客户端发送的云端服务器的地址信息，所述云端服务器用于存储所述客户端的所述埋点诊断信息；向所述云端服务器下载所述埋点诊断信息。

在一个实施例中，所述处理器1001在执行所述基于所述埋点诊断信息向所述客户端返回远程诊断结果，具体执行以下步骤：

基于所述埋点诊断信息生成针对所述客户端的远程诊断结果，向所述客服端发送所述远程诊断结果，所述远程诊断结果用于指示所述客服端向所述客服端输出所述远程诊断结果；

或，

基于所述埋点诊断信息生成针对所述客户端的所述远程诊断结果，将所述远程诊断结果发送至所述客户端。

在一个实施例中，所述处理器1001在执行所述基于所述埋点诊断信息向所述客户端返回远程诊断结果时，具体执行以下步骤：

获取所述诊断指令携带的诊断项目信息，基于所述诊断项目信息对所述埋点诊断信息进行远程诊断，生成远程诊断结果；

向所述客户端返回远程诊断结果。

在本申请实施例中，服务平台确定客户端接收到用户所输入的诊断操作时，可以建立与所述客户端的短连接，然后基于短连接获取所述客户端的埋点诊断信息，基于所述埋点诊断信息返回的远程诊断结果之客户端即可完成整个远程诊断过程。在整个远程诊断过程中，只需要客户端建立与服务平台的短连接，基于诊断开销较小的短连接，通过上传用于远程诊断的埋点诊断信息就可以实现服务平台对客户端的远程诊断，无需客户端与服务平台建立双向长连接，降低远程诊断时的资源开销；以及，服务平台在同时远程诊断多个客户端时，采用上述方式，可以兼容远程诊断业务高并发量的诊断需求，进而提升了远程诊断的容灾性能；以及，客户端在远程诊断时，可以基于服务平台的诊断验证码建立与服务平台的短连接，连接建立更便捷，基于诊断验证码可以快速实现连接建立前的鉴权验证过程，保障了远程诊断过程的诊断安全；以及，将客服端纳入到远程诊断中，客户端可以借助于客服端实现诊断验证码和/或诊断结果的获取，提升远程诊断的便捷性，以及智能性。

请参见图24，为本申请实施例提供了另一种电子设备的结构示意图。如图24所示，所述电子设备2000可以包括：至少一个处理器2001，至少一个网络接口2004，用户接口2003，存储器2005，至少一个通信总线2002。

其中，通信总线2002用于实现这些组件之间的连接通信。

其中，用户接口2003可以包括显示屏(display)，可选用户接口2003还可以包括标准的有线接口、无线接口。

其中，网络接口2004可选的可以包括标准的有线接口、无线接口(如wi-fi接口)。

其中，处理器2001可以包括一个或者多个处理核心。处理器2001利用各种借口和线路连接整个服务器2000内的各个部分，通过运行或执行存储在存储器2005内的指令、程序、代码集或指令集，以及调用存储在存储器2005内的数据，执行服务器2000的各种功能和处理数据。可选的，处理器2001可以采用数字信号处理(digitalsignalprocessing，dsp)、现场可编程门阵列(field-programmablegatearray，fpga)、可编程逻辑阵列(programmablelogicarray，pla)中的至少一种硬件形式来实现。处理器2001可集成中央处理器(centralprocessingunit，cpu)、图像处理器(graphicsprocessingunit，gpu)和调制解调器等中的一种或几种的组合。其中，cpu主要处理操作系统、用户界面和应用程序等；gpu用于负责显示屏所需要显示的内容的渲染和绘制；调制解调器用于处理无线通信。可以理解的是，上述调制解调器也可以不集成到处理器2001中，单独通过一块芯片进行实现。

其中，存储器2005可以包括随机存储器(randomaccessmemory，ram)，也可以包括只读存储器(read-onlymemory)。可选的，该存储器2005包括非瞬时性计算机可读介质(non-transitorycomputer-readablestoragemedium)。存储器2005可用于存储指令、程序、代码、代码集或指令集。存储器1005可包括存储程序区和存储数据区，其中，存储程序区可存储用于实现操作系统的指令、用于至少一个功能的指令(比如触控功能、声音播放功能、图像播放功能等)、用于实现上述各个方法实施例的指令等；存储数据区可存储上面各个方法实施例中涉及到的数据等。存储器2005可选的还可以是至少一个位于远离前述处理器2001的存储装置。如图24所示，作为一种计算机存储介质的存储器2005中可以包括操作系统、网络通信模块、用户接口模块以及远程诊断应用程序。

在图24所示的电子设备2000中，用户接口2003主要用于为用户提供输入的接口，获取用户输入的数据；而处理器2001可以用于调用存储器2005中存储的远程诊断应用程序，并具体执行以下操作：

接收客户端的呼叫操作，基于所述呼叫操作生成诊断指令；

将所述诊断指令发送至服务平台；所述诊断指令用于指示所述服务平台建立与所述客户端的短连接，并基于所述短连接向所述客户端返回埋点诊断信息对应的远程诊断结果，所述埋点诊断信息为所述客户端的所述埋点诊断信息。

在一个实施例中，所述处理器2001在执行所述基于所述呼叫操作生成诊断指令时，具体执行以下操作：

获取所述呼叫操作对应的故障信息，基于所述故障信息确定针对所述客户端的诊断项目信息；

生成携带所述诊断项目信息的诊断指令，所述诊断项目信息用于所述服务平台对所述埋点诊断信息进行远程诊断，生成远程诊断结果。

在一个实施例中，所述处理器2001在执行所述将所述诊断指令发送至服务平台之后，还执行以下操作：

接收所述服务平台发送的诊断验证码，所述诊断验证码为所述服务平台基于所述诊断指令生成；

向所述客户端输出所述诊断验证码，所述诊断验证码用于指示所述客户端生成包含所述诊断验证码的通信诊断请求并发送至所述服务平台；所述通信诊断请求用于指示所述服务平台基于所述通信诊断请求建立与所述客户端的短连接。

在一个实施例中，所述处理器2001在执行所述远程诊断验证码时，还执行以下操作：

接收所述服务平台发送的远程诊断结果，所述远程诊断结果基于所述埋点诊断信息生成；

向所述客户端输出所述远程诊断结果。

在一个实施例中，所述处理器2001在执行所述向所述客户端输出所述远程诊断结果时，还执行以下操作：

以音频播报的方式向所述客户端输出所述远程诊断结果。

在本申请实施例中，客服端接收到客户端的呼叫操作，可以基于所述呼叫操作生成诊断指令，然后将所述诊断指令发送至服务平台。服务平台就可以根据诊断指令确定客户端接收到用户所输入的诊断操作，从而可以建立与所述客户端的短连接，然后基于短连接获取所述客户端的埋点诊断信息，基于所述埋点诊断信息返回的远程诊断结果之客户端即可完成整个远程诊断过程。在整个远程诊断过程中，只需要客户端建立与服务平台的短连接，基于诊断开销较小的短连接，通过上传用于远程诊断的埋点诊断信息就可以实现服务平台对客户端的远程诊断，无需客户端与服务平台建立双向长连接，降低远程诊断时的资源开销；以及，服务平台在同时远程诊断多个客户端时，采用上述方式，可以兼容远程诊断业务高并发量的诊断需求，进而提升了远程诊断的容灾性能；以及，客户端在远程诊断时，可以基于服务平台的诊断验证码建立与服务平台的短连接，连接建立更便捷，基于诊断验证码可以快速实现连接建立前的鉴权验证过程，保障了远程诊断过程的诊断安全；以及，将客服端纳入到远程诊断中，客户端可以借助于客服端实现诊断验证码和/或诊断结果的获取，提升远程诊断的便捷性，以及智能性。

请参考图25，其示出了本申请一个示例性实施例提供的电子设备的结构方框图。本申请中的电子设备可以包括一个或多个如下部件：处理器110、存储器120、输入装置130、输出装置140和总线150。处理器110、存储器120、输入装置130和输出装置140之间可以通过总线150连接。

处理器110可以包括一个或者多个处理核心。处理器110利用各种接口和线路连接整个电子设备内的各个部分，通过运行或执行存储在存储器120内的指令、程序、代码集或指令集，以及调用存储在存储器120内的数据，执行电子设备100的各种功能和处理数据。可选地，处理器110可以采用数字信号处理(digitalsignalprocessing，dsp)、现场可编程门阵列(field－programmablegatearray，fpga)、可编程逻辑阵列(programmablelogicarray，pla)中的至少一种硬件形式来实现。处理器110可集成中央处理器(centralprocessingunit，cpu)、图像处理器(graphicsprocessingunit，gpu)和调制解调器等中的一种或几种的组合。其中，cpu主要处理操作系统、用户界面和应用程序等；gpu用于负责显示内容的渲染和绘制；调制解调器用于处理无线通信。可以理解的是，上述调制解调器也可以不集成到处理器110中，单独通过一块通信芯片进行实现。

存储器120可以包括随机存储器(randomaccessmemory，ram)，也可以包括只读存储器(read-onlymemory，rom)。可选地，该存储器120包括非瞬时性计算机可读介质(non-transitorycomputer-readablestoragemedium)。存储器120可用于存储指令、程序、代码、代码集或指令集。存储器120可包括存储程序区和存储数据区，其中，存储程序区可存储用于实现操作系统的指令、用于实现至少一个功能的指令(比如触控功能、声音播放功能、图像播放功能等)、用于实现下述各个方法实施例的指令等，该操作系统可以是安卓(android)系统，包括基于android系统深度开发的系统、苹果公司开发的ios系统，包括基于ios系统深度开发的系统或其它系统。存储数据区还可以存储电子设备在使用中所创建的数据比如电话本、音视频数据、聊天记录数据，等。

参见图26所示，存储器120可分为操作系统空间和用户空间，操作系统即运行于操作系统空间，原生及第三方应用程序即运行于用户空间。为了保证不同第三方应用程序均能够达到较好的运行效果，操作系统针对不同第三方应用程序为其分配相应的系统资源。然而，同一第三方应用程序中不同应用场景对系统资源的需求也存在差异，比如，在本地资源加载场景下，第三方应用程序对磁盘读取速度的要求较高；在动画渲染场景下，第三方应用程序则对gpu性能的要求较高。而操作系统与第三方应用程序之间相互独立，操作系统往往不能及时感知第三方应用程序当前的应用场景，导致操作系统无法根据第三方应用程序的具体应用场景进行针对性的系统资源适配。

为了使操作系统能够区分第三方应用程序的具体应用场景，需要打通第三方应用程序与操作系统之的数据通信，使得操作系统能够随时获取第三方应用程序当前的场景信息，进而基于当前场景进行针对性的系统资源适配。

以操作系统为android系统为例，存储器120中存储的程序和数据如图27所示，存储器120中可存储有linux内核层320、系统运行时库层340、应用框架层360和应用层380，其中，linux内核层320、系统运行库层340和应用框架层360属于操作系统空间，应用层380属于用户空间。linux内核层320为电子设备的各种硬件提供了底层的驱动，如显示驱动、音频驱动、摄像头驱动、蓝牙驱动、wi-fi驱动、电源管理等。系统运行库层340通过一些c/c++库来为android系统提供了主要的特性支持。如sqlite库提供了数据库的支持，opengl/es库提供了3d绘图的支持，webkit库提供了浏览器内核的支持等。在系统运行时库层340中还提供有安卓运行时库(androidruntime)，它主要提供了一些核心库，能够允许开发者使用java语言来编写android应用。应用框架层360提供了构建应用程序时可能用到的各种api，开发者也可以通过使用这些api来构建自己的应用程序，比如活动管理、窗口管理、视图管理、通知管理、内容提供者、包管理、通话管理、资源管理、定位管理。应用层380中运行有至少一个应用程序，这些应用程序可以是操作系统自带的原生应用程序，比如联系人程序、短信程序、时钟程序、相机应用等；也可以是第三方开发者所开发的第三方应用程序，比如游戏类应用程序、即时通信程序、相片美化程序、远程诊断程序等。

以操作系统为ios系统为例，存储器120中存储的程序和数据如图28所示，ios系统包括：核心操作系统层420(coreoslayer)、核心服务层440(coreserviceslayer)、媒体层460(medialayer)、可触摸层480(cocoatouchlayer)。核心操作系统层420包括了操作系统内核、驱动程序以及底层程序框架，这些底层程序框架提供更接近硬件的功能，以供位于核心服务层440的程序框架所使用。核心服务层440提供给应用程序所需要的系统服务和/或程序框架，比如基础(foundation)框架、账户框架、广告框架、数据存储框架、网络连接框架、地理位置框架、运动框架等等。媒体层460为应用程序提供有关视听方面的接口，如图形图像相关的接口、音频技术相关的接口、视频技术相关的接口、音视频传输技术的无线播放(airplay)接口等。可触摸层480为应用程序开发提供了各种常用的界面相关的框架，可触摸层480负责用户在电子设备上的触摸交互操作。比如本地通知服务、远程推送服务、广告框架、游戏工具框架、消息用户界面接口(userinterface，ui)框架、用户界面uikit框架、地图框架等等。

在图28所示出的框架中，与大部分应用程序有关的框架包括但不限于：核心服务层440中的基础框架和可触摸层480中的uikit框架。基础框架提供许多基本的对象类和数据类型，为所有应用程序提供最基本的系统服务，和ui无关。而uikit框架提供的类是基础的ui类库，用于创建基于触摸的用户界面，ios应用程序可以基于uikit框架来提供ui，所以它提供了应用程序的基础架构，用于构建用户界面，绘图、处理和用户交互事件，响应手势等等。

其中，在ios系统中实现第三方应用程序与操作系统数据通信的方式以及原理可参考android系统，本申请在此不再赘述。

其中，输入装置130用于接收输入的指令或数据，输入装置130包括但不限于键盘、鼠标、摄像头、麦克风或触控设备。输出装置140用于输出指令或数据，输出装置140包括但不限于显示设备和扬声器等。在一个示例中，输入装置130和输出装置140可以合设，输入装置130和输出装置140为触摸显示屏，该触摸显示屏用于接收用户使用手指、触摸笔等任何适合的物体在其上或附近的触摸操作，以及显示各个应用程序的用户界面。触摸显示屏通常设置在电子设备的前面板。触摸显示屏可被设计成为全面屏、曲面屏或异型屏。触摸显示屏还可被设计成为全面屏与曲面屏的结合，异型屏与曲面屏的结合，本申请实施例对此不加以限定。

除此之外，本领域技术人员可以理解，上述附图所示出的电子设备的结构并不构成对电子设备的限定，电子设备可以包括比图示更多或更少的部件，或者组合某些部件，或者不同的部件布置。比如，电子设备中还包括射频电路、输入单元、传感器、音频电路、无线保真(wirelessfidelity，wifi)模块、电源、蓝牙模块等部件，在此不再赘述。

在本申请实施例中，各步骤的执行主体可以是上文介绍的电子设备。可选地，各步骤的执行主体为电子设备的操作系统。操作系统可以是安卓系统，也可以是ios系统，或者其它操作系统，本申请实施例对此不作限定。

本申请实施例的电子设备，其上还可以安装有显示设备，显示设备可以是各种能实现显示功能的设备，例如：阴极射线管显示器(cathoderaytubedisplay，简称cr)、发光二极管显示器(light-emittingdiodedisplay，简称led)、电子墨水屏、液晶显示屏(liquidcrystaldisplay，简称lcd)、等离子显示面板(plasmadisplaypanel，简称pdp)等。用户可以利用电子设备101上的显示设备，来查看显示的文字、图像、视频等信息。所述电子设备可以是智能手机、平板电脑、游戏设备、ar(augmentedreality，增强现实)设备、汽车、数据存储装置、音频播放装置、视频播放装置、笔记本、桌面计算设备、可穿戴设备诸如电子手表、电子眼镜、电子头盔、电子手链、电子项链、电子衣物等设备。

在图25所示的电子设备中，处理器110可以用于调用存储器120中存储的远程诊断应用程序，并具体执行以下操作：

接收所输入的诊断操作，建立与服务平台的短连接；

获取所述客户端的埋点诊断信息，基于所述短连接向所述服务平台发送所述埋点诊断信息；

接收所述服务平台基于所述埋点诊断信息返回的远程诊断结果。

在一个实施例中，所述处理器110在执行所述接收所输入的诊断操作，建立与服务平台的短连接时，具体执行以下步骤：

接收所输入的诊断操作，向所述服务平台获取诊断验证码；

基于所述诊断验证码建立与服务平台的短连接。

在一个实施例中，所述处理器110在执行所述接收所输入的诊断操作，向所述服务平台获取诊断验证码时，具体执行以下步骤：

接收向客服端输入的呼叫操作，所述呼叫操作用于所述客服端指示所述服务平台生成诊断验证码；

接收所述服务平台发送的所述诊断验证码。

在一个实施例中，所述处理器110在执行所述接收所输入的诊断操作，向所述服务平台获取诊断验证码时，具体执行以下步骤：

接收向所述客服端输入的呼叫操作，所述呼叫操作用于所述客服端指示所述服务平台生成诊断验证码；

获取所述客服端输出的所述诊断验证码，所述诊断验证码由所述服务平台发送至所述客服端。

在一个实施例中，所述处理器110在执行所述基于所述诊断验证码建立与服务平台的短连接时，具体执行以下步骤：

生成包含所述诊断验证码的通信诊断请求，将所述通信诊断请求发送至所述服务平台，所述通信诊断请求用于指示所述服务平台对所述诊断验证码进行连接验证；

接收所述服务平台发送的验证通过信息，建立与所述服务平台的短连接。

在一个实施例中，所述处理器110在执行所述生成包含所述诊断验证码的通信诊断请求时，具体执行以下步骤：

启动交互应用，检测到在所述交互应用中输入的所述诊断验证码，生成包含所述诊断验证码的通信诊断请求，所述交互应用为与所述服务平台交互的客户端应用。

在一个实施例中，所述处理器110在执行所述将所述通信诊断请求发送至所述服务平台，所述通信诊断请求用于指示所述服务平台对所述诊断验证码进行连接验证之后，还执行以下步骤：

接收所述服务平台发送的验证失败信息，重新建立与所述服务平台的所述短连接。

在一个实施例中，所述处理器110在执行所述基于所述短连接向所述服务平台发送所述埋点诊断信息时，具体执行以下步骤：

向云端服务器上传所述埋点诊断信息，基于所述短连接向所述服务平台发送所述云端服务器对应的地址信息，所述地址信息用于指示所述服务平台从所述云端服务器下载所述埋点诊断信息。

在一个实施例中，所述处理器110在执行所述接收所述服务平台基于所述埋点诊断信息返回的远程诊断结果时，具体执行以下步骤：

接收所述客服端输出的远程诊断结果，所述远程诊断结果由所述服务平台发送至所述客服端。

在本申请实施例中，客户端可以接收用户所输入的诊断操作，从而建立与服务平台的短连接，然后获取所述客户端的埋点诊断信息，基于短连接向所述服务平台发送所述埋点诊断信息；客户端只需接收所述服务平台基于所述埋点诊断信息返回的远程诊断结果即可完成这个远程诊断过程。在整个远程诊断过程中，只需要客户端建立与服务平台的短连接，基于诊断开销较小的短连接，通过上传用于远程诊断的埋点诊断信息就可以实现服务平台对客户端的远程诊断，无需客户端与服务平台建立双向长连接，降低远程诊断时的资源开销；以及，服务平台在同时远程诊断多个客户端时，采用上述方式，可以兼容远程诊断业务高并发量的诊断需求，进而提升了远程诊断的容灾性能；以及，客户端在远程诊断时，可以基于服务平台的诊断验证码建立与服务平台的短连接，连接建立更便捷，基于诊断验证码可以快速实现连接建立前的鉴权验证过程，保障了远程诊断过程的诊断安全；以及，将客服端纳入到远程诊断中，客户端可以借助于客服端实现诊断验证码和/或诊断结果的获取，提升远程诊断的便捷性，以及智能性。

本领域的技术人员可以清楚地了解到本申请的技术方案可借助软件和/或硬件来实现。本说明书中的“单元”和“模块”是指能够独立完成或与其他部件配合完成特定功能的软件和/或硬件，其中硬件例如可以是现场可编程门阵列(field－programmablegatearray，fpga)、集成电路(integratedcircuit，ic)等。

以上所述者，仅为本公开的示例性实施例，不能以此限定本公开的范围。即但凡依本公开教导所作的等效变化与修饰，皆仍属本公开涵盖的范围内。本领域技术人员在考虑说明书及实践这里的公开后，将容易想到本公开的其它实施方案。本申请旨在涵盖本公开的任何变型、用途或者适应性变化，这些变型、用途或者适应性变化遵循本公开的一般性原理并包括本公开未记载的本技术领域中的公知常识或惯用技术手段。说明书和实施例仅被视为示例性的，本公开的范围和精神由权利要求限定。