WO2020248512A1 - Method for constructing runtime model of terminal application behavior - Google Patents

Abstract

Disclosed in the present invention is a method for constructing a runtime model of a terminal application behavior. A complete, accurate and detailed application behavior README file, i.e., a runtime model of an application behavior of a terminal application, is generated by means of a behavior interpreter. The defects in monitoring the application behavior of the terminal application in a dynamic, changeable and difficult-to-control application runtime environment in the prior art are overcome; flexible and complete monitoring for the application behavior of the terminal application is achieved; a technical guarantee is provided for subsequent instruction-level control to the application behavior of the terminal application.

Description

A method for constructing runtime model of terminal application behavior

This application claims the priority of a Chinese patent application filed with the Chinese Patent Office, the application number is 201910498727.X, and the invention title is "a method for constructing a runtime model of terminal application behavior" on June 10, 2019, and its entire contents Incorporated in this application by reference.

Technical field

The present invention relates to computer technology, in particular to a method for constructing a runtime model of terminal application behavior.

Background technique

Computational reflection (computational reflection, referred to as reflection) is a common operating state monitoring and control application main mechanism provided by system software such as programming languages, operating systems, and middleware. Based on computational reflection, various development frameworks and testing frameworks can be implemented to improve the efficiency of developers in code development, testing and even running deployment. In the computer field, reflexivity refers to the ability of a program to manipulate a set of data at runtime. This set of data describes the running state of the program. Manipulation has two implications: 1) Introspection, the program can observe and reason about itself 2) Control (Intercession), the program can change its operation or semantics. Both of these aspects need to be able to encode the state of program execution as data, and providing this kind of encoding is called reflection. That is to say, reflection is actually mapping the running state of the program into a set of operable data. The former part constitutes the base-level entity, the latter part forms the meta-level entity, and the causal relationship between the base-level entity and the meta-level entity is maintained. According to the different base entities, the calculated reflection is mainly divided into structural reflection and behavior reflection. The basic entity of structural reflection is the current program and its abstract data type (can be regarded as the state of the application), and the basic entity of behavior reflection is the execution behavior of the current program and the data required for its execution (can be regarded as the behavior of the application) .

Structural reflection refers to the ability of a programming language to reflect the current program and its abstract data types. It naturally exists because it is similar to the ability of a programming language framework (runtime or framework), and is an inherent ability of most programming language frameworks.

Behavior reflection refers to the ability of a programming language to provide its own execution semantics and the data reflection required for its execution, that is, the programming language framework itself needs to be reflected, and behavior reflection faces two challenges in monitoring and control: First, it needs to be complete Describe the existing application behavior, that is, monitor the execution of the application. The execution of an application can be regarded as a set of runtime activities. The finer the granularity of the activity, the richer the information to be monitored, the more resources the monitoring function occupies, and the more serious resource competition between it and business logic. At this time, the complexity and scale of application behavior monitoring have become the primary challenge for terminal application behavior reflection. Second, the existing programming language and the behavior reflection of system software such as operating system and middleware do not support instruction-level behavior control. The fundamental reason lies in the complex data and control dependencies contained in the instruction sequence. Therefore, the instruction-level application behavior Control has become the main difficulty of terminal application behavior reflection.

Summary of the invention

The main purpose of the present invention is to provide a method for constructing a runtime model of terminal application behavior, which overcomes the above-mentioned first challenge and realizes complete monitoring of terminal application runtime behavior.

The present invention is realized through the following technical solutions:

To solve the above technical problems, the present invention proposes a method for constructing a runtime model of terminal application behavior. The runtime model includes a runtime stack model and a runtime heap model. The method includes constructing a terminal application behavior. The steps of the runtime stack model and the steps of constructing the runtime heap model of the terminal application behavior;

The step of constructing the runtime stack model of the terminal application behavior includes:

When the terminal application is running, obtain the actually executed code in the memory of the terminal application, and abstract the actually executed code to generate a control flow graph;

For the control flow graph, input the control flow graph to be monitored into a preset behavior interpreter;

Use the behavior interpreter to interpret and execute the control flow graph that needs to be monitored, and generate stack activities when the terminal application is running;

When the terminal application is running, generate the dependency between the control flows of the stack activity, and obtain the runtime stack model of the terminal application behavior;

The step of constructing the runtime heap model of the terminal application behavior includes:

Generating the initial state of the heap area when the terminal application is running;

A heap operation activity is generated, and a runtime heap model of the terminal application behavior is obtained.

Compared with the prior art, the present invention uses a behavior interpreter to generate a complete, accurate, and detailed application behavior self-report, that is, a runtime model of terminal application behavior, which overcomes the dynamic, changeable, and difficult-to-controllability of the prior art The application runtime environment's insufficient monitoring of terminal application application behavior enables flexible and complete monitoring of terminal application application behavior, and provides technical guarantee for subsequent implementation of command-level control of terminal application application behavior.

The above description is only an overview of the technical solution of the present invention. In order to understand the technical means of the present invention more clearly, it can be implemented in accordance with the content of the description, and in order to make the above and other objectives, features and advantages of the present invention more obvious and understandable. In the following, specific embodiments of the present invention are specifically cited.

Description of the drawings

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

Figure 1 is an existing 3G radio resource control state machine;

Figure 2(a) is a schematic diagram of the network request control flow before the merger in an example of network request merger;

Figure 2(b) is a schematic diagram of the network request control flow after merging in an example of network request merging;

Figure 3 is an example of communication dependencies between threads-a schematic diagram of the producer-consumer model;

4 is a flowchart of the steps of a method for constructing a runtime model of terminal application behavior of the present invention;

Figure 5 is an example of Android multi-threaded programming;

Figure 6 is an example of dependencies between multithreaded programming;

Figure 7(a) is the heap area object before execution;

Figure 7(b) is the heap area object after execution;

8 is a schematic diagram of the architecture of the Reflectall model generation subsystem of the present invention;

Fig. 9 is a schematic structural diagram of an interface operation subsystem of Reflectall, an example of the present invention;

Figure 10(a) is the experimental result on the open source application set;

Figure 10(b) is the experimental result on the closed source application set;

Figure 11 is a comparison chart of application startup time results when Reflectall and Emma generate code coverage reports.

FIG. 12 schematically shows a block diagram of a computing processing device for executing the method according to the present invention; and

Fig. 13 schematically shows a storage unit for holding or carrying program codes for implementing the method according to the present invention.

Specific embodiment

In order to make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the technical solutions in the embodiments of the present invention will be described clearly and completely in conjunction with the accompanying drawings in the embodiments of the present invention. Obviously, the described embodiments It is a part of the embodiments of the present invention, not all the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those of ordinary skill in the art without creative work shall fall within the protection scope of the present invention.

In order to make the objectives, technical solutions, and advantages of the present invention clearer, the following further describes the present invention in detail with reference to embodiments and drawings.

In order to better understand the technical problems of the present application, the present invention selects two typical cases of application function evolution scenarios to analyze, so as to clarify the fundamental reason why the existing behavior reflection is not applicable.

Case number one:

Taking the 3G network module in the mobile device as an example, there are three states in total, as shown in Figure 1.

(1) IDLE: Idle state, in this state, the power consumption of the 3G module is the lowest, and it cannot send or receive any data. In this state, if you want to send or receive data, it will transition to the CELL_DCH state.

(2) CELL_DCH: In this state, the bandwidth of the 3G module reaches the maximum, and data transmission can be carried out at the maximum rate at this time, and its power consumption is also the maximum. If it continues for a period of time and there is still no data transmission, it will transition to the CELL_FACH state. Depending on the settings of different operators, the duration of continuous operation in the CELL_DCH state is usually 5 seconds to 10 seconds.

(3) CELL_FACH: In this state, the power consumption of the 3G module is 50% less than that of CELL_DCH. At the same time, in this state, its network transmission rate is also lower. If in this state, the data sent or received is greater than a certain threshold, it will re-transition to the CELL_DCH state. If no data is sent or received in the CELL_FACH state for a period of time, it will transition to the IDLE state. Generally speaking, this period of time is usually 10 seconds to 15 seconds.

