Android application energy consumption evaluation method oriented to code reconstruction

Abstract

The invention relates to a code reconstruction-oriented Android application energy consumption evaluation method, which comprises the following steps of: S1, generating a test case set associated with a method for an application program; s2, selecting test cases associated with the method influenced by reconstruction from the generated test case set to form a test case set for evaluating the energy consumption of the Android application before and after reconstruction; s3, reconstructing a plurality of given reference applications to obtain each reference application and a corresponding reconstruction method; obtaining a corresponding test case set through methods of S1-S2; for each reference application and the corresponding reconstruction method thereof, extracting dynamic feature data of corresponding energy consumption behaviors before and after the application reconstruction, and estimating corresponding energy consumption data before and after the application reconstruction, so as to generate a code reconstruction-oriented energy consumption data set; s4, constructing a prediction model of the energy consumption of the Android application before and after code reconstruction; and S5, evaluating the energy consumption of the Android application by using the prediction model. The method is beneficial to accurately evaluating the energy consumption of the Android application before and after code reconstruction.

Description

Technical Field

[0001] The present invention relates to the technical field of Android application energy consumption assessment, and in particular to an Android application energy consumption assessment method oriented to code reconstruction. Background Art

[0002] With the popularity of mobile devices and the diversity of applications, smartphones, tablets, etc. have become indispensable tools in people's daily life and work. By 2022, the number of smartphone users worldwide has exceeded 6.6 billion, of which the Android system occupies about 71.8% of the market share with its openness and flexibility. A large number of users use various applications for a long time and at a high frequency, which will undoubtedly consume a lot of electricity. This power consumption not only means a waste of energy, but also leads to a large amount of carbon dioxide emissions, exacerbating the problem of global climate change. In addition, high energy consumption will also affect the battery life of the device and reduce the user experience. More importantly, energy consumption has become a key factor affecting the user experience and uninstallation decisions of Android applications. Users prefer to use applications that run smoothly and do not consume power too quickly. Therefore, energy consumption has become a quality attribute that both developers and users pay close attention to.

[0003] In the field of software engineering, code refactoring can improve software quality by adjusting the internal structure of the code without changing the constraints of external functions and behaviors. Code refactoring is regarded as a systematic, rigorous and continuous code optimization process. It has always been a commonly used method in the industry to improve quality during software development and maintenance. In addition, a large number of studies have shown that different types of refactoring have different effects on the energy consumption of applications. Some refactorings may lead to increased runtime energy consumption, while others may reduce runtime energy consumption. Therefore, code refactoring can not only improve the quality attributes of software, but also help to improve the runtime energy consumption of Android applications to a certain extent.

[0004] Therefore, how to construct the optimal test case set to achieve comprehensive coverage of code structure changes, and then accurately evaluate the specific impact of code refactoring on energy consumption, so as to provide important judgment indicators for the update of Android applications, is an urgent problem to be studied and solved. In response to the above challenges, a number of studies on the generation of Android application test cases have emerged in recent years. Developers and testers have proposed many methods that can be used to evaluate the energy consumption of Android applications, but the existing research and methods still have certain limitations and challenges. In terms of Android application test case generation, most research methods tend to focus on the vulnerabilities of the Android application itself or shift the focus to the Android application code coverage, and do not consider the relationship between some methods that have undergone code structure changes and energy consumption. In terms of Android application energy consumption evaluation, most existing methods tend to rely on the built-in energy consumption measurement technology of Android devices, which will have certain challenges in terms of accuracy. In addition, existing methods often do not pay attention to the energy consumption impact caused by changes in code structure, which makes it difficult for existing methods to accurately evaluate the specific changes in energy consumption when facing refactored Android applications. Summary of the invention

[0005] The purpose of the present invention is to provide an Android application energy consumption evaluation method for code reconstruction, which is conducive to accurately evaluating the energy consumption of Android applications before and after code reconstruction.

[0006] In order to achieve the above object, the technical solution adopted by the present invention is: an Android application energy consumption evaluation method for code reconstruction, comprising the following steps:

[0007] S1. For an application, generate a set of test cases associated with the method;

[0008] S2. Selecting test cases associated with the methods affected by the reconstruction from the generated test case set to form a test case set for evaluating the energy consumption of the Android application before and after the reconstruction;

[0009] S3. For a given plurality of benchmark applications, refactor them through a refactoring tool to obtain each benchmark application and its corresponding refactoring method; for each benchmark application and its corresponding refactoring method, obtain a corresponding test case set through the method of steps S1-S2; for each benchmark application and its corresponding refactoring method, extract dynamic feature data of energy consumption behavior before and after application refactoring, and estimate energy consumption data before and after application refactoring, thereby generating an energy consumption data set for code refactoring;

[0010] S4, build a prediction model for the energy consumption of Android applications before and after code refactoring;

[0011] S5. Use the constructed prediction model to evaluate the energy consumption of Android applications.

[0012] Further, in step S1, for the application Appk , generating a set of test cases associated with the method, specifically including the following steps:

[0013] S101, obtaining the application name ApkName according to the input application source code address ApkNamePath;

[0014] S102, obtaining a test case set ListCasePc corresponding to the application name ApkName on the PC side;

[0015] S103, push the test case set ListCasePc to the mobile phone;

[0016] S104, for each test case in the test case set ListCasePc, execute steps S105-S108; after completion, execute step S109;

