基于物联网技术的家用电力管理系统——移动客户端设计与开发外文翻译资料

Optimizing Energy of HTTP Requests

in Android Applications

Ding Li and William G. J. Halfond

University of Southern California

Los Angeles, California, USA

{dingli,halfond}@usc.edu

ABSTRACT

Energy is important for mobile apps. Among all operations of mobile apps, making HTTP requests is one of the most energy consuming. However, there is not su cient work in optimizing the energy consumption of HTTP requests in mobile apps. In our previous study, we found that making small HTTP requests was not energy e cient. Yet, we did not study how to optimize the energy of HTTP requests. In this paper, we make a preliminary study to bundle sequential HTTP requests with a proxy server. With our technique, we had a 50% energy saving for HTTP requests in two market Android apps. This result indicates that our technique is promising and we will build on the result in our future work.

Categories and Subject Descriptors

D.2.5 [Testing and Debugging]: Diagnostics

General Terms

Performance

Keywords

Energy optimization, HTTP requests, Mobile systems

more than 32% of the total non-idle state energy of an app. Thus, researchers and developers can miss a signi cant area to optimize energy if they omit HTTP requests.

To study energy consumption of HTTP requests, we per-formed a preliminary study [7] and found that making small HTTP requests is not energy e cient. However, in that preliminary study, we did not propose a method to optimize HTTP energy.

In this paper, we introduce a preliminary study on how to optimize the energy consumption of HTTP requests in mobile apps. Our approach is to combine multiple HTTP requests that will de nitely be made together. By doing this, our approach could reduce the number of HTTP re-quests and reduce the overhead of initiating and sending each individual HTTP request. In our evaluation, we found that there was an up to 50% reduction in the HTTP energy consumption in two market Android apps when using our approach.

The structure of this paper is as follows. In Section 2, we introduce some background information about making HTTP requests and our previous results. In Section 3, we introduce our ideas of how to optimize the HTTP request energy. In Section 4, we report the results of our evaluation. Finally, in Section 5, we discuss related work and conclude in Section 6.

1. INTRODUCTION

Energy is a critical resource for battery supported devices, such as smartphones and tablets. Improving the energy ef-ciency of mobile apps could improve the user satisfaction of the apps and potentially improve the revenue of develop-ers. Recently, researchers have proposed many techniques to save energy for mobile apps. However, none of these ap-proaches focus on the optimization of HTTP request energy consumption.

Unfortunately, overlooking HTTP requests is problematic. According to our previous study [8], making HTTP requests is the most expensive type of API call in mobile applica-tions. On average, making HTTP requests can consume

2. BACKGROUND AND MOTIVATION

In our previous empirical study [8], we found that making HTTP requests is one of the most energy consuming opera-tions in Android apps. In the empirical study, we measured the energy consumption of di erent packages of APIs in 405 Android market apps. We found that, on average, making HTTP requests could represent 32% of the total non-idle state energy consumption of mobile apps. For certain apps, this percentage could be even higher than 60%. Compared with other operations, making HTTP requests consumes sig-ni cantly more energy.

Another one of our previous studies [7] further showed that making small HTTP requests is not energy e cient. In that study, we found that downloading one byte of data consumed the same amount of energy as downloading 1,024 bytes of data through HTTP requests. Furthermore, we found that downloading 10,000 bytes of data only consumed twice the amount of energy as downloading 1,000 bytes of data. In this case, making small HTTP requests consumes more energy per each byte transmitted through the network.

This ine ciency is due to the protocol of sending HTTP requests. Making an HTTP request needs three steps: es-

tablishing the connection, transmitting data, and closing the connection. In the steps of establishing the connection and closing the connection, the client side needs to have a 3-way or 4-way handshake protocol, which spend energy in trans-mitting practically empty packets. In the step of transmit-ting data, energy overhead will be introduced by the headers of the HTTP request and its lower-level network protocols, such as TCP and IP. Thus, most energy of a small HTTP request will be consumed by the handshake-protocol and headers.

1. APPROACH

Our approach focuses on optimizing the HTTP energy consumption of mobile apps with sequential HTTP requests. By sequential HTTP requests, we mean the HTTP requests that are always made together, in sequence, despite the user input or execution condition of the program. One example of sequential HTTP requests is in Program 1, where the HTTP requests at line 6, line 10, and line 14 are sequential HTTP requests. Since these HTTP requests will always be sent in sequence, their tasks can be accomplished in one HTTP request.

