CN113419919B - Method for thread monitoring of third party SDK - Google Patents

Abstract

The invention relates to a method for carrying out thread monitoring on a third party SDK, which comprises the following steps: compiling an App source code to obtain a Java byte code file expanded into class; at least one third party SDK is accessed into the source code of the App; traversing Java byte code files through a pre-deployed plug-in, and automatically replacing an instruction for creating a shadow thread preset in the plug-in when the instruction for creating the thread by the third-party SDK is found; thread monitoring is performed on the third party SDK based on the instruction for creating the shadow thread. According to the invention, the byte code is operated at the bottom layer, so that the information acquisition of the thread created by the third party SDK is realized under the condition of not invading the source code, the purpose of thread monitoring is further achieved, and convenience is provided for application program development and debugging.

Description

Method for thread monitoring of third party SDK

Technical Field

The invention relates to the technical field of third-party thread monitoring, in particular to a method for carrying out thread monitoring on a third-party SDK. The SDK is a software development kit (foreign language is called Software Development Kit in full), and simply speaking, some software functions are developed in a standardized way, so that other apps can be plug and play immediately and have the standardized functions of the SDK.

Background

In App (application program) development based on the Java language, the use of a third party SDK is inevitably required, for example: when an App (application program) is developed in Android by adopting Java language, an api provided by a third-party SDK is called, and in the application scene, the fact that threads of the third-party SDK cannot be monitored in the prior art is found, so that inconvenience is brought to development and debugging of the App (application program).

Most of the existing apps belong to applications with complex services (namely complex service logic), the apps can generate a plurality of threads, and a third party SDK accessed in the apps can also generate a plurality of threads, for example: in an App with a certain e-commerce and trip service function, 33 third party SDKs are used inside, and obviously, many threads are generated by the third party SDKs, and due to the existence of the problems (namely, the threads of the third party SDKs cannot be monitored), difficulties are brought to thread management, app debugging and the like, so that the problem of low efficiency of checking is caused, and the problems are particularly expressed in the following aspects:

threads are likely to cause inter-thread competition to be difficult to monitor and manage, so that considerable resources are consumed on thread scheduling to influence the stability of App operation;

Because the thread of the third party SDK cannot be monitored, the risk of creating the wild anonymous thread exists, and a large number of wild anonymous threads which are not uniformly managed exacerbate the consumption of resources, and further increase the difficulty of thread scheduling;

When an application program debugs the Bug, problems are sometimes located through analysis Of an online log, but the problems cannot be further located to a thread (specific thread call stack information cannot be tracked), so that a service module (which means that the service module to which the thread belongs cannot be distinguished) cannot be further located according to the thread, and finally, breakdown such as OOM (Out Memory) and the like is caused;

Because the thread of the third party SDK cannot be monitored, the thread in the third party SDK cannot be effectively managed and intervened in the existing scene.

The information disclosed in this background section is only for enhancement of understanding of the general background of the invention and should not be taken as an acknowledgement or any form of suggestion that this information forms the prior art already known to a person skilled in the art.

Disclosure of Invention

Aiming at the defects existing in the prior art, the invention aims to provide a method for carrying out thread monitoring on a third party SDK, and the method realizes the information acquisition of the thread created by the third party SDK under the condition of not invading source codes by operating byte codes at the bottom layer, thereby achieving the purpose of thread monitoring and providing convenience for the development and debugging of application programs.

In order to achieve the above purpose, the invention adopts the following technical scheme:

the method for carrying out thread monitoring on the third party SDK is characterized by comprising the following steps:

Compiling an App source code to obtain a Java byte code file expanded into class;

At least one third party SDK is accessed into the source code of the App;

traversing Java byte code files through a pre-deployed plug-in, and automatically replacing an instruction for creating a shadow thread preset in the plug-in when the instruction for creating the thread by the third-party SDK is found;

Thread monitoring is performed on the third party SDK based on the instruction for creating the shadow thread.

Based on the technical scheme, the instruction of the third-party SDK creating thread is replaced by the instruction of creating the shadow thread, and the instruction is realized through asm byte code operation.

