一个能源效率研究Android手机的网络通信

文摘

目前,移动设备是最受欢迎的普适计算设备,他们成为访问互联网的主要方式。电池是一个关键的资源在这种个人计算设备,网络通信的主要能源消费活动在任何移动应用。的确,网络通信是最显式或隐式地使用移动设备,基于http的交通是最有权力的要求。所以,移动web开发人员应该意识到能源需求多少不同的基于网络的通信方式。本文的目标是衡量和比较三种异步基于http方法的能耗移动设备在不同的浏览器。我们的实验集中于三种基于HTTP的异步通信模型,允许web服务器将数据推送到客户端浏览器通过一个HTTP / 1.1互动:轮询,长轮询,尚。然后分析了测量得到更准确的理解所选方法的影响,和移动浏览器,能源消耗的异步基于http的通信。这些实验是指开发者的效用是什么主要影响能源消耗的因素和设置使用不同的基于网络的异步通信方法时,帮助他们选择最有利的解决方案。根据这些信息,移动web开发人员应该能够降低功耗的前端web应用程序在移动设备上,就选择和配置最好的异步方法或移动浏览器,提高性能的基于http的通信方面的能源需求。

1。介绍

世界上手机用户的数量到2019年预计将突破五十亿。在2016年,估计有62.9%的人口在世界范围内已经拥有手机。移动电话普及率预计将继续增长,围捕到2019年的67% (1]。每天使用手机不同,智能手机使用被绝大多数流行的一些活动,比如社会媒体,通讯,和浏览互联网赶上新闻和更新信息。而且,正是频繁上网消耗电池。Android应对大多数的智能手机用户(在2018年,超过75%的市场份额)发现他们的Android电池定期清空。虽然可以挤出更多生命的电池通过优化一些手机设置,一些电池消耗可能是由于严重设计应用程序不断接收通知和更新的内容无需用户干预。这些隐藏通信通常是电池耗尽的罪魁祸首:应用程序经常上网在后台的更新和通知。另一个问题是,尽管其他手机屏幕和主板等硬件不断改进的更好和更强大的,电池技术还没有看到类似的进步。所以,大的甚至是全新的手机充电能力比他们的前辈们可能不会持续下去。虽然它总是推荐下载软件更新,旧手机已经升级到最新的操作系统(OS)版本也可能经历剧烈的电池消耗。用户可以找到一些技巧,这些技巧可以提高Android手机电池寿命取决于Android版本。 From the system perspective, network communication (WiFi, 3G, 4G, more recently 5G, or Bluetooth) is one of the primary energy consuming operations in mobile devices. On average, network communications can consume over 40% or more of the total non-idle state energy of an app or a mobile device [2- - - - - -4]。所以,最受欢迎的秘诀之一是关闭通知。然而,这个选项不是非常有用的应用程序想要得到实时更新电子邮件或社交网络。