[0017] S105, the application App k Install on mobile phone;

[0018] S106, open the Jacoco plug-in device and start code instrumentation;

[0019] S107. Start the application App k , and then execute the test case; after the test case is executed, exit the application App k ;

[0020] S108, obtain the Jacoco coverage report and add it to the report list ListReport;

[0021] S109. By analyzing each Jacoco coverage report in the report list ListReport, a method list associated with each test case is obtained, thereby obtaining a test case set associated with the method and outputting it.

[0022] Further, in step S2, based on the code refactoring-affected method list, test cases associated with the refactoring-affected methods are selected from the generated test case set, specifically including the following steps:

[0023] S201, searching for a test case set associated with a method corresponding to an application according to the application name, and then executing step S202;

[0024] S202, according to the input code refactoring affected method list MethodUList, for each method in the code refactoring affected method list MethodUList, execute step S203; after completion, execute step 204;

[0025] S203, according to the method name MethodName of the method, searching from the test case set associated with the method whether the method exists, if yes, selecting the test case corresponding to the method from the test case set associated with the method, otherwise regenerating the test case set associated with the method, and then selecting the test case corresponding to the method from the regenerated test case set associated with the method;

[0026] S204. All the obtained test cases are integrated to form a test case set for evaluating the energy consumption of the Android application before and after the reconstruction.

[0027] Furthermore, all the test cases obtained are synthesized, and the specific method is as follows: if there is an intersection between the test case sets corresponding to each method in the code refactoring affected method list MethodUList, then the intersection is selected as the test case set for evaluating the energy consumption of the Android application before and after the reconstruction; if there is no intersection, then several test cases are randomly selected from the test case sets corresponding to each method to form a test case set for evaluating the energy consumption of the Android application before and after the reconstruction.

[0028] Furthermore, in step S3, for a benchmark application and its corresponding reconstruction method, dynamic feature data of the corresponding energy consumption behavior before and after the application is reconstructed are extracted, specifically including: using the / proc / stat command to obtain global system behavior information; using the / proc / pid / stat command to obtain local information of the process; using the strace -c–p pid command to obtain system call information of the process.

[0029] Furthermore, in step S3, for the input benchmark application source code address set ApkNamePathList and the method-associated test case set CaseMethodlist, the energy consumption data before and after the application reconstruction are estimated, and the corresponding energy consumption data set EnergyList is output, which specifically includes the following steps:

[0030] S301, initializing the environment; initializing the measuring equipment;

[0031] S302, for each application source code address ApkNamePath in the reference application source code address set ApkNamePathList, execute steps S303-S313; after completion, execute step S314;

[0032] S303, obtaining a method list whose code has been changed after the refactoring operation through code structure change sampling, that is, a code refactoring-affected method list MethodUList;

[0033] S304, obtaining the application name ApkName according to the application source code address ApkNamePath;

[0034] S305, obtaining a test case set TestCaseList for evaluating the energy consumption of the Android application before and after the refactoring corresponding to the application according to the application name ApkName and the code refactoring-affected method list MethodUList;

[0035] S306, for the application before and after reconstruction, execute steps S306-313 respectively;

[0036] S307, initializing the environment; installing the application;

[0037] S308, after waiting for a set time, the measuring device starts measuring;

[0038] S309, performing time synchronization;

[0039] S310, executing a test case set corresponding to the application program;

[0040] S311, after waiting for a set time, the measuring device stops measuring;

[0041] S312, obtaining measurement data and outputting it;

[0042] S313, uninstall the application and wait for a set time;

[0043] S314. Output an energy consumption data set EnergyList including energy consumption data before and after application reconstruction.

[0044] Furthermore, in step S4, based on the generated energy consumption dataset for code refactoring, a prediction model of Android application energy consumption before and after code refactoring is constructed using a random forest algorithm.

[0045] Furthermore, the prediction model is composed of a combination of multiple decision tree regression models, and the final prediction result of the prediction model is obtained by averaging the prediction results of the multiple decision tree regression models; the working method of the prediction model is: first, randomly extract samples from the energy consumption data set to form n training sample sets; then, based on these n training sample sets, construct n decision tree regression models, and each decision tree regression model generates a prediction result; finally, take the average of the n prediction results, use it as the final prediction result and output it.

[0046] Compared with the prior art, the present invention has the following beneficial effects: the present invention provides an Android application energy consumption evaluation method for code refactoring, the method proposes a test case generation and selection technology, generates a test case set associated with the application method, and selects the test case associated with the method affected by the refactoring on this basis, to form a test case set for evaluating the energy consumption of the Android application before and after the refactoring; the test case generation and selection technology can provide a test case set with the highest possible coverage and the smallest possible number for the local changes in the code structure at the method level caused by the refactoring; based on the test case generation and selection technology, corresponding test case sets are generated for a given plurality of benchmark applications, and then the dynamic feature data of the energy consumption behavior before and after the application refactoring are extracted, and the energy consumption data before and after the application refactoring are estimated, thereby generating an energy consumption data set for code refactoring; on this basis, a prediction model for the energy consumption of the Android application before and after the code refactoring is constructed, so as to achieve a more accurate estimation of the energy consumption of the Android application before and after the code refactoring. BRIEF DESCRIPTION OF THE DRAWINGS

[0047] Figure 1 is a flow chart of a method implementation of an embodiment of the present invention;