• public InputStream agent(URLConnection conn)

2 f

3 if(InCache(conn))

4 f

5return GetCache(conn);

6 g

7 String oldurl=conn.getURL();

8 setURL(conn, Proxy url);

9 addHeader('old_URL',oldurl);

1. InputStream bundled=conn.getInputStream();
2. InputStream[] allResponses=GetEachResponse(bundled);
3. addToCache(allResponses);
4. return allResponses[0];
5. g
6. public void print html()
7. f
<l

剩余内容已隐藏，支付完成后下载完整资料

---

在Android应用程序中

优化HTTP请求的能耗

Ding Li and William G. J. Halfond

University of Southern California

Los Angeles, California, USA

{dingli,halfond}@usc.edu

摘要

能源对于移动应用程序很重要。在移动应用程序的所有操作中，HTTP请求是最耗能量的操作之一。然而，在优化移动应用程序中HTTP请求的能耗方面还没有足够的工作。在我们之前的研究中，我们发现小的HTTP请求并不是能量消耗。然而，我们没有研究如何优化HTTP请求的能量。本文对顺序HTTP请求与代理服务器捆绑进行了初步研究。使用我们的技术，我们在两个市场的Android应用程序中为HTTP请求节省了50%的能源。这一结果表明，我们的技术是有前途的，我们将在今后的工作成果的基础上。

类别和主题描述符

D.2.5【测试和调试】：诊断

一般条款

性能

关键词

能源优化、HTTP请求、移动系统

超过应用程序总非空闲状态能量的32%。因此，如果忽略HTTP请求，研究人员和开发人员可能会错过优化能源的重要领域。

为了研究HTTP请求的能量消耗，我们进行了初步的研究[7]，发现生成小的HTTP请求并不节能。然而，在那个初步研究中，我们没有提出优化HTTP能量的方法。

本文对移动应用中如何优化HTTP请求的能耗进行了初步研究。我们的方法是组合多个HTTP请求，这些请求将最终一起发出。通过这样做，我们的方法可以减少HTTP请求的数量，并减少启动和发送每个单独的HTTP请求的开销。在我们的评估中，我们发现使用我们的方法时，两个市场Android应用程序的HTTP能耗降低了50%。

本文的结构如下。在第2节中，我们介绍了一些关于发出HTTP请求的背景信息和以前的结果。在第3节中，我们介绍了如何优化HTTP请求能量的思想。在第4节中，我们报告了我们的评估结果。最后，在第5节中，我们讨论了相关工作，并在第6节中结束。

1. 引言

能源是支持电池的设备（如智能手机和平板电脑）的关键资源。提高移动应用的能源效率可以提高应用的用户满意度，并有可能提高开发人员的收入。最近，研究人员提出了许多移动应用节能技术。然而，这些AP都没有主动关注HTTP请求能耗的优化。

不幸的是，忽略HTTP请求是有问题的。根据我们之前的研究[8]，在移动应用程序中，HTTP请求是最昂贵的API调用类型。平均而言，发出HTTP请求会消耗

2. 背景和动机

在我们之前的实证研究[8]中，我们发现，在Android应用程序中，发出HTTP请求是最耗能量的操作之一。在实证研究中，我们测量了405个Android市场应用程序中不同应用程序包的能耗。我们发现，平均而言，发送HTTP请求可以占移动应用程序非空闲状态总能耗的32%。对于某些应用程序，这个百分比甚至可能高于60%。与其他操作相比，使得HTTP请求消耗的SIGNI能量大大增加。

我们先前的另一项研究[7]进一步表明，发出小的HTTP请求是不节能的。在那项研究中，我们发现下载一个字节的数据与通过HTTP请求下载1024个字节的数据消耗相同的能量。此外，我们发现下载10000字节的数据所消耗的能量是下载1000字节数据的两倍。在这种情况下，使较小的HTTP请求在通过网络传输的每个字节上消耗更多的能量。

这种效率是由于发送HTTP请求的协议。提出一个HTTP请求需要三个步骤：es-

建立连接、传输数据和关闭连接。在建立连接和关闭连接的步骤中，客户端需要有一个3路或4路握手协议，该协议在传输几乎为空的数据包时花费了大量精力。在传输数据的步骤中，HTTP请求的报头及其较低级别的网络协议（如TCP和IP）将引入能量开销。因此，一个小的HTTP请求的大部分能量将被握手协议和头消耗。