考虑到智能手机现在成为最受欢迎的方式浏览互联网,移动浏览器可以被认为是一个最重的下水道的电池。移动网络使用最近首次超过桌面互联网接入(5]。即使用户不积极使用浏览器,它在后台继续消费。在各种各样的网络活动中,相关的超文本传输协议(HTTP、定义在[6,7)是最耗费能源,代表近80%的所有网络相关能耗(2,8]。

不同的统计数据说明这意味着什么:2018年4月,移动设备不包括平板电脑占了全球51.2%的web页面浏览量。2021年,全球移动数据流量预计将达到每月49 eb的复合年增长率为47%。根据Statcounter,大多数移动设备的网络流量是基于http(数据排除了使用的应用程序,比如Facebook和WhatsApp,占很大比例的移动互联网的使用)。因此,减少浏览器由于数据传输能耗可以产生重大影响的整体能源消耗设备和提高整体用户体验增加底层设备的电池寿命。为了有助于提高电池寿命使用浏览器时,有必要确定哪些变量影响能源消耗的因素可以调整和配置浏览器和软件开发人员。除了数据大小,另一个必须考虑的问题是数据速率(即。,the speed at which data are updated or the number of times data is sent in a particular period). This factor depends on (i) the type of the data source, which determines when data are generated (e.g., bursty, interactive, real-timed, or at a fixed rate); and (ii) the mechanism or technology used to push the data.

起初,基于http交互发生在用户主动检索或更新web内容。每次用户点击一个链接,新内容检索和显示在浏览器中。现在,然而,大部分的网页内容自动检索无需用户干预(如即时通讯、网络邮件和实时内容)。这意味着每当新内容可用,服务器能够将这些信息发给浏览器,允许用户无意中保持及时更新网站。应用程序服务器推送技术可以解决的协议或由应用程序本身。识别服务器推送的必要性,HTTP / 2,于2017年被释放,支持服务器推送的规范。新版本之前,HTTP / 1。x是纯粹的同步请求/响应应用协议。所以,为了实现服务器将使用HTTP / 1。x,开发人员提倡使用解决方案在应用程序级别,如果他们想要一个异步交互。 However, HTTP/2 is used just by 32.9% of all the websites in 2019. So, the browser always has to initiate a request to get web content. Nowadays, Web developers can adopt different technologies to achieve server pushing in HTTP/1.x. Most of the web applications require the server to send data to the client asynchronously as the state of a dynamic system changes and without the need for the user to interact with the browser interface.

尽管HTTP是同步的,Web软件开发人员有不同的方法来实现异步交互。第一个解决方案被采纳,仍然广泛使用,包括在模拟异步通信使用连续轮询技术同步的通信通道。Web应用程序需要侦听服务器是数据可以使用连续client-originated轮询。流行的变体轮询长轮询,HTTP响应的延迟为一个特定的时间或者直到数据是可用的。最近,标记语言HTML介绍其最新版本5中,WebSocket协议(9)解决这些异步交互,也不支持HTTP / 1。WebSocket允许双向,全双工,持久的客户端和服务器之间的套接字连接。基于双向连接,服务器可以主动发送(即。推动)数据到浏览器。WebSocket连接建立在TCP和只有很小的开销相比HTTP [10]。一个更新的服务器推送解决方案在应用程序级别是W3C将API (11),它允许一个网页或应用程序发送通知在系统水平即使应用闲置或背景。所有这些解决方案的共同点,他们都使用依靠JavaScript api。

另一个独特的特性,可能会影响性能和能耗是浏览器选择显示的内容。尽管所有的浏览器提供相同的功能,在内部,他们可能不同的浏览器引擎,这是每一个主要的核心软件组件的web浏览器。因为网络平台是一个开放标准,有多个浏览器引擎实现,要有不同的性能和资源管理时呈现的内容。从移动设备访问网络时,尤为重要的是,要注意消费和使用移动浏览器的性能。所以,移动web开发人员也应该牢记有限的可用功率移动设备和设计相应的应用程序。在智能手机、电池供电能力不能跟上其他设备资源(例如,处理和内存),被认为是首先改善用户体验,尤其是针对使用移动浏览器来访问互联网的增长。电池电力不足和需要优化能源消耗为web提供动力软件开发人员使用节能技术为了管理功耗异步基于http的通信,这可能会有所不同从一个移动浏览器到另一个地方。

我们的目标是衡量和比较三种不同的使用web应用程序使用不同的异步基于http的通信技术(轮询、长轮询和WebSocket)和两种不同的移动浏览器有关能源消耗(Chrome和Firefox)的行为。我们的研究是在应用程序级别的范围和使用HTTP / 1. x。尽管HTTP / 2提高网站和web应用程序的性能,这个版本仍然是通过28.3%的网站使用,所以它的好处还不显著。此外,使用异步的解决方案在应用程序级别使用90%的网络发展,因为它们是众所周知的和广泛的解决方案。这项工作是我们正在进行的研究的一部分能源消耗的异步通信机制。这项工作扩展了我们的以前的贡献(12)和一套新的实验(即一种新的实验。,再交互实验)。此外,我们使web浏览器的一部分,我们的研究和分析是否有统计上的显著差异的能耗机制。

通过了解影响电池消费选择方法的异步通信,移动浏览器,和其他因素(推数据大小和数据推动利率),移动web开发人员可以减少功耗的前端web应用程序在移动设备上选择最合适的web浏览器和异步发送异步推数据的机制。尽管能源是智能手机的关键资源,开发人员缺乏定量和客观的信息应用程序对能源消费的行为。本文分析和比较了能源消耗的Android设备在使用三种典型异步基于http的通信技术:轮询,长轮询,尚;和两个Web浏览器:Chrome和Firefox, Android。进行的研究是根据goal-question-metrics方法与目标”分析异步Android基于http的通信,从web软件开发者的角度”和两个研究问题,旨在找出影响能源消耗的因素在不同的实验情况,如果发现有统计学意义的差异。对于开发人员来说,结果将显示如果值得学习如何使用一种技术或使用一个具体的机制而言,电池消耗。这种节能的主要受益者将是用户将受益的更新,而他们的电池不排除。

本文的组织结构如下:第二部分概述了HTTP协议和异步通信机制,第三部分介绍了能源配置文件工具在这项研究中,第四节解释这项研究的结果使用goal-question-metrics方法,第五部分说明了威胁的有效性提出了结果,第六节概述我们的研究工作,最后,第七部分总结了论文,并介绍了未来的工作。

2。摘要在HTTP协议

在本节中,我们描述了HTTP协议和机制或技术所使用的Web应用程序将数据在应用程序级别。我们特别注意的大小之间的关系数据和更新的速度,支持它们的JavaScript库,选择的原因。

超文本传输协议(6是一个请求/响应协议。客户端(即。,a browser) establishes TCP connections to a Web server with the purpose of sending HTTP requests. Each HTTP request only allows requesting a resource. Once a HTTP server accepts a request, it sends back the requested resource in the entity-body content of an HTTP response. HTTP communication takes place over TCP/IP connections. The number of TCP connections used depends on the HTTP version. The use of inline images and other associated data often require a client to make multiple requests of the same server in a short amount of time. In HTTP/1.0, most browser implementations use a different TCP connection for each HTTP request/response exchange, thus increasing the load on HTTP servers and causing congestion on the Internet. However, at the same time, it provides a lower load and rendering time since all the resources are downloaded almost simultaneously in connections that run in parallel. In the next version of this protocol, HTTP/1.1, the same persistent TCP connection may be used for one or more request/response exchanges, although connections may be closed for a variety of reasons. Persistent HTTP connections have several advantages [6),可以积极影响功耗,通过打开和关闭TCP连接较少,CPU时间和内存保存。相反,使用TCP持久连接可以影响head-of-line阻塞问题,这限制了性能和影响的终端用户体验。在移动设备,保持连接打开也有助于节约能源。似乎保持连接打开需要较少的能量比重建或打开一个新的连接13]。此外,在后续请求中延迟和功耗降低由于没有时间和精力花在TCP的连接打开握手和缓慢的开始。虽然TCP持久连接任何HTTP连接的默认行为,许多浏览器使用非持久的改进TCP连接的终端用户体验,尽管过载和所需的资源。

TCP连接的开放和控制,实例化并通过TCP套接字发送的HTTP请求,HTTP响应的接收和处理的责任是浏览器,所以选择一个浏览器或另一个可能影响电池消耗。发送和接收HTTP消息的过程中会消耗大量能源,由于底层操作,这样的请求。HTTP是一个多层网络协议栈的一部分,包括TCP IP和各种硬件级协议。这些操作,它涉及许多系统操作(如计算校验和、复制数据,引用数据缓冲区,和处理不同层的协议数据单元),是操作系统的一部分。在移动设备中,有额外的功耗,因为每个HTTP API请求有尾巴的能量,这是独立于请求的大小。尾巴能量发生在系统保持活动状态的网络电台在HTTP请求完成后执行。这样做通常是为了试图降低高能源开销的启动和关闭无线电台。虽然看似很小,一个HTTP请求的开销可以在其能源效率产生重大影响。

2.1。轮询

在标准的HTTP模型中,服务器不能启动一个连接与客户也发送一个未被要求的HTTP响应给客户端;因此,服务器不能把异步事件或数据浏览器。因此,为了尽快异步接收新数据,浏览器为新内容定期轮询服务器发送一个HTTP请求。与传统的或“空头”轮询技术,定期客户端发送请求到服务器和每个请求试图“拉动式”任何可用的事件或数据。如果没有事件或数据,服务器将返回一个空的响应,客户端等待一些时间发送请求(即另一项民意调查。轮询间隔)。轮询频率取决于客户端可以容忍的延迟从服务器获取更新的信息。轮询实现在客户端依赖于特征包括默认浏览器,比如JavaScript,而不是默认的插件。

关于能源消费,不断轮询可以消耗大量的带宽和能量通过强制的请求/响应往返当没有数据是可用的。它也可以是低效的,因为它减少了应用程序的响应能力由于新数据排队,直到服务器接收下一个调查请求从客户端14]。

这导致高能源消耗甚至一个HTTP请求。HTTP也是一个重要的额外数据的开销和发出请求时发送消息。因此,不仅发送HTTP数据的大小会影响传输成本,但也的头,它的范围可以从200 B 2 KB的页眉。

给定一个兼容的服务器和浏览器兼容,客户端只需要实例化XMLHttpRequest对象。所有现代浏览器都支持XMLHttpRequest对象,一个JavaScript对象,允许访问DOM。可以使用XMLHttpRequest对象与web服务器交换数据无需用户干预(也称为AJAX)。这意味着有可能更新的部分网页,无需重新加载整个页面。客户端实例化一个XMLHttpRequest并将其发送到服务器。之后,客户端读取HTTP响应,其中包含更新的内容数据的服务器是否有新数据可以从最后一个HTTP请求。否则,反应不包含任何有效载荷。使用“HTTP应用程序的基本通信周期轮询”如下(图1(一)):(1)客户端发出一个初始请求,然后等待响应。(2)如果有数据,与数据服务器发送一个HTTP响应。否则,它发送一个空的响应(体内没有数据)。(3)客户端通常发送一个新的民意调查请求暂停后(轮询间隔)允许一个可接受的潜伏期。

然而,投票,尽管它很简单,有一个先天的缺点:所使用资源的客户端(浏览器处理和网络)强烈依赖于频率数据更新和轮询间隔。如果数据可用性很低(例如,秒)的顺序,那么高的轮询频率会导致不可接受的负担浏览器,网络,或两者兼而有之。

