CN117632746A - Pile inserting processing method and device, storage medium and electronic equipment - Google Patents

Abstract

Embodiments of the present application disclose an instrumentation processing method, device, storage medium and electronic equipment. The method includes: compiling an intermediate bytecode file corresponding to a program source code file, and determining hot code monitoring instrumentation logic for the program source code file. , based on the preset instrumentation module, use the bytecode operation tool to add hot code monitoring instrumentation logic to the intermediate bytecode file, obtain the target intermediate bytecode file, run the target intermediate bytecode file, and obtain the hot code monitoring instrumentation logic. The corresponding hotspot code execution record file.

Description

A staking processing method, device, storage medium and electronic equipment

Technical field

The present application relates to the field of computer technology, and in particular to an instrumentation processing method, device, storage medium and electronic equipment.

Background technique

With the rapid development of computer technology, terminals such as mobile phones and tablet computers have gained rapid popularity. For terminal systems, system hot code statistics are often involved. System hot code statistics usually refer to the application programs of the terminal system. Analysis and statistics of key codes are performed to understand the execution frequency of the code, the calling of hot functions or methods, etc. System hot code statistics can help developers optimize performance, improve security, improve user experience, and provide data support for product improvement and Code maintenance, which in turn improves application quality, reliability, and user satisfaction.

Contents of the invention

Embodiments of the present application provide a staking processing method, device, storage medium and electronic equipment. The technical solution is as follows:

In a first aspect, embodiments of the present application provide a staking processing method, which method includes:

Compile the intermediate bytecode file corresponding to the program source code file, and determine the hot code monitoring instrumentation logic for the program source code file;

Use a bytecode operation tool to add the hotspot code monitoring instrumentation logic to the intermediate bytecode file based on the preset instrumentation module to obtain the target intermediate bytecode file;

Run the target intermediate bytecode file to obtain the hotspot code execution record file corresponding to the hotspot code monitoring instrumentation logic.

In a second aspect, embodiments of the present application provide a staking processing device, which includes:

The compilation module is used to compile the intermediate bytecode file corresponding to the program source code file, and determine the hot code monitoring instrumentation logic for the program source code file;

An instrumentation module, configured to use a bytecode operation tool to add the hotspot code monitoring instrumentation logic to the intermediate bytecode file based on the preset instrumentation module to obtain the target intermediate bytecode file;

An operation module is used to run the target intermediate bytecode file and obtain the hotspot code execution record file corresponding to the hotspot code monitoring instrumentation logic.

In a third aspect, embodiments of the present application provide a computer storage medium that stores multiple instructions, and the instructions are suitable for being loaded by a processor and executing the above method steps.

In a fourth aspect, embodiments of the present application provide an electronic device, which may include: a processor and a memory; wherein the memory stores a computer program, and the computer program is adapted to be loaded by the processor and execute the above method steps. .

The beneficial effects brought by the technical solutions provided by some embodiments of this application include at least:

In one or more embodiments of the present application, the terminal compiles the intermediate bytecode file corresponding to the program source code file, and determines the hotspot code monitoring instrumentation logic for the program source code file, in order to implement non-intrusive hotspots based on bytecode operating tools. Code method call monitoring and call statistics are pre-configured with a preset instrumentation module. Based on the preset instrumentation module, bytecode operation tools are used to add hot code monitoring and instrumentation logic to the intermediate bytecode file to obtain the target intermediate bytecode file. Modify the intermediate bytecode file instead of directly modifying the program source code file, and then run the target intermediate bytecode file to obtain the hotspot code execution record file corresponding to the hotspot code monitoring instrumentation logic, thus achieving non-intrusion of the program source code. Compared with intrusive code instrumentation solutions, this method improves the automation of instrumentation, reduces labor costs, reduces the impact of instrumentation on source code performance, and makes the many sub-modules included in the terminal system during the instrumentation process More convenient and efficient.

Description of drawings

In order to explain the embodiments of the present application or the technical solutions in the prior art more clearly, the drawings needed to be used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings in the following description are only These are some embodiments of the present application. For those of ordinary skill in the art, other drawings can be obtained based on these drawings without exerting creative efforts.

Figure 1 is a schematic flow chart of a staking processing method provided by an embodiment of the present application;

Figure 2 is a schematic diagram of a source code compilation scenario provided by an embodiment of the present application;

Figure 3 is a schematic diagram of a source code instrumentation monitoring scenario provided by an embodiment of the present application;

Figure 4 is a schematic flowchart of another embodiment of a staking processing method provided by the embodiment of the present application;

Figure 5 is a schematic diagram of a preset instrumentation module provided by an embodiment of the present application;

Figure 6 is a schematic diagram of a preset instrumentation module provided by an embodiment of the present application;

Figure 7 is a schematic diagram of a hotspot code call count record provided by an embodiment of the present application;

Figure 8 is a schematic diagram of a pile insertion processing device provided by an embodiment of the present application;

Figure 9 is a schematic structural diagram of an electronic device provided by an embodiment of the present application;

Figure 10 is a schematic structural diagram of the operating system and user space provided by the embodiment of the present application;

Figure 11 is the architecture diagram of the Android operating system in Figure 10;

Figure 12 is an architectural diagram of the IOS operating system in Figure 10.

Detailed ways

The technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings in the embodiments of the present application. Obviously, the described embodiments are only some of the embodiments of the present application, rather than all of the embodiments. Based on the embodiments in this application, all other embodiments obtained by those of ordinary skill in the art without creative efforts fall within the scope of protection of this application.

In the description of the present application, it should be understood that the terms "first", "second", etc. are used for descriptive purposes only and shall not be understood as indicating or implying relative importance. In the description of this application, it should be noted that, unless otherwise expressly stated and limited, "including" and "having" and any variations thereof are intended to cover non-exclusive inclusion. For example, a process, method, system, product or device that includes a series of steps or units is not limited to the listed steps or units, but optionally also includes steps or units that are not listed, or optionally also includes Other steps or units inherent to such processes, methods, products or devices. For those of ordinary skill in the art, the specific meanings of the above terms in this application can be understood on a case-by-case basis. Furthermore, in the description of this application, "plurality" means two or more unless otherwise specified. "And/or" describes the relationship between related objects, indicating that there can be three relationships. For example, A and/or B can mean: A exists alone, A and B exist simultaneously, and B exists alone. The character "/" generally indicates that the related objects are in an "or" relationship.

In related technologies, the hot code statistics or hot code analysis of the terminal's operating system (which can be referred to as the terminal system) is to add burying logic, data recording logic, and export related logic to the program source code of the system's relevant modules through manual or automated methods. The hot code monitoring logic generates new program source code, and then the new program source code is recompiled to generate a new program. Finally, the modified program is executed to implement statistics of hot code calls.

Then, on the one hand, terminal system-related modules have a large number of code warehouses, and modifying the hot code warehouse source code requires a huge workload and is inefficient; on the other hand, adding hot code monitoring logic to the program source code is an intrusive code instrumentation , which may change the execution logic of the original system module, which may lead to reduced program execution performance, program crash, etc.;