Figure 2 shows an example of a network request merge. Figure 2(a) is the network request and the power consumption of the wireless communication module before merging, the horizontal axis is time, the upper half is the power consumption of the wireless communication module; the dotted line in the lower half is the thread that initiated the two network requests; The solid line in the lower half is the control flow. First, a background news push thread wakes up the thread responsible for sending network requests①; after the thread is awakened, it initiates network requests②. At this time, the power consumption of the wireless communication module also changes from the low power consumption in the IDLE state. It is the high power consumption in the CELL_DCH state; when the entire request is completed, the thread responsible for sending the network request returns the result to the news push thread ③. At this time, although the wireless communication module does not receive or send data, it will still remain at high power The power consumption of the wireless communication module starting from this is called the "end time power consumption", which corresponds to the slash part used in Figure 2(a); the news push thread receives the returned result ④, Handle it and prompt ⑤ on the notification bar. After another period of time, another version update thread also executed similar logic ⑥ and sent a network request. As shown in Figure 2(a), because the two network requests are separated by tens of seconds, the wireless communication module is woken up twice, so there are two corresponding "tail times", which results in additional network Energy consumption.

For Android applications, a large part of background requests can be delayed for tens of seconds, or even two or three minutes, without affecting the user experience. For example, the aforementioned news push, version update push, etc. For these network requests, if they are merged in the time dimension, that is, two requests are sent at the same time, instead of sending tens of seconds apart, the network power consumption of the "tail time" can be reduced. Figure 2(b) shows the control flow and the power consumption of the wireless communication module after the two requests in Figure 2(a) are combined. First, after the thread responsible for sending the network request is awakened by the news push thread, it does not directly send the network request, but enters a waiting state⑦. After a period of time, another network request thread is awakened by the background update push thread, and at the same time, it also enters a waiting state⑧. After the waiting state is over ⑨, these two threads send network requests at the same time, and the corresponding wireless communication module is only awakened once. As shown in Figure 2(b), the power consumption of the merged network request is much less than the power consumption of the network request before the merge.

In order to achieve network request merging, 1) a network request scheduling mechanism, that is, the network request that was originally sent directly can be delayed; 2) a network request scheduling algorithm, that is, to find out the request that can be delayed, and at the same time Use the scheduling mechanism for delayed transmission. Structural reflection can be used to automatically reconstruct the network request execution logic of mobile applications, and the scheduling mechanism can be built into the application. However, this requires developers of different applications to use the same automatic refactoring framework, and all applications need to be recompiled, deployed and run. This is obviously unrealistic for a large number of closed-source applications that belong to different application developers.

Case 2:

With the popularity of WeChat, WeChat has become more than just a simple communication application, it has also become an essential tool for work communication; it has spawned "WeChat business" that uses WeChat Moments and Official Accounts for marketing; it has become the largest free Media’s publishing platform. The core of WeChat is a communication tool, and its function is still to satisfy ordinary users. Even so, it is difficult to meet the specific needs of ordinary users. For example, as WeChat has been used for longer and longer, its cached chat log files have also become larger and larger, and it is difficult for ordinary users to manage their chat logs. Furthermore, WeChat is difficult to meet the specific needs of special groups such as WeChat businessmen and self-media people. To realize the open sharing of data and functions in the WeChat application, it is necessary to transform the user-oriented user interface interface into an interoperable programmable interface. Generally speaking, for a user-oriented user interface interface, the starting point of its execution lies in operations such as clicking, dragging, and inputting user interface elements. After part of the logic processing, access to external resources by means of network requests, database queries, and file reading and writing, to obtain corresponding data or realize corresponding functions. In this processing flow, most of the logic is similar to the execution logic of the interoperable programmable interface, but the starting point of its execution is different. However, the granularity of existing behavioral reflection monitoring and control is method level. Based on the existing behavior reflection, inserting some execution logic into the execution process of existing applications, it is difficult to convert user-oriented user interface interfaces into interoperability-oriented programmable interfaces: existing functions can correspond to running A group of program activities at a time, the method-granular behavior reflects that the content of monitoring is limited, and the execution of instructions in the method cannot be monitored, and then it cannot be controlled. This has led to the fact that existing solutions are often based on existing code and documentation. For a development team, the flow of developers, the lack of documentation, and even non-standard source code comments will change the iterative development of mobile applications. Too difficult to proceed.

It can be seen from the above two case studies that the fundamental reason for the difficulty in implementing the mobile application interoperability interface is that the existing work lacks a complete and detailed description of the application behavior, and there is no self-descriptive control of this instruction granularity. Methods. Therefore, whether a runtime model that completely describes the application behavior and is operable can be given has become the difficulty and key to solving the problem of the present invention.

In view of the foregoing technical problems, the embodiment of the present invention proposes a method for constructing a runtime model of terminal application behavior. The runtime model includes a runtime stack model and a runtime heap model.

After the application runs in the operating system, it can be regarded as one or more processes. The operating system loads the executable file required by the mobile application into the memory and starts execution. Generally speaking, the memory occupied by a process can be divided into three areas:

Code segment: a memory area where the execution code is stored, with read-only attribute;

Heap area: It can be divided into a memory area (data segment) used to store global variables and a memory area used for dynamic allocation during process operation. For example, in the object-oriented programming language Java, a thread creating a new object is equivalent to A piece of memory is applied for in the heap area;

Stack area: used to temporarily store local variables, etc. For example, in the object-oriented programming language Java, when a thread calls a method, it will apply for a new frame (frame), and data such as parameters required by the method are stored in the frame.

After careful study by the inventor, it is found that the execution of the code segment will cause changes in the memory data in the heap area and the stack area when the terminal application is running. The runtime model of the application needs to be able to reflect the application over a period of time: 1) Code execution: During development, the code of the mobile application can be abstracted as a control flow graph, so corresponding to the runtime, the execution of the code can be abstracted as One or more paths of the control flow graph; 2) Changes in memory data (such as heap area): During development, developers will design various data structures to represent the data model of the application, and at runtime , The execution of the code causes the creation, modification, and deletion of instances of these data structures, which corresponds to a set of memory allocation and modification operations. From the perspective of memory area, the most important areas affected by program execution are the stack area and heap area of the memory. The path in the control flow diagram in 1) can be regarded as a description of the stack change, and the main reflection in 2) is the change of the heap area data.

Therefore, the application runtime model constructed by the present invention includes a runtime stack model describing stack changes and a runtime heap model describing heap changes. Among them, the runtime stack model also includes the acquisition of code, which completely divides the memory occupied by a process into three areas. Through the runtime stack model of the embodiment of the present invention, it is possible to understand the code execution status of the mobile application at any time; and through the runtime heap model, it is possible to understand the object data state on which the code execution depends at any time.

Runtime stack model

The control flow graph is a directed graph G=<B, P>;

Among them, B={b ₁ , b ₂ ,..., b _n } is a basic block;

Is the control flow path;

For any p _i = (b _i1 , b _i2 ), p _i ∈ P, it is executed if and only if b _{i2 is} possible after b _i1 . At runtime, the control flow graph is instantiated into one or more control flows, and basic blocks are executed according to the path in the control flow graph. The present invention calls the basic block executed at a certain moment as an activity, and the runtime stack model for a period of time is composed of a control flow graph, one or more control flows, and a set of activity sequences. When the granularity of the basic block is instruction granularity, the activity sequence is the instruction execution sequence. The formal definition of the runtime stack model of the present invention is given below.

Define the runtime stack model as a collection of activities that occur in one or more control flows within a period of time M = <G, T, A, I, E>,

Among them, G=<B, P> is the control flow graph, T={t ₁ , t ₂ ,..., t _n } is a set of moments, I={i ₁ , i ₂ ,..., i _n }, which means t The heap state of the program from ₁ to t _n .

Let F = {f ₁ , f ₂ ,..., f _n }, be a set of control flow, then A = F × 1 × T × B is the set of activities that occur within a period of time,

Represents the collection of the context of the occurrence of two activities.

The runtime stack model can be regarded as a collection of multiple paths in the control flow graph. Therefore, the edges in the runtime stack model must be in the control

The occurring context has a temporal sequence relationship for two activities in the same control flow; if there are edges for two activities in different control flows, it indicates that the two activities still have a dependency relationship.

In the same control flow, if two activities have a contextual relationship, it is impossible for any other activities

In different control flows, if two activities have a contextual relationship, for the control flow where the latter activity is located, other activities can occur first after the moment when the previous activity occurs.

