Android application energy consumption evaluation method for code refactoring

Abstract

This invention relates to a method for evaluating the energy consumption of Android applications for code refactoring, comprising: S1, generating a test case set associated with methods in the application; S2, selecting test cases associated with methods affected by refactoring from the generated test case set to form a test case set for evaluating the energy consumption of Android applications before and after refactoring; S3, refactoring multiple given benchmark applications to obtain each benchmark application and its corresponding refactoring method; obtaining the corresponding test case set through the methods in S1-S2; extracting dynamic feature data of energy consumption behavior before and after application refactoring for each benchmark application and its corresponding refactoring method, and estimating the energy consumption data before and after application refactoring, thereby generating an energy consumption dataset for code refactoring; S4, constructing a predictive model of Android application energy consumption before and after code refactoring; S5, using the predictive model to evaluate the energy consumption of Android applications. This method is beneficial for accurately evaluating the energy consumption of Android applications before and after code refactoring.

Description

Technical Field

[0001] This invention relates to the field of Android application energy consumption assessment technology, and specifically to an Android application energy consumption assessment method oriented towards code refactoring. Background Technology

[0002] With the widespread adoption of mobile devices and the diversification of applications, smartphones, tablets, and other similar devices have become indispensable tools in people's daily lives and work. By 2022, the number of smartphone users worldwide had exceeded 6.6 billion, with the Android system holding approximately 71.8% of the market share due to its openness and flexibility. The large number of users using various applications for extended periods and at high frequencies undoubtedly consumes a significant amount of electricity. This electricity consumption not only represents energy waste but also leads to substantial carbon dioxide emissions, exacerbating global climate change. Furthermore, high energy consumption affects device battery life and reduces the user experience. More importantly, energy consumption has become a key factor influencing Android app user experience and uninstallation decisions; users prefer apps that run smoothly and don't drain battery too quickly. Therefore, energy consumption has become a quality attribute of great concern to both developers and users.

[0003] In the field of software engineering, code refactoring can improve software quality by adjusting the internal structure of the code without changing external functionalities and behaviors. Code refactoring is considered a systematic, rigorous, and continuous code optimization process. It has long been a commonly used method in the industry to improve quality during software development and maintenance. Furthermore, numerous studies have shown that different types of refactoring have varying impacts on application energy consumption. Some refactorings may increase runtime energy consumption, while others may decrease it. Therefore, code refactoring not only improves software quality attributes but also contributes to improving the runtime energy consumption of Android applications to some extent.

[0004] Therefore, how to construct the optimal test case set to achieve comprehensive coverage of code structure changes and accurately assess the specific impact of code refactoring on energy consumption, so as to provide important judgment indicators for Android application updates, is an urgent problem to be studied and solved. In response to the above challenges, a number of studies on Android application test case generation have emerged in recent years. Developers and testers have proposed many methods for evaluating the energy consumption of Android applications. However, 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 vulnerabilities in the Android application itself or shift the focus to Android application code coverage, without considering the relationship between certain methods after code structure changes and energy consumption. In terms of Android application energy consumption evaluation, most existing methods rely on the built-in energy consumption measurement technology of Android devices, which presents certain challenges in terms of accuracy. Furthermore, existing methods often do not consider the energy consumption impact caused by changes in code structure, making it difficult for existing methods to accurately assess the specific changes in energy consumption when faced with refactored Android applications. Summary of the Invention

[0005] The purpose of this invention is to provide an Android application energy consumption assessment method for code refactoring, which is beneficial for accurately assessing the energy consumption of Android applications before and after code refactoring.

[0006] To achieve the above objectives, the technical solution adopted by this invention is: an Android application energy consumption assessment method oriented towards code refactoring, comprising the following steps:

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

[0008] S2. Select test cases associated with the methods affected by the refactoring 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 refactoring.

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

[0010] S4. Construct a predictive model for the energy consumption of Android applications before and after code refactoring;

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

[0012] Furthermore, in step S1, for the application Appk The process of generating a test case set associated with a method includes the following steps:

[0013] S101. Obtain the application name ApkName based on the input application source code address ApkNamePath;