图2显示了一个比较简单的JavaScript代码所需的轮询(上),长轮询(中间)和WebSocket(底部)。对于简单的轮询,客户端有一个函数(pollServer在图2),在每一个时间间隔发送一个请求(. get在JQuery函数)和立即接收和处理响应。客户端必须建立,通常硬编码轮询间隔,调查的决定当服务器应用程序的前端(时钟在图上代码2)。

2.2。长轮询

为了提高调查的缺点,有几个服务器端编程机制通常被归为常见的标签“彗星”[15]。最常见的一种是HTTP服务器推送机制“长轮询”,在这个服务器试图“开放”(没有立即回复)每个HTTP请求,响应(即。发送HTTP响应),只有当有事件。然后,总有一个未决请求,服务器可以回复发送数据是可用的。该解决方案使得web服务器将数据发送给客户新数据可用时,和浏览器不需要意识到定期轮询,也不调整轮询间隔。长轮询可以提供更及时的方式更新浏览器,同时避免延迟所经历过的客户端应用程序由于轮询间隔或空的反应,从而减少延迟在消息传递和处理/网络资源的使用。

给定一个兼容的服务器(支持异步Servlet Servlet 3.0)和一个兼容的浏览器发送请求(代码中间的蓝色阴影图2),客户刚刚来实例化一个XMLHttpRequest对象并将其发送到服务器(方法开放和发送)。之后,客户端将等待Http响应已经准备好了。一旦服务器有新数据可用,它完成HTTP交互发送相应的HTTP响应。应用程序的基本通信周期使用“HTTP”长轮询如下(图2 (b)):(1)客户端发出一个初始请求,然后等待响应(2)服务器将其响应,直到更新是可用的或推迟到一个特定的状态或超时发生(如果发生这种情况,HTTP响应没有数据)(3)当一个更新是可用的,服务器发送一个完整的响应给客户端(4)通常客户端发送一个新的长轮询请求,暂停后立即收到响应或允许一个可接受的潜伏期

HTTP长轮询机制可以应用于持续或非持久的HTTP连接。然而,使用持久HTTP连接的额外开销将避免建立一个新的TCP / IP连接(16每个长轮询请求)。

2.3。WebSocket协议

WebSocket协议中定义的(9),它允许使用TCP连接建立一个浏览器和Web服务器之间的全双工和持久socket-like通道交换非HTTP消息只有一个小的开销相比HTTP [10]。使用这个连接,后端Web服务器能够积极和异步数据推送到客户端,不管它是可用的。数据/消息交换通过连接之前,WebSocket协议需要一个初始握手建立WebSocket连接。执行消息交换的形式框架,其中包含文本或二进制数据(9]。定义不同的WebSocket subprotocols像WebSocket协议之上的SOAP绑定(MSSWSB), WebSocket应用程序消息传递协议(里面),或面向简单的文本消息传递协议(踩)。

给定一个WebSocket兼容的服务器和浏览器兼容,客户端,使用一个JavaScript API,只需要实例化一个WebSocket对象并开始听server-pushed数据事件(方法onmessage)(请参见示例代码在图的底部2)。客户端应用程序使用的基本通信周期WebSockets如下(图1(c)):(1)客户端使最初的握手,然后等待响应(2)更新可用时,通过WebSocket服务器将数据发送给客户端(3)输入数据是可用的浏览器通过异步事件(方法onmessage)

3所示。能量分析工具

测量能源消耗的软件在手机上运行的应用程序中,有多个工具基于硬件和软件(17- - - - - -24]。虽然硬件测量提供了更高的精度,我们不能使用它,因为它估计整个机器的能源消耗,和我们的研究调查消费在应用程序级别。此外,选择和配置硬件设备可能代表一个复杂的任务25),可以引入额外的偏见。一些解决方案需要特殊设备和难以使用可用的文档(18,19]。其他解决方案提供的应用程序可以安装在设备容易(20.,21),但是他们被限制到特定的设备和架构。佩特拉,这是一个缩写权力Android应用程序的评估工具,能够在方法级粒度测量功耗,但它需要一些应用预处理前测量能源消耗。佩特拉已经提供的能量测量与实际相比能耗计算硬件工具包,获得相似的结果(22]。在我们的例子中,考虑到可用的设备进行测试,我们发现两个软件解决方案,安装我们的要求:GreenOracle [26,27)和Trepn分析器(28]。GreenOracle能量是一个精确的软件模型,现在提高了GreenScaler [24]。后者提高培训过程通过自动化测试软件的生成过程。总结和简要比较现有的安卓测试工具对模型建立测试生成可以在[24]。概述的能源消耗在移动设备上的实证研究提出了相关的部分工作。

在之前的贡献(12),我们使用GreenOracle和Trepn分析器工具来配置不同的Android设备的功耗。实验的结果是非常相似的所有设备和分析工具,在这个贡献,我们选择使用的一个工具。具体来说,我们选择了绿色的甲骨文,广泛应用于其他实验研究29日,30.),它支持试验设备连接到一个电源,允许加速实验进程。

关于设备,测试被执行在三星Galaxy Nexus (https://en.wikipedia.org/wiki/Galaxy_Nexus),这是设备用于开发GreenMiner。后端web站点的web服务器部署在Glassfish的Ubuntu 14。个人电脑是一个英特尔酷睿i7 3.50 GHz 16 gb的RAM内存。web服务器有1千兆以太网网络连接。另一方面,智能手机使用WiFi连接在不同的本地网络的web服务器。

3.1。GreenOracle

GreenOracle是一个精确的能量模型使用一个大数据生成方法和数以百计的GreenMiner测量获得的能量19]。根据作者,GreenOracle上层误差界有一个接近10%,类似于其他方法的讨论(18,31日]。此外,它相对容易应用,因为它是基于信息,可以从设备的操作系统(即。Android),和作者有良好的文档记录工作流应用能量模型。最后,GreenMiner,能源计量数据的来源,已经应用在一些作品(29日,30.,32]。这支持的准确性数据用于生成能量模型。

框架用于应用GreenOracle模型是由不同的应用程序和工具(图3)。我们开发了一些脚本为Android亚行(33)操作系统的收集信息和互动与手机屏幕在一个自动化的方式避免引入额外的偏见。这个信息是由一个Java应用程序处理,最后应用模型。CPU消耗的能量模型需要信息,干扰,主要的缺点,和上下文切换,从操作系统中提取文件“/ proc /统计”和“/ proc / pid /统计”。其他必要的信息是由于执行的系统调用的执行应用程序,使用“strace命令提取,和平均执行期间屏幕颜色的RGB值。定期生成这些信息捕获应用程序的屏幕在工作(通过一个亚行脚本)和处理捕获使用效用图像颜色史书(34]。所有这些信息是处理Java应用程序,它包含GreenOracle模型,并生成csv文件可以由Microsoft Excel处理或其他类似的工具。这个框架的组件是可用的https://goo.gl/sZsMZ3。

4所示。实证研究

在本节中,我们目前的实验计划和能源配置文件获得的实验结果。使用的计量单位是焦耳(J)。一个焦耳相当于每秒一瓦特的电力辐射或消散。

4.1。目标和研究问题

