CN110007920B

CN110007920B - Method and device for acquiring code dependency relationship and electronic equipment

Info

Publication number: CN110007920B
Application number: CN201810007488.9A
Authority: CN
Inventors: 肖浩龙
Original assignee: Alibaba Group Holding Ltd
Current assignee: Alibaba Group Holding Ltd
Priority date: 2018-01-04
Filing date: 2018-01-04
Publication date: 2022-07-29
Anticipated expiration: 2038-01-04
Also published as: CN110007920A

Abstract

The application discloses a method and a device for acquiring code dependency relationship and electronic equipment. The method for acquiring the code dependency relationship comprises the following steps: analyzing the byte code file to obtain information of each class and information of each member in the byte code file; determining the calling relation of the method in each class to other methods and the inheritance relation in each class according to the information of each class, and adding a dependency relation among the classes; according to the member information, the access of the member information to the acquired other member information is acquired, and the dependency relationship is added to the member information; the dependencies between persistent classes and the dependencies of the members. According to the technical scheme, the byte code file is subjected to full-dependence scanning, and a hierarchical tree and a dependency graph of a client code layer module/class/method/attribute with multiple dimensions are constructed, so that the dependency relationship of multiple layers is simply and conveniently obtained, and data support is provided for architecture analysis, module reconstruction and quality guarantee.

Description

Method and device for acquiring code dependency relationship and electronic equipment

Technical Field

The application relates to the field of software development, in particular to a method for acquiring code dependency relationship. The scheme also relates to a device for acquiring the code dependency relationship and an electronic device.

Background

At present, with the improvement of the requirement of application software, the volume of client codes is larger and larger, the code scale is increased to hundreds of modules and hundreds of thousands of classes, service developers and system architects are difficult to intuitively obtain the mutual coupling relation between the modules/classes/methods conveniently, and certain thresholds exist for dependence analysis, system design, module marking and the like.

In this context, developers of each module want to conveniently obtain the class and the basic information of each class owned by each module of the whole client, and the modules/classes/methods have a mutual calling relationship, so as to comb out the dependency relationship of products on different dimensions such as modules/classes/methods/attributes.

In the practical application process, obtaining the dependency relationship is realized through an Integrated Development Environment (IDE), such as eclipse, intelij, and the like. The realization mode is that the project source code is imported, and after compiling, the caller of a certain class/method/attribute can be checked through the caller searching function of the IDE.

However, since the number of codes is generally huge, developers generally only have source codes of their own modules, and other modules are black boxes for the source codes, and the current usage mode of the IDE results in that the calling party is only limited to the current module when being searched, and the calling relationship of the whole product cannot be obtained. And therefore, the interdependencies between modules cannot be obtained at the module level.

Disclosure of Invention

The present application provides a method for obtaining code dependency relationship, so as to solve the above problems in the prior art. The application further provides a device for acquiring the code dependency relationship and an electronic device.

The application provides a method for acquiring code dependency relationship, which comprises the following steps:

analyzing the byte code file to obtain information of each class and information of each member in the byte code file;

determining the calling relation of the method in each class to other methods and the inheritance relation in each class based on the information of each class, and adding a dependency relation among each class;

according to the member information, the access of the member information to the acquired other member information is acquired, and a dependency relationship is added to the member information;

Persisting dependencies between the classes and dependencies of the members.

Preferably, the information of the class at least includes:

class name and parent class information.

Preferably, the determining, based on the information of each class, a call relationship of a method in each class to other methods and an inheritance relationship in each class, and adding a dependency relationship between each class includes:

constructing class nodes corresponding to the class information according to the class information;

after the class node is constructed, acquiring the information of a parent class of the class node according to the inheritance relationship in the information of the class;

determining a corresponding parent node based on the information of the parent, and adding a dependency relationship between the class node and the corresponding parent node;

determining the class to which the method called by the class belongs according to the calling relation of the method in the class to other methods;

and acquiring a corresponding class node based on the determined class, and adding a dependency relationship between the class node and the class node corresponding to the called method.

Preferably, after the step of constructing a class node corresponding to the information of the class, the method includes:

And registering the constructed class node to a node warehouse.

Preferably, the determining a corresponding parent node based on the information of the parent includes:

in the node warehouse, searching a corresponding parent node based on the information of the parent;

if the corresponding parent node is found, executing the step of adding the dependency relationship between the class node and the corresponding parent node;

and if the corresponding parent node is not found, a parent listener is established in the class node.

calling back a parent class listener created by the class node;

and if the constructed class node is the class node monitored by the parent class listener, taking the constructed class node as a parent class node, and adding a dependency relationship between the constructed class node and the class node for creating the parent class listener.

Preferably, the parent node includes: class nodes and interface nodes.

Preferably, the member information at least includes:

instructions, method lists, method names, attribute lists, and attribute names.

Preferably, before the step of obtaining the access of the member information to the obtained other member information according to the member information and adding the dependency relationship to the member information, the method includes:

And constructing a method node and an attribute node corresponding to the member information according to the member information.

Preferably, the obtaining, according to each piece of member information, an access of the member information to the obtained other piece of member information, and adding a dependency relationship in each piece of member information includes:

analyzing the instructions in the member information item by item, and determining the types of the instructions;

accessing corresponding member information according to the type of the instruction;

and adding a dependency relationship between the node to which the instruction belongs and the node corresponding to the member information according to the member information accessed by the instruction.

Preferably, the parsing the instruction and determining the type of the instruction includes:

and analyzing the instruction to obtain an operation code, and determining the type of the instruction according to the operation code of the instruction.

Preferably, the member types include: attributes and methods;

accordingly, the determining the type of the instruction includes:

an attribute access instruction and a method call instruction.

Preferably, the accessing the corresponding member information according to the type of the instruction includes:

if the type of the instruction is an attribute access instruction, acquiring an attribute node corresponding to the attribute accessed by the instruction;

And if the type of the instruction is a method calling instruction, acquiring a method node corresponding to the method called by the instruction.

Preferably, the adding a dependency relationship between a node to which the instruction belongs and a node corresponding to the member information according to the member information accessed by the instruction includes:

if the instruction accesses the attribute node, adding an attribute dependency relationship between a method node to which the instruction belongs and the attribute node;

and if the instruction accesses a method node, adding a method dependency relationship between the method node to which the instruction belongs and the method node.

Preferably, after the step of adding the dependency relationship between the node to which the instruction belongs and the node corresponding to the member information, the method includes:

and acquiring class nodes corresponding to the member information accessed by the instruction, and adding class dependency relationship between the acquired class nodes and the class nodes corresponding to the class to which the instruction belongs.