[0014] S102. Obtain the corresponding test case set ListCasePc on the PC based on the application name ApkName;

[0015] S103. Push the test case set ListCasePc to the mobile device;

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

[0017] S105, App k Install on your mobile device;

[0018] S106. Enable the Jacoco plugin device and start code instrumentation;

[0019] S107, Launch the application App k Then execute the test cases; after the test cases have finished executing, 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 Jacobo coverage report in the ListReport report list, obtain the list of methods associated with each test case, thereby obtaining the test case set associated with the method and outputting it.

[0022] Further, in step S2, based on the list of methods affected by code refactoring, test cases associated with the methods affected by the refactoring are selected from the generated test case set. This specifically includes the following steps:

[0023] S201. Locate the test case set associated with the method corresponding to the application based on the application name, and then execute step S202.

[0024] S202. Based on the input code, refactor the method list MethodUList. For each method in the method list MethodUList, execute step S203. After completion, execute step 204.

[0025] S203. Based on the method name MethodName, search the test case set associated with the method to see if the method exists. If it does, 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 and then select the test case corresponding to the method from the regenerated test case set associated with the method.

[0026] S204. Combine all the obtained test cases to form a test case set for evaluating the power consumption of the Android application before and after the reconstruction.

[0027] Furthermore, by synthesizing all the obtained test cases, the specific method is as follows: if there is an intersection between the test case sets corresponding to each method in the MethodUList list affected by the code refactoring, 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.

[0028] Furthermore, in step S3, for a benchmark application and its corresponding refactoring method, dynamic feature data of energy consumption behavior before and after application refactoring are extracted. Specifically, this includes: obtaining global system behavior information using the / proc / stat command; obtaining local information of the process using the / proc / pid / stat command; and obtaining system call information of the process using the strace -c -p pid command.

[0029] Further, in step S3, for the input benchmark application source code address set ApkNamePathList and the test case set CaseMethodlist associated with the methods, the energy consumption data before and after application refactoring is estimated, and the corresponding energy consumption dataset EnergyList is output. This specifically includes the following steps:

[0030] S301. Perform environmental initialization; perform measurement equipment initialization;

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

[0032] S303. Obtain a list of methods whose code has been modified after the refactoring operation by sampling code structure changes, i.e., the list of methods affected by code refactoring: MethodUList;

[0033] S304. Obtain the application name ApkName based on the application source code address ApkNamePath;

[0034] S305. Based on the application name ApkName and the list of methods affected by code refactoring MethodUList, obtain the test case set TestCaseList for evaluating the energy consumption of the Android application before and after refactoring.

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

[0036] S307. Perform environment initialization; install applications;

[0037] S308. After waiting for the set time, the measuring device will start measuring;

[0038] S309. Perform time synchronization;

[0039] S310, Execute the test case set corresponding to the application;

[0040] S311. After waiting for the set time, the measuring device stops measuring;

[0041] S312. Acquire and output measurement data;

[0042] S313. Uninstall the application and wait for the set time;

[0043] S314. Output EnergyList, which includes energy consumption data before and after the application reconstruction.

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

[0045] Furthermore, the prediction model is composed 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 as follows: first, samples are randomly drawn from the energy consumption dataset 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 average of the n prediction results is taken as the final prediction result and output.

[0046] Compared with existing technologies, the present invention has the following beneficial effects: The present invention provides an Android application energy consumption assessment method for code refactoring. This method proposes a test case generation and selection technique, which generates a test case set associated with the methods of the application, and selects test cases associated with the methods affected by the refactoring to form a test case set for evaluating the energy consumption of the Android application before and after the refactoring. This test case generation and selection technique can provide a test case set with the highest possible coverage and the fewest possible number of test cases, targeting local changes in code structure at the method level caused by refactoring. Based on the test case generation and selection technique, corresponding test case sets are generated for multiple given benchmark applications. Then, 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 is estimated, thereby generating an energy consumption dataset for code refactoring. On this basis, a predictive model for the energy consumption of the Android application before and after code refactoring is constructed to achieve a relatively accurate estimation of the energy consumption of the Android application before and after code refactoring. Attached Figure Description