It can be seen that hot code call monitoring in related technologies has certain limitations.

The present application will be described in detail below with reference to specific embodiments.

In one embodiment, as shown in FIG. 1 , an instrumentation processing method is proposed, which can be implemented by relying on a computer program and can run on an instrumentation processing device based on the von Neumann system. The computer program can be integrated into an application or run as a stand-alone utility application. The instrumentation processing device may be a terminal device, including but not limited to: a personal computer, a tablet computer, a handheld device, a vehicle-mounted device, a wearable device, a computing device or other processing devices connected to a wireless modem. Terminal equipment can be called different names in different networks, such as: user equipment, access terminal, user unit, user station, mobile station, mobile station, remote station, remote terminal, mobile device, user terminal, terminal, wireless communication Equipment, user agent or user device, cellular phone, cordless phone, terminal equipment in 5G network or future evolution network, etc.

Specifically, the instrumentation processing method includes:

S102: Compile the intermediate bytecode file corresponding to the program source code file, and determine the hot code monitoring instrumentation logic for the program source code file;

Program source code files can be understood as the program source codes of the development end in the code writing stage, code debugging stage, code maintenance stage, etc. Source code files encoded in different machine programmable languages can be called different language program source code files;

For example, as shown in Figure 2, Figure 2 is a schematic diagram of a source code compilation scenario. The machine programmable language can be the Java language, and the program source code file can be called a Java program source code file (Java source code for short); for example, the Java source code is compiled and converted into a class file (that is, an intermediate file) through javac (Java compiler front-end). Bytecode file), the file content of class is Java bytecode.

In practical applications, for terminal systems, system hot code statistics are often involved. System hot code statistics usually refer to the analysis and statistics of key codes in terminal system applications to understand the execution frequency and hot spots of the code. In order to avoid limitations caused by intrusive modifications, such as the calling of functions or methods, the instrumentation processing method of one or more embodiments of this specification can be implemented to implement non-intrusive hot code method invocation based on bytecode operating tools. Monitoring and call statistics.

Compile the intermediate bytecode file corresponding to the program source code file. First, the source code is converted into bytecode that can be recognized by the machine programmable language virtual machine (such as Java virtual machine). These bytecodes can be called intermediate bytecode files. .

Based on actual needs, it is determined that what needs attention is to inject those code segments that may have performance problems and are frequently called. These code segments are hot code, and the hot code monitoring instrumentation logic is: terminal users (such as developers, testers, Maintenance personnel, etc.) determine the hot code monitoring instrumentation logic (which can also be called hot code call instrumentation logic) based on the goal of hot code call monitoring in the source code, in order to collect relevant program behavior or performance when the hot code to be monitored is executed. Information.

Specifically, various tools and technologies can be used in advance to determine the hot code to be monitored in the program source code file. After determining the hot code in the program source code file, non-intrusive instrumentation logic can be used to generate hot code monitoring instrumentation. Logic, based on hot code monitoring instrumentation logic to monitor the execution and calling of hot code.

In a feasible implementation, the terminal can obtain the hot code monitoring method input by users (such as developers, testers, maintainers, etc.) for the program source code file. The hot code monitoring method includes method call count records, method At least one of input and output parameters records, method call chain records, method call time-consuming records, method parameter transfer records, method rewrite records, and method function expansion records, and then generate hot code monitoring instrumentation logic based on the hot code monitoring method. .

Using the user input hotspot code monitoring method, you can then use the bytecode operation tool in conjunction with the preset instrumentation module to add user-defined hotspot code monitoring instrumentation logic to the intermediate bytecode file.

One way can be: the hot code monitoring method input by users (such as developers, testers, maintainers, etc.) for the program source code file, and the user customizes the coding hot code monitoring instrumentation logic, and the hot code monitoring instrumentation logic is based on For the formal representation of code data, the terminal only needs to receive the hotspot code monitoring instrumentation logic input by the user;

One way can be: the template mapping relationship between the hot code monitoring type and the instrumentation logic automatically generated template is predefined, and the user only needs to enter the hot code monitoring method, and the data corresponding to the hot code monitoring method carries the hot code monitoring configuration. , hotspot code monitoring configuration includes hotspot code, hotspot code monitoring parameters, hotspot code monitoring type (such as call count record type, method input and output parameter type), etc., based on template mapping relationship, based on hotspot code monitoring type can be from the template mapping relationship Query the target instrumentation logic corresponding to the current hot code monitoring type to automatically generate a template, and then use the target instrumentation logic to automatically generate the template combined with the hot code, hot code monitoring parameters, and hot code monitoring type carried by the hot code monitoring method input by the user. Wait for the data to automatically generate hotspot code monitoring instrumentation logic.

S104: Use a bytecode operation tool to add the hotspot code monitoring instrumentation logic to the intermediate bytecode file based on the preset instrumentation module to obtain the target intermediate bytecode file;

In order to achieve non-intrusive hot code method call monitoring and call statistics based on bytecode operating tools, a preset instrumentation module is pre-configured. For example, the preset instrumentation module is integrated into the compilation intermediate product - the modification of the intermediate bytecode file. In this step, the intermediate bytecode file is modified instead of directly modifying the program source code file (Java source file), realizing non-intrusive instrumentation of the program source code. Compared with existing intrusive code instrumentation solutions, it improves the automation of instrumentation, reduces labor costs, reduces the impact of instrumentation on source code performance, and makes the numerous sub-modules included in the terminal system during the instrumentation process more efficient. Convenient and efficient.

Bytecode operation tools refer to tool programs used to perform related operations on intermediate bytecode files;

Optionally, the bytecode operation tool can be the ASM class library, which is a library for operating Java bytecode. In this manual, based on the preset instrumentation module, the bytecode manipulation tool-ASM class library can be used to read, modify and generate the bytecode of Java classes, and inject point code monitoring instrumentation logic into the intermediate bytecode file. . Through ASM, intermediate bytecode files can be manipulated programmatically to perform various bytecode-level operations, such as method insertion, modification, and deletion. This class library provides a rich API interface. In this manual, the Java bytecode in the intermediate bytecode file can be easily processed using bytecode manipulation tools based on the preset instrumentation module.

Specifically, based on the instrumentation module, bytecode operation tools such as ASM class libraries are used to add customized hotspot code monitoring instrumentation logic to the intermediate bytecode file (Class file), obtain the target intermediate bytecode file, and insert the hotspot code Monitoring instrumentation logic can include method call count recording logic, method input and output parameter recording logic, method call chain recording logic, method call time-consuming recording logic, method parameter passing recording logic, method rewriting recording logic, and method function expansion recording logic. At least one of logic and other logics;

S106: Run the target intermediate bytecode file and obtain the hotspot code execution record file corresponding to the hotspot code monitoring instrumentation logic.

