results.tex
6.48 KB
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
\section{Results}
\label{sec-results}
To examine the potential components of a value measure further, we utilize a
large dataset of energy consumption measurements collected by an IRB-approved
experiment run on the \PhoneLab{} testbed. \PhoneLab{} is a public smartphone
platform testbed located at the University at
Buffalo~\cite{phonelab-sensemine13}. 220~students, faculty, and staff carry
instrumented Android Nexus~5 smartphones and receiv subsidized service in
return for willingness to participate in experiments. \PhoneLab{} provides
access to a representative group of participants balanced between genders and
across a wide variety of age brackets, making our results more
representative.
Understanding fine-grained energy consumption dynamics such as what apps ran
for how long and how much energy each interactive session consumed while
running in the background required more information than Android normally
exposes to apps. In addition, to explore our content deliver metric we also
wanted to capture information about app usage---including foreground and
background time and use of the display and audio interface---that was not
possible to measure on unmodified Android devices.
So to collect our dataset we took advantage of \PhoneLab{}'s ability to
modify the Android platform itself. Our modification augmented the platform
to collect the fine-grained energy consumption and app behavior information
required to understand smartphone energy consumption. We instrumented the
\texttt{SurfaceFlinger} and \texttt{AudioFlinger} Android platform components
to record usage of the screen and audio, and altered the Activity Services
package to record energy consumption at each app transition, allowing energy
consumption by components such as the screen to be accurately attributed to
the foreground app, a feature that Android's internal battery monitoring
component (the Fuel Gauge) lacks. The dataset of 67~GB of compressed log
files represents \num{6806} user days during which \num{1328}~apps were
started \num{277785} times and used for a total of \num{15224} hours of
active use.
At \PhoneLab{} based on the analysis of data collected about foreground and
background energy consumption by applications running on the participants'
smartphones, we tried to formulate design for requirements for an energy
efficiency metric to apply to smartphone apps. First, it must scale with
usage, respecting the differences in baseline consumption between users and
the temporal variation of apps. Second, it must try to avoid targeting top
apps, even if they tend to consume a great deal of energy, as these may not
be apps that users are willing to uninstall. Finally, we use the analysis of
background energy consumption as a hint about where to start, given that
background energy consumption should match foreground usage in most cases.
We tried characterizing app energy consumption in multiple ways: via the
total amount, by consumption rate, and scaled against foreground energy
consumption and a new content-delivery metric we design that incorporates use
of both the display and the audio device. In each case we examine the app
consumption data generated by our usage monitoring study and use each metric
to shed light on app energy consumption.
\subsection{Total Consumption}
\input{./figures/tables/tableTOTAL.tex}
Clearly, ranking apps by total energy consumption over the entire study says
much more about app popularity than it does about anything else.
Table~\ref{table-total} shows the top and bottom energy-consuming apps over
the entire study. As expected, popular apps such as the Android Browser,
Facebook, and the Android Phone component consume the most energy, while the
list of low consumers is dominated by apps with few installs. This table does
serve, however, to identify the popular apps in use by \PhoneLab{}
participants.
\subsection{Consumption Rate}
\input{./figures/tables/tableRATE.tex}
Computing the rate at which apps consume energy by scaling their total energy
usage against the total time they were running, either in the background or
foreground, reveals more information, as shown in Table~\ref{table-rate}, The
results identify Facebook Messenger, Google+, and the Super-Bright LED
Flashlight as apps that rapidly-consume energy, while the Bank of America and
Weather Channel apps consume energy slowly. Differences between apps in
similar categories may begin to identify apps with problematic energy
consumption, such as contrasting the high energy usage of Facebook Messenger
with the low usage of WhatsApp, Twitter, Android Messaging, and even Skype.
\subsection{Foreground Energy Efficiency}
\input{./figures/tables/tableFOREGROUND.tex}
Consumption rate alone, however, is insufficient to answer important
questions about how efficient smartphone apps are. Pandora, for example, may
consume a great deal of energy either because it is poorly written, or
because it is delivering a great deal of content. Given the observations
about background usage presented earlier, we were interested in using an apps
foreground time as a utility metric to compute energy efficiency. In this
conceptual framework, smartphone apps deliver utility through screen time
with users, and should consume energy in proportion to the amount of time
users spend actively interacting with them.
\subsection{Content Energy Efficiency}
\input{./figures/tables/tableCONTENT.tex}
\begin{figure*}[t]
\centering
\includegraphics[width=\textwidth]{./figures/survey.pdf}
\caption{\textbf{Participant responses to energy inefficient app sugestions.} The height of each bar
demonstrates how many of the suggested apps the user is willing to remove for better battery life. }
\label{fig-survey}
\end{figure*}
To evaluate our efficiency metric against usage based metric, we sent out a
survey to our participants asking to answer if they would remove the 3 top
energy inefficient apps suggested by both metrics to improve the battery-life
of the smartphones by choosing one of the three options: yes, may be, no 47
participants responded to the survey. Figure~\ref{fig-survey} shows that our
efficiency metric did not do a better job than the usage based metric. This
negative result points out that our content metric design is too simplistic
to be effective. Only screen time or audio time is not enough to evaluate the
different types of rich content delivered by apps. For example, our metric
cannot distinguish between video content and interactive content. We also
need to be careful about how we assign weight to the multiple components that
consume energy to deliver the content.