CN110362363B

CN110362363B - Method for realizing terminal application control based on runtime model

Info

Publication number: CN110362363B
Application number: CN201910498732.0A
Authority: CN
Inventors: 张颖; 黄罡; 蔡华谦; 刘譞哲
Original assignee: Peking University
Current assignee: Peking University
Priority date: 2019-06-10
Filing date: 2019-06-10
Publication date: 2021-03-12
Anticipated expiration: 2039-06-10
Also published as: WO2020248511A1; CN110362363A; WO2020248511A9

Abstract

The invention discloses a method for realizing terminal application control based on a runtime model, which realizes the decomposition of a complex application behavior model and operable model segments by defining the operation on the runtime model and the equivalence of the influence of the model segments on a stack area and a stack area, establishes the causal association of the behavior model, an application state and an application code based on the decomposed model segments, and realizes the control of the instruction level of the application behavior of a terminal application during the runtime.

Description

Method for realizing terminal application control based on runtime model

Technical Field

The invention relates to a computer technology, in particular to a method for realizing terminal application control based on a runtime model.

Background

The internetware (also called terminal application) is an abstraction of the basic form of a software system in the open, dynamic and variable environment of the internet, is a natural extension of the traditional software structure, and has unique basic characteristics different from the traditional software form developed in the centralized packaging environment: 1) autonomy refers to relative independence, initiative and adaptivity of software entities in the internetware system. Autonomy distinguishes it from the dependencies and passivity of software entities in traditional software systems; 2) the cooperativity refers to interconnection, intercommunication, cooperation and alliance between software entities in the internetware software system under the open network environment according to a plurality of static connection and dynamic cooperation modes. The cooperativity makes the system different from a single static connection mode of a traditional software system in a closed centralized environment; 3) and the reactivity means that the internetware has the capability of perceiving the external operation and use environment and providing useful information for the system evolution. The responsiveness enables the internetware system to have the sensing capability of adapting to open, dynamic and changeable environments; 4) the evolution means that the network software structure can dynamically evolve according to the application requirements and the network environment changes, and mainly shows the variability of the number of elements, the adjustability of the structural relationship and the dynamic configurability of the structural form. The modeling enables the internetware system to have the strain capacity of adapting to open, dynamic and variable environments; 5) polymorphism, meaning the effect of an internetware system, represents compatible multiobjective. It can satisfy multiple compatible target forms under the dynamically changing network environment according to some basic cooperation principles. Polymorphism enables the internetware system to have certain flexibility and the capability of meeting personalized requirements under the network environment.

The implementation of the above described internetware features often requires modification of the software in the running state to ensure or improve quality, optimize or add new functions. Classical software engineering methods and techniques emphasize modifying software in the development state and do not support direct modification of software in the run state.

Correspondingly, system software such as programming languages, operating systems, middleware, and the like provide a common main mechanism for running state monitoring and control applications, namely, computational reflection (reflection). Various development frameworks and testing frameworks can be realized based on the computing reflection, so that the efficiency of developers in code development, testing and even running deployment is improved. In the computer field, b.smith gives a general definition of reflectivity: reflexibility is the ability of an entity to describe, manipulate and process itself in the same way as the main problem domain faced by the entity. This definition is subsequently interpreted as: reflexibility is the ability of a program to manipulate a set of data at runtime, which describes the running state of the program, the manipulation having two implications: 1) monitoring (Introspection), the program can observe and reason about its own state; 2) control (interaction), the program may change its operation or semantics. Both aspects require that the state of program execution be encoded as data, and providing such encoding is referred to as reflection, i.e., reflection essentially maps the running state of a program to a set of operational data. The former part constitutes a base layer entity, the latter part constitutes a meta-layer entity, and causal association is maintained between the base layer entity and the meta-layer entity. The calculated reflection is mainly divided into a structural reflection and a behavioral reflection according to the difference of basic entities. The basic entity of the structure reflection is the current program and its abstract data type (which can be regarded as the state of the application), and the basic entity of the behavior reflection is the execution behavior of the current program and the data required by the execution (which can be regarded as the behavior of the application).

Structural reflection refers to the ability of a programming language to provide reflection of current programs and their abstract data types, which is inherent in most programming language frameworks (runtime or framework) due to its natural existence in analogy with the capabilities of the programming language frameworks.

Behavior reflection refers to the ability of a programming language to provide data reflection on its execution semantics and its execution, i.e., the programming language framework itself needs to be reflected, behavior reflection faces two challenges in monitoring and control: for one, it is necessary to fully describe the existing application behavior, i.e. to monitor the execution of the application. The execution of the application can be regarded as a set of runtime activities, the finer the granularity of the activities is, the richer the monitored information is, the larger the resources occupied by the monitoring function is, and the more serious the resource competition between the monitoring function and the business logic is. At this time, the complexity and scalability of application behavior monitoring becomes a primary challenge for end-application behavior reflection. Secondly, the behavior reflection of the existing programming language, the operating system, the middleware and other system software does not support the behavior control at the instruction level, and the fundamental reason is the complex data and control dependence contained in the instruction sequence, so the instruction level control of the application behavior becomes the main difficulty of the behavior reflection of the terminal application.

Disclosure of Invention

The main purpose of the present invention is to provide a method for implementing control of terminal application based on a runtime model, which overcomes the second challenge and implements instruction level control of terminal application behavior.

The invention is realized by the following technical scheme:

in order to solve the above technical problem, the present invention provides a method for implementing control on a terminal application based on a runtime model, where the runtime model includes a runtime stack model and a runtime stack model, and the method includes:

predefining the equivalence of the operation of the runtime model and the influence of the model fragments on the stack area;

converting the runtime model keeping the equivalence, and decomposing the runtime model to obtain a group of operable model segments;

and establishing causal association among the runtime model, the application state and the application code according to the decomposed model segments so as to control the terminal application behavior.

Further, the runtime model includes a set of activities with logical associations that occur over a period of time;

the predefined operations on the runtime model include:

adding, for adding a part of program activities in the original activity execution flow;

deleting the program, wherein the deleting is used for eliminating the influence of the activities executed in the original activity execution flow on the program;

and modifying, after eliminating the effect of the original activity, to re-execute the modified activity.

Further, the controlling the terminal application behavior includes performing behavioral control and/or structural control on the terminal application behavior.

Further, the step of performing behavioral control on the terminal application behavior includes:

setting a memory initial state S and an activity sequence A of a terminal application;

after a period of execution, obtaining the memory state after the operation as S · a ═ S ', and obtaining the active sequence after the equivalence of the model during the operation is converted as a', and obtaining the target state as s.a ═ S ";

and solving the incremental activity sequence A by using the S.A ═ S.A. "A ═ S '. A", so that A + A ═ A', and finishing the process of performing behavioral control on the terminal application behaviors.