Specifically, the instrumented target intermediate bytecode file is configured into the terminal system, and the terminal runs the target intermediate bytecode file. Based on the target intermediate bytecode file, the functions of the relevant modules of the terminal system are triggered to execute the relevant program code. , during this process the hotspot code will be executed. At the same time, during the execution of the hotspot code, the hotspot code monitoring instrumentation logic based on the aforementioned instrumentation will automatically record the execution of the relevant hotspot code, such as the record of the number of method calls and the method input parameters. Parameter records, method call chain records, method call time-consuming records, method parameter transfer records, method rewrite records, method function extension records, etc.; when the source program corresponding to the target intermediate bytecode file ends running, through the hotspot code The monitoring instrumentation logic will export the call records of hot code into a binary file. This binary file is also the hot code execution record file in this manual. The exported hot code execution record file can contain the number of method calls according to the hot code monitoring instrumentation logic. , execution time, input parameters, output parameters, and dynamic call chain and other preset monitoring information.

For example, as shown in Figure 3, Figure 3 is a schematic diagram of a source code instrumentation monitoring scenario. The machine programmable language can be the Java language, and the program source code file can be called a Java program source code file (Java source code for short); for example, the Java source code is compiled and converted into a class file (that is, an intermediate file) through javac (Java compiler front-end). Bytecode file), the file content of class is Java bytecode. Then use the preset instrumentation module to use the bytecode operation tool to add the hotspot code monitoring instrumentation logic to the intermediate bytecode file, and obtain the class file after instrumentation - the target intermediate bytecode file. Further, In one or more embodiments of this specification, it is preset that the instrumentation module supports "on-the-fly" real-time instrumentation and "offline" offline instrumentation functions, and then runs the class file - the target intermediate bytecode file, based on the hotspot code By monitoring the instrumentation logic and exporting data during the running of hot code, the corresponding hot code execution record file can be obtained. Subsequently, the hot code execution record file can be further analyzed based on actual needs.

In one or more embodiments of this specification, the terminal compiles the intermediate bytecode file corresponding to the program source code file, and determines the hotspot code monitoring instrumentation logic for the program source code file, in order to implement non-intrusive hotspots based on bytecode operation tools. Code method call monitoring and call statistics are pre-configured with a preset instrumentation module. Based on the preset instrumentation module, bytecode operation tools are used to add hot code monitoring and instrumentation logic to the intermediate bytecode file to obtain the target intermediate bytecode file. Modify the intermediate bytecode file instead of directly modifying the program source code file, and then run the target intermediate bytecode file to obtain the hotspot code execution record file corresponding to the hotspot code monitoring instrumentation logic, thus achieving non-intrusion of the program source code. Compared with intrusive code instrumentation solutions, this method improves the automation of instrumentation, reduces labor costs, reduces the impact of instrumentation on source code performance, and makes the many sub-modules included in the terminal system during the instrumentation process More convenient and efficient.

Please refer to Figure 4, which is a schematic flow chart of another embodiment of a staking processing method proposed in this application. specific:

S202: Compile the intermediate bytecode file corresponding to the program source code file, and determine the hot code monitoring instrumentation logic for the program source code file;

Specifically, the terminal compiles the intermediate bytecode file corresponding to the program source code file. After determining the hot code monitoring instrumentation logic for the program source code file, the terminal executes the bytecode operation tool based on the preset instrumentation module to analyze the intermediate bytecode file. Add the hotspot code monitoring instrumentation logic to the bytecode file to obtain the target intermediate bytecode file;

Further, the terminal executes a bytecode operation tool based on the preset instrumentation module to add the hotspot code monitoring instrumentation logic to the intermediate bytecode file to obtain the target intermediate bytecode file, as follows:

The preset instrumentation module can support real-time instrumentation function and offline instrumentation function. The real-time instrumentation function can be suitable for fast and instant small-scale program instrumentation, and the offline instrumentation function can be suitable for large-scale system-level instrumentation. Based on different needs, the hot code monitoring instrumentation logic can be added to the type of intermediate bytecode file based on the relevant instrumentation function to obtain the target intermediate bytecode file;

After the terminal determines the hot code monitoring instrumentation logic for the program source code file, it first determines that the instrumentation method for the hot code monitoring instrumentation logic is a real-time instrumentation type or an offline instrumentation type;

Optionally, determine that the instrumentation method for hot code monitoring instrumentation logic is a real-time instrumentation type, the terminal uses a bytecode operation tool to run the intermediate bytecode file online, and uses the preset instrumentation module as a program agent The device uses a preset instrumentation module to read the bytecode class files in the intermediate bytecode file based on the bytecode operation tool, and adds hot code monitoring instrumentation logic generation targets to the bytecode class files. Bytecode file, perform writeback processing on the intermediate bytecode file for the target bytecode file to obtain the target intermediate bytecode file;

For example, the on-the-fly real-time instrumentation function of the preset instrumentation module is used, and the preset instrumentation module is used as a program agent (JavaAgent), and the premain method is implemented in it. In Java, a JavaAgent is a program agent that integrates with a target Java application to modify or enhance its behavior. This is achieved through Java's Instrumentation API interface. The premain method is a special entry point of the program agent JavaAgent. The premain method is executed before the main method of the target application (can be regarded as before the source program code is executed).

Further, in the premain method, the bytecode operation tool (such as ASM or other bytecode operation library) is used through the preset instrumentation module to read the bytecode class file in the intermediate bytecode file. You can use Go to the bytecode operation tool to modify or rewrite the bytecode of the target class corresponding to the "hot code monitoring instrumentation logic", complete adding the hot code monitoring instrumentation logic to the bytecode class file to generate the target bytecode class file, and then write back the target bytecode class file to the intermediate bytecode file to obtain the target intermediate bytecode file;

Subsequently, at runtime, the JavaAgent can be loaded through the Java command line, ensuring that the premain method that adds hot code monitoring instrumentation logic is executed before the main method of the application, thereby achieving real-time instrumentation. By using the premain method of JavaAgent, bytecode enhancement is performed on the specified method during the class loading process. By modifying the Java compilation intermediate product, that is, the bytecode, during the class loading process, non-intrusive function addition without modifying the source code can be achieved, which is suitable for fast and instant small-scale program instrumentation.

The on-the-fly real-time instrumentation function supported by the default instrumentation module allows the instrumentation module to be used as a program agent (such as Java Agent) to count the number of hot code calls during local debugging during the program development stage, on-the- fly's real-time instrumentation function is more flexible and faster.

Optionally, determine the instrumentation method for the hot code monitoring instrumentation logic as an offline instrumentation type, use a bytecode operation tool to run the intermediate bytecode file offline, and use the intermediate bytecode file as a bytecode. To save code, a preset instrumentation module is used to read the bytecode class files in the intermediate bytecode file based on the bytecode operation tool and the file input stream method, and add hot code to the bytecode class files. The instrumentation logic is monitored to generate a target bytecode class file, and the intermediate bytecode file is written back to the target bytecode class file based on the file output stream mode to obtain the target intermediate bytecode file.

