An applet running state monitoring method and device, a terminal and a medium

Abstract

This application discloses a method, device, terminal, and medium for monitoring the running status of a mini-program. The method provided by this application monitors the progress of the mini-program's startup phase. After the first loading phase of the mini-program's startup phase is completed, a preset startup phase monitoring logic is initiated. This allows for monitoring logic operations performed during the startup phase and the page loading phase. By integrating Taro into Arms, the monitoring logic can be obtained without modifying the native code files, thus enabling the mini-program's running status results to be obtained during the startup and page loading phases. This solves the technical problem that existing mini-program running status monitoring methods are cumbersome and time-consuming to write.

Description

Technical Field

[0001] This application relates to the field of software technology, and in particular to a method, device, terminal and medium for monitoring the running status of a mini-program. Background Technology

[0002] With the rapid development of internet technology, mini-programs, as a convenient tool that can be used without downloading or installing, have received widespread attention from all walks of life. Mini-programs need to run through a specific platform, such as WeChat mini-programs, which need to run on the WeChat platform.

[0003] To ensure the normal operation of mini-program services, after a mini-program is launched and running, it is necessary to monitor its operational status data to measure its health. Currently, the most commonly used method for monitoring the operational status of mini-programs is Alibaba Cloud's ARMS front-end monitoring method, which supports the native code of the mini-program, allowing it to directly integrate monitoring capabilities. However, native support requires writing monitoring logic for each file, which is a heavy and time-consuming task. Summary of the Invention

[0004] This application provides a method, device, terminal, and medium for monitoring the running status of mini-programs, which solves the technical problem that existing mini-program running status monitoring methods require writing targeted monitoring logic for each file, which is a heavy and time-consuming task.

[0005] The first aspect of this application provides a method for monitoring the running status of a mini-program, including:

[0006] When the launch of the mini-program to be monitored is detected, the launch phase of the mini-program is monitored;

[0007] After the mini-program has completed the first loading stage in the startup phase, the preset startup phase monitoring logic is started to obtain the startup error information of the mini-program and the feedback information of third-party service calls, and the startup phase running status information of the mini-program is determined based on the startup error information and the feedback information of third-party service calls.

[0008] Once the mini-program is launched, a preset page monitoring logic is initiated to obtain the page rendering information of the mini-program, and the running status information of the page loading stage of the mini-program is determined based on the page rendering information.

[0009] The running status of the mini-program is determined based on the running status information of the startup phase and the running status information of the page loading phase.

[0010] Preferably, determining the startup phase running status information of the mini-program based on the startup error information and the third-party service call feedback information specifically includes:

[0011] Based on the startup error information, the error event of the mini-program is located to obtain the error location information;

[0012] Calculate the success rate of third-party service requests based on the feedback information from the third-party service calls.

[0013] Based on the error location information and the call success rate, the startup phase running status information of the mini-program is determined.

[0014] Preferably, the startup error information specifically includes: error text, error line number, error time, user's device model and user network on which the mini-program is running.

[0015] Preferably, the feedback information for the third-party service call specifically includes: the input parameters, path, user device type, user network, and request status of the third-party service interface request.

[0016] Preferably, calculating the success rate of the third-party service request based on the third-party service call feedback information specifically includes:

[0017] Based on the input parameters, path, and user device type of the third-party service interface request, the requests are classified according to the request objects corresponding to each third-party service interface request. Then, based on the user network and request status of the same request object, the success rate of calling all interface services under the request object is calculated.

[0018] Preferably, the page rendering information specifically includes: page information and page rendering time.

[0019] Preferably, determining the running status information of the mini-program during the page loading stage based on the page rendering information specifically includes:

[0020] Based on the page rendering time corresponding to the page information, the page rendering time is compared with a preset rendering time threshold to determine the running status information of the page loading stage of the mini program based on the comparison result.

[0021] A second aspect of this application provides a device for monitoring the running status of a mini-program, comprising:

[0022] The mini-program startup detection unit is used to monitor the startup phase of the mini-program when it is detected that the mini-program to be monitored has started.