[0047] Figure 1 This is a flowchart illustrating the method implementation of an embodiment of the present invention;

[0048] Figure 2 This is a flowchart illustrating the generation of test case sets associated with the method in this embodiment of the invention;

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

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

[0051] Figure 5 This is a flowchart of the test case selection process in an embodiment of the present invention;

[0052] Figure 6 This is a flowchart of dynamic feature extraction of Android application energy consumption behavior in an embodiment of the present invention;

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

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

[0055] Figure 9 This is a flowchart of energy consumption measurement in an embodiment of the present invention;

[0056] Figure 10 This is a flowchart of the energy consumption dataset generation for code refactoring in an embodiment of the present invention;

[0057] Figure 11This is a schematic diagram illustrating the implementation principle of the prediction model based on random forest in this embodiment of the invention. Detailed Implementation

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

[0059] It should be noted that the following detailed descriptions are exemplary and intended to provide further explanation of this application. Unless otherwise specified, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this application pertains.

[0060] It should be noted that the terminology used herein is for the purpose of describing particular embodiments only and is not intended to limit the exemplary embodiments according to this application. As used herein, the singular form is intended to include the plural form as well, unless the context clearly indicates otherwise. Furthermore, 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.

[0061] like Figure 1 As shown, this embodiment provides a method for evaluating the energy consumption of Android applications for code refactoring, including the following steps:

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

[0063] S2. Select test cases associated with the methods affected by the refactoring 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 refactoring.

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

[0065] S4. Construct a predictive model for the energy consumption of Android applications before and after code refactoring;

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

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

[0068] To build an efficient and accurate list of test cases associated with 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 simple operational logic, the required test case set can be generated directly using either random or manual test case generation methods. For apps with a large number of lines of code and more complex operational logic, a combination of random and manual test case generation methods can be used to generate the required test case set. The logic of combining random and manual test case generation is as follows: First, a test case generation framework for the app is built using random testing methods to generate a large number of test cases, also known as a test case set. Then, the Jacoco tool is used to check the code coverage obtained after the test case set has been executed. If the code coverage is low, for example, the method coverage is around 20%, then manual test case generation methods are used to compensate for the shortcomings of the random test case generation method.

[0069] Based on this, 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 were executed and which were not. If at least one command in a method is executed, the method is considered executed; otherwise, the method is not executed. This generates a method-associated test case set. The main purpose of generating method-associated test case sets is to allow for targeted selection of appropriate test cases for specific applications, facilitating energy consumption measurement of refactored methods later in this paper.

[0070] For Applications (Apps) k The test case set corresponding to the App is generated using a method-oriented, high-coverage Android application test case generation method. k The corresponding set of test cases associated with the method. Figure 2 This is a flowchart illustrating the generation of test case sets associated with the method. Table 1 shows the pseudocode for this algorithm. Figure 2 As shown in Table 1, the specific implementation steps of this method are as follows.

[0071] S101. Obtain the application name ApkName based on the input application source code address ApkNamePath.

[0072] S102. Retrieve the corresponding test case set ListCasePc on the PC based on the application name ApkName. This test case set ListCasePc is a pre-generated set generated manually, randomly, or through a combination of both methods.

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

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

[0075] S105, App k Install on your mobile device.

[0076] S106. Enable the Jacoco plugin device and start code instrumentation.

[0077] S107, Launch the application App k Then execute the test cases; after the test cases have finished executing, 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, crawl and collect the list of methods associated with each test case, thereby obtaining the test case set CaseMethodList associated with the method and outputting it.

[0080] Table 1 shows the algorithm flow for generating test case sets associated with the method.

[0081]

[0082] 1.1 Generate code coverage report