Preferably, after the step of adding a class dependency relationship between class nodes corresponding to classes to which the instruction belongs to the class nodes to be obtained from the class nodes corresponding to the member information accessed by the instruction, the method includes:

Determining a module to which the member information accessed by the instruction belongs, and adding a class dependency relationship between the module and the module to which the instruction belongs.

Preferably, the parsing bytecode file includes:

and analyzing the byte code file based on a preset byte code frame.

Preferably, the persisting the dependencies between the classes and the dependencies of the members includes:

outputting the dependency relationship between the classes in a structure tree mode;

and outputting the dependency relationship between the members in a dependency graph mode.

Preferably, the parsing bytecode file further includes:

acquiring a package name and a configuration list of the byte code file;

accordingly, prior to the step of persisting dependencies between the classes and dependencies of the members, comprising:

and filtering redundant information according to the packet name and the configuration list.

Correspondingly, an embodiment of the present application further provides a device for obtaining a code dependency relationship, where the device for obtaining a code dependency relationship includes:

the file analysis unit is used for analyzing the byte code file and acquiring the information of each class and the information of each member in the byte code file;

The class dependency adding unit is used for determining the calling relation of the method in each class to other methods and the inheritance relation in each class based on the information of each class and adding the dependency relation among the classes;

the method dependence adding unit is used for acquiring the access of the member information to the acquired other member information according to the member information and adding dependence relationship in the member information;

and the persistence unit is used for persisting the dependency relationship among the classes and the dependency relationship of the members.

In addition, an embodiment of the present application further provides an electronic device, including:

a processor;

a memory for storing a code dependent fetch program, which when read and executed by the processor performs the following operations: analyzing the byte code file to obtain information of each class and information of each member in the byte code file; determining the calling relation of the method in each class to other methods and the inheritance relation in each class based on the information of each class, and adding a dependency relation among each class; according to each piece of member information, the access of the member information to other acquired member information is acquired, and a dependency relationship is added to each piece of member information; persisting dependencies between the classes and dependencies of the members.

Compared with the prior art, the method has the following advantages:

according to the method, the device and the electronic equipment for obtaining the code dependency relationship, information of each class and information of each member in a byte code file are obtained by analyzing the byte code file; determining the calling relation of the method in each class to other methods and the inheritance relation in each class based on the information of each class, and adding a dependency relation among each class; according to the member information, the access of the member information to the acquired other member information is acquired, and a dependency relationship is added to the member information; persisting dependencies between the classes and dependencies of the members. According to the technical scheme, the byte code file is subjected to full-dependence scanning, and a hierarchical tree and a dependency graph of a client code layer module/class/method/attribute with multiple dimensions are constructed, so that the dependency relationship of multiple layers is simply and conveniently obtained, and data support is provided for architecture analysis, module reconstruction and quality guarantee.

Drawings

In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the drawings needed to be used in the description of the embodiments or the prior art will be briefly described below, it is obvious that the drawings in the following description are only some embodiments described in the present application, and other drawings can be obtained by those skilled in the art according to the drawings.

FIG. 1 shows a flowchart of a method of obtaining code dependencies, provided according to an embodiment of the present application;

FIG. 2 is a flowchart illustrating determining, based on the information of the classes, a calling relationship of a method in each class to another method and an inheritance relationship in each class, and adding a dependency relationship between the classes, according to an embodiment of the present application;

FIG. 3 illustrates an implementation process for determining, based on the information of the classes, a calling relationship of the methods in the classes to other methods and an inheritance relationship in the classes, and adding a dependency relationship between the classes, according to the embodiment of the present application;

fig. 4 is a flowchart illustrating that, according to the member information, the member information is obtained to access the obtained other member information, and a dependency relationship is added to the member information;

FIG. 5 illustrates a diagram provided in accordance with an embodiment of the present application that outputs dependencies between the classes in a structure tree;

6.1-6.2 illustrate schematic diagrams provided in accordance with embodiments of the present application that output dependencies between the members in the form of a dependency graph;

FIG. 7 is a schematic diagram illustrating an apparatus for obtaining code dependencies, provided in accordance with an embodiment of the present application;

fig. 8 shows a schematic diagram of an electronic device provided in accordance with an embodiment of the application.

Detailed Description

In order that the above objects, features and advantages of the present application can be more clearly understood, the present application will be described in further detail with reference to the accompanying drawings and detailed description. It should be noted that the embodiments and features of the embodiments of the present application may be combined with each other without conflict.

In the following description, numerous specific details are set forth in order to provide a thorough understanding of the present application. This application is capable of implementation in many different ways than those herein set forth and of similar import by those skilled in the art without departing from the spirit and scope of this application, and it is therefore not limited to the specific implementations disclosed below.

The embodiment of the application provides a method for acquiring a code dependency relationship; the embodiment of the application also relates to a device for acquiring the code dependency relationship and an electronic device. Details are described in the following examples one by one.

Currently, in the actual application process, obtaining the dependency relationship is implemented by an Integrated Development Environment (IDE), such as eclipse, intelij, and the like. The realization mode is that the project source code is imported, and after compiling, the caller of a certain class/method/attribute can be checked through the caller searching function of the IDE. However, since the number of codes is generally huge, developers generally only have source codes of their own modules, and other modules are black boxes for the source codes, and the current usage mode of the IDE results in that the calling party is only limited to the current module when being searched, and the calling relationship of the whole product cannot be obtained. And therefore, the interdependencies between modules cannot be obtained at the module level. Aiming at the problem, in the embodiment of the application, the dependency relationship between the classes and the dependency relationship of the method are obtained by analyzing the byte code file according to the inheritance relationship in the information of each class and the access of each member information to other member information, so that the hierarchical tree and the dependency graph of a plurality of dimensions of client code layer modules/classes/methods/attributes are constructed, the dependency relationship of a plurality of layers is simply and conveniently obtained, and data support is provided for architecture analysis, module reconstruction and quality guarantee.

Before describing the specific steps of this embodiment in detail, a brief description will be given to the bytecode file related to this embodiment.

The byte code file is a file formed by byte codes, wherein the byte codes are in an instruction format executed by the Java virtual machine. The bytecode file can be a file generated by compiling Java source code, such as a class file. The class bytecode file has a unified specification, and relevant instructions required by the JVM to run are in the class bytecode file.

Code dependency refers to: the calling and called relation existing on the code level. The execution process of the program is the calling process of the method, and the method calling can cause the object to generate the dependency. "method call" is the most common reason for generating dependency, one object communicates with other objects, communication usually means call with method, call with method means that there is dependency between the two objects, and another common reason for generating dependency is: and (4) inheritance.