[0048] Figure 2 is a flow chart of generating a test case set associated with a method in an embodiment of the present invention;

[0049] Figure 3 This is a schematic diagram of the Jacoco operation in an embodiment of the present invention;

[0050] Figure 4 This is a diagram of the network crawler architecture in an embodiment of the present invention;

[0051] Figure 5 is a test case selection flow chart in an embodiment of the present invention;

[0052] Figure 6 is a flow chart of dynamic feature extraction of energy consumption behavior of Android applications in an embodiment of the present invention;

[0053] Figure 7 is a flow chart of energy consumption estimation of an Android application before and after reconstruction based on a test case set in an embodiment of the present invention;

[0054] Figure 8 is a schematic diagram of time synchronization in an embodiment of the present invention;

[0055] Fig. 9 is a flow chart of energy consumption measurement in an embodiment of the present invention;

[0056] Fig.10 is a flow chart of energy consumption data set generation for code reconstruction in an embodiment of the present invention;

[0057] Fig.11It is a schematic diagram of the implementation principle of the prediction model based on random forest in an embodiment of the present invention. DETAILED DESCRIPTION

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

[0059] It should be noted that the following detailed descriptions are exemplary and are intended to provide further explanation of the present application. Unless otherwise specified, all technical and scientific terms used herein have the same meanings as those commonly understood by those skilled in the art to which the present application belongs.

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

[0061] like Figure 1 As shown, this embodiment provides an Android application energy consumption evaluation method for code reconstruction, comprising the following steps:

[0062] S1. For an application, generate a set of test cases associated with the method;

[0063] S2. Selecting test cases associated with the methods affected by the reconstruction from the generated test case set to form a test case set for evaluating the energy consumption of the Android application before and after the reconstruction;

[0064] S3. For a given plurality of benchmark applications, refactor them through a refactoring tool to obtain each benchmark application and its corresponding refactoring method; for each benchmark application and its corresponding refactoring method, obtain a corresponding test case set through the method of steps S1-S2; for each benchmark application and its corresponding refactoring method, extract dynamic feature data of energy consumption behavior before and after application refactoring, and estimate energy consumption data before and after application refactoring, thereby generating an energy consumption data set for code refactoring;

[0065] S4, build a prediction model for the energy consumption of Android applications before and after code refactoring;

[0066] S5. Use the constructed prediction model to evaluate the energy consumption of Android applications.

[0067] 1. Generation of test case sets associated with methods

[0068] In order to build an efficient and accurate list of test case-associated methods, a large number of test cases must be generated to ensure the highest possible method coverage. For apps with a small number of lines of code and simpler operating logic, you can directly use the random test case generation method or the manual test case generation method to generate the required test case set. For apps with a large number of lines of code and more complex operating logic, you can use the random test case generation method combined with the manual test case generation method to generate the required test case set. The logic of randomly generating test cases combined with manually generating test cases is: first, use the random test method to build an App test case generation framework to generate a large number of test cases, also known as test case sets, and then use the jacoco tool to detect the code coverage obtained after the above test case set is executed. If the obtained code coverage is at a low level, for example, the method coverage is around 20%, then the manual test case generation method is used to make up for the shortcomings of the random test case generation method.

[0069] On this basis, a corresponding method list is generated for each test case in the test case set. By executing the test case set, it is analyzed which methods are executed and which methods are not executed. If at least one command in a method is executed, the method is considered to have been executed, otherwise, the method is not executed, thereby generating a method-associated test case set. The main function of generating a method-associated test case set is to select appropriate test cases in a specific application, which is convenient for energy consumption measurement of the reconstruction method in the following text.

[0070] For App k , using the method-level high coverage Android application test case generation method to generate the corresponding test case set, namely App k The test case set associated with the corresponding method. Figure 2 is a flowchart of the test case set generated by the method. Table 1 is the pseudo code of the algorithm. Figure 2 As shown in Table 1, the specific implementation steps of the method are as follows.

[0071] S101. Obtain the application name ApkName according to the input application source code address ApkNamePath.

[0072] S102, according to the application name ApkName, obtain the test case set ListCasePc corresponding to it on the PC side. Here, the test case set ListCasePc is a test case set pre-generated by artificial generation, random generation or a combination of both methods.

[0073] S103. Push the test case set ListCasePc to the mobile phone.

[0074] S104. For each test case in the test case set ListCasePc, execute steps S105-S108; after completion, execute step S109.

[0075] S105, the application App k Install on your mobile phone.

[0076] S106, open the Jacoco plug-in device and start code instrumentation.

[0077] S107. Start the application App k , and then execute the test case; after the test case is executed, exit the application App k .

[0078] S108. Obtain the Jacoco coverage report and add it to the report list ListReport.

[0079] S109. By analyzing each Jacoco coverage report in the report list ListReport, crawling and collecting the method list associated with each test case through a crawler, thereby obtaining the method-associated test case set CaseMethodList and outputting it.

[0080] Table 1 Method-related test case set generation algorithm flow

[0081]

[0082] 1.1 Generate code coverage report

