CN117850787A

CN117850787A - Dynamic call chain acquisition method and device, electronic equipment and readable storage medium

Info

Publication number: CN117850787A
Application number: CN202211211602.2A
Authority: CN
Inventors: 李安旭; 蒋剑琴; 卢艳梅
Original assignee: Tencent Technology Shenzhen Co Ltd
Current assignee: Tencent Technology Shenzhen Co Ltd
Priority date: 2022-09-30
Filing date: 2022-09-30
Publication date: 2024-04-09

Abstract

The embodiment of the application provides a dynamic call chain acquisition method, a dynamic call chain acquisition device, electronic equipment and a readable storage medium. The method comprises the following steps: compiling the target flutter source code to obtain a corresponding first intermediate product and a corresponding abstract syntax tree; traversing functions and function call relations in the abstract syntax tree, and determining a function call relation and a static call chain corresponding to a life cycle function; inserting corresponding instrumentation codes into code blocks corresponding to each static call chain of the abstract syntax tree to obtain a second intermediate product, and obtaining a dynamic call chain corresponding to the target flutter source code based on the second intermediate product. According to the method, the static call chains corresponding to the function call relations and the static call chains of the life cycle functions in the abstract syntax tree are obtained, the complete dynamic call chains of the target flutter source code are obtained, testing personnel can test all call chains in the target flutter source code, omission is avoided, and therefore performance of an application program corresponding to the target flutter source code is guaranteed.

Description

Dynamic call chain acquisition method and device, electronic equipment and readable storage medium

Technical Field

The present application relates to the field of computer technologies, and in particular, to a method and apparatus for acquiring a dynamic call chain, an electronic device, and a readable storage medium.

Background

flutter is an open-source toolkit for building User Interfaces (UIs), which helps developers to efficiently build multi-platform exquisite application programs through a set of code libraries and supports mobile, web, desktop and embedded platforms. The flutter component is built with modern responsive frameworks, the central idea being to build the UI with components (widgets). Components describe what they display given their current configuration and state. When the component state changes, the component reconstructs its description (description), and the filter compares the previous description to determine the minimum change required by the underlying rendering tree to transition from the current state to the next state.

For the test links of application programs developed by various tools, in order to test each call relation of the application program, a dynamic call chain of a code corresponding to the application program needs to be acquired, but due to the characteristics of the flutter, a dynamic call chain acquisition method for the flutter application program is not available at present.

Disclosure of Invention

The purpose of the present application is to at least solve one of the above technical drawbacks, and the technical solutions provided in the embodiments of the present application are as follows:

in a first aspect, an embodiment of the present application provides a method for acquiring a dynamic call chain, including:

compiling the target flutter source code to obtain a corresponding first intermediate product, and obtaining an abstract syntax tree corresponding to the target flutter source code based on the first intermediate product;

traversing functions and function call relations in the abstract syntax tree, and determining life cycle functions contained in the abstract syntax tree, and a main call function and a called function corresponding to each function call relation;

for each function call relation, determining a static call chain corresponding to the function call relation based on a main call function and a called function corresponding to the function call relation, and for each life cycle function, determining a static call chain corresponding to the life cycle function based on a flutter system-level implicit call link to which the life cycle function belongs, wherein the flutter system-level implicit call link is used for a stateful component in a flutter to call the life cycle function;

inserting corresponding instrumentation codes into code blocks corresponding to each static call chain of the abstract syntax tree to obtain a second intermediate product, and acquiring a dynamic call chain corresponding to the target flutter source code based on the second intermediate product, wherein the instrumentation codes comprise indication information of the corresponding static call chain.

In an alternative embodiment of the present application, determining a lifecycle function contained in an abstract syntax tree comprises:

for each function in the abstract syntax tree, comparing the function with each flutter system level implicit call link, and if the function is contained in any flutter system level implicit call link, determining that the function is a life cycle function.

In an alternative embodiment of the present application, determining a main call function and a called function corresponding to each function call relationship in an abstract syntax tree includes:

for each function call relation, a first node where the function call relation is located and a second node where a call target position corresponding to the function call relation is located are obtained;

in the abstract syntax tree, recursively searching a father node upwards from a first node until a first function to which the first node belongs is acquired, and determining the function as a main call function corresponding to a function call relation; and

and in the abstract syntax tree, recursively searching the father node upwards from the second node until a first function to which the second node belongs is acquired, and determining the function as a called function corresponding to the function call relation.

In an optional embodiment of the present application, determining a static call chain corresponding to a function call relationship based on a main call function and a called function corresponding to the function call relationship includes:

Respectively obtaining function names, classes and file positions of the main call function and the called function, and obtaining a corresponding static call chain;

and determining the links from the function names, the classes and the file positions corresponding to the main call functions to the function names, the classes and the file positions corresponding to the called functions as corresponding static call links.

In an optional embodiment of the present application, a static call chain corresponding to a lifecycle function is determined based on a flutter system level implicit call link to which the lifecycle function belongs:

searching at least one other life cycle function behind the life cycle function in a flutter system level implicit call link to which the life cycle function belongs from a component corresponding to the life cycle function of the abstract syntax tree;

respectively acquiring function names, classes and file positions of the life cycle functions and corresponding function names of other life cycle functions;

and sequentially connecting the function names, the classes and the file positions of the other life cycle functions according to the connection sequence of the other life cycle functions in the flutter system level implicit call link to which the life cycle functions belong, so as to obtain the corresponding static call functions.

In an alternative embodiment of the present application, inserting corresponding instrumentation codes in code blocks corresponding to each static call chain of the abstract syntax tree to obtain a second intermediate product, including:

for each static call chain, if the static call chain comprises static call chains of at least three life cycle functions, the static call chains are sequentially used as a static call chain to be inserted according to the connection sequence, and if the static call chain only comprises two life cycle functions or does not comprise life cycle functions, the static call chain is determined to be the corresponding static call chain to be inserted;

for each static call chain to be inserted, transmitting the static call information to be inserted as corresponding indication information to a preset global instrumentation function to obtain corresponding instrumentation codes, and determining instrumentation positions of the instrumentation codes corresponding to the static call chains to be inserted;

and inserting each pile inserting code into a corresponding pile inserting position to obtain a second intermediate product.

