CN106951347B

CN106951347B - Online diagnosis method and online diagnosis device

Info

Publication number: CN106951347B
Application number: CN201610014022.2A
Authority: CN
Inventors: 杨龙; 张德顺; 林宇; 曾树奇
Original assignee: Alibaba China Co Ltd
Current assignee: Alibaba China Co Ltd
Priority date: 2016-01-06
Filing date: 2016-01-06
Publication date: 2020-08-25
Anticipated expiration: 2036-01-06
Also published as: CN106951347A

Abstract

The embodiment of the invention provides an online diagnosis method and an online diagnosis device for diagnosing or solving online problems. According to the embodiment of the invention, when the server side receives the on-line problem fed back by the client side, the server side generates the identification code for the client side to identify. And after identifying the information of the identification code, the client sends a diagnosis request to the server to activate a diagnosis process. And the server returns a diagnosis instruction to the client after receiving the diagnosis request, and the client executes corresponding action according to the diagnosis instruction to complete the online diagnosis process of the online problem. The method can improve the efficiency and range of solving the online problem and enhance the user experience when the user encounters the online problem.

Description

Online diagnosis method and online diagnosis device

Technical Field

The invention relates to the technical field of diagnosis and solution of online problems of application programs, in particular to an online diagnosis method and an online diagnosis device of online problems.

Background

Currently, with the development of computer technology and electronic technology, clients such as smart phones, Mobile Internet Devices (MIDs), Personal Digital Assistants (PDAs), tablet computers, and the like have become indispensable communication and entertainment tools in daily work and life of people. Many clients support custom installation of various applications (apps) by users to meet different user requirements. When the client uses an application program (such as a browser), some online problems may occur, such as file damage or data loss. It has been a complex and troublesome task for the server side to provide these applications to deal with the on-line problem.

In general, the on-line problem is divided into two categories. The first is a simple, consistently reproducible problem that is relatively easy to reproduce and handle. The second problem is related to the specific environment of the user, such as the model, resolution, whether the operating system is out of jail, or other problems that cannot be reproduced stably, and problems caused by specific use states, such as damage to bookmark files, damage to video index files, and the like. In these cases, if the problem is not reproducible, the chance of it being solved is greatly reduced. The current processing method for such a situation generally extracts relevant documents (such as database files, state files, etc.) of the user, and then the developer analyzes or debugs the data, so as to trace the problem. The specific method is to guide a user to use a third-party mobile phone assistant to guide the user to extract a possibly useful document, and then the document is returned through a network, and a test or research and development staff analyzes or debugs the document. The processing method is very troublesome and inconvenient, and requires a user to install a third-party mobile phone assistant on a computer and simultaneously go deep into a file system to export the required files. In addition, the above processing method cannot obtain some memory states of the application program during operation, and it is not easy to grasp the real "scene" of the user.

Another problem to be noted is that there is no effective means to repair the problem of the user in time and quickly at present, and even if the problem is finally known and solved, the user needs to wait until the next version is released and reinstall the application program of the new version to solve the problem, which brings huge repair cost and is a great test for the patience of the user.

Disclosure of Invention

In view of the above, the embodiment of the present invention provides an online diagnosis method, which is applied to a server and a client that are communicatively connected to each other. The online diagnosis method comprises the following steps:

the server receives the on-line problem fed back by the client;

the server side records the identification number of the client side and the problem description of the online problem into a database;

the server side writes an instruction to be executed by the client side into the database;

the server generates an identification code according to the online problem and the identification number of the client, sends the identification code to the client and prompts the client to identify the identification code;

the client identifies the identification code to obtain the information included by the identification code, and judges whether the information included by the identification code is matched with the self identification number of the client;

when the information included in the identification code is matched with the identification number of the client, the client sends a diagnosis request to the server;

the server side returns a diagnosis instruction corresponding to the online problem to the client side; and

the client receives the instruction returned by the server and executes corresponding action according to the instruction so as to solve the online problem.

Another preferred embodiment of the present invention provides an online diagnosis apparatus, which is applied to a server communicatively connected to a client. The online diagnosis apparatus includes:

the problem receiving module is used for receiving the on-line problem fed back by the client;

the information input module is used for inputting the identification number of the client and the problem description of the online problem into a database;

the instruction writing module is used for writing the diagnosis instruction which needs to be executed by the client into the database;

the identification code generating module is used for generating an identification code according to the online problem and the identification number of the client, sending the identification code to the client and prompting the client to identify the identification code; and

and the instruction sending module is used for sending a diagnosis instruction corresponding to the online problem to the client when the client identifies the identification code and returns a diagnosis request to the server, and the client executes corresponding action according to the diagnosis instruction so as to solve the online problem.

The present invention provides another online diagnosis apparatus, which is applied to a client communicatively connected to a server. The another online diagnosis apparatus includes:

the identification module is used for identifying an identification code sent by the server after receiving the on-line problem fed back by the client to obtain information included in the identification code;

a matching module; the system is used for judging whether the information included in the identification code is matched with the identification number of the client;

the request module is used for sending a diagnosis request to the server side when the information contained in the identification code is matched with the identification number of the client side; and

and the execution module is used for receiving the diagnosis instruction returned by the server after receiving the diagnosis request and executing corresponding action according to the diagnosis instruction so as to finish the online diagnosis of the online problem.

