Small game debugging method and device and electronic equipment

Abstract

The invention relates to the technical field of software debugging, in particular to a small game debugging method and device and electronic equipment, and is used for solving the problem of how to efficiently debug. The method comprises the following steps: running a script of software to be debugged through a target kernel under the condition that communication connection with second electronic equipment running an integrated development environment is established through a public network room service server; the server receives first information sent by an integrated development environment through a public network room service server; analyzing the first information to obtain a debugging result corresponding to the service identifier; and debugging information carrying the to-be-debugged result is sent to the integrated development environment through the public network room service server.

Description

Technical Field

[0001] The present disclosure relates to the technical field of software debugging, and in particular to a method, device and electronic device for debugging a mini-game. Background Art

[0002] From the perspective of R&D, a mini-game needs to go through at least the development and debugging stages, from the project plan to the application implementation. An excellent mini-game integrated development environment not only needs to guarantee the basic development experience, but also needs to provide a good debugging experience.

[0003] At present, how to debug efficiently has become an urgent problem to be solved. Summary of the invention

[0004] In order to solve the above technical problems, the present disclosure provides a mini-game debugging method, device and electronic device. In order to achieve the above objectives, the present disclosure provides the following technical solutions:

[0005] In a first aspect, the present disclosure provides a method for debugging a mini-game, comprising: when a communication connection is established with a second electronic device running an integrated development environment through a public network room service server, running a script of software to be debugged through a target kernel; sending a service identifier of the script of the software to be debugged to the integrated development environment through the public network room service server; receiving first information sent by the integrated development environment through the public network room service server; parsing the first information to obtain a debugging result corresponding to the service identifier; and sending debugging information carrying the debugging result to be debugged to the integrated development environment through the public network room service server.

[0006] In a second aspect, the present disclosure provides a mini-game debugging device, including: a processing unit, which is used to run the script of the software to be debugged through a target kernel when a communication connection is established with a second electronic device running an integrated development environment through a public network room service server; the processing unit is also used to control a sending unit to send a service identifier of the script of the software to be debugged to the integrated development environment through the public network room service server; a receiving unit, which is used to receive first information sent by the integrated development environment through the public network room service server; the processing unit is also used to parse the first information received by the receiving unit to obtain a debugging result corresponding to the service identifier; the processing unit is also used to control the sending unit to send debugging information carrying the debugging result to the integrated development environment through the public network room service server.

[0007] In a third aspect, the present disclosure provides an electronic device, comprising: a memory and a processor, the memory being used to store a computer program; the processor being used to enable the electronic device to implement any one of the mini-game debugging methods provided in the first aspect when executing the computer program.

[0008] In a fourth aspect, the present invention discloses a computer-readable storage medium having a computer program stored thereon. When the computer program is executed by a computing device, the computing device implements any of the mini-game debugging methods provided in the first aspect.

[0009] In a fifth aspect, the present invention discloses a computer program product. When the computer program product is run on a computer, the computer implements any of the mini-game debugging methods provided in the first aspect.

[0010] The description of the second, third, fourth and fifth aspects in the present disclosure can refer to the detailed description of the first aspect; and the beneficial effects of the description of the second, third, fourth and fifth aspects can refer to the beneficial effect analysis of the first aspect, which will not be repeated here.

[0011] It should be noted that the above computer instructions may be stored in whole or in part on the first computer-readable storage medium. The first computer-readable storage medium may be packaged together with the processor of the mini-game debugging device, or may be packaged separately from the processor of the mini-game debugging device, and this disclosure does not limit this.

[0012] In the present disclosure, the name of the above-mentioned mini-game debugging device does not limit the device or functional module itself. In actual implementation, these devices or functional modules may appear with other names. As long as the functions of each device or functional module are similar to those of the present disclosure, they fall within the scope of the claims of the present disclosure and their equivalent technologies.

[0013] These and other aspects of the present disclosure will become more apparent from the following description.

[0014] Compared with the prior art, the technical solution provided by the present invention has the following advantages:

[0015] As can be seen from the above, the present disclosure can obtain the debugging result of the script of the software to be debugged by the target kernel of the first electronic device by establishing a communication connection between the second electronic device running the integrated development environment and the public network room service server, such as: the first electronic device establishes a communication connection with the second electronic device running the integrated development environment through the public network room service server, and runs the script of the software to be debugged through the target kernel. In order to let the integrated development environment of the second electronic device know the currently running script and the service identifier of the script, the first electronic device sends the service identifier of the script of the software to be debugged to the integrated development environment through the public network room service server, so that the user can know the script currently running by the first electronic device and the service identifier corresponding to the script. In this way, when it is necessary to query the debugging result of a script, the first information carrying the service identifier of the script to be queried can be sent to the first electronic device through the integrated development environment of the second electronic device. Thus, after the first electronic device receives the first information sent by the integrated development environment through the public network room service server, it parses the first information to obtain the debugging result corresponding to the service identifier; and sends the debugging information carrying the debugging result to the integrated development environment through the public network room service server. It can be seen that when the first electronic device tests the software to be debugged, the second electronic device can directly obtain the debugging result of the first electronic device testing the software to be debugged, which improves the efficiency of obtaining the debugging result and solves the problem of how to debug efficiently. BRIEF DESCRIPTION OF THE DRAWINGS

[0016] The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments consistent with the present disclosure and, together with the description, serve to explain the principles of the present disclosure.

[0017] In order to more clearly illustrate the embodiments of the present invention or the technical solutions in the prior art, the drawings required for use in the embodiments or the description of the prior art will be briefly introduced below. Obviously, for ordinary technicians in this field, other drawings can be obtained based on these drawings without paying any creative labor.

[0018] Figure 1 A schematic diagram of the network architecture of the mini-game debugging method provided in an embodiment of the present disclosure;

[0019] Figure 2 One of the flowcharts of the mini-game debugging method provided in the embodiment of the present disclosure;

[0020] Figure 3 The second flowchart of the mini-game debugging method provided in the embodiment of the present disclosure;

[0021] Figure 4 A schematic diagram of the structure of a first electronic device of a mini-game debugging method provided by an embodiment of the present disclosure;

[0022] Figure 5 One of the schematic diagrams of the floating window UI style of the mini-game debugging method provided in the embodiment of the present disclosure;

[0023] Figure 6 A second schematic diagram of a floating window UI style for a mini-game debugging method provided in an embodiment of the present disclosure;

[0024] Figure 7 A third schematic diagram of a floating window UI style for a mini-game debugging method provided in an embodiment of the present disclosure;

[0025] Figure 8 A fourth schematic diagram of a floating window UI style of a mini-game debugging method provided in an embodiment of the present disclosure;

[0026] Fig. 9 A fifth schematic diagram of a floating window UI style of a mini-game debugging method provided in an embodiment of the present disclosure;

[0027] Fig.10 A schematic diagram of the structure of a second electronic device of the mini-game debugging method provided by an embodiment of the present disclosure;

[0028] Fig.11 A schematic diagram of a process flow between a public network room service server and a second electronic device in a mini-game debugging method provided by an embodiment of the present disclosure;

[0029] Fig.12 The third flowchart of the mini-game debugging method provided in the embodiment of the present disclosure;

[0030] Fig.13 A fourth flowchart of the mini-game debugging method provided in an embodiment of the present disclosure;

[0031] Fig.14 A fifth flowchart of the method for debugging a mini-game provided in an embodiment of the present disclosure;

[0032] Fig.15 The sixth flowchart of the mini-game debugging method provided in the embodiment of the present disclosure;

[0033] Fig.16 Flow chart of the mini-game debugging method provided in the embodiment of the present disclosure, No. 7;

[0034] Fig.17 The eighth flowchart of the mini-game debugging method provided in the embodiment of the present disclosure;

[0035] Fig.18 A ninth flowchart of a method for debugging a mini-game provided in an embodiment of the present disclosure;

[0036] Fig.19The tenth flowchart of the mini-game debugging method provided in the embodiment of the present disclosure;

[0037] Fig. 20 11 is a flowchart of a method for debugging a mini-game provided in an embodiment of the present disclosure;

[0038] Fig.21 The twelfth flowchart of the mini-game debugging method provided in the embodiment of the present disclosure;

[0039] Fig. 22 13 is a flowchart of a method for debugging a mini-game provided in an embodiment of the present disclosure;

[0040] Fig.23 The fourteenth flowchart of the mini-game debugging method provided in the embodiment of the present disclosure;

[0041] Fig.24 The fifteenth flowchart of the mini-game debugging method provided in the embodiment of the present disclosure;

[0042] Fig.25 A sixteenth flowchart of a method for debugging a mini-game provided in an embodiment of the present disclosure;

[0043] Fig.26 A schematic diagram of the structure of a mini-game debugging device provided in an embodiment of the present disclosure. DETAILED DESCRIPTION

[0044] In order to more clearly understand the above-mentioned objectives, features and advantages of the present disclosure, the scheme of the present disclosure will be further described below. It should be noted that the embodiments of the present disclosure and the features in the embodiments can be combined with each other without conflict.

[0045] In the following description, many specific details are set forth to facilitate a full understanding of the present disclosure, but the present disclosure may also be implemented in other ways different from those described herein; it is obvious that the embodiments in the specification are only part of the embodiments of the present disclosure, rather than all of the embodiments.

[0046] It should be noted that, in this article, relational terms such as "first" and "second" are only used to distinguish one entity or operation from another entity or operation, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Moreover, the terms "include", "comprise" or any other variants thereof are intended to cover non-exclusive inclusion, so that a process, method, article or device including a series of elements includes not only those elements, but also other elements not explicitly listed, or also includes elements inherent to such process, method, article or device. In the absence of further restrictions, the elements defined by the sentence "comprise a ..." do not exclude the existence of other identical elements in the process, method, article or device including the elements.

[0047] Figure 1 A schematic diagram of the network architecture of the mini-game debugging method provided for the embodiment of the present disclosure includes a first electronic device 1 including a target kernel, a public network room service server 2, and a second electronic device 3 running an integrated development environment. Among them, the integrated development environment and the first electronic device 1 work together at both ends to support full-duplex long connections (WebSocket) as a communication channel for information. According to the information processing responsibilities, it can be subdivided into four specific user roles: integrated development environment, open debugging tools, native and target kernel, wherein the integrated development environment and debugging tools (such as Devtools) are located in the second electronic device 3, the native and target kernel are located in the first electronic device 1, and the first electronic device 1 is responsible for managing the life cycle of each user role. Devtools and the target kernel are the users of the preset protocol, responsible for parsing and executing the specific preset protocol information; the integrated development environment and native, as the intermediate bridge role, are responsible for packaging and distributing the communication information, and are also users of information of non-preset protocols, and will process some business customized logic.

[0048] In some examples, the overall process sequence diagram between the first electronic device 1, the public network room service server 2 and the second electronic device 3 is as follows: Figure 2 As shown in the figure, according to the connection status of the WebSocket long connection, it is divided into three stages: establishment stage, communication stage and disconnection stage.

