Small program debugging method and device, storage medium and equipment

Abstract

The embodiment of the invention discloses an applet debugging method and device, a storage medium and equipment, which can be applied to various scenes such as cloud technology, artificial intelligence, intelligent traffic, auxiliary driving and the like. The method comprises the following steps: for a debugger running on a terminal, generating a preset simulator corresponding to the debugger, and establishing an association relationship between the debugger and the preset simulator; receiving configuration parameters sent by the debugger, determining a target applet to be debugged in a preset applet library according to the configuration parameters, loading the target applet into the preset simulator according to the association relationship, and returning a loading result to the debugger; and receiving a program debugging instruction sent by the debugger, transmitting the program debugging instruction to a preset simulator according to the association relationship, and running the program debugging instruction through a target applet in the preset simulator to obtain a corresponding program debugging result. According to the embodiment of the invention, the applet debugging efficiency can be improved.

Description

Technical Field

[0001] The present application relates to the field of program debugging technology, and in particular to a method, apparatus, storage medium, and device for debugging a small program. Background Art

[0002] Mini programs are lightweight applications that can run across multiple applications. Debugging mini programs is an essential part of the development process. With the increasing popularity of mobile internet, mini program debugging is crucial for ensuring code quality, fixing issues, optimizing performance, and ensuring multi-platform compatibility.

[0003] In related technologies, the debugging of mini-programs requires deploying the mini-programs during development on a real machine and running them. The running status of the mini-programs is then fed back to the debugging platform. The debugging process also requires building a special command line interface (CLI) on the debugging platform to perform debugging work through the debugging instructions provided by the CLI.

[0004] However, this method has high requirements for the real machine and debugging platform. It requires setting up the operating environment of the real machine and the debugging platform, and also requires a specially built CLI environment for debugging. This makes the debugging of the mini program time-consuming and labor-intensive, and the debugging has limitations. It not only increases the cost of mini program debugging, but also reduces the efficiency of mini program debugging. Summary of the Invention

[0005] The embodiments of the present application provide a method, apparatus, storage medium, and device for debugging a mini-program, which can improve the efficiency of mini-program debugging.

[0006] To solve the above technical problems, the embodiments of the present application provide the following technical solutions:

[0007] A first aspect of an embodiment of the present application provides a method for debugging a mini-program, comprising:

[0008] For a debugger running on a terminal, generating a preset simulator corresponding to the debugger, and establishing an association relationship between the debugger and the preset simulator;

[0009] receiving configuration parameters sent by the debugger, and determining a target applet to be debugged in a preset applet library according to the configuration parameters, loading the target applet into the preset simulator according to the association relationship, and returning the loading result to the debugger;

[0010] Receive the program debugging instruction sent by the debugger, transmit the program debugging instruction to the preset simulator according to the association relationship, and run the program debugging instruction through the target applet in the preset simulator to obtain a corresponding program debugging result.

[0011] A second aspect of the embodiments of the present application provides a method for debugging a mini-program, including:

[0012] In response to a configuration operation on the debugger, configuration parameters are obtained and sent to a cloud server, so that the cloud server determines a target applet to be debugged in a preset applet library according to the configuration parameters. The cloud server also generates a preset simulator corresponding to the debugger and establishes an association between the debugger and the preset simulator, so as to load the target applet into the preset simulator according to the association, and generate and return a loading result.

[0013] Receive the loading result sent by the cloud server, and in response to the program debugging instruction input on the debugger based on the loading result, send the program debugging instruction to the cloud server, so that the cloud server transmits the program debugging instruction to the preset simulator according to the association relationship, and runs the program debugging instruction through the target applet in the preset simulator to obtain corresponding program debugging results.

[0014] A third aspect of the embodiments of the present application provides a debugging device for an applet, including:

[0015] An encapsulation unit, configured to generate a preset simulator corresponding to a debugger running on a terminal, and establish an association relationship between the debugger and the preset simulator;

[0016] A mini-program loading unit, configured to receive configuration parameters sent by the debugger, determine a target mini-program to be debugged in a preset mini-program library according to the configuration parameters, load the target mini-program into the preset simulator according to the association relationship, and return the loading result to the debugger;

[0017] The debugging unit is used to receive the program debugging instruction sent by the debugger, transmit the program debugging instruction to the preset simulator according to the association relationship, and run the program debugging instruction through the target applet in the preset simulator to obtain corresponding program debugging results.

[0018] In some embodiments, the packaging unit is used to:

[0019] For debuggers respectively running on multiple terminals, generating a preset simulator corresponding to each debugger, and establishing an instruction transmission channel between each debugger and the preset simulator as an association relationship between each debugger and the preset simulator;

[0020] In some embodiments, the debugging unit is configured to:

[0021] The program debugging instruction is sent to the instruction transmission channel, the program debugging instruction is converted into a preset format through the instruction transmission channel, and the program debugging instruction in the preset format is transmitted to a corresponding preset simulator.

[0022] In some implementations, the debugger carries an application identifier, and the encapsulation unit is further configured to:

[0023] generating a preset simulator corresponding to the application identifier of each debugger, and establishing an instruction transmission channel between the debugger and the preset simulator;

[0024] In some embodiments, the debugging unit is further configured to:

[0025] The program debugging instruction in the preset format is transmitted to a preset simulator corresponding to the application identifier.

[0026] In some embodiments, after obtaining the corresponding program debugging result, the debugging unit is further configured to:

[0027] When the program debugging result indicates that an abnormal event occurs during the operation of the target applet, obtaining a target use case corresponding to the abnormal event in the target applet;

[0028] receiving a use case debugging instruction sent by the debugger, transmitting the use case debugging instruction to the preset simulator according to the association relationship, and running the use case debugging instruction through the target applet in the preset simulator to load the target use case and obtain a corresponding use case debugging result;

[0029] When the use case debugging result indicates that the target use case fails to load, obtaining a related internal interface function in the target applet;

[0030] Receive the interface debugging instruction sent by the debugger, transmit the interface debugging instruction to the preset simulator according to the association relationship, run the interface debugging instruction through the target applet in the preset simulator, and call the internal interface function during the running process to obtain the corresponding interface debugging result.

[0031] In some embodiments, the debugging unit is further configured to:

[0032] Determine a file path of a header file in the target applet according to the configuration parameters, and extract the header file according to the file path;

[0033] Relevant internal interface functions in the target applet are obtained from the header file.

[0034] In some embodiments, the debugging unit is further configured to:

[0035] Acquire multiple program programming interface functions when the target applet runs the use case debugging instruction;

[0036] Based on the plurality of program programming interface functions, internal instance information and internal attributes of the target applet are extracted from the header file, and the relevant internal interface functions in the target applet are obtained according to the internal instance information and internal attributes.

[0037] In some embodiments, the debugging unit is further configured to:

[0038] storing the internal interface function in a preset communication bridge by registering it, and setting a breakpoint for the internal interface function in the communication bridge based on the interface debugging instruction;

[0039] When it is recognized through the communication bridge that the internal interface function is called, the corresponding interface data is obtained, and the breakpoint is triggered to stop the running of the target applet, and the corresponding interface debugging result is obtained according to the interface data.

[0040] In some implementations, when there are multiple internal interface functions, the debugging unit is further configured to:

[0041] Setting a stack for the plurality of internal interface functions, and setting a corresponding breakpoint for each of the internal interface functions;

[0042] The interface debugging instruction is run through the target applet in the preset simulator and runs to the stack. Based on each breakpoint, each internal interface function is single-step debugged to obtain the interface debugging result corresponding to each internal interface function.

[0043] In some embodiments, the debugging apparatus for the applet further includes a preset simulator configuration unit, which is configured to:

[0044] Creating a virtual machine or a container, building an environment for the virtual machine or the container for running any applet in the preset applet library, and using the virtual machine or the container after the environment is built as the preset simulator;

[0045] Alternatively, a connection relationship with a preset mobile terminal is established, and a terminal environment of the preset mobile terminal is obtained according to the connection relationship, and the preset mobile terminal is used as the preset simulator based on the terminal environment.

[0046] A fourth aspect of the embodiments of the present application provides a debugging device for an applet, including:

[0047] A configuration input unit, configured to obtain configuration parameters in response to a configuration operation on the debugger, and send the configuration parameters to a cloud server, so that the cloud server determines a target applet to be debugged in a preset applet library according to the configuration parameters. The cloud server also generates a preset simulator corresponding to the debugger, establishes an association between the debugger and the preset simulator, loads the target applet into the preset simulator according to the association, and generates and returns a loading result.

[0048] An instruction input unit is used to receive the loading result sent by the cloud server, and in response to the program debugging instruction input on the debugger based on the loading result, send the program debugging instruction to the cloud server, so that the cloud server transmits the program debugging instruction to the preset simulator according to the association relationship, and runs the program debugging instruction through the target applet in the preset simulator to obtain corresponding program debugging results.

[0049] The fifth aspect of the embodiments of the present application provides a computer-readable storage medium, which stores multiple instructions, and the instructions are suitable for a processor to load to execute the steps of the debugging method of the applet in the above-mentioned first aspect embodiment, or to execute the steps of the debugging method of the applet in the above-mentioned second aspect embodiment.

[0050] The sixth aspect of the embodiments of the present application provides a computer device, including a memory, a processor, and a computer program stored in the memory and capable of running on the processor. When the processor executes the computer program, it implements the steps of the method for debugging the applet in the embodiment of the first aspect, or executes the steps of the method for debugging the applet in the embodiment of the second aspect.

[0051] A seventh aspect of the present application provides a computer program product or computer program, comprising computer instructions stored in a storage medium. A processor of a computer device reads the computer instructions from the storage medium and executes the computer instructions to implement the steps of the method for debugging a mini-program in the first aspect of the present application, or to execute the steps of the method for debugging a mini-program in the second aspect of the present application.

[0052] The embodiment of the present application generates a preset simulator corresponding to the debugger running on the terminal, and establishes an association relationship between the debugger and the preset simulator; receives configuration parameters sent by the debugger, and determines the target applet to be debugged in the preset applet library based on the configuration parameters, and loads the target applet into the preset simulator based on the association relationship, and returns the loading result to the debugger; receives program debugging instructions sent by the debugger, transmits the program debugging instructions to the preset simulator based on the association relationship, and runs the program debugging instructions through the target applet in the preset simulator to obtain corresponding program debugging results. In this way, by establishing an association between the debugger and the preset simulator, the debugger on the terminal can send configuration parameters to the cloud server remotely according to the needs of debugging, and the cloud server can load the target applet to be debugged into the preset simulator according to the configuration parameters. During the debugging process, when the debugger sends the program debugging instruction to the cloud server, debugging can be initiated. The cloud server can transmit the program debugging instruction to the preset simulator according to the association, and run the program debugging instruction through the target applet in the preset simulator, so that the applet that needs to be debugged does not need to be run and loaded locally on the terminal, and the terminal no longer needs to set up a real machine running environment. Instead, the entire process is debugged remotely on the cloud server, and debugging is initiated through the debugger on the terminal without the need to set up a special debugging environment. Therefore, terminals of any operating system can perform remote debugging of the applet through the debugger to obtain the required program debugging results. The limitations of debugging are greatly reduced, which ultimately not only reduces the cost of applet debugging but also improves the efficiency of applet debugging.

[0053] Other features and advantages of the present disclosure will be described in the following description, and in part will become apparent from the description, or will be understood by practicing the present disclosure. The purposes and other advantages of the present disclosure can be realized and obtained by the structures particularly pointed out in the description, claims and drawings. BRIEF DESCRIPTION OF THE DRAWINGS

[0054] In order to more clearly illustrate the technical solutions in the embodiments of the present application, the following briefly introduces the drawings required for use in the description of the embodiments. Obviously, the drawings described below are only some embodiments of the present application. For those skilled in the art, other drawings can be obtained based on these drawings without creative work.

[0055] Figure 1 This is a schematic diagram of a scenario for implementing the debugging method of the mini-program provided in an embodiment of the present application;

[0056] Figure 2 This is a flowchart of a method for debugging a mini-program provided in an embodiment of the present application;

