Adaptive Offloading Method for Object-Oriented Applications at the Function Granularity in Edge Environments

Abstract

The present invention relates to an adaptive offloading method for object-oriented applications at the function granularity in an edge environment. First, a program call tree is established through code analysis to discover function calls suitable for offloading, and then the relevant functions are refactored according to a specific program structure. Then, at runtime, an offloading scheme decision is made based on the context environment, and the functions are sent to multiple remote devices in the environment for execution. This method can meet the adaptability and effectiveness during the offloading of object-oriented applications, and improve the user experience of the application while ensuring the quality of service.

Description

Technical Field

[0001] The present invention relates to the technical field of computing offloading, and particularly relates to an adaptive offloading method for object-oriented applications in an edge environment with functions as the granularity. Background Art

[0002] With the rise of intelligent technologies, more and more computationally intensive application programs (such as autonomous driving, face recognition, augmented reality, etc.) have been developed to meet people's needs, and the computing platforms of these application programs are not limited to smartphones and laptops, and have gradually expanded to intelligent devices such as wearable devices, vehicles, and drones. Although these mobile devices have more and more powerful functions, due to the constraints of size and weight, they are still limited in terms of processing power, memory capacity, and battery capacity. Most mobile devices are still unable to process various emerging computationally intensive tasks in a short time.

[0003] Computing offloading is an effective way to solve the problem of resource constraints of mobile devices. It sends computationally intensive tasks in software from the local to a remote device for execution, and uses remote resources to expand local resources. The proposal of mobile cloud computing (MCC) first integrates cloud computing capabilities into the mobile network, enabling mobile users to access and use cloud computing services through the core network of mobile operators; in MCC, computing offloading sends computationally intensive tasks to a cloud server, thus using the computing and storage resources of the cloud server. However, from the perspective of network topology, the distance between the cloud server and the mobile device is too far, which leads to high network latency and also adds a large load to the core network of mobile operators.

[0004] To solve the problem of too high latency in MCC, the newly emerging mobile edge computing (MEC) considers deploying cloud computing services near the mobile device, that is, at the edge of the mobile network. Figure 1 Describes the mobile edge computing architecture: in the traditional MCC, the mobile device accesses and uses cloud resources through the core network of the mobile operator; while in MEC, the computing and storage resources are placed close to the mobile device. Therefore, compared with MCC, MEC can provide lower service latency.

[0005] Due to the geographical distribution of edge servers and the mobility of mobile devices, the operating environment of software in MEC is highly complex and dynamic, which brings great difficulty and complexity to the implementation of computing offloading. It is mainly reflected in the following two aspects:

[0006] Challenge 1: Adaptive offloading enabling technology. In MEC, computing resources are distributed among mobile devices, edge servers, and cloud servers, and there are significant differences in the amount of resources owned by each computing platform. Therefore, for an application, the computing resources it needs and can obtain are often distributed across multiple different computing platforms and change dynamically with location. The research on software adaptive offloading enabling technology requires that the application can effectively use these distributed and changing computing resources during runtime.

[0007] Challenge 2: Adaptive offloading optimization technology. The changing computing resource requirements of applications and the changes in the resources themselves require the offloading scheme to change, and in a highly complex and dynamic operating environment, such changes will occur frequently. Therefore, adaptive offloading means that the offloading scheme needs to be continuously optimized to match the resource requirements of the application with the resource supply in the environment to provide better functionality or performance. The offloading scheme determines which computing tasks of the application should run on which computing platform, but no offloading scheme is the ultimate solution. When the operating environment of the application changes, the offloading scheme also needs to be optimized accordingly to match the resource supply and demand again. Therefore, it is necessary to make decisions at runtime on whether to offload computing tasks and to which computing platforms to offload them.

[0008] In existing research work, there are methods aimed at supporting the dynamic offloading of applications in MCC. Taking virtual machines, classes, methods, program fragments, etc. as granularities, the application is cut into two parts and deployed on mobile devices and cloud servers respectively, realizing the computing offloading of the application from mobile devices to cloud servers. For the highly complex and dynamic application operating environment in MEC, since existing methods all assume that mobile devices use a single remote server for computing offloading, they cannot utilize the distributed and changing computing resources in MEC. Summary of the Invention

[0009] The object of the present invention is to provide an adaptive offloading method for object-oriented applications in an edge environment with functions as granularities, which can meet the adaptability and effectiveness during the offloading of object-oriented applications and improve the user experience of the application while ensuring the service quality.

[0010] To achieve the above object, the technical solution adopted by the present invention is: an adaptive offloading method for object-oriented applications in an edge environment with functions as granularities. First, a program call tree is established through code analysis to discover function calls suitable for offloading, then the relevant functions are refactored according to a specific program structure, and then an offloading scheme decision is made based on the context environment during runtime, and the functions are sent to multiple remote devices in the environment for execution.

[0011] Furthermore, the method includes the following steps:

[0012] Step S1: First, establish a program call tree. Through static code analysis, construct a program call tree starting from the main function for the entire program. Each node in the program call tree represents an object method, and the directed edges between nodes represent method calls between object methods. Then, based on the computational complexity and data transfer volume, preliminarily identify the object method calls suitable for computational offloading. The role of such object method calls is to consider whether to perform computational offloading when the object method call is executed.

[0013] Step S2: First, organize all the object method calls suitable for computational offloading discovered in Step S1 to obtain their corresponding class methods. Then, perform code refactoring on the class methods according to the computational offloading program structure, and respectively construct method wrappers and method forwarders corresponding to the class methods. Then, write the offloading scheme into the configuration file. Based on the configuration file, the runtime mechanism performs adaptive offloading according to the offloading scheme.

[0014] Step S3: First, construct a cost evaluation model to automatically generate an offloading scheme according to the application context environment. In this offloading scheme, different computational tasks of the application program will be executed locally, at the edge, or on cloud devices in the MEC environment. Based on this cost evaluation model, use the fitness function through the offloading decision algorithm to calculate the program response time under different offloading schemes to determine a suitable offloading scheme.

[0015] Compared with the prior art, the present invention has the following beneficial effects: The present invention proposes an adaptive computational offloading method with object methods (functions) as the offloading granularity. This method targets object-oriented applications and supports dynamic offloading of application programs in MEC from the perspective of program structure, and realizes adaptive offloading in the mobile edge environment with object methods (functions) as the offloading unit. This method can meet the adaptability and effectiveness during the offloading of object-oriented applications, and improve the user experience of the application while ensuring the quality of service. Description of the Drawings

[0016] Figure 1 is the mobile edge computing architecture in the prior art;

[0017] Figure 2 is the principle block diagram of the method implementation in the embodiment of the present invention;

[0018] Figure 3 are two object-oriented application program structures in the embodiment of the present invention;

[0019] Figure 4 is the comparison diagram between the original method and the method wrapper in the embodiment of the present invention;

[0020] Figure 5 is the comparison diagram between the original method and the method forwarder in the embodiment of the present invention;

[0021] Figure 6 It is a schematic diagram of the context environment in an embodiment of the present invention;

[0022] Figure 7 It is a performance comparison of license plate recognition applications staying in four regions respectively using different offloading methods in an embodiment of the present invention;

[0023] Figure 8 It is a comparison of offloading schemes of three offloading methods when located in Garden in an embodiment of the present invention;

[0024] Figure 9 It is a comparison of the time overhead for adjusting the offloading scheme of three offloading methods in an embodiment of the present invention;

[0025] Figure 10 It is a performance comparison of license plate recognition applications cruising among four regions using different offloading methods in an embodiment of the present invention;

[0026] Figure 11 It is a set diagram of segmentation point methods in an embodiment of the present invention;

[0027] Figure 12 It is a comparison diagram of program response time in an embodiment of the present invention. Detailed implementation manners

[0028] The present invention will be further described below in conjunction with the accompanying drawings and embodiments.

[0029] It should be noted that the following detailed description is exemplary and is intended to provide further illustration of the present application. Unless otherwise specified, all technical and scientific terms used herein have the same meaning as commonly understood by those of ordinary skill in the technical field to which the present application belongs.

[0030] It should be noted that the terms used herein are only for describing specific implementation manners and are not intended to limit the exemplary implementation manners according to the present application. As used herein, unless the context clearly indicates otherwise, the singular forms are also intended to include the plural forms. In addition, it should be understood that when the terms "comprising" and / or "including" are used in this specification, they indicate the presence of features, steps, operations, devices, components, and / or combinations thereof.

[0031] This embodiment provides an adaptive offloading method for object-oriented applications in an edge environment at the function granularity. This method first establishes a program call tree through code analysis and discovers function calls suitable for offloading, then refactors the relevant functions according to a specific program structure, and then makes an offloading scheme decision based on the context environment at runtime and sends the functions to multiple remote devices in the environment for execution.

[0032] 1 Method overview

[0033] This method can be used to support object-oriented applications to have good service capabilities in the field of mobile edge computing. Figure 2 The framework of this method is shown, which can be divided into three parts. The left part represents the cost prediction model of AndroidOff in the preliminary work, and this cost prediction model is used to predict the execution cost of application methods, where the execution cost refers to the execution time of the method; the middle part includes program analysis techniques for computing offloading, the computing offloading program structure, and an evaluation model for the above computing offloading program structure; the right part is the model of the mobile edge environment. In the figure, circles represent different types of operation data, which are the inputs or results of the algorithm, and squares represent fitness functions.