In an alternative embodiment of the present application, determining a instrumentation location of instrumentation code corresponding to a static call chain to be inserted includes:

if the called function corresponding to the static call chain to be inserted is positioned in the code block, determining the position after the code of the previous line of the return statement in the code block as the corresponding pile inserting position;

If the called function is located in a single sentence of the conditional statement of the code block, converting the single sentence into a corresponding sub-code block, and determining the last position of the sub-code block as a corresponding pile inserting position;

if the called function is located in the return statement of the code block, converting the return statement into a corresponding subcode block, creating a first statement which is equal to the temporary variable of the called function and a second statement which returns the temporary variable, and determining the position between the first statement and the second statement as a corresponding instrumentation position.

In an optional embodiment of the present application, obtaining, based on the second intermediate product, a dynamic call chain corresponding to the target flutter source code includes:

converting the second intermediate product into an executable file;

executing the executable file, and determining the static call chain which is executed by the static call chain to be inserted and corresponds to the executed executable file as the dynamic call chain corresponding to the target router source code.

In a second aspect, an embodiment of the present application provides a dynamic call chain acquiring apparatus, including:

the abstract syntax tree acquisition module is used for compiling the target flutter source code to obtain a corresponding first intermediate product, and acquiring an abstract syntax tree corresponding to the target flutter source code based on the first intermediate product;

The abstract syntax tree traversing module is used for traversing functions and function calling relations in the abstract syntax tree and determining life cycle functions contained in the abstract syntax tree, and main call functions and called functions corresponding to the function calling relations;

the static call chain acquisition module is used for determining a static call chain corresponding to the function call relation based on a main call function and a called function corresponding to the function call relation, and determining a static call chain corresponding to the life cycle function based on a flutter system-level implicit call link to which the life cycle function belongs for each life cycle function, wherein the flutter system-level implicit call link is used for a stateful component in flutter to call the life cycle function;

the dynamic call chain acquisition module is used for inserting corresponding instrumentation codes into code blocks corresponding to the static call chains of the abstract syntax tree to obtain a second intermediate product, and acquiring the dynamic call chain corresponding to the target router source code based on the second intermediate product, wherein the instrumentation codes contain indication information of the corresponding static call chains.

In an alternative embodiment of the present application, the abstract syntax tree traversal module is specifically configured to:

In an alternative embodiment of the present application, the static call chain acquisition module is specifically configured to:

and sequentially connecting the function names, the classes and the file positions of the other life cycle functions according to the connection sequence of the other life cycle functions in the flutter system-level implicit call link to which the life cycle functions belong, so as to obtain the corresponding static call link.

In an alternative embodiment of the present application, the dynamic call chain acquisition module is specifically configured to:

In an alternative embodiment of the present application, the dynamic call chain acquisition module is further configured to:

converting the second intermediate product into an executable file;

In a third aspect, embodiments of the present application provide an electronic device including a memory and a processor;

a memory having a computer program stored therein;

a processor for executing a computer program to implement the method provided in the first aspect embodiment or any of the alternative embodiments of the first aspect.

In a fourth aspect, embodiments of the present application provide a computer readable storage medium having a computer program stored thereon, which when executed by a processor implements the method provided in the embodiment of the first aspect or any of the alternative embodiments of the first aspect.

In a fifth aspect, embodiments of the present application provide a computer program product or computer program comprising computer instructions stored in a computer readable storage medium. The computer instructions are read from a computer readable storage medium by a processor of a computer device, which processor executes the computer instructions such that the computer device, when executed, implements the method provided in the embodiment of the first aspect or any alternative embodiment of the first aspect.

The beneficial effects that technical scheme that this application embodiment provided brought are:

through traversing the abstract syntax tree corresponding to the target flutter source code, a main call function and a called function corresponding to each life cycle function and each function call relation contained in the abstract syntax tree are firstly determined, then a corresponding static call chain is determined according to a flutter system-level implicit call link to which each life cycle function belongs, a corresponding static call chain is determined according to the main call function and the called function corresponding to each function call relation, and finally a dynamic call chain corresponding to the target flutter source code is determined by adding instrumentation codes to each static call chain. According to the method, the static call chains corresponding to the function call relations and the static call chains of the life cycle functions in the abstract syntax tree are obtained, the complete dynamic call chains of the target flutter source code are obtained, testing personnel can test all call chains in the target flutter source code, omission is avoided, and therefore performance of an application program corresponding to the target flutter source code is guaranteed.

Drawings

In order to more clearly illustrate the technical solutions in the embodiments of the present application, the drawings that are required to be used in the description of the embodiments of the present application will be briefly described below.

Fig. 1 is a schematic flow chart of a dynamic call chain acquisition method according to an embodiment of the present application;

FIG. 2 is a schematic flow chart of a static call chain for traversing an abstract syntax tree to obtain a function correspondence and a static call chain corresponding to a life cycle function in an example of an embodiment of the application;

FIG. 3 is a life cycle schematic of stateful components in a flutter in one example of an embodiment of the present application;

FIG. 4 is a schematic diagram of a process for obtaining a dominant function, a called function, and related information by using a recursive upward search in an example of an embodiment of the present application;

FIG. 5 is a schematic diagram of a process of obtaining a static call chain corresponding to a function call relationship in an abstract syntax tree in an example of an embodiment of the application;

FIG. 6 is a schematic diagram of a process of obtaining a static call chain corresponding to a lifecycle function in an abstract syntax tree according to an example of an embodiment of the disclosure;

FIG. 7 is a schematic diagram of a process for obtaining a static call chain to be inserted corresponding to the static call chain in an example of an embodiment of the present application;

FIG. 8a is code prior to stake insertion in several situations where the stake insertion location is determined in one example of an embodiment of the application;

FIG. 8b is code after instrumentation in several scenarios of determining the location of instrumentation in one example of an embodiment of the present application;

FIG. 9 is a schematic diagram of a process of acquiring a dynamic call chain in one example of an embodiment of the present application;

FIG. 10 is a block diagram of a dynamic call chain acquisition device according to an embodiment of the present application;

fig. 11 is a schematic structural diagram of an electronic device according to an embodiment of the present application.

Detailed Description