Inheritance means that: one concept among object-oriented software technologies, inheritance can cause subclasses to have properties and methods of parent classes or redefine, append properties and methods, etc. If a class A "inherits" from another class B, then A is referred to as a "child of B" and B is referred to as a "parent of A". Inheritance can enable subclasses to have various properties and methods of parent classes without the need to write the same code again.

The embodiment of the application provides a method for acquiring code dependency relationship, and the method for acquiring code dependency relationship acquires the dependency relationship between the classes and the dependency relationship of the method by analyzing byte code files, so that a hierarchical tree and a dependency graph of a client code level module/class/method/attribute with multiple dimensions are constructed. The embodiment of the method for acquiring the code dependency relationship is as follows:

referring to fig. 1, a flowchart of a method for obtaining code dependencies is shown according to an embodiment of the present application.

The method for acquiring the code dependency relationship comprises the following steps:

step S101, analyzing the byte code file, and acquiring the information of each class and the information of each member in the byte code file.

In this embodiment, by parsing the bytecode file, information of each class therein may be acquired, and a method included in the class may also be acquired.

It should be noted that the Java bytecode file is a binary stream of 8-bit bytes. Data items are stored in order in the class file with no space between adjacent items. The Java byte code file contains a plurality of items with different sizes, and the structure of each item is strictly specified, so that the class file can be successfully analyzed from beginning to end. The Constant Pool entry in the class file is used for storing constants such as various character strings, class names, method names, interface names, final variables, reference information to external classes and the like in the classes; the Access flag entry in a class file indicates whether classes or interfaces are defined in the file (only one class or interface in a class file), and also indicates Access flags for the class or interface, such as: public, private, abstrat, etc.; the Methods section describes in detail the Methods declared in a class or interface, such as: name of method, parameter and return value type, etc. It should be noted that the Methods list only stores the Methods in the class or the interface, and does not include Methods inherited from the super class and the parent interface.

In a specific implementation, the Scanner may be used to analyze the Constant Pool entry and the Methods entry of the bytecode file in combination with ASM (Java bytecode manipulation framework), so as to obtain information of each class and each member in the bytecode file.

It should be noted that the ASM framework is a Java bytecode manipulation framework that can be used to dynamically generate classes or enhance the functionality of existing classes. The ASM can either directly generate the binary class file or dynamically change the class behavior before the class is loaded into the Java virtual machine. Java class is stored in a strictly format defined class file, which has enough metadata to parse all the elements in the class: class name, method, attribute, and Java bytecode (instruction). After the ASM framework reads information from the class file, the class behavior can be changed, the information of the class can be analyzed, and even a new class can be generated according to the requirements of users.

In this embodiment, after parsing the bytecode file, a global node repository may be further defined, and is used to store information of each class and information of each member acquired in the bytecode file parsing process.

When the bytecode file is parsed in step S101, the number of the bytecode files may be one, or may be more than one, and in more than one case, this step may sequentially parse each bytecode file, and record the various parsed information in the node repository.

In this embodiment, the bytecode file may be provided by a package file jar or war. Besides, some specific code modules containing byte code files are included, such as: aar, awb.

Step S103, determining the calling relation of the method in each class to other methods and the inheritance relation in each class based on the information of each class, and adding a dependency relation among each class.

In this embodiment, the determining, based on the information of each class, a call relationship of a method in each class to another method and an inheritance relationship in each class, and adding a dependency relationship between each class may be implemented in the following manner: for each class of information, judging whether the class information inherits other classes, if so, taking the class information as a subclass, taking the class inherited by the class information as a parent, and recording the dependency relationship between the subclass and the parent; and judging whether the class calls methods in other classes or not according to the information of each class, and if so, recording the dependency relationship between the class and the class where the called method is located.

It should be noted that in this step, after the bytecode file is parsed, whether the obtained information of each class inherits other classes is determined, so that a dependency relationship is added between the classes.

In this embodiment, the information of the class obtained by parsing the bytecode file at least includes: class name and parent class information. For example: class (class a extensions B) having a keyword extension, information of the class obtained by analysis is: class name a, information B of the parent class; the class without the keyword extensions, the class information obtained after the over-analysis is: the class name C.

In this step, adding a dependency relationship between the classes according to the inheritance relationship in the information of each class may specifically be implemented by the following steps:

referring to fig. 2, a flowchart for determining a calling relationship of a method in each class to other methods and an inheritance relationship in each class based on the information of each class, and adding a dependency relationship between each class is shown according to an embodiment of the present application.

And step S103-1, constructing class nodes corresponding to the class information according to the class information.

In this embodiment, the constructing a class node corresponding to the class information according to the class information may be implemented as follows: and constructing corresponding class nodes according to the information of each class analyzed from the byte code file in the step S101.

It should be noted that, in this step, after a bytecode file generated by compiling a source code is analyzed by an ASM framework, a corresponding class node is constructed for each acquired class information, and the constructed class node already includes information of a parent class and a parent interface.

In this embodiment, the class nodes constructed for each class of information may be registered in a defined node repository. The class node is constructed according to the information of the corresponding class, so the class node can record the relevant information of the class constructing the node, for example: class name and parent class information.

Step S103-2, after the class node is constructed, acquiring the information of the parent class of the class node according to the inheritance relationship in the information of the class.

In this embodiment, the obtaining of the information of the parent class of the class node according to the inheritance relationship in the information of the class may be implemented in the following manner: determining a parent class inherited by the class information according to the inheritance relationship in the class information, and acquiring the parent class information of the class node based on the parent class.

Step S103-3, determining a corresponding parent node based on the information of the parent, and adding a dependency relationship between the class node and the corresponding parent node;

in this embodiment, the determining a corresponding parent node based on the information of the parent, and adding a dependency relationship between the class node and the corresponding parent node may be implemented by: and determining and searching a corresponding parent node based on the information of the parent, and adding a dependency relationship between the class node and the corresponding parent node after the parent node is obtained.

And S103-4, determining the class to which the method called by the class belongs according to the calling relation of the method in the class to other methods.

It should be noted that, in Java code, the dependency relationship between classes is not only an inheritance relationship but also a dependency relationship existing between classes due to inter-call between methods, for example: method a in class a calls method B in class B, the dependencies between classes due to inter-method calls.

Step S103-5, acquiring a corresponding class node based on the determined class, and adding a dependency relationship between the class node and the class node corresponding to the called method.

In this embodiment, the obtaining of the corresponding class node based on the determined class and the adding of the dependency relationship between the class node and the class node corresponding to the called method may be implemented by: based on the determined class information, searching a corresponding class node in a node warehouse through the class name of the class, and after the class node corresponding to the called method is obtained, adding a dependency relationship between the class node and the class node corresponding to the called method.