[0034] This method takes the source code and context environment of the application as inputs and outputs an optimal offloading scheme, which contains the offloading locations of object methods (it should be noted that since this invention is inspired by functions as a service, in the description we also refer to "object methods" as "functions", and these two are equivalent) in the application call tree. Among them, in this method, the context environment is modeled as a graph, where nodes represent computing nodes (including mobile devices and MEC servers with different computing capabilities), and edges represent communication links (including transmission rate and round-trip time) between two computing nodes. The implementation steps of this method are as follows:

[0035] Step S1: Implement a program analysis technique for computing offloading. First, establish a program call tree. Through static code analysis, construct a program call tree starting from the main function for the entire program. Each node of the program call tree represents an object method, and the directed edges between nodes represent method calls between object methods. Then, based on the computational complexity and data volume, initially identify object method calls suitable for computing offloading. The role of such object method calls is to consider whether to perform computing offloading when the execution reaches this object method call. See Part 2 for details.

[0036] Step S2: Propose a computing offloading program structure that supports remote execution of object methods. First, since refactoring targets class methods in the source program, we first organize all object method calls suitable for computing offloading found in Process 1 to obtain their corresponding class methods. Then we perform code refactoring on the class methods according to the computing offloading program structure, respectively constructing method wrappers and method forwarders corresponding to the class methods. Finally, we write the offloading scheme into the configuration file, and based on the configuration file, the runtime mechanism performs adaptive offloading according to the offloading scheme. See Part 3 for details.

[0037] Step S3. According to the results of the above process, first design a cost evaluation model to automatically generate an offloading plan based on the device context environment. In this offloading plan, different computing tasks of the application will be executed locally, at the edge, or on cloud devices in the MEC environment. Based on this cost evaluation model, further implement an offloading decision algorithm that uses a fitness function to calculate the program response time under different offloading plans to determine the appropriate offloading plan. See Part 4 for details. 2 Program Analysis Techniques for Computational Offloading

[0038] This part will elaborate on the program analysis techniques for computational offloading, and implement the acquisition of the program structure of object-oriented applications and the object method calls suitable for computational offloading. On the one hand, Subsection 2.1 introduces the modeling of the object-oriented program structure based on code analysis, including the definition of the program call tree and the construction process of this program call tree; on the other hand, in order to reduce the additional execution cost of the offloading mechanism and the time overhead brought by the offloading plan decision, Subsection 2.2 takes the program call tree as the input, and combines factors such as the performance differences of different computing nodes and the context environment where the application is located to process the program call tree to further discover the object method calls suitable for computational offloading.

[0039] 2.1 Establishing the Program Call Tree

[0040] Writing object-oriented applications in the Java language is a common form. In this process, developers follow the development specifications of this type of application, write the classes that make up the object-oriented application, and then compile and debug to ensure the implementation of the application functions. An object-oriented application has a main class, which is the only entry point of the program. When the application runs, the entry method of the main class is first called, and then the entry method sequentially calls the methods in this class or other classes according to the code until all the methods for completing a certain function are executed and the results are returned. The above process can be described by a program call tree, and any method in the program call tree has a unique execution path.

[0041] The present invention proposes a method based on code analysis. By performing static code analysis on the compiled binary file, extracting code keywords, and constructing a program call tree for the object-oriented application. For a more vivid elaboration, the present invention uses Definition 1 to describe the program call tree:

[0042] Definition 1: The program structure of an object-oriented application can be represented as a program call tree Tree r =(M, R), whose entry method is m r . Wherein, M = {m1, m2,..., m n} represents the node set of this program call tree, and any m iA method representing a program call tree; R represents the set of node call relationships in the program call tree, and any one represents an edge of the program call tree, representing m i calling m j , and the weight of the edge represents the call frequency between nodes.

[0043] Definition 2: A method of a program call tree includes a method signature and a call path, and the present invention represents it as a binary tuple m i =<mSig i , cSeq i >, m i ∈M. Among them, mSig i represents the method signature of m i , and cSeq i represents a method call path from the main function (denoted as m main , the same below) to m i .

[0044] Definition 3: mSig i ={mSig|mName(mParams)} represents the method signature of a program call tree method m i . Among them, mName represents the method name, and mParams represents the method parameter list.

[0045] Definition 4: cSeq i ={mSig main , mSig a ,..., mSig i} represents the call path of a program call tree method m i , which is a combination of the method signatures of the nodes passed from m main to m i , and it uniquely constitutes a path to m i .

[0046] After defining the program call tree completely, we start to extract the program structure. This method uses the code analysis tool Soot for static analysis of the program. Here, we specify the address where the.apk file of the application is located and run Soot for analysis to extract relevant information.

[0047]

[0048]

[0049] Algorithm 1 describes the extraction process of the program call tree. The algorithm takes the main function m main as the entry point of the application and constructs the application with m mainThe program call tree rooted at, uses a HashMap to record R, and the key is stored in the form of <m i ,m j >, indicating that m i invokes m j , and its corresponding value indicates the number of times m i invokes m j . The input of this algorithm is the program entry point m main and the statement set U main of m main , where any represents the i-th statement of U main . Lines 2 - 20 recursively construct the program call tree by calling the method getTree(). The input parameters m a and U a of this method represent the method to be analyzed and the statement set of this method respectively. Among them, line 4 obtains the Soot keyword of , that is, the intermediate code defined in Soot. For example, the invoke keyword indicates that this is a method call statement. The complete keyword definition can be referred to the Soot manual. If this statement contains the keyword of method call, lines 6 - 10 update the M set, that is, record that method m a invokes method m s . Lines 11 - 16 update the R set, that is, record the method call relationship and update the weight. Line 17 performs a recursive call of getTree() on method m s . When this recursive process ends, the algorithm outputs the program call tree.

[0050] 2.2 Obtaining Object Method Calls Suitable for Offloading

[0051] Considering that the object methods suitable for computational offloading only account for a small part of the application program, this method adds a preprocessing algorithm to reduce the subsequent decision search time overhead and the additional cost of the runtime support mechanism. Based on the program call tree established in Subsection 2.1, this section will further search for the object method calls suitable for computational offloading in the application program, which are uniformly called split point methods for convenience of description.

[0052] Table 1 Empirical Metrics Affecting the Decision of Split Point Methods

[0053]

[0054] Whether a method can be offloaded is affected by many factors. Table 1 shows the empirical metrics affecting the decision of split point methods, that is, the relevant parameters of the algorithm for obtaining split point methods. The above metrics are determined by relevant experts according to factors such as application program characteristics and conventional network conditions.

[0055] Affected by the performance of different computing nodes, a method has different execution costs when executed on different computing nodes. The present invention will model the execution costs of the methods in the program call tree in Part 4. Here, the method m is introduced. i At the computing node n k Execution cost: Its specific meaning is shown in Definition 11.

[0056] Before preprocessing, we introduce the symbol m cur to represent the current node. Then, according to the above empirical metrics, the preprocessing algorithm takes the program call tree as input and assigns the starting node m main of the program call tree to m cur during initialization. Next, the algorithm searches for the splitting point method in a depth-first manner. The rules for obtaining the splitting point method are as follows:

[0057] Traverse all branches of m cur . For any branch, first find the path from m cur to the first branch node in this branch and obtain all the nodes on this path; then select at most one splitting point method from these nodes, and this splitting point method can minimize the response time of the program call tree rooted at m cur . Here, according to the description of Definition 1, the program call tree rooted at m cur is represented as Tree cur , and at the same time, its response time is represented as The calculation formula is shown in Formula (1).

[0058]

[0059] The present invention takes the response time of the application program as the main metric, that is, to find the splitting point method m i such that is minimized. When m i becomes the splitting point method, then all the methods on the program call tree rooted at m i will be executed on the remote computing node. Therefore, this consists of the local execution time the remote execution time and the data transmission time , which are respectively represented by Formula (2), Formula (3), and Formula (4).

[0060]

[0061] Formula (2) represents the local execution time, which is equal to the total execution time of m cur on the local computing node and m iThe difference in total execution time on the local computing node. Among them, represents the number of times m is called in one call to m cur , and it is the product of the number of calls on the path from m i to m cur . i to m

[0062]

[0063] Formula (3) represents the remote execution time, and this execution time is quantified by the performance ratio of the remote computing node to the local computing node.

[0064]

[0065] Formula (4) represents the data transmission time. One part is the transmission delay, which is equal to the data transmission volume of the segmentation point method divided by the transmission rate between the remote computing node and the local computing node; the other part is the round-trip delay between the remote computing node and the local computing node.

[0066] Based on the above rules and formulas, the present invention designs a preprocessing algorithm for obtaining the segmentation point method, and Algorithm 2 describes this.

[0067]

[0068]

[0069] The execution process of Algorithm 2 is as follows: In the first line, the segmentation point set is assigned an empty set. In the second line, the method M.m main is used as the input of the method getDivMethod(), so as to call getDivMethod() to complete the acquisition of the segmentation point. Lines 3 to 23 of Algorithm 3 describe the detailed specific process of getDivMethod(). In the fourth line, it is checked whether m cur has a successor. If so, from the fifth line to the twenty-first line, the following operations are performed on each branch: From the seventh line to the eighth line, the methods on the branch path are sequentially added to the set L d until the first branch node is found. If there is a branch node, in the tenth line, it is used as the current function and getDivMethod() is recursively called. From the fourteenth line to the fifteenth line, the methods in L d are sequentially traversed until the method m i is found, and this method can make the tree Tree curThe response time for its invocation should be less than the local execution time. When the method is found, lines 16 to 17 add it to divMethod and recursively call the function getDivMethod(). When Algorithm 2 finishes execution, the set of methods for obtaining the splitting points divMethod is obtained.

[0070] 3 Computation Offloading Mechanism