[0083] The most important task of generating a code coverage report is to automatically install and start the App and the Jacoco plug-in, and generate an intermediate file (coverage.gc) after the App finishes running, in order to generate the final required code coverage report. Specifically, (1) Automatically install and start the App: This embodiment uses the gradle command in AndroidStudio / Idea to install the Apk on the mobile phone by executing gradle installDebug or . / gradle installDebug, and starts the App through the adb shellam start-n{package_name} / {activity_name} command; (2) Start the Jacoco plug-in and generate a coverage report: It should be noted here that if you want to obtain the execution path of the application, you need to instrument the application. As a Java language inspection tool, Jacoco provides two instrumentation methods, namely On-The-Fly (online instrumentation) and Offliine (offline instrumentation). Since most of the applications selected in this embodiment are Android projects, the instrumentation method selected in this embodiment is offline instrumentation. The principle of this method is as follows Figure 3 As shown in the figure, the bytecode needs to be instrumented before testing, and then the instrumented class files or jar packages are generated. After executing these instrumented files or packages, the corresponding coverage information will be generated and stored in the file. Finally, these coverage information are processed uniformly and a detailed report is generated based on them. The command required for this process is adb shell aminstrument "+package_name+" / "+package_name+".jacoco.JacocoInstrumentation".

[0084] 1.2 Test case set associated with analysis report and output method

[0085] In this embodiment, the analysis report module mainly uses a crawler mechanism to reduce manual workload. Its principle diagram is as follows: Figure 4 As shown in the figure, the web crawler architecture is mainly divided into the following parts: crawler caller, URL management, web page downloader, and web page parser. The main functions of each part are as follows:

[0086] (1) Crawler caller: mainly responsible for monitoring the operation of the entire crawling program.

[0087] (2) URL Manager: Categorize and manage URLs to be crawled and URLs that have been crawled.

[0088] (3) Web page downloader: Download the web page corresponding to the captured URL and give it to the web page parser for use.

[0089] (4) Web page parser: After obtaining the target data from the downloaded web page, it generates a new URL set and gives it to the URL manager.

[0090] Under the orderly call of the crawler caller, the three parts are executed cyclically, and finally a data set that meets all the experimental requirements of this article is extracted.

[0091] 2. Test case selection

[0092] Before selecting test cases, we first explain why we need to select test cases. For an Android application, there are n test cases. After code refactoring, the method whose code has changed is method1. At this time, the modified code is local. If all test cases are run once, too much irrelevant code will be executed, that is, code whose code structure has not changed. At this time, the evaluation time and energy consumption measurement noise of this article will increase. However, if the test case set associated with the method affected by the refactoring is strategically selected after the test case selection operation, in this case, the number of test cases to be executed can be minimized, thereby reducing the evaluation time and energy consumption measurement noise of this article. Therefore, before performing energy consumption measurement, the corresponding test case set must be selected for the App to be tested to meet the code changes caused by sampling of code structure changes mentioned above as much as possible.

[0093] Figure 5 is the test case selection flow chart. Table 2 is the pseudo code of the algorithm. Figure 5 As shown in Table 2, based on the list of methods affected by code refactoring, test cases associated with the methods affected by refactoring are selected from the generated test case set. The specific implementation steps of this method are as follows.

[0094] S201. Search for a test case set associated with a method corresponding to an application according to the application name ApkName, and then execute step S202.

[0095] S202 . According to the input code refactoring affected method list MethodUList, for each method in the code refactoring affected method list MethodUList, execute step S203 . After completion, execute step 204 .

[0096] S203. According to the method name MethodName of the method, search from the test case set associated with the method to see whether the method exists. If so, select the test case corresponding to the method from the test case set associated with the method. Otherwise, regenerate the test case set associated with the method according to the execution method path table corresponding to the test case, and then select the test case corresponding to the method from the regenerated test case set associated with the method.

[0097] S204. All the obtained test cases are integrated to form a test case set for evaluating the energy consumption of the Android application before and after the reconstruction.

[0098] All the test cases obtained are summarized as follows: if there is an intersection between the test case sets corresponding to the methods in the code refactoring affected method list MethodUList, then the intersection is selected as the test case set for evaluating the energy consumption of the Android application before and after the refactoring; if there is no intersection, then a number of test cases are randomly selected from the test case sets corresponding to the methods to form a test case set for evaluating the energy consumption of the Android application before and after the refactoring. For example, assuming that the method list affected by the refactoring instance is [A, B], they correspond to [[case1, case2, case3, case4], [case1, case2, case5, case6]] respectively. Take their intersection as the test case set to be executed, that is, [case1, case2]. Through this process, the appropriate test case set can be dynamically selected according to the specific situation of the application to ensure effective test coverage when the method changes.

[0099] Table 2 Test case selection process

[0100]

[0101] 3. Dynamic feature extraction of Android application energy consumption behavior

[0102] For a benchmark application and its corresponding reconstruction method, the dynamic feature data of the energy consumption behavior before and after the application reconstruction is extracted, including: using the / proc / stat command to obtain the global system behavior information; using the / proc / pid / stat command to obtain the local information of the process; using the strace-c–p pid command to obtain the system call information of the process.

[0103] like Figure 6 As shown in the figure, the specific process of dynamic feature extraction of Android application energy consumption behavior is as follows:

[0104] After installing ADB (Android Debug Bridge) on the computer to establish a communication connection with the mobile phone, first delete the feature information saved on the computer and send the uninstall apk command to uninstall the existing application with the same name on the mobile phone; then install the application to be tested, start the application, and use the ps-ef|grep packageName command to obtain the process number (pid) of the application;

