Remote debugging method and device, electronic equipment, storage medium and product

Abstract

The invention provides a remote debugging method and device, electronic equipment, a computer storage medium and a computer program product, the method is applied to the technical field of computers, and the method comprises the following steps: receiving a debugging identifier of a to-be-debugged application; the debugging identifier is obtained through a debugging end and is sent to a client through a third-party platform; according to the debugging identifier, loading an SDK (Software Development Kit); based on the loaded SDK, obtaining an operation path of a first user for the to-be-debugged application, and sending the operation path to the debugging end through a server, so that the debugging end obtains a debugging code input by a second user according to the operation path and returns the debugging code to the client through the server; and executing the debugging code, and returning the executed debugging result to the debugging end through the server side.

Description

Technical Field

[0001] The present application relates to the field of computer technology, and in particular to a remote debugging method, device, electronic device, computer storage medium and computer program product. Background Art

[0002] With the rapid development of mobile Internet, H5 (HTML5) has been widely used in mobile applications due to its lightweight, cross-platform, fast iteration and easy distribution.

[0003] In the related technology, when users report a problem with the operation of an H5 application, they cannot directly perform debugging operations because the device where the debugging tool is located and the device running the H5 application are not the same device. In this case, developers can only communicate with users to provide problem reproduction steps and related operation recording videos, and then try to reproduce the problem locally based on the information provided by the user and provide corresponding solutions. However, the time cost of communicating with users in the above technical solutions is high, making the troubleshooting process time-consuming and labor-intensive, affecting the efficiency of fault detection. Summary of the invention

[0004] The present application provides a remote debugging method, device, electronic device, computer storage medium and computer program product, which can improve fault detection efficiency.

[0005] The technical solution of this application is implemented as follows:

[0006] The present application provides a remote debugging method, which is applied to a client, and the method includes:

[0007] Receiving a debugging identifier of an application to be debugged; the debugging identifier is obtained by a debugging terminal and sent to the client via a third-party platform;

[0008] According to the debugging identifier, loading a software development kit (SDK);

[0009] Based on the loaded SDK, an operation path of the first user on the application to be debugged is obtained, and the operation path is sent to the debugging end via the server, so that the debugging end obtains the debugging code input by the second user according to the operation path and returns it to the client via the server; the operation path represents at least one operation behavior performed by the first user on the application to be debugged, and the at least one operation behavior includes an abnormal operation behavior that triggers an abnormality in the application to be debugged;

[0010] The debugging code is executed, and the debugging result after execution is returned to the debugging end via the server end.

[0011] The present application provides a remote debugging method, which is applied to a debugging end, and the method includes:

[0012] Obtaining a debugging identifier of the application to be debugged, and sending the debugging identifier to a client through a third-party platform, so that the client loads an SDK according to the debugging identifier, and obtaining an operation path of a first user on the application to be debugged based on the loaded SDK; the operation path represents at least one operation behavior performed by the first user on the application to be debugged, and the at least one operation behavior includes an abnormal operation behavior that triggers an abnormality in the application to be debugged;

[0013] receiving an operation path sent by the client via the server, acquiring a debugging code input by a second user according to the operation path, and returning the debugging code to the client via the server, so that the client executes the debugging code;

[0014] Receive the debugging result after execution returned by the client via the server.

[0015] The present application provides a remote debugging device, applied to a client, the device comprising:

[0016] A first receiving module, configured to receive a debugging identifier of an application to be debugged; the debugging identifier is obtained by a debugging terminal and sent to the client via a third-party platform;

[0017] A loading module, used to load the SDK according to the debugging identifier;

[0018] an acquisition module, configured to acquire an operation path of a first user on the application to be debugged based on the loaded SDK, and send the operation path to the debugging end via the server, so that the debugging end acquires the debugging code input by the second user according to the operation path and returns it to the client via the server; the operation path represents at least one operation behavior performed by the first user on the application to be debugged, and the at least one operation behavior includes an abnormal operation behavior that triggers an abnormality in the application to be debugged;

[0019] The execution module is used to execute the debugging code and return the debugging result after execution to the debugging end via the server end.

[0020] The present application provides a remote debugging device, which is applied to a debugging end, and the device includes:

[0021] a sending module, configured to obtain a debugging identifier of the application to be debugged, and send the debugging identifier to a client through a third-party platform, so that the client loads an SDK according to the debugging identifier, and obtains an operation path of a first user for the application to be debugged based on the loaded SDK; the operation path represents at least one operation behavior performed by the first user for the application to be debugged, and the at least one operation behavior includes an abnormal operation behavior that triggers an abnormality in the application to be debugged;

[0022] A generating module, configured to receive an operation path sent by the client via the server, obtain a debugging code input by the second user according to the operation path, and return the debugging code to the client via the server, so that the client executes the debugging code;

[0023] The second receiving module is used to receive the debugging result after execution returned by the client via the server.

[0024] The present application provides an electronic device, which includes a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor implements the remote debugging method provided by one or more of the aforementioned technical solutions when executing the program.

[0025] The present application provides a computer storage medium, wherein the computer storage medium stores a computer program; after the computer program is executed, the remote debugging method provided by one or more of the above-mentioned technical solutions can be implemented.

[0026] The present application provides a computer program product, including a computer program, which, when executed by a processor, implements the remote debugging method provided by one or more of the aforementioned technical solutions.

[0027] The embodiments of the present application provide a remote debugging method, device, electronic device, computer storage medium and computer program product, which are applied to a client. The method includes: receiving a debugging identifier of an application to be debugged; the debugging identifier is obtained by a debugging terminal and sent to the client via a third-party platform; loading an SDK according to the debugging identifier; based on the loaded SDK, obtaining an operation path of a first user for the application to be debugged, and sending the operation path to the debugging terminal via a server, so that the debugging terminal obtains a debugging code input by a second user according to the operation path and returns it to the client via the server; the operation path represents at least one operation behavior performed by the first user on the application to be debugged, and the at least one operation behavior includes an abnormal operation behavior that triggers an abnormality in the application to be debugged; executing the debugging code, and returning the debugging result after execution to the debugging terminal via the server.

[0028] It can be seen that in the embodiment of the present application, the client can obtain the user's operation path for the application to be debugged through the SDK, and send it to the debugging end via the server, so that the developer of the debugging end can quickly restore the abnormal operation behavior with problems based on the operation path, and return the corresponding debugging code, thereby realizing remote debugging of the application to be debugged and reducing the difficulty of troubleshooting; the entire debugging process does not require obtaining the fault information of the application to be debugged through communication, thus reducing the communication cost of remote debugging and improving the efficiency of fault detection. BRIEF DESCRIPTION OF THE DRAWINGS

[0029] Figure 1 is a flowchart of a remote debugging method in the related art;