[0049] Among them, 1. The connection establishment stage includes the following process: After the developer clicks the "scan code debugging" control displayed by the first electronic device 1, the native of the first electronic device 1 sends a request message to the integrated development environment of the second electronic device 3 through the public network room service server 2. After receiving the request message sent by the first electronic device 1 sent by the public network room service server 2, the integrated development environment of the second electronic device 3 sends a long connection request to the public network room service server 2. After receiving the long connection request sent by the integrated development environment of the second electronic device 3, the public network room service server 2 creates a debugging room service and sends the room identification code 1 of the debugging room to the second electronic device 3. After receiving the room identification code 1 sent by the public network room service server 2, the integrated development environment of the second electronic device 3 generates and displays the QR code corresponding to the room identification code 1. Afterwards, the developer can use the first electronic device 1 to scan the QR code displayed by the second electronic device 3, and the native of the first electronic device 1 sends a scan request to the second electronic device 3 through the public network room service server 2. The integrated development environment of the second electronic device 3 responds to the scanning request of the first electronic device 1 for the QR code, and the integrated development environment of the second electronic device 3 sends information carrying the program code of the software to be debugged and the room identification code 1 to the first electronic device 1 through the public network room service server 2. After receiving the information carrying the program code of the software to be debugged and the room identification code 1 sent by the public network room service server 2, the native of the first electronic device 1 establishes a long connection with the public network room service server 2, and enters the corresponding debugging room based on the room identification code 1, and the first electronic device 1 starts the JS context environment. After determining to establish a long connection with the first electronic device 1 and the first electronic device 1 enters the debugging room, the public network room service server 2 sends the first electronic device 1 online information to the integrated development environment of the second electronic device. After receiving the online information sent by the public network room service server 2, the second electronic device 3 sends authentication information (such as entrust authentication information) to the first electronic device 1 through the public network room service server 2. After receiving the authentication information sent by the public network room service server 2, the native of the first electronic device 1 completes the authentication, and sends a ready message carrying the device information of the first electronic device 1 (such as a device identification code, etc.) to the second electronic device 3 through the public network room service server 2. After the integrated development environment of the second electronic device 3 receives the ready message sent by the public network room service server 2, the integrated development environment of the second electronic device 3 successfully pulls up the Devtools panel. Among them, the ready message, as the first message to identify that the integrated development environment of the first electronic device 1 and the second electronic device 3 are officially communicating normally, will carry the device information of the first electronic device 1, and will be displayed on the panel by the integrated development environment of the second electronic device 3 when pulling up the Devtools panel.

[0050] 2. The communication stage (i.e., the stable debugging stage) includes the following process: the integrated development environments of the first electronic device 1 and the second electronic device 3 communicate in full duplex through the transparent transmission of the room service located on the public network room service server 2. The native located in the first electronic device 1 and the integrated development environment located in the second electronic device 3 are responsible for adding a layer of encapsulated information to the information to be sent and specifying the data type; wherein, the encapsulation header contains target (the room service uses this field and determines which end to send to), device identification (one first electronic device 1 corresponds to one device identification. When debugging multiple devices, the integrated development environment of the second electronic device 3 determines the first electronic device 1 that sends the information, that is, the specific sender of the information based on the device identification) and cursor (specify the specific data type), and then inserts it into the WebSocket pipeline after serialization; the Devtools of the second electronic device 3 is responsible for sending the CDP Method to the integrated development environment of the second electronic device 3 at certain operation times of the panel. The integrated development environment of the second electronic device 3 adds a layer of encapsulated information to the CDP Method sent by the Devtools, and specifies the data type to obtain encapsulated information. Then, the encapsulated information is serialized to obtain serialized encapsulated information. Afterwards, the integrated development environment of the second electronic device 3 sends the serialized encapsulation information to the public network room service server 2. After receiving the serialized encapsulation information sent by the second electronic device 3, the public network room service server 2 transparently transmits the serialized encapsulation information to the first electronic device 1. Afterwards, the native of the first electronic device 1 performs a deserialization operation on the serialized encapsulation information sent by the public network room service server 2. When it is determined that the distribution object is the target kernel, the native of the first electronic device 1 parses the deserialized encapsulation information to obtain information in a preset protocol format, such as CDPMethod. The target kernel is responsible for processing the CDP Method and encapsulating the processing result into CDP Callback information and returning it. The native of the first electronic device 1 adds a layer of encapsulation information to the CDP Callback information returned by the target kernel, and specifies the data type to obtain encapsulation information. Then, the encapsulation information is serialized to obtain serialized encapsulation information. Afterwards, the native of the first electronic device 1 sends the serialized encapsulation information to the public network room service server 2. After receiving the serialized encapsulation information sent by the first electronic device 1, the public network room service server 2 transparently transmits the serialized encapsulation information to the second electronic device 3. The integrated development environment of the second electronic device 3 performs a deserialization operation on the serialized package information sent by the public network room service server 2 to obtain the deserialized package information.At the same time, the integrated development environment of the second electronic device 3 parses the deserialized encapsulation information to obtain information in a preset protocol format, and sends the information in the preset protocol format to the Devtools of the second electronic device 3. At the same time, the target kernel of the first electronic device 1 will also actively send CDPEvent information to inform the Devtools of the second electronic device 3 of certain timings and corresponding information. Among them, the process of the target kernel of the first electronic device 1 sending CDP Event information to the Devtools of the second electronic device 3 is similar to the process of the target kernel of the first electronic device 1 sending CDP Callback information to the Devtools of the second electronic device 3, which will not be repeated here.

[0051] 3. There are mainly two scenarios in the disconnection stage, namely, a scenario in which the first electronic device 1 closes the software to be debugged and a scenario in which the second electronic device 3 closes and debugs the software to be debugged.

[0052] The implementation process of the scenario in which the first electronic device 1 closes the software to be debugged is as follows:

[0053] In response to the user operation of closing the software to be debugged, the native of the first electronic device 1 sends a first closing message (such as called close message 1) to the integrated development environment of the second electronic device 3 through the public network room service server 2; wherein the first closing message is used to instruct Devtools to change the connection state with the first electronic device 1 to unconnected. After the integrated development environment of the second electronic device 3 receives the close message 1 sent by the public network room service server 2, it sends the first closing message to the Devtools of the second electronic device 3. After receiving the first closing message sent by the integrated development environment of the second electronic device 3, the Devtools of the second electronic device 3 changes the connection state with the first electronic device 1 to unconnected. At the same time, the integrated development environment of the second electronic device 3 sends offline message 1 (such as called offline message 1) to the public network room service server 2; wherein the offline message 1 is used to indicate that the development and debugging tool has changed the connection state with the first electronic device to unconnected. At the same time, in response to the user operation of closing the software to be debugged, the native of the first electronic device 1 releases the resources occupied by the script of the software to be debugged (such as releasing the JS context environment), and sends offline message 2 (such as called offline message 2) to the public network room service server 2. The offline information 2 is used to indicate that the resources occupied by the script of the software to be debugged have been released.

[0054] 2. The implementation process of the scenario in which the second electronic device 3 closes the software to be debugged is as follows:

[0055] The Devtools of the second electronic device 3 responds to the user operation of closing the Devtools panel, closes the Devtools panel, and sends a closing message of closing the Devtools panel to the integrated development environment of the second electronic device 3. After receiving the closing message sent by the Devtools of the second electronic device 3, the integrated development environment of the second electronic device 3 sends a second closing message (such as called close message 2) to the first electronic device 1 through the public network room service server 2 to indicate that the development and debugging tools have been closed. At the same time, the integrated development environment of the second electronic device 3 sends an offline message 3 (such as called offline message 3) to the public network room service server 2. The offline message 3 is used to indicate that the Devtools panel has been closed. After receiving the close message 2 sent by the public network room service server 2, the native of the first electronic device 1 updates the status display floating window status to "disconnected", and sends an offline message 4 (such as called offline message 4) to the public network room service server 2. The offline message 4 is used to indicate that the Devtools of the second electronic device 3 has been determined to have closed the Devtools panel. Afterwards, the native of the first electronic device 1 continues to run the software to be debugged based on the target kernel normally until receiving a user operation to close the software to be debugged, and then releases the resources occupied by the script of the software to be debugged (such as releasing the JS context environment).

[0056] In some examples, based on Figure 2 One of the overall process sequence diagrams between the first electronic device 1, the public network room service server 2 and the second electronic device 3 is given. In the connection establishment stage, the first electronic device 1 will obtain the program code of the small game in the debugging environment by scanning the QR code. If there is a change in the software to be debugged during the debugging process, it is necessary to regenerate a new QR code by the integrated development environment of the second electronic device 3 after saving the code, and the first electronic device 1 scans the code again to obtain the regenerated QR code. For ease of operation, the small game debugging method provided in the embodiment of the present disclosure is as follows: Figure 3The second sequence diagram of the overall process between the first electronic device 1, the public network room service server 2 and the second electronic device 3 is provided, including the first connection phase scenario, the non-first connection phase scenario and the push disconnection phase scenario, which can realize the automatic push process of the program code of the mini-game. From the user's perspective, the integrated development environment of the second electronic device 3 is bound to the first electronic device 1 when the code is scanned for the first time. If there is a code change, you only need to click the "Push and Debug" button of the integrated development environment of the second electronic device 3 after saving the code to push the new program code of the mini-game to the first electronic device 1. From a technical perspective, in essence, when the code is scanned for the first time, a WebSocket dedicated to the program code push is established between the integrated development environment of the second electronic device 3 and the first electronic device 1, and the program code of the mini-game is pushed once. After that, each time the "Submit and Debug" button is clicked, the integrated development environment of the second electronic device 3 will push the new program code once through this additional WebSocket channel.

[0057] Among them, 1. The implementation process of the scenario in the first connection stage is as follows:

[0058] After the developer clicks the "scan code debugging" control displayed by the first electronic device 1, the native of the first electronic device 1 sends a request message to the integrated development environment of the second electronic device 3 through the public network room service server 2. After receiving the request message sent by the first electronic device 1 sent by the public network room service server 2, the integrated development environment of the second electronic device 3 sends a push long connection request to the push room service of the public network room service server 2. After receiving the push long connection request sent by the integrated development environment of the second electronic device 3, the public network room service server 2 creates a push room service and sends the room identification code 2 of the push room service to the second electronic device 3. After receiving the room identification code 2 sent by the public network room service server 2, the integrated development environment of the second electronic device 3 generates and displays the QR code corresponding to the room identification code 2. After that, the developer can use the first electronic device 1 to scan the QR code displayed by the second electronic device 3, and the native of the first electronic device 1 sends a scan request to the second electronic device 3 through the public network room service server 2. The integrated development environment of the second electronic device 3 responds to the scan request of the first electronic device 1 for the QR code, and the integrated development environment of the second electronic device 3 sends information carrying the room identification code 2 to the first electronic device 1 through the public network room service server 2. After receiving the information carrying the room identification code 2 sent by the public network room service server 2, the native of the first electronic device 1 establishes a long connection with the push room service of the public network room service server 2, and enters the corresponding push room based on the room identification code 1. After determining to establish a long connection with the first electronic device 1 and the first electronic device 1 enters the debugging room, the public network room service server 2 sends the information of the first electronic device 1 going online (such as called online information) to the integrated development environment of the second electronic device. After the integrated development environment of the second electronic device 3 receives the online information sent by the public network room service server 2, the integrated development environment of the second electronic device 3 sends a debugging long connection request to the debugging room service of the public network room service server 2. After receiving the debugging long connection request sent by the second electronic device 3, the debugging room service of the public network room service server 2 creates a debugging room service and sends the room identification code 3 corresponding to the debugging room service to the integrated development environment of the second electronic device 3. After receiving the room identification code 3, the integrated development environment of the second electronic device 3 sends the program code of the software to be debugged and the information of the room identification code 3 to the first electronic device 1 through the public network room service server 2. After receiving the information carrying the program code of the software to be debugged and the room identification code 3 sent by the second electronic device 3, the push room service of the public network room service server 2 sends the information carrying the program code of the software to be debugged and the room identification code 3 to the first electronic device 1.After the native of the first electronic device 1 receives the information sent by the public network room service server 2 carrying the program code of the software to be debugged and the room identification code 3, the JS context environment is started; at the same time, the native of the first electronic device 1 establishes a long connection with the debugging room service of the public network room service server 2, and enters the corresponding debugging room based on the room identification code 3. After determining that the first electronic device 1 has established a long connection with the debugging room service and the first electronic device 1 has entered the debugging room, the public network room service server 2 sends the information of the first electronic device 1 going online (such as called online information) to the integrated development environment of the second electronic device. After receiving the online information sent by the public network room service server 2, the integrated development environment of the second electronic device 3 sends authentication information (such as: entrust authentication information) to the first electronic device 1 through the debugging room service of the public network room service server 2. After receiving the authentication information sent by the public network room service server 2, the native of the first electronic device 1 completes the authentication, and sends the ready information carrying the device information (such as the device identification code, etc.) of the first electronic device 1 to the second electronic device 3 through the public network room service server 2. After the debugging room service of the public network room service server 2 receives the ready information, it forwards the ready information to the second electronic device 3. After the integrated development environment of the second electronic device 3 receives the ready information sent by the public network room service server 2, the integrated development environment of the second electronic device 3 successfully pulls up the Devtools panel. Among them, the ready information, as the first information to identify that the integrated development environment of the first electronic device 1 and the second electronic device 3 are officially communicating normally, will carry the device information of the first electronic device 1, and will be displayed on the panel by the integrated development environment of the second electronic device 3 when pulling up the Devtools panel.

[0059] 2. The implementation process of the scenario not in the first connection stage is as follows:

[0060] The native of the first electronic device 1 responds to the selection operation of the "push and debug" control, and sends a push message to the second electronic device 3 through the public network room service server 2. After the integrated development environment of the second electronic device 3 receives the push message sent by the public network room service server 2, it sends a third closing message (such as a close message) to the first electronic device 1 through the push room service of the public network room service server 2. After the native of the first electronic device 1 receives the third closing message sent by the public network room service server 2, it instructs the target kernel of the first electronic device 1 to release the resources occupied by the script of the software to be debugged. At the same time, the integrated development environment of the second electronic device 3 establishes a long connection with the debugging room service of the public network room service server 2. After establishing a long connection with the integrated development environment of the second electronic device 3, the debugging room service of the public network room service server 2 creates a debugging room service and sends the room identification code 4 corresponding to the debugging room service to the integrated development environment of the second electronic device 3. After receiving the room identification code 4, the integrated development environment of the second electronic device 3 sends information carrying the program code of the software to be debugged and the room identification code 4 to the first electronic device 1 through the public network room service server 2. After receiving the information of the program code of the software to be debugged and the room identification code 4 sent by the second electronic device 3, the push room service of the public network room service server 2 sends the information of the program code of the software to be debugged and the room identification code 4 to the first electronic device 1. After receiving the information of the program code of the software to be debugged and the room identification code 3 sent by the public network room service server 2, the native of the first electronic device 1 starts a new JS context environment; at the same time, the native of the first electronic device 1 establishes a long connection with the debugging room service of the public network room service server 2, and enters the corresponding debugging room based on the room identification code 4. After determining that the first electronic device 1 has established a long connection with the debugging room service and the first electronic device 1 has entered the debugging room, the public network room service server 2 sends the information of the first electronic device 1 going online (such as called online information) to the integrated development environment of the second electronic device. After receiving the online information sent by the public network room service server 2, the integrated development environment of the second electronic device 3 sends authentication information (such as: entrust authentication information) to the first electronic device 1 through the debugging room service of the public network room service server 2. After receiving the authentication information sent by the public network room service server 2, the native of the first electronic device 1 completes the authentication and sends the ready information carrying the device information (such as the device identification code, etc.) of the first electronic device 1 to the second electronic device 3 through the public network room service server 2. After receiving the ready information, the debugging room service of the public network room service server 2 forwards the ready information to the second electronic device 3.After the integrated development environment of the second electronic device 3 receives the ready information sent by the public network room service server 2, the integrated development environment of the second electronic device 3 successfully pulls up the Devtools panel. The ready information, as the first piece of information indicating that the integrated development environment of the first electronic device 1 and the second electronic device 3 are officially communicating normally, will carry the device information of the first electronic device 1 and will be displayed on the panel when the integrated development environment of the second electronic device 3 pulls up the Devtools panel.

[0061] 3. The implementation process of the push disconnection phase scenario is as follows:

[0062] The native of the first electronic device 1 responds to the binding operation of the "rebind device" control and sends binding information to the second electronic device 3 through the public network room service server 2. After the integrated development environment of the second electronic device 3 receives the binding information sent by the public network room service server 2, it sends a disconnection binding information (including the room identification code 3 corresponding to the push room service) to the push room service of the public network room service server 2; after the push room service of the public network room service server 2 receives the disconnection binding information (such as called offline information 1) sent by the second electronic device 3, it disconnects the service of the push room corresponding to the room identification code 3, and sends a disconnection information (such as called offline information 2) to the first electronic device 1.

[0063] It can be seen that Figure 2 Compared with the overall process sequence diagram between the first electronic device 1, the public network room service server 2 and the second electronic device 3, the Figure 3 The second sequence diagram of the overall process between the first electronic device 1, the public network room service server 2 and the second electronic device 3 is given. In the first connection phase, a new push room service will be started. The integrated development environment of the second electronic device 3 and the first electronic device 1 will push the device information and debug the program code of the mini-game through an additional push WebSocket. At the same time, in the non-first connection phase between the first electronic device 1 and the second electronic device 3 during the device binding cycle, the developer does not need to re-scan the code, but only needs to click the "Push and Debug" button to close the running mini-game and open a new mini-game for a new round of debugging.

[0064] In some examples, in the mini-game debugging method provided by the embodiments of the present disclosure, there are four supported debugging data panels, namely, the console panel, the source panel, the network panel, and the storage panel.

[0065] Exemplarily, the configuration information of each panel in the console panel, source panel, network panel, and storage panel is shown in Table 1.

[0066] Table 1

[0067]

[0068]

[0069] For the console panel and source panel, native can be considered as a pure transparent layer, and the information users and interacting subjects are Devtools and the target kernel. For the network panel and storage panel, native is the user of the information of the preset protocol, responsible for data interception, splicing and storage. The communication data will be spliced ​​into standard preset protocol information (CDP Event and CDP Callback).

[0070] In some examples, the structural diagram of the first electronic device 1 is as follows: Figure 4 As shown, the first electronic device 1 includes software to be debugged 1-1, a basic library 1-2, native 1-3 and an engine 1-4, native 1-3 includes a container layer 1-3-1 and a glue layer 1-3-2, the engine 1-4 includes a preset kernel (such as JSC) and a target kernel, and the container layer 1-3-1 includes a logic layer 1-3-1-1 and a rendering side 1-3-1-2.

[0071] Specifically, the module composition of the logic side 1-3-1-1 is shown in Table 2.

[0072] Table 2

[0073]

[0074]

[0075] Specifically, in the real machine debugging environment, the rendering engine of the software to be debugged is the self-developed engine Sonic Instance. Sonic Instance itself does not contain the JS runtime environment, but is bound to the JS kernel through NAPI, and the target kernel has been connected to NAPI through extension support. When the rendering side initializes Sonic's oc layer to encapsulate Sonic Instance, it will bind the JS context at two levels:

[0076] 1. In the C++ layer, in the real machine debugging environment, it is necessary to bind the NAPI environment NAPI_env and the target kernel context LepusContext during the initialization phase of NAPI.

[0077] 2. At the oc layer, when SonicRuntime is initialized when running on the rendering side, the DebugRuntime object will be passed in as an input parameter and handed over to SonicRuntime for weak holding. Since DebugRuntime holds the Context context of the JS kernel (QJContext, the glue layer encapsulation of the target kernel in the real machine environment), SonicRuntime can naturally hold the Context object weakly and inject JS callback logic or execute JS code at the right time.

[0078] Specifically, in order to allow developers to intuitively perceive the debugging WebSocket connection status of the first electronic device 1, a draggable connection status floating window will exist in the first electronic device 1 during the debugging of the software to be debugged. The DebugRuntime instantiates a Connect StatusWindow object at the same time as initialization, and its life cycle follows the entire life cycle of the DebugRuntime. When the WebSocket connection status changes, the Socket Proxy first receives the status callback and informs the DebugRuntime in the delegate proxy mode, and the DebugRuntime controls the connection status floating window to display the changes in the user interface (UI).

[0079] Exemplarily, the style of the connection status floating window is shown in Table 3.

[0080] Table 3

[0081]

[0082] Specifically, the role of glue layer 1-3-2 is mainly to shield the specific execution of the JS kernel from the container layer 1-3-1. The encapsulation classes JCContext and QJContext of JSC and the target kernel will bind and register themselves with a certain RuntimeType enumeration value at an earlier time. When JSRuntime is initialized, it will instantiate the corresponding Context context through RuntimeType. Since JSC has provided a set of available native OC interfaces, and the target kernel is still a pure C++ implementation layer. Therefore, the responsibilities and roles of their encapsulation classes JCContext / JCValue and QJContext / QJValue are also somewhat different:

[0083] 1. JCContext / JCValue is a pure transparent layer, which directly passes the calls from the container layer 1-3-1 to the JSC native interface. Its main function is to follow ContextProtocol and ValueProtocol respectively, which facilitates protocol abstraction and decoupling. In other words, the value type that interacts with the basic library JSSDK is still JSValue.

[0084] 2. QJContext / QJValue is the specific implementation of the target kernel in the oc layer. In addition to following ContextProtocol and ValueProtocol, its main function is to encapsulate a layer of oc implementation on the c++ layer and provide an oc interface aligned with JSC. The value type that interacts with the basic library JSSDK is QJValue.

[0085] In some examples, the structural diagram of the second electronic device 3 is as follows: Fig.10 As shown, the second electronic device 3 includes a room service RoomService3-1, Accessor3-2 and Devtools3-3, wherein Accessor3-2 is mainly responsible for distributing messages of the chrome devtools protocol.

[0086] Specifically, the communication process between the first electronic device 1 and the second electronic device 3 is as follows: 1. The integrated development environment of the second electronic device 3 connects to the room service; 2. The first electronic device 1 sends online information to the integrated development environment of the second electronic device 3; 3. The integrated development environment of the second electronic device 3 sends entrust information to the first electronic device 1; 4. The first electronic device 1 sends ready information (carrying device information) to the integrated development environment of the second electronic device 3; 5. The integrated development environment of the second electronic device 3 starts communicating with the first electronic device 1.