[0057] Figure 3 is a schematic diagram of a virtual machine or container provided in an embodiment of the present application as a preset simulator;

[0058] Figure 4 is a schematic diagram of a preset mobile terminal provided in an embodiment of the present application as a preset simulator;

[0059] Figure 5 This is a schematic diagram of creating a preset mini-program library provided by an embodiment of the present application;

[0060] Figure 6 This is a schematic diagram of managing and maintaining a preset mini-program library provided by an embodiment of the present application;

[0061] Figure 7 It is a schematic diagram of transmitting a program debugging instruction in a preset format to a corresponding preset simulator provided by an embodiment of the present application;

[0062] Figure 8 This is a schematic diagram of obtaining internal interface functions from header files through runtime and reflection technology provided by an embodiment of the present application;

[0063] Figure 9 This is a schematic diagram of identifying internal interface functions through bridging provided by an embodiment of the present application;

[0064] Figure 10 This is a complete flowchart of the mini-program debugging process provided by the embodiment of the present application;

[0065] Figure 11 This is another flowchart of the debugging method of the mini-program provided in an embodiment of the present application;

[0066] Figure 12 This is a schematic diagram of the structure of the debugging device of the mini-program provided in the embodiment of the present application;

[0067] Figure 13 This is another structural diagram of the debugging device for the mini-program provided in an embodiment of the present application;

[0068] Figure 14 It is a schematic diagram of the structure of the terminal provided in an embodiment of the present application. DETAILED DESCRIPTION

[0069] In order to enable those skilled in the art to better understand the solutions of this application, the technical solutions in the embodiments of this application will be clearly and completely described below in conjunction with the drawings in the embodiments of this application. Obviously, the described embodiments are only part of the embodiments of this application, not all of the embodiments. Based on the embodiments in this application, all other embodiments obtained by those skilled in the art without making any creative efforts shall fall within the scope of protection of this application.

[0070] It can be understood that in the specific implementation of this application, when it comes to retrieving data generated during the debugging process of the preset mini-program library or the target mini-program, when the above embodiments of this application are applied to specific products or technologies, it is necessary to obtain the object's permission or consent, and the collection, use and processing of relevant data must comply with relevant laws, regulations and standards.

[0071] In addition, when the embodiment of the present application needs to call the data generated during the debugging process of the preset mini-program library or the target mini-program, a separate license or separate consent for the data generated during the debugging process of the preset mini-program library or the target mini-program will be obtained through a pop-up window or jumping to a confirmation page. After clearly obtaining the separate license or separate consent for the data generated during the debugging process of the preset mini-program library or the target mini-program, the necessary general test cases and test-related data for the normal operation of the embodiment of the present application will be obtained.

[0072] It should be noted that some processes described in the specification, claims, and figures above include multiple steps that appear in a specific order. However, it should be understood that these steps may be executed in a different order or in parallel. Step numbers are used solely to distinguish between different steps and do not imply any order of execution. Furthermore, terms such as "objective" are used herein to distinguish similar objects and do not necessarily describe a specific order or sequence.

[0073] In the embodiments of the present application, the term "module" or "unit" refers to a computer program or a part of a computer program that has a predetermined function and works together with other related parts to achieve a predetermined goal, and can be implemented in whole or in part by using software, hardware (such as processing circuits or memories) or a combination thereof. Similarly, a processor (or multiple processors or memories) can be used to implement one or more modules or units. In addition, each module or unit can be part of an overall module or unit that includes the function of the module or unit.

[0074] Before further explaining the embodiments of the present disclosure in detail, the nouns and terms involved in the embodiments of the present disclosure are explained. The nouns and terms involved in the embodiments of the present disclosure are subject to the following interpretations:

[0075] Mini programs are lightweight applications that sit somewhere between traditional Hypertext Markup Language (HTML) pages and applications (APPs). Mini programs rely on a host application to run, and there can be many types of host applications. These host applications can provide various functions, such as resource transfer, communication, purchasing, express delivery, ticket sales and collection, rentals, and more. Compared to traditional applications, mini programs do not require downloading or installation and can be accessed directly by scanning a QR code, searching, or using recommendations.

[0076] A Software Development Kit (SDK) is a collection of development tools used to build application software for a specific software package, software framework, hardware platform, operating system, or other application. It helps developers build applications more quickly and implements common features. Different software and platforms have their own SDKs. By using an SDK, developers can accelerate development, improve application quality, and fully leverage the capabilities and features of the platform or device.

[0077] The mini program engine is the terminal SDK environment in which the mini program runs. For example, it can be a chat software that uses a certain chat software as the host platform and can run on a desktop system, or a chat software that can also run on a mobile terminal system. In addition to chat software, it can also host any other application, such as an e-commerce software.

[0078] A debugger is a development tool used to help identify and resolve program errors and issues. It provides a range of functions and tools to perform operations such as checking code execution, viewing and modifying variables, setting breakpoints, and outputting debugging information while the program is running. When a program's debugger catches an exception or event, it determines whether to handle the exception or event based on its own logic. This behavior varies depending on the platform.

[0079] The Command Line Interface (CLI) is a way for debuggers to interact with a computer, running programs or commands by entering text, and then returning the results in text form. When debugging applets, you need to use the CLI to perform specific operations, such as starting a server and running tests.

[0080] JavaScript (Java Script) is an object-based, event-driven, and secure interpreted scripting language. Its purpose is to add dynamic effects and interactive capabilities to client-side web pages, thereby achieving a real-time, dynamic interactive relationship between users and web pages.

[0081] Secure Shell (SSH) is a network protocol used for secure remote login and data transmission over insecure networks. It uses encryption technology to ensure the security of remote connections and provides functions such as terminal access, file transfer, and remote command execution.

[0082] In related technologies, mini-program debugging requires deploying the mini-program during development on a real device and running it. The mini-program's running status is then fed back to the debugging platform. For example, it is necessary to run the corresponding real-device mini-program in advance and publish it to an open platform for access by applications on mobile terminals such as mobile phones. When the run is successful, a mini-program real-device debugging QR code will be returned for the application to scan. The mini-program can be viewed by scanning the code using the application on the corresponding mobile terminal and tested on the debugging platform. At the same time, during the debugging process, a debugging connection that can be opened in the debugging platform is output. The debugging platform uses a private CLI to build a debugging command provided by the CLI to perform debugging work.

[0083] However, this method has high requirements for the real machine and debugging platform. It requires setting up the operating environment of the real machine and the debugging platform, and also requires a specially built CLI environment for debugging, which makes the debugging of the mini program time-consuming and labor-intensive, and can only rely on some debugging instructions given by the platform, such as the mini program identity document (ID), terminal type, whitelist verification, etc. for debugging. For the mini program, it cannot debug and verify its own business API, and cannot be debugged on a platform without a CLI environment. Debugging has limitations, and once the operating system of the debugging platform is different, it is necessary to build a CLI environment under the corresponding operating system respectively. In short, the relevant technology not only increases the cost of mini program debugging, but also reduces the efficiency of mini program debugging.

[0084] In order to solve the above problems, the embodiments of the present application provide a method, apparatus, storage medium and device for debugging mini-programs, which can improve the efficiency of mini-program debugging.

[0085] See also Figure 1 , Figure 1 A schematic diagram of a scenario of an implementation environment for a debugging method of a mini-program provided in an embodiment of the present application includes: a terminal 101 and a server 102, wherein the terminal 101 and the server 102 are connected via a communication network.

[0086] Exemplarily, the terminal 101 can be equipped with a display device (display screen) and an input device (touch screen, keyboard or mouse), and deploy a debugging system (hereinafter referred to as the system) with a small program. The system is a software system that can interact with testers or other staff through the front-end display device, and can also be deployed with a debugger, which can also interact with testers or other staff through the front-end display device.

[0087] Exemplarily, server 102 is deployed in the cloud, and may also be referred to as a cloud server, which may be a platform of any cloud service provider. Server 102 may generate a preset simulator corresponding to the debugger running on terminal 101, and establish an association relationship between the debugger and the preset simulator; receive configuration parameters sent by the debugger, and determine the target applet to be debugged in the preset applet library based on the configuration parameters, and load the target applet into the preset simulator based on the association relationship, and return the loading result to the debugger; receive program debugging instructions sent by the debugger, and transmit the program debugging instructions to the preset simulator based on the association relationship, and run the program debugging instructions through the target applet in the preset simulator to obtain corresponding program debugging results.

[0088] Exemplarily, terminal 101 can obtain configuration parameters in response to configuration operations on the debugger, and send the configuration parameters to server 102, so that the cloud server determines the target applet to be debugged in the preset applet library according to the configuration parameters. Server 102 also generates a preset simulator corresponding to the debugger, and establishes an association relationship between the debugger and the preset simulator, so as to load the target applet into the preset simulator according to the association relationship, and generate and return the loading result; terminal 101 can also receive the loading result sent by server 102, and in response to the program debugging instructions input on the debugger based on the loading result, send the program debugging instructions to server 102, so that server 102 transmits the program debugging instructions to the preset simulator according to the association relationship, and runs the program debugging instructions through the target applet in the preset simulator to obtain the corresponding program debugging result.

[0089] The terminal 101 may be a mobile phone, a computer, an intelligent voice interaction device, a smart home appliance, a vehicle terminal, an aircraft, etc., but is not limited thereto. The terminal 101 and the server 102 may be connected directly or indirectly via wired or wireless communication, and this embodiment of the application does not limit this.

[0090] Server 102 can be a standalone physical server, a server cluster or distributed system consisting of multiple physical servers, or a cloud server that provides basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communications, middleware services, domain name services, security services, CDN (Content Delivery Network), and big data and artificial intelligence platforms. Furthermore, server 102 can be a node server in a blockchain network.

[0091] It should be noted that Figure 1 The scenario diagram of the implementation environment of the mini-program debugging method shown is only an example. The mini-program debugging system and scenario described in the embodiment of the present application are intended to more clearly illustrate the technical solution of the embodiment of the present application, and do not constitute a limitation on the technical solution provided by the embodiment of the present application. Ordinary technicians in this field can know that with the evolution of the mini-program debugging system and the emergence of new business scenarios, the technical solution provided by the embodiment of the present application is also applicable to similar technical problems.

[0092] The embodiments of the present application can be applied to various scenarios, including but not limited to cloud technology, artificial intelligence, smart transportation, assisted driving, smart medical care and other scenarios.

[0093] See also Figure 2 , Figure 2 This is a flowchart of the debugging method of the mini-program provided in the embodiment of the present application. The debugging method of the mini-program can be applied in the cloud server (i.e., the server in the above embodiment), or jointly executed by the terminal and the cloud server. The debugging method of the mini-program includes steps 201 to 203:

[0094] In step 201, a preset simulator corresponding to the debugger is generated for the debugger running on the terminal, and an association relationship between the debugger and the preset simulator is established.

[0095] Among them, the terminal is a specific debugging terminal, which is the equipment used by the debugger. In order to debug the applet, the terminal can be remotely connected to the cloud server deployed in the cloud. A debugger is pre-packaged on the terminal. The type of debugger depends on the terminal environment in which the applet is to run. Therefore, according to the debugging requirements, debuggers can be installed on terminals of different operating systems. For each terminal, it can be loaded with a debugger, and multiple different debuggers can be loaded according to the debugging needs. Multiple debuggers can debug the same applet, or they can debug different applet separately.

[0096] The preset simulator is a simulator created by the cloud server. Because it's pre-configured, it's called "pre-configured." The cloud server can use this pre-configured setup to set up the environment required for mini-program debugging. Specifically, the cloud server creates a simulator based on the environment the mini-program needs to run, and uses it as the preset simulator. The cloud server then selects the preset simulator's operating system and hardware configuration as needed. The required development tools, libraries, and frameworks are then installed to host the mini-program's development environment. For example, the cloud server loads the applications the mini-program needs to run, such as chat software or e-commerce software.

[0097] An association is the connection or communication method between the debugger and the preset simulator, allowing the debugger to control and interact with the preset simulator. This association establishes a communication connection between the debugger and the preset simulator, allowing information to be transmitted between them. This allows the debugger to remotely control the preset simulator on the cloud server without having to set up a real machine runtime environment on the terminal.