1. 方法

我们的方法侧重于通过连续的HTTP请求优化移动应用程序的HTTP能耗。通过连续的HTTP请求，我们指的是尽管用户输入或程序执行条件不同，但始终按顺序一起发出的HTTP请求。顺序HTTP请求的一个例子是在程序1中，第6行、第10行和第14行的HTTP请求是顺序HTTP请求。由于这些HTTP请求总是按顺序发送，因此它们的任务可以在一个HTTP请求中完成。

• public InputStream agent(URLConnection conn)

2 f

3 if(InCache(conn))

4 f

5return GetCache(conn);

6 g

7 String oldurl=conn.getURL();

8 setURL(conn, Proxy url);

9 addHeader('old_URL',oldurl);

1. InputStream bundled=conn.getInputStream();
2. InputStream[] allResponses=GetEachResponse(bundled);
3. addToCache(allResponses);
4. return allResponses[0];
5. g
6. public void print html()
7. f
8. URL url1, url2, url3;
9. URLConnection urlConnection1,urlConnection2, urlConnection3;
10. //query current weather
11. url1 = new URL('http://weather');
12. urlConnection1 = url1.openConnection();
13. ParseStream(agent(urlConnection1));
14. //query weather forcast
15. url2 = new URL('http://daily');
16. urlConnection2 = url2.openConnection();
17. ParseStream(urlConnection2.getInputStream());
18. //query location info
19. url3 = new URL('http://location');
20. urlConnection3 = url3.openConnection();
21. ParseStream(urlConnection3.getInputStream());
22. g

程序1：顺序HTTP请求示例

为了优化连续HTTP请求的能耗，我们提出了一种将连续HTTP请求组合成较大HTTP请求的方法。这种方法可以减少HTTP请求的数量，并增加单个HTTP请求传输的数据的大小。我们的基本思想是将原始HTTP请求重定向到代理服务器，该代理服务器将连续的HTTP请求组合为单个请求。我们方法的工作流程如图1所示，其中虚线框表示原始应用程序的代码，实线框表示在我们方法中开发的组件。在我们的工作中，我们首先使用代码重写技术来替换

Android HTTP API和Android应用程序中的代理HTTP API。然后，代理HTTP API将把HTTP请求重定向到代理，这是一个从客户机截取HTTP请求到服务器的过程。它包含两个组件，捆绑计算器和重定向器。

当客户端开始发送HTTP请求时，它通过代理HTTP API发送请求。然后，代理HTTP API将请求重定向到代理。当代理收到HTTP请求时，它将请求传递给绑定计算器，该计算器计算是否有任何其他HTTP请求应该绑定。它的决策基于应用程序开发人员提供的规则。之后，绑定计算器使用重定向器查询需要从服务器绑定的所有HTTP请求的数据。当检索到响应时，绑定计算器将所有HTTP请求的响应捆绑在一个包中，并将其回复到代理HTTP API。然后，当绑定响应返回时，代理HTTP API将解包绑定响应并恢复每个请求的响应。然后，这些响应存储在本地缓存中或为当前HTTP请求返回。最后，当调用同一组序列HTTP请求中的其他HTTP请求时，响应将直接从本地存储返回。

3.1 例子

我们使用程序1中的示例来解释我们的方法。在程序1中，我们首先用代理HTTP API替换第8行、第12行和第16行的HTTP API。当在第8行发出HTTP请求时，它被发送到代理服务器。然后，代理nds传入请求是一组连续HTTP请求中的第一个请求，其中包含第6行链路天气、第10行预测和第14行位置的三个HTTP请求。这样的决策是基于开发人员手动提供的规则及其领域特定知识。然后，代理从服务器查询对天气、预报和位置的响应，并将它们全部返回到客户机的单个数据包中。

当代理发送回打包的响应时，我们的代理HTTP API将在程序1的第8行捕获该响应。代理HTTP API RST从代理中解包响应，从打包的响应中检索预测和位置的响应，并将它们存储在本地缓存中。然后它检索weather的响应，weather是第8行HTTP请求的目标URL，并将响应作为inputstream返回，该inputstream与原始的android HTTP请求具有相同的数据结构。

在第8行的代理HTTP API返回后，代码使用代理HTTP API在第12行发出预测HTTP请求。在第12行，代理HTTP API检查本地缓存和NDS是否已存储响应，因此它直接返回forecast的响应。位置的情况也是如此。