Where a _i ={f _i1 , t _i2 , b _i3 ), a _j = (f _j1 , t _j2 , b _j3 ), if f _i1 ≠ f _j1 , then t _i2 <t _j2 .

Activity definition program a _j depends on the synchronization program activities a _i, a _j if the start or end of a _i by the implementation of the decisions, in general, a _i and often some thread synchronization operation. It is said that a _j communication depends on a _i , if a certain data dependency of a _j is generated by a _i activity. Taking the object-oriented programming language Java as an example, the granularity of the basic block is the granularity of the basic block of the source code. Each control flow of the runtime stack model corresponds to the execution sequence of a Java thread. There are six states of thread state transition:

Creation: The thread object has just been created and is in this state when it has not yet started;

Running: The thread is in a running state, and the thread in this state may wait for some system resources, such as CPU;

Blocking: The thread is waiting for a Monitor Lock. For example, when the thread enters the method or code block modified by the synchronized keyword, the thread will enter the blocking state;

Waiting/Timed Waiting: The thread is waiting, for example, when the thread calls the wait method of an object to enter the waiting state. When the notify method of the object is used, the thread will re-enter the running state;

Death: When the run method of a thread ends, it will enter the dead state.

From the above state transition, it can be found that in some cases, a thread in a running state can wake up another thread in a non-running state to enter the running state. The present invention calls this relationship between threads a synchronization dependency relationship. When these inter-thread wakeups occur, corresponding to the runtime stack model, there is a cross-thread (cross-control flow) edge between the activities of the threads in the running state and the activities that occur when the non-running threads enter the running state. From the Java language level, these thread dependencies can be summarized into four categories, as shown in Table 1.

Table 1: Classification of synchronization dependencies at the Java language level

In Table 1, the activity of each running thread corresponds to the activity of the non-running thread. Therefore, the inter-thread dependency in Table 1 is called the synchronization dependency. Based on the state transition of the above threads, Java provides a variety of multi-threaded programming libraries to support. For example, java.util.concurrent provides read-write locks, reentrant locks, blocking locks, and thread pools.

Figure 3 shows an example of communication dependencies between threads-the producer-consumer model. In this example, the Task class represents computing tasks; the static field tasks represents a queue of pending tasks; the postTask method represents generating and submitting tasks; and the handleTask method represents processing tasks. As shown in Figure 3, there are two threads: 1) Thread 1 represents the producer thread, which will submit tasks to the pending task queue; 2) Thread 2 represents the consumer thread, and will check the pending task queue at regular intervals. And handle the corresponding tasks. In this example, there is no synchronization dependency between the producer thread and the consumer thread-the consumer thread will automatically switch from the timed waiting state to the running state every certain period of time, but there is a communication dependency-if the production If the user thread does not submit the task, the task.run method of the consumer thread will not be called.

From the above example, it can be found that the generation of the activity relationship in the runtime stack model must depend on the corresponding data at runtime. In classic data flow analysis, the data flow analysis algorithm calculates the data flow equation based on the structure of the control flow graph and iterates to a stable point. Therefore, in addition to the above-mentioned runtime stack model, the runtime model of the application also needs a runtime heap model that describes changes in the data state of the memory heap area.

Runtime heap model

The classic data flow diagram is often used in the requirements analysis phase. The software uses the data flow diagram to decompose the software system to be developed layer by layer from abstract to concrete. The data flow graph is a directed graph, which contains two different types of edges and a variety of different nodes to describe data starting from an initial node, performing layer-by-layer calculations, and finally getting the final result. At runtime, a certain node of the data flow graph essentially corresponds to a set of changes in memory data. Therefore, the heap model of the application behavior runtime model of the present invention focuses on changes in memory data, rather than changing operations. The runtime heap model of the present invention only models the heap area of the memory during application runtime from the perspective of memory data changes.

The runtime heap model is a collection of the initial value of a set of memory data and the memory modification activities of the heap during a period of time M = <D, A, T, R>;

Among them, D = {d ₁ , d ₂ ,..., d _n }, is the initial value of a set of memory addresses, A = {i ₁ , i ₂ ,..., i _n }, is the activity that causes memory data changes, T = {T ₁ , t ₂ ,..., t _n }, which is the time stamp.

For different object-oriented programming languages, they will provide different application programming interfaces to achieve dynamic memory allocation and recovery. For example, in the C/C++ language, memory allocation and recovery are realized by providing malloc and free functions in the standard library functions; while in the Java language, new objects can be created through the new keyword to achieve memory allocation. Through an automatic garbage collection mechanism, Realize the recovery of memory.

In view of the technical problems of the present invention, how to construct the above-mentioned runtime model of the embodiment of the present invention will be described in detail below.

4, there is shown a step flow chart of a method of constructing a runtime model of terminal application behavior of the present invention, the method includes the steps of constructing a runtime stack model of the terminal application behavior and constructing the terminal application behavior The steps of the runtime heap model.

The step of constructing the runtime stack model of the terminal application behavior may specifically include:

Step S401: When the terminal application is running, obtain the actually executed code in the memory of the terminal application, and abstract the actually executed code to generate a control flow graph;

Step S402: Regarding the control flow graph, input the control flow graph to be monitored into a preset behavior interpreter;

Step S403: Use the behavior interpreter to interpret and execute the control flow graph that needs to be monitored, and generate stack activities when the terminal application is running;

Step S404: When the terminal application is running, the dependency between the control flows of the stack activity is generated to obtain the runtime stack model of the terminal application behavior;

In the embodiment of the present invention, the construction of the runtime stack model includes the following three basic elements: 1) Control flow graph: contains all possible activities and all possible activity relationships, is the source code of the program, or the abstraction of the intermediate code Representation; 2) A group of activities that occur at runtime, that is, a path in the control flow graph, can be regarded as a group of nodes in the stack model; 3) The relationship between activities that occur at runtime, that is, the edges of the stack model.

The construction of the stack model needs to focus on solving three challenges: First, due to technologies such as compilation optimization and runtime just-in-time compilation, the source code of the application and the bytecode generated by the compilation may be different from the code segment in the runtime memory. How to ensure The control flow graph and runtime activities can be mapped correctly; second, how to generate activities with different granularities to describe the changes of complex application running state; third, because current applications use a lot of multi-threaded compilation to ensure the response speed of the interface, To improve user experience, how to generate dependencies between runtime control flows. In view of the above three challenges, the first step of the embodiment of the present invention is to obtain the actually executed code in the memory at runtime and abstract the currently executed code, which can ensure the accurate mapping of the control flow graph and the runtime activities. In the second step, a behavior interpreter is proposed. The behavior interpreter takes the control flow graph generated in the previous step as input to interpret and execute it. The third step is to explain the runtime activities of the generated application during the execution process; and the last step of model generation is to generate the dependency between the control flow at runtime.

Below, a further overview is given to the steps of generating the runtime stack model.

1. Control flow graph generation. During the application development process, since the installation package release will contain the intermediate code compiled by the application, for protection purposes, the application will use various obfuscation tools to generate the intermediate code, such as the dex bytecode under Android , To be confused. This makes it difficult to map the directly provided source code with the activities performed during application runtime. These obfuscated codes will be loaded and executed through the application runtime environment. For example, the Dex bytecode in an Android application will be executed in Android Runtime (ART). In the present invention, the bytecode of the application is obtained by modifying the running time of the application. This approach can bring two benefits. One is that there is no need to provide matching intermediate code or source code, which improves the practicability of the method; the other is that the intermediate code generated when the application is running can ensure consistency with the executed activities. This ensures the matching of the control flow graph with the control flow at runtime.

Specifically, control flow graph generation:

According to the instruction type, the boundary of the basic block is obtained. An instruction is the beginning of a basic block if and only if: 1) it is the first instruction of a method or 2) a certain instruction may jump to the current instruction. An instruction is the end of a basic block, if and only if: 1) it is the return of a method, such as return, throw instructions; or 2) it is a jump instruction, such as if, goto, or the instruction may throw an exception . After defining the start and end of the basic block, the control flow graph generation algorithm of the present invention is divided into the following three steps:

Calculate the target address of all jump instructions (including explicit jump and exception jump), and mark the instruction at this address as an instruction that can be used as the start of a basic block.