Further, the incremental activity sequence a "includes: control transfer, arithmetic operation, field reading, array reading, class instantiation, array instantiation, field assignment, array assignment, thread synchronization, garbage collection, method invocation, and class loading.

Further, the step of performing structural control on the terminal application behavior includes:

acquiring a runtime model M of terminal application behaviors, a group of operations and a converted activity sequence A';

mapping the set of operations to a piece of object code such that an activity sequence A 'resulting from execution of the object code maintains a control equivalence relation with an activity sequence A'.

Further, for any activity, mapping the set of operations to a piece of object code comprises:

acquiring data dependence so that the data dependence of the activity execution is the same as the activity occurrence time;

the activity is converted into corresponding object code.

Further, the data dependency comprises a value type and an object type;

for an activity, when the data type of the activity is a numerical value type, directly adopting a corresponding numerical value when the activity in the runtime model is executed;

for an activity, when the data type depended on by the activity is an object type, the activity is divided into a local object and a global object; when the data type depended on by the local object is a local object, generating a code for constructing the local object by playing back activities related to the object; when the data type of the dependency is a global object, a group of reachable object reference chains are constructed through program analysis to obtain the object, and the code related to the dynamic data dependency is automatically generated according to the reference type between the objects.

Further, the construction of the local object comprises a local object construction constructed based on the activity sequence and a local object construction constructed based on the runtime heap model.

Further, the global object is obtained according to a reference chain in the runtime heap model.

Compared with the prior art, the method realizes the decomposition of the complex application behavior model by defining the operation on the runtime model and the equivalence of the influence of the model segment on the stack area and the stack area, can operate the model segment, establishes the causal association of the behavior model, the application state and the application code based on the decomposed model segment, and realizes the control of the instruction level of the application behavior of the terminal application when the terminal application runs.

Drawings

Fig. 1 is a prior art 3G radio resource control state machine;

FIG. 2(a) is a schematic diagram of the flow of control of network requests before merging in an example of merging of network requests;

FIG. 2(b) is a schematic diagram of a flow of control of a merged network request in an example of merging network requests;

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

FIG. 4 is a flowchart illustrating steps of a method for implementing control of a terminal application based on a runtime model according to an embodiment of the present invention;

FIG. 5 is an example of a stack model for automatically reconfiguring an implementation network request schedule;

FIG. 6(a) is a schematic diagram of a user-oriented graphical interface messaging execution flow;

FIG. 6(b) is a schematic diagram of an execution flow of an interoperation-oriented messaging interface;

FIG. 7 is a schematic diagram of an exemplary refletall model generation subsystem architecture of the present invention;

FIG. 8 is a schematic structural diagram of an interface operation subsystem of an example refletall of the present invention;

FIG. 9(a) is a diagram of the original classes of an exemplary calculator of the present invention;

FIG. 9(b) is an exemplary modified class diagram of the present invention.

Detailed Description

In order to make the objects, technical solutions and advantages of the present invention more apparent, the present invention will be further described in detail with reference to the following embodiments and the accompanying drawings.

In order to better understand the technical problem of the application, the invention adopts the application function evolution scenes of two typical cases to analyze, so as to determine the root cause of the inapplicability of the existing behavior reflex.

Case one:

with the development of smart phones, mobile applications of terminals increasingly rely on software and hardware resources provided by a cloud to provide better services. However, the communication between the cloud and the terminal consumes a large amount of power. The networking application (such as weather, mail, news and the like) presents the typical componentization characteristics of the internetware, and the communication between the terminal and each component in the cloud is realized by utilizing the network. Particularly, under the 3G/4G environment, the networking application acquires corresponding push messages by utilizing the network at intervals for a long time in the background. Such long-time, intermittent message pushing puts a great strain on the endurance of smartphones with limited battery capacity. 3G and 4G are mobile cellular networks which are currently used in mainstream, and the power consumption characteristics of the mobile cellular networks are more complex. On the one hand, because cellular networks are highly mobile, it is possible for a mobile device to quickly handoff to a different cellular network base station as the physical location moves. Thus, it is not possible for a cellular network base station to always allocate a channel to a mobile device. On the other hand, as the mobile device has limited endurance and is connected to the cellular network base station for a long time, the power consumption of the mobile device is greatly increased, and the endurance is affected. Therefore, in the cellular network standard, the state of a Radio Resource Control (RRC) module is further defined.

Taking the 3G network module in the mobile device as an example, a total of three states are included, as shown in fig. 1.

(1) IDLE: i.e. an idle state in which the 3G module consumes the lowest power and cannot transmit or receive any data. In this state, if data is to be transmitted or received, a transition is made to the CELL _ DCH state.

(2) CELL _ DCH: in this state, the bandwidth of the 3G module is maximized, where data transmission can be performed at the maximum rate, while its power consumption is maximized. If there is still no data transmission for a while, it transitions to the CELL _ FACH state. The time for continuously operating in the CELL _ DCH state is typically 5 to 10 seconds, depending on the settings of different operators.

(3) CELL _ FACH, in this state, the power consumption of 3G module is saved by 50% compared with CELL _ DCH, and at the same time, the network transmission rate is lower. If the data sent or received in this state is greater than a certain threshold, the state will be transferred back to the CELL _ DCH state. And if no data is transmitted or received for a while in the CELL _ FACH state, it is transferred to the IDLE state. Typically this time is typically 10 seconds to 15 seconds.

Figure 2 shows an example of network request consolidation. FIG. 2(a) shows network request and power consumption of the wireless communication module before merging, with time on the horizontal axis and power consumption of the wireless communication module in the upper half; the dotted line in the lower half is the thread initiating the two network requests; the solid line in the lower half represents the control flow thereof. Firstly, a background news pushing thread wakes up a thread (I) responsible for sending a network request; after the thread is awakened, a network request is initiated, and at the moment, the power consumption of the wireless communication module is changed from low power consumption in an IDLE state to high power consumption in a CELL _ DCH state; after the whole request is completed, the thread responsible for sending the network request returns the result to the news pushing thread (c), at this time, although the wireless communication module does not receive or send data, the wireless communication module still keeps in a high power consumption state, and the power consumption of the wireless communication module from this beginning is called 'tail time power consumption', and corresponds to a diagonal line part used in fig. 2 (a); and after receiving the returned result, the news pushing thread processes the result and prompts on the notification bar. After a while, another version update thread also executes a similar logic sixth, and sends a network request. As shown in fig. 2(a), since the two network requests are separated by several tens of seconds, the wireless communication module is woken up twice, and there are two corresponding "tail times", thereby causing additional network energy consumption.