[0030] Figure 2 A schematic diagram of the structure of a remote debugging system provided in an embodiment of the present application;

[0031] Figure 3 A flowchart of a remote debugging method provided in an embodiment of the present application;

[0032] Figure 4 A schematic diagram of a scenario for generating an activation reminder message provided in an embodiment of the present application;

[0033] Figure 5 A flowchart of another remote debugging method provided in an embodiment of the present application;

[0034] Figure 6 A flowchart of another remote debugging method according to an embodiment of the present application;

[0035] Figure 7 A schematic diagram of the structure of a remote debugging device according to an embodiment of the present application;

[0036] Figure 8 A schematic diagram of the structure of another remote debugging device according to an embodiment of the present application;

[0037] Fig. 9 A schematic diagram of the structure of an electronic device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0038] The present application will be further described in detail below in conjunction with the accompanying drawings and Examples. It should be understood that the embodiments provided herein are only used to explain the present application and are not intended to limit the present application. In addition, the embodiments provided below are partial embodiments for implementing the present application, rather than providing all embodiments for implementing the present application. In the absence of conflict, the technical solutions recorded in the embodiments of the present application can be implemented in any combination.

[0039] It should be noted that, in the embodiments of the present application, the terms "include", "comprise" or any other variants thereof are intended to cover non-exclusive inclusion, so that a method or system including a series of elements includes not only the elements explicitly recorded, but also includes other elements not explicitly listed, or also includes elements inherent to the implementation of the method or system. In the absence of further restrictions, an element defined by the sentence "includes a ..." does not exclude the presence of other related elements (such as steps in a method or units in a system, for example, a unit may be a part of a processor, a part of a program or software, etc.) in the method or system including the element.

[0040] For example, the remote debugging method provided by the present application includes a series of steps, but the remote debugging method provided by the present application is not limited to the recorded steps. Similarly, the remote debugging device provided by the present application includes a series of modules, but the remote debugging device provided by the present application is not limited to including the modules explicitly recorded, and may also include modules that need to be set up to obtain relevant information or perform processing based on the information.

[0041] In related technologies, when developers debug H5 applications, they need to first connect the device running the H5 application to the computer via a data cable, and then use the debugging tools that come with the browser on the computer to debug the H5 application. When facing user feedback issues, since users and developers are not in the same geographical location, and the feedback issues are usually local and specific issues for specific users, specific models, and specific scenarios, developers usually need to rely on the problem reproduction steps and related information provided by users to troubleshoot the problem. The basic process can be referred to Figure 1 , corresponding to step 101 to step 107, the specific process is as follows:

[0042] Step 101: Steps to reproduce the problem reported by the user.

[0043] Step 102: The developer reproduces the problem according to the problem reproduction steps reported by the user.

[0044] Step 103: Determine whether the problem is reproducible; if so, execute step 104; otherwise, execute step 105.

[0045] Step 104: The developer successfully reproduces the problem and resolves it.

[0046] Step 105: The developer has difficulty reproducing the problem and asks the customer to provide an additional operation recording video.

[0047] Step 106: The developer constructs user data in the test environment, uses a similar terminal, and reproduces the problem according to the operation path provided by the user.

[0048] Step 107: The developer successfully reproduces the problem and resolves it.

[0049] However, the above technical solution has the following disadvantages:

[0050] 1) High cost: The cost of recording videos is high. Some users may not know how to record the screen, or the quality of the recorded screen is poor, resulting in an inability to effectively analyze the problem.

[0051] 2) Difficult to reproduce: Developers can only learn the specific operation path from the video recorded by the user, and cannot obtain the application log information and context data. In actual scenarios, due to the diversity of terminal models and system versions, it is difficult to find a terminal similar to the user's terminal. Even if the user's problem reproduction path is obtained, it is difficult to reproduce the problem.

[0052] 3) Low efficiency: The entire process is time-consuming and labor-intensive, and takes a long time. It often requires repeated communication and confirmation with users, and has high requirements for users, who need to describe the problem clearly.

[0053] In view of the above problems, the following embodiments are proposed below.

[0054] In some embodiments of the present application, the remote debugging method can be implemented using a processor in a remote debugging device, and the above-mentioned processor can be at least one of an application-specific integrated circuit (ASIC), a digital signal processor (DSP), a digital signal processing device (DSPD), a programmable logic device (PLD), a field programmable gate array (FPGA), a central processing unit (CPU), a controller, a microcontroller, and a microprocessor.

[0055] Figure 2 A schematic diagram of the structure of a remote debugging system provided in an embodiment of the present application is shown in FIG. Figure 2 As shown, the system includes a client 01, a server 02 and a debugging terminal 03. The functions of each part of the system are exemplarily described below.

[0056] Exemplarily, the client 01 is located at the user side, and the application to be debugged is running on the client 01. The application to be debugged is an H5 application that needs to be debugged. Here, the type of the client is not specifically limited. For example, the client 01 can be a mobile phone, a computer, or a tablet.

[0057] Exemplarily, the debugging terminal 03 is located on the developer side. It should be noted that the user and the developer are not in the same geographical location. The debugging terminal 03 is a World Wide Web (Web) application system that runs on the developer's computer device. It integrates the developer-friendly devtools-frontend as the debugging page, and expands the panel on its basis. A real-time preview panel is added to provide real-time viewing of the application to be debugged. The developer can use the debugging terminal 03 to view the information and debug the application to be debugged, and realize remote, cross-device restriction, and compatible with any browser to debug H5 applications.

[0058] Exemplarily, the server 02 is a Node.js service deployed on a remote server, which undertakes the interaction between the client 01 and the debugging terminal 03 and has functions such as data communication, message forwarding and data storage.

[0059] Exemplarily, the data communication method between the three is: the client 01 and the server 02 perform two-way message transmission based on the WebSocket protocol, the debugging end 03 and the server 02 also perform two-way message transmission based on the WebSocket protocol, and the client 01 and the debugging end 03 realize two-way message transmission via the server 02; and the transmission message format is based on the Chrome remote debugging protocol (Chrome DevTools Protocol, CDP).

[0060] It should be noted that the bidirectional message transmission channel between the client 01, the server 02 and the debugging end 03 is not established at the beginning, but is established during the interaction process, which will be explained in the subsequent embodiments and will not be repeated here.

[0061] For example, the WebSocket protocol is a network transmission protocol that can perform full-duplex communication on a single Transmission Control Protocol (TCP) connection and is located at the application layer of the Open System Interconnect (OSI) model. WebSocket makes data exchange between the client 01 and the server 02 easier, allowing the server 02 to actively push data to the client 01. In the WebSocket API, the browser of the client 01 and the server 02 only need to complete a handshake, and a persistent connection can be established between the two, and two-way data transmission can be carried out.