[0105] Then send the / proc / stat command to obtain the global system information before running the test case and save it in the computer's file system; then send the strace-cp-pid& command to track the system call information of the application corresponding to the pid process in the background and start running the test case, using / proc / pid / stat to capture the local information of the application process when it is running;

[0106] Next, the computer sends the kill pid command to terminate the application. At this time, the computer will save the local information of the process, and the system call information when the application is running will be saved in the folder specified by the mobile phone. Finally, the system call information saved on the mobile phone is copied to the folder specified by the computer, and the / proc / stat command is used again to obtain the global system information after the operation. The global system information after running the test case is subtracted from the global system information before the operation to obtain the global system resource information occupied by the application. At this point, all the dynamic characteristics of the application at runtime can be obtained.

[0107] 4. Energy consumption estimation of Android applications before and after reconstruction based on test case sets

[0108] Aiming at covering the changes in code structure due to the refactoring of instance combination applications as comprehensively as possible and measuring energy consumption as accurately as possible, this method gives an Android application App k When executing test cases, how to implement energy consumption measurement, such as Figure 7 shown.

[0109] In order to evaluate the efficiency of code refactoring, the initial version of App (App k0 , without refactoring) and the refactored version (App k1 ) to compare and evaluate the energy consumption values. Therefore, when measuring the energy consumption, it is necessary to measure the energy consumption of the application before and after the reconstruction.

[0110] Before estimating energy consumption, time synchronization is required to lay a solid foundation for accurate energy consumption measurement. Finally, the energy consumption measurement tool Monsoon Power Monitor is used to measure the App k0 And App k1 The energy consumed by the execution process is measured. The pseudo code of the algorithm is shown in Table 3.

[0111] For the input benchmark application source code address set ApkNamePathList and the method-associated test case set CaseMethodlist, estimate the energy consumption data before and after the application reconstruction, and output the corresponding energy consumption data set EnergyList, specifically including the following steps:

[0112] S301, perform environment initialization; perform measurement equipment initialization.

[0113] S302. For each application source code address ApkNamePath in the reference application source code address set ApkNamePathList, execute steps S303-S313; after completion, execute step S314.

[0114] S303 . Obtain, through code structure change sampling, a method list whose codes have been changed after the refactoring operation, that is, a code refactoring-affected method list MethodUList.

[0115] S304. Obtain the application name ApkName according to the application source code address ApkNamePath.

[0116] S305 . According to the application name ApkName and the code refactoring-affected method list MethodUList, obtain a test case set TestCaseList corresponding to the application for evaluating the energy consumption of the Android application before and after the refactoring.

[0117] S306. For the application before and after reconstruction, execute steps S306-313 respectively.

[0118] S307, initialize the environment; install the application.

[0119] S308: After waiting for a set time, the measuring device starts measuring.

[0120] S309: Perform time synchronization.

[0121] S310: Execute the test case set corresponding to the application.

[0122] S311. After waiting for a set time, the measuring device stops measuring.

[0123] S312: Obtain measurement data and output it.

[0124] S313, uninstall the application and wait for a set time.

[0125] S314. Output an energy consumption data set EnergyList including energy consumption data before and after application reconstruction.

[0126] Table 3. Energy consumption estimation of Android applications before and after reconstruction based on test case sets

[0127]

[0128]

[0129] 4.1 Time Synchronization

[0130] Time synchronization is a key process to ensure that the time between different devices or systems remains consistent. In the experimental device of this embodiment, the time used by the Monsoon device is based on the time on the PC, while the mobile phone relies on its local time. There may be time inconsistencies between the two, and this inconsistency is a problem that cannot be ignored for experiments that rely on time to measure and process data.

[0131] Specifically, the inconsistency of time may cause deviations in the experimental results. In the energy consumption measurement of this embodiment, different measurement intervals are divided by time, and the energy consumption data in these intervals are accumulated. If the time of the PC and the mobile phone are not synchronized, there may be errors in the divided measurement intervals, resulting in inaccurate calculation of the energy consumption data. This error may have a significant impact on the experimental results, making it impossible to draw correct conclusions.

[0132] In addition, time synchronization is also an important means to ensure the repeatability and consistency of experiments. If the time on the PC and the mobile phone is inconsistent during each experiment, the results of each experiment may be different, which makes it impossible to accurately compare and analyze the experimental results. By performing time synchronization, it can ensure that the time between devices is consistent during each experiment, making the experimental results more reliable and accurate.

[0133] Therefore, in the experimental device of this embodiment, time synchronization is very important. By performing time synchronization, the time inconsistency between the PC and the mobile phone can be eliminated, and the accuracy and reliability of energy consumption measurement can be ensured, thereby providing strong data support for the experiment of this method.

[0134] The synchronization method selected in this embodiment is to use the Network Time Protocol (NTP) to perform synchronization operations, and the NTP server used is ntp.com.

[0135] The time synchronization principle is as follows Figure 8 As shown, there are four time points (T1, T2, T3, T4) and two transmission delays (d1, d2), which are used to calculate the time deviation (t) between the server and the client and the round-trip time (d) of the NTP packet.

[0136] T1 is the timestamp when the client sends the NTP request; T2 is the timestamp when the server receives the NTP request; T3 is the timestamp when the server replies to the NTP request; T4 is the timestamp when the client receives the NTP reply packet; d1 is the transmission delay of the NTP request packet, d2 is the transmission delay of the NTP reply packet; t is the time deviation between the server and the client, and d is the round-trip time of the NTP packet. Now that T1, T2, T3, and T4 are known, we hope to find t to adjust the client clock, and we can get formula (4-1).