For android applications, a significant portion of background requests can be delayed for tens of seconds, or even two or three minutes, without affecting the user experience. Such as the above-described newsfeed, version update push, and the like. For these network requests, the "tail time" network power consumption can be reduced if the merging is done in the time dimension, i.e. two requests are sent simultaneously, instead of being sent several tens of seconds apart. Fig. 2(b) shows the power consumption of the wireless communication module and the control flow obtained by combining the two requests in fig. 2 (a). First, after the thread responsible for sending the network request is awakened by the newsfeed thread, the network request is not sent directly, 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 wait state. And ninthly, after the waiting state is finished, the two threads simultaneously send network requests, and the corresponding wireless communication modules are awakened once. As shown in fig. 2(b), the power consumption of the merged network request is much smaller than that of the network request before merging.

In order to implement network request merging, 1) a network request scheduling mechanism is needed, i.e., the network request which is originally and directly sent can be delayed to be sent; 2) a network request scheduling algorithm finds out the request which can be delayed and scheduled, and utilizes the scheduling mechanism to delay the transmission. The network request execution logic for automatically reconstructing the mobile application can be realized by utilizing the structural reflection, and a scheduling mechanism is built in the application. However, this requires that developers of different applications all use the same auto-reconfiguration framework and that all applications need to be recompiled, deployed and run. This is clearly not practical for a large number of closed-source applications that belong to different application developers.

Case two:

with the popularization of the WeChat, the WeChat not only is a simple communication application, but also becomes a necessary tool for work communication; the WeChat friend circle and the public number are used for marketing; becomes the largest self-media publishing platform. The core of the WeChat is used as a communication tool, and the function of the WeChat is mainly to meet the requirement of common users. Even so, it is difficult to satisfy the specific needs of the general users. For example, as WeChat is used for a longer time, the cached chat log file is also larger, and it is difficult for a common user to manage the chat log of the user. Further, it is difficult for wechat to meet the specific needs of a particular group of westerners, self-media people, etc. To implement open sharing of data and functions in a WeChat application, a user-oriented user interface needs to be converted into an interoperation-oriented programmable interface. Generally, for user-oriented user interface, the execution starts with operations such as clicking, dragging, and inputting of user interface elements. Through partial logic processing, external resources are accessed in the modes of network request, database query and file reading and writing, and corresponding data are acquired or corresponding functions are realized. In this process flow, most of the logic is similar to the execution logic of the interoperation-oriented programmable interface, except that the start of its execution is different. However, the granularity of existing behavioral reflex monitoring and control is at the method level. Based on the existing behavior reflection, the method of inserting some execution logic into the execution flow of the existing application is difficult to realize the conversion of the user interface facing the user into the programmable interface facing the interoperation: existing functions may correspond to a set of program activities at runtime, with method-granular behavior reflecting that its monitored content is limited, unable to monitor execution of instructions within the method, and then, unable to control. This has led to existing solutions often being based on existing code and documentation, and the flow of developers, the absence of documentation, and even irregular annotation of source code, can make iterative development of mobile applications difficult for a development team.

It can be seen from the above two case analyses that the fundamental reason for the difficulty in implementing the mobile application interoperation interface is that the existing work lacks a complete and detailed description of the application behavior, and there is no way to control the self-description of the instruction granularity.

The monitoring of the behavior reflection can be realized by using the existing related monitoring technology, such as monitoring by using an Xposed framework, wherein the Xposed framework is a framework service (revolute 89,2012) which can monitor and modify the program running behavior without modifying the APK. This part belongs to the prior art, and does not belong to the focus of the present invention, and will not be described herein. However, the control of behavioral reflex is less in the prior art, and thus the approach to self-described control of such instruction granularity is a difficult and critical issue for the present invention.

In view of the above technical problems, an embodiment of the present invention provides a method for implementing control on a terminal application based on a runtime model, where the runtime model includes a runtime stack model and a runtime stack model.

After the application runs in the operating system, which may be referred to as one or more processes, the operating system loads the executable files needed by the mobile application into memory and begins execution. Generally, the memory occupied by a process can be divided into three regions:

a code segment: a memory area for storing the execution code, having read-only properties;

stacking area: the method can be divided into a memory area (data segment) for storing global variables and a memory area for dynamic allocation in process running, for example, in object-oriented programming language Java, a thread creates a new object which is equivalent to applying for a memory in a heap area;

a stack area: for temporary storage of local variables, etc. For example, in object-oriented programming language Java, when a thread calls a method, a frame (frame) is newly applied, and data such as parameters required by the method is stored in the frame.

The inventors have carefully studied that, when the terminal application runs, the execution of the code segment may cause the memory data in the stack area and the stack area to change. The runtime model of an application needs to be able to reflect the application's: 1) execution of the code: during development, the code of the mobile application can be abstracted into a control flow graph, and then corresponding to the operation, the execution condition of the code can be abstracted into one or more paths of the control flow graph; 2) change of memory data (e.g., heap area): at development time, a developer designs various Data structures to represent the Data Model (Data Model) of an application, and at runtime, execution of code causes creation, modification, deletion of instances of these Data structures, i.e., allocation and modification operations corresponding to a set of memory. From a memory area perspective, the most significant areas affected by program execution are the stack and heap areas of memory. 1) The path in the control flow graph in (1) can be regarded as a description of stack change, and the change of heap area data is mainly reflected in (2).

Thus, the application runtime model constructed by the present invention includes a runtime stack model that describes stack changes and a runtime heap model that describes heap changes. The runtime stack model also comprises code acquisition, so that the memory occupied by one process is completely divided into three areas. By the runtime stack model of the embodiment of the invention, the code execution condition of the mobile application at any moment can be known; while through the runtime heap model, the state of the object data on which code execution depends at any time can be known.

Runtime stack model

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

wherein B ═ B₁，b₂，…，b_nIs a basic block;

is a control flow path;

for arbitrary p_i＝(b_i1，b_i2)，p_iE P, if and only if b_i2Possibility b_i1And then executed. At run-time, the control flow graph is instantiated into one or more control flows and the basic blocks are executed according to paths in the control flow graph. The invention refers to the basic block executed at a certain moment as the activity, and the runtime stack model in a period of time is composed of a control flow graph, one or more control flows and a group of activity sequences. When the granularity of a basic block is instruction granularity, the active sequence is an instruction execution sequence. The following presents a formal definition of the runtime stack model described in the present invention.

Defining a runtime stack model as a set of one or more activities of a control flow that occur over a period of time, m ═ G, T, a, I, E >,

wherein G ═<B，P>To control a flow graph, T ═ T₁，t₂，…，t_nI ═ I, a set of times₁，i₂，…，i_nDenotes t₁To t_nHeap status of the program at time.

Let F be F₁，f₂，…，f_nA set of control flows, then a-F x I x T x B is the set of activities that occur over a period of time,

representing a set of contexts in which two activities occur.

Operation ofThe runtime stack model may be viewed as a collection of multiple paths of the control flow graph, and therefore, edges in the runtime stack model must have corresponding edges in the control flow graph. Namely:

wherein a is_i＝(f_i1，t_i2，b_i3)，a_j＝(f_j1，t_j2，b_j3)a_j＝(f_j1，t_j2，b_j3) Is given by_i3，b_j3) E.g. P. In addition, the edges of the runtime stack model represent the context in which two activities occur, and for two activities in the same control flow, there is a chronological order; if an edge exists for two activities in different control flows, it indicates that there is also a dependency between the two activities.

If two activities have a tandem relationship in the same control flow, it is not possible for any other activity to occur between the two activities in the same control flow, i.e.

Wherein a is_i＝(f_i1，t_i2，b_i3)，a_j＝(f_j1，t_j2，b_j3) If f is_i1≠f_j1Then, then

In different control flows, if two activities have a pre-post occurrence relationship, then for the control flow in which the next activity is located, after the moment when the previous activity occurs, the other activities may occur first.

Wherein a is_i＝(f_i1，t_i2，b_i3)，a_j＝(f_j1，t_j2，b_j3) If f is_i1≠f_j1Then t is_i2＜t_j2。

Defining program activity a_jSynchronization is dependent on program activity a_iIf a is_jIs started or ended by a_iIs determined, in general, by_iOften some threads operate synchronously. Scale a_jCommunication is dependent on a_iIf a is_jIs a by_iAn activity is generated. Taking 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 run stack model corresponds to an execution sequence of a Java thread. There are six states for state transitions of a thread:

creating: the thread object is just created and is in the state when not started;

operation: a thread is in a running state where it may wait for some system resources, such as a CPU;

blocking, in which a thread is waiting for a monitoring Lock (Monitor Lock), for example, when the thread enters a method for modifying a synchronized keyword or a code block, the thread enters a blocking state;

wait/timed wait-a thread is waiting, for example, when it calls the wait method of an object to enter a wait state. When the notify method of the object is used, the thread can re-enter the running state;

death: when run method execution for a thread is finished, the thread enters a dead state.

From the above state transition, it can be seen that in some cases, one thread in a running state may wake up another thread in a non-running state to enter a running state. The invention refers to the relation between threads as synchronous dependency relation. When these inter-thread wakeups occur, there is an edge across threads (across control flows) corresponding to the activity that occurs for a thread in a running state in the runtime stack model than the activity that occurs when a non-running state thread enters a running state. From the Java language level, these thread dependencies can be reduced into four classes, as shown in Table 1.

Table 1: java language level synchronous dependency classification

In Table 1, the activity of each running thread corresponds to the activity of the non-running thread. Therefore, the inter-thread dependencies in Table 1 are referred to as synchronization dependencies. Based on the state transition of the threads, Java provides various multi-thread programming libraries to support, for example, read-write locks, reentrant locks, blocking locks, thread pools, and the like, provided in Java.

FIG. 3 illustrates an example of communication dependencies between threads-a producer-consumer model. In this example, the Task class represents a computational Task; static field tasks represents a task queue to be processed; the postTask method represents the generation and submission of tasks; the handleTask method represents a processing task. As shown in fig. 3, there are two threads: 1) thread 1 represents a producer thread and submits a task to a task queue to be processed; 2) thread 2 represents a consumer thread that looks at the pending task queue at intervals and processes the corresponding task. In this example, there is no synchronization dependency between the producer thread and the consumer thread — the consumer thread automatically transitions from the timed wait state to the run state at intervals, but there is a communication dependency — if the producer thread does not submit a task, the consumer thread's task run method is not called.

It can be seen from the above example that the generation of the active relationships in the runtime stack model must rely on the corresponding data at runtime. In a classical data flow analysis, a data flow analysis algorithm calculates a data flow equation according to the structure of a control flow graph and iterates to a stable point. Therefore, the runtime model of the application needs a runtime stack model describing the change of the data state of the memory stack area in addition to the runtime stack model.

Runtime heap model

Classical dataflow graphs are often used in the demand analysis phase. Software utilizes a dataflow graph to decompose a software system to be developed from abstraction to concrete layer by layer. The data flow graph is a directed graph and comprises two different types of edges and a plurality of different nodes for describing data from an initial node, and layer-by-layer calculation is carried out to finally obtain a final result. At run-time, a certain node of the dataflow graph essentially corresponds to a change in a set of memory data. Therefore, the heap model of the behavioral runtime model of the application of the present invention focuses on the change of the memory data, not on the changed operation. The heap model during the operation of the invention only models the heap area of the memory during the application operation from the memory data change angle.

The runtime heap model is a set of memory modification activities M ═ D, a, T, R > from a set of initial values of a set of memory data and the heap occurring over a period of time;