Specifically, in software development, especially in large-scale terminal systems such as Android systems, tracking, analysis, and optimization of hot code are crucial. In order to achieve the purpose of hot code monitoring, users often need to use instrumentation technology to collect code execution information. For large-scale system-level instrumentation, the default instrumentation module provides offline instrumentation function, that is, offline instrumentation function.

For example, after the javac compiler source code file generates the intermediate bytecode file -class file, use the bytecode operation tool to run the intermediate bytecode file offline, regard the intermediate bytecode file as bytecode, and use the default The instrumentation module reads the bytecode class files in the intermediate bytecode file based on the bytecode operation tool and the file input stream method, that is, using the file input stream to read the generated intermediate bytecode file, and These intermediate bytecode files are converted into bytecode form and passed to the CustomTransformer component using the preset instrumentation module. The function of the CustomTransformer component is to modify or enhance these bytecodes according to specific requirements or rules. The process of modifying or enhancing these bytecodes realizes adding hot code monitoring and instrumentation logic to the bytecode class files to generate target bytecode class files. This modification or enhancement may be based on the insertion of hot code monitoring and instrumentation logic. Performance timers, logging statements or any other type of code, CustomTransformer completes the modification or enhancement of the bytecode (that is, the bytecode class file) to generate the target bytecode class file, and the custom instrumented bytes The code (that is, the target bytecode class file) will be written back to the original intermediate bytecode file through the file output stream, replacing the old bytecode. In this way, non-intrusive offline custom instrumentation is achieved, where the source code files remain unchanged and the bytecodes in the intermediate bytecode files have been modified and enhanced to generate the target intermediate bytecode files.

The default instrumentation module provides offline instrumentation functionality and is suitable for large-scale system-level instrumentation. In the development of terminal systems, due to the complexity of the system and the large amount of code, effective instrumentation of each sub-module of the system can be achieved by executing the method of one or more embodiments of this specification. The preset instrumentation module provides offline instrumentation function to achieve high-efficiency hot code call monitoring by processing the bytecode of the entire system at one time.

Under subsequent processing, instrumentation compilation macros can be turned on during the compilation phase of the system. This means that during the process of compiling the code into bytecode, the target intermediate bytecode file has been integrated with the instrumentation logic. Therefore, the compiled final product target intermediate bytecode file (that is, the .class file) already contains the instrumentation code. In this way, when these instrumented hot code functions are used during execution, the system will automatically record the number of calls, execution time and other information of the hot code.

S204: Run the intermediate bytecode file;

S206: Use the preset instrumentation module to read the bytecode class files in the intermediate bytecode file based on the bytecode operation tool, and add hot code monitoring instrumentation logic generation targets to the bytecode class files. The bytecode class file performs writeback processing on the target bytecode class file on the intermediate bytecode file to obtain the target intermediate bytecode file.

In a feasible implementation, as shown in Figure 5, Figure 5 is a schematic diagram of a preset instrumentation module. The preset instrumentation module includes an instrumentation converter, a class reader, a class modifier, and a class writer. inserter,

The instrumentation converter can be called Transformer (CustomTransformer). Transformer is associated with class readers, class modifiers, and class writers. Among them, the instrument method rewritten in CustomTransformer will read the bytecode in the class file. And return the bytecode after adding custom instrumentation code through the associated class writer.

The class reader can be called ClassReader; the class modifier can be called a custom ClassAdapter (or CustomClassAdapter). The class modifier rewrites the ClassVisitor method in the ASM class library; the class writer can be called ClassWriter. To write back the modified class file.

The following methods can be used for specific implementation:

A2: The terminal is based on the bytecode operation tool and controls the class reader to read the bytecode class files in the intermediate bytecode file through the instrumentation converter;

A4: Based on the bytecode operation tool, add hot code monitoring instrumentation logic to the bytecode class file through the instrumentation converter control class modifier to generate the target bytecode class file;

A6: Based on the bytecode operation tool, the instrumentation converter controls the class writer to write back the intermediate bytecode file against the target bytecode class file to obtain the target intermediate bytecode file.

Specifically, the terminal obtains the notification adapter class corresponding to the bytecode operation tool, obtains the entry method corresponding to the notification adapter class, and controls the class reader to intercept the bytecode class through the instrumentation converter. file, determine the target bytecode execution method based on the bytecode class file, and when the entry method is called, the hot code monitoring instrumentation logic is written into the target bytecode execution method to generate a file containing the target bytecode. The target bytecode class file for the section code execution method.

For example, as shown in Figure 6, Figure 6 is a schematic diagram of a scenario of instrumentation processing provided in this specification. The class file (that is, the bytecode class file) is intercepted through the class modifier CustomClassAdapter, and the modification logic is implemented by rewriting the visitMethod method of ClassVisitor (which can be understood as the visitor mode, relative to the class access object). The specific steps are: 1. Based on the bytecode operation tool, intercept the class file through the instrumentation converter control class modifier, and modify the corresponding bytecode class file (relative to the hotspot code) by overriding the visitMethod method (notifying the corresponding method of the adapter class) Corresponding bytecode class file) method logic is added (hot code) instrumentation logic (that is, the target bytecode class file is obtained after adding instrumentation logic). 2. Use the instrumentation converter to control the class writer to rewrite the onMethodEnter method of the AdviceAdapter class of the bytecode operation tool (such as the ASM class library) (which can be understood as the "when entering the method" method), and monitor the hot code instrumentation logic. (Record of the number of method calls, record of input and output parameters, and call chain record) Insert the corresponding method entry of the corresponding bytecode class file, complete the write-back processing of the intermediate bytecode file for the target bytecode class file, and obtain the target intermediate Bytecode file.

Exemplarily, as shown in Figure 7, Figure 7 is a schematic diagram of recording the number of calls to hot code methods; Figure 7 illustrates the detailed process of recording the number of execution calls of hot code methods based on hot code monitoring instrumentation logic. First, generate The unique ID of the hot code method (that is, the "Get method information to generate a unique ID" step in the figure), obtain the "bytecode class" and "input and output parameters" parameters of the hot code method, and then determine whether the hot code method can be inserted Stub (that is, insert hot code to monitor the stub logic),

If instrumentation is possible, the control class modifier adds hot code monitoring instrumentation logic to the bytecode class file. Specifically, the onMethodEnterDo method (that is, the method when entering the method) is used to implement the CustomData (stored in memory) each time the method is entered. The number of hotspot code method calls with the same ID in the method call record data structure) is increased by 1.

Optionally, whether the method entry of the hot code method can be instrumented can be determined by judging the conditions: the hot code method belongs to the "bridging method and the method automatically generated by the compiler" type; instrumentation is not performed;

S208: Run the target intermediate bytecode file, and record the hotspot code execution record file corresponding to the hotspot code monitoring instrumentation logic;

For details, please refer to the method steps in other embodiments of this specification, and they will not be described again here.

S210: Export the hotspot code execution record file through the file output stream through the data export module, and store the hotspot code execution record file in the device file system.