[0087] Specifically, the room service 3-1 of the second electronic device 3 is a relay station for the communication between the first electronic device 1 and the integrated development environment of the second electronic device 3, and is a WebSocket Server. When the developer clicks the real machine debugging button, the integrated development environment of the second electronic device 3 first calls the interface to apply for room service from the public network room service server 2. The public network room service server 2 will return gtoken (an identifier used for authentication) and roomid (a unique identifier for the room service), and create a WebSocket service at the same time. The integrated development environment of the second electronic device 3 generates a WebSocket uniform resource locator (Uniform Resource Locator, URL) based on gtoken and roomid, and connects to the remote WebSocket service based on the URL.

[0088] Specifically, Accessor mainly contains two objects: phoneConnection and DevtoolsConnection.

[0089] 1. phoneConnection inherits NodeJS's events.EventEmitter, and is mainly responsible for forwarding WebSocket messages from the room service. When messages are transmitted from the server-side room service to the integrated development environment, phoneConnection triggers events.EventEmitter.emit('message'); when messages need to be sent to the server-side room service, phoneConnection uses the WebSocket.send method in RoomService to send messages.

[0090] 2. DevtoolsConnection is a WebSocket object that connects to the local WebSocket server and is responsible for forwarding information of the Devtools preset protocol.

[0091] Exemplarily, the timing diagram of the integrated development environment of the public network room service server 2 and the second electronic device 3 is as follows: Fig.11 shown.

[0092] Among them, the room service of the public network room service server 2 establishes a long connection with the RoomService3-1 of the integrated development environment of the second electronic device 3. When the public network room service server 2 receives the message1 sent by the first electronic device 1, the room service of the public network room service server 2 sends the message1 to the RoomService3-1 of the integrated development environment of the second electronic device 3. RoomService3-1 sends a forwarded message1 to the phoneConnection of the integrated development environment of the second electronic device 3. The phoneConnection forwards the message1 to the DevtoolsConnection of the integrated development environment of the second electronic device 3. After receiving the message1 forwarded by the phoneConnection, the DevtoolsConnection deserializes the message1 to obtain the deserialized message1. Afterwards, the DevtoolsConnection parses the deserialized message1 to obtain the information 1 of the preset protocol. Afterwards, the DevtoolsConnection sends the obtained information 1 of the preset protocol to the Devtools of the integrated development environment of the second electronic device 3. After Devtools receives the preset protocol message 1 sent by DevtoolsConnection, it executes the preset protocol message 1 to obtain the corresponding debugging result. After that, Devtools sends the preset protocol message 2 carrying the debugging result to DevtoolsConnection. After receiving the preset protocol message 2 sent by Devtools, DevtoolsConnection serializes the preset protocol message 2 to obtain the serialized debugging result. At the same time, Devtools adds a layer of encapsulated information to the serialized debugging result, and specifies the data type to obtain message2. DevtoolsConnection forwards message2 to phoneConnection. After receiving message2 forwarded by DevtoolsConnection, phoneConnection forwards message2 to RoomService3-1. After receiving message2 sent by phoneConnection, RoomService3-1 forwards message2 to the room service of the public network room service server 2.

[0093] Specifically, the role of Devtools is that when the ready information from the first electronic device 1 is received in phoneConnection, the integrated development environment of the second electronic device immediately starts a BrowserWindow, and simultaneously starts a local WebSocket server and a Chrome Devtools Front-end project. The local WebSocket server is connected to Accessor.DevtoolsConnection, and the Chrome Devtools Front-end is also connected to the local WebSocket server. At this time, the debugging link is connected, and the integrated development environment of the first electronic device 1 and the second electronic device 3 are formally connected. When the developer manually closes the BrowserWindow, a close flag is sent to disconnect the debugging service.

[0094] In some examples, the preset protocol divides the capabilities of different directions by domain (Domains) - for example, the network-related Domain is Network, and the storage-related Domain is DOMStorage. The preset protocol instructions under each Domain are divided into Methods and Events according to different communication modes. Among them, Methods corresponds to the request / response mode of communication, and Events corresponds to the subscription / listening mode of communication. In layman's terms, the preset protocol instructions in Methods are actively issued by Devtools and wait for the callback response from the debugging backend; the preset protocol instructions in Events are actively notified by the debugging backend to Devtools of certain times and events. Therefore, in order to facilitate the explanation of the solution, taking the preset protocol as CDP as an example, the mini-game debugging method provided in the embodiment of the present disclosure defines the information of the preset protocols used to represent different flow directions and functions as shown in Table 4:

[0095] Table 4

[0096]

[0097] In some examples, in order to enable normal communication between the first electronic device 1 and the second electronic device 3, the first electronic device 1 needs to follow a preset protocol. The main protocols related to debugging are shown as follows:

[0098] 1. Source code display related: Debugger.scriptParsed is used to indicate to the debugger that the script has been parsed; Debugger.getScriptSource is used to indicate to the debugger that the script source is obtained.

[0099] 2. Breakpoint related: Debugger.setBreakpoint is used to instruct the debugger to set a breakpoint; Debugger.setBreakpointByURL is used to instruct the debugger to set a JavaScript breakpoint at a given location specified by a URL or URL regular expression; Debugger.setBreakpointsActive is used to instruct the debugger to set breakpoint activity (such as activating / deactivating all breakpoints on the page); Debugger.getPossibleBreakpoints is used to instruct the debugger to get the location of the breakpoint in the source code; Debugger.removeBreakpoint is used to instruct the debugger to delete the breakpoint; Debugger.continueToLocation is used to instruct the debugger to continue execution until a specific location is reached.

[0100] 3. Single-step debugging: Debugger.stepInto is used to instruct the debugger to step into (single-step into a function call); Debugger.stepOut is used to instruct the debugger to step out (step out of a function call); Debugger.stepOver is used to instruct the debugger to step over (single-step into a statement); Debugger.resume is used to instruct the debugger to resume JavaScript execution; Debugger.paused is used to instruct the debugger to pause (triggered when the first electronic device 1 stops due to a breakpoint, exception, or any other stop condition).

[0101] 4. The program is paused to display the stack and variables: Debugger.evaluateOnCallFrame is used to instruct the debugger to call the frame identifier; Runtime.compileScript is used to instruct the run to compile the script; Runtime.getProperties is used to instruct the run to return the properties of a given object.

[0102] 5. The console executes JS statements or prints variables: Runtime.compileScript is used to instruct the execution of compiled scripts; Runtime.evaluate is used to instruct the execution of expressions that calculate global objects.

[0103] 6. Enter A. in the console to display the properties of the A variable: Runtime.compileScript is used to indicate the run. Compile the script; Runtime.evaluate is used to indicate the run. Calculate the expression of the global object; Runtime.callFunctionOn is used to indicate the run. Details of the exception (or error) raised during script compilation or execution.

[0104] Afterwards, the first electronic device 1 and the second electronic device 3 can perform debugging communication according to a prescribed preset protocol.

[0105] Fig.12 is a flowchart of a method for debugging a mini game according to an exemplary embodiment. Fig.12 As shown, including the following S11-S15.

[0106] S11, when a communication connection is established with a second electronic device running an integrated development environment through a public network room service server, a script of the software to be debugged is run through a target kernel, wherein one script corresponds to one service identifier.

[0107] In some examples, in combination with the above Fig.12 In the example given, the first electronic device 1 and the second electronic device 3 can communicate with each other through Fig.12 A communication connection is established in the given connection establishment phase; thereafter, the integrated development environment of the second electronic device 3 can send information of the preset protocol to the first electronic device 1 to obtain the debugging results of the script, or other information (such as the source code of the script, breakpoint information, etc.).

[0108] In some examples, the software to be debugged contains at least one script. For ease of management, each script needs to be assigned a service identifier (such as a script number or other identifier that uniquely identifies the script) to facilitate subsequent management.

[0109] In some examples, the script of the software to be debugged may be pre-stored in the memory of the first electronic device 1, or the first electronic device 1 obtains the network storage address of the software to be debugged (such as obtaining the network storage address based on the program code of the software to be debugged) through the push room service of the public network room service server 2. The first electronic device 1 downloads the software to be debugged by accessing the network storage address, so that after adjusting the script of the software to be debugged, the adjusted software to be debugged can be obtained more quickly, thereby improving the user experience.

[0110] S12. Send the service identifier of the script of the software to be debugged to the integrated development environment through the public network room service server.

[0111] In some examples, the target kernel of the first electronic device 1 sends a service identifier of the script of the software to be debugged to the integrated development environment through the public network room service server.

[0112] S13, receiving first information sent by the integrated development environment through the public network room service server, wherein the first information includes a service identifier.

[0113] In some examples, since each script corresponds to a service identifier, when a user needs to check the debugging result of any script of the software to be debugged, the service identifier of the script can be determined first, and then the user can enter the service identifier of the corresponding script in the integrated development environment of the second electronic device 3, so that the integrated development environment of the second electronic device 3 can send the first information carrying the service identifier to the first electronic device 1 through the public network room service server 2. The native of the first electronic device 1 receives the first information sent by the public network room service server 2.

[0114] S14: parse the first information to obtain a debugging result corresponding to the service identifier.

[0115] In some examples, since the target kernel supports a preset protocol (such as CDP), when the user needs to view the debugging result of any script of the software to be debugged, the user can directly send the first information (including the service identifier of the script to be viewed (such as service identifier 1)) with the preset protocol to the first electronic device 1 through the second electronic device 3, so that the native of the first electronic device 1 performs a deserialization operation on the first information after receiving the first information, and determines the distribution object for executing the first information. If the distribution object is the target kernel, the native of the first electronic device 1 parses the first information based on the message usage role information of the first information, and obtains the information of the preset protocol corresponding to the first information. Afterwards, the native of the first electronic device 1 sends the information of the preset protocol to the target kernel of the first electronic device 1 for processing, and obtains the corresponding parsing result. Afterwards, the target kernel of the first electronic device 1 sends the parsing result to the native of the first electronic device 1. The native of the first electronic device 1 performs a serialization operation on the parsing result, and obtains the debugging result corresponding to the service identifier 1. Afterwards, the first electronic device 1 sends the debugging result to the second electronic device 3 through the public network room service server 2, so that the user can view the debugging result of the script corresponding to the service identifier 1 that needs to be viewed.

[0116] S15. Send debugging information including debugging results to the integrated development environment through the public network room service server.

[0117] In some examples, the target kernel of the first electronic device 1 sends debugging information carrying debugging results to the integrated development environment through the public network room service server.

[0118] In some examples, the first electronic device 1 can use a target interface (such as sendProtocolResponse or sendProtocolNotification) to send the debugging information from the public network room service server 2 to the integrated development environment of the second electronic device 3.