[0023] The startup phase monitoring trigger unit is used to start a preset startup phase monitoring logic after the mini program has executed the first loading phase in the startup phase, so as to obtain the startup error information and third-party service call feedback information of the mini program, and determine the startup phase running status information of the mini program based on the startup error information and the third-party service call feedback information.

[0024] The page loading phase monitoring trigger unit is used to start a preset page monitoring logic after the mini program is launched, so as to obtain the page rendering information of the mini program and determine the running status information of the page loading phase of the mini program based on the page rendering information.

[0025] The mini-program running status determination unit is used to determine the running status of the mini-program based on the running status information of the startup phase and the running status information of the page loading phase.

[0026] A third aspect of this application provides a terminal for monitoring the running status of a mini-program, including: a memory and a processor;

[0027] The memory is used to store program code, which corresponds to a method for monitoring the running status of a mini-program as provided in the first aspect of this application.

[0028] The processor is used to execute the program code.

[0029] The fourth aspect of this application provides a computer-readable storage medium storing program code, which corresponds to a method for monitoring the running status of a mini-program as provided in the first aspect of this application.

[0030] As can be seen from the above technical solutions, the embodiments of this application have the following advantages:

[0031] The method provided in this application monitors the startup progress of the mini-program. After the first loading stage of the mini-program's startup progress is completed, a preset startup monitoring logic is started. This logic enables the integration of Taro with Arms without modifying the monitoring logic in the native code files. It can also obtain the running status results of the mini-program in the startup and page loading stages, thereby determining the running status of the mini-program. This solves the technical problem that existing mini-program running status monitoring methods are cumbersome and time-consuming to write. Attached Figure Description

[0032] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0033] Figure 1 This is a flowchart of the Taro framework integration process.

[0034] Figure 2 for Figure 1 The flowchart shown is a process for the loader parsing file stage during the access process.

[0035] Figure 3 This is a flowchart illustrating a method for monitoring the running status of a mini-program provided in this application.

[0036] Figure 4 This is a schematic diagram of the structure of a mini-program operation status monitoring device provided in this application. Detailed Implementation

[0037] Currently, the most commonly used methods for monitoring the runtime status of mini-programs are Alibaba Cloud's ARM front-end monitoring method. This method supports the native code of the mini-program, allowing the native code to directly integrate monitoring capabilities. However, it does not support the existing ARM front-end monitoring methods of the Taro framework. Moreover, native support requires writing monitoring logic for each file. Currently, a typical mini-program usually contains thousands of files. If monitoring logic code has to be written for each one, the task is cumbersome and time-consuming.

[0038] This application provides a method, device, terminal, and medium for monitoring the running status of a mini-program, which solves the technical problem that existing mini-program running status monitoring methods require writing targeted monitoring logic for each file, resulting in a heavy and time-consuming writing task.

[0039] To make the inventive objectives, features, and advantages of this application more apparent and understandable, the technical solutions in the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the embodiments described below are only some embodiments of this application, and not all embodiments. Based on the embodiments in this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0040] The technical solution in this application can effectively connect the Taro framework and Alibaba Cloud Arms front-end monitoring through simple code, thereby enabling the monitoring of the online status of mini-programs. For example... Figure 1 As shown, based on the applicant's research on the Taro framework, it was discovered that a custom loader process can be executed through the Taro loader stage to achieve the integration of the Taro framework. The technical solution of this application is to add a custom plugin to the webpack plugin chain to achieve the purpose of executing a custom loader process in the loader stage, thereby integrating Taro into Arms and enabling it to play the role of mini-program status monitoring. The same function can be achieved with less than 10 lines of code, avoiding the need to modify thousands of files when using native code.

[0041] like Figure 2 As shown, the loader stage in this embodiment consists of four parts. The jx file, babel-loader, and taro-loader are existing technologies, while the arms-loader part is the part optimized in this application, which is the process corresponding to the method for monitoring the running status of a mini-program provided in this application.

[0042] Please see Figure 3 The first embodiment of this application provides a method for monitoring the running status of a mini-program, including:

[0043] Step 101: When the mini-program to be monitored is detected to be launched, monitor the launch phase of the mini-program.

[0044] Step 102: After the mini program has completed the first loading stage in the startup phase, start the preset startup phase monitoring logic to obtain the startup error information of the mini program and the feedback information of third-party service calls, and determine the startup phase running status information of the mini program based on the startup error information and the feedback information of third-party service calls.

[0045] It should be noted that the first loading stage in the startup phase mentioned in this embodiment refers to... Figure 2 The current stage in the startup phase shown is the JSX file parsing stage to the taro-loader stage. After the taro-loader finishes, the loader used by this technology continues to execute on the code, starting the preset startup phase monitoring logic, namely the Monitor.hookApp() function. This function is used to execute the monitoring logic for the mini-program during the startup phase, because the tens of thousands of characters compiled by taro originally only included the creation feedback function, createReactApp(), which is called only during the mini-program startup phase.

[0046] In this embodiment, the custom Monitor.hookApp() function is based on the created feedback function createReactApp(), which incorporates monitoring logic code. That is, the Monitor.hookApp() function first executes the monitoring logic operation and only calls the createReactApp() function to successfully start the mini program after confirming that the mini program is running healthily during the startup phase.

[0047] In some embodiments, the step 102 of determining the startup phase running status information of the mini-program based on startup error information and third-party service call feedback information may specifically include:

[0048] Based on the startup error information, the error events of the mini program are located to obtain the error location information; based on the feedback information of third-party service calls, the success rate of third-party service requests is calculated; based on the error location information and the success rate of calls, the running status information of the mini program in the startup phase is determined.

[0049] After the Monitor.hookApp() function starts, the overridden 'onLaunch' startup function and 'onError' function will be called. Because the original 'onLaunch' and 'onError' functions of the mini program object do not include monitoring execution logic, the functions need to be rewritten in advance.

[0050] ① The rewritten 'onLaunch' startup function will be called when the mini program starts. It can perform the operation of obtaining the startup time of the mini program. After obtaining the startup time, it will be reported to the backend so that the backend can monitor the subsequent running status of the current mini program based on the current startup time.

[0051] ② The rewritten 'onError' function is activated when a mini-program reports an error. It retrieves specific error information and sends it to the backend, allowing the backend to pinpoint the exact location of the error. This information includes the error text (e.g., an object not found, an object in mini-program version A that is obsolete in the updated version B), line number (identifying the specific location of the error in the mini-program code), time, user device model, and user network. The text, line number, time, user device model, and user network information clearly indicate "at what time, which user, and which mini-program encountered which error, and in which line and column of the corresponding mini-program file." This detailed information can be used to assess the health of the mini-program's operation.

[0052] The rewritten `send()` function of the global object `XMLHttpReques` class in the mini-program's code (adding data feedback functionality for third-party service calls) collects specific information such as input parameters, path, user device type, user network, and request status of the mini-program's requests to third-party service interfaces, and then reports it to the backend. The backend can calculate the success rate of the current mini-program's external service calls based on this information; this monitoring metric determines whether the interface request was successful, and the request status indicates success (Yes or No). The backend can also analyze different interfaces under various domains based on input parameters, path, and user device type, and then calculate the interface call success rate for all interfaces under the same domain based on user network and request status. The backend configures a success rate threshold for each domain. If the calculated interface call success rate for each domain is greater than the current threshold, the mini-program's current startup phase is considered healthy. For example, if domain A has three different interfaces, a1, a2, and a3, and the calculated average interface call success rate is 98%, and the current pre-configured success threshold for domain A is 95%, then this indicates that the current mini-program startup can meet this threshold, and the current running status of the mini-program startup phase is determined to be healthy.

[0053] Step 103: After the mini program starts, start the preset page monitoring logic to obtain the page rendering information of the mini program, and determine the running status information of the page loading stage of the mini program based on the page rendering information.

[0054] It should be noted that once the mini program has finished launching, the preset page monitoring logic Monitor.hookPage() will be started. This function is used to execute the monitoring logic for the running status of the mini program's page. This is because the tens of thousands of characters compiled by Taro originally only contained the page configuration function called by the mini program when the page is running, namely createPageConfig().