[0071] This section will elaborate on the offloading mechanism that supports object - oriented application computation offloading. First, Subsection 3.1 describes the program structure in detail, including the comparison between this structure and the traditional structure, the main components of this structure, and how this structure supports computation offloading; secondly, to enable the application to support this program structure, Subsection 3.2 introduces code refactoring, focusing on the refactoring mechanisms required for the transformation of the original code of object - oriented applications into target code, including method wrappers (Section 3.2.1) and method forwarders (Section 3.2.2); finally, Subsection 3.3 introduces the runtime support mechanism when the method of the present invention is implemented for offloading.

[0072] 3.1 Program Structure

[0073] Object - oriented applications are composed of different classes. The implementation of functions in the application can be abstracted as method calls between different classes. This can be understood as the minimum computational granularity of the program being a method, and the process of method calls is the execution process of the program. Before the introduction of computation offloading, the entire application program was deployed on a single computing node (such as: a smart phone). At this time, the interaction between methods could only be completed through local calls, and the resources available to the application program were single. After the introduction of computation offloading, remote calls have further expanded the interaction method between application program codes, and remote servers have enriched the resource supply of the application program. For further exploration, the structures and call processes of native application programs and target application programs are described below.

[0074] In traditional object - oriented applications, their inherent structure only supports their operation on a single device, such as Figure 3 as shown in (a), the process of method Method_I in a class calling method Method_T of the same class or other classes can be abstracted into the following pattern: First, obtain a memory reference to Method_T; secondly, call Method_T; finally, return the execution result of Method_T. This "In - VM" program structure can only ensure that method calls are made on a single computing node and does not support calls between multiple computing nodes.

[0075] To extend this mode and enable the application to support computing offloading at the method granularity in the MEC environment, a program structure that supports the independent deployment of object-oriented methods needs to be designed. Therefore, the method of the present invention supports the application to use multiple remote servers for on-demand offloading from the perspective of the program structure. At the same time, considering the consistency maintenance of the program state when the network connection changes, this method uses stateless object methods as the offloading unit, that is, the objects are deployed locally, and only their methods are offloaded to the remote server. Thus, when the application performs computing offloading, its program state data is all kept locally. When the network connection changes and the remote server cannot be connected, the relevant object methods can still run normally.

[0076] As Figure 3 (b) shows, the core of the target program structure consists of two elements: the method wrapper Method_T_Wrapper and the method forwarder Method_T_Transmitter, and its working principle is as follows:

[0077] (1) Convert the direct call of Method_I to Method_T into an indirect call via Method_T_Transmitter.

[0078] (2) Method_T_Wrapper completes the same function as Method_T and is responsible for executing the actual calculation. It transforms Method_T, finds out its external variable references, and transforms them into the form of passing in through parameters and returning through return values. The transformed class method is stateless.

[0079] (3) Method_T_Transmitter is a proxy mechanism for methods. Its external behavior is the same as that of Method_T, but it does not perform actual calculations; it is responsible for determining the execution location of the method, and performing control forwarding (local call / remote call), as well as data synchronization (including: initializing and serializing the actual parameter data required for the method wrapper to execute the calculation, and deserializing the return value of the method wrapper to update the local corresponding variables).

[0080] Based on the above structure, Method_I locally calls the method forwarder Method_T_Transmitter, and Method_T_Transmitter decides whether to execute the method wrapper Method_T_Wrapper locally or remotely according to the offloading scheme in the configuration file. In particular, the call logic of Method_I to Method_T has not changed.

[0081] 3.2 Reconstruction mechanism

[0082] The key to the target program structure introduced in the previous subsection enabling on-demand unloading of applications lies in two core elements: the method wrapper and the method forwarder. This subsection introduces code refactoring to restructure the original object-oriented application into a target program application that conforms to the above program structure. Next, we will introduce how to use refactoring to construct the method wrapper and the method forwarder in two parts respectively.

[0083] 3.2.1 Method Wrapper

[0084] In our target program structure, objects are deployed locally, and only their methods are unloaded to the remote server. To support the independent execution of object methods on the remote server, the present invention refactors the methods in the class file to construct method wrappers. Before that, it is necessary to sort out the divMethod obtained in Section 2.2 to obtain its corresponding class method for subsequent refactoring. The present invention uses the following definitions to describe the class method:

[0085] Definition 5-1: DM = {dm1, dm2,..., dm n} represents the set of class methods corresponding to divMethod. Among them, dm i represents the information of the i-th class method.

[0086] Definition 5-2: dm i = <mSig i , S i > is the class method information represented by a binary tuple. Among them, mSig i represents the method signature of dm i , which is equal to the method signature mSig j of the corresponding split point method m j in divMethod; represents the set of source code statements of dm i .

[0087] After defining the class method, the present invention completes the construction of the method wrapper in two steps: the first step is to use static code analysis to detect external variables used during method execution; the second step is to transform the external variables into the form of being passed in through parameters and returned through return values.

[0088] (1) Obtaining external variables through static code analysis

[0089] External variables refer to variables that are accessed during method execution and defined outside the method. The present invention introduces the following definitions (Definition 5, Definition 6, Definition 7) to describe it:

[0090] Definition 5: Parmeters i = {parameter i1, parameter i2 ,..., parameter in} represents the external variable set of method dm i , where parameter ij represents the j-th external variable information.

[0091] Definition 6: parameter ij = {name ij , type ij , ref ij , attr ij} is the external variable information represented by a quadruple, where name ij represents the name of the external variable; type ij represents the type of the external variable; ref ij represents the unique reference of the external variable; attr ij = {attr ij1 , attr ij2 ,..., attr ijn} represents the attribute information set of the external variable, where attr ijk represents the k-th attribute information.

[0092] Definition 7: attr ijn = <attrType ijk , attrName ijk > is the attribute information represented by a binary tuple, where attrType ijk is the type of the attribute; attrName ijk is the name of the attribute.

[0093] Based on the above definitions, the present invention uses static code analysis technology to obtain external variables, and its obtaining process can be described as follows: First, take the statement set S i of method dm i as input to obtain its intermediate code statements; Second, obtain the external variables of each method through string matching. In object-oriented applications, external variables are divided into two types: basic data types and object types, and their intermediate code is as follows:

[0094] For variables of basic types, the string pattern is "reference to the object to which the method belongs.<class to which the external variable belongs: type name>". For example, analyzing the middle statement of a certain method: $r0.<plateRecognition.ColorKMeans:int R>, an external variable of this method in the class ColorKMeans can be obtained as: parameter = <R, int, null, null>; for variables of object types, the string pattern is "variable reference = reference to the object to which the method belongs.<class to which the external variable belongs: type name>", and then the properties of the external variable of the object type are obtained using this variable reference. For example, analyzing the following middle statements: ① r1 = $r0. <plateRecognition.PlateocrActivity:plateRecognition.PlateNumberGroup plateng>, ② r3 = virturalinvoke r1.<plateRecognition.PlateNumberGroup boolean AlreadyChecked>, an external variable parameter = <platepng, plateRecognition.PlateNumberGroup, r1, <boolean, AlreadyCheck>> of a certain method in the class PlateocrActivity can be obtained.

[0095] (2) Code refactoring constructor wrapper

[0096] dm i The set of external variables is obtained through static code analysis. Further, the present invention refactors the methods suitable for offloading to remote execution to generate corresponding method wrappers, that is, a stateless method whose execution does not involve access to external variables and can be executed on any computing node, and its method service is called in the form of receiving data (input parameter) → performing calculations → returning results (output parameter). The construction of the method wrapper is based on additional input and output parameters, and the additional parameters are constructed according to Parmeters i of the present invention, and Definitions 8 and 9 are introduced to describe it:

[0097] Definition 8: Params i = {params i1 , params i2 ,..., params in} represents the set of additional parameters of the method dm i . Among them, params ij represents the information of the jth additional parameter.

[0098] Definition 9: params ij = <parType ij ,parName ij ,parValue ij > is additional parameter information expressed in a triple. ij Indicates the parameter type, which corresponds to Parmeters i .type ij ;parName ij Indicates the parameter name, which corresponds to Parmeters i .name ij ;parValue ij Represents the parameter value, which will be assigned during the method execution.

[0099] Based on the description of constructing a method wrapper in the previous article, we will explain the steps of refactoring the source code of a given object-oriented application to generate a method wrapper.

[0100] like Figure 4 As shown, the method wrapper performs code refactoring according to the following rules, where the external variables of the original method are referenced as variables c and d.

[0101] Rule 1: Modify the parameter list and return value of the method, see Figure 4 (a) and (b) Line 1. Add the parameter params to represent the external variables of the original method, so that the external variables can be passed into the method body in the form of parameters. At the same time, add params to the return result so that the changes of the external variables can be returned to the method caller.

[0102] Rule 2: Modify all statements in the method that access external variables, see Figure 4 (a) and (b) Line 2: Replace the external variable references c and d with the corresponding input parameters params.c and params.d, so that there are no more statements accessing external variables in the method.

[0103] Rule 3: Modify all return statements of the method, see Figure 4 Lines 3-6 of (a) and (b): Add the parameter params to the return result so that the changes of external variables can be returned to the method caller.

[0104] 3.2.2 Method Forwarder

[0105] In the target program structure, the method forwarder is the proxy mechanism of the method, which is responsible for controlling forwarding and data synchronization. Similarly, the present invention reconstructs the application program to construct the method forwarder.

[0106] Figure 5 This is an example of constructing a method forwarder, which is constructed according to the following rules.

[0107] Rule 1: Keep the method signature (name, parameter list) and return type of the method forwarder the same as those of the original method, as shown in Figure 5 (b) line 1.

