CN117632746A

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

Info

Publication number: CN117632746A
Application number: CN202311660702.8A
Authority: CN
Inventors: 杨逸
Original assignee: Guangdong Oppo Mobile Telecommunications Corp Ltd
Current assignee: Guangdong Oppo Mobile Telecommunications Corp Ltd
Priority date: 2023-12-05
Filing date: 2023-12-05
Publication date: 2024-03-01

Abstract

The embodiment of the application discloses a pile inserting processing method, a pile inserting processing device, a storage medium and electronic equipment, wherein the method comprises the following steps: compiling an intermediate byte code file corresponding to the program source code file, determining hot code monitoring instrumentation logic for 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 operating the target intermediate byte code file to obtain a hot code execution record file corresponding to the hot code monitoring instrumentation logic.

Description

Pile inserting processing method and device, storage medium and electronic equipment

Technical Field

The present disclosure relates to the field of computer technologies, and in particular, to a pile inserting processing method, a pile inserting processing device, a storage medium, and an electronic device.

Background

With the rapid development of computer technology, terminals such as mobile phones and tablet computers are rapidly popularized, and for terminal systems, system hot code statistics is often involved, which generally refers to analysis and statistics of key codes in application programs of the terminal systems so as to know the execution frequency of the codes, the call condition of hot functions or methods, and the like, and can help developers optimize performance, promote safety, improve user experience, provide data support for product improvement and code maintenance, and further improve the quality, reliability and user satisfaction of the application programs.

Disclosure of Invention

The embodiment of the application provides a pile inserting processing method, a pile inserting processing device, a storage medium and electronic equipment, wherein the technical scheme is as follows:

in a first aspect, an embodiment of the present application provides a pile inserting processing method, where the method includes:

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.

In a second aspect, an embodiment of the present application provides a pile inserting processing apparatus, including:

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.

In a third aspect, embodiments of the present application provide a computer storage medium storing a plurality of instructions adapted to be loaded by a processor and to perform the above-described 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 adapted to be loaded by the processor and to perform the above-mentioned method steps.

The technical scheme provided by some embodiments of the present application has the beneficial effects that at least includes:

in one or more embodiments of the present application, a terminal compiles an intermediate bytecode file corresponding to a program source code file, determines hot code monitoring instrumentation logic for the program source code file, and in order to implement non-invasive hot code method call monitoring and call statistics based on a bytecode operation tool, a preset instrumentation module is configured in advance, the hot code monitoring instrumentation logic is added to the intermediate bytecode file by using the bytecode operation tool based on the preset instrumentation module to obtain a target intermediate bytecode file, the intermediate bytecode file is modified instead of directly modifying the program source code file, and then the target intermediate bytecode file is operated to obtain a hot code execution record file corresponding to the hot code monitoring instrumentation logic, thereby implementing non-invasive instrumentation of the program source code.

Drawings

In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the drawings that are required in the embodiments or the description of the prior art will be briefly described below, it being obvious that the drawings in the following description are only some embodiments of the present application, and that other drawings may be obtained according to these drawings without inventive effort for a person skilled in the art.

Fig. 1 is a schematic flow chart of a pile-inserting processing method provided in an embodiment of the present application;

FIG. 2 is a schematic view of a source code compilation scenario provided in an embodiment of the present application;

fig. 3 is a schematic view of a scenario for monitoring source code instrumentation according to an embodiment of the present application;

FIG. 4 is a schematic flow chart of another embodiment of a pile-driving processing method according to the embodiments of the present application;

fig. 5 is a schematic diagram of a preset stake-inserting module according to an embodiment of the present application;

fig. 6 is a schematic diagram of a preset stake-inserting module according to an embodiment of the present application;

FIG. 7 is a schematic diagram of a hot code call number record according to an embodiment of the present application;

fig. 8 is a schematic device diagram of a pile inserting processing device according to an embodiment of the present disclosure;

Fig. 9 is a schematic structural diagram of an electronic device according to an embodiment of the present application;

FIG. 10 is a schematic diagram of an operating system and user space provided by an embodiment of the present application;

FIG. 11 is an architecture diagram of the android operating system of FIG. 10;

FIG. 12 is an architecture diagram of the IOS operating system of FIG. 10.

Detailed Description

The following description of the embodiments of the present application will be made clearly and fully with reference to the accompanying drawings, in which it is evident that the embodiments described are only some, but not all, of the embodiments of the present application. All other embodiments, which can be made by one of ordinary skill in the art without undue burden from the present disclosure, are within the scope of the present disclosure.