[0062] For example, CDP is a set of development tool protocols for Google Chrome, which allows developers to detect, check, debug and analyze web pages opened based on Chromium browsers through programming. It supports third-party custom debugging functions and is usually used in debugging web pages, performance optimization and automated testing. It is divided into several domains, such as DOM, Debugger and Network, and each domain defines several commands it supports and the events it generates. Commands and events are both serialized JS object notation (JavaScript Object Notation, JSON) objects with fixed structures. Commands are sent by the Devtools panel to the target server. The target server executes the corresponding logic according to the instructions and assembles them into events according to the format and sends them to Devtools. Devtools will consume event data and display the corresponding data in the specified panel.

[0063] In the embodiment of the present application, the remote debugging method is applicable to the remote debugging scenario where the developer and the user are not in the same geographical location. It should be noted that in the technical solution of the present application, the collection, use, storage, sharing and transfer of user personal information involved are in compliance with the provisions of relevant laws and regulations, and the user needs to be informed and the user's consent or authorization is obtained. When applicable, the user's personal information is de-identified and / or anonymized and / or encrypted.

[0064] Figure 3 A flowchart of a remote debugging method provided in an embodiment of the present application, applied to Figure 2 The client in Figure 3 As shown, the process may include:

[0065] Step 201: Receive a debugging identifier of an application to be debugged.

[0066] Exemplarily, the application to be debugged may be an H5 application running on a client and requiring debugging; herein, the type of the H5 application is not specifically limited, for example, it may be an H5 game or another type of H5 application.

[0067] In this step, the debugging end has not yet established a communication connection with the client, and the debugging identifier is obtained by the debugging end and sent to the client via the third-party platform; that is, the debugging end first obtains the debugging identifier of the application to be debugged, and then sends the obtained debugging identifier to the client via the third-party platform.

[0068] Here, the third-party platform is also referred to as a third-party communication platform, which may be a communication platform for a customer manager or other communication platform, etc.; illustratively, the debugging identifier carries relevant information for identifying the application to be debugged; the information carried by the debugging identifier may include: the user number of the first user, the Uniform Resource Locator (URL) of the application to be debugged, and a debugging enablement identifier; here, the first user is the user of the client, that is, the user who reports problems with the application to be debugged.

[0069] Here, the data format of the debug identifier is not limited. For example, the debug identifier may be in a QR code format or a link format, and the QR code format will be used as an example for explanation below.

[0070] In some embodiments, the process of the debugging end obtaining the debugging identifier may include: when the debugging end receives a login request from the second user, obtaining the login information carried in the login request; verifying the login information to obtain a verification result; and when the verification result indicates that the verification has passed, obtaining the debugging identifier of the application to be debugged.

[0071] Here, the second user refers to the person who performs debugging operations on the debugging end, corresponding to the above-mentioned developer; the login information may include but is not limited to the login account and login password of the second user; when the second user uses the login information to log in to the debugging end, the debugging end can receive the login request of the second user, which is generated by the debugging end according to the login information input by the second user.

[0072] In an embodiment of the present application, when the debugging end receives a login request from a second user, it can obtain the login information carried in the login request; then, the login information is verified; illustratively, the login information carried in the login request can be matched with the stored preset login information with debugging permissions. If the match is successful, a verification result indicating that the verification has passed is obtained; if the match fails, a verification result indicating that the verification has not passed is obtained.

[0073] Exemplarily, when the verification result indicates that the verification is passed, it means that the second user has debugging authority. At this time, the second user successfully logs in to the debugging terminal, and any debugging behavior of the second user will be logged in.

[0074] Furthermore, the debugging end obtains the URL of the application to be debugged, and supplements the first user's user number and the debugging enablement flag based on the URL; it should be noted that the various information obtained by the debugging end can be manually input by the second user, or automatically obtained by the debugging end, which is not specifically limited here.

[0075] Among them, the purpose of supplementing the user number is to generate a unique identity for the first user, so that the second user can find the corresponding application to be debugged in the debugging list of the debugging end after the first user turns on the debugging mode; the purpose of supplementing the debugging enablement identifier is to enable the first user to load the SDK when opening the application to be debugged, so as to facilitate the subsequent turning on of the debugging mode.

[0076] Exemplarily, SDK is a collection of development tools, written in JavaScript, and is a tool provided to R&D-related personnel for application development. R&D-related personnel can directly use corresponding functions through integration, thus eliminating the process of writing corresponding function codes.

[0077] Exemplarily, after obtaining the URL of the application to be debugged, the user number of the first user, and the debugging enablement flag, the debugging end can generate a debugging flag for the application to be debugged; further, after obtaining the debugging flag of the application to be debugged, the debugging end can first send the debugging flag to the third-party platform, which then sends it to the client. At this time, the client can receive the debugging flag of the application to be debugged.

[0078] Exemplarily, assuming that the third-party platform is the account manager's communication platform and the debugging identifier is in the form of a QR code, after the debugging end generates the debugging identifier QR code for the application to be debugged, the debugging end can return the debugging identifier QR code to the client via the account manager's communication platform, or it can first return the debugging identifier QR code to the second user's terminal, which will then be sent to the account manager's communication platform, and then the communication platform will forward the debugging identifier QR code to the client.

[0079] Step 202: Load the SDK according to the debugging identifier.

[0080] In the embodiment of the present application, after receiving the debugging identifier of the application to be debugged, the client can open the application to be debugged and load the SDK according to the debugging identifier.

[0081] Exemplarily, assuming that the debug logo is in the form of a QR code, after receiving the debug logo QR code, the client can display the debug logo QR code to guide the first user to open the client's scan code function, scan the debug logo QR code to open the application to be debugged, and load the SDK.

[0082] In some embodiments, loading the SDK according to the debug identifier may include: identifying the debug identifier to obtain an identification result; and loading the SDK if it is determined according to the identification result that the debug identifier carries a debug enabling identifier.

[0083] Exemplarily, after the application to be debugged is opened, the client will identify the debug flag and obtain an identification result; here, the identification result is used to indicate whether the debug flag carries a debug enable flag.

[0084] Exemplarily, according to the above content, for the application to be debugged that needs to be debugged, after the second user successfully logs in to the debugging end, he will add the debugging enablement flag while entering the URL of the application to be debugged, that is, the debugging flag finally generated will carry the debugging enablement flag; in this way, when the client receives the debugging flag of the application to be debugged, it can identify the debugging flag, and load the SDK when it is determined that the debugging flag carries the debugging enablement flag according to the identification result; in actual scenarios, the SDK can be dynamically loaded according to the URL parameters of the application to be debugged carried by the debugging flag.

[0085] It can be understood that in order to avoid all customers loading the SDK, causing traffic waste and unnecessary pressure on the server, the embodiment of the present application can realize on-demand loading of the SDK; that is, the SDK will only be loaded when the debug enable flag is carried in the debug flag.