[0098] Furthermore, the systems or environments in which the mini-programs that need to be debugged during remote debugging are diverse. For example, some mini-programs run on the Android system, while others run on other systems. In this case, multiple simulators can be pre-created on the cloud server as preset simulators. Each preset simulator has a corresponding operating environment configuration. If the created systems are different, each preset simulator can run and load some mini-programs in the corresponding systems or environments. Therefore, in the embodiment of the present application, by establishing an association between the debugger and the preset simulator, the subsequent debugger can deploy the mini-program in the corresponding preset simulator based on the association, rather than running it in other preset simulators that cannot run the mini-program, thereby meeting the needs of remote debugging and being more suitable for remote debugging scenarios.

[0099] Furthermore, some mini-programs require higher environmental configuration requirements, but the preset simulators created may not all have the corresponding environmental configuration. Therefore, the cloud server can create some preset simulators that meet specific needs, and by establishing an association between the debugger and the preset simulator, the subsequent debugger can deploy the mini-program in the corresponding preset simulator based on the association to run, further meeting the needs of remote debugging.

[0100] In some embodiments, there are multiple options for preset simulators, which can be configured by the following steps, including:

[0101] (1) Create a virtual machine or container, build an environment for the virtual machine or container to run any applet in the preset applet library, and use the virtual machine or container after the environment is built as the preset simulator;

[0102] (2) Alternatively, a connection relationship is established with a preset mobile terminal, and a terminal environment of the preset mobile terminal is obtained according to the connection relationship, and the preset mobile terminal is used as a preset simulator based on the terminal environment.

[0103] See also Figure 3 , Figure 3 It is a schematic diagram of a virtual machine or container provided in an embodiment of the present application as a preset simulator. In an embodiment of the present application, it is possible to choose to create a virtual machine or container on a cloud service provider's platform (which can be any cloud service), build an environment for running any applet in the preset applet library on the virtual machine or container, and use the virtual machine or container after building the environment as the preset simulator. Due to the characteristics of the virtual machine or container, an independent operating environment can be created for each applet without affecting each other, and the virtual machine or container can be easily copied and reset, reducing the debugging cost, and they can be reused to debug different applets, and the creation of the virtual machine or container can be carried out as needed, for example, their hardware configuration, operating system version, etc. can be adjusted to meet the debugging needs of different applets, so hardware resources can be fully utilized through virtualization technology, improving resource utilization.

[0104] In addition, see Figure 4 , Figure 4 : This is a schematic diagram of the preset mobile terminal provided in the embodiment of the present application as a preset simulator. The preset mobile terminal refers to a pre-configured computer device with mobile communication functions. For example, the preset mobile terminal is a real machine environment that is remotely deployed. The preset mobile terminal can be connected to the cloud server, so a connection relationship with the preset mobile terminal can be established, and the terminal environment of the preset mobile terminal can be obtained according to the connection relationship. The preset mobile terminal is used as a preset simulator based on the terminal environment. Due to the characteristics of the preset mobile terminal, the environment in which the mini program runs is similar to the actual use environment, which can better simulate the real scene. The cloud server can obtain and debug the operation status on the preset mobile terminal in real time, improve debugging efficiency, and save the cost of purchasing and maintaining virtual machines or containers.

[0105] It is understandable that the above two methods have their own advantages, and which method to choose depends on the specific debugging requirements and resource conditions. Therefore, the embodiment of the present application can greatly improve the efficiency and flexibility of mini-program debugging and reduce costs and risks by reasonably configuring the preset simulator.

[0106] The specific process of step 201 is described above. The following describes step 202 after step 201:

[0107] In step 202, the configuration parameters sent by the debugger are received, and the target applet to be debugged is determined in the preset applet library according to the configuration parameters, the target applet is loaded into the preset simulator according to the association relationship, and the loading result is returned to the debugger.

[0108] Configuration parameters are parameters that need to be passed to the preset simulator during the debugging process. They are instructions issued during the mini-program debugging process. These parameters can specify the debugger's behavior and relevant information about the target mini-program. These parameters can be sent to the cloud server through the debugger to load and run the target mini-program and obtain the corresponding debugging results.

[0109] Furthermore, the configuration parameters may include mandatory parameters, which are shown in Table 1:

[0110] Table 1

[0111]

[0112] Among them, the required parameters are some parameters that are essential in the process of selecting the target applet, and the optional parameters are some parameters that have additional requirements for the debugging process. For example, the required parameters may include the name (identifier) ​​of the target applet, project configuration, project entry file path, header file path, output product path, operating platform, etc. The full packaging in Table 1 refers to packaging all the applets that need to be packaged into executable code at one time. Full packaging is suitable for the first packaging or when the entire applet needs to be recompiled. Incremental packaging refers to packaging only some applets that need to be updated without recompiling the entire applet. Incremental packaging can save time and resources and is suitable for situations where only some applets have changed.

[0113] Furthermore, the configuration parameters can also be optional parameters, as shown in Table 2:

[0114] Table 2

[0115] Parameter name Parameter Description -h / --help Output help documentation -a / --all Full packaging parameters -u / --update Branch update instructions -l / --log Whether to output tool logs during packaging -q / --quick Fast packaging

[0116] Among them, optional parameters can include output help documents, full packaging parameters, branch update instructions, whether to output tool logs, quick packaging options, etc. When the full packaging parameters are selected, the required parameters `--sub` / `-s` will not be used. The branch update instruction is used to execute the `install` update command to update the branch before packaging. Quick packaging can inherit all the information of the previous packaging and can be partially updated by other parameters.

[0117] Finally, the target applet generated by the packaging instructions in the configuration parameters can be run on the corresponding preset simulator of the cloud server.

[0118] See also Figure 5 , Figure 5 : This is a schematic diagram of creating a preset applet library provided by an embodiment of the present application. The preset applet library is a pre-created source code repository, which is a collection of multiple applets. The source code of the applet will be submitted to the remote warehouse by the developer through git / svn / HG and other methods each time the function is iterated. Therefore, these applets are developed in advance and stored, and can be loaded and debugged as needed. Each applet in the preset applet library contains corresponding parameters, entry file path, header file path and other information, and each applet has a unique identifier so that the debugger can choose to load different applets based on this information.

[0119] For further information, see Figure 6 , Figure 6 It is a schematic diagram of the management and maintenance of the preset applet library provided by the embodiment of the present application. The preset applet library can be managed and maintained by the cloud server. After accessing the applet source code, the cloud server creates a preset applet library, and can detect the update status of the preset applet library through the port. Specifically, it can generate node information for each submission by configuring the pull method, port update, and branch modification of any applet in the preset applet library, that is, the updated node of the applet, and then use an xml file to save the record. After receiving the debugging instruction, the modification time of the submitted node is obtained by scanning the xml file, so that the corresponding interface is marked, so that the modified version of the applet and the specific changes can be known. In addition, since the cloud server runs in the cloud, the cloud will record the interface functions of each version of the applet. In order to be able to access the cloud development environment of the applet from any location, it is necessary to configure remote access. You can use SSH or use the remote desktop tool provided by the cloud service provider, etc., and no specific restrictions are made here.

[0120] Therefore, the debugger can remotely access the pre-set mini-program library on the cloud server and select the target mini-program to load for debugging as needed. In this way, the terminal no longer needs to set up a real machine operating environment, and the entire debugging process can be performed remotely on the cloud server, reducing debugging costs and improving debugging efficiency.

[0121] The target applet is the program that needs to be debugged and tested. Debugging can reveal errors and problems within the applet, allowing for repairs and optimization. The target applet can be a fully developed program or one that needs debugging and optimization. The target applet is already prepared in the preset applet library and contains information such as parameters, entry file paths, and header file paths. This allows the debugger to load and run the target applet for debugging based on this information.

[0122] For example, the configuration parameters are instructions issued to a unified applet based on the encapsulated debugger, which can be implemented through a scripting language. When the debugger needs to debug the applet, some configuration parameters can be entered in the scripting language according to the debugging needs. These parameters can be the identification, configuration, and operating environment requirements of the target applet, etc., depending on the implementation method of the debugger and the characteristics of the target applet. After receiving the configuration parameters, the cloud server can determine the target applet that needs to be debugged from the preset applet library, and convert the code of the target applet into executable code for each system platform, generate the corresponding binary file (SDK file), and load it into the preset simulator. Subsequently, the corresponding application can be opened on the preset simulator and the loaded target applet can be pulled for debugging.

[0123] Furthermore, the preset mini-program library can synchronize branches to detect updates to the mini-programs stored therein. When a mini-program in the library is modified, it can be synchronously updated in the preset mini-program library to adapt to changes in the development process.

[0124] The specific process of step 202 is described above. The following describes step 203 after step 202:

[0125] In step 203, the program debugging instruction sent by the debugger is received, the program debugging instruction is transmitted to the preset simulator according to the association relationship, and the program debugging instruction is run through the target applet in the preset simulator to obtain the corresponding program debugging result.

[0126] Program debugging instructions are instructions sent by the debugger to the preset simulator during the mini-program debugging process. They are a set of instructions used to control and manipulate the behavior and state of the target mini-program. These instructions can help debuggers debug mini-programs and fix problems. In the preset simulator, program debugging instructions are parsed and executed to control the operation of the target mini-program. The preset simulator will perform corresponding operations based on the debugger's instructions, such as pausing program execution, checking memory status, and modifying variable values, so as to better understand the mini-program's operating mechanism and problems, thereby quickly locating and fixing problems.

[0127] Furthermore, program debugging instructions can be simple control instructions, such as executing the next line of code, entering a function, or jumping out of a loop, or they can be complex operation instructions, such as breakpoint setting, single-step execution, variable viewing and modification, etc. Through these instructions, debuggers can step by step check the execution process of the program, observe the changes in variable values ​​and program status, and thus discover and fix errors and problems in the program.

[0128] Program debugging results are the results obtained after debugging the target applet through the debugger. These can include various types of debugging results, such as program status, variable value changes, and exception information output during program execution. These can help debuggers understand the program's operation and identify potential issues.

[0129] Illustratively, an embodiment of the present application provides a method for a debugger to debug a mini-program at any location using only an Internet-connected terminal. The terminal can trigger the interface function of the target mini-program during the debugging process in any way, such as URL access, page triggering, command triggering, interface triggering, etc. By calling the debugger to initiate debugging, the target mini-program will start running in the remote environment. Regardless of the operating system of the terminal, the mini-program can be debugged through remote debugging without the need to build a dedicated CLI environment locally. During the debugging process, debugging can be interrupted at the location where the breakpoint is set, waiting for further operation, etc., and no specific restrictions are made here.

[0130] In summary, through the above steps 201 to 203, the embodiment of the present application generates a preset simulator corresponding to the debugger for the debugger running on the terminal, and establishes an association relationship between the debugger and the preset simulator; receives the configuration parameters sent by the debugger, and determines the target applet to be debugged in the preset applet library according to the configuration parameters, and loads the target applet into the preset simulator according to the association relationship, and returns the loading result to the debugger; receives the program debugging instructions sent by the debugger, transmits the program debugging instructions to the preset simulator according to the association relationship, and runs the program debugging instructions through the target applet in the preset simulator to obtain the corresponding program debugging results. In this way, by establishing an association between the debugger and the preset simulator, the debugger on the terminal can send configuration parameters to the cloud server remotely according to the needs of debugging, and the cloud server can load the target applet to be debugged into the preset simulator according to the configuration parameters. During the debugging process, when the debugger sends the program debugging instruction to the cloud server, debugging can be initiated. The cloud server can transmit the program debugging instruction to the preset simulator according to the association, and run the program debugging instruction through the target applet in the preset simulator, so that the applet that needs to be debugged does not need to be run and loaded locally on the terminal, and the terminal no longer needs to set up a real machine running environment. Instead, the entire process is debugged remotely on the cloud server, and debugging is initiated through the debugger on the terminal without the need to set up a special debugging environment. Therefore, terminals of any operating system can perform remote debugging of the applet through the debugger to obtain the required program debugging results. The limitations of debugging are greatly reduced, which ultimately not only reduces the cost of applet debugging but also improves the efficiency of applet debugging.