In the description of the present application, it should be understood that the terms "first," "second," and the like are used for descriptive purposes only and are not to be construed as indicating or implying relative importance. In the description of the present application, it is to be understood that the terms "comprise" and "have," and any variations thereof, are intended to cover non-exclusive inclusions, unless otherwise specifically defined and defined. For example, a process, method, system, article, or apparatus that comprises a list of steps or elements is not limited to only those listed steps or elements but may include other steps or elements not listed or inherent to such process, method, article, or apparatus. The specific meaning of the terms in this application will be understood by those of ordinary skill in the art in a specific context. Furthermore, in the description of the present application, unless otherwise indicated, "a plurality" means two or more. "and/or", describes an association relationship of an association object, and indicates that there may be three relationships, for example, a and/or B, and may indicate: a exists alone, A and B exist together, and B exists alone. The character "/" generally indicates that the context-dependent object is an "or" relationship.

In the related art, hot spot code statistics or hot spot code analysis of an operating system (which may be abbreviated as a terminal system) of a terminal is to add embedded point logic, data recording logic, related logic and other hot spot code monitoring logic in program source codes of a system related module in a manual or automatic mode to generate new program source codes, then the new program source codes are recompiled to generate new programs, and finally the modified programs are executed to realize statistics of hot spot code call.

On the one hand, the related modules of the terminal system are provided with a large number of code warehouses, so that the workload of modifying the source codes of the hot code warehouses is extremely high and the efficiency is low; on the other hand, hot code monitoring logic is added in the program source code, and belongs to invasive code instrumentation, and the execution logic of an original system module can be changed, so that the phenomena of program execution performance reduction, program breakdown and the like can be caused;

as can be seen, there are certain limitations to hot code call monitoring in the related art.

The present application is described in detail with reference to specific examples.

In one embodiment, as shown in fig. 1, a method of pile driver processing is proposed, which may be implemented in dependence on a computer program and may be run on a pile driver processing device based on von neumann system. The computer program may be integrated in the application or may run as a stand-alone tool class application. The pile driver processing device may be a terminal device, including but not limited to: personal computers, tablet computers, handheld devices, vehicle mounted devices, wearable devices, computing devices, or other processing devices connected to a wireless modem, and the like. Terminal devices in different networks may be called different names, for example: a user equipment, an access terminal, a subscriber unit, a subscriber station, a mobile station, a remote terminal, a mobile device, a user terminal, a wireless communication device, a user agent or user equipment, a cellular telephone, a cordless telephone, a terminal device in a 5G network or a future evolution network, etc.

Specifically, the pile inserting processing method comprises the following steps:

s102: 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;

the program source code file can be understood as the program source code of the development end in the stages of code writing, code debugging, code maintenance and the like, and the source code files coded by different machine programmable languages can be called as different language program source code files;