wherein D ═ { D ═ D₁，d₂，…，d_nIs the initial value of a set of memory addresses, a ═ i₁，i₂，…，i_nT ═ T, activity that causes memory data changes₁，t₂，…，t_nAnd is a time stamp.

For different object-oriented programming languages, different application programming interfaces are provided to realize dynamic allocation and recovery of memory. For example, C/C + + language, and realizes the allocation and recovery of the memory by providing malloc and free functions in the standard library function; in the Java language, a new object can be created through new keywords to realize the allocation of the memory, and the recovery of the memory is realized through an automatic garbage recovery mechanism.

Through the introduction of the above model, it can be understood that the implementation of flexible control of application behaviors faces challenges of polymorphism and practicality of control: on one hand, since the monitored basic entity is the behavior of the application runtime, the control is embodied as the modification of the runtime behavior, however, each activity in the model is the occurred activity, and how to correctly define the modification of the runtime state; on the other hand, control may also be embodied as implementing partial structural reflection, just as partial behavioral reflection may be implemented using structural reflection, how partial structural reflection is implemented based on behavioral reflection. Due to various compiling optimization technologies, the provided source code often cannot directly correspond to an instruction executed in runtime, and the practicability is not high, so that the framework needs to support applications after compiling optimization.

In view of the above technical problem, how to implement self-described control of such instruction granularity is explained in detail next.

Referring to fig. 4, a flowchart illustrating steps of a method for implementing control of a terminal application based on a runtime model according to an embodiment of the present invention is shown, where the method includes:

step S401: predefining the equivalence of the operation of the runtime model and the influence of the model fragments on the stack area;

step S402: converting the runtime model keeping the equivalence, and decomposing the runtime model to obtain a group of operable model segments;

step S403: and establishing causal association among the runtime model, the application state and the application code according to the decomposed model segments so as to control the terminal application behavior.

In a preferred embodiment of the invention, the runtime model includes a set of activities with logical associations that occur over a period of time;

the predefined operations on the runtime model include:

The definition is as follows:

operation of the application runtime behavior model: let M ═ G, T, a, I, E > be the application behavior runtime model, a ═ (T, I, b), and a ∈ a, the operation set is OpSet ═ { Add, Delete, Transform }, the operation Op ∈ OpSet, where:

Add:A→A∪{a}

Delete:A→A-{a}

Transform:A→A-{a}∪{a′}。

with the three operations described above, modification of a set of activities in an application runtime model can be achieved. The control of the memory by the active sequence is embodied as reading and writing operations of the memory. The same control over memory is possible for two different levels of activity. In the following, the present invention defines the equivalence of control from the perspective of memory state as follows:

stack control equivalence: if the initial state is the same, the end state after the activity sequence A 'is executed and the activity A' is executed is also the same, and the stack control is called that A 'is equivalent to A' and is recorded as

The resulting memory control equivalence is thus defined as follows:

memory control equivalence: if two activity sequences A ', A' satisfy

And is

Then called A 'and A' memory control equivalents, noted

The equivalence of the control of the activity sequence is further illustrated below with the code in case one automatically reconstructing the bytecode to achieve network energy consumption optimization as an example.

Fig. 5 shows that the process of sending a network request is changed from (ii) before reconstruction to (iii) to (iv) (+ v), and the changes of the stacks of the two active sequences are different: this is due to the extra scheduler NetworkStub. Thus, these two active sequences are not stack control equivalents. However, in the process of sending the network request, the change situation of the heap to which the original execution logic is applied is similar: before and after reconstruction, the change of the object related to the application service logic is kept consistent; after reconstruction, objects related to network request scheduling logic are newly added to the heap. Thus, the two activity sequences are heap control equivalents only from the perspective of the objects associated with the application's native execution logic. That is, this automatic reconfiguration is one that achieves the equivalent of heap control. Similar to the example, there is a tool for implementing code coverage report by using automatic reconstruction, such as Emma, JCover, and their applications before and after automatic reconstruction are all the execution sequences before and after reconstruction of any one method that maintains the original application, and the heap control equivalence is maintained. Therefore, the heap control equivalence before and after reconstruction ensures the functional consistency of program execution.

Taking the generation of the interface oriented to interoperation of the WeChat application in case two as an example, the application behavior runtime model for realizing messaging by the existing graphical interface oriented to the user can be abstracted into a sequence diagram as shown in FIG. 6 (a): firstly, triggering an object of an interface layer by a user to send a message (I), and switching and executing an application execution logic between a control layer and a data layer (II → II); when the result returns, the result is notified to the interface layer object. Assuming that fig. 6(b) is an execution flow of the message sending interface oriented to the interoperation, it can be found that, in the two execution flows, (+) and [ - ], that is, in the interaction process between the background thread and the server, the execution of the activity thereof maintains the stack control equivalence and the heap control equivalence. Although the two sequences of activities are not equivalent in controlling the heap throughout the interaction: the interoperation-oriented interface is independent of interface-related elements, while the user-oriented interface is dependent on chat window objects; the control of the stack is also not equivalent: only the user-oriented interface execution process involves a user interface thread.

The above case shows that the consistency of the application service logic before and after reconstruction is ensured by the stack control equivalence of the application execution flow before and after reconstruction, and the functions orthogonal to the service logic are added, such as generating a code coverage report and scheduling a network request. From the control of the structural reflection, on one hand, the essence is to modify the code of the application, thereby affecting the execution flow of the application. On the other hand, behavior reflection, namely monitoring and modification of the application execution flow, can be realized based on the structure. This also means that there are two implications for the control of behavioral reflexes implemented based on behavioral interpreters. On the one hand, the control of behavior reflexes essentially requires modifying the behavior executed by the application. On the other hand, if the behavior sequence at runtime is used as a program, the modification of the application code can also be realized through the modification of the behavior. Thus, control of behavioral reflex also enables structural reflex to some extent. In the following, the classification and definition of the behavior control based on the runtime model according to the present invention are given.

And (3) control classification: an application behavior runtime model may be viewed as a complete sequence diagram of when an application performs a function, which is depicted as a collection of logically related activities that occur over a period of time. If the application runtime model is considered as a set of activities that affect memory, adding, deleting, modifying means modifying the current program running state. If the application runtime model is regarded as a piece of executed code, adding, deleting and modifying means modifying the piece of code, and the control of the application is embodied as generating a new piece of code.

In a preferred embodiment of the present invention, controlling the terminal application behavior includes performing behavioral control and/or structural control on the terminal application behavior. The invention defines the control which directly influences the current application memory as behavioral control, and defines the control which can generate new application codes as structural control.

(1) Behavioral control

Behavioral control emphasizes direct control and modification of the state of the original application, i.e., control of the state and behavior of the original application without generating or writing new code fragments, recompiling, or restarting the application. Behavioral control treats a behavioral runtime model as a set of happened activities, and operating on a behavioral runtime model means modifying the impact of the happened activities of the original application on the memory state.

In the embodiment of the present invention, the step of performing behavioral control on the terminal application behavior includes:

In the following, the incremental activity sequence a "required for behavioral control is given according to the semantics of the add, delete and modify operations of the different activities that occur at runtime: the incremental activity sequence a "includes: control transfer, arithmetic operation, field reading, array reading, class instantiation, array instantiation, field assignment, array assignment, thread synchronization, garbage collection, method invocation, and class loading.

And (3) control transfer: the instructions corresponding to the control transfer activities include if series instructions, switch series instructions, and the like. For a branch control instruction, the effect of execution is to continue execution, or to jump to a branch. If the modification affects the structure of the program, then the externality of the program needs to be considered, i.e. the modification of the control transfer will result in a different series of activities being subsequently performed. However, the behavior control at this time is only to control a single activity, so that, only from the view of the influence on the stack, the instruction influences the calculation of the PC register, and the PC register is the register which changes most frequently — the execution of each instruction causes the PC register to change. The operations of addition, deletion, and modification of the control transfer instruction hardly correspond to the active execution, and therefore, the present invention does not define any operation for the control transfer instruction.

And (3) arithmetic operation: the effect of the arithmetic operation activity is to perform arithmetic operations on certain registers in the stack. An arithmetic instruction may be considered to assign a value to a certain register. For example: the corresponding activity of add-int/2addr Reg1Reg2 at runtime means that an assignment is made to register Reg1, the result of the assignment being the sum of the values of this register and the Reg2 register. The add, delete, modify operations on the activity may be implemented as controls on the target register: add means to Add a register to which the activity is assigned for further assignment; the meaning of Delete is to eliminate the effect of the assignment of the register, i.e. to restore the value of the register; the implication of Transform is the assignment of the registers affected by the modified activity. Add, Delete and Transform all require that the method corresponding to the activity is not executed when the application reaches the S' state. If the method has been executed, the method stack has been destroyed, and the register does not exist.

Reading fields: the area of memory affected by field read activity is the stack. The effect of a field read activity on memory is to read a field of an object in the heap and write to a specific register. Thus, the semantics of addition, deletion, modification of such activities are the same as those of arithmetic operation activities.

Reading an array: the array read activity is close to the field read activity, and the effect on the memory is to read an element from an array in the heap and write to a register. Thus, the semantics of addition, deletion, modification of such activities are the same as those of arithmetic operation activities.

Class instantiation: the memory region affected by this type of activity is the heap. In the Java programming language, the instruction corresponding to the class instantiation activity is new-instance. Class-formatted bytecode or dex-formatted bytecode, instantiation of a class is split into two instructions: one is new-instance and the other is calling its corresponding constructor. For class instantiation activity, the added (Add) semantics are to Add a new object of the same type; modified semantics are undefined; the semantics of deletion is to eliminate the object, i.e. to force the object to be recycled. For the case where there is another object referencing it, then this can be done by assigning the corresponding field of the object referencing it to null.

Array instantiation: the semantics of the addition and deletion of this type of activity are the same as class instantiation.

Field assignment: the memory region affected by this type of activity is a heap. The field assignment is to read the value of a register and write to a field of an object in the heap. Thus, the addition (Add) of such an activity means that an activity is newly added, which is an assignment to a certain field of a certain object; delete means to eliminate the influence of the write activity, i.e. to assign it to the previous value; and Transform is a modification to a field of an object.

And (5) assigning an array: similar to field assignments, the semantics of addition, deletion, and modification are consistent with field assignments.

Thread synchronization: while this type of activity may affect the order of execution between threads, this type of activity does not directly affect the stack area, nor does it affect the stack area. Thus, the present invention does not define any operation for thread synchronization from the memory control equivalence point of view.

And (3) garbage recovery: the garbage collection activity is an activity that affects the heap area. Specifically, there are a classification into a recycle object activity and a compress object activity. For recycle object activity, Add means to recycle an object, which is forced to be recycled as in the control implemented by Delete of new instance, and the value is null for the case where there is a reference. Delete means that the object is instantiated and the state of the object is restored to the state at the time of the just-recycled. The Transform operation for the recycle object activity is undefined. For an object compression activity, the effect of the activity is to move an object from address 1 to address 2. From a programming language perspective, this compression activity is completely transparent to the developer; existing virtual machines may not even implement garbage collection algorithms with compaction activities. Therefore, there is no definition of the three operations for the compression activity.

The method comprises the following steps: the method invocation activity is more complex than the activities described above. A method invocation activity is an activity that comprises a series of activities. Therefore, it may affect not only the stack area but also the stack area data. The Add operation of the method invocation activity means that the method invocation is executed again; delete means to eliminate the effect of method invocation. For the method call which has already been executed, Delete means to eliminate the heap area related activity included in the method at the same time; whereas Transform is difficult to define. 1) If it is defined that a method call is re-executed once in a new context, the sequence of re-executed method calls is difficult to compare with! ' maintain memory control equivalent relationships. 2) If it is defined that the register and stack corresponding to the parameters are modified directly, it is difficult to maintain consistency on the register-based dex bytecode and the operation stack-based class format bytecode. Therefore, a Transform operation is not defined for a method call.