Compared with the prior art, according to the online diagnosis method and the online diagnosis device for the online problem, which are provided by the preferred embodiment of the invention, the server side activates the online diagnosis process for the client side by generating the identification code, so that the uploading, downloading and repairing of the diagnosis information are completed, the help of a third-party software assistant is not needed, the user does not need to go deep into the file structure of the application program, the solution efficiency and range of the online problem are improved, and the user experience of the user when the online problem is encountered is improved.

In order to make the aforementioned and other objects, features and advantages of the present invention comprehensible, preferred embodiments accompanied with figures are described in detail below.

Drawings

In order to more clearly illustrate the technical solutions of the embodiments of the present invention, the drawings needed to be used in the embodiments will be briefly described below, it should be understood that the following drawings only illustrate some embodiments of the present invention and therefore should not be considered as limiting the scope, and for those skilled in the art, other related drawings can be obtained according to the drawings without inventive efforts.

Fig. 1 is an interaction diagram of a server communicating with at least one client according to a preferred embodiment of the present invention.

Fig. 2 is a block schematic diagram of the server shown in fig. 1.

Fig. 3 is a block schematic diagram of the client shown in fig. 1.

Fig. 4 is a flowchart of an online diagnosis method applied to the server and the client shown in fig. 1 according to a preferred embodiment of the present invention.

Fig. 5 is a schematic diagram of a dialog box for prompting a user whether to approve of entering a diagnostic flow.

Fig. 6 is a schematic diagram of a dialog box for prompting a user whether to approve downloading a file to a client.

Fig. 7 is a functional block diagram of a first online diagnosis device of the server shown in fig. 2 according to a preferred embodiment of the present invention.

Fig. 8 is a functional block diagram of a second online diagnosis apparatus of the client shown in fig. 3 according to a preferred embodiment of the present invention.

Description of the main elements

Detailed Description

The technical solutions in the embodiments of the present invention will be clearly and completely described below with reference to the drawings in the embodiments of the present invention, and it is obvious that the described embodiments are only a part of the embodiments of the present invention, and not all of the embodiments. The components of embodiments of the present invention generally described and illustrated in the figures herein may be arranged and designed in a wide variety of different configurations. Thus, the following detailed description of the embodiments of the present invention, presented in the figures, is not intended to limit the scope of the invention, as claimed, but is merely representative of selected embodiments of the invention. All other embodiments, which can be derived by a person skilled in the art from the embodiments of the present invention without making any creative effort, shall fall within the protection scope of the present invention.

It should be noted that: like reference numbers and letters refer to like items in the following figures, and thus, once an item is defined in one figure, it need not be further defined and explained in subsequent figures. Meanwhile, in the description of the present invention, the terms "first", "second", and the like are used only for distinguishing the description, and are not to be construed as indicating or implying relative importance.

Fig. 1 is an interaction diagram of a server 100 and at least one client 200 according to a preferred embodiment of the present invention. The server 100 can communicate with the client 200 through the network 300 to realize data communication or interaction between the server 100 and the client 200. The server 100 may provide at least one installation package of Application programs (APPs) 400 suitable for various operating systems for downloading by the client 200. After the client 200 accesses the server 100 through the network 300, the installation package of the application 400 suitable for the operating system of the client 200 may be downloaded from the server 100 through the network 300, so as to install the application 400 into the client 200.

In this embodiment, the server 100 may be, but is not limited to, a web server, an ftp (file transfer protocol) server, and the like. The client 200 may be, but is not limited to, a smart phone, a Personal Computer (PC), a tablet PC, a Personal Digital Assistant (PDA), a Mobile Internet Device (MID), and the like. The network 300 may be, but is not limited to, a wired network or a wireless network. The operating system of the client 200 may be, but is not limited to, an Android system, an ios (internet operating system) system, a Windows system, and the like. Preferably, in this embodiment, the operating system of the client 200 is an IOS system. The application 400 can be any application provided by the server 100 and capable of being downloaded and installed by the client 200 in a customized manner, and preferably, in this embodiment, the application 400 is a Browser application.

Fig. 2 is a block diagram of the server 100 shown in fig. 1. The server 100 includes a first online diagnosis device 110, a first memory 111, a first processor 112, and a first communication unit 113.

The first memory 111, the first processor 112 and the first communication unit 113 are electrically connected to each other directly or indirectly to realize data transmission or interaction. For example, the components may be electrically connected to each other via one or more communication buses or signal lines. The first online diagnostic device 110 includes at least one software function module which can be stored in the first memory 111 in the form of software or firmware (firmware) or is fixed in an Operating System (OS) of the server 100. The first processor 112 is used for executing executable modules stored in the first memory 111, such as software functional modules and computer programs included in the first online diagnostic apparatus 110.

The first Memory 111 may be, but is not limited to, a Random Access Memory (RAM), a Read Only Memory (ROM), a Programmable Read-Only Memory (PROM), an Erasable Read-Only Memory (EPROM), an electrically Erasable Read-Only Memory (EEPROM), and the like. The first memory 111 is used for storing a program, and the first processor 112 executes the program after receiving the execution instruction. The first communication unit 113 is configured to establish a communication connection between the server 100 and the client 200 through the network 300, and is configured to send and receive data through the network 300.

As shown in fig. 3, is a block schematic diagram of the client 200 shown in fig. 1. The client 200 includes a second online diagnosis apparatus 210, a second memory 211, a memory controller 212, a second processor 213, a peripheral interface 214, an input-output unit 215, an audio unit 216, a display unit 217, a radio frequency unit 218, and a second communication unit 219.