[0108] Rule 2: Add statements to record the position of the current method call in the program call tree. The method of the present invention maintains a global variable seq, which represents the position of the current method call in the program call tree; when entering each method, add the method signature to seq, indicating the position of the new method call in the program call tree, as shown in Figure 5 (b) line 2; when exiting each method, delete the method signature from seq, as shown in Figure 5 (b) line 18.

[0109] Rule 3: Add statements to handle additional variables. Construct a variable params of type Params and assign values to params using the external variable information of the method, as shown in Figure 5 (b) lines 3 - 5.

[0110] Rule 4: Add statements to call local / remote method wrappers. According to the offloading scheme (see Part 4 for details), determine the execution location of the current method call (seq) and call the local or remote method wrapper, as shown in Figure 5 (b) lines 6 - 15; when making a remote call, send seq and the method wrapper call parameters to the proxy program on the remote node, and the remote proxy identifies the current method through seq and makes the call.

[0111] Rule 5: Add statements to receive the return result of the method call. In particular, use the result data to update the external variables of the method to ensure the consistency of the program state, as shown in Figure 5 (b) lines 16 - 17. At the same time, return the method call return value to its caller, as shown in Figure 5 (b) line 19.

[0112] 3.3 Runtime mechanism

[0113] During the execution phase of the object - oriented application, the refactored target code and the description file of the offloading scheme generated according to the evaluation model in the following text will be sent to all computing nodes in the edge environment. For the description file, the present invention formalizes it as Definition 10:

[0114] Definition 10: config_file(m) represents a description file of the offloading scheme for an object-oriented application, where m represents different nodes (object methods) in the node set of the program call tree. With the evaluation model in Section 4, when the execution location of the object method is decided to be local, config_file(m) takes the value of Local; when the execution location of the object method is decided to be a remote computing node, config_file(m) takes the IP address of the remote computing node. It is worth mentioning that the configuration file is not static but is continuously updated according to the resource supply and demand of the current context environment.

[0115] As described in Subsection 3.2.1, the method forwarder serves as the proxy mechanism for methods. The runtime mechanism of computing offloading will be supported by the method wrapper, which is responsible for identifying the execution location of the current object method, preparing the actual parameters for method execution according to the local runtime execution environment, and forwarding the method call. Taking the example in Subsection 3.2.2 for illustration: Under the guidance of the configuration file, the method forwarder identifies the current location of the object method method. If method runs locally, it directly makes a local call, and at this time, the call between methods does not involve remote communication services; if method executes remotely, it sends a request to the remote proxy according to the IP address of the remote computing node. When the remote proxy receives this remote call request, it obtains the method name and actual parameters (the actual values of the original method parameters and additional parameters) from the sent parameters, constructs an object using reflection technology and calls the method. When the method execution is completed, its execution result and external variables will be packaged into return data together, and then sent back to the application program on the mobile device for necessary program state synchronization to ensure the correctness of the application program. It can be seen that the method forwarder shields the process of identifying the execution location of the method wrapper, and the logic of method calls is not modified. This on-demand call method makes the execution location of the called object method transparent. When the execution location of the called method changes, the calling method will not notice the change in the location of the called method.

[0116] 4 Computing Offloading Evaluation Model

[0117] This part will elaborate on the cost evaluation model and decision algorithm of computing offloading. First, Subsection 4.1 models the basic information, including the method cost model and the application context model; secondly, Subsection 4.2 establishes the evaluation model of the offloading scheme based on the models established in the previous section, including the evaluation factors affecting the offloading scheme decision and the offloading scheme fitness function; finally, Subsection 4.3 designs the offloading decision algorithm based on the greedy strategy. Combining this evaluation model, it can automatically make decisions and evaluate the execution overhead of the offloading scheme according to the device context.

[0118] 4.1 Program Structure

[0119] This section mainly introduces two information models. One is the method cost model, which is used to describe the execution overhead of each method in an application on different computing nodes. The other is the application context model, which collects the environmental information of the application device, including the computing nodes in the environment and the connection information between them. The above two will be used as important information and input into the cost evaluation model in Subsection 4.2.

[0120] 4.1.1 Method Cost Model

[0121] An object-oriented application contains a large number of methods. Since the computational complexities of different methods are different, and the computing performances of each basic resource platform are also very different, the computing times of different methods are different, and the computing times of the same method on different computing nodes are also different. In order to reflect the differences in the method execution costs of the above application programs, the present invention models this to better serve the evaluation model and ensure the effectiveness of the offloading scheme.

[0122] For a method m of an application program i (whose definition is shown in Definition 2), assuming its execution location is n k (whose definition is shown in Definition 13), then the present invention uses Definition 11 and Definition 12 to represent the execution cost and net execution cost of this method on this node respectively.

[0123] Definition 11: The execution cost of an object-oriented method on a certain computing node can be represented as a binary tuple where Etime represents the execution time of this method from receiving data to generating results, which is related to the performance of the computing node; Edatasize represents the size of the input data of the method, which is not affected by the performance of the computing node and is a fixed value.

[0124] Definition 12: The net execution cost of an object-oriented method on a certain computing node can be represented as a binary tuple where Stime represents the net execution time of this method, which is expressed as the execution time of this method - the execution time of all method calls inside this method body * the respective call times of each method call. For example, assume method m a ,m b ,m c are executed on the same computing node. During the execution process, m a calls m b twice, and calls m c once, then m a .Stime = m a .Etime - (m b .Etime * 2 + m c.Etime*1); Sdatasize represents the input data size of the method, which is equal to Edatasize.

[0125] Due to the large volume of methods in object-oriented applications and the difficulty of directly monitoring the execution cost of some methods at runtime, it is difficult and costly to monitor and obtain the execution time of each method on each computing node by running the application on each computing node. Therefore, based on the previous work, the present invention implements a cost prediction model in AndroidOff, which predicts the execution time of all methods in the application on all computing nodes by using the historical execution time data of a part of the methods as input to obtain the method cost.

[0126] 4.1.2 Application Context Model

[0127] Computing offloading needs to make decisions according to the application context environment to match the current resource supply and demand. Therefore, this section will model, analyze, and define the application context. Before that, the present invention will describe what the application context environment is. As Figure 6 shown, the context environment of the application program consists of devices (DS) in different scenarios, two edge servers (ES), and a cloud server (CS). The present invention uses Definition 13 to describe it:

[0128] Definition 13: Model the context environment with a graph G c =(N, E), where N represents a set of computing node sets including local devices and remote servers, and E represents a set of communication link sets between nodes. Each edge (n p , n q ) ∈ E is associated with the data transfer rate p between n q and n and the round-trip delay .

[0129] According to this context environment, a typical offloading scenario of an object-oriented application can be summarized as follows: Initially, the application program runs on the local device (only DS); during the execution process, the object method is sent to the edge server (ES) or the cloud server (CS); finally, the result data is returned to the local device through the communication link.

[0130] 4.2 Cost Evaluation Model

[0131] Based on the modeling in Subsection 4.1, this section mainly describes the evaluation model of the offloading scheme. First, the evaluation model needs to consider different evaluation factors, and Subsection 4.2.1 will introduce the evaluation factors, including their representations and meanings; based on the introduced evaluation factors, Subsection 4.2.2 will introduce the optimization objectives and calculation formulas of the fitness function. To minimize the overall response time of the application, the evaluation model will be applied to the decision-making algorithm to determine which methods need to be offloaded and to which computing nodes they should be offloaded.

[0132] 4.2.1 Evaluation Factors

[0133] Computing offloading requires making offloading decisions, which means determining which methods are offloaded and to which computing nodes, forming an offloading scheme. The optimal offloading decision should minimize the offloading cost. First, we define the offloading scheme as shown in Definition 14.

[0134] Definition 14: DEP = {dep(m1), dep(m2),..., dep(m n )} represents an offloading scheme. Among them, m i ∈ Tree main .M, that is, all methods in the program call tree (see Subsection 2.1 for details); dep(m i ) ∈ N represents a computing node for a certain offloading.

[0135] The present invention proposes a cost evaluation model to evaluate the program response time of the offloading scheme. This evaluation model is affected by evaluation factors. Table 2 lists the evaluation factors that need to be considered when making the offloading scheme DEP decision. Among them, M, R, N, n k ∈ N, and have been defined above. denotes the offloading time of m i , and dep(m i ) and dep(m j ) respectively represent the execution locations of m i and its caller m j . The overall response time of the application can be represented by T response , which is equal to the sum of m i ∈ Tree main .M.

[0136] Table 2 Offloading Decision Evaluation Factors

[0137]

[0138] 4.2.2 Fitness Function

[0139] The fitness function described in this section evaluates the response time of an offloading decision, which is calculated based on the evaluation factor. As defined above, the response time of the program is denoted as T response In this section, a fitness function will be used to evaluate the response time of a given offloading scheme. In this case, the present invention considers the offloading scheme that minimizes the fitness value as the optimal offloading scheme.

[0140] Program response time T response The program calls the tree Tree main Uninstall time of all methods in The calculation formula is formula (5).

[0141]

[0142] Formula (6) represents m i The unloading time includes two parts: i In dep(m i ) execution time Second, data transmission time

[0143]

[0144] Formula (7) indicates that m i In dep(m i ) execution time, which is determined by m i In dep(m i ) multiplied by the number of times it is called.

[0145]

[0146] Formula (8) represents the total data transmission time, part of which is the sending time, which is equal to m i The data transfer volume divided by dep(m j ) and dep(m i ) transmission rate, and the other part is dep(m j ) and dep(m i ) round trip delay.

[0147]

[0148] According to formula (6), each m i ∈Tree main The accumulation of .M is the response time of the application. This result will be used for the offloading decision in Algorithm 3.