[0086] It should be noted that the SDK has no association with the business code of the application to be debugged, so the SDK's function code can be encapsulated in an independent script file for SDK distribution.

[0087] Exemplarily, the functions of the SDK can be set accordingly according to actual needs. Its main functions include collecting the running information of the application to be debugged on the client, performing message format conversion, communicating with the server, collecting fault information when an exception occurs in the application to be debugged, proxying the browser native methods for the data to be transmitted, and injecting interception logic.

[0088] In some embodiments, the above method may further include: after loading the SDK, generating an activation reminder message for whether to activate the debugging mode; upon receiving an activation instruction triggered by the first user in response to the activation reminder message, establishing a two-way communication connection with the server.

[0089] Exemplarily, after the SDK is loaded, the SDK is integrated into the application to be debugged; it should be noted that the integration of the SDK into the application to be debugged does not mean that the debugging mode is turned on, and the first user's consent is required before it is turned on.

[0090] In an embodiment of the present application, after the client loads the SDK, the loaded SDK will be automatically injected into the application to be debugged. At this time, the client generates and displays a reminder message on whether to turn on the debugging mode. Here, there is no limitation on the display method of the reminder message, for example, it can be a pop-up window or other methods.

[0091] Furthermore, when the client receives the activation instruction triggered by the first user for the activation reminder message, a two-way communication connection is established with the server. Here, there is no limitation on the triggering method of the activation reminder message, for example, it can be a click trigger.

[0092] For example, see Figure 4 Assuming that the method of generating the start reminder message is a pop-up window, after the first user scans the debugging logo QR code to load the SDK to be debugged, the SDK is automatically injected into the application to be debugged, and the client will first pop up a request pop-up window for the start reminder message to ask the first user to confirm whether to agree to start the debugging mode. If the client receives the first user's click operation on the consent button, that is, receives the start instruction triggered by the first user for the start reminder message, it means that the first user agrees to start the debugging mode. At this time, the client will truly establish a remote debugging relationship with the debugging end; otherwise, it means that the first user does not agree to start the debugging mode, and the current process ends.

[0093] Exemplarily, when the client receives the start instruction triggered by the first user in response to the start reminder message, the client and the server establish a two-way communication connection based on the WebSocket protocol, that is, the two-way communication connection between the client and the server is established at this time.

[0094] In some embodiments, the above method may further include: after establishing a two-way communication connection with the server, the client sends a user ID and a URL to the server, so that the server generates and saves a debugging record of the application to be debugged according to the user ID and the URL.

[0095] In an embodiment of the present application, after a two-way communication connection is established between the client and the server, the client can send the user number of the first user and the URL of the application to be debugged to the server. At this time, the server can generate and save a debugging record of the application to be debugged based on the user number and URL.

[0096] For example, after generating the debugging record of the application to be debugged, the server can save the debugging record in its own debugging list, and the debugging end can pull the debugging list and display it; the debugging list is used to store the debugging records of each H5 application that needs to be debugged. In this way, the second user can filter out the application to be debugged from the debugging list pulled by the debugging end according to the user ID of the first user.

[0097] In some embodiments, the above method may also include: when the debugging end pulls the debugging record of the application to be debugged, determining whether a debugging instruction triggered by a second user for the application to be debugged is received; the debugging record is generated and saved by the server based on the user number of the first user and the URL of the application to be debugged sent by the client; if it is determined to be yes, establishing a two-way communication connection with the server.

[0098] Exemplarily, the second user can query the debug list pulled by the debug end to determine whether the debug end has pulled the debug record of the application to be debugged; accordingly, the debug end can receive the query request of the second user, and the query request carries the user number of the first user. The debug end can query the debug list according to the user number of the first user to determine whether it has pulled the debug record of the application to be debugged. If it is determined to be so, the debug record of the application to be debugged can be displayed. At this time, the second user can determine that the debug end has pulled the debug record of the application to be debugged.

[0099] Exemplarily, the debugging instruction may be an instruction generated after the second user triggers a debugging button on the debugging end, which is used to open the debugging tool devtools; here, the debugging button may be an open button of the debugging tool devtools. For example, when the second user determines that the debugging end stores debugging records of the application to be debugged, the second user may click the open button of the debugging tool devtools. At this time, the debugging end determines that it has received the debugging instruction triggered by the second user for the application to be debugged; after the second user clicks the open button, the devtools will be opened for debugging.

[0100] For example, devtools is Chrome devtools, which is a tool for web developers to test and debug code. It is a separate architecture from the Chrome browser, supports developers to view elements, network requests, and breakpoint debugging JS, etc., and is a powerful tool for auxiliary development. In the embodiment of the present application, the front-end interface part of the debugging tool devtools, namely devtools-frontend, is mainly used. This part is a web application that includes multiple debugging panels and can realize the reception and sending of CDP events.

[0101] In the embodiment of the present application, when the debugging end determines that it has received a debugging instruction triggered by a second user for the application to be debugged, the debugging end and the server establish a two-way communication connection based on the WebSocket protocol, that is, the two-way communication connection between the debugging end and the server is established at this time. Since the two-way communication connection between the client and the server has been established before, at this time, the two-way communication connection between the client and the server is established; that is, the message sent by the client can be forwarded to the debugging end via the server. Similarly, the message sent by the debugging end can also be forwarded to the client via the server. The two transfer messages through the server, thereby realizing indirect communication.

[0102] Step 203: Based on the loaded SDK, obtain the operation path of the first user for the application to be debugged, send the operation path to the debugger via the server, so that the debugger obtains the debug code input by the second user according to the operation path and returns it to the client via the server.

[0103] In an embodiment of the present application, the operation path represents at least one operation behavior performed by the first user on the application to be debugged, wherein at least one operation behavior of the at least one operation behavior includes an abnormal operation behavior that triggers an abnormality in the application to be debugged.

[0104] Here, the type of operation behavior is not specifically limited. For example, the operation behavior may be click, scroll, execute refresh or pull-down logic, and the like.

[0105] Exemplarily, after a two-way communication connection is established between the client and the server, the first user can reproduce the problem in the application to be debugged, and during the problem reproduction process, the first user will perform at least one operation on the application to be debugged, thereby generating an operation path; these operation behaviors will be saved in the log of the application to be debugged.

[0106] In an embodiment of the present application, the client obtains the operation path of the first user for the application to be debugged from the log of the application to be debugged based on the loaded SDK. After obtaining the operation path, it can convert it into a CDP event that complies with the CDP protocol specification through the loaded SDK and send it to the debugging end via the server; at this time, the debugging end can receive the CDP event.

[0107] Exemplarily, the debugging tool devtools includes a real-time preview panel. When the debugging end receives a real-time preview instruction triggered by the second user for the application to be debugged, the debugging end can display the real-time preview panel and display the CDP event corresponding to the operation path in the real-time preview panel.