The second memory 211, the memory controller 212, the second processor 213, the peripheral interface 214, the input/output unit 215, the audio unit 216, the display unit 217, the radio frequency unit 218, and the second communication unit 219 are electrically connected to each other directly or indirectly to implement data transmission or interaction. For example, the components may be electrically connected to each other via one or more communication buses or signal lines. The second online diagnostic device 210 includes at least one software function module which may be stored in the second memory 211 in the form of software or firmware (firmware) or solidified in an Operating System (OS) of the client 200. The second memory 211 stores the application 400 downloaded and installed from the server 100 by the client 200. The second processor 213 is used for executing executable modules stored in the second memory 211, such as software functional modules and computer programs included in the second online diagnosis device 210.

The second Memory 211 may be, but is not limited to, a Random Access Memory (RAM), a Read Only Memory (ROM), a Programmable Read-Only Memory (PROM), an Erasable Read-Only Memory (EPROM), an electrically Erasable Read-Only Memory (EEPROM), and the like. The second memory 211 is used for storing programs, and the second processor 213 executes the programs after receiving the execution instructions. Access to the second memory 211 by the second processor 213 and possibly other components may be under the control of the memory controller 212.

The second processor 213 may be an integrated circuit chip having signal processing capabilities. The Processor may be a general-purpose Processor, including a Central Processing Unit (CPU), a Network Processor (NP), and the like; but may also be a Digital Signal Processor (DSP)), an Application Specific Integrated Circuit (ASIC), an off-the-shelf programmable gate array (FPGA) or other programmable logic device, discrete gate or transistor logic, discrete hardware components. The various methods, steps and logic blocks disclosed in the embodiments of the present invention may be implemented or performed. A general purpose processor may be a microprocessor or the processor may be any conventional processor or the like.

The peripheral interface 114 couples various input/output devices (e.g., an input/output unit 215, an audio unit 216, a display unit 217, and a radio unit 218) to the second processor 213 and the second memory 211. In some embodiments, the peripheral interface 214, the second processor 213, and the memory controller 212 may be implemented in a single chip. In other examples, they may be implemented separately from the individual chips.

The input/output unit 215 is used for providing input data for a user to realize the interaction of the user with the client 200. The input/output unit 215 may be, but is not limited to, a mouse, a keyboard, and the like.

The audio unit 216 provides an audio interface to the user, which may include one or more microphones, one or more speakers, and audio circuitry.

The display unit 217 provides an interactive interface (e.g., a user operation interface) between the client 200 and a user or is used to display image data. In this embodiment, the display unit 217 may be a liquid crystal display or a touch display. In the case of a touch display, the display can be a capacitive touch screen or a resistive touch screen, which supports single-point and multi-point touch operations. The support of single-point and multi-point touch operations means that the touch display can sense touch operations generated at one or more positions on the touch display and send the sensed touch operations to the processor for calculation and processing.

The rf unit 218 is configured to receive and transmit radio wave signals (e.g., electromagnetic waves), so as to perform interconversion between radio waves and electrical signals, thereby performing wireless communication between the client 200 and the network 300 or other communication devices.

The second communication unit 219 is configured to establish a connection with the first communication unit 113 of the server 100 through the network 300, so as to implement a communication connection between the server 100 and the client 200. For example, the second communication unit 219 may connect to the network 300 by using the radio frequency signal sent by the radio frequency unit 218, and further establish a communication connection with the first communication unit 113 at the service end through the network 300.

Please refer to fig. 4, which is a flowchart illustrating an online diagnosis method applied to the server 100 and the client 200 shown in fig. 1 according to a preferred embodiment of the present invention. The specific process and steps shown in fig. 4 will be described in detail below.

In step S411, the server 100 receives the online problem fed back by the client 200.

In this embodiment, the client 200 may have online problems during the use of the application 400, such as damage to a bookmark file, damage to a video index file, and running errors of a script. When the above problem occurs, the application 400 may provide a feedback interface for the user to feed back the online problem to the server 100. For example, a user feedback interface may pop up on the client 200, so that the user can input information about the online question, such as a question description of the online question, through the feedback interface, and then click to submit the information to be fed back to the server 100.

In step S412, the server 100 records the identification number of the client 200 and the question description of the online question into a database, and sets the status of the online question as an activated status.

Specifically, the database may be pre-established in the first memory 111 for recording relevant information about the on-line problem of the user. The identification number of the client 200 may be sent to the server 100 when the client 200 feeds back the online problem. The identification number of the client 200 refers to a unique device identification number of the client 200. In this embodiment, the identification number of the client 200 includes the device identification number of the client 200 and a unique Serial Number (SN) allocated to the client 200 by the server 100 when the application 400 is installed in the client 200. The device identification number of the client 200 includes, but is not limited to, an International Mobile Equipment Identity (IMEI).

In addition, before the identification number of the client 200 is entered into the database, the server 100 first encrypts the identification number by using an encryption algorithm to ensure data security. Meanwhile, after the question description of the online question is entered into the database, the database automatically generates a question ID (identifier) of the online question, which is used for identifying the online question. The encryption algorithm may be, but is not limited to, MD5(Message-DigestAlgorithm 5, version 5 of the Message digest algorithm).

In step S413, the server 100 writes the diagnosis instruction to be executed by the client 200 into the database.

Specifically, in this embodiment, the server 100 writes various types of diagnostic instructions that need to be executed by the client 200 into the database according to the types of online problems that the client 200 may feedback. The diagnosis instruction to be executed by the client 200 may be roughly classified into an instruction to upload a file, an instruction to download a file, and an instruction to download an executable script file according to the type of the online problem. The script file is preferably a Lua script file. The final implementation form of the diagnosis instruction is identified by json (JavaScript Object Notation) format.