[0131] The following describes in detail the steps further included in step 201 and step 203:

[0132] In some implementations, there may be multiple terminals, each of which is provided with a debugger. For these debuggers, establishing an association relationship between the debugger and a preset simulator includes:

[0133] For debuggers respectively running on multiple terminals, preset simulators corresponding to respective debuggers are generated, and instruction transmission channels are established between respective debuggers and the preset simulators as association relationships between the respective debuggers and the preset simulators.

[0134] After the command transmission channel is established, subsequent commands can be transmitted through the command transmission channel, including:

[0135] The program debugging instruction is sent to the instruction transmission channel, the program debugging instruction is converted into a preset format through the instruction transmission channel, and the program debugging instruction in the preset format is transmitted to the corresponding preset simulator.

[0136] The instruction transmission channel is a communication channel connecting the debugger and the preset simulator, used to transmit data such as program debugging instructions and debugging results. The instruction transmission channel can be a network connection, or, provided that it meets the requirements of the embodiments of this application, a serial port communication, a Bluetooth connection, etc. The specific communication method and protocol can be selected based on actual needs and communication protocols.

[0137] The preset format is a unified format, defined to standardize the format and transmission method of program debugging instructions during the program debugging process. The preset format can unify the instruction format of debuggers on different terminals, avoiding problems caused by inconsistent instruction formats. Furthermore, the preset format can be compressed and encoded, making instruction transmission more efficient and reducing data transmission volume. Therefore, program debugging instructions in the preset format are more easily parsed and processed by the preset simulator, improving debugging efficiency, ensuring the secure transmission of debugging instructions, and preventing malicious tampering.

[0138] For example, see Figure 7 , Figure 7It is a schematic diagram of an embodiment of the present application for transmitting program debugging instructions in a preset format to a corresponding preset simulator. The debugger can use a variety of different scripting languages ​​(such as Python, js, etc.) to write instructions in the debugging process, and after writing, the resulting script file is sent to the instruction transmission channel for format conversion, and then an instruction set is formed, which can be transmitted to the preset simulator in the cloud based on the instruction set. Furthermore, when loading the target applet into the preset simulator, it is also necessary to convert the configuration parameters, etc. into the preset format, and then load the target applet into the preset simulator.

[0139] Exemplarily, when there is only one preset simulator, the debuggers running on multiple terminals respectively have instruction transmission channels built between them and the preset simulator, so that different debuggers can share the resources of a preset simulator and perform debugging under remote resources. When different debuggers issue instructions, such as issuing program debugging instructions, they will all be transmitted to the instruction transmission channel. At this time, the instructions issued by different debuggers may have different formats. The program debugging instructions in different formats can be converted to a unified preset format through the instruction transmission channel, and after the conversion, the program debugging instructions of different debuggers are transmitted to the preset simulator so that the preset simulator executes the corresponding instructions. It can be understood that the preset simulator can respond to the debugging of one debugger in the same time period, or it can respond to the debugging of multiple debuggers. When responding to the debugging of multiple debuggers, multiple applications can be loaded on the preset simulator, and each application is loaded with the target applet that needs to be debugged by different debuggers.

[0140] Exemplarily, when there are multiple preset simulators, the debugger running on each terminal can be matched with a corresponding preset simulator. In this way, according to the debugging needs of each debugger, a preset simulator that meets each debugging need can be built. For example, different preset simulators have different environmental configurations, different parameter configurations, different system configurations, etc., to further meet personalized debugging needs. Therefore, an instruction transmission channel can be built between each debugger and each corresponding preset simulator. Each instruction transmission channel is also used to convert the instructions of each debugger, such as program debugging instructions, into a preset format that meets the input of each preset simulator. The preset formats between different preset simulators can be the same or different. When different debuggers issue instructions, such as program debugging instructions, they will all be transmitted to the corresponding instruction transmission channel. At this time, the instructions issued by different debuggers may have different formats. The program debugging instructions in different formats can be converted to a unified preset format through the instruction transmission channel. After the conversion, the program debugging instructions of different debuggers are transmitted to the matching preset simulators so that the preset simulators execute the corresponding instructions.

[0141] In short, in a remote debugging scenario, the debugger on the terminal needs to send program debugging instructions to the cloud server, which then transmits the instructions to the preset simulator, executes them, and returns the debugging results. Through the instruction transmission channel, the debugger can remotely control and operate the target applet to debug and optimize the program. Therefore, the establishment of the instruction transmission channel enables the debugger on the terminal to communicate with the cloud server, transmitting data such as configuration parameters and program debugging instructions to the cloud server. At the same time, it can also receive debugging results, program execution status, and other information returned by the cloud server. This simplifies the debugging process, reduces debugging costs, improves debugging efficiency, and makes it easier for debuggers to develop and debug applet.

[0142] In some implementations, the debugger carries an application identifier, and the process of establishing an association between the debugger and the preset simulator further includes:

[0143] Generate a preset simulator corresponding to the application identifier of each debugger, and establish an instruction transmission channel between the debugger and the preset simulator;

[0144] After the command transmission channel is established, you can select a preset simulator based on the application identifier and transmit commands through the command transmission channel, including:

[0145] The program debugging instruction in the preset format is transmitted to the preset simulator corresponding to the application identifier.

[0146] Among them, the application identifier is a unique identifier used to identify and distinguish different applications, and can be a string. It is understandable that the applet is used in the application, and each application has a unique identifier for distinguishing different applications. In the embodiment of the present application, when the debugger is run on the terminal, the debugger will carry its corresponding application identifier so that it can correctly correspond and identify when establishing the association relationship between the debugger and the preset simulator, and can ensure the correct association between the debugger and the preset simulator, so that the debugger can correctly load and debug the target applet.

[0147] For example, the application identifier is the unique identifier of the application run by the mini program, such as a chat software, an e-commerce software, etc. Multiple mini programs can run on one application. Therefore, the application identifier can be used to load the mini program running under the application into the same preset simulator for execution and debugging.

[0148] Specifically, the cloud server can generate a corresponding preset simulator for each application identifier. After receiving the program debugging instructions from each debugger, it will perform format conversion. After converting to the preset format, the program debugging instructions under the same application identifier will be transferred to the same preset simulator, so that the target applet can be loaded on the same application. In this way, by using application identifiers to load and debug applet, a more centralized, efficient and accurate debugging process can be achieved, thereby improving the efficiency of software development and the quality of software. In addition, by utilizing the feature that applet is loaded on the application, there is no need to create separate preset simulators for different applet under the same application. In this way, when facing the debugging of multiple applets, the cloud server in the cloud will not be overloaded, ensuring debugging efficiency.

[0149] Alternatively, the cloud server can generate a corresponding preset simulator for each application identifier, and multiple debuggers can be set up on the terminal, each debugger can correspond to an application identifier. After receiving the program debugging instructions from each debugger, the format will be converted, and after converting to the preset format, the program debugging instructions under the same application identifier will be transmitted to the same preset simulator, so as to load the target applet on the preset simulator corresponding to the debugger. In this way, by using application identifiers to load and debug applet, a more centralized, efficient and accurate debugging process can be achieved. Each debugger can debug one applet as needed, or the number of applet debugged by each debugger can be limited, thereby avoiding cloud overload, ensuring debugging efficiency, and improving software development efficiency and software quality.

[0150] Furthermore, in the embodiment of the present application, the number of debugged applets in the same preset simulator can be limited, or it can be ensured that only one target applet is debugged on one application at a time to ensure the normal operation of each applet and avoid interference. The embodiment of the present application does not impose specific restrictions on this.

[0151] The following are detailed descriptions of the steps further included after step 203:

[0152] In some implementations, after obtaining corresponding program debugging results, further debugging may be performed for exceptions that occur during the debugging process, which may specifically include:

[0153] (1) When the program debugging result indicates that an abnormal event occurs during the operation of the target applet, a target use case corresponding to the abnormal event in the target applet is obtained;

[0154] (2) receiving the use case debugging instruction sent by the debugger, transmitting the use case debugging instruction to the preset simulator according to the association relationship, and running the use case debugging instruction through the target applet in the preset simulator to load the target use case and obtain the corresponding use case debugging result;

[0155] (3) When the use case debugging result indicates that the target use case fails to load, obtain the relevant internal interface functions in the target applet;

[0156] (4) Receive the interface debugging instructions sent by the debugger, transmit the interface debugging instructions to the preset simulator according to the association relationship, run the interface debugging instructions through the target applet in the preset simulator, and call the internal interface function during the running process to obtain the corresponding interface debugging results.

[0157] Abnormal events refer to unexpected situations that occur during the operation of the target mini-program. These include unexpected or unusual situations such as a blank screen, crashes, or data errors. Abnormal events can be caused by code errors, resource issues, network problems, or other external factors. These events can affect the normal execution of the target mini-program, causing errors or abnormalities in the target mini-program.

[0158] Target use cases are test cases that correspond to abnormal events. When an abnormal event occurs, running the target use case allows for in-depth analysis and identification of the cause of the problem. Therefore, target use cases are designed to verify whether the program correctly handles abnormal situations. By testing the target use case, you can verify whether the target applet correctly handles and resumes execution under abnormal circumstances. This is one of the key test cases used to discover and resolve potential problems in the target applet.

[0159] Exemplarily, there can be multiple abnormal events and target use cases. For example, the abnormal event can be a white screen phenomenon. When the target applet is loaded, the screen is blank and no content is displayed. At this time, the target use case can be to check whether the resource package (such as pictures, script files, etc.) is successfully loaded; or the abnormal event can be a crash. When the target applet suddenly stops running or closes, the target use case can be to perform stress testing or error handling testing on the code segment that may cause the crash; or the abnormal event can be a data error, such as incorrect data display, data loss or data format error of the target applet. The target use case can be to test the input and output of data to ensure the integrity and accuracy of the data; or the abnormal event can be a network problem, such as network disconnection, network delay, etc. The target use case can be to simulate the program running in different network environments to check whether the program can correctly handle network fluctuations or no network.

[0160] Exemplarily, there are multiple ways to obtain the target use case corresponding to the abnormal event in the target applet. After obtaining the corresponding abnormal event, the corresponding target use case can be found by looking up the table. In the embodiment of the present application, the use cases corresponding to different abnormal events can be pre-recorded; alternatively, after obtaining the abnormal event, it can be sent to the terminal for display. The debugger inputs the specific target use case based on the actual error situation and transmits it to the preset simulator; alternatively, the cloud server, preset simulator or terminal can be provided with a test tool. After obtaining the abnormal event, the abnormal event can be input into the test tool for automated detection, and the target use case to be checked can be obtained.

[0161] Next, the debugger sends the use case debugging instructions to the cloud server. After receiving the instructions, the cloud server transmits the use case debugging instructions to the preset simulator based on the preset association relationship. The preset simulator loads the target applet and runs the target use case according to the use case debugging instructions. During this process, the preset simulator simulates the real operating environment, allowing the target applet to run in the simulated environment and record the running results. By running the target use case, the corresponding use case debugging results can be obtained. This result includes the program's behavior under abnormal conditions, return values, log information, etc., which helps debuggers further analyze the cause of the problem and take appropriate measures to repair and optimize it.

[0162] When the use case debugging results indicate that the target use case failed to load, it is necessary to obtain the relevant internal interface functions in the target applet to further analyze the cause of the use case loading failure. By obtaining the relevant internal interface functions, we can gain a deeper understanding of the debugging-related issues. Subsequently, the interface debugging instructions sent by the debugger are received, and the interface debugging instructions are transmitted to the preset simulator based on the association relationship. The interface debugging instructions are then run through the target applet in the preset simulator, and the internal interface functions are called during the running process to obtain the corresponding interface debugging results.

[0163] It should be noted that obtaining the relevant internal interface functions in the target mini-program is intended to further diagnose and debug abnormal events. Internal interface functions are private functions in the target mini-program, containing the target mini-program's private classes, private objects, private properties, and private methods. They are an important component in implementing specific program functions. When the use case debugging results indicate that the target use case failed to load, obtaining the relevant internal interface functions can help debuggers gain a deeper understanding of the logic and implementation methods within the target mini-program. Subsequently, they can obtain interface debugging results by examining the function call parameters, return values, and the status and behavior during execution.