[0137]

[0138] Assuming that the transmission delays of NPT request and reply packets are equal, that is, d1 = d2, we can obtain equation (4-2).

[0139]

[0140] According to formula (3-1), t can also be expressed as formula (4-3).

[0141]

[0142] It can be seen that t and d are only related to the difference between T2 and T1 and the difference between T3 and T4, but not to the difference between T2 and T3, that is, the final result has nothing to do with the time required for the server to process the request. Therefore, the client can calculate the time offset Offset with the server through T1, T2, T3, and T4. That is, offset = ((T2-T1) + (T3-T4)). Through this calculation, the time deviation (t) between the server and the client can be obtained. This time deviation can be used to adjust the client's clock to ensure time synchronization between the client and the server.

[0143] In the above case, the synchronization operation is completed by simply synchronizing the time of the PC and mobile device with the NTP server. Specifically, on the PC, write a time synchronization tool to calculate the time difference between the PC and the NTP server as PcOffset. On the mobile device, program a time synchronization App, install it on the mobile device and run it, calculate the time difference between it and the NTP server as AndroidOffset. In the energy consumption calculation, add the corresponding time difference to the time recorded on the PC and the time recorded on the mobile phone to achieve time synchronization.

[0144] As mentioned above, write a program on the PC to calculate PcOffset, and write a synchronization app on the Android platform to get AndroidOffset. Then add PcTime (local time on the PC) and PcOffset (offset of PC relative to Ntp) to get NtpTime. The time synchronization on the Android device is to add AndroidTime (local time of Android) and AndroidOffset (offset relative to Ntp) to get NtpTime. In this way, the synchronization between the Android device and the PC is completed. The time synchronization process is shown in Table 4 below.

[0145] Table 4 Time synchronization process

[0146]

[0147] 4.2 Energy consumption measurement

[0148] For the sake of illustration, we will use an initial version of App in an application. k0 As an example, eng(0,j,k) is used to represent the training application App k (1≤k≤p) The 0th version collects energy consumption values ​​under the jth test case set. Fig. 9 Shows the App k The process of obtaining the energy consumption value eng(0,j,k) of the 0th version under the jth test case mainly includes six steps: first, the desktop sends a start measurement command to the power measurement device; then sends a command to execute the jth test case tcj to the test mobile phone; then the mobile phone executes the test case tcj and drives the i-th version of the App k Run. When the test case tcj is executed, the command of the Android debug bridge is used to automatically send the collected feature information to the specified folder of the desktop computer; then the module deployed by the Monkey framework on the mobile terminal notifies the module deployed by the Monkey framework on the desktop computer of the end of the test case tcj execution; at the same time, the desktop computer sends an end measurement instruction to the measurement device, and collects the power data between the start and end instructions from the measurement device; finally, the desktop computer calculates the training application App k The energy consumption value eng(0,j,k) of the 0th version under the jth test case.

[0149] In order to accurately calculate the App k The 0th version is in the jth test case tc j The energy consumption value eng(0,j,k) under the condition of Monsoon measurement equipment is set to 5000Hz and tc jThe actual execution start and end timestamps are used as the starting and end points of the calculation. The energy consumption value eng(0,j,k) is calculated by accumulating the energy consumption (the product of the instantaneous power value and the sampling period value) corresponding to the sampling points between the start and end points.

[0150] 5. Generation of energy consumption dataset for code refactoring

[0151] The generation of energy consumption datasets for code refactoring is mainly based on the above work, which includes the test case technology for energy efficiency evaluation of Android application code refactoring, dynamic feature extraction of Android application energy consumption behavior, and energy consumption estimation of Android applications before and after refactoring based on test case sets. The implementation process of energy consumption dataset generation for code refactoring is as follows: Fig.10 As shown, first, for a given benchmark case, the benchmark application App can be generated by using the test case technology and preprocessing method of Android application code reconstruction energy efficiency evaluation. k The corresponding test case set is then sent to the dynamic feature extraction module of Android application energy consumption behavior and the Android application energy consumption estimation module before and after reconstruction based on the test case set, and the App k App before reconstruction k0 、App k Refactored App k1 The corresponding dynamic characteristics of energy consumption behavior and energy consumption value. By repeating the above work several times, this paper finally generates a total of 998 energy consumption data sets through the data set. Next, the two key steps of preprocessing and data set generation are explained.

[0152] 5.1 Preprocessing

[0153] During preprocessing, for known benchmark cases App k , by obtaining the refactoring type specific to Android through the refactoring tool, we can get the refactoring set. Assuming its length is n, we then randomly sample the set to generate a 0, 1 vector r of length n. By analogy, we can get a set of sequences, which includes many sequences. For each sequence, we apply it to the source code, delete the specific instance of the refactoring corresponding to the position 0. If the position is 1, then keep the refactoring instance of the corresponding position, and finally output the Apk file corresponding to a certain refactoring sequence combination. In this process, we can get the list of methods affected by the refactoring according to the tool, and then use the third section of Chapter 3 to get the benchmark case App. k Finally, through the first and second sections of this chapter, we can get the characteristic values ​​and energy consumption values, and then aggregate the obtained characteristic data and energy consumption values ​​to complete the data set generation.