Initialize the basic block queue to be empty, and traverse each instruction from low to high. If the instruction is the beginning of a basic block or the current basic block is empty, create a new basic block, use it as the current basic block, and place it in the basic block The end of the block queue; if the instruction is the end of the basic block, put it in the current basic block, create a new basic block as the current basic block, and put it at the end of the basic block queue.

Traverse the entire basic block queue to establish the predecessor and successor relationship of the basic block: if the last instruction of a basic block is a jumpable instruction, add a directed edge to the basic block and the target basic block of the jump; if If a basic block is not a return or goto instruction, it adds a directed edge to the next basic block in the queue.

Second, the execution of the control flow graph is redistributed on demand, and the activities of the application runtime generated by the behavior interpreter. When the application is running, each thread corresponds to a control flow, and each control flow can be regarded as a set of ordered activities. This group of activities can be regarded as a path of the control flow graph generated in the previous step. Therefore, the present invention proposes a behavior interpreter suitable for monitoring program execution. According to the configuration, assign the control flow graph that needs to be monitored to the behavior interpreter for execution. If the execution of each instruction corresponds to an activity, this group of instruction sequences will become extremely large and difficult to process: 1. Numerical calculation statements are difficult to correspond to semantics; 2. A large number of activities generated by program loops will obliterate the real Processing logic. Therefore, the present invention divides activities into numerical calculation, branch control, method invocation, etc., and implements an activity filter that provides multiple granular activity screening in the behavior interpreter, so as to generate a suitable stack model.

In the construction method of the embodiment of the present invention, a class filter and an activity type filter are included; wherein the class filter is based on a coarse-grained filter based on regular matching of package and class names, and is used to remove program activities that developers do not care about; The activity type filter is based on fine-grained filtering of activity types, and is used to remove activity types that are not of concern to developers.

Wherein, the activity type of the stack activity includes method start and method end, field read, array read, and synchronization instructions; based on the above activity type, the implementation method of step S403 includes:

Interpret and execute the control flow graph that needs to be monitored by using a behavior interpreter that has a monitoring function for the application behavior of the terminal application, and obtain the activities of the terminal application when the terminal application is running;

According to the class of interest, use the class filter to perform coarse-grained screening of the activities of the terminal application during runtime, and generate stack activities caused by the class;

With regard to the activity type of the stack activity, the activity type filter is used to perform fine-grained screening of the stack activity.

The embodiment of the present invention can generate a required stack model by flexibly specifying a specific package, class, and instruction type, which improves the ease of use.

In order to improve the accuracy of the construction model, the present invention regards the start and end of the execution method call instruction as activities and records. From the point of view of Java's method invocation, its invocation appears to be a tree-like structure: for a certain method invocation, multiple method invocations may occur during the execution. Therefore, in order to ensure that the generated sequence can be restored to this tree-like structure, the subscript s in the present invention represents the activity at the beginning of the method call, and the subscript e represents the activity at the end of the method call. For the above example, the two program execution situations will correspond to two different sequences:

1) If both calculate doInBackground is called, then the sequence is _{d s → c s → c e} → c s → c e → d e;

2) If there is a recursive call to itself calculate, the sequence _{d s → c s → c s} → c e → c e → d e.

The method call that reconstructs the generated activity sequence into a tree structure can adopt the call tree construction algorithm. The algorithm process is actually the process of simulating the execution process of the Java virtual machine. At the beginning of the algorithm, each thread's activity corresponds to an actions object. For each thread, two data structures are maintained: 1) the sub-control flow queue that has been executed; 2) the function stack of the current control flow execution. Traverse each activity in actions in order, and make the following judgments:

If there is no current control flow, one is instantiated and pushed onto the function stack.

If the current activity is the method start type, instantiate a new sub-control flow, push the newly instantiated sub-control flow onto the function stack, and add it to the activity queue of the current control flow. Finally, the current control flow is set to the sub-control flow just instantiated.

If the current activity is the method end type, pop the stack operation. If the function stack is empty after the pop-up stack ends, it means that the sub-control flow of the current thread has been executed and can be added to the executed sub-control flow queue; if the function stack is not empty, the current control flow is set to the function The sub-control flow at the top of the stack.

Otherwise, the current activity is pressed into the activity queue of the sub-control flow.

Similar to method call instructions, other types of instructions can have two activities: instruction start execution and execution end. Because these instructions are atomic, that is, in the same thread, no other activities will occur between the beginning and the end of the instruction execution. Therefore, for these types of instructions, only the activity of starting the execution of the instruction is required.

In the specific implementation, the runtime activity representation implementation can have a storage form: it can be an object in the memory, or a persistent binary file or an ASIC II file. In the present invention, the runtime heap model can be expressed in the form of Backus paradigm.

The present invention achieves this scalability through an active serialization and deserialization mechanism. When the runtime model is generated, the sequence of activities in the runtime model is stored in a buffer with a configurable size. When the number of activities exceeds the preset, the activities in the buffer are serialized and persisted to local storage .

Third, the generation of dependencies between control flows. Multithreaded programming has become an important part of Android application development. The use of multi-threaded programming can realize the efficient response of the user interface and the parallel acceleration of multiple computing tasks. The thread synchronization and mutual wake-up (called thread dependency) in multithreaded programming can be abstracted as the edge between the control flow in the stack model. Thread dependency is a relationship related to time: at a certain moment, the main thread can send calculation tasks to the background thread, and the activities performed by the background thread at this time depend on the activities of the main thread; and at the next moment, the background thread completes the calculation task After that, the main thread is notified to update the interface; at this time, the activities performed by the main thread depend on the activities of the background thread. Therefore, the present invention classifies these inter-thread dependencies, and processes different types of dependencies to generate these dependencies at runtime.

In the embodiment of the present invention, the dependency relationship includes synchronization dependency and communication dependency. The thread state transfer related methods provided in the Java language specification are used between threads, such as Thread.join, Object.wait, Object.notify, etc., to realize the coordination between multiple threads. The present invention calls the dependencies between these threads as synchronization dependencies. . Whereas objects are used between threads to achieve coordination among multiple threads, and the present invention calls these dependencies among threads as communication dependencies. In actual development, application developers will reuse various multi-threaded programming classes provided by the framework layer to improve development efficiency. Although the framework layer provides a good semantic application programming interface to the application layer classes, shielding the implementation details, but in order to ensure the performance and robustness of the framework, the implementation is often more complicated. Programs implemented using these programming frameworks may be dependent on synchronization or communication between threads at runtime.

Take the BackgroundTask.execute method call in Figure 5 from the beginning to the end of the onPostExecute method call as an example. There are two active threads globally, and there are synchronization dependencies and communication dependencies between them. The method call of this process is shown in Figure 6: the upper and lower axes in the figure represent the method stacks of the foreground thread and the background thread over time; the boxes in the figure represent the methods, and the gray boxes represent the methods of the framework layer. , The white box represents the method of the application layer, that is, the method implemented by the application developer; the arrow in the figure represents the dependency between threads, the solid arrow represents the synchronization dependency, and the dashed arrow represents the communication dependency. In the method call process shown in Figure 6, the BackgroundTask.execute method will call the ThreadPoolExecutor.execute method during the execution process (activity ①), and then call the start method of the background thread object (activity ②), which will further cause the background thread to run Method call (activity ③). After the background thread's run method starts to execute, it will eventually call the BackgroundTask.doInBackground method (activity ④) after layers of calls. During the execution of this method, in addition to calling the calculate method for calculation tasks, it will also call AsyncTask.publishProgress Method (activity ⑤), so that the foreground thread calls the onProgressUpdated method (activity ⑥) to update the interface. Subsequently, after the background thread ends the calculation task, it will notify the foreground process that the current task has ended in a similar manner. Among them, activity ② and activity ③ are synchronous dependence, and activity ⑤ and activity ⑥ are communication dependence.

Generation of synchronization dependencies:

In order to realize the generation of synchronization dependencies, the methods related to synchronization dependencies in Java are considered to be activities that need to be collected. In this way, the runtime stack model can collect various activities related to synchronization dependencies as shown in Table 1.

For two activities that have synchronization dependencies, the subsequent activity may be the end of a method or the beginning of a method. Based on this, the synchronization dependencies can be divided into two types and processed separately:

For the case where the end of one method depends on the end of another method, the timestamp is used to find matching activities in other threads from back to front. If found, it corresponds to a synchronization dependency. For example, the end of Thread.join depends on the end of Thread.run; the end of Object.wait depends on the end of Object.notify. For methods such as Thread.join or Object.wait to end the activity, you can use the timestamp to find others from back to front. Matchable activities in the thread. If found, it corresponds to a synchronization dependency.

When generating synchronization dependencies between control flows, for the case where the end of one method depends on the end of another method, the timestamp is used to find matching activities in other threads from back to front. If found, it corresponds to a synchronization dependency Relationship; for example, the end of Thread.join depends on the end of Thread.run; the end of Object.wait depends on the end of Object.notify. For methods such as Thread.join or Object.wait to end the activity, you can use the timestamp to move forward Find matching activities in other threads. If found, it corresponds to a synchronization dependency.

For the case where the start of an activity depends on the end of another activity, check the current thread first. If the activity is the first activity executed in the current thread, the activity is dependent on another thread to end the activity, otherwise the Activities are just normal method calls and do not depend on the activities of another thread. For example, the start of Thread.run depends on the end of Thread.start, because in Java, the start of an activity (that is, a method call) can be performed any number of times at any place, including the Thread.run method. Therefore, to determine whether a call to the Thread.run method depends on the call of the Thread.start method, the current Thread.run needs to be checked first: if the activity is in the current thread. The first activity executed, it depends on another thread Thread.start to end the activity, otherwise it is just a normal method call and does not depend on the activity of another thread.

Generation of communication dependencies:

The threads are not based on the method provided by Java that can realize the thread state transition, and realize the coordination among multiple threads. The present invention refers to the dependency between these threads as communication dependency.

Taking activities ⑤ and ⑥ in Figure 6 as an example, the concrete implementation is based on the next method and enqueueMessage method of MessageQueue. In this process, if there are elements in the pending queue of the foreground thread waiting to be processed, the enqueueMessage method caused by activity ⑤ will only add the current task to the queue, and will not explicitly wake up the foreground thread. But logically, it can be considered that for a MessageQueue object, the Message object returned by its next method will be passed into the dispatchMessage method by the Handler as a parameter, so it can be considered that the end of the MessageQueue next method depends on MessageQueue.enqueueMessage And the dependency is based on the parameter Message as the matching object instead of MessageQueue.

When generating communication dependencies between control flows, all classes related to communication dependencies between activities are summarized, and the related methods of these classes and thread dependencies are used as the knowledge base for generating communication dependencies. The knowledge base can also support application customization.

4, the step of constructing the runtime heap model of the terminal application behavior may specifically include:

Step S405: Generate an initial state of the heap area when the terminal application is running;

Step S406: Generate a heap operation activity, and obtain a runtime heap model of the terminal application behavior.

In the embodiment of the present invention, the runtime heap model includes the following basic elements: 1) the initial state of a heap area; 2) a group of activities that affect the data of the heap area during operation. The present invention first provides a description method of the initial state of the heap area, and generates an initial state of heap data that conforms to the representation during operation. Secondly, the present invention provides a description method of heap operation activities, and constructs activities in the runtime heap model at runtime. Finally, the BNF representation of the initial state of the heap area and the heap operation activity is given.

Below, a further overview of the generation steps of the runtime heap model is given.

One is the generation of the initial state of the heap area. The initial state of the heap area is the state of the heap area data at the start time. In the Java virtual machine specification, only the simplest description of the heap area is given: the heap is the area used to analyze all class instances and arrays at runtime, and this area is managed by an automatic storage management system (ie garbage collector) . Objects in the heap are never explicitly collected, but are automatically collected by the garbage collector. The initial state of the heap area can be regarded as a snapshot of the heap area data at a certain moment. Therefore, if the data state of the memory heap area is generated, if other threads continue to execute and perform heap area operations (such as creating objects and performing garbage collection) Etc.), it will destroy the atomicity of the initial state. Therefore, the present invention first provides a BNF representation describing the initial state of the heap area, and adopts a method of "freezing" the heap area data when generating the initial state of the heap area data to ensure the atomicity of the initial state generation process.

2. The generation of activities in the heap model. When the application is running, Java's garbage collector can generate activities to reclaim memory. In addition to these activities, other activities can be regarded as a subset of the activities in the runtime stack model. On the one hand, if each operation that affects the data in the heap area corresponds to an activity, the number of activities in this group will become extremely large and difficult to process. For example, there are I/O operations of large files in an application. If all operations are recorded in the form of activities, the amount of active data will not be less than that of large files; on the other hand, similar to the control flow model, it may only Focusing on the execution of some classes and methods, generating a heap model that is too large is difficult to analyze. The description of activities is expanded here to support the description of garbage collection activities, similar to the runtime stack model, providing multiple granular activity selection filtering options to generate a suitable heap model. The generated heap model describes the changes of the objects of interest in detail. Therefore, the heap object state query algorithm based on timestamp can query the state of the heap object at any time.

Next, use a specific example to introduce the runtime heap model modeling process:

The data in the Java heap area only includes instantiated objects and arrays. For applications, the creation of objects may occur in application layer code or framework layer code. Therefore, we divide the objects in the application into application layer and framework layer. Taking the code implemented in Figure 5 as an example, before triggering the click event, The objects of the heap area are shown in Figure 7(a). Each circle in the figure represents an object, and the line between the circle and the circle represents the reference relationship. The objects related to the application business logic in Figure 7(a) include the display interface FloatActivity, the button that can trigger the background calculation task, the background task to be processed, the BackgroundTask, the TextView used to display the calculation result of the task, and the click event listener OnClickListener. In addition to objects related to business logic, there are many framework-level objects. For example, a MessageQueue object in the framework layer. Realizing background processing tasks can notify the foreground to update. The solid arrow in Figure 7 indicates the reference relationship of the object, that is, if there is a field in object A that points to another object B, there is a directed connection from A to B; the dotted arrow indicates that there is a Through the reference relationship of the object, and at the end, there is no reference relationship.

During the event triggering process, the following objects will be created: During the execution of the BackgroundTask.execute method, the ThreadPoolExecutor.execute method will be called. At this time, since the object executes the execute method for the first time, the object will create a new Thread object①, which is The thread of background execution; after calling the start method of the background thread object, it will further cause the call of the run method of the background thread and officially start calling the doInBackground method. In this method, in addition to calling the calculate method to perform the calculation task, it also calls the AsyncTask.publishProgress method. Before executing the method, the incoming parameters will be encapsulated into the newly created Integer[] object ②; During execution, a new Message object ③ will be created and placed in a global MessageQueue queue. When the front thread receives the Message and executes onProgressPublished, it will create a StringBuilder object ④ to construct the parameters required by setText, and instantiate a new String object ⑤ through the StringBuilder.toString method. Before the execution of the doInBackground method ends, a new StringBuilder object ⑥ will be created, and the return value String object ⑦ will be calculated. The String object will be encapsulated again in a newly created Message object ⑧, and notify the foreground thread to execute the onPostExecute method. The above process has simplified some of the steps, and more objects will be created in actual operation. For example, the Thread object does not directly rely on the BackgroundTask, but will be encapsulated by FutureTask, Callable and other objects, and indirectly rely on the BackgroundTask object. After the end of the process, objects ① to ⑧ may be collected in a garbage collection.

In the heap model, the present invention treats the instantiation, field assignment, and recycling of each object in Figure 7(b) as an activity. Similar to the representation of the runtime stack model, the following invention preferably provides a representation of the runtime stack model in the form of Backus paradigm.

Among them, DataAction is similar to the ControlAction described in the key technology of runtime stack model construction. ControlAction is used to describe the execution of instructions, and DataAction is used to describe changes in memory data. Number represents a number type, which can be a numeric value or a memory address; String represents a string type. From the above representation, it can be found that the complexity of the model mainly depends on: 1) the number of objects in the initial state; 2) the number of data activities in the heap area.

In the specific implementation of Android, its heap area can be divided into three sub-areas: 1) App Heap, the memory area used by the current application to instantiate objects and arrays; 2) Image Heap, which is loaded The memory area of the current application mirroring; 3) Zygote Heap, the memory area where the system classes loaded when the system starts. The initial state described in the present invention mainly focuses on the application stack that changes the most during runtime. For the Dalvik virtual machine and ART virtual machine on the Android platform, they realize that the current application heap state can be saved as a file at any time (heap dump operation). This file is a private memory image format, which can be converted to hprof format that complies with J2EE platform regulations through Android Developer Tools.