本研究的方法是根据定义goal-question-metrics方法(35如下:”分析异步Android基于http的通信,网络软件开发人员”的观点的。为了实现这一目标,我们设置了以下研究问题(rq):

RQ1。是什么因素(轮询/推动间隔时间或数据大小),最能影响能源消耗在异步通信吗?这个问题探讨了数据大小的影响,数据延迟;和轮询/时间间隔,和他们的关系考虑功耗的三个方法。同时,与轮询间隔的数据可用性频率也被认为是在简单的轮询方法,因为在轮询机制,如果客户端轮询间隔比数据可用性频率小,它会导致接收空的HTTP响应。其他因素,如两个移动web浏览器的使用不同的浏览器引擎,也将被考虑。

RQ2。异步通信方法是最有效的能源消耗?有统计学意义的差异在能源消费方面的三个沟通机制?RQ2比较和概述每个异步方法的能耗是否显著不同,存在着不同的场景或浏览器,一个方法是比别人更好。这个问题的答案是做出最好的选择的关键的能源消耗和应用程序需求。此外,我们分析的量化节省功耗是否移动浏览器的一个通信机制对他人具有重要意义。这对于开发者来说是特别有趣,考虑改变一个Web应用程序的实现移动前端更尊重与设备的能量。

4.2。数据收集

为了测量和比较消费的三个异步通信机制在两个不同的移动浏览器,我们开发了三个简单的网站兼容移动浏览器(http://caosd.lcc.uma.es: 9000 /)。他们每个人允许测试的三个通信机制之一。前端的用户界面允许配置参数为每个实验:轮询/把数据从服务器接收到的频率和大小(图4)。所有的网站允许配置服务器随机生成数据(包括大小和时间)。服务器生成事件随机显示两个正常(或高斯分布)。

这三个网站呈现相同的简单的用户界面。我们的测试侧重于能源消耗数据接收,我们测量了能源消耗的移动浏览器接收数据时使用的三个通信机制与不同的时间在不同的场景中,数据大小和频率。我们认为实验两个时间:1分钟和5分钟。我们选择了1分钟,因为根据不同的工作36,37),简称为手机的交互的人是1分钟左右的时间。此外,我们考虑再实验的五分钟。与平板电脑的互动或特定的Web应用程序,如赌博、新闻咨询,或访问社交网络,超过1分钟,通常这个时间(38]。大多数通知和更新发生在间隔超过30秒。关于数据的大小,我们考虑五种不同的消息大小(140字节,280字节,560字节,1120字节,和2240个字节),来自一个(即通常的twitter消息。140字节)的消息需要碎片在IP水平(即。2240字节)。数据更新周期选择测试(以毫秒为单位)1000,5000,10000,30000,50000。这些更新时间代表了轮询频率对于简单的轮询和数据之间的间隔时间长轮询和WebSockets服务器的可用性。每个测试已经重复20次。

数据5- - - - - -7这些实验的结果。结果足够确凿的标准偏差低于15焦耳实验1分钟,低于25焦耳实验5分钟。根据我们的实验,有不同的能源消费模式的持续时间取决于web浏览器和实验。一般而言,Chrome能耗低于Firefox。然而,它似乎更合理的降低轮询周期。正如所料,WebSocket最低能源消耗为所有实验。其他有趣的问题是,似乎对能耗数据大小几乎没有影响。

我们已经做了实验,测量能源消耗长轮询和WebSocket更现实的场景。具体地说,我们有测量能量两种通信机制的随机数据规模的场景可用随机时间。为了生成随机数据的后端,我们使用了java类java.util.Random和它的方法nextGaussian ()。该方法用于获取正态分布的伪随机数(即。,他们遵循一个高斯分布)的意思是0和标准偏差1。我们使用方程(1)的参数dev和的意思是生成更现实的数据模式。的高斯分布模型事件生成时间的意思是5000和标准偏差(dev)1000年(这意味着70%的值将介于5000±1000,4000和6000毫秒之间换句话说;95%的值将下降3000至7000毫秒)。高斯分布的标准差大小有一个用于生成数据的意思是500和标准偏差(dev)100(70%的值将介于500±100,换句话说在400和600字节)。

描述在表的随机试验的结果1。我们可以看到一个伟大的相似性长轮询和WebSocket但对WebSocket略低消费。此外,有趣的是,对于随机实验中,Firefox的能源消耗比Chrome的消费高。

4.3。研究问题的答案

RQ1。是什么因素(轮询/推动间隔时间或数据大小),有更多的影响在异步通信能耗?为了回答这个问题,我们运用相关系数(39]。相关系数是一个某种类型的数值衡量两个变量之间的相关性。根据不同的类型的变量之间的关系(即。,linear and monotonic), we can use different correlation coefficients like Pearson or Spearman. Therefore, before applying the corresponding coefficient, we will study the relationship between the variables. In order to accomplish this task, we will create scatterplots matrices of the data. In addition, scatterplots can detect whether there is a relationship between the variables.

我们的实验(数据的散点图8- - - - - -13显示三个重要的结果。首先,没有一个字节的变量和能源消费之间的关系在任何场景中进行了研究。其次,有一个频率和能源消费之间的关系,这种关系是单调的。这适用于所有的场景,除了使用Firefox在轮询之一(图1分钟的实验8)。在这种情况下,变量之间的关系是线性的。最后,这些散点图证实我们的输入变量(即独立。、字节和时间)。

为了评估的频率和能源消费之间的关系,我们运行斯皮尔曼等级相关系数。这个系数是一个单调的强度的统计测量成对数据之间的关系。因此,对单调相关的变量来说是足够的。所有的线性关系是单调,我们可以将这个系数应用于轮询Firefox(图1分钟的场景8)。斯皮尔曼等级相关系数是用r_年代并受到−1和1。越接近r_年代是 ,较强的单调关系。我们使用IBM SPSS统计工具进行分析。

斯皮尔曼相关(表的应用结果2从散点图)证实了很明显;有一个强烈的负面能量消耗和时间之间的关系在所有场景。因此,短的轮询周期与高能源消耗有关。我们有测试结果使用的重要性值,低于0.001在所有情况下,我们可以确认结果。

总之,轮询/推间隔的因素对能源消费的影响。我们可以证实这一事实数据的柱状图5- - - - - -7。在Chrome中,有相当大的区别1秒的时间所消耗的能量,其余的轮询时间不管实验的持续时间。一方面,1分钟(数据的实验5(一个),5 (b)- - - - - -7(一),7 (b))、轮询时间1秒能耗大约是150 - 200焦耳,而其余的轮询时间大约是100焦耳,传输的数据没有意义。实验的情况下5分钟(图相似5 (c),5 (d)- - - - - -7 (c),7 (d))、轮询时间1秒的能源消耗约500 - 800焦耳,和其余的轮询时间分析了约400焦耳。这些差异是WebSocket比较微小。另一方面,Firefox似乎不太合理的轮询周期的变化。

考虑提供的信息条形图和斯皮尔曼等级系数,我们状态更新频率是有更多的因素对能源消费的影响。所以,机制,必要时将引发一些互动减少消费。然而,这不是轮询机制的情况下,将消耗能量,不管数据的可用性。针对这些数据,问题的答案RQ1是经常更新的数据会对能源消耗造成负面影响,而数据的大小几乎不影响能源消耗。为了减少电池消耗在移动前端,如果数据推/轮询可以设置为固定利率没有危害的质量服务和用户体验,开发人员应该配置web应用程序的后端将数据与上面一段时间5000毫秒。如果新数据产生在这个区间,它可以发送在一起没有惩罚能源消耗相同的交付。

RQ2。异步通信方法是最有效的能源消耗?显著的差异在能源消耗方面的三个沟通机制?为了回答这个问题,我们首先做一个定量研究的能耗值获得不同的通信机制和web浏览器。表3包括这些值的描述性统计。轮询显然是能耗最高的通信机制虽然长轮询和WebSockets之间的相似性。概括地说,使用WebSocket数据显示最低的能源消耗。然而,轮询/推时间超过1秒,使用Firefox,它的消费非常类似于其他通信机制。简单的轮询能耗最高的异步通信机制但长轮询时间长轮询的消费是非常相似的。答案是,根据我们的研究结果(数据5- - - - - -7),没有单一的异步机制显然更好的在所有的情况下。

这个结果是连贯的活动处理浏览器执行小时间。例如,如果80字节的数据可用每2000毫秒,轮询客户端轮询间隔1500毫秒,HTTP请求的发送462字节(7760字节的数据过载+头的大小字节的HTTP响应)。同样的场景中,客户机使用长轮询发送HTTP请求的462字节(加上大小的字节的HTTP响应头)。自从WebSocket客户机不需要发送任何请求和数据服务器接收80字节的数据每2000毫秒,开销是0。发送的消息数量解释了更高的能源消耗。在实用性方面,TCP连接传输比轮询与长轮询更有用的应用程序数据。

测试随机产生的数据(见表1),它允许测量能源消耗当丛发性或互动生成的数据来源,已确认长轮询和WebSockets之间类似的能源消耗。1分钟和5分钟的实验中,能源消耗的WebSocket端略低于长轮询客户的能源消耗。这些随机的结果证实长轮询的优势和WebSocket轮询当源不生成数据在一个固定利率。当最充足的轮询时间不能提前,客户端调查数据更频繁,引起了一些空的反应和增加能源消耗:轮询在Chrome的平均能耗为1分钟的实验是137焦耳和5分钟的实验是498焦耳。使用Firefox,消费高:1分钟的实验的消费是225焦耳,5分钟实验是616焦耳。在所有的测试(固定利率/数据和随机生成),Firefox的能源消耗比Chrome的消费高。

考虑到结果,我们答案的第一部分RQ2长轮询的能源消耗和WebSocket非常相似的实验。简单的轮询是最低效的能源消耗。然而,当新的数据经常可用,长轮询引入了一个过载来自HTTP请求的处理和发送,消耗更多的能量(使用WebSockets,客户没有发送请求到服务器)。令人惊讶的是,这不是维持更长时间。原因是WebSocket协议定期发送信号数据保持连接打开如果不使用和能源消耗的作用类似于能源消费引起的长轮询发送HTTP请求。肯定很多开发人员可能认为WebSockets,最近的技术,将消耗不到一个年长的一个,但是我们发现,这些web开发人员的信仰并不对应于现实,这种实验的效用。

回答的第二部分RQ2意味着分析能源消费上的这些差异是否显著。我们直观地分析了能源消耗的通信机制使用箱线图(图14)。这些图表证据不同的能源消耗模式取决于web浏览器和实验的持续时间。在能源消耗显著差异(参见图1分钟的实验(14日)和14 (b))。有趣的是,能源消耗的最低和最高价值的长轮询所有实验除了Firefox在5分钟的实验。我们可以看到异常值在所有实验,可以意味着显著统计学差异三个沟通机制。

因此,我们还进行了Wilcoxon等级测试(也称为Mann-Whitney求和U以及)为每一对团体测试观察差异他们的平均值。Wilcoxon等级和测试是一种非参数测试适合小样本在我们的案例中。这个测试用于测试两个样品是否有可能来源于相同的人口。因此,本次测试的零假设是“没有两个数据集之间的统计上的显著差异。“如果这个测试的价值低于0.05,零假设被拒绝。的这些测试值在表中做了总结4零假设被拒绝,Chrome在1分钟的实验,但令人惊讶的是接受Firefox在1分钟,但轮询与长轮询之间。

所以,一般来说,有统计上显著的差异取决于通信机制。在1分钟的实验,这是真的除了火狐的差异并不显著。我们有不同的实验和结果5分钟轮询与长轮询之间差异具有统计学意义,与长轮询和WebSockets在Chrome。在Firefox中,有一个轮询与长轮询之间统计上的显著差异,轮询和WebSocket。

Wilcoxon和等级测试展示了一些场景之间存在统计上的显著差异。然而,我们没有评估这些差异的相关性。为了完成这项任务,我们运行一个效果测试科恩d情况下Wilcoxon丢弃的零假设(表4,黑色细胞Wilcoxon意味着没有统计上的显著差异,所以科恩d不申请的情况下)。根据经验法则,科恩d值高于0.8显示了一个巨大的影响,或者换句话说,两组之间的差异有关。在我们的实验中,这是对Polling-Long轮询用火狐,Polling-WebSocket Firefox在5分钟的实验。另一方面,科恩d值高于0.5显示介质的影响,的情况下Polling-WebSocket Chrome在1分钟的实验和久Polling-WebSocket Chrome的5分钟的场景。

RQ2的第二部分的答案是,考虑的结果分析,我们得出结论能耗最低的通信机制是WebSocket。然而,能源消耗的差异这显然只是相关与轮询机制在Chrome为5分钟1分钟的实验和Firefox实验。根据我们的分析,对功耗的最重要的区别是轮询与长轮询之间当web浏览器Firefox。

5。威胁的有效性

本节简要讨论了内部效度,结构效度,我们研究的外部效度。内部效度打算探索获得的结果是否或不受其他因素影响。建构效度的威胁是关心是理论和观测之间的关系多好。然而,外部效度分析实验的结果是否可以通用。

关于内部效度,我们应该分析结果的准确性energy-measuring提供的工具。尽管硬件解决方案通常提供更多的能源测量的精度,我们选择使用一个软件测量工具,GreenOracle。如前所述,在本文的第三部分,繁殖实验的困难由第三方硬件解决方案的精度,证明了软件工具的主要原因是选择软件解决方案。此外,我们报告绝对能源值不感兴趣,但给建议开发人员根据比较结果。

另一个内部效度是与其他元素的能耗实验的Web应用程序。为了减轻这种威胁,所有在场的JavaScript客户端相同的用户界面,它将呈现在所有的能源消耗实验。在内部,三个基于javascript客户端实现是建立在最小的示例中提供的教程从Netbeans和大学课程。客户端不使用CSS和JavaScript函数用于实现异步机制从标准JavaScript库和移动浏览器完全支持的用于我们的实验。

另一个内部威胁可能来自使用一组参数的实验,不能认为是详尽。根据文献,参与在异步通信能耗的主要因素是轮询周期和传输的信息量。值的范围选择说明最小交互等消息的交付在Twitter(140字节)和更复杂的情况下,甚至需要碎片在IP层(2240字节)。所以,考虑五种不同大小的数据,我们认为我们已经介绍了各种各样的情况。关于新数据可用的频率,我们认为能源消耗长网的交互或更新不需要用户交互。这种情况可能发生,当用户需要通知最近的出版物的社会网络或专业网(如交易,赌博和运动结果网,更别提几)。

建构效度分析威胁的程度的能量测量工具措施目的是测量的理论构建。我们已经识别出的选举一个软件工具来衡量能源消费结构效度威胁。在前一节中,我们已经讨论了使用只有一个能量测量工具不能被视为一个严重的构造威胁因为我们已经测试了不同的被广泛接受的软件工具在之前的实验中,结果表明,他们提供类似的能源措施。

对于外部有效性,我们考虑使用一个具体的移动浏览器的影响实验。只有两个移动浏览器支持本研究的三个异步通信机制,Chrome和Firefox。我们意识到使用一个浏览器或其他可能影响设备的能源消耗。所以,我们选择使用两个最扩展web浏览器在我们的实验中,谷歌Android手机浏览器和火狐浏览器,使用不同的浏览器引擎(即。壁虎)。其他移动浏览器使用内部眨眼,相同的浏览器引擎,包括移动浏览器。

最后,我们考虑作为外部威胁的推广结果所有手机和安卓版本。这里的限制是有可靠的能源为足够的设备测量工具。为了减轻这种限制,我们选择了使用GreenOracle作为测量工具(如前面所述的一样,GreenOracle和Trepn分析器产生相似的结果为不同的设备)。

6。相关工作

研究了能源消耗在移动设备在不同工作。实验研究应对能源消耗在不同环境和不同的目的12,27,29日- - - - - -31日,39- - - - - -51]。进行这些研究帮助开发者关注的能源消耗和贡献提供替代选择更节能。这项研究在31日]分析如何设计拙劣的症状或实现的选择(即代码味道)影响能源消耗。这项研究揭示方法受到一些代码气味类型消费高达87倍以上方法受到其他代码味道并提出重构在所有的情况下减少能源消耗。代码味道的能源消耗也在研究[29日)为了评估工具,自动纠正代码味道的好处并评估它们对能源消费的影响。这项研究在40]提供了详细的资料的能量消耗等常见的数据结构的Java执行常见的操作列表,地图,并设置抽象,这表明这些抽象的替代数据类型差别很大的能源消耗取决于操作。开发人员可以使用使用上下文数据结构和测量之间的能源配置文件决定选择集合实现。的能量影响登录不同的Android手机应用程序使用GreenMiner评估(30.]。这项研究表明,测井对能源消费的影响可忽略不计的移动应用程序测试。该方法在40)结合实证测量不同的机器学习算法实现的复杂性理论提供混凝土和理论上接地建议开发人员想在智能手机采用机器学习的能源消耗和准确性。这项研究得出结论,有些实现的算法通常比别人表现得更好,表明哪些其他因素和参数可以影响哪些机器学习算法和实现将提供最好的结果。