[0119] As can be seen from the above, the disclosed embodiment sets a target kernel in the first electronic device, so that the second electronic device running the integrated development environment can obtain the debugging result of the script of the software to be debugged by the target kernel of the first electronic device through the public network room service server. Since the target kernel of the first electronic device supports the target protocol, the first electronic device and the second electronic device can communicate through the target protocol, so that when the first electronic device tests the software to be debugged, the second electronic device can directly obtain the debugging result of the first electronic device testing the software to be debugged, completing the online debugging of the app on the first electronic device.

[0120] As an optional implementation of the present disclosure, Fig.12 ,like Fig.13 As shown, the above S14 can be specifically implemented through the following S140-S142.

[0121] S140: Deserialize the first information to determine a distribution object.

[0122] In some examples, combined Figure 4 In the example given, the distribution object includes JSC and the target kernel. Since JSC does not support the preset protocol, while the target kernel supports the preset protocol, after receiving the first information, the native of the first electronic device 1 needs to perform a deserialization operation on the first information to determine the distribution object, such as: when the distribution object is JSC, the first information is distributed to JSC for processing; when the distribution object is the target kernel, the first information is distributed to the target kernel for processing, thereby avoiding the problem of being unable to process the first information in a timely manner.

[0123] S141. When the distribution object is a target kernel, the first information is parsed based on a data type corresponding to the first information to obtain a parsing result.

[0124] In some examples, the data type includes information usage role information.

[0125] S142: Serialize the parsing result to obtain a debugging result corresponding to the service identifier.

[0126] As an optional implementation of the present disclosure, Fig.13 ,like Fig.14 As shown, the above S141 can be specifically implemented through the following S1410 and S1411.

[0127] S1410. When the distribution object is a target kernel, parse the first information based on the data type corresponding to the first information, and when it is determined that the first information is a first operation for indicating pausing the thread of the current test script, suspend the thread of the target kernel.

[0128] In some examples, when the distribution object is the target kernel, the native of the first electronic device 1 parses the first information based on the data type corresponding to the first information to obtain information of the preset protocol corresponding to the first information. Afterwards, the native of the first electronic device 1 sends the information of the preset protocol to the target kernel of the first electronic device 1 for processing to obtain the corresponding parsing result, such as: when the target kernel determines that the first information is the first operation for indicating the suspension of the thread of the current test script, the thread of the target kernel is suspended.

[0129] In some examples, when the protocol information corresponding to the first information (such as Debugger.pause, etc.) or a breakpoint is hit, the first electronic device 1 can call the runMessageLoopOnPause method to make the thread where the current line of the target kernel is located wait in a loop, thereby pausing the thread where the target kernel is located.

[0130] S1411, determining that the parsing result is the thread where the target kernel is suspended.

[0131] In some examples, the target kernel determines that the parsing result is a thread where the target kernel is suspended.

[0132] In some examples, when the thread where the target kernel is located is in a paused state, if protocol information sent by the second electronic device 3 is received, when the dispatchProtocolMessage method is used to determine that the distribution object is the target kernel, the target kernel will process the protocol information, and the target kernel will choose to continue in the paused state or end the paused state according to the processing result.

[0133] In some examples, the first operation may be single-step debugging Debugger.pause, hitting a breakpoint, single-step pause, etc.

[0134] As an optional implementation of the present disclosure, Fig.13 ,like Fig.15 As shown, the above S141 can be specifically implemented through the following S1412 and S1413.

[0135] S1412: When the distribution object is the target kernel, parse the first information according to the data type, and when it is determined that the first information is for instructing the debugger to execute a second operation for waking up the thread where the target kernel is located, wake up the thread where the target kernel is located.

[0136] In some examples, when the target kernel processes information of the preset protocol (such as: Debugger.resume, Debugger.stepInto, Debugger.stepOut, Debugger.stepOver, etc.) to restore the program from the paused state to the execution state, the target kernel calls the quitMessageLoopOnPause method to cancel the loop waiting of the thread, thereby waking up the thread of the target kernel.

[0137] In some examples, the second operation includes any of Debugger.resume, Debugger.stepInto, Debugger.stepOut, Debugger.stepOver.

[0138] In some examples, when the distribution object is the target kernel, the native of the first electronic device 1 parses the first information based on the data type corresponding to the first information to obtain information of the preset protocol corresponding to the first information. Afterwards, the native of the first electronic device 1 sends the information of the preset protocol to the target kernel of the first electronic device 1 for processing to obtain a corresponding parsing result, such as: when the target kernel determines that the first information is for instructing the debugger to execute the second operation of waking up the thread where the target kernel is located, the thread where the target kernel is located is woken up.

[0139] S1413: Determine that the parsing result is the thread where the target core has been awakened.

[0140] In some examples, the target core determines that the parsing result is a thread in which the target core has been awakened.

[0141] In some examples, when the thread of the target kernel is awakened, the target kernel executes a bytecode (a bytecode corresponds to a script). After the bytecode is executed, if there is no first information to be processed, the next bytecode is executed; if there is first information to be processed, the distribution object of the first information is determined.

[0142] As an optional implementation of the present disclosure, Fig.13 ,like Fig.16 As shown, the above S141 can be specifically implemented through the following S1414.

[0143] S1414. When the distribution object is a target kernel, parse the first information according to the data type, and when it is determined that the first information is a third operation, execute the third operation to obtain a parsing result corresponding to the third operation; wherein the third operation is an operation other than the first operation and the second operation.

[0144] In some examples, when the distribution object is the target kernel, the native of the first electronic device 1 parses the first information based on the data type corresponding to the first information to obtain information of the preset protocol corresponding to the first information. Afterwards, the native of the first electronic device 1 sends the information of the preset protocol to the target kernel of the first electronic device 1 for processing to obtain the corresponding parsing result, such as: when the target kernel determines that the first information is the third operation, the third operation is executed to obtain the parsing result corresponding to the third operation.

[0145] In some examples, when the target kernel is in the execution state, before executing each bytecode, a related method is called to obtain the protocol information of the second electronic device 3 and process it, otherwise the next bytecode is executed.

[0146] In some examples, when the protocol information corresponding to the first information is other protocols or situations, the target kernel will execute the first information regardless of whether the current thread is awakened or not, and obtain the corresponding parsing result.

[0147] As an optional implementation of the present disclosure, Fig.13 ,like Fig.17 As shown, the above S141 can be specifically implemented through the following S1415-S1417.

[0148] S1415: When the distribution object is the target kernel, the first information is parsed according to the data type, and when it is determined that the first information is a fourth operation for adding a first breakpoint in the first script, a breakpoint data structure of the first breakpoint is determined based on the first configuration information of the first breakpoint and the second configuration information of the first script, and data of the breakpoint data structure type is added to the breakpoint linked list. In the breakpoint linked list, one breakpoint corresponds to one breakpoint identification code.

[0149] In some examples, when the distribution object is the target kernel, the native of the first electronic device 1 parses the first information based on the data type corresponding to the first information to obtain information of the preset protocol corresponding to the first information. Afterwards, the native of the first electronic device 1 sends the information of the preset protocol to the target kernel of the first electronic device 1 for processing to obtain the corresponding parsing result, such as: when the target kernel determines that the first information is the fourth operation for adding a first breakpoint in the first script, based on the first configuration information of the first breakpoint and the second configuration information of the first script, the breakpoint data structure of the first breakpoint is determined, and the data of the breakpoint data structure type is added to the breakpoint linked list.

[0150] In some examples, when the distribution object is the target kernel, the native of the first electronic device 1 parses the first information based on the data type corresponding to the first information to obtain information of the preset protocol corresponding to the first information. Afterwards, the native of the first electronic device 1 sends the information of the preset protocol to the target kernel of the first electronic device 1 for processing to obtain the corresponding parsing result, such as: when the target kernel determines that the first information is the fourth operation for adding a first breakpoint in the first script, based on the first configuration information of the first breakpoint and the second configuration information of the first script, the breakpoint data structure of the first breakpoint is determined, and the data of the breakpoint data structure type is added to the breakpoint linked list.

[0151] In some examples, the first electronic device 1 needs to use a data structure to record basic debugging information during the process of completing the debugging protocol processing. The debugging information includes: debugging protocol queue, breakpoint information, JS script information, console information, and more important status information (such as the current single-step state, whether an exception is encountered, and information related to the variable list in the pause state), etc. This data structure type of data can be stored in the target kernel execution context. For each execution context, there is a data structure related to debugging.

[0152] Exemplarily, taking the data structure as a breakpoint data structure, the breakpoint data structure records all the information of the breakpoint, including: breakpoint_id: set a unique identification code (such as id) for each breakpoint; script_URL: the URL of the script to which the breakpoint belongs; script_id: the service identifier of the script to which the breakpoint belongs; line: the line number where the breakpoint is located; column: the column number where the breakpoint is located; condition: the condition that needs to be met for the breakpoint to hit, which is empty by default; pc: the bytecode where the breakpoint is located; specific_location: indicates whether the Debugger.continueToLocation information is currently being executed (we regard it as a special breakpoint); is_adjust: whether the breakpoint has been adjusted. For the setBreakpoint protocol, if there is no code at the location where the breakpoint is set, it needs to be adjusted. After the adjustment, this flag bit is set to a true value (true). After filling all the information of the breakpoint into the breakpoint data structure, the data of the breakpoint data structure type can be added to the breakpoint linked list.

[0153] S1416: When there is executable code in the code line where the first breakpoint is located, perform a fifth operation, wherein the fifth operation includes: constructing a first string identifier of the first breakpoint based on the breakpoint identification code, the first configuration information, and the second configuration information of the first script, and updating the total number of breakpoints included in the breakpoint linked list; wherein the first configuration information includes a line number and a column number, and the second configuration information includes a hash value and a uniform resource locator system.

[0154] In some examples, the target kernel performs the fifth operation when there is executable code in the code line where the first breakpoint is located.

[0155] S1417: Determine that the parsing result is a first string identifier that has completed construction of a first breakpoint.

[0156] In some examples, the target kernel determines that the parsing result is a first string identifier that has completed construction of a first breakpoint.

[0157] In some examples, when a user sets a breakpoint on a certain line of a script, the integrated development environment of the second electronic device 3 will send a Debugger.SetBreakpointByURL message. In the mini-game debugging method provided in an embodiment of the present invention, the first electronic device 1 needs to fill in the Breakpoint data structure, save the row and column numbers of the breakpoint, the service identifier of the script where the breakpoint is located, and other information, and save the data of this Breakpoint data structure type in the breakpoint linked list.

[0158] As an optional implementation of the present disclosure, Fig.17 ,like Fig.18 As shown, the mini-game debugging method provided by the embodiment of the present disclosure also includes S1418.

[0159] S1418: When there is no executable code in the code line where the first breakpoint is located, perform the sixth operation. The sixth operation includes: traversing the bytecodes of all previous functions in the first script, determining a target line with a line number less than or equal to the line threshold; based on the target line, updating the line number of the first breakpoint to the line number corresponding to the target line, and setting the adjustment field of the first breakpoint to a true value; based on the updated line number, column number, and second configuration information, constructing a first string identifier of the first breakpoint, and updating the total number of breakpoints included in the breakpoint linked list.

[0160] In some examples, when there is no executable code in the code line where the first breakpoint is located, the target kernel performs the sixth operation.

[0161] In some examples, the adjustment field may be an adjust field and the true value may be true.