During the instrumentation process of the intermediate bytecode file-class file, the hotspot code monitoring instrumentation logic is configured with the call record data structure of the hotspot code. The call record data structure of the hotspot code will be inserted into the intermediate bytecode file-class file. . The call record contains two layers of data structures: The top level of the data structure is the mapping relationship between the hot code class file "the unique ID (ClassId) of the corresponding method of the hot code class and the custom data CustomData", where CustomData contains each inserted data in the hot code class. The corresponding relationship between the unique ID (MethodId) of the stub's hot code method and the class method execution record parameters (such as the number of executions, execution time, etc.). After the program is executed, all data is written into the hotspot code execution record file through the file output stream. The hotspot code execution record file is a binary file (such as a CustomEc file) and is stored in the terminal's device file system.

S212: Read the hotspot code execution record file through the data analysis module, perform graph analysis on the hotspot code execution record file, obtain a method call data list of the graph data type, and store the method call data list in the database.

The data parsing module is composed of FileReader. The main processing process of the data parsing module is: reading the hot code execution record file (binary file), and restoring the hot code execution record file to the Map data type (i.e. ClassId in the data export module) through the file input stream. corresponding relationship with CustomData), then intercept the (hot code) method call data contained in CustomData, and finally generate a method call data list and store it in the database.

The above method achieves non-intrusive hot code statistics through bytecode manipulation tools such as the ASM library, does not affect the logic and performance of the original program source code, provides a flexible instrumentation method, and supports large-scale system-level instrumentation .

In one or more embodiments of this specification, on-the-fly instrumentation and offline instrumentation are simultaneously implemented in the above manner, where on-the-fly allows users (such as developers) to use the default instrumentation module as a JavaAgent During local debugging during the program development phase, hot code calls can be counted. For developers, this instrumentation method is more flexible and faster. Offline instrumentation is suitable for large-scale instrumentation scenarios, such as instrumentation for each sub-module of the system. In this application scenario, you can turn on the instrumentation compilation macro when compiling the terminal system to implement large-scale code instrumentation, so that the compiled product contains the instrumentation code. When the instrumented code function is run during execution, information such as the number of calls to the hotspot code will be automatically recorded. And, compared with traditional intrusive code burying techniques, it is more scalable.

The staking processing device provided by the embodiment of the present application will be introduced in detail below with reference to FIG. 8 . It should be noted that the instrumentation processing device shown in Figure 8 is used to perform the methods of the embodiments shown in Figures 1 to 7 of the present application. For convenience of explanation, only the parts related to the embodiments of the present application are shown. Specifically, If the technical details are not disclosed, please refer to the embodiments shown in Figures 1 to 7 of this application.

Please refer to FIG. 8 , which shows a schematic structural diagram of a pile insertion processing device according to an embodiment of the present application. The instrumentation processing device 1 can be implemented as all or part of the user terminal through software, hardware, or a combination of both. According to some embodiments, the instrumentation processing device 1 includes a compilation module 11, an instrumentation module 12 and an execution module 13, specifically for:

The compilation module 11 is used to compile the intermediate bytecode file corresponding to the program source code file, and determine the hot code monitoring instrumentation logic for the program source code file;

The instrumentation module 12 is configured to use the bytecode operation tool to add the hotspot code monitoring instrumentation logic to the intermediate bytecode file based on the preset instrumentation module to obtain the target intermediate bytecode file;

Running module 13 is used to run the target intermediate bytecode file and obtain the hotspot code execution record file corresponding to the hotspot code monitoring instrumentation logic.

Optionally, as shown in Figure 6, the device 1 includes:

Optionally, the instrumentation module 12 is used for:

Use a bytecode manipulation tool to run the intermediate bytecode file;

A preset instrumentation module is used to read the bytecode class files in the intermediate bytecode file based on the bytecode operation tool, and the hotspot code is added to the bytecode class file to monitor the instrumentation logic to generate target bytes. code class file, perform writeback processing on the target bytecode class file on the intermediate bytecode file to obtain the target intermediate bytecode file.

Optionally, the preset instrumentation module includes an instrumentation converter, a class reader, a class modifier, and a class writer. The instrumentation module 12 is used for:

Control the class reader to read the bytecode class file in the intermediate bytecode file through the instrumentation converter based on the bytecode operation tool;

Based on the bytecode operation tool, the instrumentation converter controls the class modifier to add hot code to the bytecode class file and monitor the instrumentation logic to generate a target bytecode class file;

Based on the bytecode operation tool, the instrumentation converter controls the class writer to perform writeback processing on the intermediate bytecode file for the target bytecode class file to obtain the target intermediate byte code file.

Optionally, the instrumentation module 12 is used for:

Obtain the notification adapter class corresponding to the bytecode operation tool, and obtain the entry method method corresponding to the notification adapter class;

The class reader is controlled by the instrumentation converter to intercept the bytecode class file, the target bytecode execution method is determined based on the bytecode class file, and the hot code monitoring instrumentation is performed when the entry method is called. The logic is written into the target bytecode execution method, and a target bytecode class file containing the target bytecode execution method is generated.

Optionally, the instrumentation module 12 is used to: determine that the instrumentation method for monitoring the instrumentation logic for the hotspot code is a real-time instrumentation type, and use a bytecode operation tool to run the intermediate bytecode file online, The preset instrumentation module is used as a program agent, and the preset instrumentation module is used to read the bytecode class files in the intermediate bytecode file based on the bytecode operation tool, and then Add hot code monitoring and instrumentation logic to the class file to generate a target bytecode class file, perform writeback processing on the intermediate bytecode file for the target bytecode class file, and obtain the target intermediate bytecode file;

Determine that the instrumentation method for the hot code monitoring instrumentation logic is the offline instrumentation type, use the bytecode operation tool to run the intermediate bytecode file offline, use the intermediate bytecode file as bytecode, and use The preset instrumentation module reads the bytecode class files in the intermediate bytecode file based on the bytecode operation tool and the file input stream method, and adds hot code monitoring instrumentation logic to the bytecode class files. Generate a target bytecode class file, and perform writeback processing on the target bytecode class file based on the file output stream mode to obtain the target intermediate bytecode file.

Optionally, the compilation module 11 is used for:

Obtain the hot code monitoring method input for the program source code file. The hot code monitoring method includes method call number records, method input and output parameter records, method call chain records, method call time-consuming records, method parameter transfer records, At least one of method rewriting records and method function extension records;

Hotspot code monitoring instrumentation logic is generated based on the hotspot code monitoring method.

Optional, the running module is used for:

Run the target intermediate bytecode file and record the hotspot code execution record file corresponding to the hotspot code monitoring instrumentation logic;

The hot code execution record file is exported through the file output stream through the data export module, and the hot code execution record file is stored in the device file system.

Optional, the device 1:

The hotspot code execution record file is read through the data analysis module, and graph analysis is performed on the hotspot code execution record file to obtain a method call data list of the graph data type, and the method call data list is stored in the database.