Embodiments of the present application are described below with reference to the drawings in the present application. It should be understood that the embodiments described below with reference to the drawings are exemplary descriptions for explaining the technical solutions of the embodiments of the present application, and the technical solutions of the embodiments of the present application are not limited.

As used herein, the singular forms "a", "an", "the" and "the" are intended to include the plural forms as well, unless expressly stated otherwise, as understood by those skilled in the art. It will be further understood that the terms "comprises" and "comprising," when used in this application, specify the presence of stated features, information, data, steps, operations, elements, and/or components, but do not preclude the presence or addition of other features, information, data, steps, operations, elements, components, and/or groups thereof, all of which may be included in the present application. It will be understood that when an element is referred to as being "connected" or "coupled" to another element, it can be directly connected or coupled to the other element or intervening elements may be present. Further, "connected" or "coupled" as used herein may include wirelessly connected or wirelessly coupled. The term "and/or" as used herein indicates that at least one of the items defined by the term, e.g., "a and/or B" may be implemented as "a", or as "B", or as "a and B".

For the purpose of making the objects, technical solutions and advantages of the present application more apparent, the embodiments of the present application will be described in further detail below with reference to the accompanying drawings.

Several terms which are referred to in this application are first introduced and explained:

dynamic call chain: chained call relationships between dynamically generated functions at program runtime

Ast (Abstract Syntax Tree): an abstract syntax tree is an abstract representation of the source code syntax structure. It contains all the information of the source code, presents the grammar structure of the programming language in the form of a tree, each node on the tree representing a structure in the source code.

Dill (Dart Intermediate Language): the intermediate product compiled by the dart contains definitions and accesses of nodes related to all AST trees, and abstracts programming basic concepts such as types, functions, sentences, statements, expressions and the like into objects. By manipulating the dill file, the entire AST tree may be traversed or new types and functions may be generated, code statements inserted, etc. Dart is an object-oriented, class-defined, single-inherited language, among others.

The technical solutions of the embodiments of the present application and technical effects produced by the technical solutions of the present application are described below by describing several exemplary embodiments. It should be noted that the following embodiments may be referred to, or combined with each other, and the description will not be repeated for the same terms, similar features, similar implementation steps, and the like in different embodiments.

Fig. 1 is a flow chart of a dynamic call chain obtaining method provided in an embodiment of the present application, and as shown in fig. 1, the method may include:

step S101, compiling the target flutter source code to obtain a corresponding first intermediate product, and obtaining an abstract syntax tree corresponding to the target flutter source code based on the first intermediate product.

The target router source code is the source code of an application program to be tested, the application program is developed through a router tool, and a corresponding dynamic call chain is required to be acquired in a test stage for a tester to evaluate. It can be understood that, in the development stage, the target flutter source code dynamic call chain can also be obtained through the scheme provided by the embodiment of the application for evaluation and modification.

The first intermediate product may be a dill file (or app. Dill file) obtained after the intermediate product, where the dill file includes definitions and accesses of nodes related to an abstract syntax tree, and abstracts programming basic concepts such as types, functions, sentences, declarations, expressions and the like into objects, and the abstract syntax tree corresponding to the target flutter source code may be obtained through the dill file.

Specifically, first, a target router source code corresponding to an application program to be tested is acquired, then compiled to obtain a corresponding first intermediate product, and then a corresponding abstract syntax tree is acquired according to information contained in the first intermediate product. And processing the abstract syntax tree by using a call chain instrumentation tool later to further obtain a dynamic call chain corresponding to the target flutter source code.

Step S102, traversing functions and function call relations in the abstract syntax tree, and determining life cycle functions contained in the abstract syntax tree, and a main call function and a called function corresponding to each function call relation.

The abstract syntax tree contains various functions, and the life cycle functions belong to functions in implicit calling relations, and the implicit calling relations are not directly reflected in sentences of codes. In this embodiment of the present application, the life cycle function is a StatefulWidget (stateful component) life cycle function. The display call relationship can be determined by the statement in the code, that is, the function call relationship in the embodiment of the application can be determined by analyzing the statement in the abstract syntax tree.

Specifically, as shown in FIG. 2, the functions in the abstract syntax tree are traversed using a call chain instrumentation tool and a determination is made as to whether each function is a lifecycle function. Specifically, whether each function belongs to a certain implicit call relation is judged, if so, the function is determined to be a life cycle function, and if not, the function is determined not to be a life cycle function. Because the implicit calling relation corresponding to the life cycle function cannot be directly obtained from the code statement, namely the corresponding calling chain (namely the static calling chain) cannot be directly obtained from the abstract syntax tree, the life cycle function in the abstract syntax tree needs to be found out, and then the static calling chain corresponding to the life cycle function is determined independently according to the method provided by the embodiment of the application. The subsequent steps will be described in detail with respect to the acquisition of a static call chain of life cycle functions.

And traversing function call relations in the abstract syntax tree by using a call chain instrumentation tool, namely traversing various display call relations. Specifically, function call relations indicated by each node in the abstract syntax tree are analyzed, a main call function and a called function corresponding to each function call relation are determined according to the position and the structure of the abstract syntax tree corresponding to each node, and the corresponding static call chain can be further determined in the subsequent step by determining the main call function and the called function.

Step S103, for each function call relation, based on the main call function and the called function corresponding to the function call relation, determining a static call chain corresponding to the function call relation, and for each life cycle function, based on the flutter system level implicit call link to which the life cycle function belongs, determining a static call chain corresponding to the life cycle function, wherein the flutter system level implicit call link is used for a stateful component in flutter to call the life cycle function.

The calling relation obtained by carrying out static analysis on the source codes is a static calling chain.

Specifically, the function and the function call relation of the grammar tree are traversed in the last step, the main call function and the called function corresponding to each life cycle function and each function call relation are determined, and then the corresponding static call chain is further determined, namely the static call chain corresponding to each life cycle function and the static call chain corresponding to each function call relation are determined respectively.

Specifically, for the determined function call relationship, the corresponding main call function and the called function are determined in the process of traversing the abstract syntax tree, so that corresponding information of the main call function and the called function can be further determined according to the positions of corresponding nodes of the main call function and the called function in the abstract syntax tree and the structure of the abstract syntax tree, and further, a corresponding static call chain is determined and recorded according to the information.