for example, as shown in fig. 2, fig. 2 is a schematic view of a source code compiling scenario. The machine programmable language may be a Java language, and the program source code file may be called a Java program source code file (Java source code for short); illustratively, java source code is compiled and converted into class files (i.e., intermediate byte code files) through Java (Java's compiler front end), and the file content of the class is Java byte code.

In practical applications, for terminal systems, system hot code statistics is often related to analysis and statistics of key codes in application programs of the terminal systems, so as to understand execution frequency of the codes, call conditions of hot functions or methods, and the like, in order to avoid limitations caused by invasive modification, the instrumentation processing method of one or more embodiments of the present disclosure may be executed, so as to implement non-invasive hot code method call monitoring and call statistics based on a bytecode operation tool.

The source code is first converted into the byte code that can be identified by the machine programmable language virtual machine (e.g., java virtual machine), and these byte codes can be called as intermediate byte code files.

Based on the actual needs, it is determined that the code segments which may have performance problems and are frequently called are injected, namely hot codes, and hot code monitoring instrumentation logic is as follows: the user of the terminal (e.g., developer, tester, maintainer, etc.) determines hot code monitoring instrumentation logic (also referred to as hot code call instrumentation logic) from the targets of hot code call monitoring in the source code in order to gather information about program behavior or performance as the hot code to be monitored executes.

Specifically, various tools and techniques can be used in advance to determine the hot codes to be monitored in the program source code file, and after the hot codes in the program source code file are determined, the hot code monitoring instrumentation logic can be generated by using the non-invasive instrumentation logic, and the execution calling condition of the hot codes can be monitored based on the hot code monitoring instrumentation logic.

In a possible implementation manner, the terminal may obtain a hot code monitoring manner input by a user (for example, a developer, a tester, a maintainer, etc.) for a program source code file, where the hot code monitoring manner includes at least one of a method call number record, a method entry and exit record, a method call chain record, a method call time-consuming record, a method parameter transfer record, a method rewrite record, and a method function extension record, and then generates hot code monitoring instrumentation logic based on the hot code monitoring manner.

And a user-defined hot code monitoring instrumentation logic can be added to the intermediate byte code file by using a byte code operation tool in combination with a preset instrumentation module.

One way may be: a user (such as a developer, a tester, a maintainer and the like) inputs a hot code monitoring mode aiming at a program source code file, and the user self-defines a code hot code monitoring instrumentation logic, wherein the hot code monitoring instrumentation logic is characterized in a code data form, and a terminal only needs to receive the hot code monitoring instrumentation logic input by the user;

one way may be: the method comprises the steps that a template mapping relation between a hot code monitoring type and a instrumentation logic automatic generation template is predefined, a user only needs to input a hot code monitoring mode, hot code monitoring configuration is carried in data corresponding to the hot code monitoring mode, the hot code monitoring configuration comprises hot codes, hot code monitoring parameters, hot code monitoring types (such as call times record types and method parameter entering and exiting types) and the like, a target instrumentation logic corresponding to the current hot code monitoring type can be queried from the template mapping relation based on the hot code monitoring types, then the target instrumentation logic automatic generation template is used for automatically generating the hot code monitoring instrumentation logic in combination with the hot codes, the hot code monitoring parameters, the hot code monitoring types and the like carried in the hot code monitoring mode input by the user.

S104: 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;

in order to realize the non-invasive hot code method call monitoring and call statistics based on the byte code operation tool, a preset instrumentation module is pre-configured, for example, the preset instrumentation module is fused into a modification step of compiling an intermediate product-intermediate byte code file, the intermediate byte code file is modified instead of directly modifying a program source code file (Java source file), and the non-invasive instrumentation of the program source code is realized. Compared with the existing invasive code pile inserting scheme, the automatic degree of pile inserting is improved, the labor cost is reduced, the influence of pile inserting on the performance of source codes is reduced, and a plurality of sub-modules contained in a terminal system in the pile inserting process are more convenient and efficient.

The byte code operation tool refers to a tool program for performing related operations on the intermediate byte code file;

alternatively, the bytecode manipulation tool may be an ASM class library, which is a library that manipulates Java bytecodes. The use of a bytecode operator-ASM class library based on a preset instrumentation module in the present specification may be used to read, modify, and generate the bytecode of Java classes and inject the point code monitoring instrumentation logic into the intermediate bytecode file. Through ASM, the intermediate byte code files may be operated programmatically to perform various byte code level operations, such as insertion, modification, deletion, etc. of methods. This class library provides a rich API interface that allows the Java bytecode in the intermediate bytecode file to be conveniently handled based on the preset instrumentation module in this specification using a bytecode manipulation tool.

Specifically, a custom hot spot code monitoring instrumentation logic is added to an intermediate byte code file (Class file) by using a byte code operation tool such as an ASM Class library based on the instrumentation module to obtain a target intermediate byte code file, wherein the instrumentation logic can be at least one of a method call number recording logic, a method entry and exit recording logic, a method call chain recording logic, a method call time consuming recording logic, a method parameter transferring recording logic, a method rewriting recording logic, a method function expanding recording logic and the like;

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

Specifically, configuring a target intermediate byte code file after instrumentation into a terminal system, enabling the terminal to run the target intermediate byte code file, triggering the functions of related modules of the terminal system based on the target intermediate byte code file to execute related program codes, wherein in the process of executing the hot codes, the hot codes are operated, meanwhile, in the process of executing the hot codes, monitoring instrumentation logic based on the hot codes of the instrumentation, automatically recording the execution conditions of the related hot codes, such as method calling times record, method joining and joining records, method calling chain record, method calling time-consuming record, method parameter transferring record, method rewriting record, method function expanding record and the like; when the source program corresponding to the target intermediate byte code file finishes running, the hot code monitoring instrumentation logic exports the call record of the hot code into a binary file, namely a hot code execution record file in the specification, wherein the exported hot code execution record file can contain preset monitoring information such as method call times, execution time, parameter entering, parameter exiting, dynamic call chains and the like according to the hot code monitoring instrumentation logic.

Exemplary, as shown in fig. 3, fig. 3 is a schematic view of a source code instrumentation monitoring scenario. The machine programmable language may be a Java language, and the program source code file may be called a Java program source code file (Java source code for short); illustratively, java source code is compiled and converted into class files (i.e., intermediate byte code files) through Java (Java's compiler front end), and the file content of the class is Java byte code. And then adding the hot code monitoring instrumentation logic to the intermediate byte code file by using a byte code operation tool through a preset instrumentation module to obtain a class file-target intermediate byte code file after instrumentation, further, in one or more embodiments of the present specification, the preset instrumentation module supports the "on-the-fly" real-time instrumentation and "off-line instrumentation functions, then operates the class file-target intermediate byte code file, and performs data derivation in the hot code operation process based on the hot code monitoring instrumentation logic, so that a corresponding hot code execution record file can be obtained, and then further data analysis can be performed on the hot code execution record file according to actual requirements.

In one or more embodiments of the present disclosure, a terminal compiles an intermediate byte code file corresponding to a program source code file, determines hot code monitoring instrumentation logic for the program source code file, and in order to implement non-invasive hot code method call monitoring and call statistics based on a byte code operation tool, a preset instrumentation module is configured in advance, the hot code monitoring instrumentation logic is added to the intermediate byte code file by using the byte code operation tool based on the preset instrumentation module to obtain a target intermediate byte code file, the intermediate byte code file is modified instead of directly modifying the program source code file, and then the target intermediate byte code file is operated to obtain a hot code execution record file corresponding to the hot code monitoring instrumentation logic, thereby implementing non-invasive instrumentation of the program source code.

Referring to fig. 4, fig. 4 is a flow chart illustrating another embodiment of a pile driving processing method according to the present application. Specific:

s202: 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;

specifically, after a terminal compiles an intermediate byte code file corresponding to a program source code file and determines a hot code monitoring instrumentation logic for the program source code file, the terminal executes a process of 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;

further, the terminal executes the hot code monitoring instrumentation logic added 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, as follows:

the preset pile inserting module can support a real-time pile inserting function and an off-line pile inserting function, the real-time pile inserting function can be suitable for small-scale program pile inserting in a quick and instant mode, and the off-line pile inserting function can be suitable for large-scale system-level pile inserting. Based on different requirements, the hot code monitoring instrumentation logic can be added to the type intermediate byte code file based on the related instrumentation function to obtain a target intermediate byte code file;

After determining the hot code monitoring instrumentation logic aiming at the program source code file, the terminal determines that the instrumentation mode aiming at the hot code monitoring instrumentation logic is a real-time instrumentation type or an offline instrumentation type;

optionally, determining that the instrumentation mode of the instrumentation logic for hot code monitoring is a real-time instrumentation mode, using a byte code operation tool by a terminal 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 the preset instrumentation module based on the byte code operation tool, 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 for the target byte code class file to obtain a target intermediate byte code file;

illustratively, the pre-main method is implemented by using the on-the-fly real-time instrumentation function of the preset instrumentation module, and using the preset instrumentation module as a program agent (JavaAgent). In Java, javaAgent is a program agent that can be integrated with a target Java application to modify or enhance its behavior. This is achieved through the Instrumentation API interface of Java. And the premain method is a special entry point of the program agent JavaAgent, and is executed before the main method of the target application program (which can be regarded as before the execution of the source program code).

Further, in the premain method, a byte code operation tool (such as an ASM or other byte code operation library) is used by a preset instrumentation module to read a byte code class file in the middle byte code file, the byte code operation tool can be used to modify or rewrite the byte code of a target class corresponding to the hot code monitoring instrumentation logic, the hot code monitoring instrumentation logic is added to the byte code class file to generate a target byte code class file, and then the target byte code class file is written back to the middle byte code file to obtain a target middle byte code file;

subsequently, when running, java agents can be loaded through Java command lines, so that the premain method added with the hot code monitoring instrumentation logic is ensured to be executed before the main method of the application program, and real-time instrumentation is realized. The method is characterized in that a specified method is subjected to byte code enhancement in the class loading process by utilizing a premain method of the JavaAgent. The java compiling intermediate product, namely the byte code, is modified in the class loading process so as to realize the function addition of non-invasive source code without modification, and the method is applicable to quick and instant small-scale program instrumentation.

The on-the-fly real-time instrumentation function supported by the preset instrumentation module enables the number of hot code call times to be counted when the instrumentation module is used as a program Agent (such as Java Agent) to be locally debugged in a program development stage, and the on-the-fly real-time instrumentation function is more flexible and rapid.

Optionally, determining that the instrumentation mode of the hot code monitoring instrumentation logic is an offline instrumentation type, using a byte code operation tool to offline operate the intermediate byte code file, taking the intermediate byte code file as a byte code, reading a byte code class file in the intermediate byte code file by adopting a preset instrumentation module 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 for the target byte code class file based on a file output stream mode to obtain the target intermediate byte code file.

In particular, in software development, especially in terminal large systems such as android systems, tracking, analysis and optimization of hot codes is of paramount importance. For the purpose of hot code monitoring, users often need to use instrumentation techniques to collect code execution information. For large-scale system-level pile insertion, the preset pile insertion module provides an offline pile insertion function, namely an off-line pile insertion function.

For example, after the java compiler source code file generates an intermediate byte code file-class file, the intermediate byte code file is operated offline by using a byte code operation tool, the intermediate byte code file is regarded as a byte code, and a byte code class file in the intermediate byte code file is read by adopting a preset instrumentation module based on the byte code operation tool and a file input stream mode, namely: the file input stream is used to read the generated intermediate byte code files, the intermediate byte code files are converted into byte code forms, and the byte code files are transferred to the components of the Customtransformer by adopting a preset instrumentation module. The role of the custom form component is to modify or enhance these bytecodes according to specific requirements or rules. The process of modifying or enhancing the bytecodes realizes that the hot code monitoring instrumentation logic is added to the bytecode class file to generate a target bytecode class file, wherein the modification or enhancement may be to insert a performance timer, a log record statement or any other type of code according to the hot code monitoring instrumentation logic, and the target bytecode class file is generated after the customs former finishes modifying or enhancing the bytecodes (namely, the bytecode class file), and the bytecodes subjected to custom instrumentation (namely, the target bytecode class file) are written back into the original intermediate bytecode file through a file output stream to replace old bytecodes. Thus, a non-invasive offline custom instrumentation is realized, the source code file of which remains unchanged, while the bytecodes in the intermediate bytecode file have been modified and enhanced to generate the target intermediate bytecode file.

The preset pile inserting module provides an offine pile inserting function and is applicable to large-scale system-level pile inserting. In the development of a terminal system, due to the complexity of the system and the huge amount of codes, effective instrumentation of each sub-module of the system can be realized by executing the method of one or more embodiments of the present specification. The preset stake inserting module provides the function of the offline stake inserting, and the high-efficiency hot code calling monitoring is realized by processing the byte codes of the whole system at one time.

Under subsequent processing, the instrumented compiled macros may be opened at the compilation stage of the system. This means that the target intermediate bytecode file has incorporated the instrumented logic during the compilation of the code into bytecodes. Thus, the compiled end product target intermediate bytecode file (i.e., class file) already contains instrumented code. Thus, when the hot code functions after instrumentation are used in execution, the system can automatically record the calling times, execution time and other information of the hot code.

S204: running the intermediate byte code file;

s206: 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.

In one possible embodiment, as shown in fig. 5, fig. 5 is a schematic diagram of a pre-staking module including a stake-ing transducer, a class reader, a class modifier, a class writer,

the instrumentation converter may be called Transformer (CustomTransformer), and the transducer is associated with a class reader, a class modifier, and a class writer, where the instrumentation method rewritten in the custom plug-in is to read the bytecode in the class file, and return the bytecode added with the custom instrumentation code through the associated class writer.

Class readers may be referred to as classreaders; class modifiers may be referred to as custom ClassAdapters (or custom ClassAdapters), which rewrite the ClassVisitor methods in the ASM class library; the class writer may be referred to as a ClassWriter for writing back modified class files.

The specific implementation method can be as follows:

a2: the terminal controls a class reader to read a byte code class file in the middle byte code file through a instrumentation converter based on a byte code operation tool;

a4: the method comprises the steps that based on a byte code operation tool, a class modifier is controlled by a instrumentation converter, hot code monitoring instrumentation logic is added to a byte code class file, and a target byte code class file is generated;

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

Specifically, the terminal acquires a notification adapter class corresponding to the byte code operation tool, acquires a method when the notification adapter class corresponds to an entering method, controls the class reader to intercept a byte code class file through the instrumentation converter, determines a target byte code execution method based on the byte code class file, and writes hot code monitoring instrumentation logic into the target byte code execution method when the entering method is called, so as to generate a target byte code class file containing the target byte code execution method.

For example, as shown in fig. 6, fig. 6 is a schematic view of a pile inserting process provided in the present specification. The class files (i.e., bytecode class files) are intercepted by a class modifier, custom class adapter, and the modification logic is implemented by a visittmethod method of overwriting the class identifier (which can be understood as a visitor pattern, as opposed to a class access object). The method comprises the following specific steps: 1. the class modifier is controlled to intercept class files through the instrumentation transformer based on the byte code operation tool, and the method logic of the corresponding byte code class files (corresponding to the byte code class files corresponding to the hot codes) is modified through the rewriting visittmethod (notifying the corresponding method of the adapter class) so as to add (hot code) instrumentation logic (namely, the target byte code class files are obtained after adding the instrumentation logic). 2. The method is characterized in that a instrumentation converter is used for controlling a class writer to rewrite an onmethod entry method (which can be understood as a method-in-process) of an AdviceAdapter class of a byte code operation tool (such as an ASM class library), hot code monitoring instrumentation logic (a method call frequency record, a parameter entry record and a call chain record) is inserted into a corresponding method entry of a corresponding byte code class file, and write-back processing of an intermediate byte code file for a target byte code class file is completed, so that the target intermediate byte code file is obtained.

Illustratively, as shown in FIG. 7, FIG. 7 is a schematic diagram of a record of hot code call times; fig. 7 illustrates a detailed flow of the execution call number record of the hot code monitoring instrumentation logic for the hot code method based on the hot code monitoring instrumentation logic, wherein the unique ID of the hot code method is generated (i.e. the step of acquiring the method information to generate the unique ID in the drawing), the parameters of the "bytecode class" and the "in-and-out parameter" of the hot code method are acquired, then whether the hot code method can be instrumented (i.e. the hot code monitoring instrumentation logic is inserted) is determined,

if the instrumentation is possible, the control class modifier adds hot code monitoring instrumentation logic to the byte code class file, specifically, adds 1 to the hot code method call times of the same ID in the CustomData (method call record data structure stored in the memory) each time the method is entered by the onmethod EnterDo method (i.e. the method when the method is entered).

Optionally, whether the method entry of the hot code method can be instrumented may be determined by determining the condition: the hot code method is not subject to instrumentation, which belongs to the types of bridging methods and methods automatically generated by a compiler;

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

Reference may be made specifically to the steps of the method according to other embodiments of the present disclosure, which are not described herein.

S210: 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.

In the middle byte code file-class file instrumentation process, the hot code monitoring instrumentation logic is correspondingly configured with a call record data structure of the hot code, and the call record data structure of the hot code is inserted into the middle byte code file-class file. The call record contains two layer data structures: the top layer of the data structure is the mapping correspondence between the unique ID (ClassId) of the corresponding method of the hot code class file and the custom data CustomData, wherein the CustomData contains the correspondence between the unique ID (methodId) of each instrumented hot code method in the hot code class and the class method execution record parameters (such as execution times, execution time consumption and the like). After the program is executed, all data are written into a hot code execution record file through a file output stream, and the hot code execution record file is a binary file (such as a Customec file) and is stored in a device file system of a terminal

S212: 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.

The data analysis module consists of a FileReader, and the data analysis module processes the following main processes: and reading a hot code execution record file (binary file), restoring the hot code execution record file into Map data types (namely, the corresponding relation between ClassId and CustomData in a data export module) through a file input stream, intercepting (hot code) method call data contained in the CustomData, and finally generating a method call data list and storing the method call data list into a database.

The method realizes non-invasive hot code statistics through byte code operation tools such as ASM library, does not affect the logic and performance of original program source codes, provides a flexible instrumentation mode, and supports large-scale system-level instrumentation.

In one or more embodiments of the present disclosure, on-the-fly instrumentation and offly instrumentation are simultaneously implemented in the above manner, where on-the-fly allows a user (e.g., a developer) to use a preset instrumentation module as a java agent to locally debug a program development stage, so that hot code call conditions can be counted, and the instrumentation approach is more flexible and faster for the developer. The offline pile is suitable for a large-batch pile inserting scene, such as pile inserting aiming at each sub-module of the system. Under the application scene, the instrumentation compiling macro can be opened when the terminal system compiles, so that a large number of code instrumentation is realized, and the compiled products contain the instrumentation codes. And when the code function after instrumentation is executed, information such as the calling times of hot codes and the like can be automatically recorded. And compared with the traditional invasive code embedded point method, the method has stronger expansibility.

The pile driver processing apparatus according to the embodiment of the present application will be described in detail below with reference to fig. 8. It should be noted that, the pile driver processing apparatus shown in fig. 8 is configured to perform the method of the embodiments shown in fig. 1 to 7, and for convenience of explanation, only the portion relevant to the embodiments of the present application is shown, and specific technical details are not disclosed, please refer to the embodiments shown in fig. 1 to 7 of the present application.

Fig. 8 is a schematic structural diagram of a pile driver processing device according to an embodiment of the present disclosure. The instrumentation processing device 1 may be implemented as all or part of the user terminal by software, hardware or a combination of both. According to some embodiments, the instrumentation processing device 1 comprises a compiling module 11, an instrumentation module 12 and an operating module 13, in particular for:

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

the instrumentation module 12 is configured to add 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, so as to obtain a target intermediate byte code file;

an operation module 13, configured to operate the target intermediate byte code file, and obtain a hot code execution record file corresponding to the hot code monitoring instrumentation logic

Alternatively, as shown in fig. 6, the apparatus 1 includes:

optionally, the pile inserting module 12 is configured to:

running the intermediate bytecode file using a bytecode operation tool;

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.

Optionally, the preset instrumentation module includes an instrumentation transformer, a class reader, a class modifier, and a class writer, and the instrumentation module 12 is configured to:

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.

Optionally, the pile inserting module 12 is configured to:

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.

Optionally, the pile inserting module 12 is configured to: 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.

Optionally, the compiling module 11 is configured to:

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.

Optionally, the operation module is configured to:

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.

Optionally, the device 1:

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.

It should be noted that, when the pile inserting processing apparatus provided in the foregoing embodiment performs the pile inserting processing method, only the division of the foregoing functional modules is used as an example, and in practical application, the foregoing functional allocation may be performed by different functional modules according to needs, that is, the internal structure of the device is divided into different functional modules, so as to complete all or part of the functions described above. In addition, the pile inserting processing device and the pile inserting processing method provided in the foregoing embodiments belong to the same concept, and the implementation process is embodied in the method embodiment, which is not described herein again.

The foregoing embodiment numbers of the present application are merely for describing, and do not represent advantages or disadvantages of the embodiments.

The embodiment of the present application further provides a computer storage medium, where the computer storage medium may store a plurality of instructions, where the instructions are suitable for being loaded by a processor and executed by the pile inserting processing method according to the embodiment shown in fig. 1 to 7, and a specific execution process may refer to a specific description of the embodiment shown in fig. 1 to 7, which is not repeated herein.

The present application further provides a computer program product, where at least one instruction is stored, where the at least one instruction is loaded by the processor and executed by the processor, where the specific execution process may refer to the specific description of the embodiment shown in fig. 1 to 7, and details are not repeated herein.

Referring to fig. 9, a block diagram of an electronic device according to an exemplary embodiment of the present application is shown. An electronic device in the present application may include one or more of the following components: processor 110, memory 120, input device 130, output device 140, and bus 150. The processor 110, the memory 120, the input device 130, and the output device 140 may be connected by a bus 150.

Processor 110 may include one or more processing cores. The processor 110 utilizes various interfaces and lines to connect various portions of the overall electronic device, perform various functions of the electronic device 100, and process data by executing or executing instructions, programs, code sets, or instruction sets stored in the memory 120, and invoking data stored in the memory 120. Alternatively, the processor 110 may be implemented in at least one hardware form of digital signal processing (digital signal processing, DSP), field-programmable gate array (field-programmable gate array, FPGA), programmable logic array (programmable logic Array, PLA). The processor 110 may integrate one or a combination of several of a central processing unit (central processing unit, CPU), an image processor (graphics processing unit, GPU), and a modem, etc. The CPU mainly processes an operating system, a user interface, an application program and the like; the GPU is used for being responsible for rendering and drawing of display content; the modem is used to handle wireless communications. It will be appreciated that the modem may not be integrated into the processor 110 and may be implemented solely by a single communication chip.

The memory 120 may include a random access memory (random Access Memory, RAM) or a read-only memory (ROM). Optionally, the memory 120 includes a non-transitory computer readable medium (non-transitory computer-readable storage medium). Memory 120 may be used to store instructions, programs, code, sets of codes, or sets of instructions. The memory 120 may include a stored program area and a stored data area, wherein the stored program area may store instructions for implementing an operating system, which may be an Android (Android) system, including an Android system-based deep development system, an IOS system developed by apple corporation, including an IOS system-based deep development system, or other systems, instructions for implementing at least one function (such as a touch function, a sound playing function, an image playing function, etc.), instructions for implementing various method embodiments described below, and the like. The storage data area may also store data created by the electronic device in use, such as phonebooks, audiovisual data, chat log data, and the like.

Referring to FIG. 10, the memory 120 may be divided into an operating system space in which the operating system is running and a user space in which native and third party applications are running. In order to ensure that different third party application programs can achieve better operation effects, the operating system allocates corresponding system resources for the different third party application programs. However, the requirements of different application scenarios in the same third party application program on system resources are different, for example, under the local resource loading scenario, the third party application program has higher requirement on the disk reading speed; in the animation rendering scene, the third party application program has higher requirements on the GPU performance. The operating system and the third party application program are mutually independent, and the operating system often cannot timely sense the current application scene of the third party application program, so that the operating system cannot perform targeted system resource adaptation according to the specific application scene of the third party application program.

In order to enable the operating system to distinguish specific application scenes of the third-party application program, data communication between the third-party application program and the operating system needs to be communicated, so that the operating system can acquire current scene information of the third-party application program at any time, and targeted system resource adaptation is performed based on the current scene.

Taking an operating system as an Android system as an example, as shown in fig. 11, a program and data stored in the memory 120 may be stored in the memory 120 with a Linux kernel layer 320, a system runtime library layer 340, an application framework layer 360 and an application layer 380, where the Linux kernel layer 320, the system runtime library layer 340 and the application framework layer 360 belong to an operating system space, and the application layer 380 belongs to a user space. The Linux kernel layer 320 provides the underlying drivers for various hardware of the electronic device, such as display drivers, audio drivers, camera drivers, bluetooth drivers, wi-Fi drivers, power management, and the like. The system runtime layer 340 provides the main feature support for the Android system through some C/c++ libraries. For example, the SQLite library provides support for databases, the OpenGL/ES library provides support for 3D graphics, the Webkit library provides support for browser kernels, and the like. Also provided in the system runtime library layer 340 is a An Zhuoyun runtime library (Android run) which provides mainly some core libraries that can allow developers to write Android applications using the Java language. The application framework layer 360 provides various APIs that may be used in building applications, which developers can also build their own applications by using, for example, campaign management, window management, view management, notification management, content provider, package management, call management, resource management, location management. At least one application program is running in the application layer 380, and these application programs may be native application programs of the operating system, such as a contact program, a short message program, a clock program, a camera application, etc.; and may also be a third party application developed by a third party developer, such as a game-like application, instant messaging program, photo beautification program, etc.

Taking an operating system as an IOS system as an example, the program and data stored in the memory 120 are shown in fig. 11, the IOS system includes: core operating system layer 420 (Core OS layer), core service layer 440 (Core Services layer), media layer 460 (Media layer), and touchable layer 480 (Cocoa Touch Layer). The core operating system layer 420 includes an operating system kernel, drivers, and underlying program frameworks that provide more hardware-like functionality for use by the program frameworks at the core services layer 440. The core services layer 440 provides system services and/or program frameworks required by the application, such as a Foundation (Foundation) framework, an account framework, an advertisement framework, a data storage framework, a network connection framework, a geographic location framework, a sports framework, and the like. The media layer 460 provides an interface for applications related to audiovisual aspects, such as a graphics-image related interface, an audio technology related interface, a video technology related interface, an audio video transmission technology wireless play (AirPlay) interface, and so forth. The touchable layer 480 provides various commonly used interface-related frameworks for application development, with the touchable layer 480 being responsible for user touch interactions on the electronic device. Such as a local notification service, a remote push service, an advertisement framework, a game tool framework, a message User Interface (UI) framework, a User Interface UIKit framework, a map framework, and so forth.

Among the frameworks illustrated in fig. 12, frameworks related to most applications include, but are not limited to: the infrastructure in core services layer 440 and the UIKit framework in touchable layer 480. The infrastructure provides many basic object classes and data types, providing the most basic system services for all applications, independent of the UI. While the class provided by the UIKit framework is a basic UI class library for creating touch-based user interfaces, iOS applications can provide UIs based on the UIKit framework, so it provides the infrastructure for applications to build user interfaces, draw, process and user interaction events, respond to gestures, and so on.

The manner and principle of implementing data communication between the third party application program and the operating system in the IOS system may refer to the Android system, which is not described herein.

The input device 130 is configured 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, a speaker, and the like. In one example, the input device 130 and the output device 140 may be combined, and the input device 130 and the output device 140 are a touch display screen for receiving a touch operation thereon or thereabout by a user using a finger, a touch pen, or any other suitable object, and displaying a user interface of each application program. Touch display screens are typically provided on the front panel of an electronic device. The touch display screen may be designed as a full screen, a curved screen, or a contoured screen. The touch display screen can also be designed to be a combination of a full screen and a curved screen, and a combination of a special-shaped screen and a curved screen, which is not limited in the embodiment of the application.

In addition, those skilled in the art will appreciate that the configuration of the electronic device shown in the above-described figures does not constitute a limitation of the electronic device, and the electronic device may include more or less components than illustrated, or may combine certain components, or may have a different arrangement of components. For example, the electronic device further includes components such as a radio frequency circuit, an input unit, a sensor, an audio circuit, a wireless fidelity (wireless fidelity, wiFi) module, a power supply, and a bluetooth module, which are not described herein.

In the embodiment of the present application, the execution subject of each step may be the electronic device described above. Optionally, the execution subject of each step is an operating system of the electronic device. The operating system may be an android system, an IOS system, or other operating systems, which embodiments of the present application do not limit.

The electronic device of the embodiment of the application may further be provided with a display device, where the display device may be various devices capable of implementing a display function, for example: cathode ray tube displays (cathode ray tubedisplay, CR), light-emitting diode displays (light-emitting diode display, LED), electronic ink screens, liquid crystal displays (liquid crystal display, LCD), plasma display panels (plasma display panel, PDP), and the like. A user may utilize a display device on electronic device 101 to view displayed text, images, video, etc. The electronic device may be a smart phone, a tablet computer, a gaming device, an AR (Augmented Reality ) device, an automobile, a data storage device, an audio playing device, a video playing device, a notebook, a desktop computing device, a wearable device such as an electronic watch, electronic glasses, an electronic helmet, an electronic bracelet, an electronic necklace, an electronic article of clothing, etc.

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

In one embodiment, the processor 110, when executing the preset instrumentation module, adds the hot code monitoring instrumentation logic to the intermediate bytecode file using a bytecode operation tool to obtain a target intermediate bytecode file, performs the following operations:

running the intermediate bytecode file using a bytecode operation tool;

In one embodiment, the preset instrumentation module includes an instrumentation converter, a class reader, a class modifier, and a class writer, and when the processor 110 executes the operations of reading a bytecode class file in the intermediate bytecode file by using the 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, the following operations are specifically executed:

In one embodiment, the processor 110, when executing the step of controlling the class modifier to add hot code monitoring instrumentation logic to the bytecode class file through the instrumentation transformer based on the bytecode operation tool, performs the following steps:

In one embodiment, the processor 110 executes the intermediate bytecode file by using a bytecode operation tool, reads a bytecode class file in the intermediate bytecode file by using a preset instrumentation module based on the bytecode operation tool, adds hot code monitoring instrumentation logic to the bytecode class file to generate a target bytecode class file, performs write-back processing on the intermediate bytecode file for the target bytecode class file to obtain a target intermediate bytecode file, and executes the following steps:

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;

In one embodiment, the processor 110, upon executing the hot code monitoring instrumentation logic that determines the hot code for the program source code file, performs the steps of:

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

In one embodiment, the processor 110, when executing the method, further performs the steps of:

Those skilled in the art will appreciate that implementing all or part of the above-described methods in accordance with the embodiments may be accomplished by way of a computer program stored on a computer readable storage medium, which when executed may comprise the steps of the embodiments of the methods described above. The storage medium may be a magnetic disk, an optical disk, a read-only memory, a random access memory, or the like.

The foregoing disclosure is only illustrative of the preferred embodiments of the present application and is not intended to limit the scope of the claims herein, as the equivalent of the claims herein shall be construed to fall within the scope of the claims herein.

Claims

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

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;

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:

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:

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:

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

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:

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

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

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.