It should be noted that when the instrumentation processing device provided in the above embodiments performs the instrumentation processing method, only the division of the above functional modules is used as an example. In practical applications, the above functions can be allocated to different functions as needed. Module completion means dividing the internal structure of the device into different functional modules to complete all or part of the functions described above. In addition, the instrumentation processing device and the instrumentation processing method embodiment provided in the above embodiments belong to the same concept. For details of the implementation process, please refer to the method embodiment, which will not be described again here.

The above serial numbers of the embodiments of the present application are only for description and do not represent the advantages and disadvantages of the embodiments.

Embodiments of the present application also provide a computer storage medium. The computer storage medium can store multiple instructions. The instructions are suitable to be loaded and executed by the processor as described in the embodiments shown in Figures 1 to 7. For the specific execution process of the instrumentation processing method, please refer to the specific description of the embodiment shown in Figures 1 to 7, and will not be described in detail here.

This application also provides a computer program product, which stores at least one instruction. The at least one instruction is loaded by the processor and executes the instrumentation as shown in the above embodiments shown in Figures 1 to 7. For the processing method and specific execution process, please refer to the specific description of the embodiment shown in Figures 1 to 7, and will not be described again here.

Please refer to FIG. 9 , which shows a structural block diagram of an electronic device provided by an exemplary embodiment of the present application. The electronic device in this application may include one or more of the following components: a processor 110, a memory 120, an input device 130, an output device 140, and a bus 150. The processor 110, the memory 120, the input device 130 and the output device 140 may be connected through a bus 150.

Processor 110 may include one or more processing cores. The processor 110 uses various interfaces and lines to connect various parts of the entire electronic device, and executes electronic devices by running or executing instructions, programs, code sets or instruction sets stored in the memory 120, and calling data stored in the memory 120. Various functions and processing data of device 100. Optionally, the processor 110 may adopt at least one of digital signal processing (DSP), field-programmable gate array (FPGA), and programmable logic array (PLA). implemented in hardware form. The processor 110 may integrate one or a combination of a central processing unit (CPU), a graphics processing unit (GPU), a modem, and the like. Among them, the CPU mainly handles the operating system, user interface, and applications; the GPU is responsible for rendering and drawing the display content; and the modem is used to handle wireless communications. It can be understood that the above-mentioned modem may not be integrated into the processor 110 and may be implemented solely through a communication chip.

The memory 120 may include random access memory (RAM) or read-only memory (ROM). Optionally, the memory 120 includes non-transitory computer-readable storage medium. Memory 120 may be used to store instructions, programs, codes, sets of codes, or sets of instructions. The memory 120 may include a program storage area and a data storage area, where the program storage area may store instructions for implementing an operating system and instructions for implementing at least one function (such as a touch function, a sound playback function, an image playback function, etc.) , instructions for implementing each of the following method embodiments, etc., the operating system can be an Android system, including a system developed in depth based on the Android system, an IOS system developed by Apple, including a system developed in depth based on the IOS system, or Other systems. The storage data area can also store data created during use of the electronic device, such as phone books, audio and video data, chat record data, etc.

As shown in FIG. 10 , the memory 120 can be divided into operating system space and user space. The operating system runs in the operating system space, and native and third-party applications run in the user space. In order to ensure that different third-party applications can achieve better operating results, the operating system allocates corresponding system resources to different third-party applications. However, different application scenarios in the same third-party application also have different requirements for system resources. For example, in the local resource loading scenario, the third-party application has higher requirements for disk reading speed; in the animation rendering scenario, the Third-party applications have higher requirements for GPU performance. The operating system and third-party applications are independent of each other, and the operating system is often unable to detect the current application scenarios of third-party applications in a timely manner, resulting in the operating system being unable to perform targeted system resource adaptation according to the specific application scenarios of third-party applications.

In order for the operating system to distinguish the specific application scenarios of third-party applications, it is necessary to open up data communication between the third-party applications and the operating system, so that the operating system can obtain the current scenario information of the third-party applications at any time, and then perform operations based on the current scenario. Targeted system resource adaptation.

Taking the operating system as an Android system as an example, the programs and data stored in the memory 120 are shown in Figure 11. The memory 120 can store a Linux kernel layer 320, a system runtime library layer 340, an application framework layer 360 and an application layer 380. Among them, the Linux kernel layer 320, the system runtime layer 340 and the application framework layer 360 belong to the operating system space, and the application layer 380 belongs to the user space. The Linux kernel layer 320 provides underlying drivers for various hardware of electronic devices, such as display drivers, audio drivers, camera drivers, Bluetooth drivers, Wi-Fi drivers, power management, etc. The system runtime library layer 340 provides main feature support for the Android system through some C/C++ libraries. For example, the SQLite library provides database support, the OpenGL/ES library provides 3D drawing support, and the Webkit library provides browser kernel support, etc. The system runtime library layer 340 also provides an Android runtime library (Android runtime), which mainly provides some core libraries and allows developers to write Android applications using Java language. The application framework layer 360 provides various APIs that may be used when building applications. Developers can also use these APIs to build their own applications, such as activity management, window management, view management, notification management, content providers, Package management, call management, resource management, positioning management. At least one application program runs in the application layer 380. These applications can be native applications that come with the operating system, such as contact programs, SMS programs, clock programs, camera applications, etc.; they can also be developed by third-party developers. Third-party applications, such as game applications, instant messaging programs, photo beautification programs, etc.

Taking the operating system as an IOS system as an example, the programs and data stored in the memory 120 are shown in Figure 11. The IOS system includes: a core operating system layer 420 (Core OS layer), a core service layer 440 (Core Services layer), and a media layer. 460 (Media layer), touchable layer 480 (Cocoa Touch Layer). The core operating system layer 420 includes the operating system kernel, drivers and underlying program frameworks. These underlying program frameworks provide functions closer to hardware for use by the program framework located in the core service layer 440 . The core service layer 440 provides system services and/or program frameworks required by applications, such as foundation framework, account framework, advertising framework, data storage framework, network connection framework, geographical location framework, sports framework, etc. The media layer 460 provides audio-visual interfaces for applications, such as interfaces related to graphics and images, interfaces related to audio technology, interfaces related to video technology, wireless playback (AirPlay) interfaces of audio and video transmission technology, etc. The touchable layer 480 provides various commonly used interface-related frameworks for application development. The touchable layer 480 is responsible for the user's touch interaction operations on the electronic device. For example, local notification service, remote push service, advertising framework, game tool framework, message user interface interface (User Interface, UI) framework, user interface UIKit framework, map framework, etc.

In the framework shown in FIG. 12 , frameworks related to most applications include but are not limited to: the basic framework in the core service layer 440 and the UIKit framework in the touchable layer 480 . The basic framework provides many basic object classes and data types, providing the most basic system services for all applications, regardless of the UI. The classes provided by the UIKit framework are basic UI class libraries, used to create touch-based user interfaces. iOS applications can provide UI based on the UIKit framework, so it provides the application infrastructure for building user interfaces, drawing , handle user interaction events, respond to gestures, etc.

Among them, the method and principle of realizing data communication between third-party applications and the operating system in the IOS system can be referred to the Android system, which will not be described in detail here in this application.