[0149] 4.3 Unloading decision algorithm based on greedy strategy

[0150] Based on the cost evaluation model in Section 4.2, this section proposes a greedy strategy-based algorithm to calculate the appropriate deployment plan according to the execution cost of each method (including the execution cost of mobile devices, cloud servers, and each edge server) and the data transmission volume, as shown in Algorithm 3.

[0151]

[0152]

[0153] Since the call tree is a tree structure, for any node, if the uninstallation location of the node has been determined, then the uninstallation schemes between all sub-branches of the node will not affect each other. Based on this premise, we first add a virtual node to the program call tree, namely the caller of the main function (denoted as m main 'caller) and connect it to the main function m main The execution location is set to the mobile device (DS); then the getGreedyDEP() method is called and the m main 'caller is passed in as an actual parameter. The getGreedyDEP() method uses a depth-first strategy to traverse the program call tree. The specific operations are as follows:

[0154] Lines 4-6 indicate whether the input parameter of the method determines whether there is a subtree: if not, 0 is returned directly; if so, line 8 indicates that the execution position of the subtree is set to the execution position of the parent node; lines 9-17 indicate that for object method calls suitable for unloading in the subtree, a new unloading node with the minimum function value of the fitness function is selected from the current unloading node and nodes with better performance than the current unloading node; line 18 indicates that the appropriate unloading plan for the subtree is recursively calculated according to the above method, and when a better plan for the subtree is found, the optimal plan is updated; when the traversal is completed, the unloading plan composed of the unloading position of each method is the final deployment plan.

[0155] 5 Case Studies and Uninstallation Evaluation

[0156] In this section, we establish a mobile edge environment as the running environment for applications and use a real application evaluation method. First, Section 5.1 introduces the experimental settings, including the mobile edge environment, experimental devices, and experimental applications; second, Section 5.2 conducts a macro evaluation, comparing the performance of the application when performing computing offloading using the method of the present invention (for convenience of presentation, the method of the present invention will be named RESTOff in the subsequent charts), AndroidOff, and MAUI for two scenarios of staying and cruising in different regions; finally, Section 5.3 conducts a micro evaluation, combining the empirical metrics in Part 2 to explore the optimal parameter scheme, evaluating the additional execution cost of the offloading mechanism in Part 3, and discussing the time overhead of the decision-making algorithm in Part 4.

[0157] 5.1 Experimental Environment

[0158] This section will introduce the settings for experimental evaluation, simulate the actual application scenarios for object-oriented instances in the mobile edge environment, and thus conduct the evaluation of offloading to verify the feasibility and effectiveness of the method of the present invention. The specific experimental settings will be described in the following three parts.

[0159] (1) Context Environment

[0160] To be closer to the real scenario, the context environment includes four typical usage areas in the application scenario, namely Playground, Teaching building, Garden, and Laboratory; the experimental environment is equipped with 5 computing nodes, namely 2 mobile devices (Device1, Device2) and 3 edge servers (Edge1, Edge, Cloud).

[0161] Table 3 Device Context Environment in Different Regions

[0162]

[0163] Table 3 describes the network connection conditions between mobile devices and MEC servers at different locations. Among them, each cell represents the round-trip time and data transfer rate between the mobile device and the computing node corresponding to the row where the cell is located in the region corresponding to the column where the cell is located. For example: the 4th column in the 2nd row of the table indicates that in the Garden, the round-trip time between the mobile device and Edge1 is 40ms, and the transmission rate reaches 1.5 Mb / s. The data in the table is measured using the WLAN-RTT tool, and a smaller rtt and a larger v represent a better network connection between the two computing nodes.

[0164] (2) Devices and Servers

[0165] To verify the effect of computing offloading on devices with different performances, the present invention installed object-oriented applications for evaluation on two mobile devices with different performances. These two mobile devices are: ① HUAWEI Honor MYA-AL10 with a 1.4 GHz quad-core CPU and 2 GB of RAM, named Device1, representing a low-end device; and ② HUAWEI Honor STF-AL00 with a 2.4 GHz quad-core CPU and 4 GB of RAM, named Device2, representing a high-end device.

[0166] The MEC environment includes edge servers closer to the terminal devices, which can provide computing capabilities for the terminal devices while solving the network latency problem between the terminal devices and the cloud. To simulate the device context environment, the experimental environment includes two edge servers (named Edge1 and Edge2) and a cloud server (named Cloud). Among them, Edge1 is a server with an 8-core CPU of 2.5 GHz and 4 GB of RAM, which can be accessed at the Teaching building and Garden locations. Edge2 is a server with an 8-core CPU of 3.0 GHz and 8 GB of RAM, which can be accessed at the Garden and Laboratory locations. Cloud is a server with a 16-core CPU of 3.6 GHz and 16 GB of RAM, which can be publicly accessed at all locations except the Garden.

[0167] (3) Object-oriented application

[0168] The object-oriented application used by the present invention for experimental evaluation is a license plate recognition application with an Android architecture (named LPRA by the present invention). First, we installed this application on both types of mobile devices and moved around in the above four areas (Playground, Teaching building, Garden, Laboratory) to record parked vehicles; then we enabled the license plate recognition program to identify the license plate information: LRPA obtained the license plate number by preprocessing and OCR processing the images obtained by processing each frame of the video, and connected to other servers to check whether the license plate number is legal; during this process, we recorded the data transfer volume of each method, as well as the execution time of the method on the mobile device, Edge1, Edge2, and Cloud. To ensure the rigor of the experiment, we repeated this process twenty times in the experiment to reduce unnecessary errors.

[0169] 5.2 Macroscopic evaluation

[0170] This section will, based on the experimental setup in Subsection 5.1, explore the improvement effect of the method of the present invention on application performance in different scenarios by comparing the method of the present invention with the uninstallation solutions of AndroidOff and MAUI.

[0171] 5.2.1 Control Methods

[0172] AndroidOff is an object - granularity computing offloading framework. It traverses all combinations of deployment results of all offloadable objects on four devices: mobile devices (Device1 or Device2), Edge1, Edge2, and Cloud, and selects the solution with the minimum response time as the final adaptive solution.

[0173] MAUI is a method - granularity computing offloading framework. It uses a linear programming solver to solve all migratable methods, leaving the methods with a solution result of 0 locally and offloading the methods with a solution result of 1 to a single remote server, i.e., Edge1, Edge2, or Cloud.

[0174] Due to the mobility of the device, we considered the following two scenarios: (1) when the mobile device stays in different regions respectively, (2) when the mobile device cruises between different regions, and the movement route is set as: starting from the Playground, passing through the Teaching building, Garden, and finally reaching the Laboratory. The present invention uses the program response time as the performance indicator.

[0175] 5.2.2 Performance Comparison When Staying in Different Regions

[0176] Figure 7 Shows the comparison of the program response times of the three offloading methods when running LPRA on Device1 and Device2, which includes data from four usage regions. It can be seen that the response time of the method of the present invention is the smallest.

[0177] Compared with the application program that does not adopt any migration method (the program response times on Honor MYA - AL10 and Honor STF - AL00 are 4329ms and 3436ms respectively), in regions with good network connections such as the Teaching building, Garden, and Laboratory, the method of the present invention reduces the response time by 18% - 62%. The reason is that in these regions, some computationally intensive tasks are offloaded to the edge server or cloud server; on the contrary, when the mobile device is in a region with relatively poor network connection such as the Playground, the performance improvement of the method of the present invention is not significant, and most of the methods of the application program run on the local device at this time.

[0178] Through Figure 7 (a) and Figure 7From the comparison between the method of the present invention and AndroidOff and MAUI in (b), it can be found that after uninstallation using the method of the present invention, the response time in all regions is less than that of uninstallation using AndroidOff and MAUI. To illustrate the reason for this result, we show the uninstallation schemes when using AndroidOff, MAUI, and the method of the present invention in Garden. This area contains two mobile edges, and they are both connected to the cloud server at a rate of 1.5 Mb / s and a round-trip delay of 40 ms. Figure 8 Shows the uninstallation schemes of the method of the present invention and the other two comparison methods when running LPRA on Device1.

[0179] By comparing Figure 8 (a) The method of the present invention and Figure 8 (b) AndroidOff, the method of the present invention unloads some methods of the class RecInEachChar to Edge2, some methods to Cloud, and the remaining methods are left to be executed on the mobile device; AndroidOff unloads the complete object of this class to Edge2. Therefore, the unloading granularity of our method is smaller, it is more flexible than AndroidOff that unloads the complete object, and relatively, the performance improvement is greater.

[0180] At the same time, by comparing Figure 8 (a) The method of the present invention and Figure 8 (c) MAUI, we can find that compared with unloading all selected unloading methods to a single server, different servers with different performances and network connections cooperating with each other can achieve better results. First, the unloading scheme can balance different network connections and unload the method calls with a larger data transfer volume (abstracted as a subtree of the program call tree rooted at m main to the remote server with a better network connection; second, the unloading scheme can balance the performances of different servers and place the method calls with more complex calculations and greater execution overhead on the remote server with better performance but relatively worse network connection.

[0181] 5.2.3 Performance comparison when cruising between different regions

[0182] This subsection evaluates the time overhead required to re-make the unloading scheme decision and prepare for computing unloading when the position of the mobile device changes, resulting in changes in available computing resources, network connection conditions, etc., that is, the time overhead for adjusting the unloading scheme. Since the available computing resources and network connection conditions in different regions are different, when the mobile device enters a new region, it is necessary to adjust the unloading scheme, including unloading scheme decision and computing unloading preparation. We count the above time overhead when entering different regions. Figure 9Shows the comparison of the time overhead of three methods for unloading scheme adjustment. Experiments prove that the method of the present invention has the following advantages in the time overhead of unloading scheme adjustment:

[0183] (1) The method of the present invention has obvious advantages in the time overhead of unloading scheme decision-making. According to Figure 9 , the average decision-making times of the method of the present invention, AndroidOff, and MAUI are 218 ms, 1206 ms, and 442 ms respectively. Since the method of the present invention is based on the greedy strategy and only makes decisions on the execution locations of the method calls suitable for computational offloading, its decision-making time is linearly related to the number of segmentation point methods; AndroidOff is based on the traversal method and needs to make decisions on all possible object distribution schemes, so its decision-making time is exponentially related to the number of offloadable objects; MAUI is based on the program partitioning strategy and makes decisions on whether all method calls are executed on the device side or a single server side, so its decision-making time is linearly related to the number of offloadable methods. Thus, it can be seen that the number of decisions required by the other two methods is greater than that of the method of the present invention.

[0184] (2) When the unloading scheme changes, the method of the present invention and MAUI do not need to make additional preparations for new computational offloading, while the average preparation time of AndroidOff is 1671 ms. Both the method of the present invention and MAUI perform offloading at the method granularity, and the program state data remains on the mobile device, and only method calls are executed on the remote server. Therefore, when the unloading scheme changes, the method calls can be directly executed on the new remote server. However, AndroidOff performs offloading at the object granularity, and the objects run on the mobile device, edge, and cloud respectively. When the unloading scheme changes, the application needs to re-offload the objects to the new computing nodes according to the unloading scheme, and when the offloaded object cannot be accessed, the application crashes and needs to be restarted.

[0185] Figure 10Shows the comparison of the program response times of three offloading methods when running LPRA on Device1 and cruising among four regions. Among them, during the movement of the device this time, there is a 1-minute stay time in each region. Overall, the method of the present invention has the best performance, AndroidOff is the second, and MAUI has the largest execution overhead. The main reason is that: the method of the present invention and AndroidOff can use multiple remote servers for computing offloading, while MAUI can only use a single remote server for computing offloading. When the device context changes, the program response times of the method of the present invention and MAUI only increase slightly, mainly due to the time overhead brought by the offloading scheme decision; when the device context changes, the program response time of AndroidOff increases by about 3 seconds, mainly due to the time overhead brought by the offloading scheme decision and the preparation for computing offloading; when the device enters the Garden from the Teachingbuilding, AndroidOff has an unresponsive state of about 20s. Since the mobile device is not connected to the Cloud in the Garden, the application cannot access the objects offloaded to the Cloud when in the Teaching building, so the application crashes and needs to be restarted.

[0186] 5.3 Microscopic Evaluation

[0187] Based on the experimental settings in Section 5.1, this section will further conduct a microscopic evaluation of the details of the method, including the optimal parameters of the preprocessing algorithm, the additional execution cost of the offloading mechanism, and the time overhead of the decision-making algorithm.

[0188] 5.3.1 Optimal Parameters of the Preprocessing Algorithm

[0189] This section mainly explores the rationality and feasibility of the combination of empirical indicators of the preprocessing algorithm (Algorithm 2) in the experiment. Before conducting the experiment, by analyzing the application call tree and the experimental context environment, we traversed all offloading schemes to obtain the optimal offloading scheme of the application in different regions, and obtained the union of the object method calls for computing offloading in all optimal offloading schemes, that is Figure 11 the object method calls marked in green in the program call tree shown in (a). The present invention refers to the set composed of these object method calls as the ideal cut point set. Since the decision-making algorithm (Algorithm 3) used in the present invention only makes decisions on the execution location of the cut point method, if the cut point set obtained by preprocessing can cover the ideal cut point set, it can ensure finding the optimal offloading scheme during decision-making.

[0190] In Subsection 2.2, we introduced the empirical metrics that affect the decision of the splitting point method: the performance ratio λ, the round-trip time rtt, and the transmission rate v. Among them, λ represents the different performance ratio factors between experimental devices, and the combination of rtt and v represents the network connection characteristic factor. According to their meanings, it is easy for us to obtain that for a local device in the environment, the greater the performance ratio, the better the performance of the remote device, and the greater the possibility that the nodes of the program call tree are selected as the splitting point method; at the same time, the better the network connection, the more splitting points will be generated. In order to make the set of splitting points obtained by preprocessing cover the set of ideal splitting points, so as to ensure finding the optimal decision, we perform a mathematical combination operation on the different performance ratios (λ) between experimental devices (i.e., Device1, Device2, Edge1, Edge2, Cloud) and the different device context environments (rtt + v) in the network configuration according to the experimental environment introduced in Section 5.1, and take the optimal combination of empirical metrics as the experimental scheme to obtain the empirical metric scheme of the present invention, specifically as follows: λ = 2.8, rtt = 40ms, v = 1.5Mb / s.

[0191] To verify the rationality and feasibility of this empirical metric scheme, we use Algorithm 2 to calculate the corresponding set of splitting point methods, as Figure 11 (b) shows.

[0192] Figure 11 It shows that the set of splitting point methods obtained by the empirical metric scheme used in the experiment of the present invention contains a total of 10 splitting point methods. Comparing Figure 11 (a) and Figure 11 (b), it can be found that the 10 splitting points of the experiment of the present invention cover all the ideal splitting points. Further, we respectively perform program refactoring and offloading decisions on the splitting point method of the experimental scheme and the ideal splitting point method to obtain the offloading scheme and the ideal offloading scheme when they are in four regions (for example: Figure 8 shows the offloading scheme for running an application on Honor MYA-AL10 when the device is located in the Garden). By comparison, it is found that the offloading schemes of the two are the same, which also shows that the selection of the empirical metric scheme of the present invention is reasonable and feasible.

[0193] 5.3.2 Additional Execution Cost of the Offloading Mechanism

[0194] To support an application's ability to utilize decentralized and variable computing resources in a mobile edge environment, we propose a program structure reconstruction mechanism for computing offloading. In this section, we will evaluate the overhead brought by the reconstruction to the application. We run the original application, the application with the split point method reconstructed, and the application with all methods reconstructed on a mobile device without performing any offloading operations during the running process. By comparing the program response times of the above three applications, we measure the additional execution cost brought by this computing offloading mechanism. Figure 12 The results on two mobile devices, Honor MYA-AL10 and Honor STF-AL00, are shown.

[0195] Figure 12 The results show that, taking the program response time of the original application as a reference, the program response times of both reconstructed applications increase. The reason is that, compared with the original application, when the reconstructed application calls a method, the method forwarder will incur additional overhead for data transmission and control forwarding. Therefore, we conclude that this computing offloading mechanism does bring some additional execution costs to the application. Further, by comparing the program response times of the original application and the application with the split point method reconstructed, it can be found that the application with the split point method reconstructed has an average additional execution cost of 160 ms, which is acceptable compared to the program response time of the original application. By comparing the program response times of the application with the split point method reconstructed and the application with all methods reconstructed, it can be seen that there is a large gap between them. The application with all methods reconstructed has an average additional execution cost of 1328 ms, and the method of the present invention reduces the additional execution cost.

[0196] 5.3.3 Time Overhead of the Decision Algorithm

[0197] In this section, the decision-making algorithm of the present invention is evaluated by comparing six decision-making algorithms. The decision-making algorithms are classified according to the following two dimensions: (1) The algorithm types are divided into traversal algorithms, genetic algorithms, and the algorithm of the present invention; (2) Whether the algorithm has gone through the preprocessing step of the present invention. Among them, the traversal algorithm obtains the optimal offloading scheme by traversing the combination schemes of all method calls on different computing nodes; the traversal algorithm after preprocessing only combines the object method calls suitable for offloading obtained by preprocessing. The genetic algorithm encodes all method calls into genes 0-1 and forms chromosomes, and obtains the optimal offloading scheme according to evolutionary operations such as selection, crossover, and mutation. Among them, the number of evolutionary generations, population size, crossover probability, and mutation probability of this algorithm are 2000, 150, 0.6, and 0.3 respectively; the genetic algorithm after preprocessing only encodes the object method calls suitable for offloading obtained by preprocessing, and the relevant parameter settings are 1100, 80, 0.6, and 0.3 respectively. The algorithm of the present invention without preprocessing is based on the greedy algorithm idea, and makes decisions on the execution positions of all method calls in turn according to the program call tree; the method of the present invention only makes decisions on the object method calls suitable for offloading obtained by preprocessing (Algorithm 3).

[0198] Table 4 Comparison of Decision-making Times of Different Algorithms

[0199]

[0200]

[0201] Table 4 shows the average time overhead of the above six decision-making algorithms in four regions. The results show that the average decision-making time of the method of the present invention is 218 ms, saving 54%-99% of the time overhead compared with other algorithms. Comparing the three algorithms without preprocessing, comparing the traversal algorithm and the genetic algorithm, the method of the present invention without preprocessing reduces the time by 99% and 78% respectively; comparing the three algorithms after preprocessing, comparing the traversal algorithm and the genetic algorithm, the method of the present invention reduces the time by 89% and 54% respectively; the results show that the offloading decision-making algorithm of the present invention can effectively reduce the time overhead. Analyzing the effect of preprocessing, the decision-making algorithm of the present invention, the genetic algorithm, and the traversal algorithm after preprocessing reduce the time by 63%, 82%, and 99% respectively compared with the corresponding algorithms without preprocessing; the results show that since the preprocessing method of the present invention can reduce the number of cut points, thereby reducing the problem scale and the number of decision-making times (see Subsection 5.3.1 for details), it can be considered that the preprocessing method of the present invention can effectively improve the performance of various types of decision-making algorithms.

[0202] The present invention is directed to object-oriented applications and supports dynamic unloading of applications in MEC from the perspective of program structure. Taking object methods (functions) as the unloading unit, it realizes adaptive unloading in the mobile edge environment. Experiments show that the present invention significantly improves the performance of the program and can quickly determine the optimal unloading scheme in this environment when the context of the device changes. In addition, we find that taking object methods (functions) as the unloading granularity is more suitable for computing unloading in the mobile edge environment, and the preprocessing method of the present invention can effectively improve the performance of the unloading decision algorithm.

[0203] Those skilled in the art should understand that the embodiments of the present application can be provided as methods, systems, or computer program products. Therefore, the present application can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Moreover, the present application can take the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to disk memory, CD-ROM, optical memory, etc.) containing computer-usable program code.

[0204] The present application is described with reference to the flowcharts and / or block diagrams of methods, devices (systems), and computer program products according to the embodiments of the present application. It should be understood that each flow and / or block in the flowchart and / or block diagram can be implemented by computer program instructions, as well as the combination of flows and / or blocks in the flowchart and / or block diagram. These computer program instructions can be provided to the processor of a general-purpose computer, a special-purpose computer, an embedded processor, or other programmable data processing devices to generate a machine, so that the instructions executed by the processor of the computer or other programmable data processing devices generate for implementing in the process Figure 1 one process or multiple processes and / or blocks Figure 1 a device for the functions specified in one block or multiple blocks.

[0205] These computer program instructions can also be stored in a computer-readable memory that can direct a computer or other programmable data processing device to work in a specific manner, so that the instructions stored in the computer-readable memory generate a manufactured article including an instruction device, and the instruction device implements in the process Figure 1 one process or multiple processes and / or blocks Figure 1 a device for the functions specified in one block or multiple blocks.

[0206] These computer program instructions can also be loaded onto a computer or other programmable data processing device, so that a series of operation steps are executed on the computer or other programmable device to generate a computer-implemented process, and thus the instructions executed on the computer or other programmable device provide steps for implementing the functions specified in Figure 1 one process or multiple processes and / or blocks Figure 1 a device for the functions specified in one block or multiple blocks.

[0207] The above are only the preferred embodiments of the present invention, and are not intended to limit the present invention in any other form. Any person skilled in the art may use the technical content disclosed above to make changes or modifications into equivalent embodiments with equivalent changes. However, any simple modifications, equivalent changes and modifications made to the above embodiments based on the technical essence of the present invention without departing from the technical solution content of the present invention still fall within the protection scope of the technical solution of the present invention.

Claims

1. An adaptive offloading method for object-oriented applications at the function granularity in an edge environment, characterized in that First, establish a program call tree through code analysis and discover function calls suitable for unloading. Then, refactor the code of relevant functions according to a specific program structure. Next, make a decision on the unloading scheme based on the context environment at runtime and send the functions to multiple remote devices in the environment for execution; This method includes the following steps: Step S1: First, establish a program call tree. Build a program call tree starting from the main function of the entire program through static code analysis. Each node of the program call tree represents an object method, and the directed edge between nodes represents the method call between object methods. Then, based on the computational complexity and data transfer volume, initially identify the object method calls suitable for computational offloading. The role of such object method calls is to consider whether to perform computational offloading when the execution reaches this object method call; Step S2: First, organize all the object method calls suitable for computational offloading discovered in Step S1 to obtain their corresponding class methods. Then, refactor the code of the class methods according to the computational offloading program structure, and respectively construct a method wrapper and a method forwarder corresponding to the class methods. Then, write the unloading scheme into a configuration file. Based on the configuration file, the runtime mechanism performs adaptive unloading according to the unloading scheme; Step S3: First, construct a cost evaluation model to automatically generate an unloading scheme according to the application context environment. In this unloading scheme, different computational tasks of the application program will be executed on local, edge, or cloud devices in the MEC environment. Based on this cost evaluation model, use the fitness function to calculate the program response time under different unloading schemes through the unloading decision algorithm to determine the appropriate unloading scheme.

2. The method for adaptive offloading of object-oriented applications at the function granularity in the edge environment according to claim 1, wherein In Step S1, the specific method for establishing the program call tree is as follows: Based on the code analysis method, perform static code analysis on the compiled binary file, extract code keywords, and build a program call tree for object-oriented applications; First, describe the program call tree through the following definitions: Definition 1: The program structure of an object-oriented application can be represented as a program call tree Tree r =(M, R), and its entry method is m r ; Among them, M = {m1, m2,..., m n} represents the set of nodes of the program call tree, and any m i represents a method of the program call tree; R represents the set of node call relationships of the program call tree, and any represents an edge of the program call tree, representing that m i calls m j , and the weight of the edge represents the call frequency between nodes; Definition 2: A method of a program call tree includes a method signature and a call path, which is represented as a binary tuple m i =<mSig i , cSeq i >, m i ∈M; where, mSig i represents the method signature of m i , and cSeq i represents a method call path from the main function m main to m i ; Definition 3: mSig i = {mSig|mName(mParams)} represents the method signature of a method m in a program call tree i where mName represents the method name and mParams represents the method parameter list; Definition 4: cSeq i = {mSig main , mSig a ,..., mSig i} represents the call path of a program call tree method m i , which is the combination of the method signatures of the nodes passed from m main to m i , and uniquely constitutes a path to m i ; After the program call tree is completely defined, the code analysis tool Soot is used for static analysis of the program, and the program structure is extracted through the program call tree extraction algorithm; this algorithm takes the main function m main as the entry point of the application program, constructs the program call tree with m main as the root, and uses HashMap to record R. The storage form of the key is <m i ,m j >, indicating that m i calls m j , and its corresponding value represents the number of times m i calls m j ; the input of this algorithm is the program entry point m main and the statement set U main of m main , where any represents the i-th statement of U main ; this algorithm recursively constructs the program call tree by calling the method getTree(). The input parameters m a and U a of this method represent the method to be analyzed and the statement set of this method respectively; this algorithm first obtains the Soot keywords of , then updates the M set, that is, records that the method m a calls the method m s , and then updates the R set, that is, records the method call relationship and updates the weight. Then, the method m s is recursively called for getTree(); when this recursive process ends, the program call tree is output; The specific method for obtaining the object method calls suitable for unloading is as follows: To reduce the subsequent decision search time overhead and the additional cost of the runtime support mechanism, use a preprocessing algorithm to find the object method calls suitable for computational offloading in the application program, that is, obtain the cut-point method; Before preprocessing, introduce the symbol m cur to represent the current node; this preprocessing algorithm takes the program call tree as input and assigns the starting node m of the program call tree to m main during initialization, and then searches for the splitting point method in a depth-first manner; the rules for obtaining the splitting point method are as follows: cur ​ Traverse all branches of m cur For any one of the branches, first find the path from m cur to the first branch node in this branch, and obtain all the nodes on this path; then select at most one splitting point method from these nodes, and this splitting point method can minimize the response time of the program call tree rooted at m cur According to the description of Definition 1, represent the program call tree rooted at m cur as Tree cur , and at the same time represent its response time as T Tree cur (m i ), and the calculation formula is as shown in formula (1); Using the response time of the application as the main metric, i.e., the method m for finding the splitting point i , such that T Tree cur (m i ) is minimized; when m i becomes the splitting point method, then all the methods on the program call tree rooted at m i will be executed on the remote computing node. Therefore, this T Tree cur (m i ) consists of three parts: the local execution time , the remote execution time , and the data transfer time , which are respectively represented by Formula (2), Formula (3), and Formula (4); Formula (2) represents the local execution time, which is equal to m cur The difference between the total execution time on the local computing node and m i The difference in the total execution time on the local computing node; where Represents the number of times m is called in one call to m cur In one call to m i The number of times m is called, which is m cur To m i The product of all the call times on the path to m; Formula (3) represents the remote execution time, and this execution time is quantified by the performance ratio of the remote computing node to the local computing node; Formula (4) represents the data transfer time. One part is the transmission delay, which is equal to the data transfer volume of the cut-point method divided by the transmission rate between the remote computing node and the local computing node. The other part is the round-trip delay between the remote computing node and the local computing node.

3. The method for adaptively offloading an object-oriented application in an edge environment at the function level according to claim 2, characterized in that The implementation method of the preprocessing algorithm for obtaining the cut-point method is as follows: Assign the set of splitting points to an empty set, and use method M.m main as the input of method getDivMethod(), so as to call getDivMethod() to complete the acquisition of splitting points; then check whether m cur has a successor. If so, perform the following operations for each branch: Add the methods on this branch path to set L d in sequence until the first branch node is found; if a branch node exists, use it as the current function and recursively call getDivMethod(); traverse the methods in L d in sequence until method m i is found, and this method can make the response time of the call to tree Tree cur less than the local execution time; when the method is found, add it to divMethod and recursively call the function getDivMethod(); when the preprocessing algorithm finishes execution, obtain the set of splitting point methods divMethod.

4. The object-oriented application under the edge environment adaptive offloading method with function as the granularity according to claim 3, characterized in that In Step S2, to enable the application program to support computational offloading at the method granularity in the MEC environment, construct a program structure that supports the independent deployment of object-oriented methods. The program structure mainly consists of two elements: the method wrapper Method_T_Wrapper and the method forwarder Method_T_Transmitter, and their working principles are as follows: (1) Convert the direct call of Method_I to Method_T into an indirect call via Method_T_Transmitter; (2) Method_T_Wrapper performs the same function as Method_T and is responsible for executing the actual calculation. Method_T_Wrapper modifies Method_T, finds its external variable references, and transforms them into the form of passing in through parameters and returning through return values. The modified class method is stateless; (3) Method_T_Transmitter is a method proxy mechanism. Its external behavior is the same as that of Method_T, but it does not perform actual calculations; it is responsible for determining the execution location of the method, and performing control forwarding and data synchronization, including: initializing and serializing the actual parameter data required for the method wrapper to execute the calculation, and deserializing the return value of the method wrapper to update the local corresponding variables; Based on the above program structure, Method_I locally calls the method transmitter Method_T_Transmitter, and Method_T_Transmitter decides whether to execute the method wrapper Method_T_Wrapper locally or remotely according to the offloading scheme in the configuration file; the call logic of Method_I to Method_T remains unchanged; The construction methods of the method wrapper and the method transmitter are as follows: In the above program structure, the object is deployed locally, and only its methods are offloaded to the remote server; to support the independent execution of the object methods on the remote server, the methods in the class file are refactored to construct the method wrapper; before that, the obtained divMethod is sorted out to obtain its corresponding class method for subsequent refactoring; the class method is described by the following definition: Definition 5-1: DM = {dm1, dm2,..., dm n} represents the set of class methods corresponding to divMethod; where dm i represents the information of the i-th class method; Definition 5-2: dm i = <mSig i , S i > is the class method information represented by a binary tuple, where mSig i represents the method signature of dm i , which is equal to the method signature m j of the corresponding split point method m in divMethod j ; represents the source code statement set of dm i ; After defining the class method, the construction of the method wrapper is completed through the following two steps: The first step is to use static code analysis to detect the external variables used during the method execution; the second step is to transform the external variables into the form of passing in through parameters and returning through return values; External variables refer to variables that are accessed during the method execution and are defined outside the method, and are described by the following definition: Definition 5: Parmeters i = {parameter i1 , parameter i2 ,..., parameter in} represents the external variable set of method dm i , where parameter ij represents the j-th external variable information; Definition 6: parameter ij = {name ij , type ij , ref ij , attr ij} is the external variable information represented by a quadruple, where name ij represents the name of the external variable; type ij represents the type of the external variable; ref ij represents the unique reference of the external variable; attr ij = {attr ij1 , attr ij2 ,..., attr ijn} represents the set of attribute information of the external variable, where attr ijk represents the k-th attribute information; Definition 7: attr ijn = <attrType ijk , attrName ijk > is the attribute information represented by a binary tuple, where attrType ijk is the type of this attribute; attrName ijk is the name of this attribute; Based on the above definitions, the process of obtaining external variables using static code analysis technology is as follows: First, take the statement set S i of method dm i as input to obtain its intermediate code statements; Second, obtain the external variables of each method through string matching; In object-oriented applications, external variables are divided into two types: basic data types and object types, and their intermediate code is as follows: For variables of basic types, the string pattern is "reference of the object to which the method belongs.<class to which the external variable belongs: type name>", and an external variable of a method in the class ColorKMeans is: parameter = <R, int, null, null>; for variables of object types, the string pattern is "variable reference = reference of the object to which the method belongs.<class to which the external variable belongs: type name>", and then the attributes of the external variable of the object type are obtained using the variable reference, and an external variable parameter = <platepng, plateRecognition.PlateNumberGroup, r1, <boolean, AlreadyCheck>> of a method in the class PlateocrActivity is obtained; dm i The set of external variables is obtained through static code analysis; methods suitable for offloading to remote execution are refactored to generate corresponding method wrappers, which are stateless methods that do not involve access to external variables during execution and can be executed on any computing node. Call its method service in the form of receiving data, i.e., input parameters → performing calculations → returning results, i.e., output parameters; the construction of the method wrapper is based on additional input and output parameters, and the additional parameters are constructed according to Parmeters i Construct and describe it as follows: Definition 8: Params i = {params i1 , params i2 ,..., params in} represents the additional parameter set of method dm i ; where params ij represents the information of the j-th additional parameter; Definition 9: params ij =<parType ij , parName ij , parValue ij > is the additional parameter information represented by a triple; where, parType ij represents the parameter type, which corresponds to Parmeters i. type ij ; parName ij represents the parameter name, which corresponds to Parmeters i. name ij ; parValue ij represents the parameter value, which will be assigned during the method execution; The method wrapper performs code refactoring according to the following rules, where the external variable references of the original method are variables c and d: Rule 1: Modify the parameter list and return value of the method; Rule 2: Modify all statements in the method that access external variables; Rule 3: Modify all return statements of the method; The method forwarder is constructed according to the following rules: Rule 1: Keep the method signature and return type of the method forwarder the same as those of the original method; Rule 2: Add a statement to record the position of the current method call in the program call tree; Rule 3: Add a statement to handle additional variables; Rule 4: Add a statement to call the local / remote method wrapper; Rule 5: Add a statement to receive the return result of the method call; During the execution phase of the object-oriented application, the refactored target code and the description file of the offloading scheme generated according to the evaluation model in the following text will be sent to all computing nodes in the edge environment. For the description file, it is formalized as Definition 10: Definition 10: config_file(m) represents a description file of the offloading scheme of an object-oriented application, where m represents different nodes in the set of nodes of the program call tree, that is, object methods; when the execution location of the object method is decided to be local, then config_file(m) takes the value Local; when the execution location of the object method is decided to be a remote computing node, then config_file(m) takes the IP address of the remote computing node; As a proxy mechanism for methods, the method forwarder is supported by the method wrapper in the runtime mechanism of computing offloading. It is responsible for identifying the execution location of the current object method, preparing the actual parameters for method execution according to the local runtime execution environment, and forwarding the method call; when the method execution is completed, its execution result and external variables will be packaged together into return data and then sent back to the application program on the mobile device for necessary program state synchronization to ensure the correctness of the application program.

5. The adaptive offloading method for object-oriented applications at the function granularity in the edge environment according to claim 4, characterized in that In step S3, a method cost model is constructed to describe the execution overhead of each method in the application program on different computing nodes; For a method m of an application i assuming its execution location is n k the execution cost and net execution cost of the method at this node are represented by Definition 11 and Definition 12 respectively; Definition 11: The execution cost of an object-oriented method on a certain computing node can be represented as a binary tuple where Etime represents the execution time of the method from receiving data to generating results, which is related to the performance of the computing node; Edatasize represents the size of the input data of the method, which is not affected by the performance of the computing node and is a fixed value; Definition 12: The net execution cost of an object-oriented method on a certain computing node can be represented as a binary tuple where Stime represents the net execution time of the method, which is expressed as the execution time of the method - the execution time of all method calls within the method body * the respective call times of each method call; Build an application context model to collect the environmental information of the application device, including the computing nodes in the environment and the connectivity information between them; The context environment of the application program consists of devices DS in different scenarios, two edge servers ES, and a cloud server CS; it is described by Definition 13: Definition 13: Model this context environment with a graph G c =(N, E), where N represents a set of computing node sets including local devices and remote servers, and E represents a set of communication link sets between nodes. Each edge (n p , n q ) ∈ E is associated with the data transfer rate p between n q and n and the round-trip delay ; According to this context environment, the offloading scenario for object-oriented applications is as follows: initially, the application program runs on the local device; during the execution process, the object method is sent to the edge server or the cloud server; finally, the result data is returned to the local device through the communication link; Computing offloading requires offloading decisions, which determine which methods are offloaded and to which computing nodes, forming an offloading plan; the optimal offloading decision should minimize the offloading cost; the offloading plan is defined by Definition 14; Definition 14: DEP = {dep(m1), dep(m2),..., dep(m n )} represents an unloading scheme; where m i ∈Tree main .M, that is, all methods in the program call tree; dep(m i )∈N is a computing node for a certain unloading; Evaluate the program response time of the offloading plan through a cost evaluation model; the cost evaluation model is affected by evaluation factors; Evaluate the response time of the offloading decision through a fitness function, which is calculated according to the evaluation factors, and the offloading plan with the minimum fitness value is the optimal offloading plan; Program response time T response Composed of the unloading times of all methods main in the program call tree Tree and the calculation formula is formula (5); Equation (6) represents the unloading time of m i , which consists of two parts of time. One is the execution time of m i in dep(m i ); the other is the data transfer time. Equation (7) represents m i at the execution time of dep(m i ), which is calculated by multiplying the net execution time of m i at dep(m i ) by the number of invocations; Equation (8) represents the total data transfer time, part of which is the transmission time, which is equal to the data transfer volume of m i divided by the transmission rate of dep(m j ) and dep(m i ), and the other part is the round-trip delay between dep(m j ) and dep(m i ); Each calculated according to formula (6) m i ∈Tree main . The accumulation of.M is the response time of the application; this result is used for the offloading decision algorithm; The implementation method of the unloading decision algorithm is as follows: First, add a virtual node to the program call tree, that is, the caller of the main function, denoted as m main ’caller, and set its execution location to the mobile device DS together with the main function m main ; then call the getGreedyDEP() method and pass m main ’caller as the actual parameter; the getGreedyDEP() method traverses the program call tree using the depth-first strategy; the specific operations are as follows: Determine whether there is a subtree in the input parameter of the method: if not, directly return 0; if so, set the execution location of the subtree to the execution location of the parent node; for the object method calls suitable for unloading in the subtree, select a new unloading node that makes the function value of the fitness function the smallest among the current unloading node and the nodes with better performance than the current unloading node; recursively calculate the appropriate unloading scheme for the subtree according to the above method, and update the optimal scheme when a better scheme for the subtree is found; when the traversal is completed, the unloading scheme composed of the unloading locations of each method is the final deployment scheme.

Images