Commit 8ca4e169221528ce22a3649643223b841677ba1d
1 parent
fd01472c
Done.
Showing
3 changed files
with
32 additions
and
90 deletions
.ispell_english
0 → 100644
| 1 | +Android | |
| 2 | +Android's | |
| 3 | +app | |
| 4 | +app's | |
| 5 | +apps | |
| 6 | +AudioFlinger | |
| 7 | +clickable | |
| 8 | +ESPN | |
| 9 | ||
| 10 | +foregrounded | |
| 11 | +IRB | |
| 12 | +kbps | |
| 13 | +OTA | |
| 14 | +overvalue | |
| 15 | +overweighting | |
| 16 | +pedometer | |
| 17 | +pedometers | |
| 18 | +realtime | |
| 19 | +Skype | |
| 20 | +smartphone | |
| 21 | +smartphones | |
| 22 | +Snapchat | |
| 23 | +Sportscenter | |
| 24 | +SurfaceFlinger | |
| 25 | +testbed | |
| 26 | +touchscreen | |
| 27 | +UI | |
| 28 | +undervalue | |
| 29 | +uninstall | |
| 30 | ||
| 31 | +Yahoo | |
| 32 | +YouTube | ... | ... |
old/utility.tex deleted
| 1 | -\section{Computing Energy Efficiency} | |
| 2 | -\label{sec-utility} | |
| 3 | - | |
| 4 | -Based on the results from the previous section, we can formulate design | |
| 5 | -requirements for an energy efficiency metric to apply to smartphone apps. | |
| 6 | -First, it must scale with usage, respecting the differences in baseline | |
| 7 | -consumption between users identified in Section~\ref{subsec-uservariation} | |
| 8 | -and the temporal variation of apps identified in | |
| 9 | -Section~\ref{subsec-timevariation}. Second, it must try to avoid targeting | |
| 10 | -top apps, even if they tend to consume a great deal of energy as described in | |
| 11 | -Section~\ref{subsec-consumption}, as these may not be apps that users are | |
| 12 | -willing to uninstall. Finally, we use the analysis of background energy | |
| 13 | -consumption in Section~\ref{subsec-background} as a hint about where to | |
| 14 | -start, given that background energy consumption should match foreground usage | |
| 15 | -in most cases. | |
| 16 | - | |
| 17 | -In the section we walk through several ways of characterizing app energy | |
| 18 | -consumption: via the total amount, by consumption rate, and scaled against | |
| 19 | -foreground energy consumption and a new content-delivery metric we design | |
| 20 | -that incorporates use of both the display and the audio device. In each case | |
| 21 | -we examine the app consumption data generated by our usage monitoring study | |
| 22 | -and use each metric to shed light on app energy consumption. | |
| 23 | - | |
| 24 | -\subsection{Total Consumption} | |
| 25 | - | |
| 26 | -\input{./figures/tables/tableTOTAL.tex} | |
| 27 | - | |
| 28 | -Clearly, ranking apps by total energy consumption over the entire study says | |
| 29 | -much more about app popularity than it does about anything else. | |
| 30 | -Table~\ref{table-total} shows the top and bottom energy-consuming apps over | |
| 31 | -the entire study. As expected, popular apps such as the Android Browser, | |
| 32 | -Facebook, and the Android Phone compunent consume the most energy, while the | |
| 33 | -list of low consumers is dominated by apps with few installs. This table does | |
| 34 | -serve, however, to identify the popular apps in use by \PhoneLab{} | |
| 35 | -participants. | |
| 36 | - | |
| 37 | -\subsection{Consumption Rate} | |
| 38 | - | |
| 39 | -\input{./figures/tables/tableRATE.tex} | |
| 40 | - | |
| 41 | -Computing the rate at which apps consume energy by scaling their total energy | |
| 42 | -usage against the total time they were running, either in the background or | |
| 43 | -foreground, reveals more information, as shown in Table~\ref{table-rate}, The | |
| 44 | -results identify Facebook Messenger, Google+, and the Super-Bright LED | |
| 45 | -Flashlight as apps that rapidly-consume energy, while the Bank of America and | |
| 46 | -Weather Channel apps consume energy slowly. Differences between apps in | |
| 47 | -similar categories may begin to identify apps with problematic energy | |
| 48 | -consumption, such as contrasting the high energy usage of Facebook Messenger | |
| 49 | -with the low usage of WhatsApp, Twitter, Android Messaging, and even Skype. | |
| 50 | - | |
| 51 | -\subsection{Foreground Energy Efficiency} | |
| 52 | - | |
| 53 | -\input{./figures/tables/tableFOREGROUND.tex} | |
| 54 | - | |
| 55 | -Consumption rate alone, however, is insufficient to answer important | |
| 56 | -questions about how efficient smartphone apps are. Pandora, for example, may | |
| 57 | -consume a great deal of energy either because it is poorly written, or | |
| 58 | -because it is delivering a great deal of content. Given the observations | |
| 59 | -about background usage presented earlier, we were interested in using an apps | |
| 60 | -foreground time as a utility metric to compute energy efficiency. In this | |
| 61 | -conceptual framework, smartphone apps deliver utility through screen time | |
| 62 | -with users, and should consume energy in proportion to the amount of time | |
| 63 | -users spend actively interacting with them. | |
| 64 | - | |
| 65 | -\subsection{Content Energy Efficiency} | |
| 66 | - | |
| 67 | -\input{./figures/tables/tableCONTENT.tex} | |
| 68 | - | |
| 69 | -\subsection{Discussion} |
related.tex deleted
| 1 | -\section{Related Work} | |
| 2 | -\label{sec-related} | |
| 3 | -One of the main activities on these mobile devices is \textbf{content | |
| 4 | -consumption}. A large number of applications for mobile devices are | |
| 5 | -content-delivery applications such as browsers, e-book readers, video players, | |
| 6 | -audio players, and photo viewers. Surveys have shown that consuming mobile | |
| 7 | -content such as video, books, news, etc. is the most popular activity among | |
| 8 | -mobile device users~\cite{mobile-content1, mobile-content2}. | |
| 9 | - | |
| 10 | -But high app usage will often translate to high energy consumption and lack of longevity | |
| 11 | -in battery life is reported to be the least satisfying aspect of smartphone ~\cite{battery-complaint1}. | |
| 12 | -Previous work on component-based power modelling~\cite{dong2011, zhang2010, | |
| 13 | -jung2012} has mapped energy consumption to system-components like cpu, wifi chip, screen etc. | |
| 14 | -On the other hand, efforts like Eprof~\cite{pathak2011,pathak2012}, AppScope~\cite{yoon} traces system calls and monitors kernel activities to answer how much energy is consumed in an application level. | |
| 15 | -There has also being an impressive body of work to provide accurate energy measurement techniques | |
| 16 | -like by using either external hardware~\cite{carroll, | |
| 17 | -cignetti} or device-provided, built-in mechanisms such as smart | |
| 18 | -battery interfaces and voltage information~\cite{mansdi, vedge-nsdi13}. | |
| 19 | -But there has been no work as per our knowledge about identifying how much energy is consumed in providing | |
| 20 | -utility to the user. There exists a gap in our understanding what part of energy consumption by an app is | |
| 21 | -necessary to provide useful content to the user and what part of it is lost in inefficiency. |