The input device 130 is used to receive input instructions or data, and the input device 130 includes but is not limited to a keyboard, a mouse, a camera, a microphone, or a touch device. The output device 140 is used to output instructions or data, and the output device 140 includes but is not limited to a display device and a speaker. In one example, the input device 130 and the output device 140 may be co-located. The input device 130 and the output device 140 may be a touch display screen. The touch display screen is used to receive the user's movement of a finger, a touch pen, or any other suitable object on the display screen or the display screen. Nearby touch operations, as well as displaying the user interface of individual applications. Touch display screens are usually provided on the front panels of electronic devices. Touch display screens can be designed as full screens, curved screens or special-shaped screens. The touch display screen can also be designed as a combination of a full screen and a curved screen, or a combination of a special-shaped screen and a curved screen, which are not limited in the embodiments of the present application.

In addition, those skilled in the art can understand that the structure of the electronic device shown in the above drawings does not constitute a limitation on the electronic device. The electronic device may include more or fewer components than those shown in the figures, or a combination of certain components. components, or different component arrangements. For example, electronic equipment also includes radio frequency circuits, input units, sensors, audio circuits, wireless fidelity (WiFi) modules, power supplies, Bluetooth modules and other components, which will not be described again here.

In the embodiment of the present application, the execution subject of each step may be the electronic device introduced above. Optionally, the execution subject of each step is the operating system of the electronic device. The operating system may be an Android system, an IOS system, or other operating systems, which are not limited in the embodiments of this application.

The electronic device in the embodiment of the present application can also be equipped with a display device. The display device can be a variety of devices that can realize display functions, such as: cathode ray tube display (cathode ray tube display, CR for short), light emitting diode display (light emitting diode display) -emitting diode display (LED), electronic ink screen, liquid crystal display (LCD), plasma display panel (PDP), etc. The user can use the display device on the electronic device 101 to view displayed text, images, videos and other information. The electronic device may be a smartphone, a tablet computer, a game device, an AR (Augmented Reality, augmented reality) device, a car, a data storage device, an audio playback device, a video playback device, a notebook, a desktop computing device, a wearable device such as an electronic device. Watches, electronic glasses, electronic helmets, electronic bracelets, electronic necklaces, electronic clothing and other equipment.

In the electronic device shown in FIG. 9 , where the electronic device may be a terminal, the processor 110 may be used to call the application program stored in the memory 120 and specifically perform the following operations:

Compile the intermediate bytecode file corresponding to the program source code file, and determine the hot code monitoring instrumentation logic for the program source code file;

Use a bytecode operation tool to add the hotspot code monitoring instrumentation logic to the intermediate bytecode file based on the preset instrumentation module to obtain the target intermediate bytecode file;

Run the target intermediate bytecode file to obtain the hotspot code execution record file corresponding to the hotspot code monitoring instrumentation logic.

In one embodiment, the processor 110 uses a bytecode operation tool to add the hotspot code monitoring instrumentation logic to the intermediate bytecode file based on the preset instrumentation module to obtain the target intermediate byte. code file, perform the following operations:

Use a bytecode manipulation tool to run the intermediate bytecode file;

A preset instrumentation module is used to read the bytecode class files in the intermediate bytecode file based on the bytecode operation tool, and the hotspot code is added to the bytecode class file to monitor the instrumentation logic to generate target bytes. code class file, perform writeback processing on the target bytecode class file on the intermediate bytecode file to obtain the target intermediate bytecode file.

In one embodiment, the preset instrumentation module includes an instrumentation converter, a class reader, a class modifier, and a class writer. When the processor 110 executes the preset instrumentation module based on the word The section code operation tool reads the bytecode class files in the intermediate bytecode file, adds hot code monitoring instrumentation logic to the bytecode class file to generate the target bytecode class file, and The code file is subjected to writeback processing for the target bytecode class file. When the target intermediate bytecode file is obtained, the following operations are specifically performed:

Control the class reader to read the bytecode class file in the intermediate bytecode file through the instrumentation converter based on the bytecode operation tool;

Based on the bytecode operation tool, the instrumentation converter controls the class modifier to add hot code to the bytecode class file and monitor the instrumentation logic to generate a target bytecode class file;

Based on the bytecode operation tool, the instrumentation converter controls the class writer to perform writeback processing on the intermediate bytecode file for the target bytecode class file to obtain the target intermediate byte code file.

In one embodiment, the processor 110 controls the class modifier to add hot code monitoring instrumentation to the bytecode class file through the instrumentation converter when executing the tool based on the bytecode operation. Logically generate target bytecode class files and perform the following steps:

Obtain the notification adapter class corresponding to the bytecode operation tool, and obtain the entry method method corresponding to the notification adapter class;

The class reader is controlled by the instrumentation converter to intercept the bytecode class file, the target bytecode execution method is determined based on the bytecode class file, and the hot code monitoring instrumentation is performed when the entry method is called. The logic is written into the target bytecode execution method, and a target bytecode class file containing the target bytecode execution method is generated.

In one embodiment, the processor 110 uses a bytecode operation tool to run the intermediate bytecode file, and uses a preset instrumentation module to read the intermediate bytecode based on the bytecode operation tool. The bytecode class files in the file, add hot code monitoring instrumentation logic to the bytecode class files to generate target bytecode class files, and perform the target bytecode class file on the intermediate bytecode class files. Write back processing to obtain the target intermediate bytecode file and perform the following steps:

Determine that the instrumentation method for the hot code monitoring instrumentation logic is the real-time instrumentation type, use the bytecode operation tool to run the intermediate bytecode file online, use the preset instrumentation module as the program agent, and use The preset instrumentation module reads the bytecode class files in the intermediate bytecode file based on the bytecode operation tool, and adds hot code monitoring and instrumentation logic to the bytecode class files to generate target bytecodes. Class file: perform writeback processing on the intermediate bytecode file for the target bytecode class file to obtain the target intermediate bytecode file;

Determine that the instrumentation method for the hot code monitoring instrumentation logic is the offline instrumentation type, use the bytecode operation tool to run the intermediate bytecode file offline, use the intermediate bytecode file as bytecode, and use The preset instrumentation module reads the bytecode class files in the intermediate bytecode file based on the bytecode operation tool and the file input stream method, and adds hot code monitoring instrumentation logic to the bytecode class files. Generate a target bytecode class file, and perform writeback processing on the target bytecode class file based on the file output stream mode to obtain the target intermediate bytecode file.

In one embodiment, when the processor 110 is executing the hot code monitoring instrumentation logic to determine the hot spot code for the program source code file, the processor 110 performs the following steps:

Obtain the hot code monitoring method input for the program source code file. The hot code monitoring method includes method call number records, method input and output parameter records, method call chain records, method call time-consuming records, method parameter transfer records, At least one of method rewriting records and method function extension records;

Hotspot code monitoring instrumentation logic is generated based on the hotspot code monitoring method.