In addition, the life cycle of flutter can be divided into two types: statefulwidgets and stateless widgets. They are two basic components of flutter, the names of which indicate the functions of the two components: stateful and stateless.

The stateless widget is a stateless component, and its life cycle has only one build function, i.e. it is rendered only once for the stateless widget, after which it does not change any more. Because the stateless component has only one build stage in the execution process, only one build function is executed during the execution process, and no other life cycle functions exist. Thus, it can be understood that stateleswidgets do not have an implicit call.

However, statefulwidgets include a series of lifecycles, as shown in fig. 3, which may include the following stages (arrow mark call in the figure):

createState function: the function is a method for creating State for the statefulWidget, and the stateWidget can immediately execute the createState function when called.

initState function: the function is a State initialization call, so that initial assignment of all variables of the State can be executed in the period, meanwhile, interaction with a server side can be performed in the period, and the setState function is called to set the State after the data of the server side are acquired.

DidChangeDependencies function: the function is that State is a global State, such as language or theme, when the State that the component depends on changes.

build function: the method mainly returns the Widget (component) to be rendered, and because the build function can be called for a plurality of times, only the Widget related logic can be returned in the function, and the state exception caused by the execution for a plurality of times is avoided.

The reassemble function: the method mainly provides a development stage to use, and in the debug mode, the function is called each time the function is subjected to hot reloading, so that some debug codes can be added in the debug stage to check code problems.

The didupdate Widget function: the function is mainly that under the condition that a component is reconstructed, such as a hot reload, and a father component is built, a child component can be called the method, and the built method in the component can be called after the method is called.

deactivate function: the function is invoked after the component is removed from the node, and if the component is removed from the node and then not inserted into other nodes, the immediate function is invoked for permanent removal.

dispose function: this function is used to permanently remove the component and release the component resources.

In addition, in stateleswidgets, as long as setState is called, redrawing is performed, that is, the build function is re-executed, so that the UI can be changed.

In summary, the build function is called each time the UI interface is refreshed, and the callback of the build function may be caused by two situations of initialization or state update. In other words, for a series of life cycles contained in the statefulwidgets, there may be multiple implicit call relationships in the component, that is, there are multiple implicit calls to the build function, and in order to obtain a complete dynamic call chain of the target flutter source code, in this embodiment of the present application, the call chain corresponding to the part of implicit call is also completed. Specifically, the following implicit call links may exist in statefulwidgets:

(1) Initializing: the structure is- > initState- > didchchange dependencies- > build;

(2) And (5) updating the state: setState- > build, didUpdateWidget- > build.

These implicit call lines may also be referred to as flutter system level implicit call links.

Then, the lifecycle function determined after traversing the abstract syntax tree in the previous step may further determine a component where the lifecycle function is located, and store each lifecycle function belonging to the same component, for example, store the structor function belonging to a StatefulWidget, initState, and didchhange dependencies under the same storage path.

Further, after determining the life cycle function, determining the implicit call relationship to which the life cycle function belongs, and determining the implicit call link of the corresponding flutter system level in practice, and then determining the static call chain of the life cycle function according to the position of the implicit call link of the life cycle function in the corresponding flutter system level and other life cycle functions contained in the implicit call link of the corresponding flutter system level.

Step S104, inserting corresponding instrumentation codes into code blocks corresponding to the static call chains of the abstract syntax tree to obtain a second intermediate product, and acquiring dynamic call chains corresponding to the target router source codes based on the second intermediate product, wherein the instrumentation codes comprise indication information of the corresponding static call chains.

The instrumentation code is executable code, and includes indication information of corresponding static call chains.

Specifically, the static call chain corresponding to each life cycle function and the static call chain corresponding to each function call relationship in the abstract syntax tree determined in the previous step are not necessarily the final dynamic call chain, that is, are not necessarily executed when the executable file corresponding to the target router source code is executed. Thus, to determine which static call chains are executed, corresponding instrumentation code may be added to none of the static call chains to determine whether the corresponding static call chains are executed and, in turn, which static call chains are dynamic call chains.

According to the scheme, through traversing the abstract syntax tree corresponding to the target router source code, the main call function and the called function corresponding to each life cycle function and each function call relation contained in the abstract syntax tree are firstly determined, then the corresponding static call chain is determined according to the router system-level implicit call link to which each life cycle function belongs, the corresponding static call chain is determined according to the main call function and the called function corresponding to each function call relation, and finally the dynamic call chain corresponding to the target router source code is determined in a mode of adding the instrumentation code for each static call chain. According to the method, the static call chains corresponding to the function call relations and the static call chains of the life cycle functions in the abstract syntax tree are obtained, the complete dynamic call chains of the target flutter source code are obtained, testing personnel can test all call chains in the target flutter source code, omission is avoided, and therefore performance of an application program corresponding to the target flutter source code is guaranteed.

Among them, in the flutter, there may be a plurality of flutter system level implicit call links, for example, the flutter system level implicit call link corresponding to "initialization" and the flutter system level implicit call link corresponding to "state update" in the statefulwidgets mentioned above. Of course, it can be understood that more implicit call links of the system level of the router may be predefined according to different requirements in the router, which may not be limited in the embodiment of the present application.

Specifically, function names of functions contained in each router system level implicit call link class are obtained in advance. When the abstract syntax tree is traversed by using the call chain instrumentation tool, each function in the abstract syntax tree can be traversed through the visitprocesse function, and the function name of each function is recorded (the class and the file location of each function can also be recorded). And comparing the obtained function name of each function with the function names contained in the implicit call links of the flutter system levels, if the function name of the function is contained in a certain implicit call link of the flutter system level, determining that the function is a life cycle function, and if the function name of the function is not contained in any implicit call link of the flutter system level, determining that the function is not a life cycle function. For example, a function traversed to a function is named a constructor, which is included in the "constructor- > initState- > didchchange dependencies- > build" link of the implicit call at the flutter system level, so the function is determined to be a lifecycle function, and the function belongs to the "initialization" flutter system level implicit call link.

Further, after the life cycle function is obtained, the component to which the life cycle function belongs, that is, which statefulwidgets the life cycle function belongs, may be further determined, and the function name, the class and the file location corresponding to the life cycle function are stored together in the storage path corresponding to the statefulwidgets. In other words, all the storage paths corresponding to the statefulwidgets store life cycle functions belonging to the statefulwidgets.