When determining a corresponding parent node based on the information of the parent, the method may specifically be implemented by the following steps:

In this embodiment, in the node warehouse, the parent node corresponding to the parent node is searched based on the information of the parent, and the following method may be adopted: and searching a parent node with the same name as the parent node in the node warehouse according to the determined class name of the information of the parent.

It will be appreciated that, when this step is executed, the nodes registered in the node repository are all class nodes, and the corresponding parent class nodes searched in this step are essentially class nodes, but the attributes or methods in the class nodes are inherited by other class nodes, so these class nodes are called parent class nodes in order to distinguish the class nodes inherited by other class nodes.

It should be noted that, since the class nodes corresponding to the class information structures are the class nodes corresponding to the class information analyzed from the bytecode file, the class nodes corresponding to the class information structures can be constructed one by one, and therefore, the following two cases can be distinguished according to the order of the class nodes corresponding to the class information structures:

when no parent node exists:

after constructing a corresponding class node according to the class information and registering the class node to a node warehouse, if the current class node is the first constructed class node and has a keyword extensions, then a parent class node is not necessarily arranged in the node warehouse; or the current class node has the keywords extensions, but the class nodes are constructed according to a certain sequence, at this time, the parent class node required by the current class node is not constructed, at this time, a parent class listener for monitoring the parent class node needs to be created in the current class node, and after the corresponding parent class listener is created, the corresponding class node is constructed continuously for the information of other classes analyzed from the byte code file.

When a parent node exists:

and after constructing a corresponding class node according to the class information and registering the class node to a node warehouse, if the current class node finds a corresponding parent class node in the node warehouse, executing the step of adding the dependency relationship between the class node and the corresponding parent class node, and after adding the dependency relationship, continuing constructing the corresponding class node for the information of other classes analyzed from the byte code file.

Specifically, when the corresponding parent node is searched in the node warehouse, the name of the determined parent information can be used to match with each type of node in the node warehouse one by one, and if the matched type node is found, the method is as follows: if the information of the two parties participating in matching is consistent, judging that the searched class node is a required parent class node, and executing the step of adding a dependency relationship between the class node and the corresponding parent class node; correspondingly, if no matched class node is found, the method comprises the following steps: if the node warehouse does not register the class node with the same name as the information of the parent class, judging that the required parent class node is not registered in the node warehouse, and creating a parent class listener in the class node.

For example: the registered class nodes in the node warehouse comprise: if the name of the parent class in the information of the parent class of the current class node A is B, searching the class node named B in a node warehouse, and because the class node B is registered in the node warehouse, taking the current class node A as a subclass and the class node B as a parent class, and adding a dependency relationship between the class node A and the class node B; if the name of the parent class in the information of the parent class of the current class node A is D, searching the class node with the name of D in a node warehouse, and creating a parent class listener for monitoring the class node D in the class node A because the class node D is not registered in the node warehouse.

In this embodiment, since the class nodes are constructed one by one when constructing the class nodes, when constructing a new class node, the class node may be a parent class node of a registered class node, and after constructing each new class node corresponding to the class information in step S103-1, the following steps need to be performed based on the existing parent class listener:

calling back a parent class listener created by the class node;

It should be noted that the listener is actually a class, which implements a specific interface, and can be instantiated at startup to start up the listener. When the state of the scope object changes, then the method in the listener object is automatically invoked.

In this embodiment, the listener may involve the following three objects:

event: an operation on a component, called an event (constructing a new class node)

Event sources: the component where the event occurs is the event source

Event listener (processor): method for monitoring and handling events (adding dependency between the class node of the structure as parent class node and the class node of the parent listener)

It should be noted that, the calling back of the parent class listener created by the class node refers to: when a new class node is constructed, the created parent class listener is invoked.

The implementation of the above steps is described below by way of an example.

Reference is made to fig. 3, which illustrates an implementation process for providing addition of dependencies between classes according to inheritance relationships in information of the classes according to an embodiment of the present application.

In fig. 3, the solid line represents the process of actual processing, and the dotted line represents the process of interaction with the node repository.

The class nodes referred to in the examples are explained below. There may be class node a, class node B and class node C registered in the node repository, and class node a has created a corresponding parent class listener and listened to class node D, and class node D that has not been constructed inherits other class F, while class node E that has not been constructed inherits class C.

The implementation process of adding dependency relationships between classes is described below with reference to fig. 3.

After an initial step is executed, constructing a class node corresponding to the class information according to the class information, and constructing a class node D;

registering the constructed class node D into a node warehouse;

as a new class node is constructed, the parent class listener created by the registered class node in the node warehouse is called back, and as only the class node A creates the corresponding parent class listener, only the parent class listener of the class node A is called back;

because the parent class listener created by the class node A is used for monitoring the class node D, after the class node D is constructed, the parent class listener of the class node A is triggered, so that the class node A is used as a subclass, the class node D is used as a parent class, and a dependency relationship is added between the class node A and the class node D;

Judging whether the class node D inherits other classes according to the inheritance relationship in the constructed class node D;

since the class node D inherits other class F, when the node warehouse is accessed and the corresponding parent class node is searched based on the information of the parent class, a parent class listener for monitoring the class node F is created in the class node D because the class node F cannot be searched;

after the parent class listener is created, because the class information analyzed from the byte code file contains the class information of the class nodes which are not constructed, returning to the initial step and continuously constructing the corresponding class nodes E;

registering the constructed class node E in a node warehouse;

because the parent class listener created by the class node A is used for monitoring the class node D, after the class node E is constructed, the parent class listener is not triggered, and whether other classes are inherited in the class node E is judged directly according to the inheritance relationship in the constructed class node E;

Since the class node E inherits other class C, when the class node E accesses the node warehouse and searches a corresponding parent class node based on the information of the parent class, the class node E is used as a subclass and the class node C is used as a parent class, and a dependency relationship is added between the class node E and the class node C;

and finishing the step of adding the dependency relationship between the classes because class nodes are completely constructed in the class information analyzed from the byte code file.

The process of adding a dependency between the class node and the corresponding parent class node is described below by way of a practical example.

Define a Person class:

defining a Student class inherits the Person class:

since the Student class has the keyword extensions, it is stated that the Student class inherits the Person class, that is: and if the Student class is a subclass and the Person class is a parent class, establishing a dependency relationship between the Student class node and the Person class node in the node warehouse, wherein the dependency relationship depends on the Person class node.

It should be noted that, in addition to the class node as the parent class node, the interface node may also be used as the parent class node. Since the interface can provide a method therein, but does not provide the specific operation of the method, the class is a carrier for the implementation of the interface, i.e. a method defined in the class implementation interface, and the class can implement the interface, and writes the specific implementation of the method in the class, i.e.: the interface can be used as the information of a parent class and can be realized through other classes.