Class loading: the class loading activities correspond to the execution of a set of initialization activities of the classlnker and the < clinit > method of the relevant class. Unlike ordinary method calls, < clinit > caused by class loading will only be called once. Therefore, its Add operation is undefined. While Delete means class offload, which the present invention defines as performing all Add operations of objects belonging to this class and removing the impact of the class on the classlnker.

(2) Structural formula control

Structured control means that modifications to runtime activities are reflected in the code fragments of the original application. The structural control takes the application behavior runtime model as a section of executed code segment, and the operations of adding, deleting and modifying the behavior runtime model are embodied as the addition, deletion and modification of the code segment.

In the embodiment of the present invention, the step of performing structural control on the terminal application behavior includes:

For any given behavior runtime model segment, it consists of a set of actions like method invocation, field read-write, etc. Each activity can automatically generate a corresponding code segment by a program analysis method, and the corresponding code segment is equivalent to the original segment maintaining stack control.

In the above step, the step of mapping the set of operations into a target code for any activity includes: acquiring data dependence so that the data dependence of the activity execution is the same as the activity occurrence time;

the activity is converted into corresponding object code.

In the embodiment of the invention, the data dependency comprises a value type and an object type;

The local object in the embodiment of the invention is an object instantiated in the function execution process, and can be garbage-recycled after the function execution is finished. Constructing the local object, wherein the local object construction based on the activity sequence construction and the local object construction based on the runtime heap model are included; the runtime heap model is illustrated below as an example:

for activity sequence based local object construction:

the input to the algorithm for solving the stack control equivalence sequence of an object in an activity sequence is an algorithm that contains a set of activity sequence control flows f and a related object. First, it is judged whether the current control flow node is related to the object, and if not, the null is returned directly. If so, an array, resut, is constructed to preserve the heap control equivalent order of activityAnd (4) columns. Second, the first equivalent sequence of activities is the outermost activity of the control flow. For example, if the current control flow is a method call, then the same method call is executed directly again and the state of the corresponding object is equivalent to heap control. In addition, if the control flow is a method call, then the heap control equivalent sequence of activities also includes the Cartesian product of the heap equivalent sequences of its child control flows. Solving the stack control equivalent sequence of the sub-control flows can be regarded as a process of performing function inlining. For a group of control flows with the average sub-control flow number of K and the average depth of H, the number of stack control equivalent sequences is O (K)^H)。

For the local object construction based on the runtime heap model:

based on the initial Snapshot and all heap operation activity sequence DataActions in the runtime heap model, the query of the state of the object at any time can be realized. First, loading initial mirror image and activity, and the steps are as follows:

and reading the initial mirror image, thereby obtaining an initial Snapshot, wherein each object is identified by the memory address in the current operation.

Traversing all activities: for instantiation activities, sequentially adding corresponding objects in the initial Snapshot; adding modification activities and cleaning activities to the activity sequence of the related objects; for compression activities, in addition to adding to the sequence of related objects, an object identified by a compressed address is created, and the compression activity is taken as the first activity of the newly created object.

All objects appearing in the process can be guaranteed to be in the Snapshot through the two steps. Among them, due to compression activity, recycling activity, and reallocation activity, a certain memory address may correspond to multiple objects. Therefore, the identification and creation time is used as a global identifier of an object in the Snapshot.

After the loading is finished, the state query of any object at any time can be realized. To query the state of an object at a certain time, the value of each field of the object at that time is queried. For a field of a value type, the value at the time is the value of the modification operation closest to the time; and for the field of the object type, the value of the address of the object referenced at that time. The core of the algorithm is therefore to query the value at that time based on the activity of each field in the object. First, all activities related to one object are allocated to each field, and then the activity closest to the moment in the activity sequence ordered in time sequence is searched through binary query. Let DataActionCount be the activity associated with a field of an object, ObjectCount be the number of objects, and FieldCount be the average number of fields of a class. Then on average see:

thus, the complexity of the algorithm is log (dataactioncount) number of queries per field, i.e., the complexity of the algorithm is: o (FieldCount log (dataactioncount)). The algorithm is proportional to the logarithm of the number of activities, so that the retrieval efficiency can be kept when the number of activities is huge.

Compared with the two ways of generating the local dependency, the second way is higher from the aspect of execution efficiency, namely, the field write operation related to the required object is only executed in a playback mode; from a readability point of view, local object construction based on activity sequences can produce a smaller number of lines of code.

In an embodiment of the present invention, the global object is obtained from a chain of references in a runtime heap model.

The method for acquiring the global object reference based on the reference chain comprises the following steps: a global object is just before or after the function is executed, and the object is stored in a heap. The global object can be obtained in two ways:

and obtaining or utilizing the algorithm according to the reference chain in the runtime heap model, and generating a corresponding model segment by taking the global object as a related object. Because the object is a global object, there may be some method that has less data dependency in the original execution logic, and even no data dependency can directly obtain the global object. Therefore, only the fragments with fewer elements in the generated corresponding model fragments need to be screened.

According to the dependency relationship of the objects, model segments of a plurality of objects in a plurality of control flows are selected, and corresponding code segments can be automatically generated through the method. And editing the code segment to a certain extent to realize the modification of the application behavior under the control of the structural formula.

Next, a specific example is used to verify the effectiveness of the behavior control of the terminal application according to the embodiment of the present invention.

Aiming at android mobile applications widely used in the mobile internet, a prototype system implementation of a behavior reflection framework is given: refletall. The Reflection is called as Reflection at low level interpreters, and has double meanings, namely, Reflection realized based on a behavior interpreter at the bottom layer; secondly it can monitor and control the application behavior at the instruction level. Refletall is based on an android operating system open source project. In order to realize the monitoring and control of the mobile application behaviors, the refleltall platform can be divided into a behavior runtime model construction subsystem, a model analysis and code generation subsystem and a running subsystem, so that the monitoring and control in a behavior reflection framework are realized.

Referring to fig. 7, a schematic diagram of a subsystem architecture for refleltall model generation is shown. The behavior runtime model construction subsystem of refletall realizes the construction of a behavior runtime model of mobile application, and the core of the behavior runtime model construction subsystem is realized in a system layer and consists of an optimization-inverse optimizer, a behavior interpreter, a model construction module and an interface layer. The four modules realize the monitoring and control of the mobile application behaviors.

Wherein the optimizer-inverse optimizer: the android runtime environment can load native instructions that the CPU can directly execute. Therefore, the native instructions need to be switched into bytecodes, i.e. to be optimized and interpreted by the behavior interpreter, so as to monitor the runtime activity of the mobile application. Due to the complexity of mobile applications, it is difficult to monitor all activities in the mobile application execution, and therefore a two-level screening mechanism is introduced. The optimization-inverse optimizer realizes a class screening mechanism in a two-stage screening mechanism, and can inversely optimize the class to be monitored into byte codes as required and perform interpretation and execution through the optimization-inverse optimizer; while for classes that are not monitored, execution is still in the native executor. The optimiser-inverse optimiser will trigger in three cases: 1) when a command for starting monitoring is received, screening the currently loaded class method according to the configured parameters, and performing inverse optimization; 2) when receiving a command of finishing monitoring, re-optimizing the class which is subjected to reverse optimization at present, and enabling the class to enter the native actuator again for execution; 3) when the class linker loads a new class, the class is subjected to a screening and de-optimization process similar to that in case 1). In order to ensure the correctness of program execution, the process of inverse optimization needs to suspend the execution of all threads as part of garbage collection algorithm, and the execution of the threads is resumed after the execution of inverse optimization is finished. By such local de-optimization, and maintaining the state in which interpretive execution coexists with native execution, the performance overhead of monitoring can be greatly reduced.

A behavior interpreter: the behavior interpreter is an interpreter for interpreting byte codes in the execution dex format and can monitor the activities occurring in the current program execution during the interpretation execution. The activities in the mobile application behavior runtime model are mostly generated by a behavior interpreter. In addition to activities generated by the behavior interpreter, the garbage collector may also generate partial activities — garbage collection activities. The behavior interpreter also implements an activity screening mechanism in a two-level screening mechanism, which can generate different types of activities according to the configured activity collection granularity.

A model builder: the activities generated by the behavior interpreter and the garbage collector are built in the model builder. When the activities generated during the operation are more, the memory occupation is larger. Thus, the model builder enables online and offline model building. When the activity is less, the model builder runs in an online model building mode, and when the activity number reaches a configured threshold value, the model builder can persist the currently generated activity sequence and persist the activity sequence to storage in a file form.

Interface layer: the functionality provided by the optimiser-inverse, the behaviour interpreter and the model builder is encapsulated. While also providing the interface required for deserialization activities such as finding an object from an address and translating a given object to an address, etc.

In the prototype implemented by the embodiment of the present invention, two mobile application behavior runtime models can be generated: 1) a refined model containing runtime data dependence; 2) do not contain a reduced model of runtime data dependencies. Based on the implementation of a system layer, at a framework layer, a refletall comprises a group of behavior reflection interfaces, and can monitor the activities of applications with different granularities and generate application behavior runtime models with different granularities; and the remote debugging connection interfaces can control the start and the end of application activity monitoring. And in the application layer, the interface of the framework layer is encapsulated, so that an android application is realized, and a remote debugging interface can be externally provided in a Web service form.

The refletall analysis and code generation subsystem is a browser-server architecture. The analysis and code generation subsystem realizes that:

version management: and managing different versions of the mobile application and the interoperation interface by utilizing git. Meanwhile, the server side is supported to compile, and the compiled dex byte codes are pushed to the client side by using the interface management application of the client side.

Visualization of a stack model: provides a tree-like view and supports keyword-based data-dependent contamination analysis.

The interface running subsystem of refletall adds a behavior reflection type loader on the framework layer of the android source project, as shown in fig. 8, which is a schematic structural diagram illustrating the interface running subsystem of refletall according to an example of the present invention. When the application process starts, it will check if there is a loadable behavior reflection interface bytecode file. And if the behavior reflection interface byte code file suitable for the current application exists, loading the behavior reflection interface byte code file into an application process through a behavior reflection class loader, and simultaneously registering the interoperation interface provided by the current application with the interface management application by using a Binder communication mechanism. The interface management application provides services such as interface forwarding, state detection, and the like. The caller process can interoperate with the designated application through the interface management application.