For example, the instruction to upload a file is as follows:

the "up" instruction indicates that the client 200 is required to upload a file or folder with a path.

The instructions to download the file are as follows:

wherein, the down instruction indicates that the client 200 is required to download a file or lua script file with a specified name from the server 100 via a specified path.

In step S414, the server 100 generates an identification code according to the online problem and the identification number of the client 200, sends the identification code to the client 200, and prompts the client 200 to identify the identification code.

In this embodiment, the identification code includes an identification number of the client 200. The identification code is a pattern identification code which is used for recording data symbol information and is distributed on a plane according to a certain rule by a specific geometric figure. The identification code includes, but is not limited to, a bar code and a two-dimensional code. Preferably, the identification code is a two-dimensional code. The identification method of the client 200 includes a method of scanning the identification code and a method of pressing the identification code. Furthermore, the identification code is used to activate the diagnosis procedure of the online problem after the client 200 identifies it. The information in the identification code includes the unique device identification number of the client 200, the unique serial number assigned to the client 200 by the server 100, and the problem ID of the online problem. In one embodiment, the identification code includes information represented as follows:

Debug://m9encode(md5(IMEI)&md5(SN)&ID＝xxx)。

in step S415, the client 200 identifies the identification code to obtain the information included in the identification code. If the client 200 does not recognize the identification code, the diagnostic process can be directly ended. For example, the service end 100 may directly end the diagnosis process if it does not receive the feedback information after the identification code is recognized by the client 200 after a certain time (e.g. 15 minutes).

In step S416, the client 200 determines whether the information included in the identification code matches the identification number of the client 200 itself. If the information included in the identification code matches the identification number of the client 200 itself, the process proceeds to step S417, otherwise, the process is ended.

Specifically, after the client 200 identifies the two-dimensional code, the information included in the two-dimensional code is decrypted (for example, using M9 decryption algorithm), so that the information included in the two-dimensional code, such as the identification number of the client 200 and the problem ID of the on-line problem, can be obtained, and then the analyzed information is matched with the identification number of the client 200 itself. This step is to ensure that the identification code is only valid for the specific client that feeds back the on-line problem, and to prevent malicious use of the identification code caused by other clients scanning the identification code to activate the diagnostic process. That is, in this embodiment, the identification code is used for the client 200 to activate a diagnosis process, so as to perform online diagnosis on the online problem.

In addition, in other embodiments, a determination step may be further included before the step S415, in which the client 200 determines whether a diagnosis switch for diagnosing the online problem is turned on, if the diagnosis switch is not turned on, the process is directly ended, and if the diagnosis switch is turned on, the process proceeds to the step S415. Specifically, after the client 200 installs the application 400, a software diagnostic switch may be set for the application 400, and the diagnostic switch may be controlled online by the server 100. For example, in the step S412, the service end 100 may turn on the diagnosis switch after receiving the on-line problem fed back by the client 200. Specifically, the diagnostic switch may be turned on when the state of the online problem is set to the active state by the server 100, or may be turned on before the state of the online problem is set to the active state. Finally, after the on-line problem is resolved (as in step S418 described below), the service end may turn off the diagnostic switch.

In step S417, the client 200 sends a diagnosis request to the server 100. In this embodiment, the diagnosis request is in a format of an http (hypertext transfer protocol) request, and the client 200 sends the diagnosis request to the server 100 through a preset URL (Uniform Resource Location). The diagnostic request includes the encrypted identification number (e.g., IMEI and SN) of the client 100 and the problem ID of the online problem. An example format of a diagnostic request is as follows:

http://m9encode(IMEI＝xxx&SN＝xxx&ID＝xxx)。

in other embodiments, before sending the diagnosis request in step S417, the client 200 first prompts the user whether to approve entering the online diagnosis flow of the online problem. After the user enters the diagnostic process, the step S417 is executed. And if the user does not agree to enter the diagnosis process, the process is directly ended. Therefore, the user can automatically interrupt the diagnosis process in the midway according to the actual situation, and the remote operation of the server 100 on the client 200 is avoided. For example, the client 200 may prompt the user to select whether to enter the online diagnostic process by popping up a dialog box as shown in fig. 5.

In step S418, the server 100 returns a diagnosis instruction corresponding to the online problem to the client 200.

In addition, in other embodiments, the server 100 may further determine whether the diagnosis request sent by the client 200 is true and valid, and then execute step S416 when determining that the diagnosis request is true and valid. Specifically, if the identification number and the problem ID included in the diagnosis request sent by the client 200 are completely matched with the identification number and the problem ID of the client corresponding to the online problem stored in the database of the server 100, the diagnosis request sent by the client 200 is considered to be true and valid, and a status code of "200 OK" is returned. Otherwise, the diagnosis request is considered invalid, and then a status code of "403 forbidden" is returned to end the diagnosis process.

The diagnosis instruction returned by the server 100 to the client 200 includes at least one diagnosis instruction entered into the database by the server 100 when the online problem fed back by the client is received.