On the basis of the technical scheme, the pre-deployed plugin is a Gradle plugin, is declared as a thread monitoring module, and is uploaded to a Maven warehouse in the form of plugin to finish the pre-deployment.

On the basis of the technical scheme, when the instruction of the third-party SDK creating thread is found, the instruction of the third-party SDK creating thread is replaced by the instruction of the shadow thread by declaring the mode of introducing the Gradle plug-in, and when the program is executed, the instruction of the shadow thread is created to complete the operation of initializing the thread monitoring module.

Based on the technical scheme, the method further comprises the following steps: storing the byte code file with the traversing and replacing operation as a target byte code file;

the target byte code file is sent to a virtual machine jvm, and an interpreter in the virtual machine jvm converts the target byte code file into an executable binary machine code, and the executable binary machine code is stored to obtain an App program;

when the App program is executed, a thread is generated by creating an instruction of the shadow thread, and an interface for acquiring thread information is provided, so that thread monitoring is realized.

The method for carrying out thread monitoring on the third party SDK has the following beneficial effects:

by operating the byte code at the bottom layer, the information acquisition of the thread created by the third party SDK is realized under the condition of not invading the source code, thereby achieving the purpose of thread monitoring and providing convenience for application program development and debugging.

Drawings

The invention has the following drawings:

The drawings are included to provide a better understanding of the invention and are not to be construed as unduly limiting the invention. Wherein:

FIG. 1 is a flow chart of a method of thread monitoring a third party SDK according to the present invention.

Detailed Description

The present invention will be described in further detail with reference to the accompanying drawings. The detailed description, while indicating exemplary embodiments of the invention, includes various details of the embodiments of the invention for the purpose of illustration only, should be considered as exemplary. Accordingly, those skilled in the art will recognize that various changes and modifications of the embodiments described herein can be made without departing from the scope and spirit of the invention. Also, descriptions of well-known functions and constructions are omitted in the following description for clarity and conciseness.

As shown in fig. 1, the method for performing thread monitoring on the third party SDK according to the present invention includes the following steps:

Compiling an App source code to obtain a Java byte code file (called byte code file for short) which is expanded into class; the App refers to an App based on Java language, and the source code of the App refers to Java source code of the App, and the Java source code is compiled to obtain Java byte code files which are expanded into class;

At least one third party SDK is accessed into the source code of the App;

Traversing Java byte code files through a pre-deployed plugin, and when an instruction (such as THREAD THREAD = NEW THREAD () instruction) for creating a thread by a third-party SDK is found, automatically replacing the instruction with an instruction (such as THREAD THREAD = new ShadowThread () instruction) for creating a shadow thread preset in the plugin, and performing thread monitoring on the third-party SDK by ShadowThread;

Thread monitoring is performed on the third party SDK based on the instruction for creating the shadow thread.

The invention carries out the byte code operation on the application itself and the third party SDK without perception during compiling in a non-invasive way, and monitors the threads of the third party SDK and the application itself by operating the byte code at the bottom layer, thereby realizing the corresponding service scene which helps the application developer to quickly locate the problem;

the compilation supports concurrent compilation.

Based on the above technical solution, the instruction of the third party SDK creation thread is replaced by the instruction of creating the shadow thread, which is implemented by asm bytecode operation, that is: modifying the bytecode based on asm;

the asm is a Java byte code operation framework, and can dynamically check the information of the class, dynamically modify, delete and add the class.

On the basis of the technical scheme, the pre-deployed plugin is a Gradle plugin, is declared as a thread monitoring module, and is uploaded to a Maven warehouse in the form of plugin to finish the pre-deployment;

The Gradle is a framework and is responsible for defining processes and rules, and specific compiling work is completed in a plug-in mode, such as compiling Java with Java plug-ins, compiling Groovy with Groovy plug-ins, compiling Android APP with Android APP plug-ins and compiling Android Library with Android Library plug-ins;

When the instruction of the third-party SDK creating thread is found, the instruction of the third-party SDK creating thread is replaced by the instruction of the shadow thread creating by declaring the mode of introducing the Gradle plugin, and when the program is executed, the instruction of the shadow thread creating completes the operation of initializing the thread monitoring module.