[0154] 5.2 Dataset Generation

[0155] The dataset generation process mainly includes two important modules: dataset collection and dataset processing. The following describes the two modules separately.

[0156] (1) Dataset Collection

[0157] Data collection needs to collect two aspects of content, one is the data collection about dynamic features, and the other is the data collection about energy consumption values. Among them, the dynamic feature value mainly provides functions such as tracking system calls and processor process state changes based on the strace command of Android's underlying Linux. Its -c command gives statistics on different system calls activated by Android applications. At the same time, the Linux / proc pseudo file system can be used to capture the number of CPU ticks and dynamic feature information about the process. Training App k The local information of the process can be collected through / proc / pid / stat, and some information related to the global behavior of the system can be captured by / proc / stat. The energy consumption collection is mainly based on the energy consumption measurement technology mentioned above. The Monkey tool drives the test case set to execute, and the energy consumption meter Monsoon Power Monitor is used to collect energy data. Then the energy consumed during the execution of the Android phone is calculated and incorporated into the dynamic characteristic value to complete the data set collection. Based on the above, the number of data sets constructed in this embodiment is 998.

[0158] (2) Dataset processing

[0159] We observed that the system call information in these dynamic features, although their features are very similar, have different names. For example, lseek and llseek are two system calls with the same purpose. When one application calls lseek and the other calls llseek, this is a problem for building an energy consumption model. It is difficult to establish a generalized energy consumption model when the training data is inconsistent. For example, in a case where llseek has never appeared in the model training phase, the impact of llseek on building the energy consumption model is unknown, although the model knows that llseek can have the same effect as lseek. This embodiment solves this problem by grouping similar system calls according to the semantics described in the Linux manual page. System calls with unique functions are not grouped with other system calls.

[0160] Machine learning algorithms usually suffer when the range of values ​​between different features varies greatly. Since the differences between features are observed to be so large, the data is normalized to the range of 0 to 1. This normalization not only speeds up the learning time but also improves the accuracy of the model. The normalization formula is shown below, where x represents the feature vector.

[0161]

[0162] Based on the work that has been done, we study and construct a training data set that can reflect the relationship between the dynamic feature changes of the code and energy consumption, so as to comprehensively capture the impact of the common dynamic feature changes caused by the reconstruction of the Android application code on energy consumption; further design the training algorithm to build a prediction model that does not use external measurement equipment and can accurately evaluate the energy consumption of Android application code after code changes. This method uses dynamic features as X variables and energy consumption values ​​as Y variables, and establishes an energy consumption prediction model through machine learning, which can effectively ensure the effectiveness of the evaluation.

[0163] 6. Construction of prediction model for Android application energy consumption before and after code refactoring

[0164] For a given Android application energy consumption dataset, the random forest regression model shows good prediction performance. Therefore, in this embodiment, based on the generated energy consumption dataset for code refactoring, a prediction model for Android application energy consumption before and after code refactoring is constructed using the random forest algorithm to ensure a high prediction accuracy. The implementation principle of the prediction model based on random forest is as follows: Fig.11 As shown. The prediction model is composed of a plurality of decision tree regression models, and the final prediction result of the prediction model is obtained by averaging the prediction results of the plurality of decision tree regression models. The working method of the prediction model is as follows: first, samples are randomly extracted from the energy consumption data set to form n training sample sets; then, based on the n training sample sets, n decision tree regression models are constructed, and each decision tree regression model generates a prediction result; finally, the n prediction results are averaged, and this is used as the final prediction result and output.

[0165] Those skilled in the art will appreciate that the embodiments of the present application may be provided as methods, systems, or computer program products. Therefore, the present application may adopt the form of a complete hardware embodiment, a complete software embodiment, or an embodiment in combination with software and hardware. Moreover, the present application may adopt the form of a computer program product implemented in one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) that include computer-usable program code.

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

[0167] These computer program instructions may also be stored in a computer-readable memory capable of directing a computer or other programmable data processing device to operate in a specific manner, so that the instructions stored in the computer-readable memory produce an article of manufacture comprising an instruction device, which implements the process Figure 1 A process or multiple processes and / or boxes Figure 1 A function specified in one or more boxes.

[0168] These computer program instructions can also be loaded onto a computer or other programmable data processing device so that a series of operating steps are executed on the computer or other programmable device to produce a computer-implemented process, thereby providing instructions for implementing the process. Figure 1 A process or multiple processes and / or boxes Figure 1 The steps for the functions specified in one or more boxes.

[0169] The above is only a preferred embodiment of the present invention, and does not limit the present invention in other forms. Any technician familiar with the profession may use the above disclosed technical content to change or modify it into an equivalent embodiment with equivalent changes. However, any simple modification, equivalent change and modification made to the above embodiment according to the technical essence of the present invention without departing from the technical solution of the present invention still belongs to the protection scope of the technical solution of the present invention.

Claims

1. A method for evaluating energy consumption of Android applications for code reconstruction, characterized in that: The following steps are involved: S1. For an application, generate a set of test cases associated with the method; S2. Selecting test cases associated with the methods affected by the reconstruction from the generated test case set to form a test case set for evaluating the energy consumption of the Android application before and after the reconstruction; S3. For a given plurality of benchmark applications, refactor them through a refactoring tool to obtain each benchmark application and its corresponding refactoring method; for each benchmark application and its corresponding refactoring method, obtain a corresponding test case set through the method of steps S1-S2; for each benchmark application and its corresponding refactoring method, extract dynamic feature data of energy consumption behavior before and after application refactoring, and estimate energy consumption data before and after application refactoring, thereby generating an energy consumption data set for code refactoring; S4, build a prediction model for the energy consumption of Android applications before and after code refactoring; S5. Use the constructed prediction model to evaluate the energy consumption of Android applications.