[0164] For example, if during the debugging of the target applet, it is found that an abnormal event occurs when opening the target applet page, the corresponding abnormal event is a white screen phenomenon. Under the white screen phenomenon, it is necessary to call the target use case to check whether it is normal. The target use case corresponding to the white screen phenomenon is to call whether the resource package is loaded successfully, and then execute the target use case. Then, when executing the target use case, the result returns failure. Therefore, the internally refined internal interface functions are extracted, such as some private methods, including internal interface functions for loading resources such as images, text, and buttons. Therefore, these internal interface functions are subsequently debugged, and the values ​​of variables and execution expressions are checked to understand the running status of the target applet until the specific function is located and the corresponding interface debugging results are obtained.

[0165] In some implementations, relevant internal interface functions in the target applet can be obtained from the header file of the target applet, specifically including:

[0166] (1) Determine the file path of the header file in the target applet according to the configuration parameters, and extract the header file according to the file path;

[0167] (2) Obtain the relevant internal interface functions in the target applet from the header file.

[0168] It's important to note that because the interface functions called by mini-programs are obfuscated within the mini-program engine, the obfuscated internal interface functions are difficult to extract. Therefore, due to code obfuscation, direct reading and understanding become more difficult, requiring a debugger to identify and call these obfuscated functions. Furthermore, the header files in mini-programs contain function declarations. Some of these functions are private, meaning they aren't directly exposed to external calls but serve as the underlying implementation for other public interface functions. Therefore, in order to debug these private functions, it's necessary to extract their declarations from the header files.

[0169] Specifically, when filling in the configuration parameters, the file path of the mini-program header file is configured. Through these parameters, we can know the location of the header file in the file system and where to find it. Therefore, we can find the location of the header file based on the file path, extract the header file based on the file path, and extract the contents of the header file. After obtaining the contents of the header file, we need to analyze the content to find the interface functions marked as "internal" or "private" to identify and extract the relevant internal interface functions in the target mini-program.

[0170] In some implementations, the relevant internal interface functions in the target applet can be obtained from the header file through runtime and reflection technology, specifically including:

[0171] (1) Obtain multiple program programming interface functions when the target applet runs the use case debugging instructions;

[0172] (2) Extracting the internal instance information and internal attributes of the target applet from the header file based on multiple program programming interface functions, and obtaining the relevant internal interface functions in the target applet according to the internal instance information and internal attributes.

[0173] This application implements the use of reflection technology to identify and extract obfuscated internal interface functions when the target applet is running, that is, when the target applet runs the use case debugging instructions, so that they can be called during debugging. Therefore, it is necessary to run multiple program programming interface functions when the use case debugging instructions are run, that is, the runtime application programming interface (Application Programming Interface, API).

[0174] Next, based on multiple program programming interface functions, the internal instance information and internal properties of the target applet are extracted from the header file. The internal instance information includes instance methods (private methods) and instance variables (private variables) related to these functions, and the internal properties include instance properties (private properties) related to these functions. Then, the relevant internal interface functions in the target applet can be obtained based on these internal instance information and internal properties.

[0175] For example, see Figure 8 , Figure 8 This is a schematic diagram of obtaining internal interface functions from header files through runtime and reflection technology provided by an embodiment of the present application. The embodiment of the present application can be obtained by using a variety of runtime program programming interface functions, such as relevant runtime APIs (such as class_getInstanceMethod, class_getInstanceVariable and ivar_getName, etc.) for extraction. When the target applet reports data, the private class is initialized and reported through the ClassFromString function, and then the performSelector function is used to execute the instance method of obtaining the unreported data in the database. The return value is used as a private object, and the class name and object attribute are passed in through the class_getInstanceVariable function to obtain the instance variable and instance attribute. Finally, the reported parameter values ​​are extracted to obtain the function parameters of the internal interface function, and finally the required internal interface function is obtained.

[0176] In some implementations, it is necessary to identify the calling of internal interface functions through bridging, specifically including:

[0177] (1) storing the internal interface function in a preset communication bridge by registering it, and setting a breakpoint for the internal interface function in the communication bridge based on the interface debugging instruction;

[0178] (2) When the internal interface function is identified to be called through the communication bridge, the corresponding interface data is obtained, and the breakpoint is triggered to terminate the operation of the target applet, and the corresponding interface debugging result is obtained according to the interface data.

[0179] It should be noted that in the embodiments of this application, it is necessary to use the mini-program engine js to call relevant functions and detect and modify the captured function input and output parameters. Since the extracted internal interface functions, such as private methods, protocols, and objects, cannot be directly accessed through the breakpoint commands sent by the debugger, it is necessary to identify the calling status of the internal interface functions through bridging.

[0180] The communication bridge (jsbridge) is a pre-defined framework or tool for establishing communication between mini-programs and JavaScript code. Debuggers can register internal interface functions with this bridge so that they can be accessed and called by external code. Breakpoints are a concept in debugging. When a mini-program reaches a specific point (i.e., a breakpoint), it automatically stops, allowing debuggers to view the current state, variable values, and more.

[0181] In the embodiment of the present application, breakpoints are set at the internal interface functions in the communication bridge according to the interface debugging instructions. In this way, when these functions are called, the target applet will stop at that point, allowing the debugger to perform further debugging.

[0182] When the bridge detects that an internal interface function is called by external code, it can capture all data or parameters related to the function call. This data can show how the function is called, what parameters are passed, etc. When the target applet runs to a breakpoint, it will stop, and the debugger can view the current status, variable values, etc., to better understand the function call process and possible errors. Finally, based on the captured interface data, more information about the function call can be obtained, allowing for deeper debugging and obtaining corresponding interface debugging results. For example, if the value of a parameter is found to be unexpected, the code can be checked to understand why this happened, thereby obtaining the corresponding interface debugging results.

[0183] For example, see Figure 9 , Figure 9This is a schematic diagram of identifying internal interface functions through bridging provided by an embodiment of the present application. In the embodiment of the present application, the js layer of the target applet is used for bridging. When the target applet engine executes compilation, the method name of the extracted internal interface function is stored in the communication bridge through registration. After the target applet header file method is injected, each called interface will be refined into an API, and the communication bridge will then trigger the corresponding API identification. Since communication bridge injection is an asynchronous process, after identifying the event as much as possible, use jsBridge.invoke to call the refined API. With the communication bridge as the calling bridge, the debugger can indirectly insert the breakpoint command into the internal interface function and record the stack intermediate variables generated by the calling process.

[0184] In some implementations, when there are multiple internal interface functions, these internal interface functions can be run in a stack manner, and each internal interface function can be debugged step by step, specifically including:

[0185] (1) Setting up stacks for multiple internal interface functions and setting corresponding breakpoints for each internal interface function;

[0186] (2) Run the interface debugging instruction through the target applet in the preset simulator and run it to the stack. Perform single-step debugging on each internal interface function based on each breakpoint to obtain the interface debugging results corresponding to each internal interface function.

[0187] In the embodiments of the present application, a stack is required for multiple internal interface functions. When there are multiple internal interface functions, the stack provides a complete history of function calls. When an internal interface function is called, it is pushed onto the stack; when it completes execution and returns, it is popped off the stack, and the next internal interface function is called. This allows debuggers to see how multiple internal interface functions are called consecutively.

[0188] A breakpoint is a specific point in a program's execution where the target applet stops. In this embodiment, a specific breakpoint is set for each internal interface function so that when these functions are called, they stop at the corresponding breakpoint. Therefore, with the stack, you can select single-step execution at each breakpoint.

[0189] After receiving the interface debugging instruction, the target applet in the preset simulator runs the interface debugging instruction. The target applet will execute multiple internal interface functions in the order in the stack until it encounters a breakpoint or completes the execution of all functions. At each breakpoint, you can choose to execute single-step (such as executing the code step by step). In this way, you can view the detailed process of each function call, as well as the variables and status inside each function, and finally obtain the interface debugging results corresponding to each internal interface function, including any possible problems or exceptions.

[0190] In combination with the method described in the above embodiment, the following examples are given to further illustrate the method in detail.

[0191] To better illustrate the embodiments of this application, please refer to Figure 10 As shown, Figure 10 This is a complete flowchart of the mini-program debugging process provided by the embodiment of this application.

[0192] S1. Create a cloud development environment for the terminal debugger and connect to the source code management repository of the mini program.

[0193] Specifically, the terminal is packaged with a debugger. Based on debugging needs, a pre-set simulator is created on the cloud server for the terminal debugger. This simulator stores the development environment and is configured accordingly, including selecting the operating system and hardware configuration as needed, ensuring the installation of the required development tools, libraries, and frameworks. For example, if an IDE applet requires a Linux environment, a Linux container will be configured as the pre-set simulator.

[0194] Furthermore, the source code of the mini program will be submitted to the remote warehouse by the developer through git / svn / HG and other methods each time the function is iterated. The preset mini program library can be managed and maintained by the cloud server. After accessing the mini program source code, the cloud server creates a preset mini program library and can obtain the update status of the preset mini program library through the port. Specifically, it can generate node information for each submission by configuring the pull method, port update, and branch modification of any mini program in the preset mini program library, that is, the updated node of the mini program, and then use an xml file to save it. After receiving the debugging instructions, the modification time of the submitted node is obtained by scanning the xml file, and the corresponding interface is marked, so that the modified version of the mini program and the specific changes can be known. In addition, since the cloud server runs in the cloud, the cloud will record the interface functions of each version of the mini program. In order to be able to access the cloud development environment of the mini program from any location, remote access needs to be configured. You can use SSH or the remote desktop tool provided by the cloud service provider, etc. There are no specific restrictions here.

[0195] S2. Build and encapsulate cross-end debugging instructions to debug the determined target applet.

[0196] Here, the debugger can debug through breakpoints, logs, performance testing, etc. during the debugging process, and each terminal can get the problems encountered during the debugging process.

[0197] The terminal pre-packages a debugger for the mini-program's runtime environment. The debugger type depends on the terminal environment the mini-program will run in. The cloud server then establishes a command transmission channel between the debugger and the pre-set simulator. The debugger can be a Python debugger, such as pdb. With pdb, which comes with Python, you can insert the `import pdb; pdb.set_trace()` statement in your code to set breakpoints. For backend JavaScript code, you can use the Node.js built-in debugger or a third-party debugger, such as `node-inspect`. Insert `debugger` statements in your code to set breakpoints, then run the code using the `node inspect your_script.js` command.

[0198] Furthermore, the debugging process can be based on the packaged debugger to build a unified applet to issue instructions. When the debugger needs to debug the applet, he can enter some configuration parameters in the scripting language according to the debugging needs. These parameters can be the target applet's identification, configuration, operating environment requirements, etc., depending on the implementation method of the debugger and the characteristics of the target applet. After receiving the configuration parameters, the cloud server can determine the target applet that needs to be debugged from the preset applet library, and convert the code of the target applet into executable code for each system platform, generate the corresponding binary file (SDK file), review and sign it, and then load it into the preset simulator. Subsequently, you can open the corresponding application on the preset simulator and pull the loaded target applet for debugging.

[0199] This process can use a unified business applet packaging script, such as providing a package.py script file, filling in required parameters and optional parameters, etc. The target applet generated by the packaging command can be run on the corresponding preset simulator of the cloud server.

[0200] When extracting the target mini-program's internal interface functions, the mini-program's internal implementation of code obfuscation within the mini-program engine makes the obfuscated internal interface functions difficult to extract. Therefore, due to code obfuscation, direct reading and understanding become more difficult, requiring the debugger to identify and call these obfuscated functions. Furthermore, the mini-program's header files contain function declarations. Some of these functions are private, meaning they are not directly exposed to external calls but serve as the underlying implementation for other public interface functions. Therefore, in order to debug these private functions, their declarations must be extracted from the header files.