[0108] Exemplarily, the real-time preview instruction is used to turn on the real-time preview mode. When the debugging end receives the real-time preview instruction triggered by the second user for the application to be debugged, the real-time preview mode will be turned on. In this mode, the real-time preview panel of the debugging end will restore the interface currently seen by the first user in a 1:1 ratio. At this time, the second user can observe the operation path of the first user and the state changes of the page after the operation in real time.

[0109] It can be understood that since the second user can observe the various operation behaviors of the first user in the real-time preview panel, the second user can quickly locate the problematic operation behavior and enter the corresponding debugging code according to the operation path on the console panel of devtools to solve the existing problem; at this time, the debugging end can obtain the debugging code entered by the second user according to the operation path, and after obtaining the debugging code, the debugging end forwards it to the client via the server, so that the client can receive the debugging code returned by the debugging end.

[0110] Exemplarily, the debugging code input by the second user according to the operation path will be converted into a CDP instruction that complies with the CDP specification by devtools and sent to the server, and then returned to the client through the server. It should be noted that after receiving the CDP instruction, the client will parse it according to the CDP protocol specification and restore it to the debugging code. At this time, the client receives the debugging code corresponding to the operation path.

[0111] Step 204: Execute the debugging code, and return the debugging result after execution to the debugging end via the server end.

[0112] In the embodiment of the present application, after receiving the debugging code corresponding to the operation path, the client executes the debugging code and returns the debugging result after execution to the debugging end via the server.

[0113] Exemplarily, after obtaining the debugging result after execution, the client converts it into a CDP event that complies with the CDP protocol specification through the loaded SDK, and sends it to the debugging end via the server; at this time, the debugging end can receive the corresponding CDP event.

[0114] Exemplarily, the devtools on the debugging end consumes the received CDP events and displays the debugging results in the real-time preview panel. At this time, the second user can determine whether the debugging is successful based on the results displayed on the panel. If the debugging is successful, the process ends. If the debugging is unsuccessful, the debugging is repeated until it is successful.

[0115] For example, devtools can consume the received data and display the data in the corresponding panel, which is developer-friendly. For example, developers can see the application log of the client user in the log panel, and observe the client user's click, scroll and other operation behaviors in the real-time preview panel. The user's scrolling behavior will be synchronized to the preview interface of the real-time preview panel, and the user's click behavior will be presented in the real-time preview panel in the form of a highlight block. Developers can clearly identify the user's operation path by the position of the highlight block. Therefore, developers can locate problems based on the operation paths observed in the log panel and real-time preview panel of devtools, and finalize corresponding solutions based on the root cause of the problem to solve the problems faced by users.

[0116] Figure 5 A flowchart of another remote debugging method provided in an embodiment of the present application, which is applied to a debugging end, may include:

[0117] Step 301: Obtain a debugging identifier of the application to be debugged, and send the debugging identifier to the client through a third-party platform, so that the client loads the SDK according to the debugging identifier, and obtains the operation path of the first user for the application to be debugged based on the loaded SDK.

[0118] Step 302: receiving the operation path sent by the client via the server, obtaining the debugging code input by the second user according to the operation path, and returning the debugging code to the client via the server, so that the client executes the debugging code;

[0119] Step 303: Receive the debugging result after execution returned by the client via the server.

[0120] It should be noted that the aforementioned embodiment has exemplarily described the process of implementing remote debugging through interaction between the client and the debugging end, and to avoid repetition, it will not be described again here.

[0121] In order to better reflect the purpose of this application, based on the above embodiments of this application, the remote debugging process is further explained in combination with application scenarios.

[0122] In this application scenario, the application to be debugged is an H5 application to be debugged, the debugging identifier is a debugging identifier QR code, which will be referred to as the QR code hereinafter, the first user is a user, and the second user is a developer.

[0123] Figure 6 Flow chart of another remote debugging method according to an embodiment of the present application, such as Figure 6 As shown, the process may include:

[0124] Step 401: The developer logs in to the debugging terminal.

[0125] For example, a developer can log in to the debugging end using an account and password, and the debugging end performs a login status check to ensure that only developers with debugging permissions can perform remote debugging operations.

[0126] Step 402: The developer successfully logs in.

[0127] For example, the account and password entered by the developer are verified. If the verification passes, any debugging behavior of the developer will be logged in.

[0128] Step 403: Enter the URL of the H5 application to be debugged, the user ID, and the debugging enablement flag.

[0129] Exemplarily, the developer enters the URL of the H5 application to be debugged, the user ID, and the debugging enablement flag on the debugging terminal.

[0130] Step 404: Return the QR code to the developer.

[0131] Exemplarily, after receiving the URL of the H5 application to be debugged, the user ID, and the debugging enablement flag, the debugging end generates a QR code and returns it to the developer.

[0132] Step 405: The account manager's communication platform forwards the QR code to the user.

[0133] For example, the developer may send the generated QR code to the account manager's communication platform, and the account manager's communication platform may forward the QR code to the user.

[0134] Step 406: The user scans the code to open the H5 application to be debugged that integrates the SDK and confirms to start the debugging mode.

[0135] For example, the user opens the code scanning function of the client, scans the QR code to open the H5 application to be debugged, and in order to avoid loading the SDK for all users, resulting in traffic waste and unnecessary pressure on the server, it is necessary to implement on-demand loading of the SDK, and the SDK will only be loaded if the debug enablement mark is carried in the QR code. The specific method is to implement the logic of dynamically loading the SDK script according to the URL parameter in the H5 application to be debugged. In step S403, the generated QR code will carry the debug enablement mark, and the user can identify the debug enablement mark when opening the H5 application to be debugged after scanning the code, and load the SDK remotely.

[0136] Step 407: Establish a WebSocket connection.

[0137] For example, after the user chooses to turn on the debugging mode, the client's H5 application to be debugged will establish a two-way communication connection with the server based on the WebSocket protocol. After the connection is successfully established, the server generates a debugging record with a unique identifier based on the user ID and the URL of the H5 application to be debugged, and displays it in the debugging list of the debugging terminal.

[0138] Step 408: Filter the H5 application to be debugged from the debugging list according to the user ID, and open devtools to perform debugging operations.

[0139] For example, the developer selects the H5 application to be debugged from the debugging list of the debugging terminal according to the customer number, and clicks the debug button to open the devtools for debugging.

[0140] Step 409: Establish a WebSocket connection.

[0141] Exemplarily, the devtools of the debugging end and the server establish a two-way communication connection based on the WebSocket protocol. At this time, the messages sent by the client are forwarded to the debugging end via the server. Similarly, the messages sent by the debugging end are also forwarded to the client terminal via the server. The two realize indirect communication by transferring messages through the server.

[0142] Step 410: The developer opens the real-time preview mode and enters the debugging code.