Specifically, when step S103 is executed, the interface information may also be constructed as an interface node, and a dependency relationship is added between the class and the interface according to the implementation relationship between the class node and the interface node. Since the implementation process is similar to that in the above embodiment, specific contents may refer to the above embodiment, and details of the process of adding the dependency relationship between the class and the interface are not repeated here.

The process of adding dependencies between class nodes and interface nodes is illustrated by a practical example below.

Defining an Action interface:

defining a Student class to realize an Action interface:

because the Student class has the keyword instances, the Student class is explained to realize the Action interface, namely: and if the Student class is a subclass and the Action interface is a parent class, establishing a dependency relationship between the Student class node and the Action interface node and the dependency relationship between the Student class node and the Action interface node in the node warehouse.

And step S105, according to each piece of member information, obtaining the access of the member information to the obtained other piece of member information, and adding a dependency relationship in each piece of member information.

In this embodiment, the obtaining of the access of the member information to the obtained other member information according to the member information, and adding the dependency relationship in each member information may be implemented in the following manner: and judging whether the member information accesses the acquired other member information or not aiming at each member information, and if so, adding a dependency relationship between the member information and the member information accessed by the member information.

It should be noted that in this step, after the bytecode file is analyzed, it is determined for each piece of acquired member information whether the type has accessed the acquired other piece of member information, so that a dependency relationship is added to the piece of member information.

In this embodiment, the member information at least includes:

instructions, method lists, method names, attribute lists, and attribute names.

In terms of class structure, the interior of the container may have the following common forms: attributes (including class attributes and instance attributes), methods (including class methods and instance methods), namely: the attributes and methods are contained in classes.

Since the attributes and methods are included in the class, before the step S105 is executed to obtain the access of the member information to the obtained other member information according to each piece of member information, and add a dependency relationship to each piece of member information, a node corresponding to the member information (attributes and methods) needs to be constructed according to each piece of member information, and specifically, when a class node is constructed in the step S103, a node of the attributes and methods in the class is constructed, that is: and constructing corresponding method nodes and attribute nodes.

In this embodiment, after constructing the corresponding method node and attribute node, the method node and attribute node may be registered in the defined node repository. The method node may record relevant information of a method for constructing the node, for example: the name of the method; likewise, the attribute node may record related information for constructing the attribute of the node, such as: an attribute name.

Specifically, the access of the member information to the acquired other member information is acquired according to the member information, and the dependency relationship is added to the member information, which can be implemented in the following manner: the method comprises the steps of traversing each analyzed instruction by analyzing a byte code file, judging the type of the current instruction by an operation code (opcode) of the instruction, and adding a corresponding dependency relationship with member information accessed by a current method execution sequence according to the type of the current instruction.

In this step, the access of the member information to the acquired other member information is acquired according to the member information, and a dependency relationship is added to each member information, which may specifically be implemented by the following steps:

referring to fig. 4, shown is a flowchart illustrating that, according to the member information, the member information is obtained to access the obtained other member information, and a dependency relationship is added to the member information.

Step S105-1, analyzing the instructions in the member information one by one, and determining the types of the instructions.

In this embodiment, the analyzing the instructions in the member information item by item to determine the type of the instruction may be implemented as follows: according to the instruction analyzed from the byte code file in step S101, the operation code of the instruction is determined item by item, thereby determining the type of the instruction.

It is understood that the types of members that the instructions may access include: attributes and methods, so the type of the instruction, for different members accessed by the instruction, includes: an attribute access instruction and a method call instruction.

And step S105-2, accessing corresponding member information according to the type of the instruction.

In this embodiment, the accessing the corresponding member information according to the type of the instruction may be implemented in the following manner: and determining the type of the member to be accessed by the instruction according to the type of the instruction, and searching a corresponding node in a node warehouse for access based on the member type.

It should be noted that, the instruction may search different types of nodes in the node repository for access according to different types. For example:

If the type of the instruction is an attribute access instruction, acquiring an attribute node accessed by the instruction;

and if the type of the instruction is a method calling instruction, acquiring a method node called by the instruction.

For example: if the instruction is a method calling instruction (i.e. the instruction opcode is one of invokestatic, invokevirtual, invokeinterface, invokespecific), the class name, the method name, and the parameter list of the method called by the instruction can be parsed, so as to find out the method node of the method.

It should be noted that, if the current instruction is a method call instruction, then a method node corresponding to the called method is searched from a node repository by analyzing the method name, the parameter list and the return value type of the called method and the class name of the class in which the method is located; in the same way, if the current instruction is an attribute access instruction, the accessed attribute name and the class name of the class where the attribute is located are analyzed, and then the attribute node corresponding to the accessed attribute is searched from the node warehouse.

In particular, when a method node is looked up from the node repository,

matching with each node in a node warehouse one by one through a packet name and a class name of a class where the method is located until a matched class node is found, searching a corresponding method node in a method list of the class node, if the method node cannot be found, searching in a father node of the class node, and continuously backtracking to the father node until the corresponding method node is found; in the same way, when searching for an attribute node from the node repository, a class node is searched for in the node repository according to a package name and a class name of a class in which the attribute is located, after the method node is searched for, a corresponding attribute node is searched for in an attribute list of the class node, if the attribute node cannot be found, the parent node of the class node is searched for, and backtracking is continuously performed to the parent node until the corresponding attribute node is found. For example: the accessed attribute name is in a class A, and if the class A is in a com.alibaba.test, the com.alibaba.test.A is used for searching a class node in a node warehouse, and then an attribute node named as the name is searched in an attribute node list of the class node.

The following describes, by way of an actual example, a process of acquiring a method node called by the instruction if the type of the instruction is a method call instruction.

An Add () method in the Test class is defined:

defining a Student class call Add () method:

since the math and english achievements in the Student class are to be summed, and there is no Add () method in the Student class, an external class Test is defined, and the Add () method that calls the external class Test by the Student class sums the math and english achievements. When the Add () method is called, the Student calls through instantiation of the class, instantiates the class through a new keyword, calls the instantiated class through Sum ═ test.

It can be understood that when the type of the instruction is a method call instruction, the method called by the instruction is an Add () method, so the method node to be acquired in the node warehouse is an Add node.

It should be noted that, when the called method is declared as static, the method in this class may be called directly in other methods, specifically as follows:

defining a Student class call Add () method:

the following describes, by way of an actual example, a process of acquiring an attribute node accessed by the instruction if the type of the instruction is an attribute access instruction.

Defining a Student class access attribute maths:

note that, in the above example, the attribute maths is called by the print method println () and the value of maths is output.

It can be understood that when the type of the instruction is an attribute access instruction, the instruction accesses the attribute maths, so the attribute node to be acquired in the node warehouse is the maths node.

And S105-3, adding a dependency relationship between the node to which the instruction belongs and the node corresponding to the member information according to the member information accessed by the instruction.

In this embodiment, the adding of the dependency relationship between the node to which the instruction belongs and the node corresponding to the member information according to the member information accessed by the instruction may be implemented in the following manner: and searching a node corresponding to the member information needing to be accessed from a node warehouse based on the instruction, and adding a dependency relationship between the node to which the instruction belongs and the acquired node after acquiring the node.

It should be noted that, because the types of the member information accessed by the instruction are different, when the step S105-3 is executed to add the dependency relationship between the instruction and the corresponding member information according to the member information accessed by the instruction, the dependency relationship needs to be added according to the types of the member information, and the method specifically includes the following steps:

If the instruction accesses the attribute node, adding an attribute dependency relationship between the method node to which the instruction belongs and the attribute node;

and if the instruction accesses the method node, adding a method dependency relationship between the method node to which the instruction belongs and the method node.

It should be noted that, because the attribute is called by a method, and the method needs to be included in a class, and when a method in one class calls methods in other classes, because there is a dependency relationship between the classes caused by mutual calling between the methods, after the step S105-3 adds a dependency relationship between the node to which the instruction belongs and the node corresponding to the member information, it is further necessary to determine the dependency relationship between the accessed class node and the class node corresponding to the class to which the instruction belongs, which specifically includes the following steps:

In Java development, classes are encapsulated in a package, one package may contain multiple classes, the package is distributed in corresponding function modules according to needs to implement functions, and one function module may contain a package of multiple functions that the module can implement, so after adding a class dependency between a class to which the instruction belongs and an accessed class node, a module dependency between the module information needs to be added according to module information to which each class belongs, specifically including the following steps:

Determining a module to which the member information accessed by the instruction belongs, and adding a class dependency relationship between the module and the module to which the instruction belongs

It should be noted that the relationship between modules/classes/methods/attributes is that a module includes a class, and a class includes a method/attribute, if an instruction of a certain method a accesses a certain attribute B or method c, the method a where the instruction is located depends on the attribute B/method c, the class a where the method a is located depends on the class B where the attribute B/method c is located, and the module where the class a is located depends on the module where the class B is located.

And step S107, persisting the dependency relationship among the classes and the dependency relationship of the members.

In this embodiment, the persisting the dependency relationship between the classes and the dependency relationship between the members may be implemented as follows: and persistence is carried out on the acquired dependency relationships among the classes and the acquired dependency relationships of the members in a preset mode, and output is carried out.

It should be noted that the persistence is a mechanism for transferring program data between a persistent state and a transient state. That is, transient data (e.g., data in memory that cannot be persisted) is persisted as persistent data (e.g., persisted to a database that can be persisted for long). For example: the objects in the memory are stored in a database, or stored in a disk file, an XML data file, and the like.

In this embodiment, the preset manner is: and outputting the dependency relationship between the classes in a structure tree mode, and outputting the dependency relationship between the members in a dependency graph mode.

The following describes persisting dependencies between the classes and dependencies of the members, still using the above-described practical example.

Please refer to fig. 5, which illustrates a schematic diagram of outputting the dependency relationship between the classes in a structure tree manner according to an embodiment of the present application.

As can be seen from fig. 5, the figure includes: class node student, class node person, interface node action, class node A and class node B.

The class node student comprises a method node and an attribute node, and the method node comprises the following steps: study () and println (), wherein the attribute node comprises: studentNo, maths, english and sum;

the class node person has a property node, and the property node includes: name, age, sex;

the interface node action has a method node, and the method node comprises: eat (), move ();

in fig. 5, a black arrow between a class node student and a class node person represents an inheritance relationship, and the class node student inherits to the class node person; a black arrow between the class node person and the class node A represents an inheritance relationship, and the class node person inherits the class node A; a black arrow between the class node student and the class node B represents an inheritance relationship, and the class node B inherits the class node student; the black arrow between the class node student and the interface node action represents the realization relation, and the class node student realizes the method defined in the interface node action.

It should be noted that, in practical cases, since the number of classes is much larger than that of the classes in fig. 5, the dependency relationship between the complete classes cannot be shown in fig. 5, so that fig. 5 is only schematic.

Please refer to fig. 6.1-6.2, which illustrate schematic diagrams of outputting the dependency relationship between the members in a dependency graph manner according to an embodiment of the present application.

In this embodiment, the dependency graph refers to a logic graph showing the dependency relationship between modules/classes/methods/attributes, and after the persistence, there are two forms:

the first (fig. 6.1) is to describe the dependencies between modules/classes/methods/properties in a plain text way;

the second (fig. 6.2) is to expose the dependencies between modules/classes/methods/attributes in an interactive query through HTML pages.

As a preferred implementation manner, in the method for obtaining code dependency provided in this embodiment of the present application, since a java item often carries redundant information from a library file (JDK/ADK), when persisting the dependency between the classes and the dependency of the members, the redundant information is also persisted, and in order to avoid this, when executing step S101 to parse a bytecode file, a package name and a configuration list of the bytecode file need to be obtained.

After the package name and the configuration list of the bytecode file are obtained, redundant information in the bytecode file can be determined, and the redundant information is filtered according to the package name and the configuration list before the dependency relationship between the classes and the dependency relationship of the members are persisted in step S107.

In the foregoing embodiment, a method for obtaining a code dependency relationship is provided, and the present application also provides a device for obtaining a code dependency relationship, corresponding to the method for obtaining a code dependency relationship. Since the embodiments of the apparatus are substantially similar to the embodiments of the method, they have been described in a relatively simple manner, and reference may be made to the description of the embodiments of the method for relevant points. The device embodiments described below are merely illustrative. The device for acquiring the code dependency relationship comprises the following embodiments:

please refer to fig. 7, which illustrates a schematic diagram of an apparatus for acquiring code dependencies according to an embodiment of the present application.

The device for acquiring the code dependency relationship comprises the following steps: a file parsing unit 701, a class dependency adding unit 703, a method dependency adding unit 705, and a persistence unit 707;

the file parsing unit 701 is configured to parse a byte code file, and obtain information of each class and information of each member in the byte code file;

The class dependency adding unit 703 is configured to determine, based on the information of each class, a call relationship of a method in each class to another method and an inheritance relationship in each class, and add a dependency relationship between each class;