[0201] Therefore, it can be obtained by using a variety of runtime program programming interface functions, such as relevant runtime APIs (class_getInstanceMethod, class_getInstanceVariable, and ivar_getName, etc.). When the target applet reports data, the private class is initialized and reported through the ClassFromString function, and then the performSelector function is used to execute the instance method of obtaining the unreported data in the database. The return value is used as a private object, and the class name and object attribute name are passed in through the class_getInstanceVariable function to obtain the instance variable and instance attribute. Finally, the reported parameter values ​​are extracted to obtain the function parameters of the internal interface function, and finally the required internal interface function is obtained.

[0202] S3. Use the mini program engine js to call related functions, and test and modify the captured function input and output parameters.

[0203] When an exception occurs during the debugging of the target applet, the embodiment of the present application requires the use of the applet engine js to call the relevant function and detect and modify the captured function input and output parameters. Because the extracted internal interface functions, such as private methods, protocols, and objects, cannot be directly accessed through the breakpoint commands sent by the debugger, it is necessary to identify the calling status of the internal interface functions through bridging.

[0204] Specifically, in the embodiment of the present application, the js layer of the target applet is used for bridging. When the engine of the target applet executes compilation, the method name of the extracted internal interface function is stored in the communication bridge through registration. After the injection of the target applet header file method is completed, each called interface will be refined into an API, and the communication bridge will then trigger the corresponding API identification. Since the communication bridge injection is an asynchronous process, after identifying the event as much as possible, jsBridge.invoke is used to call the refined API. With the communication bridge as the calling bridge, the debugger can indirectly insert the breakpoint command into the internal interface function and record the stack intermediate variables generated by the calling process.

[0205] For example, if during the debugging of the target applet, it is found that an abnormal event occurs when opening the target applet page, the corresponding abnormal event is a white screen phenomenon. Under the white screen phenomenon, it is necessary to call the target use case to check whether it is normal. The target use case corresponding to the white screen phenomenon is to call whether the resource package is loaded successfully, and then execute the target use case. Then, when executing the target use case, the result returns failure. Therefore, the internally refined internal interface functions are extracted, such as some private methods, including internal interface functions for loading resources such as images, text, and buttons. Therefore, these internal interface functions are subsequently debugged, and the values ​​of variables and execution expressions are checked to understand the running status of the target applet until the specific function is located and the corresponding interface debugging results are obtained.

[0206] Finally, by building and encapsulating unified cross-end debugging instructions, the applet can be debugged on multiple platforms (such as Windows, Mac, iOS, Android, etc.), improving the efficiency of development and testing, and cloud debugging can feedback problems in real time, allowing debuggers to discover and solve problems in a timely manner, improving development efficiency and code quality, and is more convenient than traditional debugging methods, saving more manpower. In addition, cloud debugging allows team members to debug the applet at any location using a networked terminal, facilitating team collaboration and resource sharing. The cloud debugging environment is isolated from the local development environment of the terminal, which can avoid problems caused by local environment differences and improve the stability and reliability of the applet. Further, the embodiment of the present application also uses runtime and reflection technology to extract the internal interface functions of the applet, so that the debugger can analyze and debug the internal implementation of the applet more deeply, wherein the communication bridging technology is also used to enable the debugger to indirectly insert breakpoint commands into the internal interface functions of the applet, thereby improving the flexibility and accuracy of debugging.

[0207] See also Figure 11 , Figure 11This is another flowchart of the debugging method of the mini-program provided in the embodiment of the present application. The debugging method of the mini-program can be applied in the terminal, or jointly executed by the terminal and the cloud server (that is, the server in the above embodiment). The debugging method of the mini-program includes steps 1101 to 1102:

[0208] Step 1101: In response to a configuration operation on the debugger, obtain configuration parameters and send the configuration parameters to the cloud server;

[0209] Among them, the cloud server is used to determine the target applet to be debugged in the preset applet library according to the configuration parameters. The cloud server also generates a preset simulator corresponding to the debugger, and establishes an association relationship between the debugger and the preset simulator to load the target applet into the preset simulator according to the association relationship, and generate and return the loading result.

[0210] Step 1102: receiving the loading result sent by the cloud server, and sending a program debugging instruction to the cloud server in response to a program debugging instruction input on the debugger based on the loading result;

[0211] Among them, the cloud server is also used to transmit the program debugging instructions to the preset simulator according to the association relationship, and run the program debugging instructions through the target applet in the preset simulator to obtain the corresponding program debugging results.

[0212] The debugging method of the mini program in the embodiment of the present application is similar to the debugging method of the mini program in steps 201 to 203 in the above embodiment. The difference is that it is applied in the terminal, or jointly executed by the terminal and the server. The similarities with the above embodiment are not repeated here.

[0213] In summary, through the above steps 1101 to 1102, configuration parameters are obtained by responding to the configuration operation on the debugger, and the configuration parameters are sent to the cloud server, so that the cloud server determines the target applet to be debugged in the preset applet library according to the configuration parameters. The cloud server also generates a preset simulator corresponding to the debugger, and establishes an association relationship between the debugger and the preset simulator, so as to load the target applet into the preset simulator according to the association relationship, and generate and return the loading result; receive the loading result sent by the cloud server, and in response to the program debugging instruction input on the debugger based on the loading result, send the program debugging instruction to the cloud server, so that the cloud server transmits the program debugging instruction to the preset simulator according to the association relationship, and runs the program debugging instruction through the target applet in the preset simulator to obtain the corresponding program debugging result. By establishing an association between the debugger and the preset simulator, the debugger on the terminal can send configuration parameters to the cloud server remotely according to the needs of debugging. The cloud server can load the target applet to be debugged into the preset simulator according to the configuration parameters. During the debugging process, when the debugger sends the program debugging instruction to the cloud server, debugging can be initiated. The cloud server can transmit the program debugging instruction to the preset simulator according to the association, and run the program debugging instruction through the target applet in the preset simulator, so that the applet that needs to be debugged does not need to be run and loaded locally on the terminal. The terminal no longer needs to set up a real machine running environment, and the entire process is debugged remotely on the cloud server. Debugging is initiated through the debugger on the terminal without the need to set up a special debugging environment. Therefore, terminals of any operating system can remotely debug the applet through the debugger to obtain the required program debugging results. The limitations of debugging are greatly reduced, which ultimately not only reduces the cost of applet debugging but also improves the efficiency of applet debugging.

[0214] See also Figure 12 , Figure 12 This is a structural diagram of the debugging device for the mini-program provided in an embodiment of the present application. The debugging device for the mini-program can be applied to the cloud server in the above embodiment (that is, the server in the above embodiment), or jointly executed by the terminal and the cloud server, wherein the debugging device for the mini-program may include an encapsulation unit 1201, a mini-program loading unit 1202, and a debugging unit 1203, etc.

[0215] The encapsulation unit 1201 is configured to generate a preset simulator corresponding to the debugger running on the terminal, and establish an association relationship between the debugger and the preset simulator;

[0216] The applet loading unit 1202 is used to receive the configuration parameters sent by the debugger, determine the target applet to be debugged in the preset applet library according to the configuration parameters, load the target applet into the preset simulator according to the association relationship, and return the loading result to the debugger;

[0217] The debugging unit 1203 is used to receive the program debugging instruction sent by the debugger, transmit the program debugging instruction to the preset simulator according to the association relationship, and run the program debugging instruction through the target applet in the preset simulator to obtain the corresponding program debugging result.

[0218] In some embodiments, the encapsulation unit 1201 is used to:

[0219] For debuggers running on multiple terminals respectively, a preset simulator corresponding to each debugger is generated, and an instruction transmission channel is established between each debugger and the preset simulator as an association relationship between each debugger and the preset simulator;

[0220] In some implementations, the debugging unit 1203 is configured to:

[0221] The program debugging instruction is sent to the instruction transmission channel, the program debugging instruction is converted into a preset format through the instruction transmission channel, and the program debugging instruction in the preset format is transmitted to the corresponding preset simulator.

[0222] In some implementations, the debugger carries an application identifier, and the encapsulation unit 1201 is further configured to:

[0223] Generate a preset simulator corresponding to the application identifier of each debugger, and establish an instruction transmission channel between the debugger and the preset simulator;

[0224] In some implementations, the debugging unit 1203 is further configured to:

[0225] The program debugging instruction in the preset format is transmitted to the preset simulator corresponding to the application identifier.

[0226] In some implementations, after obtaining the corresponding program debugging result, the debugging unit 1203 is further configured to:

[0227] When the program debugging result indicates that an abnormal event occurs during the operation of the target applet, a target use case corresponding to the abnormal event in the target applet is obtained;

[0228] Receive the use case debugging instructions sent by the debugger, transmit the use case debugging instructions to the preset simulator according to the association relationship, run the use case debugging instructions through the target applet in the preset simulator, load the target use case, and obtain the corresponding use case debugging results;

[0229] When the use case debugging result indicates that the target use case fails to load, the relevant internal interface functions in the target applet are obtained;

[0230] Receive the interface debugging instructions sent by the debugger, transmit the interface debugging instructions to the preset simulator according to the association relationship, run the interface debugging instructions through the target applet in the preset simulator, and call the internal interface function during the running process to obtain the corresponding interface debugging results.

[0231] In some implementations, the debugging unit 1203 is further configured to:

[0232] Determine the file path of the header file in the target applet according to the configuration parameters, and extract the header file according to the file path;

[0233] Get the relevant internal interface functions in the target applet from the header file.

[0234] In some implementations, the debugging unit 1203 is further configured to:

[0235] Obtain multiple program programming interface functions when the target applet runs the use case debugging instructions;

[0236] The internal instance information and internal attributes of the target applet are extracted from the header file based on multiple program programming interface functions, and the relevant internal interface functions in the target applet are obtained according to the internal instance information and internal attributes.

[0237] In some implementations, the debugging unit 1203 is further configured to:

[0238] The internal interface function is stored in a preset communication bridge by registering, and a breakpoint is set for the internal interface function in the communication bridge based on the interface debugging instruction;

[0239] When the internal interface function is identified to be called through the communication bridge, the corresponding interface data is obtained, and the breakpoint is triggered to terminate the operation of the target applet, and the corresponding interface debugging result is obtained according to the interface data.

[0240] In some implementations, when there are multiple internal interface functions, the debugging unit 1203 is further configured to:

[0241] Set up stacks for multiple internal interface functions and set corresponding breakpoints for each internal interface function;

[0242] The interface debugging instruction is run through the target applet in the preset simulator, and runs to the stack. Based on each breakpoint, each internal interface function is single-step debugged to obtain the interface debugging result corresponding to each internal interface function.

[0243] In some embodiments, the debugging apparatus of the applet further includes a preset simulator configuration unit (not identified), which is configured to:

[0244] Create a virtual machine or container, build an environment for the virtual machine or container that can run any applet in the preset applet library, and use the virtual machine or container with the built environment as the preset simulator;

[0245] Alternatively, a connection relationship with a preset mobile terminal is established, and a terminal environment of the preset mobile terminal is obtained according to the connection relationship, and the preset mobile terminal is used as a preset simulator based on the terminal environment.

[0246] The specific implementation of each of the above units can be found in the previous embodiments and will not be described again here.

[0247] From the above, it can be seen that the embodiment of the present application generates a preset simulator corresponding to the debugger for the debugger running on the terminal through the encapsulation unit 1201, and establishes an association relationship between the debugger and the preset simulator; receives the configuration parameters sent by the debugger through the applet loading unit 1202, and determines the target applet to be debugged in the preset applet library according to the configuration parameters, and loads the target applet into the preset simulator according to the association relationship, and returns the loading result to the debugger; receives the program debugging instructions sent by the debugger through the debugging unit 1203, transmits the program debugging instructions to the preset simulator according to the association relationship, and runs the program debugging instructions through the target applet in the preset simulator to obtain the corresponding program debugging results. In this way, by establishing an association between the debugger and the preset simulator, the debugger on the terminal can send configuration parameters to the cloud server remotely according to the needs of debugging, and the cloud server can load the target applet to be debugged into the preset simulator according to the configuration parameters. During the debugging process, when the debugger sends the program debugging instruction to the cloud server, debugging can be initiated. The cloud server can transmit the program debugging instruction to the preset simulator according to the association, and run the program debugging instruction through the target applet in the preset simulator, so that the applet that needs to be debugged does not need to be run and loaded locally on the terminal, and the terminal no longer needs to set up a real machine running environment. Instead, the entire process is debugged remotely on the cloud server, and debugging is initiated through the debugger on the terminal without the need to set up a special debugging environment. Therefore, terminals of any operating system can perform remote debugging of the applet through the debugger to obtain the required program debugging results. The limitations of debugging are greatly reduced, which ultimately not only reduces the cost of applet debugging but also improves the efficiency of applet debugging.