In one embodiment, when the processor 110 executes the target intermediate bytecode file, obtains the hotspot code execution record file corresponding to the hotspot code monitoring instrumentation logic, and performs the following steps:

Run the target intermediate bytecode file and record the hotspot code execution record file corresponding to the hotspot code monitoring instrumentation logic;

The hot code execution record file is exported through the file output stream through the data export module, and the hot code execution record file is stored in the device file system.

In one embodiment, the processor 110 also performs the following steps when executing the method:

The hotspot code execution record file is read through the data analysis module, and graph analysis is performed on the hotspot code execution record file to obtain a method call data list of the graph data type, and the method call data list is stored in the database.

Those of ordinary skill in the art can understand that all or part of the processes in the methods of the above embodiments can be implemented by instructing relevant hardware through a computer program. The program can be stored in a computer-readable storage medium. The program can be stored in a computer-readable storage medium. During execution, the process may include the processes of the embodiments of each of the above methods. Wherein, the storage medium may be a magnetic disk, an optical disk, a read-only memory or a random access memory, etc.

What is disclosed above is only the preferred embodiment of the present application. Of course, it cannot be used to limit the scope of rights of the present application. Therefore, equivalent changes made according to the claims of the present application still fall within the scope of the present application.

Claims (11)

1. A method of pile driving processing, the method comprising:

compiling an intermediate byte code file corresponding to a program source code file, and determining hot code monitoring instrumentation logic aiming at the program source code file;

Adding the hot code monitoring instrumentation logic to the intermediate byte code file by using a byte code operation tool based on a preset instrumentation module to obtain a target intermediate byte code file;

and running the target intermediate byte code file, and obtaining a hot code execution record file corresponding to the hot code monitoring instrumentation logic.

2. The method of claim 1, wherein the adding the hot code monitor instrumentation logic to the intermediate bytecode file based on the preset instrumentation module using a bytecode operation tool to obtain a target intermediate bytecode file comprises:

running the intermediate byte code file;

and reading the byte code class file in the intermediate byte code file by adopting a preset instrumentation module based on the byte code operation tool, adding hot code monitoring instrumentation logic to the byte code class file to generate a target byte code class file, and performing write-back processing on the intermediate byte code file aiming at the target byte code class file to obtain a target intermediate byte code file.

3. The method of claim 2, wherein the pre-set instrumentation module comprises an instrumentation transformer, a class reader, a class modifier, a class writer,

The step of adopting a preset instrumentation module to read a byte code class file in the intermediate byte code file based on the byte code operation tool, adding hot code monitoring instrumentation logic to the byte code class file to generate a target byte code class file, and performing write-back processing on the intermediate byte code file aiming at the target byte code class file to obtain a target intermediate byte code file, wherein the step of obtaining the target intermediate byte code file comprises the following steps:

controlling the class reader to read a byte code class file in the intermediate byte code file through the instrumentation converter based on the byte code operation tool;

controlling the class modifier to add hot code monitoring instrumentation logic to the byte code class file through the instrumentation converter based on the byte code operation tool to generate a target byte code class file;

and controlling the class writer to write back the intermediate byte code file through the instrumentation converter based on the byte code operation tool to obtain a target intermediate byte code file.

4. The method of claim 3, wherein the controlling the class modifier to add hot code monitoring instrumentation logic to the bytecode class file via the instrumentation transformer based on the bytecode operation tool to generate a target bytecode class file comprises:

Acquiring a notification adapter class corresponding to the byte code operation tool, and acquiring an entry method corresponding to the notification adapter class;

and controlling the class reader to intercept the byte code class file through the instrumentation converter, determining a target byte code execution method based on the byte code class file, and writing hot code monitoring instrumentation logic into the target byte code execution method by the method when the entry method is called to generate a target byte code class file containing the target byte code execution method.

5. The method according to claim 2, wherein the running the intermediate bytecode file using a bytecode operation tool, reading a bytecode class file in the intermediate bytecode file using a preset instrumentation module based on the bytecode operation tool, adding hot code monitoring instrumentation logic to the bytecode class file to generate a target bytecode class file, and performing write-back processing for the target bytecode class file on the intermediate bytecode file to obtain a target intermediate bytecode file, includes:

determining that the instrumentation mode of the hot code monitoring instrumentation logic is a real-time instrumentation mode, using a byte code operation tool to operate the intermediate byte code file on line, using the preset instrumentation module as a program agent, reading a byte code class file in the intermediate byte code file by adopting the preset instrumentation module based on the byte code operation tool, adding the hot code monitoring instrumentation logic into the byte code class file to generate a target byte code class file, and performing write-back processing on the intermediate byte code file aiming at the target byte code class file to obtain a target intermediate byte code file;

Determining that the instrumentation mode of the hot code monitoring instrumentation logic is an offline instrumentation mode, using a byte code operation tool to offline operate the intermediate byte code file, taking the intermediate byte code file as a byte code, adopting a preset instrumentation module to read byte code class files in the intermediate byte code file based on the byte code operation tool and a file input stream mode, adding the hot code monitoring instrumentation logic to the byte code class file to generate a target byte code class file, and performing write-back processing on the intermediate byte code file aiming at the target byte code class file based on a file output stream mode to obtain a target intermediate byte code file.

6. The method of claim 1, wherein the determining hot code monitoring instrumentation logic for the program source code file comprises:

acquiring a hot code monitoring mode input for the program source code file, wherein the hot code monitoring mode comprises at least one of a method call frequency record, a method entry and exit record, a method call chain record, a method call time-consuming record, a method parameter transmission record, a method rewriting record and a method function expansion record;

And generating hot code monitoring instrumentation logic based on the hot code monitoring mode.

7. The method of claim 1, wherein the running the target intermediate bytecode file, obtaining a hot code execution record file corresponding to the hot code monitoring instrumentation logic, comprises:

operating the target intermediate byte code file, and recording a hot code execution record file corresponding to the hot code monitoring instrumentation logic;

and exporting the hot code execution record file through a file output stream by a data export module, and storing the hot code execution record file into a device file system.

8. The method according to any one of claims 1-7, further comprising:

and reading the hot code execution record file through a data analysis module, performing graphic analysis processing on the hot code execution record file to obtain a method call data list of the graph data type, and storing the method call data list into a database.

9. A stake-inserting processing device, the device comprising:

the compiling module is used for compiling the intermediate byte code file corresponding to the program source code file and determining hot code monitoring instrumentation logic aiming at the program source code file;

The instrumentation module is used for adding the hot code monitoring instrumentation logic to the intermediate byte code file by using a byte code operation tool based on a preset instrumentation module to obtain a target intermediate byte code file;

and the operation module is used for operating the target intermediate byte code file and acquiring a hot code execution record file corresponding to the hot code monitoring instrumentation logic.

10. A computer storage medium storing a plurality of instructions adapted to be loaded by a processor and to perform the method steps of any one of claims 1 to 8.

11. An electronic device, comprising: a processor and a memory; wherein the memory stores a computer program adapted to be loaded by the processor and to perform the method steps of any of claims 1-8.