Specifically, in the process of traversing the abstract syntax tree by using the call chain instrumentation tool, the abstract syntax tree analysis library provides a plurality of methods for traversing function call relations, and a visittConstructor solicitation method, a visittStaticsolicitation method and a visittMethodsolicitation method can be adopted to respectively traverse call relations of constructional functions, call relations of static functions and call relations of common method functions in the syntax tree.

After the function call relation is obtained through traversing, it is obvious that the node (i.e. the first node) where the function call relation is located in the abstract syntax tree is located in the main call function, and then the corresponding main call function can be found by recursively searching the parent node upwards. Meanwhile, the target position (corresponding to the second node) of the call indicated by the function call relation is located in the called function, so that the corresponding called function can be found by recursively searching the parent node upwards.

Specifically, as shown in fig. 4, when any node (the first node or the second node) performs a recursive upward search for a parent node, each time a parent node immediately preceding the node is found, it is determined whether the parent node corresponds to a function, and if the parent node corresponds to a function, the corresponding function is determined to be a corresponding major function, in other words, the first function to which the first node belongs is determined to be a corresponding major function (or a tuned function). Meanwhile, a parent node is searched upwards in a recursion mode, a first class (class) and a first file position of the node are obtained, the first class is determined to be the class where a corresponding main call function (or called function) is located, and the file position is determined to be the file position where the corresponding main call function (or called function) is located. And finally, recording the function name, the class and the file position of the main call function corresponding to each function call relation, and the function name, the class and the file position of the corresponding called function.

Specifically, as shown in fig. 5, in the foregoing embodiment, the main call function and the called function corresponding to each function call relationship have been acquired and recorded, and the function names, the classes, and the file locations of the main call function and the called function corresponding to each function call relationship. Then, the links from the function name corresponding to the main call function, the class and the file position corresponding to the called function to the function name corresponding to the class and the file position corresponding to the called function can be determined as the corresponding static call chains. For example, a main call function corresponding to a certain function call relationship is a, a called function is B, a function name corresponding to a, a class corresponding to a and a file position corresponding to a is respectively denoted as "AFunc", "AClass" and "AFile", a function name corresponding to B, a class corresponding to a and a file position corresponding to a location are respectively denoted as "BFunc", "BClass" and "BFile", and then a static call link corresponding to the function call relationship may be denoted as "AFile:: AClass:::: AFunc- > BFile::: BClass: BFunc).

Specifically, as shown in fig. 6, in the process of traversing the abstract syntax tree, after a certain function is determined to be a life cycle function, a flutter system level implicit call link to which the life cycle function belongs and a component to which the life cycle function belongs are determined. Then, one or more other lifecycle functions following the lifecycle function in the belonging flutter system level implicit call link may be determined. Since the determined life cycle functions are all stored according to the belonged components when traversing each function of the abstract syntax tree. Then, it may be searched in the storage path corresponding to the component to which the lifecycle function belongs to determine whether one or more other lifecycle functions following the lifecycle function exist. If one or more other life cycle functions exist, function names, classes and file positions of the life cycle functions are connected in sequence according to the connection sequence of the life cycle functions in the flutter system level implicit call link to which the life cycle functions belong, and the function names, the classes and the file positions of the life cycle functions are connected in sequence, so that corresponding static call functions are obtained. If no other life cycle function exists, the life cycle function is indicated to have no corresponding static call chain.

For example, for a certain life cycle function, the link of the implicit call of the router system level to which the function belongs is "structor- > initState- > didchhange dependencies- > building", the life cycle function is "structor", and other life cycle functions after the "structor" are "initState", "didchhange dependencies" and "building". Then, find whether these other lifecycle functions exist in the component corresponding to the lifecycle function "constructor", for example, if two other lifecycle functions, "didchchange dependencies" and "build" exist, construct the corresponding static call chain as "constructor- > didchchange dependencies- > build according to their order in the corresponding flutter system-level implicit call link. If one life cycle function of "build" exists, the corresponding static call chain is constructed as "constructor- > build", and if the other life cycle functions do not exist, the corresponding static call chain does not exist in the life cycle function "constructor". Of course, the "constructor- > didchchange dependencies- > building" type indicates that the function name is recorded, and may also include the class where each life cycle function corresponds to and the file location where each life cycle function corresponds to, where these information are recorded in the corresponding component.

Specifically, as shown in fig. 7, as to the function call relationship in the abstract syntax tree, the corresponding static call chain includes only one main call function and one called function, and as to the life cycle function in the abstract syntax tree, the corresponding static call chain may include two, three or more life cycle functions. Then, for a static call chain containing three or more lifecycle functions, before determining its corresponding instrumentation code and instrumentation location, it needs to be split to obtain multiple static call chains to be inserted. For static call chains containing only two life cycle functions and static call chains corresponding to function call relationships, the static call chains can be directly determined as corresponding static call chains to be inserted.

For example, a static call chain including three life cycle functions is denoted as "constructor- > didchhange dependencies- > build", and then before determining its corresponding instrumentation code and instrumentation location, it needs to be split to obtain the corresponding static call chain to be inserted. Specifically, according to the connection sequence of the static call chains, two adjacent lifecycle functions are used as one static call chain to be inserted, and then obtaining the corresponding static call chain to be inserted includes: "Constructor- > DidCondugDependencies (where the dominant function is a structor and the tuned function is a didCodCondugDependencies)" and "DidCondugDependencies- > building (where the dominant function is a didCodCondugDependencies and the tuned function is a building)".

After determining the static call chains to be inserted corresponding to the static call chains, the instrumentation codes and the instrumentation positions of the static call chains to be inserted need to be determined. Specifically, static call information to be inserted is used as corresponding indication information to be transmitted to a preset global instrumentation function, and corresponding instrumentation codes are obtained. For example, for a static call chain to be inserted "AFile:: AClass:: AFunc- > BFIle:: BClass: BFUNC", it is passed as indication information to a preset global instrumentation function (which may be a predefined global static function) static int updateChain (String singleChain), resulting in a corresponding instrumentation code of static int updateChain (AFile:: AClass:: AFunc- > BFIle: BClass: BFUNC). Meanwhile, the pile inserting position of the static call chain to be inserted needs to be determined. And finally, inserting each pile inserting code into a corresponding pile inserting position to obtain a corresponding second intermediate product.