[0083] The most important task in generating a code coverage report is to automatically install and launch the App and the Jacoco plugin, and generate an intermediate file (coverage.gc) after the App finishes running, in order to generate the final code coverage report. Specifically, (1) Automated installation and launch of the App: In this embodiment, the gradle command in Android Studio / Idea is used to install the Apk to the mobile device by executing gradle installDebug or . / gradle installDebug, and the App is launched by the adb shellam start-n{package_name} / {activity_name} command; (2) Launching the Jacoco plugin and generating the coverage report: It should be noted here that in order to obtain the execution path of the application, it is necessary to instrument the application. As a Java language checking tool, Jacoco provides two instrumentation methods, namely On-The-Fly (online instrumentation) and Offline (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, bytecode instrumentation is required before testing, subsequently generating instrumented class files or JAR packages. Executing these instrumented files or packages generates corresponding coverage information and stores it in a file. Finally, this coverage information is processed uniformly to generate a detailed report. The command required for this process is `adb shell aminstrument"+package_name+" / "+package_name+".jacoco.JacocoInstrumentation"`.

[0084] 1.2 Parsing the report and the test case set associated with the output method

[0085] In this embodiment, the report parsing module mainly utilizes a web crawler mechanism to reduce manual workload, and its schematic diagram is shown below. Figure 4 As shown, a web crawler architecture mainly consists of the following parts: crawler initiator, URL management, webpage downloader, and webpage 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: Categorizes and manages URLs to be crawled and URLs that have already been crawled.

[0088] (3) Webpage downloader: Downloads the webpages corresponding to the already crawled URLs and provides them to the webpage parser.

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

[0090] Under the ordered invocation of the crawler, the three parts are executed in a loop, and finally the dataset that meets all the experimental requirements of this paper is extracted.

[0091] 2. Test Case Selection

[0092] Before selecting test cases, it's essential to explain why this is necessary. For an Android application, there are n test cases. If the method whose code has changed after refactoring is called `method1`, the modified code is localized. Running all test cases would execute too much irrelevant code—code whose structure hasn't changed—increasing evaluation time and energy consumption measurement noise. However, by strategically selecting test cases related to the refactored method, the number of test cases to be executed can be minimized, reducing evaluation time and energy consumption measurement noise. Therefore, before energy consumption measurement, a corresponding test case set must be selected for the app under test to best address the code changes caused by the code structure changes mentioned above.

[0093] Figure 5 This is a flowchart of the test case selection process. Table 2 shows the pseudocode for the algorithm. For example... 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. Find the test case set associated with the method corresponding to the application based on the application name ApkName, and then execute step S202.

[0095] S202. Based on the input code refactoring impact list MethodUList, for each method in the code refactoring impact list MethodUList, execute step S203; after completion, execute step 204.

[0096] S203. Based on the method name (MethodName), check if the method exists in the test case set associated with the method. If it does, 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 based on 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. Combine all the obtained test cases to form a test case set for evaluating the power consumption of the Android application before and after the reconstruction.

[0098] The method for synthesizing all obtained test cases is as follows: If there is an intersection between the test case sets corresponding to the methods in the MethodUList list affected by the code refactoring, 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. For example, suppose the list of methods affected by the refactoring instance is [A, B], which correspond to [[case1, case2, case3, case4], [case1, case2, case5, case6]]. Their intersection is taken as the test case set to be executed, i.e., [case1, case2]. Through this process, an appropriate test case set can be dynamically selected according to the specific situation of the application to ensure effective test coverage when methods change.

[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 refactoring method, dynamic feature data of energy consumption behavior before and after application refactoring are extracted. Specifically, this includes: using the / proc / stat command to obtain global system behavior information; using the / proc / pid / stat command to obtain local information of the process; and using the strace -c -p pid command to obtain system call information of the process.

[0103] like Figure 6 As shown, the specific process for dynamic feature extraction of energy consumption behavior in Android applications 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 get the process ID (pid) of the application.

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

[0106] Next, the computer sends the `kill pid` command to terminate the application. The computer saves the process's local information, and the application's system call information is saved in a specified folder on the phone. Finally, the system call information saved on the phone is copied to the specified folder on the computer, and the ` / proc / stat` command is used again to obtain the global system information after the application runs. Subtracting the initial global system information from the current information after running the test cases gives the global system resource information used by the application. At this point, all the dynamic characteristics of the application during runtime can be obtained.

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

[0108] To address the dual requirements of comprehensively covering code structure changes resulting from refactoring combined applications and achieving the most accurate energy consumption measurement, this method provides an Android application. k When executing test cases, what is the implementation process for energy consumption measurement, such as... Figure 7 As shown.

[0109] To evaluate the efficiency of code refactoring, the initial version of App (App) needs to be refactored. k0 The version without refactoring and the version after refactoring (App) k1 Therefore, when performing energy consumption measurements, it is necessary to compare and evaluate the energy consumption values ​​of the application before and after the reconstruction.

[0110] Before performing energy consumption estimation, time synchronization is required to lay a solid foundation for accurate energy consumption measurement. Finally, the app is synchronized using an energy consumption measurement tool such as Monsoon Power Monitor. k0 and App k1 The energy consumed during execution is measured. The pseudocode 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 corresponding energy consumption data before and after application refactoring, and output the corresponding energy consumption dataset EnergyList. The specific steps include:

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

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

[0114] S303. Obtain a list of methods whose code has been modified after the refactoring operation by sampling code structure changes, i.e., the list of methods affected by code refactoring, MethodUList.

[0115] S304. Obtain the application name ApkName based on the application source code address ApkNamePath.

[0116] S305. Based on the application name ApkName and the list of methods affected by code refactoring MethodUList, obtain the test case set TestCaseList for evaluating the energy consumption of the Android application before and after refactoring.

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

[0118] S307. Perform environment initialization; install applications.

[0119] S308. After waiting for the set time, the measuring device will start measuring.

[0120] S309. Perform time synchronization.

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

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

[0123] S312. Acquire and output measurement data.

[0124] S313. Uninstall the application and wait for the set time.

[0125] S314. Output EnergyList, which includes energy consumption data before and after the application reconstruction.

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

[0127]

[0128]

[0129] 4.1 Time Synchronization

[0130] Time synchronization is a crucial process for ensuring time consistency between different devices or systems. In the experimental setup of this embodiment, the Monsoon device uses time based on the PC's time, while the mobile device relies on its local time. There may be inconsistencies between these two times, and this inconsistency is a significant problem for experiments that rely on time for data measurement and processing.

[0131] Specifically, time inconsistencies can lead to biased experimental results. In the energy consumption measurement of this embodiment, different measurement intervals are divided by time, and the energy consumption data within these intervals are accumulated. If the time on the PC and mobile devices are not synchronized, the divided measurement intervals may contain errors, resulting in inaccurate calculations of energy consumption data. This error can have a significant impact on the experimental results, making it impossible to draw correct conclusions.

[0132] Furthermore, time synchronization is also a crucial means of ensuring the repeatability and consistency of experiments. If the time on the PC and mobile devices is inconsistent during each experiment, the results may differ, making accurate comparison and analysis impossible. Time synchronization ensures that the time across devices remains consistent throughout each experiment, resulting in more reliable and accurate results.

[0133] Therefore, time synchronization is crucial in the experimental setup of this embodiment. By synchronizing time, the time inconsistency between the PC and the mobile device can be eliminated, ensuring the accuracy and reliability of energy consumption measurements, thereby providing strong data support for the experiments of this method.

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

[0135] The principle of time synchronization 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 of the client sending the NTP request; T2 is the timestamp of the server receiving the NTP request; T3 is the timestamp of the server replying to the NTP request; T4 is the timestamp of the client receiving the NTP reply packet; d1 is the NTP request packet transmission delay, d2 is the NTP reply packet transmission delay; t is the time deviation between the server and the client, and d is the round-trip time of the NTP packet. Given T1, T2, T3, and T4, we want to find t to adjust the client's clock, which can be expressed by equation (4-1).

[0137]

[0138] Assuming that the NPT request and response packet transmission delays are equal, i.e., d1 = d2, then we can obtain equation (4-2).

[0139]

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

[0141]

[0142] It can be seen that t and d are only related to the differences between T2 and T1 and the differences between T3 and T4, but not to the difference between T2 and T3. In other words, the final result is independent of the time required for the server to process the request. Therefore, the client can calculate the time offset from the server using T1, T2, T3, and T4: offset = ((T2-T1) + (T3-T4)). This calculation yields the time deviation (t) between the server and the client. 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 scenario, synchronization is achieved simply by synchronizing the time on both the PC and mobile devices with the NTP server. Specifically, on the PC, a time synchronization tool is developed to calculate the time difference between the PC and the NTP server, denoted as PcOffset. On the mobile device, a time synchronization app is developed, installed, and run. The time difference between the app and the NTP server is then calculated and denoted as AndroidOffset. In energy consumption calculations, the corresponding time difference is added to both the time recorded on the PC and the time recorded on the mobile device to achieve time synchronization.

[0144] As mentioned above, a program is written on the PC to calculate PcOffset, and a synchronization app is written on the Android platform to obtain AndroidOffset. Then, PcTime (the local time on the PC) is added to PcOffset (the PC's offset relative to Ntp) to obtain NtpTime. Time synchronization on the Android device is achieved by adding AndroidTime (the Android's local time) to AndroidOffset (the offset relative to Ntp) to obtain NtpTime. This completes the synchronization between the Android device and the PC. 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 ease of explanation, we will use an initial version of an application, App, as an example. k0 Let's take an example to explain, using eng(0,j,k) to represent the training application App respectively. k (1≤k≤p) The energy consumption value is collected in version 0 under the j-th test case set. Figure 9 The App is shown k The process of obtaining the energy consumption value eng(0,j,k) of version 0 under the j-th test case mainly includes six steps: First, the desktop computer sends a start measurement command to the power measurement device; then, it sends a command to the test mobile phone to execute the j-th test case tcj; subsequently, the mobile phone executes the test case tcj and drives the i-th version of the App. k Run. After test case tcj finishes execution, the collected feature information is automatically sent to a designated folder on the desktop using commands from the Android debug bridge. Then, the Monkey framework module deployed on the mobile device notifies the Monkey framework module deployed on the desktop of the message indicating the completion of test case tcj execution. Simultaneously, the desktop sends a measurement end command to the measurement device and collects the power data from the measurement device between the start and end commands. Finally, the desktop computes and trains the application App. k The energy consumption value eng(0,j,k) for version 0 under the j-th test case.

[0149] To accurately calculate App k Version 0 in the j-th test case tc j The energy consumption value eng(0,j,k) is given, and the sampling frequency of the Monsoon measuring device is set to 5000Hz and tc jThe start and end timestamps of the actual execution are used as the start 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 datasets for code refactoring

[0151] The generation of energy consumption datasets for code refactoring primarily relies on the work already done, namely, test case technology for evaluating the energy efficiency 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 for generating energy consumption datasets for code refactoring is as follows: Figure 10 As shown, firstly, for a given benchmark case, a benchmark application App can be generated by using Android application code refactoring technology for energy efficiency assessment test cases and preprocessing methods. k The corresponding test case set is then fed into the dynamic feature extraction module for Android application energy consumption behavior and the Android application energy consumption estimation module before and after reconstruction based on the test case set, which can respectively obtain the App's energy consumption data. k Before the refactoring, the app k0 App k Reconstructed App k1 The dynamic characteristics and energy consumption values ​​of the corresponding energy consumption behavior are analyzed. By repeating the above work multiple times, this paper finally generates an energy consumption dataset of 998 records. The following sections will elaborate on the two key steps: preprocessing and dataset generation.

[0152] 5.1 Preprocessing

[0153] During the preprocessing process, for the known benchmark case App k By using a refactoring tool to obtain Android-specific refactoring types, a refactoring set can be obtained. Assuming its length is n, a random sampling method is then applied to the set to generate a 0 / 1 vector r of length n. This process is repeated to obtain a sequence, which includes many sequences. For each sequence, it is applied to the source code, deleting instances where the refactoring position is 0, and retaining instances where the position is 1. The final output is the APK file corresponding to a given combination of refactoring sequences. During this process, the tool can be used to obtain a list of methods affected by the refactoring. Then, using Section 3 of Chapter 3, a benchmark case app can be obtained. k The corresponding test case set. Finally, through the first and second sections of this chapter, we can obtain the feature values ​​and energy consumption values. Then, by aggregating the obtained feature data and energy consumption values, we can complete the dataset generation.

[0154] 5.2 Dataset Generation

[0155] The dataset generation process mainly includes two important modules: dataset collection and dataset processing. These two modules will be described in detail below.

[0156] (1) Data collection

[0157] Data collection requires gathering two aspects: dynamic characteristics and energy consumption data. Dynamic characteristics are primarily collected using the `strace` command, a Linux-based utility for Android, which tracks system calls and processor process state changes. Its `-c` command provides statistics on different system calls activated by the Android application. Simultaneously, the Linux ` / proc` pseudo-filesystem can be used to capture CPU tick counts and dynamic process information. (Training application App) k Local process information can be collected via ` / proc / pid / stat`, while some system-wide behavior information can be captured using ` / proc / stat`. Energy consumption collection primarily utilizes the energy measurement techniques mentioned above. This involves using the Monkey tool to drive the execution of test cases and employing the Monsoon Power Monitor to collect energy data. The energy consumed by the Android phone during execution is then calculated and incorporated into dynamic feature values, thus completing the dataset collection. Based on the above, the dataset constructed in this embodiment contains 998 records.

[0158] (2) Dataset processing

[0159] We observed that system call information within these dynamic features, despite their very similar characteristics, has different names. For example, `lseek` and `llseek` are two system calls with the same purpose. When one application calls `lseek` while another calls `llseek`, this poses a problem for building an energy consumption model. It is difficult to build a generalized energy consumption model when training data is inconsistent. For instance, if `llseek` was never encountered during model training, its impact on building the energy consumption model is unknown, even though the model knows that `llseek` and `lseek` can have the same effect. This embodiment addresses this problem by grouping similar system calls according to the semantics described in the Linux man pages. Functionally unique system calls are not grouped with other system calls.

[0160] Machine learning algorithms are often affected when the value ranges of different features vary greatly. Because such large differences are observed between features, the data is normalized to a range of 0 to 1. This normalization not only speeds up the learning process but also improves the model's accuracy. The normalization formula is shown below, where x represents the feature vector.

[0161]

[0162] Building upon previous work, we researched and constructed a training dataset that reflects the relationship between dynamic changes in code characteristics and energy consumption. This dataset comprehensively captures the impact of common dynamic feature changes in Android application code after refactoring on energy consumption. Furthermore, we designed a training algorithm to construct a predictive model that can accurately assess the energy consumption of Android application code after code changes without using external measurement devices. This model, which uses dynamic features as the X variable and energy consumption as the Y variable, and establishes an energy consumption prediction model through machine learning, can effectively ensure the validity of the assessment.

[0163] 6. Building a predictive 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 exhibits good predictive performance. Therefore, in this embodiment, based on the generated energy consumption dataset for code refactoring, a predictive model for Android application energy consumption before and after code refactoring is constructed using the random forest algorithm to ensure high prediction accuracy. The implementation principle of the random forest-based prediction model is as follows: Figure 11 As shown, the prediction model is composed of multiple decision tree regression models, and the final prediction result is obtained by averaging the prediction results of the multiple decision tree regression models. The prediction model works as follows: first, n training sample sets are randomly selected from the energy consumption dataset; 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 average of the n prediction results is taken as the final prediction result and output.

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

[0166] This application is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this application. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart... Figure 1One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0167] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0168] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0169] The above description is merely a preferred embodiment of the present invention and is not intended to limit the invention in any other way. Any person skilled in the art may make changes or modifications to the above-disclosed technical content to create equivalent embodiments. 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 scope of the present invention shall still fall within the protection scope of the present invention.