[0248] See also Figure 13 , Figure 13Another structural schematic diagram of the debugging device of the mini program provided in an embodiment of the present application, the debugging device of the mini program can be applied in the terminal in the above embodiment, or jointly executed by the terminal and the cloud server (that is, the server in the above embodiment), wherein the debugging device of the mini program may include a configuration input unit 1301 and an instruction input unit 1302, etc.

[0249] Configuration input unit 1301 is used to obtain configuration parameters in response to a configuration operation on the debugger, and configure the parameters to the cloud server, so that the cloud server determines the target applet to be debugged in the preset applet library based on the configuration parameters. The cloud server also generates a preset simulator corresponding to the debugger and establishes an association between the debugger and the preset simulator, so as to load the target applet into the preset simulator based on the association, and generate and return the loading result;

[0250] The instruction input unit 1302 is used to receive the loading result sent by the cloud server, and in response to the program debugging instruction input on the debugger based on the loading result, send the program debugging instruction to the cloud server, so that the cloud server transmits the program debugging instruction to the preset simulator according to the association relationship, and runs the program debugging instruction through the target applet in the preset simulator to obtain the corresponding program debugging result.

[0251] The specific implementation of each of the above units can be found in the previous embodiments and will not be described again here.

[0252] As can be seen from the above, the embodiment of the present application obtains configuration parameters in response to the configuration operation on the debugger through the configuration input unit 1301, and sends the configuration parameters to the cloud server, so that the cloud server determines the target applet to be debugged in the preset applet library according to the configuration parameters. The cloud server also generates a preset simulator corresponding to the debugger, and establishes an association relationship between the debugger and the preset simulator, so as to load the target applet into the preset simulator according to the association relationship, and generate and return the loading result; through the instruction input unit 1302, the loading result sent by the cloud server is received, and in response to the program debugging instruction input on the debugger based on the loading result, the program debugging instruction is sent to the cloud server, so that the cloud server transmits the program debugging instruction to the preset simulator according to the association relationship, and runs the program debugging instruction through the target applet in the preset simulator to obtain the corresponding program debugging result. By establishing an association between the debugger and the preset simulator, the debugger on the terminal can send configuration parameters to the cloud server remotely according to the needs of debugging. The cloud server can load the target applet to be debugged into the preset simulator according to the configuration parameters. During the debugging process, when the debugger sends the program debugging instruction to the cloud server, debugging can be initiated. The cloud server can transmit the program debugging instruction to the preset simulator according to the association, and run the program debugging instruction through the target applet in the preset simulator, so that the applet that needs to be debugged does not need to be run and loaded locally on the terminal. The terminal no longer needs to set up a real machine running environment, and the entire process is debugged remotely on the cloud server. Debugging is initiated through the debugger on the terminal without the need to set up a special debugging environment. Therefore, terminals of any operating system can remotely debug the applet through the debugger to obtain the required program debugging results. The limitations of debugging are greatly reduced, which ultimately not only reduces the cost of applet debugging but also improves the efficiency of applet debugging.

[0253] The embodiment of the present application also provides a computer device, which may be a terminal, such as Figure 14 As shown, it shows a schematic diagram of the structure of the terminal involved in the embodiment of the present application, specifically:

[0254] The computer device may include components such as a radio frequency (RF) circuit 1401, a memory 1402 including one or more computer-readable storage media, an input unit 1403, a display unit 1404, a sensor 1405, an audio circuit 1406, a wireless fidelity (WiFi) module 1407, a processor 1408 including one or more processing cores, and a power supply 1409. It will be understood by those skilled in the art that Figure 14The terminal structure shown in the figure does not constitute a limitation on the terminal, and may include more or fewer components than shown in the figure, or combine certain components, or arrange the components differently.

[0255] RF circuit 1401 can be used to receive and send signals during information transmission or calls. Specifically, after receiving downlink information from the base station, it is handed over to one or more processors 1408 for processing. In addition, uplink data is sent to the base station. Generally, RF circuit 1401 includes but is not limited to an antenna, at least one amplifier, a tuner, one or more oscillators, a Subscriber Identity Module (SIM) card, a transceiver, a coupler, a low-noise amplifier (LNA), a duplexer, etc. In addition, RF circuit 1401 can also communicate with the network and other devices via wireless communication. Wireless communication can use any communication standard or protocol, including but not limited to Global System of Mobile Communications (GSM), General Packet Radio Service (GPRS), Code Division Multiple Access (CDMA), Wideband Code Division Multiple Access (WCDMA), Long Term Evolution (LTE), email, Short Messaging Service (SMS), etc.

[0256] The memory 1402 can be used to store software programs and modules. The processor 1408 executes various functional applications and information retrieval by running the software programs and modules stored in the memory 1402. The memory 1402 may mainly include a program storage area and a data storage area. The program storage area may store an operating system, at least one application required for a function (such as a sound playback function, an image playback function, etc.), etc.; the data storage area may store data created based on the use of the terminal (such as audio data, a phone book, etc.). In addition, the memory 1402 may include a high-speed random access memory and may also include a non-volatile memory, such as at least one disk storage device, a flash memory device, or other volatile solid-state storage device. Accordingly, the memory 1402 may also include a memory controller to provide the processor 1408 and the input unit 1403 with access to the memory 1402.

[0257] Input unit 1403 can be used to receive input digital or character information and generate keyboard, mouse, joystick, optical, or trackball signal input related to object settings and function control. Specifically, in one embodiment, input unit 1403 may include a touch-sensitive surface and other input devices. A touch-sensitive surface, also known as a touch display or touchpad, can detect touch operations performed on or near it (for example, operations performed on or near the touch-sensitive surface using a finger, stylus, or any other suitable object or accessory) and drive corresponding connected devices according to a pre-set program. Optionally, the touch-sensitive surface may include a touch detection device and a touch controller. The touch detection device detects the touch position of the object and detects signals generated by the touch operation, transmitting the signals to the touch controller. The touch controller receives the touch information from the touch detection device, converts it into touch point coordinates, and then sends it to processor 1408. The touch controller can also receive and execute commands from processor 1408. Furthermore, touch-sensitive surfaces can be implemented using various types of devices, including resistive, capacitive, infrared, and surface acoustic wave. In addition to touch-sensitive surfaces, input unit 1403 may also include other input devices. Specifically, other input devices may include, but are not limited to, one or more of a physical keyboard, function keys (such as a volume control key, a switch key, etc.), a trackball, a mouse, a joystick, and the like.

[0258] The display unit 1404 can be used to display information input by the object or information provided to the object and various graphic object interfaces of the terminal, which can be composed of graphics, text, icons, videos and any combination thereof. The display unit 1404 may include a display panel. Optionally, the display panel may be configured in the form of a liquid crystal display (LCD), an organic light-emitting diode (OLED), etc. Further, the touch-sensitive surface may cover the display panel. When the touch-sensitive surface detects a touch operation on or near it, it is transmitted to the processor 1408 to determine the type of touch event. The processor 1408 then provides corresponding visual output on the display panel according to the type of touch event. Although in Figure 14 In the embodiment, the touch-sensitive surface and the display panel are used as two independent components to realize input and output functions, but in some embodiments, the touch-sensitive surface and the display panel can be integrated to realize input and output functions.

[0259] The terminal may also include at least one sensor 1405, such as a light sensor, a motion sensor, and other sensors. Specifically, the light sensor may include an ambient light sensor and a proximity sensor, wherein the ambient light sensor may adjust the brightness of the display panel according to the brightness of the ambient light, and the proximity sensor may turn off the display panel and / or backlight when the terminal is moved to the ear. As a type of motion sensor, the gravity acceleration sensor can detect the magnitude of acceleration in all directions (generally three axes), and can detect the magnitude and direction of gravity when stationary. It can be used for applications that identify the posture of the mobile phone (such as horizontal and vertical screen switching, related games, magnetometer posture calibration), vibration recognition related functions (such as pedometer, tapping), etc.; as for other sensors that can be configured in the terminal, such as gyroscopes, barometers, hygrometers, thermometers, infrared sensors, etc., they will not be described here.

[0260] Audio circuit 1406, speakers, and microphones provide an audio interface between the device and the terminal. Audio circuit 1406 converts received audio data into electrical signals and transmits them to the speaker, which then converts them into sound signals for output. Conversely, the microphone converts collected sound signals into electrical signals, which are then received by audio circuit 1406 and converted into audio data. The audio data is then processed by processor 1408 and transmitted via RF circuit 1401 to, for example, another terminal. Alternatively, the audio data is output to memory 1402 for further processing. Audio circuit 1406 may also include an earphone jack to allow communication between an external headset and the terminal.

[0261] WiFi is a short-range wireless transmission technology. The terminal can help the object to send and receive emails, browse the web and access streaming media through the WiFi module 1407. It provides wireless broadband Internet access for the object. Figure 14 A WiFi module 1407 is shown, but it is understandable that it is not an essential component of the terminal and can be omitted as needed without changing the essence of the invention.

[0262] Processor 1408 is the terminal's control center, connecting all components of the phone using various interfaces and circuits. By running or executing software programs and / or modules stored in memory 1402 and accessing data stored in memory 1402, it executes various terminal functions and processes data, thereby providing overall monitoring of the phone. Optionally, processor 1408 may include one or more processing cores; preferably, processor 1408 may integrate an application processor and a modem processor. The application processor primarily handles the operating system, object interfaces, and application programs, while the modem processor primarily handles wireless communications. It is understood that the modem processor may not be integrated into processor 1408.

[0263] The terminal also includes a power supply 1409 (e.g., a battery) for supplying power to various components. Preferably, the power supply can be logically connected to the processor 1408 via a power management system, thereby enabling the power management system to manage charging, discharging, and power consumption. The power supply 1409 can also include one or more DC or AC power supplies, a recharging system, a power failure detection circuit, a power converter or inverter, a power status indicator, and other arbitrary components.

[0264] Although not shown, the terminal may also include a camera, a Bluetooth module, etc., which will not be described in detail here. Specifically, in this embodiment, the processor 1408 in the terminal will load the executable files corresponding to the processes of one or more applications into the memory 1402 according to the following instructions, and the processor 1408 will run the applications stored in the memory 1402 to implement various functions:

[0265] For the debugger running on the terminal, generate a preset simulator corresponding to the debugger, and establish an association relationship between the debugger and the preset simulator;

[0266] Receive the configuration parameters sent by the debugger, and determine the target applet to be debugged in the preset applet library according to the configuration parameters, load the target applet into the preset simulator according to the association relationship, and return the loading result to the debugger;

[0267] Receive the program debugging instructions sent by the debugger, transmit the program debugging instructions to the preset simulator according to the association relationship, and run the program debugging instructions through the target applet in the preset simulator to obtain the corresponding program debugging results.

[0268] Or implement:

[0269] In response to a configuration operation on the debugger, configuration parameters are obtained and configured to the cloud server, so that the cloud server determines a target applet to be debugged in a preset applet library according to the configuration parameters. The cloud server also generates a preset simulator corresponding to the debugger and establishes an association between the debugger and the preset simulator, so as to load the target applet into the preset simulator according to the association, and generate and return a loading result.

[0270] Receive the loading result sent by the cloud server, and in response to the program debugging instruction input on the debugger based on the loading result, send the program debugging instruction to the cloud server, so that the cloud server transmits the program debugging instruction to the preset simulator according to the association relationship, and runs the program debugging instruction through the target applet in the preset simulator to obtain the corresponding program debugging result.