移动设备通信功能也被认为是不同的实验研究。在[39),能源消耗的主要功能的手机,包括与2 g和3 g数据传输,研究。后,同样的作者分析了能源消耗不同的通信组件,如蓝牙无线局域网,2 g和3 g(详细44]。进行的这项研究中,诺基亚N95,认为3 g通信能耗比GSM (2 g)通信,使用不同的应用程序和服务要求的数据连接。

大部分的移动应用程序在互联网上传输数据,它是一个重要的领域分析等数据传输所需的组件在不同的层。在[45),比较WLAN和3 g提供了关于他们的能源消耗,表明使用WiFi而不是3 g是更节能。这项研究还表明,网络活动(数据包大小和数据包之间的时间间隔发送/接收)直接影响到最终能源消耗和电池寿命。工作集中在网络访问技术,和其他的研究试图优化能源消耗在应用程序级别。在[46,47),两个当前数据交换格式之间的差异(JSON和XML)进行了比较。比较分析了他们在处理速度方面,开销和能量消耗。结果表明,JSON格式显示电池管理中更好的性能。的比较47]也测试二进制协议缓冲区,这是最有效的传输大数据量时,显示出更好的管理能源原始数据。

其他作品关注提供解决方案更有效利用电池通信。自定义的方法来延长电池寿命(所示的内容48]。服务器提供内容的想法是基于连接的移动电话的电池状态。例如,手机的电池是几乎空无一人被提供文本和视频数据。服务器也扮演一个重要的角色在计算卸载方法,电池密集计算得到转移到服务器在互联网上提供(云计算),以节约能源。现有研究表明,不同的通信和数据传输的一个重要话题关于移动设备的能源消耗。能源消费在传输层包括在WLAN安全问题分析——和3 g系统(49]。接近我们的研究中,不同的工作解决能源消耗数据传输的概念手机的浏览器中。在[50),WebSocket和AJAX是以问候他们的能源消耗和性能对3 d图形渲染的浏览器的手机。比较WebSockets和WebRTC HTML5连接方法是由Mandyam和伊桑·[51]。他们建议一些方法移动web开发人员如何减少能耗等移动设备W3C电池API或最佳实践的发展。在[52),WebSocket协议是超文本传输协议(HTTP)相比,使用OpenPicus Flyport WLAN模块。这项工作也研究的影响传输的数据量和传输频率关于能源消耗。工作(13)措施,比较了HTTP / REST和WebSocket能耗使用移动电话。REST / HTTP和WebSocket之间的能耗是衡量在使用不同的接入网技术(3 g,边缘和WLAN)。影响能源消耗的因素识别通过统计分析,他们得出以下结果:(i)的使用其他比使用WebSocket消耗更多的能源;(2)高能源消耗的休息的原因不是HTTP协议的开销;(3)连续的连接和断开消耗更多的能量比站连接;(iv)的发布和订阅模型与WebSocket消耗更少的能量比长轮询与休息;(v)常务WebSocket连接延迟低于其他连接;(vi)的发布和订阅模型与WebSocket消耗更少的能量比长轮询与休息;(七)所使用的网络(边缘、3 g和WLAN)影响上述论文的结果。