在这种情况下，程序1只向第8行的代理发出一个HTTP请求，它一起检索天气、预报和位置的响应。与程序1的原始版本相比，该版本中有三个HTTP请求用于检索天气、预报和位置的响应。

3.2 代码重写

我们的方法RST需要取代原来的Android

图1：我们方法的工作流程

带有代理HTTP API的HTTP API。在此过程中，我们的方法解析原始应用程序中每个方法的字节码，并检测每个调用指令的签名。如果有调用指令调用Android HTTP API，我们的方法会将调用指令重定向到相应的代理Android API。

3.3 代理HTTP API

代理HTTP API是替换Android SDK中原始HTTP API的静态方法，例如url-connection.getinputstream。代理HTTP API的参数是目标对象和原始HTTP API的参数。代理HTTP API的返回值与原始API相同。

代理API有三个主要功能。首先，检查当前HTTP请求的响应是否存储在本地缓存中，如果是，则直接返回。其次，如果当前HTTP请求未存储在本地缓存中，则将HTTP请求重定向到代理而不是服务器。第三，解包一组连续HTTP请求的捆绑响应，将它们的响应存储在本地缓存中，并返回当前HTTP请求的响应。

3.4 代理

代理是服务器端的进程，它拦截客户端和服务器之间传入的HTTP请求。代理的第一个职责是检查传入的HTTP请求是否是HTTP请求序列中的第一个请求，第二个职责是捆绑连续的HTTP请求。代理接受来自客户端的HTTP请求，并返回这些请求的捆绑响应。代理通常部署在同一台计算机上或服务器的同一个网络域中。因此，它可以与服务器建立非常高速的连接，不会显著增加服务器和客户机之间的延迟。我们认为这一要求是现实的，因为我们的方法的用户，即被优化的应用程序的所有者或开发人员，通常控制应用程序的服务器。

第一个任务是由重定向器完成的，重定向器接受传入的HTTP请求，检索相应的顺序请求的URL，并将这些请求发送到服务器以获取响应。

第二个任务是由绑定计算器完成的，它接受一个传入HTTP请求的URL和参数，并确定应该绑定哪些请求。这个决定是根据应用程序开发人员提供的规则以及他们对应用程序的领域特定知识做出的。例如，在程序1中，开发人员可以向捆绑计算器提供规则将对天气、预报和位置的请求捆绑在一起。然后，当天气请求到来时，捆绑计算器将查询此规则，然后将天气、预报和位置的响应捆绑在一个包中。

3.5 通信协议

代理HTTP API和代理使用特定的协议

去实现通信。在这个协议中，可以以JSON格式的单个包返回对一些HTTP请求的响应。当代理向代理HTTP API返回数据时，它包含三种类型的信息：第一种是响应数；第二种是当前请求及其响应；第三种是所有绑定的请求及其响应。

当代理HTTP API得到响应时，它们将通过以下步骤处理数据。首先，它们检索当前请求的响应，此响应将用作返回值。其次，它们迭代所有捆绑请求，并检索它们的响应。第三，它们将所有捆绑请求的响应缓存在本地缓存中。

4. 评价

在我们的评估中，我们回答了一个研究问题：将后续的HTTP请求捆绑为一个HTTP请求可以节省多少HTTP能耗？

4.1 测试应用程序

为了回答我们的研究问题，我们发现了2个Market，一个来自Google Play市场

剩余内容已隐藏，支付完成后下载完整资料

---

资料编号：[20250]，资料为PDF文档或Word文档，PDF文档可免费转换为Word

</l

您可能感兴趣的文章

• 使用金属伪影减少算法从 CT 数据生成的数字模型的准确性外文翻译资料
• 彩色光流外文翻译资料
• 云环境下基于虚拟机配置文件针对DDOS攻击的最优网络攻击探测方法外文翻译资料
• 监控大视频数据分析中的模糊逻辑: 综述、挑战和研究方向外文翻译资料
• PeopleSoft人力资源管理系统实施外文翻译资料
• 图像绗缝的纹理合成与转移外文翻译资料
• 管理云中的资源:Chrome扩展到OpenStack外文翻译资料
• 一种基于凸显区域检测和SPBVM的美学QR码新算法外文翻译资料
• 微信小程序-所有你需要知道外文翻译资料
• Java核心技术卷II高级特性外文翻译资料