[0055] In some embodiments, the page rendering information preferably includes page information and page rendering time, but may also include other information, such as page information and page rendering success rate.

[0056] The steps mentioned in step 103, which involve determining the running status information of the mini-program during the page loading stage based on page rendering information, may include:

[0057] Based on the page rendering time corresponding to the page information, the page rendering time is compared with a preset rendering time threshold to determine the running status information of the page loading stage of the mini program.

[0058] The custom Monitor.hookPage() function in this application first executes the monitoring logic for each running page. Only after confirming that the current page is running healthily will it call the page configuration function createPageConfig() to successfully display the current page.

[0059] After the Monitor.hookPage() function starts, it calls the overridden `onLoad` loading function and `onReady` preparation function. Because the original `onLoad` and `onReady` functions of the mini-program object do not include monitoring execution logic, it is necessary to rewrite the functions in advance.

[0060] ① When the onLoad function is executed, the current page of the mini-program is time-stamped to record the start time;

[0061] ② When the onReady function finishes executing, the time of the current page of the mini program is marked and the end time is recorded. Then, the start time is subtracted from the end time to obtain the page rendering time. The page name of the current page and the rendering time of the page are reported to the backend. The backend will analyze the rendering time, for example, by comparing the rendering time of the current page with a time threshold. If it exceeds the threshold, it is determined that there may be a problem with the current page and the mini program needs to be further optimized.

[0062] Step 104: Determine the running status of the mini-program based on the running status information during the startup phase and the page loading phase.

[0063] Finally, based on the two sets of running status information obtained in steps 102 and 103, if the running status information of the mini program shows a healthy status in both the startup phase and the page loading phase, then the running status of the mini program can be determined to be healthy.

[0064] The method provided in this embodiment, based on the Taro framework, monitors the startup progress of the mini-program. After the Taro-loader stage is completed, a preset startup monitoring logic is initiated. This logic includes monitoring operations executed by the app-loader during startup and by the page-loader during page loading. This allows Taro to be integrated into Arms without modifying the native code files for monitoring logic. The same functionality can be achieved with less than 10 lines of code, thereby determining the running status of the mini-program. This solves the technical problem of the heavy workload and time consumption of existing mini-program running status monitoring methods.

[0065] The above content is a detailed description of the method for monitoring the running status of a mini-program provided in this application. The following is a detailed description of the device for monitoring the running status of a mini-program provided in this application.

[0066] Please see Figure 4 The second embodiment of this application provides a device for monitoring the running status of a mini-program, including:

[0067] Mini Program Startup Detection Unit 201 is used to detect the startup phase of a mini program when it is detected that the mini program to be monitored has started.

[0068] The startup phase monitoring trigger unit 202 is used to start the preset startup phase monitoring logic after the mini program has executed the first loading phase in the startup phase, so as to obtain the startup error information of the mini program and the feedback information of third-party service calls, and determine the startup phase running status information of the mini program based on the startup error information and the feedback information of third-party service calls.

[0069] The page loading phase monitoring trigger unit 203 is used to start the preset page monitoring logic after the mini program starts to obtain the page rendering information of the mini program, and determine the running status information of the page loading phase of the mini program based on the page rendering information.

[0070] The mini-program running status determination unit 204 is used to determine the running status of the mini-program based on the running status information of the startup phase and the running status information of the page loading phase.

[0071] The above content is a detailed description of the mini-program running status monitoring device provided in this application. The following is a detailed description of the mini-program running status monitoring terminal and the computer-readable storage medium provided in this application.

[0072] First, this application provides an embodiment of a mini-program running status monitoring terminal, which includes: a memory and a processor;

[0073] The memory is used to store program code, which corresponds to a method for monitoring the running status of a mini-program as provided in the first embodiment of this application.

[0074] The processor is used to execute program code.

[0075] Next, this application provides an embodiment of a computer-readable storage medium, which stores program code corresponding to a method for monitoring the running status of a small program as provided in the first embodiment of this application.