以来,能源是一个重要的资源对于移动设备上运行的应用程序,一些工作应对节能或优化电池持续时间是一个问题解决的背景下,数据传输和通信。在[8),使HTTP请求被认为是最耗费精力的活动之一的手机在所有操作。基于之前的研究,这项工作提出了一种方法来减少HTTP请求的能源消耗在Android应用程序自动检测,然后绑定多个HTTP请求。

7所示。结论和未来的工作

本文中的实验提供了面向软件开发人员的有趣信息如何不同的异步通信机制的Web应用程序和浏览器引擎从能源消费行为的观点。根据实验数据,我们可以有一个异步解决方案和模拟之间的显著差异(即。,简单的轮询)在大多数的情况下进行了研究。然而,长轮询和WebSocket之间,没有场景可以被认为是最环保的一个及其对能耗的差异没有统计学意义。本研究的相关性也在它提供的细粒度的信息,可以用来做一个合理的决定哪些是最好的异步技术对每个Web应用程序的需求。也是非常有用的发现,软件开发人员可以增加推数据的大小不会导致能耗的增加。然而,软件开发人员需要小心,因为这并非如此如果新数据的频率增加。更新率越高,能耗越高。推动利率可以设置的后端应用程序的应用程序需求。本文分析有助于做出这一决定。概括地说,使用WebSocket数据显示最低的能源消耗,尽管能源消耗非常类似于长轮询。 According to our results, there is no single asynchronous mechanism clearly better in all the scenarios. Finally, another interesting conclusion is that Chrome for Android consumes less energy than Mobile Firefox, confirming our hypothesis that it is useful to explore and identify the most efficient browser engine.