The invention has the access form of Gradle plug-in, only needs to declare to introduce plug-in the application Gradle, gradle provides TransformAPI (application program interface for injecting the operation of the custom class), can take a Java byte code file which is expanded into class of a third party SDK and application itself in the compiling process through inheritance TransformAPI, and can carry out byte code operation on the Java byte code file which is expanded into class in the compiling process by combining asm.

TransformAPI is a newly introduced manner of manipulating the Class, the Transform API acts after compiling, before generating dex, by writing a Transform to receive the compiled Class file, and adding something to the already generated input.

As one of alternative embodiments, other technologies such as non-buried point data acquisition and the like can be extended on the basis of the scheme of the invention.

Based on the technical scheme, the method further comprises the following steps: storing the byte code file with the traversing and replacing operation as a target byte code file;

the target byte code file is sent to a virtual machine jvm, and an interpreter in the virtual machine jvm converts the target byte code file into an executable binary machine code, and the executable binary machine code is stored to obtain an App program;

when the App program is executed, a thread is generated by creating an instruction of the shadow thread, and an interface for acquiring thread information is provided, so that thread monitoring is realized.

The following are specific examples.

Example 1:

Input is obtained using parameters TransformInvocation in the Transform API, while output functions are also obtained, including:

JarInput, corresponding to a third party Jar to be processed, the third party Jar refers to a Jar package of a third party SDK accessed in the source code,

DirectoryInput, corresponding to the class of the application itself,

Read/write is performed through CLASSREADER and CLASSWRITER combined with ClassVisitor;

visitMethod in ClassVisitor is triggered every time a Java function is executed, and we can perform a bytecode operation on a class file to be processed through MethodVisitor, specifically:

byte code replacement operations are performed primarily using calling methods visitMethodInsn (int opcode, string wner, STRING NAME, STRING DESC, byte itf) and byte code instructions VISITTYPEINSN (int opcode, STRING TYPE) with reference type parameters; wherein:

The opcode is an invokespecial and the owner is java/lang/Thread, the name is < init >, which means that a constructor of one Thread is called, the desc is a parameter signature such as () V, (Ljava/lang/Runnable;) V, (Ljava/lang/String;) V, etc., which correspond to a non-parameter construct, an constructor of parameter Runnable and an constructor of parameter String, respectively.

Example 2:

The use procedure is exemplified as follows:

The plug-in is introduced by using a maven warehouse, and specifically comprises the following steps:

instructions to configure the plug-in:

maven{url

'http：//172.17.90.43：8081/repository/kwplugin/

}classpath'cn.kuwo.boxer：thread：1.0.1'

instructions to use the plug-in;

apply plugin：'cn.kuwo.boxer.thread'

Declaring and introducing the plug-in 'cn. Kuwo. Box. Thread' in the Gradle file of the project;

executing a compiling and packing flow, then carrying out asm byte code replacement, and taking over and intervening the compiling process by a plug-in unit to achieve the aim of replacing an object to be monitored;

and generating an executable Android application, and monitoring the states of all threads in the application in real time in the running process.

Example 3:

asm bytecode replacement monitoring thread object

A custom plug-in KwBoxerThreadTransform is registered,

App Extension.register Transform(new KwBoxerThreadTransform(project))；

The plug-in is registered, so that the system can use the plug-in to interfere the compiling process in the compiling process;

The custom plug-in KwBoxerThreadTransform is used in the compilation process,

The following information is set in the compilation configuration:

input type: the Transform manager content CLASS,

The action range is as follows: transform manager. SCOPE_FULL_PROJECT,

Reference scope: transform manager. EMPTY_ SCOPES;

in KwBoxerThreadTransform, a scan Jar Input conversion process or a scan Directory Input conversion process is performed, either of which are used,

Void transform(Transform Invocation transform Invocation)

Jar Input is the form of Input type in Jar package for third party SDKs and the like,

The Directory Input is that the Input type is a Directory type;