[0143] Exemplarily, the developer requests to open the real-time preview mode in the real-time preview panel of the devtools extension, and enters the debugging code in the console panel of the devtools to obtain the context information and page status of the H5 application to be debugged.

[0144] Step 411: Convert the debugging code into CDP instructions that comply with the CDP specification.

[0145] For example, the debugging code input by the developer is converted into CDP instructions that comply with the CDP specification via devtools and sent to the server.

[0146] Step 412: Forward to the client.

[0147] Exemplarily, the server forwards the CDP instruction that complies with the CDP specification to the H5 application to be debugged on the client.

[0148] Step 413: The client receives the debugging code from the debugging end and executes the debugging code, and returns the debugging result after execution to the debugging end via the server.

[0149] For example, after receiving the CDP instruction, the H5 application to be debugged will be parsed and restored into debugging code according to the CDP protocol and executed. The debugging result after execution will be converted into CDP events that comply with the CDP protocol specification through the SDK and returned to the debugging end through the server. Devtools will consume the received CDP events and present the data in the corresponding panel. When the developer turns on the real-time preview mode, the interface currently seen by the user will be restored in a 1:1 ratio in the real-time preview panel, and the user's operation path and the state changes of the page after the operation can be observed in real time.

[0150] It should be noted that the above is a description of remote debugging from the developer's perspective. The following is a further description from the user's perspective, which includes the following steps:

[0151] Step 414: The user reproduces the problem.

[0152] Exemplarily, the user reproduces the problem of the H5 application to be debugged on the client.

[0153] Step 415: Convert the user's operation behavior and related application logs into specific CDP events.

[0154] For example, the user's operation behavior, the page status changes caused by the operation, and the related application logs are converted into specific CDP events via the SDK.

[0155] Step 416: Forward the CDP event to the debugging end.

[0156] Exemplarily, the client forwards the CDP event to the debugging end via the server.

[0157] Step 417: Display the debugging result in the real-time preview panel.

[0158] Exemplarily, devtools consumes the received CDP events and displays the debugged results in a real-time preview panel.

[0159] It can be seen that in the embodiment of the present application, the debugging end and the client use CDP as the communication specification, and both establish a two-way transmission channel with the server based on the WebSocket protocol, and realize indirect communication through the message transfer capability of the server. Among them, the debugging end uses devtools-frontend as the debugging interface, and adds a real-time preview panel based on devtools-frontend to view the customer's operation interface in real time, perceive the customer's scrolling and touch operations, and replace the original complex process that requires users to record videos to identify the operation path. It simulates the debugging experience of developers during development to a large extent, and realizes remote, cross-device restrictions, and compatibility with any browser to debug H5 applications. The H5 application of the client terminal obtains the ability to collect application information, communicate with the server, receive CDP instructions, and send CDP events by integrating SDK. The SDK sends the collected application log information and the execution results of the developer's debugging code to the server in the form of CDP events, which are forwarded by the server to the debugging end. The devtools-frontend of the debugging end can consume CDP events, thereby displaying relevant data on the corresponding panel, improving the efficiency of developers in problem location.

[0160] In the embodiment of the present application, the implementation process of remote debugging mainly includes four elements, namely, the debugging interface, the target debugging service, the protocol, and the transmission channel; illustratively, the debugging interface refers to devtools-frontend, which is essentially a web application that can receive CDP events and send CDP instructions. The target debugging service refers to the H5 application to be debugged on the client. Since the debugging interface selects devtools-frontend, the protocol refers to the supporting CDP protocol, and the protocol content is divided into several domains, each of which defines several commands it supports and the events it generates. In order to ensure the real-time communication, the WebSocket protocol is selected to implement a two-way transmission channel between the client and the debugging end.

[0161] For example, the debugging end uses devtools-frontend as the debugging interface, and expands the real-time preview panel on the original basis. The SDK is extended according to the CDP protocol specification, the ScreenPreview domain is added, and the corresponding instructions and events are added to the domain. The real-time preview panel can display the interface of the H5 application to be debugged opened by the customer, and the user's scrolling, clicking and other operations will be synchronized to the preview view in real time, replacing the original complex process that requires users to record videos to identify the operation path.

[0162] It should be noted that, in addition to the above four elements, since the terminals where the debugging interface and the target debugging service are located are not in the same geographical location and cannot rely on close-range hardware connections, it is necessary to add a server. The server is developed using Node.js, and the target debugging service is connected to the server based on the WebSocket protocol. The debugging interface is also connected to the server through the WebScoket protocol. The two forward messages through the server, so that the debugging interface and the target debugging service can achieve full-duplex communication.

[0163] In the embodiment of the present application, the H5 application to be debugged itself only contains relevant business logic and does not have the ability to receive CDP commands, send CDP events, and communicate with the server. It requires additional integration of SDK. The SDK has no association with the business code of the H5 application to be debugged. The SDK's functional code can be encapsulated in an independent script file for distribution.

[0164] For example, the main functions implemented by the SDK include: establishing a two-way communication connection with the server based on the WebSocket protocol; for key indicator data such as logs, errors and stack information, network, storage, etc. that developers are concerned about, the SDK proxies the browser's native methods and injects interception logic. For example, the SDK proxies all output methods on the console object. When the corresponding method on the console object is called in the code of the H5 application to be debugged to output the application log, while executing the browser's native method, the relevant parameters and information of the native method will also be collected, sorted and filled into CDP events according to the CDP protocol specification and sent to the server. It has the ability to collect H5 application fault information to be debugged, supports obtaining log content and specific log stack information, and when the H5 application to be debugged fails, developers can quickly locate the location of the problem source code based on the log stack information.

[0165] For example, in the integration of SDK, in order to avoid all users loading SDK, causing unnecessary traffic waste to users and bringing additional pressure to the server, the embodiment of the present application adopts an on-demand loading method, and pre-embeds the SDK script in the H5 application to be debugged in advance. The SDK is loaded only when the QR code carries the relevant debugging enablement logo. After the SDK is loaded, the H5 application to be debugged will pop up a window to prompt the user whether to turn on the debugging mode. Only after the user chooses to agree, the client will truly establish a remote debugging relationship with the debugging end.

[0166] In the embodiment of the present application, the debugging terminal also integrates a login module. Developers can only perform related debugging operations after successfully logging into the debugging terminal with a logged-in state. A QR code can be quickly generated through the URL of the H5 application to be debugged, the debug enablement flag, and the user number. After the user scans the QR code, the client will establish a connection with the server and add a debugging record to the debugging list. Developers can see the debugging record of the H5 application to be debugged in the debugging list of the debugging system, and can quickly index the H5 application to be debugged through the user number. Click the debug button to establish a debugging connection.