[0162] As an optional implementation of the present disclosure, Fig.13 ,like Fig.19 As shown, the above S141 can be specifically implemented through the following S1419 and S1419-1.

[0163] S1419. When the distribution object is the target kernel, the first information is parsed according to the data type, and when it is determined that the first information is the seventh operation for deleting the second breakpoint in the script, based on the second string identifier corresponding to the deleted second breakpoint contained in the first information, the breakpoint list is traversed, and when it is determined that there is a third breakpoint identical to the second string identifier, the third breakpoint is deleted, and the total number of breakpoints contained in the breakpoint list is updated.

[0164] In some examples, when the distribution object is a target kernel, the native of the first electronic device 1 parses the first information based on the data type corresponding to the first information to obtain information of the preset protocol corresponding to the first information. Afterwards, the native of the first electronic device 1 sends the information of the preset protocol to the target kernel of the first electronic device 1 for processing to obtain the corresponding parsing result, such as: when the target kernel determines that the first information is the seventh operation for deleting the second breakpoint in the script, based on the second string identifier corresponding to the deleted second breakpoint contained in the first information, traverse the breakpoint chain list, and when it is determined that there is a third breakpoint identical to the second string identifier, delete the third breakpoint, and update the total number of breakpoints contained in the breakpoint chain list.

[0165] S1419-1. Determine that the analysis result is that the third breakpoint has been deleted.

[0166] In some examples, the target kernel determines that the parsing result is that deletion of the third breakpoint has been completed.

[0167] In some examples, when the user deletes a breakpoint in the current script, the integrated development environment of the second electronic device 3 will send a Debugger.removeBreakpoint protocol message. The target kernel of the present invention needs to find the corresponding breakpoint in the breakpoint list according to the string identifier in the protocol information and delete it from the breakpoint list.

[0168] In some examples, when executing the bytecode of the script, the target kernel needs to determine whether the current execution position is at a breakpoint, such as:

[0169] The target kernel determines whether the current breakpoint is in an active state (whether the Debugger.setBreakpointActive message has been received). If the Debugger.setBreakpointActive message has been received, it indicates that the current breakpoint is in an active state; at this time, the target kernel needs to determine whether the breakpoint list is empty. When the breakpoint list is empty, it means that the breakpoint is hit, and the target kernel suspends the current thread. When the breakpoint list is not empty, the target kernel obtains the line number, column number, and service identifier of the current execution position. After that, the target kernel determines that the service identifier, line number, and column number of the script where the current breakpoint is located are evenly the same as the line number, column number, and service identifier of the current execution position, which indicates that the breakpoint is hit, and the target kernel suspends the current thread. When the breakpoint list is not empty, the target kernel obtains the line number, column number, and service identifier of the current execution position. Afterwards, the target kernel determines that if the service identifier, line number, and column number of the script where the current breakpoint is located are different from the line number, column number, and service identifier of the current execution position, it means that the breakpoint is not hit, and the target kernel continues to execute the bytecode of the script.

[0170] If the Debugger.setBreakpointActive message is not received, it means that the current breakpoint is not activated. In this case, the breakpoint is not hit and the target kernel continues to execute the bytecode of the script.

[0171] As an optional implementation of the present disclosure, Fig.13 ,like Fig. 20 As shown, the above S141 can be specifically implemented through the following S1419-2 and S1419-3.

[0172] S1419-2. When the distribution object is the target kernel, the first information is parsed according to the data type, and when it is determined that the first information is the eighth operation for viewing the source code of the second script, based on the service identifier of the second script, the script linked list is traversed, and when it is determined that there is a third script with the same service identifier as the second script, the source code of the third script is obtained.

[0173] In some examples, when the distribution object is a target kernel, the native of the first electronic device 1 parses the first information based on the data type corresponding to the first information to obtain information of a preset protocol corresponding to the first information. Afterwards, the native of the first electronic device 1 sends the information of the preset protocol to the target kernel of the first electronic device 1 for processing to obtain a corresponding parsing result, such as: when the target kernel determines that the first information is an eighth operation for viewing the source code of the second script, based on the service identifier of the second script, traverses the script linked list, and when it is determined that there is a third script with the same service identifier as the second script, obtains the source code of the third script.

[0174] S1419-3. Send viewing information of the source code carrying the third script to the integrated development environment through the public network room service server.

[0175] In some examples, the target kernel sends viewing information carrying source code of the third script to the integrated development environment through the public network room service server.

[0176] In some examples, after compiling a script, the target kernel of the first electronic device 1 needs to actively send the Debugger.scriptParsed protocol information to the debugging second electronic device 3. The Debugger.scriptParsed protocol information contains the service identifier (such as id) of the current script, URL and other key information. In order to display the source code in the Devtools panel of the second electronic device 3, the second electronic device 3 will send the Debugger.getScriptSource protocol information. The target kernel of the first electronic device 1 obtains the source code of the script corresponding to the service identifier according to the service identifier in the information, and sends it to the integrated development environment of the second electronic device 3 in the protocol format to complete the display of the source code.

[0177] In some examples, after the target kernel compiles a script (i.e., the target kernel parses the current script), the target kernel creates a script data structure (e.g., ScriptSource data structure), and fills the script's Uniform Resource Locator System, service identifier, source code, script source map Uniform Resource Locator System and other information into the script data result, and saves the data of the script data structure type in the script linked list. Afterwards, when the target kernel receives the Debugger.getScriptSource protocol message, the target kernel parses the Debugger.getScriptSource protocol message to obtain the service identifier of the script. Afterwards, based on the service identifier, the script linked list is traversed to obtain the source code of the script corresponding to the service identifier. Afterwards, the target kernel sends the viewing information of the source code of the script corresponding to the service identifier to the integrated development environment of the second electronic device 3 through the public network room service server 2.

[0178] As an optional implementation of the present disclosure, the integrated development environment includes a development and debugging tool; Fig.12 ,like Fig.21 As shown, the mini-game debugging method provided by the present disclosure also includes S16 and S17.

[0179] S16: In response to the user operation of closing the software to be debugged, the public network room service server sends a first closing message to the integrated development environment, wherein the first closing message is used to instruct the development and debugging tool to change the connection state with the first electronic device to disconnected.

[0180] S17, in response to the user operation of closing the software to be debugged, releasing the resources occupied by the script of the software to be debugged, and sending offline information to the public network room service server, wherein the offline information is used to indicate that the resources occupied by the script of the software to be debugged have been released.

[0181] In some examples, the user can close the software to be debugged on the first electronic device 1. In order to avoid the situation where the first electronic device 1 has closed the software to be debugged, but the second electronic device 3 does not know that the first electronic device 1 has closed the software to be debugged, the first electronic device responds to the user operation of closing the software to be debugged and sends a first closing message (such as close message 1) to the integrated development environment through the public network room service server. In this way, the first electronic device 1 can respond to the user operation of closing the software to be debugged, release the resources occupied by the script of the software to be debugged, and send offline information to the public network room service server, so that the first electronic device 1 can release the resources occupied by the script of the software to be debugged, and notify the second electronic device 3 to change the connection status with the first electronic device to unconnected, so as to ensure the user experience.

[0182] As an optional implementation of the present disclosure, the integrated development environment includes a development and debugging tool; Fig.12 ,like Fig. 22 As shown, the mini-game debugging method provided by the present disclosure also includes S18 and S19.

[0183] S18: Receive second closing information sent by the integrated development environment through the public network room service server to indicate that the development and debugging tool has been closed.

[0184] S19: Based on the second closing information, when a user operation to close the software to be debugged is received, releasing resources occupied by the script of the software to be debugged.

[0185] In some examples, when the user no longer needs to debug the software to be debugged, the user can close Devtools on the integrated development environment of the second electronic device 3. In response to the operation of closing Devtools, the integrated development environment of the second electronic device 3 sends a second closing message (such as close message 2) to the first electronic device 1 through the public network room service server 2 to indicate that the development and debugging tools have been closed. In this way, after receiving the second closing message sent by the public network room service server 2, the native of the first electronic device 1 updates the status display floating window status to "disconnected" and sends an offline message 4 to the public network room service server 2. The offline message 4 is used to indicate that the Devtools of the second electronic device 3 has closed the Devtools panel. After that, the native of the first electronic device 1 continues to run the software to be debugged based on the target kernel normally until it receives a user operation to close the software to be debugged, and releases the resources occupied by the script of the software to be debugged (such as releasing the JS context environment).

[0186] As an optional implementation of the present disclosure, Fig.12 ,like Fig.23 As shown, the above S11 can be specifically implemented through the following S110 and S111.

[0187] S110: When a communication connection is established with a second electronic device running an integrated development environment through a public network room service server, in the process of running a script of the software to be debugged in the target kernel, obtaining location information of the bytecode corresponding to the currently running script, wherein the location information includes a line number and a column number.

[0188] S111. Based on the location information, traverse the breakpoint list, and when it is determined that there is a fourth breakpoint in the breakpoint list that is the same as the location information, suspend the thread where the target kernel is located, and send a suspension message carrying the location information and the service identifier of the script corresponding to the bytecode to the integrated development environment through the public network room service server.

[0189] In some examples, when the target kernel of the present invention executes JS bytecode, for each bytecode, the target kernel can obtain the location information of the current position, that is, the line number, column number and service identifier of the script where the current position is located. The target kernel needs to traverse all breakpoints in the breakpoint list to determine whether the current position is on the breakpoint. If so, it means that it should stop at this time. The target kernel calls RunMessageLoopOnPause to pause the current thread, and sends Debugger.paused information to display the current call stack and variables.

[0190] In some examples, when the current thread is paused due to breakpoints / exception / single-step or other reasons, the variables in the current global / closure / local scope will be displayed in the debug panel. This function is implemented through the information of the preset protocol of Debugger.paused and Runtime.getProperties. When the current thread is paused, the target kernel will actively send the Debugger.paused information. The callFrame field of this information represents the JS stack frame at the time of pause, and the scopeChain field contains the scope chain information of the corresponding function frame. A unique objectId will be assigned to the global / closure / local scope of each frame. For the variables in each scope, there is also a unique objectId. Next, the target kernel needs to process the Runtime.getProperties information sent by the integrated development environment of the second electronic device 3. According to the objectId in the Runtime.getProperties information, the target kernel gets the corresponding variable or scope and displays the variable or scope.

[0191] In some examples, the integrated development environment of the second electronic device 3 executes js statements or displays variable target kernels to obtain Runtime.compileScript and Runtime.evaluate information, parses strings in the protocol information that need to be parse and eval, and the first electronic device 1 compiles and executes, and returns the final result through protocol information.

[0192] As an optional implementation of the present disclosure, Fig.12 ,like Fig.24 As shown, the mini-game debugging method provided by the present disclosure also includes S20 and S21.

[0193] S20. After the target kernel compiles the script, based on the Uniform Resource Locator of the compiled script, the service identifier of the compiled script, the source code of the compiled script, and the Uniform Resource Locator of the source map of the compiled script, the script data structure of the compiled script is determined, and the data of the script data structure type is saved to the script linked list.