In addition, before returning the diagnosis instruction, the server 100 may further determine whether the state of the online problem corresponding to the problem ID included in the diagnosis request is an active state, and if the online problem is an active state, the diagnosis instruction is sent again, and if the online problem is an inactive state, the diagnosis flow is ended without responding to the diagnosis request sent by the client 200. After returning the diagnosis instruction to the client 200, the server 100 may set the status of the online problem to an inactive status. In this manner, a situation in which the client 200 repeatedly sends a diagnosis request after the online problem has been solved can be prevented. It should be understood that the "active state" and the "inactive state" are only used to characterize whether the online problem is the online problem currently fed back by the client 200 and needs to be solved currently. For example, "active state" refers to a problem that the online problem is currently fed back by the client 200 and needs to be solved. Whereas "inactive state" refers to a problem that is fed back by the client 200 and has been solved or otherwise is not needed to be solved. Thus, in other embodiments, other terms may be used to represent the status of the on-line problem, and are not limited to the literal interpretation of the "active status" and "inactive status" themselves.

In step S419, the client 200 receives the diagnosis instruction returned by the server 100, and executes a corresponding action according to the diagnosis instruction, so as to complete online diagnosis of the online problem.

Specifically, in this embodiment, the client 200 first determines the status code returned by the server 100, and if the status code is "200 OK" that the characterization diagnosis request is valid, the client further analyzes the diagnosis instruction to determine the specific action that needs to be executed by the client 200. For example, in one embodiment, the diagnostic instruction is a json format instruction. If the up instruction is analyzed from the diagnosis instruction, it indicates that the client 200 is required to upload the corresponding client file to the server 100. If the "down" command is analyzed, it indicates that the client 200 is required to download the corresponding file from the server 100 to the client 200.

To summarize, the corresponding actions performed by the client 200 according to the diagnostic instructions include actions of uploading files and downloading files.

If the file is to be uploaded, the client 200 encrypts the file to be uploaded and uploads the encrypted file to the server 100. In addition, if the uploaded file is a folder, the folder is packaged and encrypted and then uploaded to the server 100.

If the file is downloaded, the server 100 requests the specified file, and then downloads and places the specified file in the directory specified by the client 100. The downloaded files include a normal file and an executable script file. The general file refers to other types of files than the executable script file, such as a bookmark file and a video index file. If the downloaded file is a script file (such as a lua script file), the script file is put into the specified directory, and then the user is prompted to restart the client 200. The script file can be executed after the client 200 is restarted, thereby solving the online problem.

In addition, in other embodiments, before the client 200 downloads the specified file, the user is first prompted whether to approve downloading the specified file, and when the user approves downloading the specified file, the specified file is downloaded. The method of prompting may be in the manner shown in the dialog box shown in fig. 6. Accordingly, before uploading the file, the uploading action can be executed after the user agrees in a similar dialogue mode. The above method is only a preferable way, so that the user can fully know the action to be performed by the server 100, and further, the mishaps (such as a user complaint problem of the client 200 caused by sensitive data leakage) caused by the unknown data of the client 200 being operated by the server 100 can be avoided.

In summary, the online diagnosis method for online problems provided by the invention adopts a common C/S structure, the client can complete the uploading, downloading and repairing of the diagnosis information only by scanning the identification code (two-dimensional code), without the help of a third-party software assistant, and even without the user going deep into the file structure of the application program, the user can complete the whole online diagnosis process only by performing simple operation according to the prompt, thereby expanding the efficiency and range of solving the online problems, and greatly improving the user experience when the user encounters the online problems.

Furthermore, in conjunction with the above-described method, the steps S411 to S414 and S418 are performed at the server 100. Therefore, for the server 100, the steps S411 to S414 and S418 constitute a complete online diagnosis process of the online problem performed by the server 100. The steps S415 to S417 and S419 are executed in the client 200, so that the steps S415 to S417 and S419 constitute a complete online diagnosis process for the online problem executed by the client 200 for the client 200.

Referring to fig. 7, a functional block diagram of the first online diagnosis apparatus 110 of the server 100 shown in fig. 2 according to a preferred embodiment of the present invention is shown. The first online diagnosis device 110 is configured to execute steps S411 to S414 and S418 in the flowchart shown in fig. 4. The first online diagnosis device 110 includes a problem receiving module 1101, an information entry module 1102, an instruction writing module 1103, an identification code generating module 1104, and an instruction sending module 1105.

The question receiving module 1101 is configured to receive an online question fed back by the client 200. Specifically, when online problems such as damage to bookmark files, damage to video index files, and running errors of scripts occur, the client 200 may feed back the online problems and the description of the online problems to the server 100. The server 100 receives and analyzes the fed back online problem by the problem receiving module 101. Other specific contents may refer to the description of step S411 above.

The information entry module 1102 is configured to enter an identification number of the client 200 and a question description of the online question into a database, and set a state of the online question to an activated state.

In addition, before the identification number of the client 200 is entered into the database, the information entry module 1102 first encrypts the identification number using an encryption algorithm to ensure data security. Meanwhile, after the question description of the online question is entered into the database, the database automatically generates a question ID (identifier) of the online question, which is used for identifying the online question. The encryption Algorithm may be, but is not limited to, MD5(Message-Digest Algorithm 5, version 5 of the information Digest Algorithm).

The instruction writing module 1103 is configured to write a diagnosis instruction that needs to be executed by the client 200 into the database.

Specifically, in this embodiment, the instruction writing module 1103 writes, into the database, various types of diagnostic instructions that need to be executed by the client 200 according to the types of online problems that may be fed back by the client 200. The diagnosis instruction to be executed by the client 200 may be roughly classified into an instruction to upload a file, an instruction to download a file, and an instruction to download an executable script file according to the type of the online problem. The script file is preferably a Lua script file. The final implementation form of the diagnosis instruction is identified by json (JavaScript Object Notation) format. As specific examples of the above-described various types of instructions, the details in step S413 can be referred to.