[0167] In the embodiment of the present application, developers can view application logs, fault information and stack information in the log panel of devtools-frontend. In this way, when the H5 application to be debugged runs into an error, the source code can be quickly located based on the application log and stack information, which facilitates developers to quickly locate the problem. In addition, developers can view the interface that the user is operating in the real-time preview panel, perceive the user's scrolling and touch operations, replacing the complex process that originally required users to record videos to identify the operation path. The operating information of the H5 application to be debugged can also be presented to the developer in a multi-dimensional graphical visualization method, which significantly reduces the difficulty of troubleshooting H5 applications, reduces communication costs, improves debugging efficiency, and enables remote, cross-device restrictions, and compatibility with any browser to debug H5 applications.

[0168] Figure 7 A schematic diagram of the structure of a remote debugging device according to an embodiment of the present application is shown in FIG. Figure 7 As shown, the device may include:

[0169] The first receiving module 500 is used to receive a debugging identifier of an application to be debugged; the debugging identifier is obtained by a debugging terminal and sent to the client via a third-party platform;

[0170] A loading module 501, used to load the SDK according to the debugging identifier;

[0171] The acquisition module 502 is used to acquire an operation path of the first user on the application to be debugged based on the loaded SDK, and send the operation path to the debugging end via the server, so that the debugging end acquires the debugging code input by the second user according to the operation path and returns it to the client via the server; the operation path represents at least one operation behavior performed by the first user on the application to be debugged, and the at least one operation behavior includes an abnormal operation behavior that triggers the application to be debugged to be abnormal;

[0172] The execution module 503 is used to execute the debugging code and return the debugging result after execution to the debugging end via the server.

[0173] In some embodiments, the loading module 501 is further used to:

[0174] Identify the debugging identifier to obtain an identification result;

[0175] In a case where it is determined according to the recognition result that the debug flag carries a debug enabling flag, the SDK is loaded.

[0176] In some embodiments, the apparatus further comprises a first establishing module, wherein the first establishing module is configured to:

[0177] After the SDK is loaded, a reminder message is generated to indicate whether to enable the debugging mode.

[0178] When receiving the opening instruction triggered by the first user in response to the opening reminder message, a two-way communication connection is established with the server.

[0179] In some embodiments, the debugging identifier carries the user ID of the first user and the URL of the application to be debugged, and the first establishing module is further used to:

[0180] After establishing a two-way communication connection with the server, the user number and the URL are sent to the server, so that the server generates and saves the debugging record of the application to be debugged according to the user number and the URL.

[0181] Figure 8 FIG. 1 is a schematic diagram of the structure of another remote debugging device according to an embodiment of the present application. Figure 8 As shown, the device may include:

[0182] The sending module 600 is used to obtain a debugging identifier of the application to be debugged, and send the debugging identifier to the client through a third-party platform, so that the client loads the SDK according to the debugging identifier, and obtains an operation path of the first user for the application to be debugged based on the loaded SDK; the operation path represents at least one operation behavior performed by the first user on the application to be debugged, and the at least one operation behavior includes an abnormal operation behavior that triggers the application to be debugged to be abnormal;

[0183] A generating module 601 is configured to receive an operation path sent by the client via the server, obtain a debugging code input by the second user according to the operation path, and return the debugging code to the client via the server, so that the client executes the debugging code;

[0184] The second receiving module 602 is used to receive the debugging result after execution returned by the client via the server.

[0185] In some embodiments, the sending module 600 is further used to:

[0186] When receiving a login request from the second user, obtaining the login information carried in the login request;

[0187] Verifying the login information to obtain a verification result;

[0188] When the verification result indicates that the verification has passed, a debugging identifier of the application to be debugged is obtained.

[0189] In some embodiments, the apparatus further comprises a second establishing module, wherein the second establishing module is configured to:

[0190] In the case of pulling the debugging record of the application to be debugged, determining whether a debugging instruction triggered by the second user for the application to be debugged is received; the debugging record is generated and saved by the server according to the user ID of the first user and the URL of the application to be debugged sent by the client;

[0191] If it is determined to be yes, a two-way communication connection is established with the server.

[0192] In some embodiments, the device further comprises a display module, wherein the display module is configured to:

[0193] When the real-time preview instruction triggered by the second user for the application to be debugged is received, a real-time preview panel is displayed, and the operation path is presented in the real-time preview panel.

[0194] In actual applications, the above-mentioned first receiving module 500, loading module 501, acquisition module 502, execution module 503, first establishment module, sending module 600, generation module 601, second receiving module 602, second establishment module and display module can all be implemented by a processor located in an electronic device, and the processor can be at least one of ASIC, DSP, DSPD, PLD, FPGA, CPU, controller, microcontroller, and microprocessor.

[0195] In addition, each functional module in this embodiment can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The above integrated unit can be implemented in the form of hardware or software functional modules.

[0196] If the integrated unit is implemented in the form of a software function module and is not sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this embodiment is essentially or the part that contributes to the relevant technology or the whole or part of the technical solution can be embodied in the form of a software product. The computer software product is stored in a storage medium, including several instructions for a computer device (which can be a personal computer, server, or network device, etc.) or a processor to perform all or part of the steps of the method of this embodiment. The aforementioned storage medium includes: a USB flash drive, a mobile hard disk, a read-only memory (ROM), a random access memory (RAM), a disk or an optical disk, and other media that can store program codes.

[0197] Specifically, a computer program instruction corresponding to a remote debugging method in this embodiment can be stored on a storage medium such as a CD, a hard disk, or a USB flash drive. When the computer program instruction corresponding to a remote debugging method in the storage medium is read or executed by an electronic device, any remote debugging method in the aforementioned embodiments is implemented.

[0198] Based on the same technical concept as the above embodiments, see Fig. 9 , which shows an electronic device 700 provided in an embodiment of the present application, which may include: a memory 701 and a processor 702; wherein,

[0199] Memory 701, used for storing computer programs and data;

[0200] The processor 702 is configured to execute a computer program stored in the memory to implement any one of the remote debugging methods in the foregoing embodiments.

[0201] In practical applications, the memory 701 may be a volatile memory, such as RAM; or a non-volatile memory, such as ROM, flash memory, hard disk drive (HDD) or solid-state drive (SSD); or a combination of the above types of memory, and provide instructions and data to the processor 702.

[0202] The processor 702 may be at least one of ASIC, DSP, DSPD, PLD, FPGA, CPU, controller, microcontroller, and microprocessor. It is understandable that for different remote debugging devices, the electronic device used to implement the processor function may also be other, which is not specifically limited in the embodiments of the present application.

[0203] In some embodiments, the functions or modules included in the device provided in the embodiments of the present application can be used to execute the method described in the above method embodiments. The specific implementation can refer to the description of the above method embodiments. For the sake of brevity, it will not be repeated here.

[0204] The above description of various embodiments tends to emphasize the differences between the various embodiments. The same or similar aspects can be referenced to each other, and for the sake of brevity, they will not be repeated herein.