2. The method for evaluating energy consumption of Android applications for code reconstruction according to claim 1, characterized in that: In step S1, for the application App k , generating a set of test cases associated with the method, specifically including the following steps: S101, obtaining the application name ApkName according to the input application source code address ApkNamePath; S102, obtaining a test case set ListCasePc corresponding to the application name ApkName on the PC side; S103, push the test case set ListCasePc to the mobile phone; S104, for each test case in the test case set ListCasePc, execute steps S105-S108; after completion, execute step S109; S105, the application App k Install on mobile phone; S106, open the Jacoco plug-in device and start code instrumentation; S107. Start the application App k , and then execute the test case; after the test case is executed, exit the application App k ; S108, obtain the Jacoco coverage report and add it to the report list ListReport; S109. By analyzing each Jacoco coverage report in the report list ListReport, a method list associated with each test case is obtained, thereby obtaining a test case set associated with the method and outputting it.

3. The method for evaluating energy consumption of Android applications for code reconstruction according to claim 1, characterized in that: In step S2, based on the code refactoring-affected method list, test cases associated with the refactoring-affected methods are selected from the generated test case set, specifically including the following steps: S201, searching for a test case set associated with a method corresponding to an application according to the application name, and then executing step S202; S202, according to the input code refactoring affected method list MethodUList, for each method in the code refactoring affected method list MethodUList, execute step S203; after completion, execute step 204; S203, according to the method name MethodName of the method, searching from the test case set associated with the method whether the method exists, if yes, selecting the test case corresponding to the method from the test case set associated with the method, otherwise regenerating the test case set associated with the method, and then selecting the test case corresponding to the method from the regenerated test case set associated with the method; S204. All the obtained test cases are integrated to form a test case set for evaluating the energy consumption of the Android application before and after the reconstruction.

4. The method for evaluating energy consumption of Android applications for code reconstruction according to claim 3 is characterized in that: For all the test cases obtained in combination, the specific method is as follows: if there is an intersection between the test case sets corresponding to each method in the code refactoring affected method list MethodUList, then the intersection is selected as the test case set for evaluating the energy consumption of the Android application before and after the refactoring; if there is no intersection, then several test cases are randomly selected from the test case sets corresponding to each method to form a test case set for evaluating the energy consumption of the Android application before and after the refactoring.

5. The method for evaluating energy consumption of Android applications for code reconstruction according to claim 1, characterized in that: In step S3, for a benchmark application and its corresponding reconstruction method, the dynamic characteristic data of the energy consumption behavior of the application before and after the reconstruction is extracted, specifically including: using the / proc / stat command to obtain the global system behavior information; using the / proc / pid / stat command to obtain the local information of the process; using the strace-c -p pid command to obtain the system call information of the process.

6. The method for evaluating energy consumption of Android applications for code reconstruction according to claim 1, characterized in that: In step S3, for the input benchmark application source code address set ApkNamePathList and the test case set CaseMethodlist associated with the method, the energy consumption data before and after the application reconstruction is estimated, and the corresponding energy consumption data set EnergyList is output, which specifically includes the following steps: S301, initializing the environment; initializing the measuring equipment; S302, for each application source code address ApkNamePath in the reference application source code address set ApkNamePathList, execute steps S303-S313; after completion, execute step S314; S303, obtaining a method list whose code has been changed after the refactoring operation through code structure change sampling, that is, a code refactoring-affected method list MethodUList; S304, obtaining the application name ApkName according to the application source code address ApkNamePath; S305, obtaining a test case set TestCaseList for evaluating the energy consumption of the Android application before and after the refactoring corresponding to the application according to the application name ApkName and the code refactoring-affected method list MethodUList; S306, for the application before and after reconstruction, execute steps S306-313 respectively; S307, initializing the environment; installing the application; S308, after waiting for a set time, the measuring device starts measuring; S309, performing time synchronization; S310, executing a test case set corresponding to the application program; S311, after waiting for a set time, the measuring device stops measuring; S312, obtaining measurement data and outputting it; S313, uninstall the application and wait for a set time; S314 , outputting an energy consumption data set ENergyList including energy consumption data before and after application reconstruction.

7. The method for evaluating energy consumption of Android applications for code reconstruction according to claim 1, characterized in that: In step S4, based on the generated energy consumption dataset for code refactoring, a prediction model of Android application energy consumption before and after code refactoring is constructed using a random forest algorithm.

8. The method for evaluating energy consumption of Android applications for code reconstruction according to claim 7, characterized in that: The prediction model is composed of a plurality of decision tree regression models, and the final prediction result of the prediction model is obtained by averaging the prediction results of the plurality of decision tree regression models; the working method of the prediction model is as follows: firstly, samples are randomly selected from the energy consumption data set to form n training sample sets; Then, based on these n training sample sets, n decision tree regression models are constructed, and each decision tree regression model generates a prediction result; finally, the n prediction results are averaged and output as the final prediction result.

Images