[0194] In some examples, the script information records the script information, and the most intuitive function is to display the source code information of the debug script in the debug panel. For some key debugging protocols (Debugger.paused, Debugger.getPossibleBreakpoints, Debugger.scriptParsed, Debugger.getScriptSource), it is necessary to return the hash value (hash) / URL / service identifier of the corresponding script for use by the integrated development environment of the second electronic device 3.

[0195] In some examples, the script information of a script includes link: all currently debugged scripts are recorded in a linked list, link records the position of the current script in the linked list; URL: the URL of the current script; source: the source code of the current script; hash: the hash value of the current script; id: the service identifier of the current script; length: the size of the current script; end_line: the line number of the last line of the current script; source_map_URL: if the current script uses a source map, this field is used to record the URL of the source map. Therefore, after obtaining the script information of the script, the script information of the script can be filled into the script data structure, and then the data of the script data structure type can be added to the script linked list.

[0196] S21. Send creation information of the service identifier carrying the compiled script to the integrated development environment through the public network room service server.

[0197] As an optional implementation of the present disclosure, Fig.12 ,like Fig.25 As shown, the mini-game debugging method provided by the present disclosure also includes S22-S25.

[0198] S22: When the thread of the target kernel is suspended, in response to the selection operation of the single-step operation control, the target kernel is controlled to save the theoretical line number and theoretical column number of the current script, the call stack depth of the current script, the theoretical service identifier of the current script, and the single-step type in the debugging context. The single-step type includes any one of step into, step out, and step across.

[0199] In some examples, when the single-step run button is clicked, the target kernel saves the line and column number of the current execution position, the call stack depth, the service identifier of the script, the single-step type (stepinto, step out, step over), etc. in the debugging context. Before executing the bytecode, single-step related processing is performed.

[0200] In the example, when the target kernel receives any single-step message among Debugger.stepinto, Debugger.step out, and Debugger.step over, the target kernel executes the following process:

[0201] When the target kernel determines that any single-step message among Debugger.stepinto, Debugger.step out, and Debugger.stepover is received and the Debugger.enable message is not received, the target kernel executes the next bytecode.

[0202] When the target kernel determines that any single-step message among Debugger.stepinto, Debugger.step out, and Debugger.stepover is received, and when the Debugger.enable message is received, the single-step type is determined based on the single-step message and recorded in the debugging context. Afterwards, the target kernel obtains the theoretical line number and theoretical column number of the current script, the call stack depth of the current script, and the theoretical service identifier of the current script, and records them in the debugging context. Afterwards, the target kernel returns a Response message to the integrated development environment of the second electronic device 3 through the public network room service server 2. At the same time, the target kernel actively sends a Debugger.resumed message to the integrated development environment of the second electronic device 3 through the public network room service server 2. At the same time, after the integrated development environment of the second electronic device 3 receives the Response message and the Debugger.resumed message sent by the public network room service server 2, the target kernel calls the QuitMesasgeLoopOnPause method to wake up the thread where the target kernel of the first electronic device 1 is located.

[0203] S23. Based on the current position information of the target kernel running the script, obtain the actual line number and the actual column number of the script, the actual service identifier of the script, and the execution stack depth corresponding to the script.

[0204] In some examples, the current location information represents the data structure of the current location. We need to get the current execution location and fill in the location data structure to know whether we need to stop at the breakpoint or continue running.

[0205] In some examples, the current position information includes script_id: the service identifier of the script where the current position is located; line / column: the line number and column number of the current position.

[0206] S24. Determine the type of single step to be executed based on the actual row number, the actual column number, the actual service identifier, the execution stack depth, the theoretical row number, the theoretical column number, the call stack depth, and the theoretical service identifier.

[0207] S25. Execute a bytecode according to the single-step type.

[0208] In some examples, when the target kernel is executing any of the received single-step messages Debugger.stepinto, Debugger.stepout, and Debugger.step over, the target kernel needs to determine whether the single-step message has been executed. The specific implementation process is as follows:

[0209] When the target kernel determines that the single-step message has not been completely executed, it continues to execute the remaining process of the single-step message.

[0210] When the target kernel determines that the single-step message has been executed, it obtains the current position information of the running script, obtains the actual line number and actual column number of the script, the actual service identifier of the script, and the execution stack depth corresponding to the script. After that, the target kernel determines the type of single step to be executed based on the actual line number, actual column number, actual service identifier, execution stack depth, theoretical line number, theoretical column number, call stack depth, and theoretical service identifier, such as:

[0211] When there is a theoretical line number that is the same as the actual line number, and there is a theoretical column number that is the same as the actual column number, and there is a theoretical service identifier that is the same as the actual service identifier, and there is a call stack depth that is the same as the execution stack depth, the target kernel executes the next bytecode.

[0212] When there is one or more different information in the theoretical line number, theoretical column number, call stack depth, and theoretical service identifier that are different from any of the actual line number, actual column number, actual service identifier, and execution stack depth (such as: the actual line number is different from the theoretical line number, and / or the actual column number is different from the theoretical column number, and / or the actual service identifier is different from the theoretical service identifier, and / or the execution stack depth is different from the call stack depth), if the single-step message is Debugger.Stepinto, based on the execution stack depth and the call stack depth, determine whether the execution stack depth has changed: if the execution stack depth and the call stack depth are different (indicating that the execution stack depth has changed), call the runMessageLoopOnPause method to make the current thread of the target kernel wait in a loop to pause the thread of the target kernel, such as: when the execution stack depth and the call stack depth are the same (indicating that the execution stack depth has not changed), and the script has not changed, and the actual stack depth is greater than the call stack depth, the target kernel executes the next bytecode. Alternatively, when the execution stack depth is the same as the call stack depth, the script changes, and the actual stack depth is less than or equal to the call stack depth, the target kernel calls the runMessageLoopOnPause method to make the current thread of the target kernel wait in a loop to achieve the suspension of the target kernel's thread; when the execution stack depth is the same as the call stack depth, the script changes, and the actual stack depth is greater than the call stack depth, the target kernel calls the runMessageLoopOnPause method to make the current thread of the target kernel wait in a loop to achieve the suspension of the target kernel's thread; when the execution stack depth is the same as the call stack depth, the script does not change, and the actual stack depth is greater than the call stack depth, the target kernel calls the runMessageLoopOnPause method to make the current thread of the target kernel wait in a loop to achieve the suspension of the target kernel's thread.

[0213] If the single-step message is Debugger.Stepout, and the actual stack depth is less than the call stack depth, the target kernel calls the runMessageLoopOnPause method to make the current thread of the target kernel wait in a loop to pause the thread of the target kernel. Alternatively, if the single-step message is Debugger.Stepout, and the actual stack depth is greater than the call stack depth, the target kernel executes the next bytecode.

[0214] If the single-step message is Debugger.Stepover and the script has not changed, the target kernel executes the next bytecode. Alternatively, if the single-step message is Debugger.Stepover and the execution stack depth is greater than the call stack depth when Stepover is clicked, the target kernel executes the next bytecode. Alternatively, if the single-step message is Debugger.Stepover and the script has not changed, and the execution stack depth is greater than the call stack depth when Stepover is clicked, the target kernel executes the next bytecode. Alternatively, if the single-step message is Debugger.Stepover and the script has changed, the target kernel calls the runMessageLoopOnPause method to make the current thread of the target kernel wait in a loop to pause the thread of the target kernel. Alternatively, if the single-step message is Debugger.Stepover, and the execution stack depth is less than or equal to the call stack depth when Stepover is clicked, the target kernel calls the runMessageLoopOnPause method to make the current thread of the target kernel wait in a loop to pause the thread of the target kernel; or if the single-step message is Debugger.Stepover, the script changes, and the execution stack depth is less than or equal to the call stack depth when Stepover is clicked, the target kernel calls the runMessageLoopOnPause method to make the current thread of the target kernel wait in a loop to pause the thread of the target kernel.

[0215] The above mainly introduces the solution provided by the embodiment of the present invention from the perspective of the method. In order to achieve the above functions, it includes hardware structures and / or software modules corresponding to the execution of each function. Those skilled in the art should easily realize that, in combination with the units and algorithm steps of each example described in the embodiments disclosed herein, the present invention can be implemented in the form of hardware or a combination of hardware and computer software. Whether a function is executed in the form of hardware or computer software driving hardware depends on the specific application and design constraints of the technical solution. Professional and technical personnel can use different methods to implement the described functions for each specific application, but such implementation should not be considered to exceed the scope of the present invention.

[0216] The embodiment of the present invention can divide the functional modules of the mini-game debugging device according to the above method example. For example, each functional module can be divided according to each function, or two or more functions can be integrated into one processing module. The above integrated module can be implemented in the form of hardware or in the form of software functional modules. It should be noted that the division of modules in the embodiment of the present invention is schematic and is only a logical function division. There may be other division methods in actual implementation.

[0217] like Fig.26 As shown, an embodiment of the present invention provides a structural schematic diagram of a mini-game debugging device 10, including a processing unit 101, a sending unit 102 and a receiving unit 103.

[0218] The processing unit 101 is used to run the script of the software to be debugged through the target kernel when a communication connection is established with a second electronic device running an integrated development environment through a public network room service server; wherein one script corresponds to one service identifier; the processing unit 101 is also used to control the sending unit 102 to send the service identifier of the script of the software to be debugged to the integrated development environment through the public network room service server; the receiving unit 103 is used to receive the first information sent by the integrated development environment through the public network room service server; the processing unit 101 is also used to parse the first information received by the receiving unit 103 to obtain the debugging result corresponding to the service identifier; the processing unit 101 is also used to control the sending unit 102 to send the debugging information carrying the debugging result to the integrated development environment through the public network room service server.

[0219] As an optional implementation of the present disclosure, the processing unit 101 is specifically used to deserialize the first information received by the receiving unit 103 to determine the distribution object; the processing unit 101 is specifically used to parse the first information based on the data type corresponding to the first information received by the receiving unit 103 when the distribution object is a target kernel to obtain a parsing result; the processing unit 101 is specifically used to serialize the parsing result to obtain a debugging result corresponding to the service identifier.

[0220] As an optional implementation of the present disclosure, the processing unit 101 is specifically used to parse the first information based on the data type corresponding to the first information received by the receiving unit 103 when the distribution object is the target kernel, and to suspend the thread of the target kernel when it is determined that the first information is a first operation for indicating pausing the thread of the current test script; the processing unit 101 is specifically used to determine that the parsing result is that the thread of the target kernel has been suspended.

[0221] As an optional implementation of the present disclosure, the processing unit 101 is specifically used to parse the first information received by the receiving unit 103 according to the data type when the distribution object is the target kernel, and wake up the thread where the target kernel is located when the first information is determined to be for instructing the debugger to execute the second operation of waking up the thread where the target kernel is located; the processing unit 101 is specifically used to determine that the parsing result is the thread where the target kernel is located that has been awakened.

[0222] As an optional implementation of the present disclosure, the processing unit 101 is specifically used to parse the first information received by the receiving unit 103 according to the data type when the distribution object is the target kernel, and when it is determined that the first information is a third operation, execute the third operation to obtain a parsing result corresponding to the third operation; wherein the third operation is an operation other than the first operation and the second operation.