作为我们未来工作的一部分,我们计划使用这些结果来分析如果大多数Web应用程序的异步交互可以通过监测和改善重构或重新配置异步通信功能不会导致一个巨大的罚款在能源消耗或用户体验。另一个目标是研究并比较HTTP / 2中的能源消耗现在支持移动浏览器。HTTP / 2提供了更好的性能的网站和web应用程序。然而,更好的性能并不总是意味着降低能源消耗。我们计划研究HTTP / 2提供更好的能源消耗性能是否达到更长的电池寿命与HTTP / 1.1相比。作为这项研究的一部分,我们还计划研究如何传输层安全性(Transport Layer Security, TLS)(移动浏览器只支持HTTP2 TLS-https)影响移动设备的能源消耗。

数据可用性

使用的数据来支持本研究的发现可以从相应的作者。

的利益冲突

作者宣称没有利益冲突有关的出版。

确认

这项工作是支持的项目魔术P12-TIC1814和哈达tin2015 - 64841 r(由菲德尔共同投资基金)和博士后计划大学的马拉加。

引用

1. “全球移动电话用户数量从2015年到2020年(在数十亿),”2018年8月,https://www.statista.com/statistics/274774/forecast-of-mobile-phone-users-worldwide/。视图:谷歌学术搜索
2. d·李,s, j . Gui和w·g . j . Halfond”实证研究能源消费的android应用程序,”学报2014年IEEE国际会议软件维护和演化维多利亚,页121 - 130年,加拿大,2014年9月。视图:谷歌学术搜索
3. m . Tawalbeh a Eardley, l . Tawalbeh”研究移动设备的能源消耗,”Procedia计算机科学卷,94年,第189 - 183页,2016年。视图:出版商的网站|谷歌学术搜索
4. Balasubramanian Balasubramanian n ., a, a . Venkataramani”在手机能耗:测量研究和对网络应用程序的影响,”学报》第九届ACM SIGCOMM互联网会议上测量,IMC的09年,第293 - 280页,芝加哥,2009年11月,美国。视图:谷歌学术搜索
5. “移动和平板电脑互联网使用超过桌面为第一次在世界范围内,“2016年5月,http://gs.statcounter.com/press/2016。视图:谷歌学术搜索
6. r·t·菲尔丁j .盖j . c .大亨等。超文本传输Protocol-http / 1.1注释、互联网要求编辑,RFC 2616, World Wide Web Consortium,剑桥,妈,美国,1999年,http://www.rfc-editor.org/rfc/rfc2616.txt。
7. r·菲尔丁j .盖j .大亨h . Frystyk和t·伯纳斯-李超文本传输Protocol-http / 1.1注释、互联网要求编辑,RFC 2068, World Wide Web Consortium,剑桥,妈,美国,1997年。
8. d . Li y律、j . Gui和w·g·j . Halfond”自动化能源优化移动应用程序的http请求”软件工程学报》第38届国际会议上,ICSE 16奥斯汀,页249 - 260年,TX,美国,2016年。视图:出版商的网站|谷歌学术搜索
9. 即Fette和a . MelnikovWebSocket协议注释、互联网要求编辑,RFC 6455, World Wide Web Consortium,剑桥,妈,美国,2011年,http://www.rfc-editor.org/rfc/rfc6455.txt。
10. 诉Pimentel和b . g . Nickerson”与WebSocket通信和显示实时数据,”IEEE网络计算,16卷,不。4,45-53,2012页。视图:出版商的网站|谷歌学术搜索
11. p . Beverloo m·汤姆森m . van Ouwerkerk b·苏利文和e . Fullea“API,推”技术报告,W3C,剑桥,妈,美国2019年1月,https://www.w3.org/TR/push-api/。视图:谷歌学术搜索
12. Ayala, m·埃莫·l·富恩特斯,D.-J。穆尼奥斯,”实证研究基于网络通信的功耗移动电话,”IEEE学报》15日国际会议上无处不在的智能和计算奥兰多,页861 - 866,美国2017年11月。视图:谷歌学术搜索
13. 诉赫韦格,r·费舍尔和p·布劳恩,“评估休息和Websocket问候他们的移动应用程序,能源消耗”IEEE学报》第八届国际会议上智能数据采集和先进的计算系统:技术与应用,IDAACS 2015,页342 - 347,华沙,波兰,2015年9月。视图:谷歌学术搜索
14. 住美国洛雷托,p . Saint-Andre s Salsano g·威尔金斯,已知问题和最佳实践的使用长轮询和双向http流媒体注释、互联网要求编辑,RFC 6202, World Wide Web Consortium,剑桥,妈,美国,2011年,http://www.rfc-editor.org/rfc/rfc6202.txt。
15. a . Russell”彗星:低延迟数据浏览器”,2006年,http://infrequently.org/2006/03/comet-low-latency-data-for-the-browser/。视图:谷歌学术搜索
16. j . Postel传输控制协议注释、互联网要求编辑,性病7,World Wide Web Consortium,剑桥,妈,美国,1981年,http://www.rfc-editor.org/rfc/rfc793.txt。
17. 霍克·m·a . m . Siekkinen k . n .汗y,和s . Tarkoma”建模、分析和调试移动设备的能源消耗,”ACM计算调查,48卷,不。3,39:1-39:40,2015页。视图:出版商的网站|谷歌学术搜索
18. d·李,s, w . g . j . Halfond和r . Govindan”为android应用程序计算线路电平能源信息,”《2013年国际研讨会上软件测试和分析,ISSTA 2013卢加诺,页78 - 89年,瑞士,2013年7月。视图:谷歌学术搜索
19. 辛德尔,a·威尔逊k .拉斯穆森e·j·巴洛j·c·坎贝尔和s . Romansky”GreenMiner:基于硬件的挖掘软件存储库软件框架,能源消耗”11日工作会议的程序挖掘软件存储库,MSR 2014页12-21海得拉巴,印度,2014年6月。视图:谷歌学术搜索
20. m .董和l .钟”Self-constructive高速系统能量建模为电池供电的移动系统,”学报》第九届国际会议在移动系统中,应用程序和服务,经验的11,页335 - 348,马里兰州贝塞斯达,美国6 - 2011。视图:谷歌学术搜索
21. “电力监控”,2017年4月,https://www.msoon.com/LabEquipment/PowerMonitor/。视图:谷歌学术搜索
22. d . Nucci f . Palomba a . Prota a . Panichella柴德曼a和a·德卢西亚,“android应用程序的基于软件的能源分析:简单,高效和可靠吗?“在IEEE学报》24日国际会议软件分析、进化和再造(理智)克拉根福,奥地利,2017年2月。视图:谷歌学术搜索
23. d . Nucci f . Palomba a . Prota a . Panichella柴德曼a和a·德卢西亚,”佩特拉:一个基于软件的工具估计能源的android应用程序”美国第39软件工程国际会议上的伙伴布宜诺斯艾利斯,阿根廷,2017年5月。视图:谷歌学术搜索
24. s . Chowdhury s Borle s Romansky, a,辛德”GreenScaler:培训软件能源模型与自动测试生成,“经验软件工程,在美国,2018页。视图:出版商的网站|谷歌学术搜索
25. 辛德尔,“绿色软件工程:方法论的诅咒,”IEEE学报》23日国际会议软件分析,进化,再造(理智),5卷,页46-55,大阪,日本,2016年3月。视图:谷歌学术搜索
26. Chowdhury a和a·辛德,“GreenOracle:估算软件能源消费与能源测量全集,”《第13次国际会议上挖掘软件存储库,MSR的16,p。4、奥斯汀、TX,美国,2016年5月。视图:谷歌学术搜索
27. s . a . Chowdhury吉尔,s . Romansky, a辛德尔。”我犯错误了吗?发现代码变化的影响在能源回归,”加拿大阿尔伯塔大学、埃德蒙顿、AB 2016年PeerJ预印本,技术报告5:e2419v3。视图:谷歌学术搜索
28. “Trepn力量分析器高通技术的产物,Inc .,“2017年4月,https://developer.qualcomm.com/software/trepn-power-profiler。视图:谷歌学术搜索
29. a . Carette m·a·a·尤尼斯·g·赫克特,n .内政部和r . Rouvoy”调查的能量影响android气味,”24日学报》国际IEEE会议软件分析、进化和再造(理智),10页、芝加哥、IL,美国,2017年2月。视图:谷歌学术搜索
30. Chowdhury s, s . Di Nardo, a,辛德和z . m .江”的探索性研究评估在Android应用程序日志的能量影响,”经验软件工程,23卷,不。3、1422 - 1456年,2018页。视图:出版商的网站|谷歌学术搜索
31. f . Palomba d . Di Nucci a . Panichella柴德曼a和a .德卢西亚”代码味道的影响能源消耗的移动应用程序,”信息与软件技术卷。105年,43-55,2019页。视图:出版商的网站|谷歌学术搜索
32. k . Aggarwal c . Zhang j·c·坎贝尔,a .辛德尔和e . Stroulia”系统调用跟踪的力量:预测软件能耗的影响变化,”24日学报》年度计算机科学和软件工程国际会议上,CASCON 14马卡姆,页219 - 233年,加拿大,2014年11月,http://dl.acm.org/citation.cfm?id=2735522.2735546。视图:谷歌学术搜索
33. “Android调试桥”,2017年4月,https://developer.android.com/studio/command - line/adb.html?hl=es - 419。视图:谷歌学术搜索
34. “图像颜色史书,RGB, HSV,华尔街日报&实验室图像颜色的统计和聚类简单和容易,”2017年4月,http://mkweb.bcgsc.ca/color-summarizer/。视图:谷歌学术搜索
35. v . r . Basili”软件建模和测量:目标/问题/公制范例,”马里兰大学学院公园,大学公园,医学博士,美国,1992年,技术报告,UMIACS tr - 92 - 96。视图:谷歌学术搜索
36. n .效力过c .罗t Anagnostopoulos说道et al .,“智能手机使用的系统评估差距,”学报2016年气会议上人为因素在计算系统中,气的16圣何塞,页4711 - 4721年,CA,美国,2016年5月。视图:谷歌学术搜索
37. d·费雷拉,j . Goncalves诉Kostakos l . Barkhuus和a·k·戴伊“上下文micro-usage经验取样的移动应用程序,”学报》第16届国际会议上与移动设备人机交互与服务,MobileHCI 14加拿大多伦多,页91 - 100,,2014年9月。视图:谷歌学术搜索
38. d·迈克·迈克·r·d·Findling和r . Mayrhofer“大规模、长期的移动设备使用特点,分析”诉讼ACM的互动、移动、可穿戴和无处不在的技术,1卷,不。2、21页。视图:出版商的网站|谷歌学术搜索
39. w . Waybe和丹尼尔,应用非参数统计美国,霍顿-米夫林-哈考特,波士顿,MA, 1978。
40. 哈桑,z国王,m .哈菲兹·m·Sayagh b·亚当斯和辛德尔,“能源配置文件的java集合类,”软件工程学报》第38届国际会议上,页225 - 236年,芝加哥,2016年5月,美国。视图:谷歌学术搜索
41. a·麦金托什,s·哈桑,a,辛德”安卓手机应用程序开发人员能做什么机器学习的能耗呢?”经验软件工程,2018年第1 - 40页。视图:谷歌学术搜索
42. e·a·桑托斯·c·麦克莱恩,c . Solinas a辛德尔,“码头工人如何影响能源消耗?评估工作负载的码头工人的容器。”系统和软件杂志》上卷。146年,14-25,2017页。视图:出版商的网站|谷歌学术搜索
43. a·帕沙克y . c . Hu m . Zhang p·巴尔,Y.-M。王”,细粒度的动力建模使用系统调用跟踪,智能手机”学报第六届会议上计算机系统,EuroSys”11萨尔斯堡,页153 - 168年,奥地利,2011年4月。视图:谷歌学术搜索
44. g . Perrucci f .惠普Fitzek g .萨索w·凯勒和j . Widmer”的影响2 g和3 g网络的使用手机的电池寿命,”欧洲无线学报》丹麦,页255 - 254,Aalborg, 2009年5月。视图:谷歌学术搜索
45. g . p . Perrucci f .惠普Fitzek, j . Widmer”调查能源消费实体智能手机平台,”职业训练局春天学报》,页1 - 6,布达佩斯,匈牙利,2011年5月。视图:谷歌学术搜索
46. g . Metri a . Agrawal r .仙女和w·史,“吃起来是什么在我的智能手机电池寿命:一个案例研究”ICEAC学报》,页1 - 6,Guzelyurt、塞浦路斯、2012年12月。视图:谷歌学术搜索
47. n . Nurseitov保尔森,r·雷诺兹和c .伊苏列塔”JSON和XML数据交换格式的比较:一个案例研究中,”《ISCA 22日国际会议和工程计算机应用在工业上,页157 - 162年,旧金山,美国,2009年11月。视图:谷歌学术搜索
48. b·吉尔和p . Trezentos”影响的数据交换格式在智能手机、能耗和性能”学报2011年研讨会的开放源码和设计沟通,OSDOC”112011年,页1 - 6,葡京,葡萄牙。视图:出版商的网站|谷歌学术搜索
49. d . g . m . w . Kim Yun, j·m·李和s . g .崔”电池寿命时间扩展方法在智能手机,使用选择性数据接收”ICOIN学报》金,y, c·金和p . Tantatsanawong Eds。,pp. 468–471, Bali, Indonesia, February 2012.视图:谷歌学术搜索
50. p·米兰达,m . Siekkinen和h·瓦里斯-“TLS和能源消耗在一个移动设备:测量研究中,”第16届IEEE学报》研讨会上计算机和通信,ISCC 2011科孚岛,页983 - 989年,希腊,6 - 2011。视图:谷歌学术搜索
51. k . Kapetanakis和美国Panagiotakis评估web 3 d图形动画的技术在便携式设备上,”学报》国际会议通讯和多媒体,TEMU 2012,页152 - 157,克里特岛,希腊,2012年7 - 8月。视图:谷歌学术搜索
52. b . d . Mandyam和n•移动系统四世”World Wide Web Consortium,剑桥,妈,美国,2012年,技术报告。视图:谷歌学术搜索

版权

版权©2019 Inmaculada Ayala等。这是一个开放分布式下文章知识共享归属许可,它允许无限制的使用、分配和复制在任何媒介,提供最初的工作是正确引用。