However, the current application heap dump can only reflect the heap state at a certain moment, and it is difficult to reflect the heap state at any time within a period of time. First of all, all threads need to be suspended to perform a heap dump operation, which is time-consuming. The generated files range from tens of megabytes to hundreds of megabytes, and it is difficult to implement a heap dump operation every once in a while. The state of the heap at any time within a period of time. Secondly, performing a heap dump operation does not dump those objects that are recovered by the collector, including those temporary objects generated during execution. However, for an execution process, the temporary objects generated are also very important for the execution of the described process. Important, for example, the objects ② to ⑧ in Figure 7 are all temporary objects, and these objects cannot be persisted directly using heap dumps.

In the embodiment of the present invention, the step of constructing the runtime heap model of the terminal application behavior includes: the terminal application runtime activities include instantiation activities, modification activities, and recycling activities.

Among them, the instantiation activity (NewAction), that is, the activity of creating a new object and a new array, can correspond to the execution of instructions such as newInstance and newArray in the bytecode at runtime.

ModifiyAction, that is, the activity of modifying the value of the static field of the class, the field of the object, and the element of the array, can correspond to instructions such as sput, iput, aput in the bytecode.

GCAction is an activity that affects objects in the heap when garbage collection is performed. For recycling activities, the garbage collection mechanism is an automatic memory management mechanism. When the data in a piece of memory will no longer be used, it will be reclaimed and released to facilitate the next allocation. Specific garbage collection algorithms are implemented with reference counting method and reachability analysis algorithm.

The recycling activity does not correspond to the instructions of the dex bytecode at runtime, because its specific implementation is at the virtual machine level. Recycling activities can be further subdivided into cleanup activities and compression activities. The so-called cleanup activity is to clean up objects that are no longer needed; while the so-called compression activity is to organize active objects into contiguous memory space to avoid allocation failure due to fragmentation when allocating large memory.

In addition, in addition to the implementation of the application layer code will create objects, the framework layer code will also create a large number of objects, in some cases, even several times the objects created by the application layer. It is necessary to provide a mechanism for the complexity management of the heap model to ensure the accuracy and ease of use of the generated runtime stack model. Similar to the aforementioned two-level screening mechanism, there is also a two-level screening mechanism for the activity generation of the heap model. Coarse-grained filtering based on regular matching of package and class names and fine-grained filtering based on activity type.

The present invention preferably provides 6 types of heap operation activities, and the activity types of the heap operation activities include object instantiation, array instantiation, object field writing, array element writing, clearing activity and compression activity;

The steps of generating a heap operation activity include:

According to the class of interest, use the class filter to perform coarse-grained screening of the terminal application runtime activities to generate heap operation activities caused by the class;

For the activity type of the heap operation activity, the activity type filter is used to perform fine-grained screening of the heap operation activity.

Regarding the control challenge faced by behavior reflection, that is, the second challenge described in the background art of the present invention, supporting instruction-level behavior control is not the focus of the present invention, so I will not repeat it here.

In the following, a specific example is used to verify the effectiveness of the embodiment of the present invention on terminal application behavior monitoring.

For Android mobile applications widely used in the mobile Internet, a prototype system implementation of the behavior reflection framework: Reflectall is given. The full name of Reflectall is Reflection at low level interpreter, which has two meanings. One is reflection based on the underlying behavior interpreter; the other is that it can monitor and control instruction-level application behavior. Reflectall is based on the Android operating system open source project. In order to realize the monitoring and control of mobile application behavior, the Reflectall platform can be divided into a behavior runtime model construction subsystem, a model analysis and code generation subsystem, and an operation subsystem to realize the monitoring and control in the behavior reflection framework.

Referring to Figure 8, a schematic diagram of the architecture of the Reflectall model generation subsystem. Reflectall's behavior runtime model construction subsystem implements the construction of mobile application behavior runtime models. Its core implementation is at the system layer and consists of four modules: optimization-deoptimizer, behavior interpreter, model construction and interface layer. These four modules realize the monitoring and control of mobile application behavior.

Among them, optimization-de-optimizer: the Android runtime environment can load native instructions that can be directly executed by the CPU. Therefore, it is necessary to switch the original instruction to bytecode, that is, de-optimization, and perform interpretation and execution through the behavior interpreter, so as to realize the monitoring of mobile application runtime activities. Due to the complexity of mobile applications, it is difficult to monitor all activities in the execution of mobile applications, so a two-level screening mechanism is introduced. The optimization-de-optimizer implements the class filtering mechanism in the two-level filtering mechanism. Through the optimization-de-optimizer, the classes to be monitored can be de-optimized into bytecodes as needed, and interpreted and executed; while for unmonitored The class is still executed in the native executor. The optimization-de-optimizer will be triggered in the following three situations: 1) When receiving the command to start monitoring, it will filter the methods of the currently loaded classes according to the configured parameters and perform de-optimization; 2) Receive When the monitoring command is finished, the currently de-optimized class will be re-optimized to re-enter the native executor for execution; 3) When the class linker loads a new class, the class will be similar to the case 1) The screening and de-optimization process. In order to ensure the correctness of the program execution, the de-optimization process needs to be the same as part of the garbage collection algorithm, temporarily suspend the execution of all threads, and resume the thread execution after the de-optimization execution ends. Through this partial de-optimization and maintaining the coexistence of interpreted execution and native execution, the performance overhead of monitoring can be greatly reduced.

Behavior interpreter: The behavior interpreter is an interpreter that interprets and executes the dex format bytecode. It can monitor the activities that occur in the current program execution during the interpretation and execution. Most of the activities in the mobile application behavior runtime model are generated by the behavior interpreter. In addition to the activities generated by the behavior interpreter, the garbage collector can also generate some activities-garbage collection activities. The behavior interpreter also implements the activity filtering mechanism in the two-level filtering mechanism, which can generate different types of activities according to the configured activity collection granularity.

Model builder: The activities generated by the behavior interpreter and garbage collector will be built in the model builder. When there are more activities during runtime, it will lead to a larger memory footprint. Therefore, the model builder implements online and offline model construction. When there are few activities, when the model builder runs in the online model building mode, when the number of activities reaches the configured threshold, the model builder will persist the currently generated sequence of activities and store them in the form of files .

Interface layer: encapsulates the functions provided by the optimization-de-optimizer, behavior interpreter, and model builder. At the same time, it also provides the interfaces required for deserialization activities, such as finding objects based on addresses and converting given objects to addresses.

In the prototype realized by the example of the present invention, two mobile application behavior runtime models can be generated: 1) a refined model that includes runtime data dependency; 2) a simplified model that does not include runtime data dependency. Based on the implementation of the system layer, in the framework layer, Reflectall includes a set of behavior reflection interfaces that can monitor the activities of applications with different granularities and generate runtime models of different granularities of application behavior; a set of remote debugging connection interfaces that can control application activity monitoring Start and end. At the application layer, the interface of the framework layer is encapsulated to realize an Android application, which can provide a remote debugging interface in the form of a Web service.

The analysis and code generation subsystem of Reflectall is a browser-server architecture. The analysis and code generation subsystem implements:

Version management: Use git to manage different versions of mobile applications and interoperability interfaces. At the same time, it supports server-side compilation, and uses the client's interface management application to push the compiled dex bytecode to the client.

Stack model visualization: Provides a tree view and supports keyword-based data dependency analysis.

The interface operation subsystem of Reflectall adds a behavior reflection class loader to the framework layer of the Android open source project, as shown in FIG. 9, which is a structural diagram of the interface operation subsystem of Reflectall, an example of the present invention. When the application process starts, it will check whether there is a loadable behavior reflection interface bytecode file. If there is a behavior reflection interface bytecode file suitable for the current application, it is loaded into the application process through the behavior reflection class loader, and at the same time, the Binder communication mechanism is used to register the interoperability interface provided by the current application with the interface management application. The interface management application provides services such as interface forwarding and status detection. The caller process can realize interoperability with the specified application through the interface management application.

During specific verification, the present invention verifies the performance of the Reflectall model generation with an open source application set containing 69 open source Android applications and a closed source application set containing 39 closed source applications.