[0205] The methods disclosed in the various method embodiments provided in this application can be arbitrarily combined without conflict to obtain new method embodiments.

[0206] The features disclosed in the various product embodiments provided in this application can be arbitrarily combined without conflict to obtain new product embodiments.

[0207] The features disclosed in the various method or device embodiments provided in this application can be arbitrarily combined without conflict to obtain new method embodiments or device embodiments.

[0208] Those skilled in the art will appreciate that the embodiments of the present application may be provided as methods, systems, or computer program products. Therefore, the present application may adopt the form of hardware embodiments, software embodiments, or embodiments in combination with software and hardware. Moreover, the present application may adopt the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to disk storage and optical storage, etc.) that contain computer-usable program code.

[0209] The present application is described with reference to the flowcharts and / or block diagrams of the methods, devices (systems), and computer program products according to the embodiments of the present application. It should be understood that each process and / or box in the flowchart and / or block diagram, as well as the combination of the processes and / or boxes in the flowchart and / or block diagram, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, an embedded processor, or other programmable data processing device to generate a machine, so that the instructions executed by the processor of the computer or other programmable data processing device generate instructions for implementing the processes in the flowchart and / or block diagram. Figure 1 A process or multiple processes and / or boxes Figure 1 A device that provides the functions specified in a block or multiple blocks.

[0210] These computer program instructions can also be loaded onto a computer or other programmable data processing device so that a series of operating steps are executed on the computer or other programmable device to produce a computer-implemented process, thereby providing instructions for implementing the process in the computer or other programmable device. Figure 1 A process or multiple processes and / or boxes Figure 1 The steps for the functions specified in one or more boxes.

[0211] The above are only preferred embodiments of the present application and are not intended to limit the protection scope of the present application.

Claims

1. A remote debugging method, characterized in that: Applied to a client, the method comprises: Receiving a debugging identifier of an application to be debugged; the debugging identifier is obtained by a debugging terminal and sent to the client via a third-party platform; According to the debugging identifier, loading the SDK; Based on the loaded SDK, an operation path of the first user on the application to be debugged is obtained, and the operation path is sent to the debugging end via the server, so that the debugging end obtains the debugging code input by the second user according to the operation path and returns it to the client via the server; the operation path represents at least one operation behavior performed by the first user on the application to be debugged, and the at least one operation behavior includes an abnormal operation behavior that triggers an abnormality in the application to be debugged; The debugging code is executed, and the debugging result after execution is returned to the debugging end via the server end.

2. The method according to claim 1, characterized in that The step of loading the SDK according to the debugging identifier includes: Identify the debugging identifier to obtain an identification result; In a case where it is determined according to the recognition result that the debug flag carries a debug enabling flag, the SDK is loaded.

3. The method according to claim 1 or 2, characterized in that: The method further comprises: After the SDK is loaded, a reminder message is generated to indicate whether to enable the debugging mode. When receiving the opening instruction triggered by the first user in response to the opening reminder message, a two-way communication connection is established with the server.

4. The method according to claim 3, characterized in that The debugging identifier carries the user ID of the first user and the URL of the application to be debugged, and the method further includes: After establishing a two-way communication connection with the server, the user number and the URL are sent to the server, so that the server generates and saves the debugging record of the application to be debugged according to the user number and the URL.

5. A remote debugging method, characterized in that: Applied to the debugging end, the method includes: Obtaining a debugging identifier of the application to be debugged, and sending the debugging identifier to a client through a third-party platform, so that the client loads an SDK according to the debugging identifier, and obtaining an operation path of a first user on the application to be debugged based on the loaded SDK; the operation path represents at least one operation behavior performed by the first user on the application to be debugged, and the at least one operation behavior includes an abnormal operation behavior that triggers an abnormality in the application to be debugged; receiving an operation path sent by the client via the server, acquiring a debugging code input by a second user according to the operation path, and returning the debugging code to the client via the server, so that the client executes the debugging code; Receive the debugging result after execution returned by the client via the server.

6. The method according to claim 5, characterized in that The step of obtaining the debugging identifier of the application to be debugged includes: When receiving a login request from the second user, obtaining the login information carried in the login request; Verifying the login information to obtain a verification result; When the verification result indicates that the verification has passed, a debugging identifier of the application to be debugged is obtained.

7. The method according to claim 5, characterized in that The method further comprises: In the case of pulling the debugging record of the application to be debugged, determining whether a debugging instruction triggered by the second user for the application to be debugged is received; the debugging record is generated and saved by the server according to the user ID of the first user and the URL of the application to be debugged sent by the client; If it is determined to be yes, a two-way communication connection is established with the server.

8. The method according to claim 5, characterized in that The method further comprises: When the real-time preview instruction triggered by the second user for the application to be debugged is received, a real-time preview panel is displayed, and the operation path is presented in the real-time preview panel.

9. A remote debugging device, characterized in that: Applied to a client, the device comprises: A first receiving module, configured to receive a debugging identifier of an application to be debugged; the debugging identifier is obtained by a debugging terminal and sent to the client via a third-party platform; A loading module, used to load the SDK according to the debugging identifier; an acquisition module, configured to acquire an operation path of a first user on the application to be debugged based on the loaded SDK, and send the operation path to the debugging end via the server, so that the debugging end acquires the debugging code input by the second user according to the operation path and returns it to the client via the server; the operation path represents at least one operation behavior performed by the first user on the application to be debugged, and the at least one operation behavior includes an abnormal operation behavior that triggers an abnormality in the application to be debugged; The execution module is used to execute the debugging code and return the debugging result after execution to the debugging end via the server end.

10. A remote debugging device, characterized in that: Applied to the debugging end, the device comprises: a sending module, configured to obtain a debugging identifier of the application to be debugged, and send the debugging identifier to a client through a third-party platform, so that the client loads an SDK according to the debugging identifier, and obtains an operation path of a first user for the application to be debugged based on the loaded SDK; the operation path represents at least one operation behavior performed by the first user for the application to be debugged, and the at least one operation behavior includes an abnormal operation behavior that triggers an abnormality in the application to be debugged; A generating module, configured to receive an operation path sent by the client via the server, obtain a debugging code input by the second user according to the operation path, and return the debugging code to the client via the server, so that the client executes the debugging code; The second receiving module is used to receive the debugging result after execution returned by the client via the server.

11. An electronic device, characterized in that: The device comprises a memory, a processor and a computer program stored in the memory and executable on the processor, and the method according to any one of claims 1 to 8 is implemented when the processor executes the program.

12. A computer storage medium having a computer program stored thereon, characterized in that: When the computer program is executed by a processor, the method according to any one of claims 1 to 8 is implemented.

13. A computer program product, comprising a computer program, characterized in that The computer program implements the method according to any one of claims 1 to 8 when executed by a processor.

Images