The performance of the refletall model generation is verified by an open-source application set comprising 69 open-source android applications and a closed-source application set comprising 39 closed-source applications. During specific verification, the graphical interface facing the user and described by the refletall model is converted into an interface algorithm facing interoperation to serve as an application example of the structural control, and experiments are performed in 35 applications in the closed-source application set. Finally, an example is given for implementing real-time modification of application states based on behavioral control without modifying the code of the original application.

Structural formula control example

In the embodiment of the invention, 35 applications are selected from a closed source application set, and interfaces to be developed are established according to functions provided by different applications, so that the total number of the interfaces is 150. The total number of developers of the interface is four, and the Java development experience is different from 1 year to 3 years. After performing refletall use training for two weeks, interface development is initiated. The number of interfaces and the workload (in human days) corresponding to each application are not listed herein because of the large number.

From the above experiments, it was found that:

(1) the development time of the interoperation interface is from 0.5 to 5 days. The interface with the largest workload is the interface with three application processes, and the execution logic is complex.

(2) For different functions of the same application, the phenomenon of similar modes often exists, and therefore, for the interfaces with similar execution modes in the same application, the development workload of the subsequent interfaces is often much smaller than that of the first interface.

(3) By utilizing the application behavior runtime model abstracted by refletall, an application developer can quickly realize interoperation interfaces under the condition of completely not knowing applications and having no documents and codes, and the average development amount of each interface is 1.5 days.

Behavioral control example

As described above, the behavioral control implements monitoring and control of the original application based on the runtime behavioral reflection interface without restarting the application or recompiling the application. In the present example, an android calculator application is taken as an example, and how to implement the recording and playback of expressions during calculator usage by using the behavioral control of the behavioral reflex interface implemented herein is described in detail.

The original class diagram of the calculator is shown in fig. 9 (a). The class MainActivity represents the main interface of the calculator in which, in addition to a series of numbers and operator buttons, there is a text box callulardettext (editText field) displaying the current expression. If the expression monitoring and modification logic orthogonal to the calculator computation logic is woven into the original application at compile time using AspectJ instead of the behavioral reflection interface described herein, the following modifications need to be made:

the developer needs to implement a monitoring class, expressrecorder, and add a new field in MainActivity, which is of the expressrecorder type. To monitor the runtime expression, the developer needs to define a section: before the execution of the ontextChanged method of editText; the logic executed in this section is to record the parameters of the onTextChanged method. The recorded sequence is sorted, since onTextChanged is called every time the expression changes, for example, when 1+1 is entered, the method is called 3 times. In order to facilitate display, developers need to screen sub-strings of multiple monitored expressions, and filter repeated sub-strings of the expressions. I.e. for an expression, filtering if it is a substring of another expression. After recording the method executed by ontextChanged, the developer writes a setText method calling editText in the expressRecorder by understanding the code, and realizes the modification of the expression state on the interface. And finally, visualizing the expression recorded by the expression recorder, wherein the three buttons respectively play the functions of starting to record the expression, stopping to record the expression and modifying the current expression into a certain expression recorded before.

After the modification, the developer configures the compiling flow of AspectJ into the compiling flow of the original application, compiles the compiling flow and generates a new calculator application. The modified class diagram is shown in fig. 9 (b). It can be seen that the developer-defined cut plane actually introduces the coupling of the CalculaterDitText with the expression Recorder-in the execution flow of CalculatoreDitText, logic is added to record the expression to the expression Recorder.

The behavior reflection interface provided based on the control of the invention only needs to be modified as follows:

the developer needs to implement a monitoring class ExpressionRecorder. To realize the monitoring of the expression in operation, only the model generation function of the behavior reflection interface needs to be called, wherein the configured class filter is a CalculatoreDitText. And screening activities in the model to realize filtering of the expression repeated substrings. And adding a setText activity through Add operation of the model to realize the function of modifying the interface expression. Finally, the expression recorded by the expression recorder is visualized as above.

Based on the remote interface, the operation logic for monitoring and modifying the operation state of the application does not need to be operated in the same process with the original application, so that the part of the logic can be stripped and independently compiled into a plug-in of the original calculator application.

Compared with the method disclosed by the invention, the method based on AspectJ needs:

step 1, modifying the original application, and newly adding the coupling of MainActivity and Expression Recorder.

And 2, modifying the compiling flow of the source application, and weaving the codes orthogonal to the service functions of the original application into the original application.

In fact, step 2 means that the coupling of the callorbeddext and the expressrecorder is established in the code. The implementation mode of the invention really separates the monitoring logic realized by the expression recorder from the original applied function by using the behavior reflection interface, and the coupling degree is lower. Meanwhile, the development process of the behavior reflection interface is simpler.

In summary, in the aspect of terminal application behavior control, based on refletall instruction level control, 150 user-oriented functions in complex closed-source applications including microblogs and jingdong are successfully and automatically converted into application programmable interfaces, 225 days are consumed totally, 1.5 persons/day is consumed averagely, and the effectiveness of refletall in realizing mobile application on-demand interoperation is demonstrated.

The above-described embodiments are merely preferred embodiments, which are not intended to limit the scope of the present invention, and any modifications, equivalents, improvements, etc. made within the spirit and principle of the present invention should be included in the scope of the present invention.

Claims

1. A method for realizing terminal application control based on a runtime model is characterized in that the runtime model comprises a runtime stack model and a runtime stack model, and comprises the following steps:

2. The method of claim 1, wherein the runtime model comprises a set of activities with logical associations that occur over a period of time;

the predefined operations on the runtime model include:

3. The method of claim 1, wherein controlling the terminal application behavior comprises behavioral and/or structural control of the terminal application behavior.

4. The method of claim 3, wherein the step of behavioral controlling the terminal application behavior comprises:

after a period of execution, obtaining the memory state after operation as S · a ═ S ', and obtaining the active sequence after the equivalence is maintained and the operation model is converted as a', and obtaining the target state as S · a ═ S ";

and solving the incremental activity sequence A "by using the S.A ═ A ═ S '· A", so that A + A ═ A', and finishing the process of performing behavioral control on the terminal application behaviors.

5. The method of claim 4, wherein the incremental activity sequence A "comprises: control transfer, arithmetic operation, field reading, array reading, class instantiation, array instantiation, field assignment, array assignment, thread synchronization, garbage collection, method invocation, and class loading.

6. The method of claim 3, wherein the step of structured control of the terminal application behavior comprises:

7. The method of claim 6, wherein the step of mapping the set of operations to a piece of object code for any activity comprises:

the activity is converted into corresponding object code.

8. The method of claim 7, wherein the data dependencies include a value type and an object type;

9. The method of claim 8, wherein the constructing of the local object comprises constructing the local object based on an activity sequence and constructing the local object based on a runtime heap model.

10. The method of claim 8, wherein the global object is obtained from a chain of references in a runtime heap model.