The identification code generation module 1104 is configured to generate an identification code according to the online problem and the identification number of the client 200, and then send the identification code to the client 200 and prompt the client 200 to identify the identification code.

In this embodiment, the identification code includes an identification number of the client 200. The identification code includes, but is not limited to, a bar code and a two-dimensional code. Preferably, the identification code is a two-dimensional code. The identification method of the client 200 includes a method of scanning the identification code and a method of pressing the identification code. Furthermore, the identification code is used to activate the diagnosis procedure of the online problem after the client 200 identifies it. The information in the identification code includes the unique device identification number of the client 200, the unique serial number assigned to the client 200 by the server 100, and the problem ID of the online problem. In one embodiment, the identification code includes information represented as follows:

Debug://m9encode(md5(IMEI)&md5(SN)&ID＝xxx)。

the instruction sending module 1105 is configured to send a diagnosis instruction corresponding to the online problem to the client 200 when the client 200 identifies the identification code and returns a diagnosis request to the server 100, and the client 200 executes a corresponding action according to the diagnosis instruction to solve the online problem.

In addition, in other embodiments, the instruction sending module 1105 may further determine whether the diagnosis request sent by the client 200 is true and valid, and send the diagnosis instruction to the client 200 for execution when determining that the diagnosis request is true and valid. Specifically, it is determined whether the diagnosis request sent by the client 200 includes the identification number and the problem ID of the client corresponding to the online problem stored in the database of the server 100. If yes, the diagnosis request sent by the client 200 is considered to be true and valid, and a status code of '200 OK' is returned. Otherwise, the diagnosis request is considered invalid, and then a status code of "403 forbidden" is returned to end the diagnosis process.

The diagnosis instruction sent by the instruction sending module 1105 to the client 200 includes at least one diagnosis instruction entered into the database by the server 100 when receiving an online problem fed back by the client.

In addition, before returning the diagnosis instruction, the instruction sending module 1105 may further determine whether the state of the online problem corresponding to the problem ID included in the diagnosis request is an active state, and send the diagnosis instruction again if the state is the active state, and directly end the diagnosis flow without responding to the diagnosis request sent by the client 200 if the state is the inactive state. After returning the diagnostic instruction to the client 200, the instruction sending module 1105 may set the status of the online problem to an inactive status. In this manner, a situation in which the client 200 repeatedly sends a diagnosis request after the online problem has been solved can be prevented.

Referring to fig. 8, a functional block diagram of the second online diagnosis apparatus 210 of the client 200 shown in fig. 3 according to a preferred embodiment of the present invention is shown. The second online diagnosis device 210 is configured to execute steps S415-S417 and S419 in the flowchart shown in fig. 4. The second online diagnostic apparatus 210 comprises an identification module 2101, a matching module 2102, a request module 2103 and an execution module 2104.

The identifying module 2101 is configured to identify an identifying code sent by the server 100 after receiving the online problem fed back by the client 200, to obtain information included in the identifying code.

The matching module 2102 is configured to determine whether the information included in the identification code matches with the identification number of the client 200 itself.

Specifically, after the client 200 identifies the two-dimensional code, decrypting the information included in the two-dimensional code (e.g., using M9 decryption algorithm) may obtain the information included in the two-dimensional code, such as the identification number of the client 200 and the question ID of the online question. The parsed information is then matched with the client 200's own identification number. This step is to ensure that the identification code is only valid for the specific client that feeds back the on-line problem, and to prevent malicious use of the identification code caused by other clients scanning the identification code to activate the diagnostic process. That is, in this embodiment, the identification code is used for the client 200 to activate the diagnosis process of the online problem.

The request module 2103 is configured to send a diagnosis request to the server 100 when the information included in the identification code matches the identification number of the client 200 itself. In this embodiment, the format of the diagnosis request is an http (hypertext transfer protocol) format, and the request module 2103 sends the diagnosis request to the server 100 through a preset URL (uniform resource Location) address. The diagnostic request includes the encrypted identification number (e.g., IMEI and SN) of the client 100 and the problem ID of the online problem. An example format of a diagnostic request is as follows:

http://m9encode(IMEI＝xxx&SN＝xxx&ID＝xxx)。

in other embodiments, the request module 2103 may first prompt the user whether to approve entering the diagnostic flow before the request module 2103 sends the diagnostic request. And after the user enters the diagnosis process, sending the diagnosis request again. Therefore, the user can automatically interrupt the diagnosis process in the midway according to the actual situation, and the remote operation of the server 100 on the client 200 is avoided. For example, the client 200 may prompt the user to select whether to enter the diagnostic flow by popping up a dialog box as shown in FIG. 5.

Additionally, in other embodiments, the determining module 2102 is further configured to determine whether a diagnostic switch for diagnosing the on-line problem is on. Specifically, after the client 200 installs the application 400, a software diagnostic switch may be set for the application 400, and the diagnostic switch may be controlled online by the server 100. For example, the diagnostic switch may be turned on directly when the information entry module 1102 sets the status of the online problem to an active status. Finally, the service end may turn off the diagnostic switch after the on-line problem is resolved. In this way, the request module 2103 may be configured to send the diagnosis request only when the user approves the diagnosis process and the diagnosis switch is turned on. However, in other embodiments, there is no limitation in this manner.