The construction cost of the mobile application behavior runtime model is positively related to the number of model activities-the more complex the application and the more activities, the greater the cost of generating the behavior runtime model. Compared with closed source applications, open source applications are far less complex in implementation than closed source applications. The median of the number of classes in the open source application set is 58 and the median of the number of methods is 246; the number of application classes in 75% of the open source application sets is no more than 167; the number of methods is no more than 859 . For applications in the closed-source application set, the median number of application classes is 14,266, and the median number of methods is 87717, which is 245 times and 102 times the corresponding values in the open source application set. The hardware configuration used in the experiment is as follows: 1) Use the Android smartphone Redmi 2A, its CPU is 1.5GHz, the memory is 1GB, and the Android operating system version is 5.1.1. 2) The experiment uses an ordinary PC as a remote control The terminal controls the mobile phone for experiments. The PC's CPU is Intel Core i5 3427U (1.8GHz), the memory is 4GB, and it runs OSX 10.11.

At present, in addition to the method of implementing the behavior interpreter described in the present invention, the method of monitoring application execution flow also includes two methods of runtime meta-message binding and compile-time bytecode reconstruction. Table 2 shows the granularity of activity monitoring supported by the three methods. Reflectall is more granular in activity monitoring than the method based on runtime binding: it supports activity monitoring up to the instruction level; at the same time, it has a wider range of adaptation than the method based on bytecode reconstruction: based on bytecode reconstruction The method needs to modify the compilation process of the original application, and it is difficult to directly use it on obfuscated and hardened applications.

Table 2: Comparison of methods for monitoring program execution flow

To	Granularity of execution process monitoring	Do you need bytecode
Reflectall	Support method level and instruction level monitoring	Not needed
Method based on runtime binding	Support method level monitoring	Not needed
Method based on bytecode reconstruction	Support method level and instruction level monitoring	need

In experiment 1, the present invention compares the performance of Reflectall and the method based on runtime binding in monitoring program execution flow. In Experiment 2, the performance of Reflectall and the method based on bytecode reconstruction in monitoring the activity of instruction granularity were compared.

Experiment 1: Compare the method of runtime meta-message binding

Xposed framework is a framework service that can monitor and modify the running behavior of the program without modifying the APK (rovo89, 2012). Similar to Reflectall, the Xposed framework is also modified on the system layer of the Android operating system. The Xposed framework implements the behavior reflection of the meta message model, that is, Xposed binds the corresponding meta object to the specified method according to the configuration when the application is running. In the subsequent execution, these methods bound to the meta-object will call the before and after methods in the meta-object before and after execution. This article uses the Xposed framework to implement an Xposed module that monitors program execution similar to Reflectall. In this section, the application startup time is used as an indicator. Reflectall and Xposed-based monitoring modules are deployed on two Redmi 2A phones with the same hardware configuration. The Android operating systems are both 5.1.1. Through the following 6 different experimental scenarios, compare the performance of Reflectall and the method based on the Xposed framework to monitor the execution of all application classes of the application on the open source application set and the closed source application set, as shown in Table 3. In each scenario, each application was launched 10 times, and the results of the experiment are shown in Figure 10.

Table 3: Comparison of methods for monitoring program execution flow

Figure 10(a) shows the experimental results on the open source application set. In the open source application set, 69 applications can be started normally in the above 6 scenarios. The solid lines in Figure 10(a) are the three scenarios where Reflectall is deployed; the dotted lines are the three scenarios where the Xposed framework is deployed. Without monitoring the program execution process, the average startup time of the mobile phone deployed with Reflectall (scenario 1) is 392 milliseconds, while the platform startup time of the mobile phone deployed with the Xposed framework (scenario 3) is 449 milliseconds. This is because even if the implementation of the Xposed framework does not bind meta objects, there will be a certain overhead when the application is loaded. Reflectall's optimization-de-optimizer realizes that all code is executed in the native executor when it is not monitored. In Scenario 2, the average startup time of Reflectall is 486 milliseconds, which is 23% more than the unmonitored situation (392 milliseconds). The Xposed framework-based method has an average startup time of up to 2078 milliseconds in Scenario 2. Compared with the unmonitored situation (449 milliseconds), the additional overhead is 368%. When generating more complex behavioral runtime models (Scenario 3 and Scenario 6), the additional overhead of Reflectall is only 27%, while the method based on the Xposed framework is as high as 477%.

Figure 10(b) shows the experimental results on the closed source application set. In the non-monitoring scenario, compared to implementing simple open source applications, the average startup time of closed source applications is 936 milliseconds (Reflectall) and 1010 milliseconds (Xposed). In scenario 2, due to the complexity of the application, Reflectall has 3 applications that are unresponsive, and the average startup time of the remaining 36 applications is 1601 milliseconds, which is 71% more than the unmonitored scenario (936 milliseconds). In Scenario 4, 22 applications are unresponsive, and the average startup time of the remaining 17 applications is 4593 milliseconds. Compared with the unmonitored scenario (1010 milliseconds), the additional overhead is 355%. When generating more complex behavioral runtime models (Scenario 3 and Scenario 6), the additional overhead of Reflectall is 98%, while the method based on the Xposed framework is as high as 470%.

The performance of Reflectall’s generated behavior runtime model is quite different from that of the open source application set and the closed source application set. This is because the implementation of the closed source application set is more complex, so the generated model scale is also larger, which may cause multiple The process of garbage collection and activity persistence, which brings more performance overhead. The Xposed-based method has similar costs in these two application sets. The reason is that when Xposed is used for monitoring, 22 applications are unresponsive, accounting for 57% of the entire closed-source application set. One of the main reasons why Reflectall’s performance overhead is lower than the Xposed framework-based method is that the Xposed framework-based method uses Java, and the behavior interpreter programming language implemented by Reflectall is C++. When the execution process of the application is more complicated, the memory allocation and recovery based on the Xposed framework will be more frequent than Reflectall. The above experiments show that this implementation of Reflectall of the present invention can handle more complex applications.

Experiment 2: Compare methods based on bytecode reconstruction

Many commonly used Java libraries use bytecode reconstruction frameworks. A very important use scenario for bytecode reconstruction is program analysis. For example, the popular bug location tool FindBugs uses ASM at the bottom to analyze bytecode and locate vulnerabilities. Another common usage scenario is to use bytecode reconstruction to generate code coverage reports for programs, such as Emma (Roubtsov, 2005) and JCover (JCover, 2017). The condensed model generated by Reflectall can be converted into a code coverage report. This experiment will compare the difference between Reflectall and Emma in generating code coverage reports. Because the method based on bytecode reconstruction is not suitable for closed source applications that only have application installation packages. Therefore, this part is only for open source application sets. This implementation still uses the application startup time as an indicator. Reflectall and an unmodified Android system are deployed on two Redmi 2A phones with the same hardware configuration. The Android operating systems are both 5.1.1. In this experiment, install the original application on the mobile phone where Reflectall is deployed; install the application plugged in by Emma on the unmodified Android phone. In the following 3 different experimental scenarios, compare Reflectall and Emma to generate code on the open source application set Cover the performance of the report. In each scenario, each application was launched 10 times, and the results of the experiment are shown in Figure 11.

Experimental results show that the average startup time of Reflectall and Emma applications is close, the average startup time is 442 milliseconds and 455 milliseconds, and the additional overhead is 13% and 16%, respectively. But from the code coverage information generated, Reflectall is more abundant than Emma. Table 4 shows the difference between Reflectall's monitoring granularity and deployment operation in the code coverage report. Emma's reporting of block coverage may be inaccurate, and does not support the number of branch executions, while Reflectall's behavioral interpreter can guarantee the accuracy of coverage reports, and it also implements branch instructions (such as If-gt, Packed-Switch) Statistics of the number of executions of each branch. Another difference is that Emma needs to be configured to reconstruct the bytecode, and repackaging is required after reconstruction; Reflectall does not require these configurations and will not change the compilation process of mobile applications. Therefore, Reflectall is more usable and practical than Emma-based tools such as bytecode reconstruction.

Table 4: Comparison of monitoring granularity between Reflectall and Emma