[0076] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working processes of the terminals, devices, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here.

[0077] In the several embodiments provided in this application, it should be understood that the disclosed apparatus and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between apparatuses or units may be electrical, mechanical, or other forms.

[0078] The terms “first,” “second,” “third,” “fourth,” etc. (if present) in the specification and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that embodiments of the application described herein can be implemented, for example, in orders other than those illustrated or described herein. Furthermore, the terms “comprising” and “having,” and any variations thereof, are intended to cover a non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0079] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0080] Furthermore, the functional units in the various embodiments of the present invention can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0081] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present invention, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of the present invention. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0082] The above-described embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application.

Claims

1. A method for monitoring the running status of a mini-program, characterized in that, include: When the launch of the mini-program to be monitored is detected, the launch phase of the mini-program is monitored; After the mini-program has completed the first loading stage in the startup phase, a preset startup phase monitoring logic is started to obtain startup error information and third-party service call feedback information of the mini-program. Based on the startup error information, the error events of the mini-program are located to obtain error location information. Based on the third-party service call feedback information, the call success rate of the third-party service request is calculated. Based on the error location information and the call success rate, the startup phase running status information of the mini-program is determined. Once the mini-program is launched, a preset page monitoring logic is initiated to obtain the page rendering information of the mini-program, and the running status information of the page loading stage of the mini-program is determined based on the page rendering information. The running status of the mini-program is determined based on the running status information of the startup phase and the running status information of the page loading phase.

2. The method for monitoring the running status of a mini-program according to claim 1, characterized in that, The startup error information specifically includes: error text, error line number, error time, user's device model and network where the mini-program is running.

3. The method for monitoring the running status of a mini-program according to claim 1, characterized in that, The feedback information from the third-party service call specifically includes: the input parameters, path, user device type, user network, and request status of the third-party service interface request.

4. The method for monitoring the running status of a mini-program according to claim 3, characterized in that, The step of calculating the success rate of third-party service requests based on the feedback information from the third-party service invocation specifically includes: Based on the input parameters, path, and user device type of the third-party service interface request, the requests are classified according to the request objects corresponding to each third-party service interface request. Then, based on the user network and request status of the same request object, the success rate of calling all interface services under the request object is calculated.

5. The method for monitoring the running status of a mini-program according to claim 1, characterized in that, The page rendering information specifically includes: page information and page rendering time.

6. The method for monitoring the running status of a mini-program according to claim 5, characterized in that, The step of determining the running status information of the mini-program during the page loading stage based on the page rendering information specifically includes: Based on the page rendering time corresponding to the page information, the page rendering time is compared with a preset rendering time threshold to determine the running status information of the page loading stage of the mini program based on the comparison result.

7. A device for monitoring the running status of a mini-program, characterized in that, include: The mini-program startup detection unit is used to monitor the startup phase of the mini-program when it is detected that the mini-program to be monitored has started. The startup phase monitoring trigger unit is used to activate a preset startup phase monitoring logic after the mini-program has executed the first loading phase in the startup phase, to obtain startup error information and third-party service call feedback information of the mini-program, and to locate the error event of the mini-program based on the startup error information to obtain error location information. Based on the third-party service call feedback information, the unit calculates the call success rate of the third-party service request, and determines the startup phase running status information of the mini-program based on the error location information and the call success rate. The page loading phase monitoring trigger unit is used to start a preset page monitoring logic after the mini program is launched, so as to obtain the page rendering information of the mini program and determine the running status information of the page loading phase of the mini program based on the page rendering information. The mini-program running status determination unit is used to determine the running status of the mini-program based on the running status information of the startup phase and the running status information of the page loading phase.

8. A terminal for monitoring the running status of a mini-program, characterized in that, include: Memory and processor; The memory is used to store program code, which corresponds to a method for monitoring the running status of a mini-program as described in any one of claims 1 to 6; The processor is used to execute the program code.

9. A computer-readable storage medium, characterized in that, The computer-readable storage medium contains program code, which corresponds to a method for monitoring the running status of a mini-program as described in any one of claims 1 to 6.

Images