The execution module 2104 is configured to receive a diagnosis instruction returned by the server 100 after receiving the diagnosis request, and execute a corresponding action according to the diagnosis instruction, so as to complete online diagnosis of the online problem.

Specifically, in this embodiment, the execution first determines the status code returned by the server 100, and if the status code is "200 OK" that the characterization diagnosis request is valid, the execution further analyzes the diagnosis instruction to determine the specific action that needs to be executed by the client 200. For example, in one embodiment, the diagnostic instruction is a json format instruction. If the up instruction is analyzed from the diagnosis instruction, it indicates that the client 200 is required to upload the corresponding client file to the server 100. If the "down" command is analyzed, it indicates that the client 200 is required to download the corresponding file from the server 100 to the client 200.

In summary, the corresponding actions performed by the execution module 2104 in accordance with the diagnostic instructions include actions to upload files and download files.

If the file is to be uploaded, the execution module 2104 encrypts the file to be uploaded and uploads the encrypted file to the server 100. In addition, if the uploaded file is a folder, the folder is packaged and encrypted and then uploaded to the server 100.

In order to download the file, the execution module 2104 requests the server 100 for the specified file, and then downloads and places the specified file into the directory specified by the client 100. If the downloaded file is a script file (such as a lua script file), the script file is put into a preset fixed path, and then the user is prompted to restart the client 200. The script file can be executed after the client 200 is restarted, thereby solving the online problem.

In addition, in other embodiments, before the execution module 2104 downloads the specified file, the user may be first prompted whether to approve downloading the specified file, and the specified file may be downloaded again when the user approves downloading the specified file. The method of prompting may be in the manner shown in the dialog box shown in fig. 6. Accordingly, before uploading the file, the uploading action can be executed after the user agrees in a similar dialogue mode. The above method is only a preferable way, so that the user can fully know the action to be performed by the server 100, and further, the mishaps (such as a user complaint problem of the client 200 caused by sensitive data leakage) caused by the unknown data of the client 200 being operated by the server 100 can be avoided.

In addition, the online diagnosis method and apparatus for online problems described above can be implemented based on a WAX framework, where the WAX framework (WAX framework) is an intermediary engine that executes lua language in Objective-C language, and functions implemented by lua language can be converted into OC language codes recognizable by an operating system (e.g., an IOS system) of an electronic device through an environment when the Objective-C is run. By using this feature, the OC function or script of the client can be rewritten by using the lua language, thereby achieving the diagnosis and repair of the online problem.

In the embodiments provided in the present application, it should be understood that the disclosed apparatus and method can be implemented in other ways. The apparatus embodiments described above are merely illustrative, and for example, the flowchart and block diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of apparatus, methods and computer program products according to various embodiments of the present invention. In this regard, each block in the flowchart or block diagrams may represent a module, segment, or portion of code, which comprises one or more executable instructions for implementing the specified logical function(s). It should also be noted that, in some alternative implementations, the functions noted in the block may occur out of the order noted in the figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved. It will also be noted that each block of the block diagrams and/or flowchart illustration, and combinations of blocks in the block diagrams and/or flowchart illustration, can be implemented by special purpose hardware-based systems which perform the specified functions or acts, or combinations of special purpose hardware and computer instructions.

In addition, the functional modules in the embodiments of the present invention may be integrated together to form an independent part, or each module may exist separately, or two or more modules may be integrated to form an independent part.

The functions, if implemented in the form of software functional modules and sold or used as a stand-alone product, may be stored in a computer readable storage medium. Based on such understanding, the technical solution of the present invention may be embodied in the form of a software product, which is stored in a storage medium and includes instructions for causing a computer device (which may be a personal computer, a server, or a network device) to execute all or part of the steps of the method according to the embodiments of the present invention. And the aforementioned storage medium includes: a U-disk, a removable hard disk, a Read-Only Memory (ROM), a Random Access Memory (RAM), a magnetic disk or an optical disk, and other various media capable of storing program codes. It is noted that, herein, relational terms such as first and second, and the like may be used solely to distinguish one entity or action from another entity or action without necessarily requiring or implying any actual such relationship or order between such entities or actions. Also, the terms "comprises," "comprising," or any other variation thereof, are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements does not include only those elements but may include other elements not expressly listed or inherent to such process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising an … …" does not exclude the presence of other identical elements in a process, method, article, or apparatus that comprises the element.

The above description is only a preferred embodiment of the present invention and is not intended to limit the present invention, and various modifications and changes may be made by those skilled in the art. Any modification, equivalent replacement, or improvement made within the spirit and principle of the present invention should be included in the protection scope of the present invention. It should be noted that: like reference numbers and letters refer to like items in the following figures, and thus, once an item is defined in one figure, it need not be further defined and explained in subsequent figures.

Claims

1. An online diagnosis method, applied to a server and a client which are in communication connection with each other, is characterized in that the online diagnosis method comprises the following steps:

the server receives the on-line problem fed back by the client and the identification number of the client, and encrypts the identification number of the client;

the client side decrypts and identifies the identification code to obtain the information contained in the identification code, and judges whether the information contained in the identification code is matched with the identification number of the client side;

when the information included in the identification code is matched with the identification number of the client, the client sends a diagnosis request to the server, wherein the diagnosis request includes the encrypted identification number of the client;

2. The online diagnostic method of claim 1, further comprising:

when the server side records the online problem into a database, setting the state of the online problem as an activated state;