Claims

1. A method for evaluating the energy consumption of Android applications oriented towards code refactoring, characterized in that, Includes the following steps: S1. For the application, generate a test case set associated with the method; S2. Select test cases associated with the methods affected by the refactoring 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 refactoring. S3. For a given set of multiple benchmark applications, refactor them using a refactoring tool to obtain each benchmark application and its corresponding refactoring method. For each benchmark application and its corresponding refactoring method, obtain the corresponding test case set using the methods in steps S1-S2. For each benchmark application and its corresponding refactoring method, extract the dynamic feature data of the energy consumption behavior before and after the application refactoring, and estimate the energy consumption data before and after the application refactoring, thereby generating an energy consumption dataset for code refactoring. S4. Construct a predictive model for the energy consumption of Android applications before and after code refactoring; S5. Use the constructed prediction model to assess the energy consumption of Android applications. In step S1, for the application App k The process of generating a test case set associated with a method includes the following steps: S101. Obtain the application name ApkName based on the input application source code address ApkNamePath; S102. Obtain the corresponding test case set ListCasePc on the PC based on the application name ApkName; S103. Push the test case set ListCasePc to the mobile device; S104. For each test case in the test case set ListCasePc, execute steps S105-S108; after completion, execute step S109. S105, App k Install on your mobile device; S106. Enable the Jacoco plugin device and start code instrumentation; S107, Launch the application App k Then execute the test cases; after the test cases have finished executing, exit the application App. k ; S108. Obtain the Jacoco coverage report and add it to the report list ListReport; S109. By analyzing each Jacobo coverage report in the report list ListReport, obtain the list of methods associated with each test case, thereby obtaining the test case set associated with the method and outputting it. In step S2, based on the list of methods affected by code refactoring, test cases associated with the methods affected by the refactoring are selected from the generated test case set. This specifically includes the following steps: S201. Locate the test case set associated with the method corresponding to the application based on the application name, and then execute step S202. S202. Based on the input code, refactor the method list MethodUList. For each method in the method list MethodUList, execute step S203. After completion, execute step 204. S203. Based on the method name MethodName, search the test case set associated with the method to see if the method exists. If it does, 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 and then select the test case corresponding to the method from the regenerated test case set associated with the method. S204. Combine all the obtained test cases to form a test case set for evaluating the power consumption of the Android application before and after the reconstruction; In step S3, for the input benchmark application source code address set ApkNamePathList and the test case set CaseMethodlist associated with the methods, the energy consumption data before and after application refactoring is estimated, and the corresponding energy consumption dataset EnergyList is output. This specifically includes the following steps: S301. Perform environmental initialization; perform measurement equipment initialization; S302. For each application source code address ApkNamePath in the benchmark application source code address set ApkNamePathList, execute steps S303-S313; after completion, execute step S314. S303. Obtain a list of methods whose code has been modified after the refactoring operation by sampling code structure changes, i.e., the list of methods affected by code refactoring: MethodUList; S304. Obtain the application name ApkName based on the application source code address ApkNamePath; S305. Based on the application name ApkName and the list of methods affected by code refactoring MethodUList, obtain the test case set TestCaseList for evaluating the energy consumption of the Android application before and after refactoring. S306. For the application before and after reconstruction, execute steps S306-313 respectively; S307. Perform environment initialization; install applications; S308. After waiting for the set time, the measuring device will start measuring; S309. Perform time synchronization; S310, Execute the test case set corresponding to the application; S311. After waiting for the set time, the measuring device stops measuring; S312. Acquire and output measurement data; S313. Uninstall the application and wait for the set time; S314. Output EnergyList, which includes energy consumption data before and after the application reconstruction.

2. The Android application energy consumption assessment method for code refactoring according to claim 1, characterized in that, The specific method for synthesizing all the test cases is as follows: if there is an intersection between the test case sets corresponding to each method in the MethodUList list affected by the code refactoring, 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.

3. The Android application energy consumption assessment method for code refactoring according to claim 1, characterized in that, In step S3, for a benchmark application and its corresponding refactoring method, dynamic feature data of energy consumption behavior before and after application refactoring are extracted. Specifically, this includes: using the / proc / stat command to obtain global system behavior information; using the / proc / pid / stat command to obtain local information of the process; and using the strace -c -p pid command to obtain system call information of the process.

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

5. The Android application energy consumption assessment method for code refactoring according to claim 4, characterized in that, The prediction model is composed 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 as follows: first, samples are randomly drawn from the energy consumption dataset 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 average of the n prediction results is taken as the final prediction result and output.

Images