For Jar Input, if a third party Jar is not monitored, no special processing is performed on the Input, the output is directly copied,

If a third party Jar needs to be monitored, a Jar Entry (each node in the Jar package) is obtained,

After a Java byte code file is found, class Visitor is constructed, and a modification monitoring object is prepared;

ClassVisitor is a class in the ASM module that provides the ability to browse class files;

For the Directory Input, a Java byte code file is found by scanning the file or the Directory, and Class Visitor is constructed after the Java byte code file is found, so as to prepare to modify the monitoring object;

ClassVisitor is a class in the ASM module that provides the ability to browse class files;

browsing the Class file, searching the thread object in the Class file, directly outputting byte codes if the thread object is not the thread object, and further executing the following operations if the thread object is the thread object:

And (3) constructing MethodVisitor, judging whether the OpCode is a NEW operation and is a thread object through VISITTYPEINSN, if not, directly neglecting and not performing replacement processing, and if yes, performing the following replacement processing:

Automatically replacing the instruction with a preset instruction for creating a shadow thread in the plug-in;

Judging whether the OpCode is an invokespecific and simultaneously satisfying two conditions of thread object and initialization through visitMethodInsn, directly outputting the byte code if the OpCode is not satisfied, replacing the object created by the original thread according to different creation modes of rules to be a monitoring thread if the OpCode is satisfied, and then outputting the byte code;

Executing a file packing process;

And generating an executable Android installation file. Wherein:

MethodVisitor is a class in the asm module that provides functions defined in the browse class;

OpCode is an operator of the Java bytecode map, for example: NEW is the creation object. An invokespecific is a static call, etc.;

VISITTYPEINSN (int opcode, STRING TYPE) is an access type, defined in MethodVisitor, mapped to be invoked when an instruction in Java source code is triggered, for example: NEW THREAD ("a") is transmitted into the OpCode to be NEW, and the type is "java/lang/Thread");

visitMethodInsn (int opcode, string wner, STRING NAME, STRING DESC, bootable itf) is a function call, defined in MethodVisitor, mapped to a trigger in Java source code when a function is called, for example: public Thread (STRING NAME); the Java Thread is a construction function, the receiving parameter is of the String type, the corresponding parameter is opcode INVOKESPECIAL, owner is Java/lang/Thread, name is < init >, and desc is Ljava/lang/String V.

What is not described in detail in this specification is prior art known to those skilled in the art.

The above description is merely of the preferred embodiments of the present invention, the protection scope of the present invention is not limited to the above embodiments, but all equivalent modifications or variations according to the disclosure of the present invention should be included in the protection scope of the claims.

Claims (2)

1. The method for carrying out thread monitoring on the third party SDK is characterized by comprising the following steps:

Compiling an App source code to obtain a Java byte code file expanded into class;

At least one third party SDK is accessed into the source code of the App;

Traversing Java byte code files through a pre-deployed plug-in, and automatically replacing an instruction for creating a shadow thread preset in the plug-in by asm byte code operation when the instruction for creating the thread by the third party SDK is found;

the pre-deployed plugin is a Gradle plugin and is declared as a thread monitoring module, and the thread monitoring module is uploaded to a Maven warehouse in the form of plugins to complete the pre-deployment;

And carrying out thread monitoring on the third party SDK based on the instruction for creating the shadow thread, when the instruction for creating the thread by the third party SDK is found, replacing the instruction for creating the thread by the instruction for creating the shadow thread by declaring a mode of introducing a Gradle plug-in, and completing the operation of initializing the thread monitoring module by the instruction for creating the shadow thread when the program is executed.

2. The method for thread monitoring of a third party SDK of claim 1, further comprising the steps of: storing the byte code file with the traversing and replacing operation as a target byte code file;

the target byte code file is sent to a virtual machine jvm, and an interpreter in the virtual machine jvm converts the target byte code file into an executable binary machine code, and the executable binary machine code is stored to obtain an App program;

when the App program is executed, a thread is generated by creating an instruction of the shadow thread, and an interface for acquiring thread information is provided, so that thread monitoring is realized.