the method dependency adding unit 705 is configured to obtain, according to each piece of member information, access of the piece of member information to the obtained other piece of member information, and add a dependency relationship to each piece of member information;

the persistence unit 707 is configured to persist the dependency relationship between the classes and the dependency relationship of the members.

Optionally, the file parsing unit 701 parses the information of the class obtained by the bytecode file, and at least includes:

class name and parent class information.

Optionally, the class dependency adding unit 703 includes: the system comprises a class node construction subunit, a parent class acquisition subunit, a class dependence adding subunit, a calling class acquisition subunit and a calling class dependence adding subunit;

the class node constructing subunit is used for constructing class nodes corresponding to the class information according to the class information;

the parent class obtaining sub-unit is used for obtaining the parent class information of the class node according to the inheritance relationship in the class information after the class node is constructed;

The class dependency adding subunit is used for determining a corresponding parent class node based on the information of the parent class and adding a dependency relationship between the class node and the corresponding parent class node;

the calling class obtaining subunit is used for determining a class to which the method called by the class belongs according to the calling relation of the method in the class to other methods;

and the calling class dependency adding subunit is used for acquiring a corresponding class node based on the determined class and adding a dependency relationship between the class node and the class node corresponding to the called method.

Optionally, the class dependency adding unit 703 further includes: registering a subunit;

the registration subunit is configured to register the constructed class node to a node repository after the construction of the class node corresponding to the class information.

Optionally, the parent class acquiring subunit includes: the parent node searches for the child unit, the class dependence addition triggering child unit and the listener creation child unit;

the parent node searching subunit is used for searching a corresponding parent node based on the information of the parent in the node warehouse;

the class dependence addition triggering subunit is used for triggering the class dependence addition subunit if the corresponding parent class node is found;

And the listener creating subunit is used for creating a parent listener in the class node if the corresponding parent class node is not found.

Optionally, the class dependency adding unit 703 further includes: a callback subunit and a monitoring subunit;

the callback subunit is configured to, after the class node corresponding to the class information is constructed, call back a parent class listener created by the class node;

and the monitoring subunit is configured to, if the constructed class node is a class node monitored by the parent class listener, add a dependency relationship between the constructed class node as a parent class node and the class node that creates the parent class listener.

Optionally, the parent class obtaining subunit obtains the class node, including: class nodes and interface nodes.

Optionally, the file parsing unit 701 parses the member information obtained by the bytecode file, and at least includes:

instructions, method lists, method names, attribute lists, and attribute names.

Optionally, the apparatus for obtaining a code dependency further includes: a method attribute node construction unit;

the method attribute node constructing unit is configured to, before the access of the member information to the acquired other member information is acquired according to each piece of the member information and a dependency relationship is added to each piece of the member information, construct a method node and an attribute node corresponding to the member information according to each piece of the member information.

Optionally, the method depends on the adding unit 705, including: a type determination subunit, an access subunit, and a method dependent add subunit;

the type determining subunit is configured to analyze the instructions in the member information piece by piece, and determine the types of the instructions;

the access subunit is used for accessing the corresponding member information according to the type of the instruction;

and the method dependence adding subunit is used for adding dependence relationship between the node to which the instruction belongs and the node corresponding to the member information according to the member information accessed by the instruction.

Optionally, the type determining subunit is specifically configured to parse the instruction to obtain an operation code, and determine the type of the instruction according to the operation code of the instruction.

Optionally, the type determining subunit is configured to determine, according to a member type in the member information accessed by the instruction, a member type in the member information, where the member type includes: attributes and methods;

correspondingly, the type determining subunit is specifically configured to determine the type of the instruction according to the member type in the member information accessed by the instruction, and includes: an attribute access instruction and a method call instruction.

Optionally, the accessing subunit includes: the attribute node access subunit and the method node access subunit;

The attribute node access subunit is configured to, if the type of the instruction is an attribute access instruction, obtain an attribute node corresponding to an attribute accessed by the instruction;

and the method node access subunit is used for acquiring a method node corresponding to the method called by the instruction if the type of the instruction is a method calling instruction.

Optionally, the method relies on adding subunits, including: adding an attribute dependent subunit and an addition method dependent subunit;

the attribute dependency adding subunit is configured to add an attribute dependency relationship between a method node to which the instruction belongs and the attribute node if the instruction accesses the attribute node;

and the method adding dependency subunit is configured to add a method dependency relationship between a method node to which the instruction belongs and the method node if the instruction accesses the method node.

Optionally, the method depends on the adding unit 705, and further includes: adding a class dependent subunit;

and the class dependency adding subunit is configured to add, after adding a dependency relationship between a node to which the instruction belongs and a node corresponding to the member information, a dependency relationship between a method node to which the instruction belongs and a class node corresponding to the class according to information of the class to which the instruction belongs.

Optionally, the method depends on the adding unit 705, and further includes: adding inter-class dependency subunits;

and the inter-class dependency adding subunit is configured to, after adding a dependency relationship between a node to which the instruction belongs and a node corresponding to the member information, acquire a class node corresponding to the member information accessed by the instruction, and add a class dependency relationship between the acquired class node and a class node corresponding to the class to which the instruction belongs.

Optionally, the method depends on the adding unit 705, and further includes: adding a module dependent subunit;

the module adding dependency subunit is configured to, after a class dependency relationship is added between class nodes corresponding to the class to which the instruction belongs and the class nodes to which the instruction belongs, determine a module to which the member information to which the instruction belongs, and add a class dependency relationship between the module and the module to which the instruction belongs.

Optionally, the file parsing unit 701 is specifically configured to parse the bytecode file based on a preset bytecode frame.

Optionally, the persistence unit 707 includes: a structure tree output unit and a dependency graph output unit;

The structure tree output unit is used for outputting the dependency relationship among the classes in a structure tree mode;

and the dependency graph output unit is used for outputting the dependency relationship among the members in a dependency graph mode.

Optionally, the file parsing unit 701 includes: a configuration acquisition unit;

the configuration acquisition unit is used for acquiring the package name and the configuration list of the byte code file;

correspondingly, the apparatus for obtaining code dependency further includes: a filtration unit;

and the filtering unit is used for filtering redundant information according to the package name and the configuration list before the dependency relationship between the persistent classes and the dependency relationship of the members.

In the above embodiment, a method and a device for obtaining code dependency relationship are provided, and in addition, an electronic device is also provided in the present application; the electronic equipment comprises the following embodiments:

referring to fig. 8, a schematic diagram of an electronic device provided according to an embodiment of the application is shown.

The electronic device includes: a processor 801; a memory 803;