Comparison category	Emma	Reflectall
Class coverage	stand by	stand by
Method coverage	stand by	stand by
Block coverage	Partial support	stand by
Branch coverage	Partial support	stand by
Line coverage	stand by	stand by
Number of branch executions	not support	stand by
Instruction coverage	not support	stand by
Do you need bytecode	need	Not needed
Need to repack	need	Not needed

In summary, the method of constructing a runtime model of terminal application behavior provided by the present invention can regard the execution of the application as a programming language framework (such as an interpreter, virtual machine), and read the memory according to the code segment of the application. Write operation. What kind of method is executed can correspond to the operation of the programming language framework on the stack; what kind of object data is modified can correspond to the operation of the programming language framework on the heap. It realizes flexible and complete monitoring of terminal application application behavior, and provides technical guarantee for subsequent realization of instruction-level control of terminal application application behavior. The computational reflection engine designed according to this method can be used as a stand-alone operating environment, and can also be integrated into various mainstream development platforms or commercial software to provide developers with the basic ability to monitor application runtimes.

The above-mentioned embodiments are only preferred embodiments, and are not intended to limit the scope of protection of the present invention. Any modification, equivalent replacement and improvement made within the spirit and principle of the present invention shall be included in the scope of protection of the present invention. .

The device embodiments described above are merely illustrative. The units described as separate components may or may not be physically separated, and the components displayed as units may or may not be physical units, that is, they may be located in One place, or it can be distributed to multiple network units. Some or all of the modules may be selected according to actual needs to achieve the objectives of the solutions of the embodiments. Those of ordinary skill in the art can understand and implement it without creative work.

The various component embodiments of the present invention may be implemented by hardware, or by software modules running on one or more processors, or by their combination. Those skilled in the art should understand that a microprocessor or a digital signal processor (DSP) may be used in practice to implement some or all of the functions of some or all of the components in the computing processing device according to the embodiments of the present invention. The present invention can also be implemented as a device or device program (for example, a computer program and a computer program product) for executing part or all of the methods described herein. Such a program for realizing the present invention may be stored on a computer-readable medium, or may have the form of one or more signals. Such signals can be downloaded from Internet websites, or provided on carrier signals, or provided in any other form.

For example, FIG. 12 shows a computing processing device that can implement the method according to the present invention. The computing processing device traditionally includes a processor 1010 and a computer program product in the form of a memory 1020 or a computer readable medium. The memory 1020 may be an electronic memory such as flash memory, EEPROM (Electrically Erasable Programmable Read Only Memory), EPROM, hard disk, or ROM. The memory 1020 has a storage space 1030 for executing the program code 1031 of any method step in the above method. For example, the storage space 1030 for program codes may include various program codes 1031 for implementing various steps in the above method. These program codes can be read out from or written into one or more computer program products. These computer program products include program code carriers such as hard disks, compact disks (CDs), memory cards or floppy disks. Such a computer program product is usually a portable or fixed storage unit as described with reference to FIG. 13. The storage unit may have storage segments, storage spaces, etc., arranged similarly to the memory 1020 in the computing processing device of FIG. 12. The program code can be compressed in an appropriate form, for example. Generally, the storage unit includes computer-readable codes 1031', that is, codes that can be read by, for example, a processor such as 1010. These codes, when run by a computing processing device, cause the computing processing device to execute the method described above. The various steps.

The term "one embodiment", "an embodiment" or "one or more embodiments" referred to herein means that a specific feature, structure or characteristic described in conjunction with the embodiment is included in at least one embodiment of the present invention. In addition, please note that the word examples "in one embodiment" herein do not necessarily all refer to the same embodiment.

In the instructions provided here, a lot of specific details are explained. However, it can be understood that the embodiments of the present invention can be practiced without these specific details. In some instances, well-known methods, structures and technologies are not shown in detail, so as not to obscure the understanding of this specification.

In the claims, any reference signs placed between parentheses should not be constructed as a limitation to the claims. The word "comprising" does not exclude the presence of elements or steps not listed in the claims. The word "a" or "an" preceding an element does not exclude the presence of multiple such elements. The invention can be implemented by means of hardware comprising several different elements and by means of a suitably programmed computer. In the unit claims enumerating several devices, several of these devices may be embodied by the same hardware item. The use of the words first, second, and third, etc. do not indicate any order. These words can be interpreted as names.

Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, not to limit them; although the present invention has been described in detail with reference to the foregoing embodiments, those of ordinary skill in the art should understand that: The technical solutions recorded in the foregoing embodiments are modified, or some of the technical features are equivalently replaced; these modifications or replacements do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present invention.

Claims (12)

1. A method for constructing a runtime model of a terminal application behavior, characterized in that the runtime model includes a runtime stack model and a runtime heap model, and the method includes the step of constructing a runtime stack model of the terminal application behavior And the step of constructing a runtime heap model of the terminal application behavior;

   The step of constructing the runtime stack model of the terminal application behavior includes:

   When the terminal application is running, obtain the actually executed code in the memory of the terminal application, and abstract the actually executed code to generate a control flow graph;

   For the control flow graph, input the control flow graph to be monitored into a preset behavior interpreter;

   Use the behavior interpreter to interpret and execute the control flow graph that needs to be monitored, and generate stack activities when the terminal application is running;

   When the terminal application is running, generate the dependency between the control flows of the stack activity, and obtain the runtime stack model of the terminal application behavior;

   The step of constructing the runtime heap model of the terminal application behavior includes:

   Generating the initial state of the heap area when the terminal application is running;

   A heap operation activity is generated, and a runtime heap model of the terminal application behavior is obtained.
2. The method of claim 1, wherein the method comprises a class filter and an activity type filter; wherein, the class filter is based on a coarse-grained filter based on regular matching of package and class names, and is used to remove developers Program activities that are not concerned; the activity type filter is based on fine-grained filtering of activity types, and is used to remove activity types that are not concerned with the developer.
3. The method according to claim 2, wherein the activity type of the stack activity includes method start and method end, field read, array read and synchronization instructions;

   The steps of using the behavior interpreter to interpret and execute the control flow graph that needs to be monitored, and generating the stack activity when the terminal application is running include:

   Interpret and execute the control flow graph that needs to be monitored by using a behavior interpreter that has a monitoring function for the application behavior of the terminal application, and obtain the activities of the terminal application when the terminal application is running;

   According to the class of interest, use the class filter to perform coarse-grained screening of the activities of the terminal application during runtime, and generate stack activities caused by the class;

   For the activity type of the stack activity, the activity type filter is used to perform fine-grained screening of the stack activity.
4. The method according to claim 1, wherein the step of constructing a runtime heap model of the terminal application behavior comprises:

   The activities when the terminal application is running include instantiation activities, modification activities and recycling activities.
5. The method according to claim 2, wherein the activity types of the heap operation activity include object instantiation, array instantiation, object field writing, array element writing, clearing activity and compression activity;

   The steps of generating a heap operation activity include:

   According to the class of interest, use the class filter to perform coarse-grained screening of the terminal application runtime activities to generate heap operation activities caused by the class;

   For the activity type of the heap operation activity, the activity type filter is used to perform fine-grained screening of the heap operation activity.
6. The method according to claim 1, wherein the dependency relationship includes synchronization dependency and communication dependency.
7. The method of claim 6, wherein when the synchronization dependency between the control flows is generated, for the case where the end of one method depends on the end of another method, the timestamp is used to find other threads from back to front. The matching activity, if found, corresponds to a synchronization dependency; for the case where the start of one activity depends on the end of another activity, the current thread is checked first, if the activity is the first activity executed in the current thread , The activity is dependent on another thread to end the activity, otherwise the activity is just a normal method call and does not depend on the activity of another thread.
8. The method according to claim 6, wherein when generating the dependency between the control flow of the stack activity, all the classes related to the communication dependency between the activities are summarized, and the related methods of the class are compared with Thread dependency related methods together serve as a knowledge base for generating communication dependencies.
9. The method according to claim 1, wherein when the runtime model is generated, the sequence of activities in the runtime model is stored in a buffer with a configurable size, and when the number of activities exceeds a preset value, Then the activities of the buffer are serialized and persisted to local storage.
10. The method of claim 1, wherein the runtime heap model is expressed in the form of Backus paradigm.
11. A computer program comprising computer readable code, which when run on a computing processing device, causes the computing processing device to execute the voice processing method according to any one of claims 1-10.
12. A computer readable medium in which the computer program according to claim 11 is stored.

Images