[0271] In the above embodiments, the description of each embodiment has its own focus. For the part that is not described in detail in a certain embodiment, please refer to the detailed description of the debugging method for the mini program above, which will not be repeated here.

[0272] From the above, it can be seen that the computer device of the embodiment of the present application can generate a preset simulator corresponding to the debugger running on the terminal, and establish an association relationship between the debugger and the preset simulator; receive the configuration parameters sent by the debugger, and determine the target applet to be debugged in the preset applet library according to the configuration parameters, and load the target applet into the preset simulator according to the association relationship, and return the loading result to the debugger; receive the program debugging instructions sent by the debugger, transmit the program debugging instructions to the preset simulator according to the association relationship, and run the program debugging instructions through the target applet in the preset simulator to obtain the corresponding program debugging results. In this way, by establishing an association between the debugger and the preset simulator, the debugger on the terminal can send configuration parameters to the cloud server remotely according to the needs of debugging, and the cloud server can load the target applet to be debugged into the preset simulator according to the configuration parameters. During the debugging process, when the debugger sends the program debugging instruction to the cloud server, debugging can be initiated. The cloud server can transmit the program debugging instruction to the preset simulator according to the association, and run the program debugging instruction through the target applet in the preset simulator, so that the applet that needs to be debugged does not need to be run and loaded locally on the terminal, and the terminal no longer needs to set up a real machine running environment. Instead, the entire process is debugged remotely on the cloud server, and debugging is initiated through the debugger on the terminal without the need to set up a special debugging environment. Therefore, terminals of any operating system can perform remote debugging of the applet through the debugger to obtain the required program debugging results. The limitations of debugging are greatly reduced, which ultimately not only reduces the cost of applet debugging but also improves the efficiency of applet debugging.

[0273] Those skilled in the art will appreciate that all or part of the steps in the various methods of the above embodiments may be accomplished by instructions, or by controlling related hardware through instructions. The instructions may be stored in a computer-readable storage medium and loaded and executed by a processor.

[0274] To this end, an embodiment of the present application provides a computer-readable storage medium storing a plurality of instructions that can be loaded by a processor to execute the steps of any of the mini-program debugging methods provided in the embodiments of the present application. For example, the instructions can execute the following steps:

[0275] For the debugger running on the terminal, generate a preset simulator corresponding to the debugger, and establish an association relationship between the debugger and the preset simulator;

[0276] Receive the configuration parameters sent by the debugger, and determine the target applet to be debugged in the preset applet library according to the configuration parameters, load the target applet into the preset simulator according to the association relationship, and return the loading result to the debugger;

[0277] Receive the program debugging instructions sent by the debugger, transmit the program debugging instructions to the preset simulator according to the association relationship, and run the program debugging instructions through the target applet in the preset simulator to obtain the corresponding program debugging results.

[0278] Or implement:

[0279] In response to a configuration operation on the debugger, configuration parameters are obtained and configured to the cloud server, so that the cloud server determines a target applet to be debugged in a preset applet library according to the configuration parameters. The cloud server also generates a preset simulator corresponding to the debugger and establishes an association between the debugger and the preset simulator, so as to load the target applet into the preset simulator according to the association, and generate and return a loading result.

[0280] Receive the loading result sent by the cloud server, and in response to the program debugging instruction input on the debugger based on the loading result, send the program debugging instruction to the cloud server, so that the cloud server transmits the program debugging instruction to the preset simulator according to the association relationship, and runs the program debugging instruction through the target applet in the preset simulator to obtain the corresponding program debugging result.

[0281] According to one aspect of the present application, a computer program product or computer program is provided, comprising computer instructions stored in a computer-readable storage medium. A processor of a computer device reads the computer instructions from the computer-readable storage medium and executes the computer instructions, causing the computer device to perform the methods provided in the various optional implementations provided in the above embodiments.

[0282] The specific implementation of the above operations can be found in the previous embodiments and will not be repeated here.

[0283] The computer-readable storage medium may include a read-only memory (ROM), a random access memory (RAM), a magnetic disk or an optical disk, etc.

[0284] Since the instructions stored in the computer-readable storage medium can execute the steps in any of the mini-program debugging methods provided in the embodiments of the present application, the beneficial effects that can be achieved by any of the mini-program debugging methods provided in the embodiments of the present application can be achieved. Please see the previous embodiments for details and will not be repeated here.

[0285] The above is a detailed introduction to the debugging method, device, storage medium and equipment of a small program provided in the embodiments of the present application. Specific examples are used in this article to illustrate the principles and implementation methods of the present application. The description of the above embodiments is only used to help understand the method of the present application and its core idea; at the same time, for technical personnel in this field, based on the ideas of the present application, there will be changes in the specific implementation methods and application scope. In summary, the content of this specification should not be understood as a limitation on the present application.

Claims

1. A method for debugging a small program, characterized in that: include: For a debugger running on a terminal, generating a preset simulator corresponding to the debugger, and establishing an association relationship between the debugger and the preset simulator; receiving configuration parameters sent by the debugger, and determining a target applet to be debugged in a preset applet library according to the configuration parameters, loading the target applet into the preset simulator according to the association relationship, and returning the loading result to the debugger; Receive the program debugging instruction sent by the debugger, transmit the program debugging instruction to the preset simulator according to the association relationship, and run the program debugging instruction through the target applet in the preset simulator to obtain a corresponding program debugging result.

2. The method for debugging a small program according to claim 1, characterized in that: The step of generating a preset simulator corresponding to a debugger running on a terminal and establishing an association relationship between the debugger and the preset simulator includes: For debuggers respectively running on multiple terminals, generating a preset simulator corresponding to each debugger, and establishing an instruction transmission channel between each debugger and the preset simulator as an association relationship between each debugger and the preset simulator; The transmitting the program debugging instruction to the preset simulator according to the association relationship includes: The program debugging instruction is sent to the instruction transmission channel, the program debugging instruction is converted into a preset format through the instruction transmission channel, and the program debugging instruction in the preset format is transmitted to a corresponding preset simulator.

3. The method for debugging a small program according to claim 2, characterized in that: The debugger carries an application identifier, and the generating of a preset simulator corresponding to each debugger and the establishing of an instruction transmission channel between each debugger and the preset simulator include: generating a preset simulator corresponding to the application identifier of each debugger, and establishing an instruction transmission channel between the debugger and the preset simulator; The transmitting the program debugging instruction in the preset format to the corresponding preset simulator includes: The program debugging instruction in the preset format is transmitted to a preset simulator corresponding to the application identifier.

4. The method for debugging a small program according to claim 1, wherein: After obtaining the corresponding program debugging result, the mini-program debugging method further includes: When the program debugging result indicates that an abnormal event occurs during the operation of the target applet, obtaining a target use case corresponding to the abnormal event in the target applet; receiving a use case debugging instruction sent by the debugger, transmitting the use case debugging instruction to the preset simulator according to the association relationship, and running the use case debugging instruction through the target applet in the preset simulator to load the target use case and obtain a corresponding use case debugging result; When the use case debugging result indicates that the target use case fails to load, obtaining a related internal interface function in the target applet; Receive the interface debugging instruction sent by the debugger, transmit the interface debugging instruction to the preset simulator according to the association relationship, run the interface debugging instruction through the target applet in the preset simulator, and call the internal interface function during the running process to obtain the corresponding interface debugging result.

5. The method for debugging a small program according to claim 4, characterized in that: The obtaining of the relevant internal interface functions in the target applet includes: Determine a file path of a header file in the target applet according to the configuration parameters, and extract the header file according to the file path; Relevant internal interface functions in the target applet are obtained from the header file.

6. The method for debugging a small program according to claim 5, characterized in that: The step of obtaining the relevant internal interface functions in the target applet from the header file includes: Acquire multiple program programming interface functions when the target applet runs the use case debugging instruction; Based on the plurality of program programming interface functions, internal instance information and internal attributes of the target applet are extracted from the header file, and the relevant internal interface functions in the target applet are obtained according to the internal instance information and internal attributes.

7. The method for debugging a small program according to claim 4, characterized in that: The internal interface function is called during the operation to obtain the corresponding interface debugging result, including: storing the internal interface function in a preset communication bridge by registering it, and setting a breakpoint for the internal interface function in the communication bridge based on the interface debugging instruction; When it is recognized through the communication bridge that the internal interface function is called, the corresponding interface data is obtained, and the breakpoint is triggered to stop the running of the target applet, and the corresponding interface debugging result is obtained according to the interface data.

8. The method for debugging a small program according to claim 4, characterized in that: When there are multiple internal interface functions, running the interface debugging instruction through the target applet in the preset simulator, and calling the internal interface function during the running process to obtain the corresponding interface debugging result, including: Setting a stack for the plurality of internal interface functions, and setting a corresponding breakpoint for each of the internal interface functions; The interface debugging instruction is run through the target applet in the preset simulator and runs to the stack. Based on each breakpoint, each internal interface function is single-step debugged to obtain the interface debugging result corresponding to each internal interface function.

9. The method for debugging a small program according to claim 1, wherein: The preset simulator is configured by the following steps: Creating a virtual machine or a container, building an environment for the virtual machine or the container for running any applet in the preset applet library, and using the virtual machine or the container after the environment is built as the preset simulator; Alternatively, a connection relationship with a preset mobile terminal is established, and a terminal environment of the preset mobile terminal is obtained according to the connection relationship, and the preset mobile terminal is used as the preset simulator based on the terminal environment.

10. A method for debugging a small program, characterized in that: include: In response to a configuration operation on the debugger, configuration parameters are obtained and sent to a cloud server, so that the cloud server determines a target applet to be debugged in a preset applet library according to the configuration parameters. The cloud server also generates a preset simulator corresponding to the debugger and establishes an association between the debugger and the preset simulator, so as to load the target applet into the preset simulator according to the association, and generate and return a loading result. Receive the loading result sent by the cloud server, and in response to the program debugging instruction input on the debugger based on the loading result, send the program debugging instruction to the cloud server, so that the cloud server transmits the program debugging instruction to the preset simulator according to the association relationship, and runs the program debugging instruction through the target applet in the preset simulator to obtain corresponding program debugging results.

11. A debugging device for a small program, characterized in that: include: An encapsulation unit, configured to generate a preset simulator corresponding to a debugger running on a terminal, and establish an association relationship between the debugger and the preset simulator; A mini-program loading unit, configured to receive configuration parameters sent by the debugger, determine a target mini-program to be debugged in a preset mini-program library according to the configuration parameters, load the target mini-program into the preset simulator according to the association relationship, and return the loading result to the debugger; The debugging unit is used to receive the program debugging instruction sent by the debugger, transmit the program debugging instruction to the preset simulator according to the association relationship, and run the program debugging instruction through the target applet in the preset simulator to obtain corresponding program debugging results.

12. A debugging device for a small program, characterized in that: include: A configuration input unit, configured to obtain configuration parameters in response to a configuration operation on the debugger, and send the configuration parameters to a cloud server, so that the cloud server determines a target applet to be debugged in a preset applet library according to the configuration parameters. The cloud server also generates a preset simulator corresponding to the debugger, establishes an association between the debugger and the preset simulator, loads the target applet into the preset simulator according to the association, and generates and returns a loading result. An instruction input unit is used to receive the loading result sent by the cloud server, and in response to the program debugging instruction input on the debugger based on the loading result, send the program debugging instruction to the cloud server, so that the cloud server transmits the program debugging instruction to the preset simulator according to the association relationship, and runs the program debugging instruction through the target applet in the preset simulator to obtain corresponding program debugging results.

13. A computer-readable storage medium, characterized in that The computer-readable storage medium stores a plurality of instructions, which are suitable for loading by a processor to execute the debugging method of the applet according to any one of claims 1 to 9, or the steps in the debugging method of the applet according to claim 10.

14. A computer device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein: When the processor executes the computer program, it implements the method for debugging the applet according to any one of claims 1 to 9, or the steps in the method for debugging the applet according to claim 10.

15. A computer program product comprising a computer program, characterized in that When the computer program is executed by a processor, it implements the method for debugging a mini-program according to any one of claims 1 to 9, or the steps in the method for debugging a mini-program according to claim 10.

Images