the memory 803 is used for storing a code dependence acquisition program, and when the program is read and executed by the processor, the program performs the following operations: analyzing the byte code file to obtain information of each class and information of each member in the byte code file; determining the calling relation of the method in each class to other methods and the inheritance relation in each class based on the information of each class, and adding a dependency relation among each class; according to the member information, the access of the member information to the acquired other member information is acquired, and a dependency relationship is added to the member information; persisting dependencies between the classes and dependencies of the members.

For example, the electronic device is a computer, and the computer analyzes the byte code file to obtain information of each class and information of each member in the byte code file; determining the calling relation of the method in each class to other methods and the inheritance relation in each class based on the information of each class, and adding a dependency relation among the classes; then according to each member information, the member information is obtained to access other obtained member information, and a dependency relationship is added to each member information; and finally, persisting the dependency relationship among the classes and the dependency relationship of the members. Because the electronic device uses the method for obtaining the code dependency relationship, please refer to the description of the embodiment of the method for obtaining the code dependency relationship, which is not described herein again.

In a typical configuration, a computing device includes one or more processors (CPUs), input/output interfaces, network interfaces, and memory.

The memory may include forms of volatile memory in a computer readable medium, Random Access Memory (RAM) and/or non-volatile memory, such as Read Only Memory (ROM) or flash memory (flash RAM). Memory is an example of a computer-readable medium.

1. Computer-readable media, including both permanent and non-permanent, removable and non-removable media, may implement the information storage by any method or technology. The information may be computer readable instructions, data structures, modules of a program, or other data. Examples of computer storage media include, but are not limited to, phase change memory (PRAM), Static Random Access Memory (SRAM), Dynamic Random Access Memory (DRAM), other types of Random Access Memory (RAM), Read Only Memory (ROM), Electrically Erasable Programmable Read Only Memory (EEPROM), flash memory or other memory technology, compact disc read only memory (CD-ROM), Digital Versatile Discs (DVD) or other optical storage, magnetic cassettes, magnetic tape magnetic disk storage or other magnetic storage devices, or any other non-transmission medium that can be used to store information that can be accessed by a computing device. As defined herein, computer readable media does not include non-transitory computer readable media (transient media), such as modulated data signals and carrier waves.

2. As will be appreciated by one skilled in the art, embodiments of the present application may be provided as a method, system, or computer program product. Accordingly, the present application may take the form of an entirely hardware embodiment, an entirely software embodiment or an embodiment combining software and hardware aspects. Furthermore, the present application may take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, and the like) having computer-usable program code embodied therein.

Although the present application has been described with reference to the preferred embodiments, it is not intended to limit the present application, and those skilled in the art can make variations and modifications without departing from the spirit and scope of the present application, therefore, the scope of the present application should be determined by the claims that follow.

Claims

1. A method for obtaining code dependencies, comprising:

analyzing a byte code file, and acquiring information of each class and member information in the byte code file, wherein the member information at least comprises: instructions, method lists, method names, attribute lists, and attribute names;

according to the member information, constructing a method node and an attribute node corresponding to the member information, analyzing instructions in the member information one by one, determining the type of the instructions, accessing the corresponding member information according to the type of the instructions, and adding a dependency relationship between the node to which the instructions belong and the node corresponding to the member information according to the member information accessed by the instructions;

Persisting dependencies between the classes and dependencies of the members.

2. The method for obtaining code dependency according to claim 1, wherein the information of the class at least includes:

class name and parent class information.

3. The method for obtaining code dependency according to claim 2, wherein the determining, based on the information of each class, a call relationship of a method in each class to other methods and an inheritance relationship in each class, and adding a dependency between each class includes:

4. The method of claim 3, wherein after the step of constructing a class node corresponding to the class information, the method further comprises:

and registering the constructed class node to a node warehouse.

5. The method of claim 4, wherein determining the corresponding parent node based on the parent information comprises:

6. The method of obtaining code dependencies of claim 5, wherein after the step of constructing class nodes corresponding to the class of information, comprising:

calling back the parent class listener created by the class node based on the class node which has created the parent class listener;

7. The method of claim 6, wherein the parent node comprises: class nodes and interface nodes.

8. The method for obtaining code dependency according to claim 1, wherein the parsing the instruction in the member information and determining the type of the instruction includes:

9. The method of claim 8, wherein the member type comprises: attributes and methods;

accordingly, the determining the type of the instruction includes:

an attribute access instruction and a method call instruction.

10. The method for obtaining code dependency according to claim 8, wherein accessing the corresponding member information according to the type of the instruction comprises:

11. The method for obtaining code dependency according to claim 10, wherein adding a dependency between a node to which the instruction belongs and a node corresponding to the member information according to the member information accessed by the instruction comprises:

12. The method for obtaining code dependency according to claim 11, wherein after the step of adding the dependency between the node to which the instruction belongs and the node corresponding to the member information, the method comprises:

13. The method according to claim 12, wherein after the step of adding a class dependency relationship between class nodes corresponding to classes to which the instruction belongs, the class nodes to be obtained at the class nodes corresponding to the member information accessed by the instruction are obtained, the method comprises:

14. The method of claim 1, wherein parsing the bytecode file comprises:

and analyzing the byte code file based on a preset byte code frame.

15. The method of claim 1, wherein persisting dependencies between classes and dependencies of the members comprises:

16. The method of claim 1, wherein parsing the bytecode file further comprises:

acquiring a package name and a configuration list of the byte code file;

17. An apparatus for obtaining code dependencies, comprising:

The file analysis unit is used for analyzing the byte code file and acquiring the information of each class and the information of each member in the byte code file, wherein the member information at least comprises: instructions, method lists, method names, attribute lists, and attribute names;

the method dependency adding unit is used for constructing method nodes and attribute nodes corresponding to the member information according to the member information, analyzing instructions in the member information one by one, determining the type of the instructions, accessing the corresponding member information according to the type of the instructions, and adding a dependency relationship between the node to which the instructions belong and the node corresponding to the member information according to the member information accessed by the instructions;

18. An electronic device, characterized in that the electronic device comprises:

a processor;

a memory for storing a code dependent fetch program, which when read and executed by the processor performs the following operations: analyzing a byte code file, and acquiring information of each class and member information in the byte code file, wherein the member information at least comprises: instructions, method lists, method names, attribute lists, and attribute names; determining the calling relation of the method in each class to other methods and the inheritance relation in each class based on the information of each class, and adding a dependency relation among each class; constructing a method node and an attribute node corresponding to the member information according to the member information, analyzing instructions in the member information item by item, determining the type of the instructions, accessing the corresponding member information according to the type of the instructions, and adding a dependency relationship between the node to which the instructions belong and the node corresponding to the member information according to the member information accessed by the instructions; persisting dependencies between the classes and dependencies of the members.