[0223] As an optional implementation of the present disclosure, the processing unit 101 is specifically used to parse the first information received by the receiving unit 103 according to the data type when the distribution object is the target kernel, and when determining that the first information is for the fourth operation of adding a first breakpoint in the first script, determine the breakpoint data structure of the first breakpoint based on the first configuration information of the first breakpoint and the second configuration information of the first script, and add the data of the breakpoint data structure type to the breakpoint linked list; wherein, one breakpoint in the breakpoint linked list corresponds to one breakpoint identification code; the processing unit 101 is specifically used to perform the fifth operation when there is executable code in the code line where the first breakpoint is located; wherein the fifth operation includes: constructing a first string identifier of the first breakpoint based on the first configuration information and the second configuration information of the first script, and updating the total number of breakpoints included in the breakpoint linked list; wherein the first configuration information includes a row number and a column number, and the second configuration information includes a hash value and a uniform resource locator system; the processing unit 101 is specifically used to determine that the parsing result is the first string identifier of the first breakpoint that has been completed.

[0224] As an optional implementation of the present disclosure, the processing unit 101 is also used to perform a sixth operation when there is no executable code in the code line where the first breakpoint is located; wherein the sixth operation includes: traversing the bytecodes of all previous functions in the first script, and determining a target line with a line number less than or equal to a line threshold; based on the target line, updating the line number of the first breakpoint to the line number corresponding to the target line, and setting the adjustment field of the first breakpoint to a true value; based on the updated line number, column number, and second configuration information, constructing a first string identifier of the first breakpoint, and updating the total number of breakpoints included in the breakpoint linked list.

[0225] As an optional implementation of the present disclosure, the processing unit 101 is specifically used to parse the first information received by the receiving unit 103 according to the data type when the distribution object is the target kernel, and when it is determined that the first information is for the seventh operation of deleting the second breakpoint in the script, based on the second string identifier corresponding to the deleted second breakpoint contained in the first information, traverse the breakpoint list, and when it is determined that there is a third breakpoint identical to the second string identifier, delete the third breakpoint and update the total number of breakpoints contained in the breakpoint list; the processing unit 101 is specifically used to determine that the parsing result is that the third breakpoint has been deleted.

[0226] As an optional implementation of the present disclosure, the processing unit 101 is also used to parse the first information according to the data type when the distribution object is the target kernel, and when it is determined that the first information is the eighth operation for viewing the source code of the second script, traverse the script linked list based on the service identifier of the second script, and when it is determined that there is a third script with the same service identifier as the second script, obtain the source code of the third script; the processing unit 101 is also used to control the sending unit 102 to send the viewing information carrying the source code of the third script to the integrated development environment through the public network room service server.

[0227] As an optional implementation of the present disclosure, the integrated development environment includes a development and debugging tool; the processing unit 101 is further used to respond to a user operation of closing the software to be debugged, control the sending unit 102 to send a first closing information to the integrated development environment through the public network room service server; wherein the first closing information is used to indicate that the development and debugging tool changes the connection state with the first electronic device to unconnected; the processing unit 101 is further used to respond to the user operation of closing the software to be debugged, release the resources occupied by the script of the software to be debugged, and control the sending unit 102 to send offline information to the public network room service server. wherein the offline information is used to indicate that the resources occupied by the script of the software to be debugged have been released.

[0228] As an optional implementation of the present disclosure, the integrated development environment includes a development and debugging tool; the receiving unit 103 is also used to receive a second closing information sent by the integrated development environment through the public network room service server to indicate that the development and debugging tool has been closed; the processing unit 101 is also used to release the resources occupied by the script of the software to be debugged based on the second closing information received by the receiving unit 103, when a user operation to close the software to be debugged is received.

[0229] As an optional implementation of the present disclosure, the mini-game debugging device also includes an acquisition unit 104; a processing unit 101, which is specifically used to control the acquisition unit 104 to obtain the location information of the bytecode corresponding to the currently running script during the process of the target kernel running the script of the software to be debugged; wherein the location information includes the line number and the column number; the processing unit 101 is also used to traverse the breakpoint list based on the location information obtained by the acquisition unit 104, and when it is determined that there is a fourth breakpoint in the breakpoint list that is the same as the location information, suspend the thread where the target kernel is located, and control the sending unit 102 to send the pause information of the service identifier of the script corresponding to the location information and the bytecode to the integrated development environment through the public network room service server.

[0230] As an optional implementation of the present disclosure, the processing unit 101 is also used to determine the script data structure of the compiled script based on the Uniform Resource Locator of the compiled script, the service identifier of the compiled script, the source code of the compiled script, and the Uniform Resource Locator of the source map of the compiled script after the target kernel compiles the script, and save the data of the script data structure type to the script linked list; the processing unit 101 is also used to control the sending unit 102 to send the creation information carrying the service identifier of the compiled script to the integrated development environment through the public network room service server.

[0231] As an optional implementation of the present disclosure, the processing unit 101 is also used to control the target kernel to save the theoretical line number and theoretical column number of the current script, the call stack depth of the current script, the theoretical service identifier of the current script, and the single-step type in the debugging context in response to the selection operation of the single-step running control when the thread of the target kernel is suspended; wherein the single-step type includes any one of stepping into, stepping out and stepping over; the processing unit 101 is also used to obtain the actual line number and actual column number of the script, the actual service identifier of the script, and the execution stack depth corresponding to the script based on the current position information of the target kernel running the script; the processing unit 101 is also used to determine the single-step type to be executed based on the actual line number, the actual column number, the actual service identifier, the execution stack depth, the theoretical line number, the theoretical column number, the call stack depth, and the theoretical service identifier; the processing unit 101 is also used to execute a bytecode according to the single-step type.

[0232] Among them, all relevant contents of each step involved in the above method embodiment can be referred to the functional description of the corresponding functional module, and its role will not be repeated here.

[0233] Of course, the mini-game debugging device 10 provided in the embodiment of the present invention includes but is not limited to the above modules, for example, the mini-game debugging device 10 may also include a storage unit 105. The storage unit 105 may be used to store the program code of the mini-game debugging device 10, and may also be used to store data generated by the mini-game debugging device 10 during operation, such as data in a write request, etc.

[0234] The embodiment of the present application also provides a computer-readable storage medium for storing computer instructions executed by the above-mentioned mini-game debugging device 10.

[0235] The above description is only a specific embodiment of the present disclosure, so that those skilled in the art can understand or implement the present disclosure. Various modifications to these embodiments will be apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of the present disclosure. Therefore, the present disclosure will not be limited to the embodiments described herein, but will conform to the widest scope consistent with the principles and novel features disclosed herein.

Claims

1. A method for debugging a mini game, characterized in that: include: When a communication connection is established with a second electronic device running an integrated development environment through a public network room service server, a script of the software to be debugged is run through the target kernel; Sending the service identifier of the script of the software to be debugged to the integrated development environment through the public network room service server; Receiving first information sent by the integrated development environment through the public network room service server; Parsing the first information to obtain a debugging result corresponding to the service identifier; The debugging information carrying the debugging result is sent to the integrated development environment through the public network room service server.

2. The mini-game debugging method according to claim 1, characterized in that: The parsing of the first information to obtain a debugging result corresponding to the service identifier includes: Performing a deserialization operation on the first information to determine a distribution object; When the distribution object is the target kernel, parsing the first information based on a data type corresponding to the first information to obtain a parsing result; A serialization operation is performed on the parsing result to obtain a debugging result corresponding to the service identifier.

3. The mini-game debugging method according to claim 2, characterized in that: When the distribution object is the target kernel, parsing the first information based on the data type corresponding to the first information to obtain a parsing result includes: When the distribution object is the target kernel, the first information is parsed based on the data type corresponding to the first information, and when it is determined that the first information is a first operation for instructing to suspend the thread currently testing the script, the thread of the target kernel is suspended; It is determined that the parsing result is that the thread where the target kernel is located has been suspended.

4. The mini-game debugging method according to claim 2, characterized in that: When the distribution object is the target kernel, parsing the first information according to the data type to obtain a parsing result includes: When the distribution object is the target kernel, the first information is parsed according to the data type, and when it is determined that the first information is used to instruct the debugger to execute a second operation of waking up the thread where the target kernel is located, the thread where the target kernel is located is woken up; The analysis result is determined to be the thread where the target core has been awakened.

5. The mini-game debugging method according to claim 2, characterized in that: When the distribution object is the target kernel, parsing the first information according to the data type to obtain a parsing result includes: When the distribution object is the target kernel, the first information is parsed according to the data type, and when it is determined that the first information is a third operation, the third operation is executed to obtain a parsing result corresponding to the third operation; wherein the third operation is an operation other than the first operation and the second operation.

6. The mini-game debugging method according to claim 2, characterized in that: When the distribution object is the target kernel, parsing the first information according to the data type to obtain a parsing result includes: When the distribution object is the target kernel, the first information is parsed according to the data type, and when it is determined that the first information is a fourth operation for adding a first breakpoint in the first script, a breakpoint data structure of the first breakpoint is determined based on the first configuration information of the first breakpoint and the second configuration information of the first script, and data of the breakpoint data structure type is added to a breakpoint linked list; wherein one breakpoint in the breakpoint linked list corresponds to one breakpoint identification code; When there is executable code in the code line where the first breakpoint is located, perform a fifth operation; wherein the fifth operation includes: constructing a first string identifier of the first breakpoint based on the breakpoint identification code, the first configuration information and the second configuration information of the first script, and updating the total number of breakpoints included in the breakpoint linked list; wherein the first configuration information includes a line number and a column number, and the second configuration information includes a hash value and a uniform resource locator system; Determine that the parsing result is a first string identifier that has completed construction of the first breakpoint.

7. The mini-game debugging method according to claim 6, characterized in that: The method further comprises: When there is no executable code in the code line where the first breakpoint is located, perform a sixth operation; wherein the sixth operation includes: traversing the bytecodes of all previous functions in the first script, and determining a target line whose line number is less than or equal to a line threshold; based on the target line, updating the line number of the first breakpoint to a line number corresponding to the target line, and setting an adjustment field of the first breakpoint to a true value; based on the updated line number, the column number, and the second configuration information, constructing a first string identifier of the first breakpoint, and updating the total number of breakpoints included in the breakpoint linked list.

8. A mini-game debugging device, characterized in that: include: A processing unit, configured to run a script of the software to be debugged through the target kernel when a communication connection is established with a second electronic device running an integrated development environment through a public network room service server; The processing unit is further used to control the sending unit to send the service identifier of the script of the software to be debugged to the integrated development environment through the public network room service server; A receiving unit, configured to receive first information sent by the integrated development environment through the public network room service server; The processing unit is further configured to parse the first information received by the receiving unit to obtain a debugging result corresponding to the service identifier; The processing unit is further used to control the sending unit to send the debugging information carrying the debugging result to the integrated development environment through the public network room service server.

9. An electronic device, characterized in that: include: A memory and a processor, wherein the memory is used to store a computer program; and the processor is used to enable the electronic device to implement the mini-game debugging method described in any one of claims 1-7 when executing the computer program.

10. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores a computer program, and when the computer program is executed by a computing device, the computing device implements the mini-game debugging method described in any one of claims 1-7.

Images