Specifically, the insertion of the corresponding instrumentation code in the static call chain is to record when the static call chain is executed. In other words, if the corresponding instrumentation code inserted in the static call chain is executed, indicating that the static call chain is also executed, then the static call chain is the corresponding dynamic call chain. Then, considering the situation that a crash may be encountered, the determination of the instrumentation location needs to ensure that the called function to be inserted into the static call chain is executed before recording that the static call chain is executed. 8a-8b, then, the determination of the pile placement location may generally include a focus scenario:

Case1 (case 1): inserting a modulated function funcB corresponding to the static call chain to be inserted into a code block (block), namely inserting an inserted code ' insert_chain ' (funcA- > funcB ') at the last position of a code of a previous line of a return statement in the code block; wherein, the function A is a main call function, and the inserted static call link indication information can be 'function A- > function B', or 'AFile::: AClass:: AFunc- > BFIle::: BClass: BFUNC';

case2 (case 2): in a single statement of which the function funcB is a conditional (if) statement, firstly converting the single statement into a code block (namely a sub-code block), and then inserting a stake in the last of the code block, namely inserting a stake inserting code of insert_chain ("funcA- > funcB");

case3 (case 3): in a return (return) statement, the return statement needs to be converted into a code block (i.e. a sub-code block), then a temporary variable is newly built to be equal to the return value of the funB, then the statement covered by the call chain is added (i.e. the instrumentation code is added for instrumentation, i.e. the instrumentation code "insert_chain" is inserted, and finally the temporary variable is returned.

Converting the second intermediate product into an executable file;

Specifically, after the second intermediate product corresponding to the target router source code is obtained, the second intermediate product is converted into an executable file, and the executable file contains instrumentation codes. Executing the executable file, if the static call chain in the executable file is executed correspondingly, then the corresponding instrumentation code is executed, and further, whether the static call chain is executed is judged by whether the instrumentation code of each static call chain is executed or not, and the executed static call chain is determined to be the dynamic call chain corresponding to the target flutter source code. Thus, the dynamic call chain corresponding to the target flutter source code is obtained.

The process of obtaining the dynamic call chain corresponding to the flutter source code in the embodiment of the present application will be described in detail by way of an example, and as shown in fig. 9, the obtaining process may include the following steps:

(1) Compiling a target flutter source code to obtain a corresponding intermediate product app.dil (namely a first intermediate product), and obtaining an abstract syntax tree corresponding to the intermediate product;

(2) Traversing the abstract grammar number by calling a chain instrumentation tool, wherein the traversing process needs to determine a life cycle function in an abstract grammar tree and determine a static call chain corresponding to the life cycle function; determining a main call function and a called function corresponding to a function call relation in an abstract syntax tree, and determining a static call chain corresponding to the function call relation; then, inserting corresponding instrumentation codes at instrumentation positions in code blocks corresponding to each static call chain;

(3) The corresponding modified intermediate product app.dill (namely a second intermediate product) can be further obtained according to the abstract syntax tree after inserting the instrumentation code;

(4) Converting the modified intermediate product into a corresponding executable file;

(5) Executing the executable file and recording the corresponding dynamic call chain.

Fig. 10 is a block diagram of a dynamic call chain obtaining apparatus according to an embodiment of the present application, and as shown in fig. 10, the apparatus 1000 may include: an abstract syntax tree acquisition module 1001, an abstract syntax tree traversal module 1002, a static call chain acquisition module 1003, and 1004. Wherein:

the abstract syntax tree obtaining module 1001 is configured to compile a target flutter source code to obtain a corresponding first intermediate product, and obtain an abstract syntax tree corresponding to the target flutter source code based on the first intermediate product;

The abstract syntax tree traversing module 1002 is configured to traverse functions and function call relationships in the abstract syntax tree, and determine a life cycle function and a main call function and a called function corresponding to each function call relationship contained in the abstract syntax tree;

the static call chain acquisition module 1003 is configured to determine, for each function call relationship, a static call chain corresponding to the function call relationship based on a main call function and a called function corresponding to the function call relationship, and determine, for each life cycle function, a static call chain corresponding to the life cycle function based on a flutter system level implicit call link to which the life cycle function belongs, where the flutter system level implicit call link is used for a stateful component in flutter to call the life cycle function;

the dynamic call chain obtaining module 1004 is configured to insert corresponding instrumentation codes into code blocks corresponding to each static call chain of the abstract syntax tree, obtain a second intermediate product, and obtain a dynamic call chain corresponding to the target router source code based on the second intermediate product, where the instrumentation codes include indication information of the corresponding static call chain.

converting the second intermediate product into an executable file;

Referring now to fig. 11, there is illustrated a schematic diagram of an architecture of an electronic device 1100 (e.g., a terminal device or server performing the method illustrated in fig. 1) suitable for use in implementing embodiments of the present application. The electronic devices in the embodiments of the present application may include, but are not limited to, mobile terminals such as mobile phones, notebook computers, digital broadcast receivers, PDAs (personal digital assistants), PADs (tablet computers), PMPs (portable multimedia players), in-vehicle terminals (e.g., in-vehicle navigation terminals), wearable devices, and the like, and stationary terminals such as digital TVs, desktop computers, and the like. The electronic device shown in fig. 11 is only an example, and should not impose any limitation on the functionality and scope of use of the embodiments of the present application.

An electronic device includes: the memory is used for storing programs for executing the methods according to the method embodiments; the processor is configured to execute a program stored in the memory. Herein, the processor may be referred to as a processing device 1101, and the memory may include at least one of a Read Only Memory (ROM) 1102, a Random Access Memory (RAM) 1103, and a storage device 1108, as follows:

as shown in fig. 11, the electronic device 1100 may include a processing means (e.g., a central processor, a graphics processor, etc.) 1101 that may perform various appropriate actions and processes according to a program stored in a Read Only Memory (ROM) 1102 or a program loaded from a storage means 1108 into a Random Access Memory (RAM) 1103. In the RAM1103, various programs and data necessary for the operation of the electronic device 1100 are also stored. The processing device 1101, ROM 1102, and RAM1103 are connected to each other by a bus 1104. An input/output (I/O) interface 1105 is also connected to bus 1104.

In general, the following devices may be connected to the I/O interface 1105: input devices 1106 including, for example, a touch screen, touchpad, keyboard, mouse, camera, microphone, accelerometer, gyroscope, and the like; an output device 1107 including, for example, a Liquid Crystal Display (LCD), a speaker, a vibrator, and the like; storage 1108, including for example, magnetic tape, hard disk, etc.; and a communication device 1109. The communication means 1109 may allow the electronic device 1100 to communicate wirelessly or by wire with other devices to exchange data. While fig. 11 shows an electronic device having various means, it is to be understood that not all of the illustrated means are required to be implemented or provided. More or fewer devices may be implemented or provided instead.

In particular, according to embodiments of the present application, the processes described above with reference to flowcharts may be implemented as computer software programs. For example, embodiments of the present application include a computer program product comprising a computer program embodied on a non-transitory computer readable medium, the computer program comprising program code for performing the method shown in the flow chart. In such an embodiment, the computer program may be downloaded and installed from a network via communications device 1109, or from storage device 1108, or from ROM 1102. The above-described functions defined in the methods of the embodiments of the present application are performed when the computer program is executed by the processing means 1101.

It should be noted that the computer readable storage medium described in the present application may be a computer readable signal medium or a computer readable storage medium, or any combination of the two. The computer readable storage medium can be, for example, but not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or a combination of any of the foregoing. More specific examples of the computer-readable storage medium may include, but are not limited to: an electrical connection having one or more wires, a portable computer diskette, a hard disk, a Random Access Memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disc read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing. In the context of this document, a computer readable storage medium may be any tangible medium that can contain, or store a program for use by or in connection with an instruction execution system, apparatus, or device. In the present application, however, a computer-readable signal medium may include a data signal that propagates in baseband or as part of a carrier wave, with the computer-readable program code embodied therein. Such a propagated data signal may take any of a variety of forms, including, but not limited to, electro-magnetic, optical, or any suitable combination of the foregoing. A computer readable signal medium may also be any computer readable medium that is not a computer readable storage medium and that can communicate, propagate, or transport a program for use by or in connection with an instruction execution system, apparatus, or device. Program code embodied on a computer readable medium may be transmitted using any appropriate medium, including but not limited to: electrical wires, fiber optic cables, RF (radio frequency), and the like, or any suitable combination of the foregoing.

In some implementations, the clients, servers may communicate using any currently known or future developed network protocol, such as HTTP (HyperText Transfer Protocol ), and may be interconnected with any form or medium of digital data communication (e.g., a communication network). Examples of communication networks include a local area network ("LAN"), a wide area network ("WAN"), the internet (e.g., the internet), and peer-to-peer networks (e.g., ad hoc peer-to-peer networks), as well as any currently known or future developed networks.

The computer readable medium may be contained in the electronic device; or may exist alone without being incorporated into the electronic device.

The computer readable medium carries one or more programs which, when executed by the electronic device, cause the electronic device to:

compiling the target flutter source code to obtain a corresponding first intermediate product, and obtaining an abstract syntax tree corresponding to the target flutter source code based on the first intermediate product; traversing functions and function call relations in the abstract syntax tree, and determining life cycle functions contained in the abstract syntax tree, and a main call function and a called function corresponding to each function call relation; for each function call relation, determining a static call chain corresponding to the function call relation based on a main call function and a called function corresponding to the function call relation, and for each life cycle function, determining a static call chain corresponding to the life cycle function based on a flutter system-level implicit call link to which the life cycle function belongs, wherein the flutter system-level implicit call link is used for a stateful component in a flutter to call the life cycle function; inserting corresponding instrumentation codes into code blocks corresponding to each static call chain of the abstract syntax tree to obtain a second intermediate product, and acquiring a dynamic call chain corresponding to the target flutter source code based on the second intermediate product, wherein the instrumentation codes comprise indication information of the corresponding static call chain.

Computer program code for carrying out operations of the present application may be written in one or more programming languages, including, but not limited to, an object oriented programming language such as Java, smalltalk, C ++ and conventional procedural programming languages, such as the "C" programming language or similar programming languages. The program code may execute entirely on the user's computer, partly on the user's computer, as a stand-alone software package, partly on the user's computer and partly on a remote computer or entirely on the remote computer or server. In the case of a remote computer, the remote computer may be connected to the user's computer through any kind of network, including a Local Area Network (LAN) or a Wide Area Network (WAN), or may be connected to an external computer (for example, through the Internet using an Internet service provider).

The flowcharts and block diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods and computer program products according to various embodiments of the present application. In this regard, each block in the flowchart or block diagrams may represent a module, segment, or portion of code, which comprises one or more executable instructions for implementing the specified logical function(s). It should also be noted that, in some alternative implementations, the functions noted in the block may occur out of the order noted in the figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved. It will also be noted that each block of the block diagrams and/or flowchart illustration, and combinations of blocks in the block diagrams and/or flowchart illustration, can be implemented by special purpose hardware-based systems which perform the specified functions or acts, or combinations of special purpose hardware and computer instructions.

The modules or units involved in the embodiments of the present application may be implemented by software, or may be implemented by hardware. Where the name of the module or unit does not constitute a limitation of the unit itself in some cases, for example, the first constraint acquisition module may also be described as "a module that acquires the first constraint".

The functions described above herein may be performed, at least in part, by one or more hardware logic components. For example, without limitation, exemplary types of hardware logic components that may be used include: a Field Programmable Gate Array (FPGA), an Application Specific Integrated Circuit (ASIC), an Application Specific Standard Product (ASSP), a system on a chip (SOC), a Complex Programmable Logic Device (CPLD), and the like.

In the context of this application, a machine-readable medium may be a tangible medium that can contain, or store a program for use by or in connection with an instruction execution system, apparatus, or device. The machine-readable medium may be a machine-readable signal medium or a machine-readable storage medium. The machine-readable medium may include, but is not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any suitable combination of the foregoing. More specific examples of a machine-readable storage medium would include an electrical connection based on one or more wires, a portable computer diskette, a hard disk, a Random Access Memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disc read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing.

Embodiments of the present application provide a computer program product or computer program comprising computer instructions stored in a computer readable storage medium. The processor of the computer device reads the computer instructions from the computer readable storage medium, and the processor executes the computer instructions such that the computer device performs:

It should be understood that, although the steps in the flowcharts of the figures are shown in order as indicated by the arrows, these steps are not necessarily performed in order as indicated by the arrows. The steps are not strictly limited in order and may be performed in other orders, unless explicitly stated herein. Moreover, at least some of the steps in the flowcharts of the figures may include a plurality of sub-steps or stages that are not necessarily performed at the same time, but may be performed at different times, the order of their execution not necessarily being sequential, but may be performed in turn or alternately with other steps or at least a portion of the other steps or stages.

The foregoing is only a partial embodiment of the present invention, and it should be noted that it will be apparent to those skilled in the art that modifications and adaptations can be made without departing from the principles of the present invention, and such modifications and adaptations are intended to be comprehended within the scope of the present invention.

Claims

1. A method for dynamically invoking a chain acquisition, comprising:

compiling a target flutter source code to obtain a corresponding first intermediate product, and acquiring an abstract syntax tree corresponding to the target flutter source code based on the first intermediate product;

for each function call relation, determining a static call chain corresponding to the function call relation based on a main call function and a called function corresponding to the function call relation, and for each life cycle function, determining a static call chain corresponding to the life cycle function based on a flutter system-level implicit call link to which the life cycle function belongs, wherein the flutter system-level implicit call link is used for calling the life cycle function by a stateful component in flutter;

inserting corresponding instrumentation codes into code blocks corresponding to each static call chain of the abstract syntax tree to obtain a second intermediate product, and acquiring a dynamic call chain corresponding to the target router source code based on the second intermediate product, wherein the instrumentation codes comprise indication information of the corresponding static call chain.

2. The method of claim 1, wherein determining a lifecycle function contained in the abstract syntax tree comprises:

For each function in the abstract syntax tree, comparing the function with each flutter system level implicit call link, and if the function is contained in any flutter system level implicit call link, determining the function as a life cycle function.

3. The method of claim 1, wherein determining a major function and a called function corresponding to each function call relationship in the abstract syntax tree comprises:

in the abstract syntax tree, recursively searching a father node upwards from the first node until a first function which the first node belongs to is obtained, and determining the function as a main call function corresponding to the function call relation; and

and in the abstract syntax tree, recursively searching a parent node upwards from the second node until a first function to which the second node belongs is acquired, and determining the function as a called function corresponding to the function call relation.

4. The method according to claim 1, wherein the determining the static call chain corresponding to the function call relationship based on the main call function and the called function corresponding to the function call relationship includes:

Respectively acquiring function names, classes and file positions of the main call function and the called function, and acquiring a corresponding static call chain;

and determining the links from the function names, the classes and the file positions corresponding to the main call function to the function names, the classes and the file positions corresponding to the called function as corresponding static call chains.

5. The method of claim 1, wherein the determining the static call chain corresponding to the lifecycle function is based on a router system level implicit call link to which the lifecycle function belongs:

searching at least one other life cycle function behind the life cycle function in a router system level implicit call link to which the life cycle function belongs from a component corresponding to the life cycle function of the abstract syntax tree;

6. The method according to claim 1, wherein inserting the corresponding instrumentation code into the code blocks corresponding to each static call chain of the abstract syntax tree, to obtain the second intermediate product, comprises:

for each static call chain, if the static call chain comprises static call chains of at least three life cycle functions, sequentially taking every two adjacent life cycle functions as a static call chain to be inserted according to the connection sequence of the static call chains, and if the static call chain only comprises two life cycle functions or does not comprise life cycle functions, determining the static call chain as a corresponding static call chain to be inserted;

for each static call chain to be inserted, transmitting the static call information to be inserted as corresponding indication information to a preset global instrumentation function to obtain corresponding instrumentation codes, and determining the instrumentation positions of the instrumentation codes corresponding to the static call chain to be inserted;

and inserting each stake inserting code into a corresponding stake inserting position to obtain the second intermediate product.

7. The method of claim 6, wherein determining the instrumentation location of the instrumentation code corresponding to the static call chain to be inserted comprises:

If the called function corresponding to the static call chain to be inserted is located in the code block, determining the position after the code of the previous line of the return statement in the code block as the corresponding instrumentation position;

if the called function is located in a single sentence of the conditional statement of the code block, converting the single sentence into a corresponding sub-code block, and determining the final position of the sub-code block as a corresponding pile inserting position;

if the called function is located in the return statement of the code block, converting the return statement into a corresponding sub-code block, creating a first statement which is equal to the temporary variable of the called function and a second statement which returns the temporary variable, and determining the position between the first statement and the second statement as a corresponding instrumentation position.

8. The method according to claim 6 or 7, wherein the obtaining, based on the second intermediate product, a dynamic call chain corresponding to the target router source code includes:

converting the second intermediate product into an executable file;

executing the executable file, and determining the static call chain which is executed by the static call chain to be inserted and corresponds to the executed executable file as the dynamic call chain corresponding to the target flutter source code.

9. A dynamic call chain acquisition device, comprising:

the system comprises a static call chain acquisition module, a state call chain generation module and a state call module, wherein the static call chain acquisition module is used for determining a static call chain corresponding to a function call relation based on a main call function and a called function corresponding to the function call relation, and determining a static call chain corresponding to a life cycle function based on a flutter system-level implicit call link to which the life cycle function belongs for each life cycle function, wherein the flutter system-level implicit call link is used for a stateful component in a flutter to call the life cycle function;

the dynamic call chain acquisition module is used for inserting corresponding instrumentation codes into code blocks corresponding to each static call chain of the abstract syntax tree to obtain a second intermediate product, and acquiring the dynamic call chain corresponding to the target router source code based on the second intermediate product, wherein the instrumentation codes contain indication information of the corresponding static call chain.

10. An electronic device comprising a memory and a processor;

the memory stores a computer program;

the processor for executing the computer program to implement the method of any one of claims 1 to 8.

11. A computer readable storage medium, characterized in that it has stored thereon a computer program which, when executed by a processor, implements the method of any of claims 1 to 8.