before the server returns a diagnosis instruction corresponding to the on-line problem to the client, the server judges whether a diagnosis request sent by the client is real and effective; and

when the diagnosis request is judged to be true and effective, judging whether the state of the online problem is an activated state;

and when the state of the online problem is judged to be an activated state, the server side returns the diagnosis instruction to the client side.

3. The online diagnostic method of claim 1, further comprising:

before the client sends a diagnosis request to the server, the client judges whether a diagnosis switch for diagnosing the online problem is turned on; and when the diagnosis switch is judged to be opened, the client sends a diagnosis request to the server.

4. The online diagnostic method of claim 1, further comprising:

before the client sends a diagnosis request to the server, the client judges whether a diagnosis switch for diagnosing the online problem is turned on; and

when the diagnosis switch is judged to be turned on, the client prompts the user whether to agree to enter the online diagnosis process of the online problem

And when the user agrees to enter the online diagnosis process of the online problems, the client sends a diagnosis request to the server.

5. The online diagnosis method according to claim 3 or 4, characterized in that the diagnosis switch is a software diagnosis switch set when the client downloads and installs an application program from the server, and the diagnosis switch is controlled online by the server; and the server turns on the diagnosis switch when receiving the on-line problem fed back by the client, and turns off the diagnosis switch after returning the diagnosis instruction to the client.

6. The online diagnostic method of claim 1, wherein the diagnostic instructions comprise instructions to upload a file, instructions to download an executable script file; the client executes corresponding actions according to the diagnosis instruction, wherein the actions comprise file uploading and file downloading; wherein:

if the file is an action of uploading the file, the client encrypts the file to be uploaded and uploads the file to the server;

if the file downloading action is carried out, the client requests the specified file from the server, and the specified file is downloaded and placed in a directory specified by the client; the downloaded files include a normal file and an executable script file.

7. The online diagnostic method of claim 1, wherein the identification number of the client comprises a device identification number of the client and a serial number assigned by a server to the client; the identification code is a two-dimensional code, and the information of the two-dimensional code comprises an identification number of the client and a problem identifier of the online problem; and the identification number of the client is sent to the server when the client feeds back the on-line problem to the server.

8. An online diagnosis device applied to a server communicatively connected to a client, the online diagnosis device comprising:

9. The online diagnostic apparatus according to claim 8, wherein the information entry module is further configured to set the status of the online problem to an active status when the online problem is entered into the database, and set the status of the online problem to an inactive status after the instruction sending module returns the diagnostic instruction to the client.

10. The online diagnosis device according to claim 8, wherein the instruction sending module is further configured to determine whether the diagnosis request sent by the client is true and valid before returning the diagnosis instruction corresponding to the online problem to the client, and further determine whether the state of the online problem is an active state when determining that the diagnosis request is true and valid; and when the online problem is judged to be in the activated state, the diagnosis instruction is returned to the client.

11. The online diagnostic apparatus of claim 10, wherein the database generates a problem identifier for the online problem when the problem description for the online problem is entered into the database; the instruction sending module judges whether the diagnosis request sent by the client is real and effective by judging whether the diagnosis request comprises an identification number of the client and a problem identifier which are stored in the database and correspond to the online problem; if the diagnosis request comprises the identification number and the problem identifier of the client corresponding to the online problem and stored in the database, the diagnosis request is judged to be true and valid, otherwise, the diagnosis request is judged to be invalid.

12. The online diagnostic apparatus of claim 10, wherein the identification number of the client comprises a device identification number of the client and a serial number assigned by a server to the client; the identification code is a two-dimensional code, and the information of the two-dimensional code comprises an identification number of the client and a problem identifier of the online problem; and the identification number of the client is sent to the server when the client feeds back the online problem to the server.

13. An online diagnosis device applied to a client end connected with a service end in a communication way, comprising:

14. The online diagnostic apparatus of claim 13, wherein the request module is further configured to determine whether a diagnostic switch for diagnosing the online problem is turned on before sending the diagnostic request to the server; and when the diagnosis switch is judged to be opened, sending a diagnosis request to the server.

15. The online diagnosis device of claim 13, wherein the request module is further configured to, before sending the diagnosis request to the server, the client determines whether a diagnosis switch for diagnosing the online problem is turned on, and when determining that the diagnosis switch is turned on, prompts the user whether to approve entering an online diagnosis process of the online problem; and when the user agrees to enter the online diagnosis process of the online problem, the request module sends a diagnosis request to the server.

16. The online diagnosis device according to claim 14 or 15, wherein the diagnosis switch is a software diagnosis switch set when the client downloads and installs an application program from the server, the diagnosis switch being controlled online by the server; the diagnosis switch is turned on when the server receives an online problem fed back by the client, and is turned off after the server sends the diagnosis instruction to the client.

17. The online diagnostic apparatus of claim 13, wherein the diagnostic instructions comprise instructions to upload a file, instructions to download an executable script file; the executing corresponding actions according to the diagnosis instruction comprise actions of uploading files and downloading files; wherein:

if the file is uploaded, the execution module encrypts the file to be uploaded and uploads the file to the server;

if the file downloading action is carried out, the execution module requests the appointed file from the server, downloads the appointed file and puts the appointed file into a directory appointed by the client; the downloaded files include a normal file and an executable script file.

18. The online diagnostic apparatus of claim 13, wherein the identification number of the client comprises a device identification number of the client and a serial number assigned by the server to the client; the identification code is a two-dimensional code, and the information of the two-dimensional code comprises the identification number of the client and the problem identifier of the online problem.