GreenBundle: An Empirical Study on the Energy
Impact of Bundled Processing
Shaiful Alam Chowdhury

Abram Hindle

Rick Kazman

Department of Computing Science
University of Alberta
Edmonton, AB, Canada
shaiful@ualberta.ca

Department of Computing Science
University of Alberta
Edmonton, AB, Canada
abram.hindle@ualberta.ca

Information Technology Management
University of Hawaii
Honolulu, HI, USA
kazman@hawaii.edu

Takumi Shuto

Ken Matsui

Yasutaka Kamei

Information Sc. & Electrical Eng.
Kyushu University
Fukuoka, Japan
shuto@posl.ait.kyushu-u.ac.jp

Information Sc. & Electrical Eng.
Kyushu University
Fukuoka, Japanmatsui@posl.ait.kyushu-u.ac.jp

Information Sc. & Electrical Eng.
Kyushu University
Fukuoka, Japankamei@ait.kyushu-u.ac.jp

Abstract—Energy consumption is a concern in the data-centerand at the edge, on mobile devices such as smartphones. Softwarethat consumes too much energy threatens the utility of the enduser’s mobile device. Energy consumption is fundamentally asystemic kind of performance and hence it should be addressedat design time via a software architecture that supports it, rather
than after release, via some form of refactoring. Unfortunately
developers often lack knowledge of what kinds of designs andarchitectures can help address software energy consumption. In
this paper we show that some simple design choices can havesignificant effects on energy consumption. In particular we examine the Model-View-Controller architectural pattern and demonstrate how converting to Model-View-Presenter with bundling can
improve the energy performance of both benchmark systems andreal world applications. We show the relationship between energy
consumption and bundled and delayed view updates: bundling
events in the presenter can often reduce energy consumption by30%.
Index Terms—energy consumption, MVP, MVC, architecture

I. I NTRODUCTION
Energy consumption is an important quality requirement
for mobile devices [1] and for mobile software such asapps [2], [3] that affects availability, battery life, and sales.
Unfortunately, and often, app developers are addressing energy
consumption when it becomes a problem [2], [4], rather thanat design time before coding starts. There is evidence thatdevelopers simply are not trained enough in the topic of energy
consumption at the application level to be able to addressenergy consumption effectively [4], [5]. Also, available optimization tips do not impact energy consumption in real-worldapps, demanding higher-level changes for efficient accesses ofenergy hungry components [6]. Unfortunately, developers havelittle idea about what design choices are even available thatwill affect energy consumption, as well as the consequenceand tradeoffs of those design choices. Yet interest exists as
Manotoas et al. [4] show: “experienced practitioners are often
willing to sacrifice other requirements for reduced energy
usage”. This paper discusses the kinds of design choices

and tradeoffs that architects face, and seeks to illustrate how
we can improve energy consumption of mobile applications(and, indeed, of any application) by relatively small changes
in an architecture. Specifically, we show how a change toModel-View-Presenter (MVP) with “bundling” or “dropping”
strategies can improve the energy performance of apps.
But why focus on mobile? By 2019, the number ofglobal smart-phone users is expected to reach 2.7 billion[7]. Smartphones are essentially portable networked pocket
computers powered by batteries [8]. Smartphone apps range
from email apps to games, to notifications, prompts, reminders,
stock tickers, etc. This wide variety of software and uses isever present as the network bandwidth demands on mobile
networks starts to eclipse PC network bandwidth [9]. Thispressure on functionality and portable computing puts a hugestrain on a mobile device’s battery, which unfortunately has
not seen much technological improvement [10]. If the device’sbattery energy is consumed, the device is typically unusable.
The importance of energy consumption on mobile devices has
immediate consequences: app developers quickly learn that
their apps that use lots of energy suffer in ratings [2] as consumers highly value battery life for their mobile devices [1].
We seek to aid developers in addressing energy consumption
at design time, before runtime. Our concern is that developers
do not have good guidelines or evidence-based models of thecosts and benefits of the design choices they make in thedesign of energy efficient apps. Developers lack knowledge
of architectures, patterns, and tradeoffs that are potentially“green” (energy efficient), or the parameters that can makean architecture “green” at runtime. So in this work, wedemonstrate how the Model-View-Presenter pattern (MVP)can be modified to reduce the event processing overhead ofmodel objects notifying view objects. We discuss how tomodify the presenter of MVP into a proxy that bundles requests or drops redundant requests by delaying notifications—thus avoiding frequent expensive intermediate notifications orcontext switches that update views. Our research questions andcontributions include:
RQ 1: What is the impact of the number of event sourcesand event generation rates on software energy consumption?
RQ 2: Can bundling and dropping events help in savingenergy while varying the numbers of sources and rates?
Contribution 1: We developed a benchmark Android appthat follows the Model-View-Presenter (MVP) architecture tounderstand the impact of bundling and dropping on ModelView-Presenter architecture. We implemented the presenter inthree different forms: no bundling, bundling, and dropping.
The number of event sources and the rate of event generation(i.e., number of events/second) are determined at runtime withuser input. Using the benchmark app, we answer RQ 1 and
RQ 2.
RQ 3: What are the energy impacts of bundling anddropping on real-world applications?
RQ 4: Can bundling and dropping help address users’
feedback without harming apps’ energy consumption?
Contribution 2: We confirm the realism of the findings fromthe benchmarks with four different real-world Android apps toanswer RQ 3 and RQ 4. Because benchmark apps, althoughgood for conducting controlled tests, do not necessarily reflect
real-world scenarios and performance [6].
RQ 5: Why do bundling and dropping save energy?
Contribution 3: We investigate the cause of performancechanges by analyzing resource access patterns (e.g., CPU use)of apps with bundling and dropping to answer RQ 5.
RQ 6: What are the maintainability consequences of implementing bundling and dropping on Android apps?
Contribution 4: We analyze the difficulty of incorporating
bundling/dropping in Android apps, and the consequences ofthese changes on maintainability, to address RQ 6. Decoupling
Level (DL) metric [11] is used for analyzing the maintainability cost of bundling and dropping versions.
We show that a small change to an architecture like MVP
allows for making energy consumption tradeoffs, allowing forenergy-aware decision making during design and maintenancephases. In general, developers can save significant amountof energy by adopting the proposed bundling and dropping
mechanisms—without harming user experience and withoutmaterially affecting the maintenance cost. To support reproducibility and extension, our energy measurements and theopen-source benchmark app are shared publicly [12].
II. BACKGROUND
A. Energy Efficiency is Difficult to Achieve
Power (P ) is the rate of work expressed in watts. Energy(E), expressed in joules, is the total amount of work in agiven time (T ): E = P × T . Energy consumption is linearly
proportional to the run-time of a component, but only when P
is constant. A reduced time T can save energy, but what if the
CPU switches to a higher power consuming state for a reduced
time T ? Without actual energy measurements or estimates,
this is hard to answer. Moreover, CPU access patterns are justone of the many considerations that affect energy consumption

in modern devices [13], [14]. Studies have recommended
energy efficient Java collections [15], [16], energy-efficient
communication protocols [17], [18], locating and finding energy bugs [19]–[22], and building models and tools for energy
estimation [14], [23]–[30]. Despite the increasing amount ofenergy efficiency research, it is often unclear how software
design decisions impact energy consumption [31], and what
tradeoffs developers should be aware of [4], [5].
B. Model-View-Presenter
Model-View-Presenter (MVP) is a form of Model-ViewController (MVC) [32], [33]. MVC often uses a design patternsuch as the observable pattern to ensure synchronization between data in the model, and visual or concrete representationsin the views, while shielding the model from direct manipulation from view objects via a controller. MVC has many
variants. Some have different purposes. One popular variant of
MVC is called active MVC [34], that is typically implemented
with a single process whereby the observer pattern is used
to allow interactions between the model objects and the view
objects. In Active MVC, model objects are observables that
notify observers (views) when their representation or data is
updated. This is done by keeping a list of observers and thennotifying each via a method call that the observable they arewatching has been updated. It is then up to the observer toquery the model objects for the information they need. Thiscan be quite cumbersome as every change can cause a cascadeof observers to react and deal with each change, regardless ofthe granularity or usefulness of the change. Another problem
with this pattern is that it puts the notification and listenerlogic into model objects.
Active MVC is cumbersome and requires many model
objects to keep track of observers. Model-View-Presenter isa variant that uses the observer pattern, but it provides a
proxy (presenter) between the model and the views. The model
objects, when modified, updates the presenter. The presenter
notifies views and provides them with the information theyneed to update. The views do not necessarily need the model
objects as the presenter is in the way, thus isolating the model
objects further from views, while removing the responsibilityof model objects to notify views for updates. The controller
part of MVP is often folded into the presenter object itself.
Using this presenter as a proxy allows one to put delegation
logic into the presenter and keep that logic out of the model
objects. This means that a presenter could, for example, bundle
updates or drop updates that were deemed irrelevant. Bothof these choices could improve the runtime behaviour of an
application. Because of its simplicity, the MVP pattern has
been recommended in several developers’ blogs and discussions [35]–[37]. Our approach, however, can also be adopted
with other architectures besides MVP.
C. Events, Bundling and Dropping Presenters
An event can be a database update request, a packet transmission request, a view update request and so on. Bundling is
the act of storing and queuing incoming events such that theyFig. 1: UML class diagram of the benchmark app.
can be processed together, even periodically. Dropping is theact of keeping only the last incoming event to be processed—
periodically, or on demand, it processes only the most recent
event. A bundling presenter stores incoming events and send
them later in a single batch for processing them together. On
the other hand, a dropping presenter discards previous eventsand processes only the most recent one. Bundling is applicablewhen a delay in processing is acceptable, whereas dropping isrelevant when, along with the delay tolerance, the most recent
event nullifies the importance of previous events.
Bundling has been found energy efficient in earlier studies.
Pathak et al. [38] proposed I/O bundling for reducing tailenergy leaks in mobile apps. The authors found that somehardware components, such as the network interface card or
SDCard, suffer from the tail energy phenomenon. Tail energy
is the wasted energy by a component while transitioning
from the active to the inactive state. Bundling operations thatinvolve such hardware devices reduces the tail energy phases
significantly, and thus save software energy consumption. For
the same reason, Chowdhury et al. [39] found that writing log
messages in batches can reduce energy consumption. Other
research found that HTTP/2 servers can reduce clients’ energy
consumption by enabling a form of bundling, compared to the
HTTP/1.1 servers [18]. Lyu et al. [40] has shown that energy
efficiency can be significantly improved by grouping multiple
database auto-commit transactions into a single transaction.
In this paper, however, we focus on modifying an existingarchitectural pattern (MVP) with dropping and bundling. We
show that by adopting this modified architecture one can gain
the maintainability and architectural benefits of MVP. Yet
developers may still decide how to balance event-based energy
consumption against other qualities such as latency.
III. M ETHODOLOGYThis section describes the benchmark app we developed
for our experimentation, along with our energy measurement
process and test scripts for driving the subject apps.
A. The Benchmark App
This app has three major components including Model,
View, and Presenter in compliance with the MVP pattern.
Figure 1 illustrates the benchmark app with a class diagram.

The benchmark app, with an UI, allows a tester to choose a
configuration of parameters to test. For example, the numberof emitters (i.e., event sources), event generation rate, test
run duration, and the version of the presenter—no bundling,bundling, or dropping—can be selected at run time. For
bundling and dropping, a delay parameter is also provided,
i.e., how long the app should wait for collecting the incoming
events before processing all the saved events in a single batch?
This UI, with a button click, can then spawn a new experimentrunning on a thread separate from the UI thread [41]. The newexperiment will have emitters and views of emitters’ emissions
instantiated.
1) Model: The model is a collection of emitters objects(i.e., event sources) based on the user’s input. The model is
responsible for dealing with the emitters and forwarding theiremissions to the presenter. The model has a registerObserver
method which can add any number of presenters that canbe interested in an update from this model. However, forsimplicity, we used only one presenter in our experiments.
The model is an observable from the Observer pattern. The
model component uses four different sub-components: Emitter,
Emission, Distribution, and EmitterQueue.
a) Emitter: An emitter is an event source that emits
events at a given rate (i.e., number of events/second). Eachemitter creates emission objects that contain all the data of
the next scheduled transmission from that emitter. The emitteris also responsible to notify the model about emissions, sothat the model can notify the interested presenter. Emitters
are meant to simulate event sources like stock prices, weather
information, or sensor output.
b) Emission: An emission is an event that contains
some data, usually a message. These messages are randomly
generated and timestamped.
c) Distribution: Each emitter produces emissions following a probability distribution function (PDF) for scheduling the next emission. The benchmark app is designed toaccommodate any PDF at run-time. For simplicity and low
variability in our energy measurements, we used only the
uniform distribution.
d) EmitterQueue: The EmitterQueue uses a priority
queue (Java’s PriorityQueue) to schedule emitters for emitting
and transmitting the next emissions. The priority queue enacts
an efficient algorithm for scheduling the emitter. The EmitterQueue sorts all the emitters based on their next waiting time.
The model then removes the first emitter from the priority
queue, finishes its transmission, and then insert it again basedon its next scheduled emission time. This process continues
until the test run duration expires.
2) Presenter: The presenter is an observer of the modelcomponent. It is notified whenever one of the model’s emitterstransmits. The presenter maintains a mapping of emitters andviews, which the presenter uses to notify the view of thecorresponding emitter with the emission. There are 3 kindsof presenter used in both the benchmark App and the study: i)
No bundling—forwards the update immediately; ii) Bundling:
waits for the given bundling time, saves all the incoming

B. Energy Measurements and Test Scripts
We used two implementations, to verify the generalizabilityof our proposed approach, of the GreenMiner [42] softwareenergy measurement platform to measure the energy consumption and resource usage of the apps used in this paper. The
GreenMiner’s tests and measurements can be accessed remotely, and GreenMiner has been used extensively in a variety
of software engineering energy consumption research [15],[18], [30], [42]–[47].
The system under test is typically an Android smartphone.
Energy is measured using current sensor INA219 and INA159
chipsets that report to an Arduino Uno microcontroller. The
microcontroller processes and aggregates measurements, sending to the test computer—a Raspberry Pi model B computer.
The current sensors and the Pi are connected to the phones
under test. The first GreenMiner is connected to 4 Galaxy
Nexus phones (system-under-test) running Android 4.4.1 withan INA219, while the GreenMiner-2 is connected to an ASUS
ZenFone 2 running Android 5.0.2 with an INA159. For agiven app and test, the Pi acts as the test-runner which pushes,
runs, and collects measurements for a given test script. The
first GreenMiner system has four identical settings with four
Galaxy Nexus phones. Running different tests in parallel helps
accelerate the measurement process. GreeMiner-2 has only 1
ASUS Zenphone 2. GreenMiner test framework cleans any
previously installed apps before running a new test. This is toensure the same system state for each test; energy consumptionof a particular test is therefore unaffected by previous tests.
We ran the real-world app tests on the GreenMiner andGreenMiner-2; the benchmark app was tested solely on the

Benchmark App

1
2
4
8
16
32
64
128

55
50
45

Energy (J)updates, and forwards each of them all together; iii) Dropping:same as the bundling except the presenter forwards only themost recent update and discards all the previous updates.
The presenter runs in a separate thread than the UI thread.
When the presenter receives an update, it decides which view
to notify and passes off the necessary information to the viewin the view’s thread—such as the UI thread if the view has
a UI. The bundling presenter, for example, sleeps inside atimer thread and stores the incoming events in parallel. It thenforward all the stored events to the interested views once thesleeping time is over (i.e., the bundling time provided by theuser). The dropping presenter is identical except it discards
previous events and only forwards the most recent one. To help
practitioners for implementing bundling/dropping presenters,
we made the benchmark app public and open-source [12].
3) View: Views are meant to receive updates from thepresenter. What they do with the update is up to them, but
typically they only talk to the presenter and updates themwith the emission objects they receive. They are observersof the presenter but might be associated with a particular
object. For simplicity, the benchmark app maintains a one-toone relationship between the emitters and view components—
a single view, a textfield, is interested in a single emitter. A
view in the benchmark app is thus responsible to display thereceived emission data from a emitter through the presenter.

40
35

Number of emitters

30
25
20
1

2

4

8

16

32

64

Event generation rate (events/second)

128

Fig. 2: Energy consumption of the benchmark app withdifferent numbers of emitters and event generation rates. Bars
indicate the 99% confidence interval.
GreenMiner to simplify comparison of parameters and energy
consumption.
Previous GreenMiner based works [15], [18], [30], [44],[46] recommended running the same test multiple times, forthe observed variability in energy consumption. We ran all
versions of our subject apps (benchmark and real world apps)
10 times. To minimize outlier effects, we show the 99% confidence interval of our measurement distribution. In addition,
whenever necessary, we used the Kruskal-Wallis test [48] toverify if two energy measurement distributions are statisticallydifferent. The advantage of Kruskal-Wallis test is that it does
not assume any distribution of the data as it is non-parametric.
To measure the energy consumption of an app, we need to
run the app multiple times, which is infeasible with manual
testing. We used the Android’s adb shell [49] script for
writing the test cases. For the benchmark app, writing thetest script was straightforward. The script selects the numberof emitters, the presenter type, the bundling time in case ofbundling and dropping, and provides the test duration andevent generation rate before clicking the start button. For the
real-world apps, however, the tests were written with two of
the authors’ consensus that these tests represent an averageuser’s interaction with these apps.
IV. R ESULTS : B ENCHMARK APP
In this section, we show the energy consumption of thedifferent versions of the benchmark app with different settings.
To select the number of emitters, and event generation rate,
we use powers of 2: 1, 2, 4, 8, 16, 32, 64, and 128. This large
range is able to show the big picture: the impact on energy
consumption with the increase in the number of emitters andevent generation rate. All versions (at all settings) of thebenchmark app were run for a fixed period of 20 seconds,
repeating 10 times each.
RQ 1: What is the impact of the number of event
sources and event generation rates on software energy
consumption? Figure 2 shows the energy consumption of

the benchmark app with different numbers of emitters (i.e.,
event sources) and event generation rates. Clearly, the energy consumption goes up when we increase the number of
emitters and/or the event rate. The Spearman [50] correlation
coefficient is 0.66 (p ≈ 0) between the number of emittersand energy consumption in joules. The coefficient is 0.69
(p ≈ 0) between the event rates and energy consumption.
The coefficient would have been higher if the phones wereable to process high numbers of events and emitters. The
variations in energy measurements among multiple runs foreach setting are small; Figure 2 shows that the 99% confidence
intervals are not noticeable until the performance is saturated.
This is because we kept the benchmark app as simple anddeterministic as possible, which is harder to control in realworld apps. We also observe that for high number of emitters(i.e., ≥32 emitters) the energy consumption does not changewith the increase in the event rate after a threshold. Thisis because of the limited capacities of the phones we used
for our measurements; these phones can process a certain
number of events within the allotted 20 seconds test duration.
Producing more events than this threshold does not impact
the energy consumption, for the phone can not process theextra events within the allotted time. In fact, with the KruskalWallis test, we found statistical differences between the energy
measurements until the numbers of emitters and rates are high.
For example, with 8 emitters, α = 0.05, p = 0.0001 between
32 events/sec and 64 events/sec. However, for α = 0.05, p is
statistically insignificant (0.6242) between 64 events/sec and
128 events/sec when the number of emitters is fixed to 64.
Table I shows the percent increase in energy consumption
in the number of emitters and event generation rates comparedagainst the energy consumption of one emitter with one event
per second. For example, even with a single emitter, the energy
consumption can go up 38% when the event generation rate
is high (128 events/second). And note that the percentage
increase with high numbers of emitters and rates would havebeen much higher than the reported values if the phones wereto able processing more events.
Findings: Many modern applications deal with large numbers of event sources with high numbers of incoming
events [51]–[53]. Our results show that energy consumption
is correlated with both the number of event producers andthe rate of event production.
RQ 2: Can bundling and dropping events help in savingenergy while varying the numbers of sources and rates?
To answer this question, we considered three different waitingtimes for both bundling and dropping: 0.1 second—the corneal
reflex time of human eyes; 0.5 second—half of user-acceptablelatency; and 1 second—the broadly used acceptable latency
target for interactive applications [54]. Unlike the real-world
apps presented later, a wider range of waiting times were notconsidered for the benchmark app so the graphs are readable.
Figure 3 shows the energy savings of different bundlingand dropping rates compared with no bundling or dropping(presented as Nobundling in the figures). Each graph shows

TABLE I: Percent increase of energy consumption comparedwith the energy consumption of 1 emitter and 1 event/second.
For readability, nearest integer values are presented.
Emitters
1
2
4
8
16
32
64
128

1
0
2
5
8
14
22
26
30

2
2
4
8
13
23
33
36
42

Rates
8
16
6
12
12
22
22
33
33
40
41
47
47
53
53
54
54
54

4
4
7
13
22
33
41
45
51

32
22
33
40
46
53
55
54
54

64
32
39
44
51
55
56
55
54

128
38
43
49
55
56
56
54
54

TABLE II: Energy savings (in percent) by different bundlers
and droppers when compared with no bundling or dropping.
Results are presented for just one emitter.
Versions
Bundling-0.1s
Dropping-0.1s
Bundling-0.5s
Dropping-0.5s
Bundling-1s
Dropping-1s

1
0
0
0
0
0
0

2
0
0
0
0
1
1

4
0
0
2
2
4
4

8
0
0
3
3
5
5

Rates
16
3
4
8
9
10
11

32
13
14
18
19
19
20

64
22
25
27
29
29
31

128
25
30
30
34
31
36

the results for all the possible scenarios for a fixed numberof emitters. Except for very high numbers of emitters or
rates, the energy consumption goes up monotonically for the
Nobundling version. While this trend is true for the bundlingversions as well, for the dropping versions we do not see
such clear trends. This is because the number of events
processed by a dropping version (transferring events from thepresenter to the views) is to some extent independent of thenumber of events generated. The small energy increase forthe dropping versions with increased rates is due to the costof producing more events by the model component in ourbenchmark app. Not surprisingly, dropping is more energy
efficient than bundling; the dropping versions process fewer
events than the bundling versions. The bundling versions, inspite of processing the same number of events as the nobundling version, can save significant energy.
It is encouraging that, with bundling, we can process anddeal with the same amount of workload, and yet can makeapps significantly more energy efficient. Table II shows theenergy savings by different bundlers and droppers with fixed
one emitter. This is to ensure that the energy consumption
is not affected by resource limitations, thus enabling accuratecomparison. It shows that with bundling (doing all the workwithout dropping anything) and maintaining a latency suchthat a user does not notice any change (0.1 second), we canstill save up to 25% of the energy (Bundling-0.1s). With useracceptable latency (Bundling-1s), bundling can save up to 31%
in a simple app like our benchmark, with just one event source.
We verified with the Kruskal-Wallis test that these differences
are indeed statistically significant (with α = 0.05, p ≤ 0.01).

26
24
22
1

4 8 16 32 64 128
Rate (events/second)

Number of emitters = 8

45

Nobundling
Bundling-0.1s
Bundling-0.5s
Bundling-1s
Dropping-0.1s
Dropping-0.5s
Dropping-1s

40Energy (J)

2

35
30
25
20

45
40
35

Number of emitters = 4

40

Nobundling
Bundling-0.1s
Bundling-0.5s
Bundling-1s
Dropping-0.1s
Dropping-0.5s
Dropping-1s

35
30
25

1

2

20

4 8 16 32 64 128
Rate (events/second)

Number of emitters = 16

Energy (J)20

Number of emitters = 2

Nobundling
Bundling-0.1s
Bundling-0.5s
Bundling-1s
Dropping-0.1s
Dropping-0.5s
Dropping-1s

Energy (J)

28

36
34
32
30
28
26
24
22
20

Nobundling
Bundling-0.1s
Bundling-0.5s
Bundling-1s
Dropping-0.1s
Dropping-0.5s
Dropping-1s

3025Energy (J)Energy (J)30

Energy (J)Number of emitters = 1

Nobundling
Bundling-0.1s
Bundling-0.5s
Bundling-1s
Dropping-0.1s
Dropping-0.5s
Dropping-1s

32

60
55
50
45
40
35
30
25
20

1

2

4 8 16 32 64 128
Rate (events/second)

Number of emitters = 32

Nobundling
Bundling-0.1s
Bundling-0.5s
Bundling-1s
Dropping-0.1s
Dropping-0.5s
Dropping-1s

20 1 2 4 8 16 32 64 128
4 8 16 32 64 128
1 2 4 8 16 32 64 128
Rate (events/second)Rate (events/second)Rate (events/second)Fig. 3: Energy consumption of bundling and dropping compared with the Nobundling versions for different number of emitters.
Results for more than 32 emitters are not presented; due to resource limitations, the energy consumption is inconsistent forvery high numbers of emitters and rates. Bars indicate the 99% confidence interval.
1

2

Findings: Dropping is the most energy efficient approachcompared to bundling and no bundling. However, dropping
might not be an acceptable alternative when accuracy isimportant. Application developers can consider bundlingin such scenarios, which still saves significant energy overno bundling.
V. R EAL WORLD A PPSResults from the benchmark app shows that bundling anddropping can save significant energy in Android apps. And
this saving is larger with increased numbers of event sources
or event generation rates. It is, however, not obvious how such
optimization approaches would perform in real-world apps [6].
In this section, we evaluate bundling and dropping in four
selected real-world Android apps.
A. Selection of Applications
The apps we selected had to be open source so that we
can implement bundling and dropping. We explored the FDroid repository [59] to find suitable apps. F-Droid contains
source code for all the posted Android apps and was usedin earlier mining software repositories research [60]–[62].
Finding suitable apps with reasonably small code size (so that
we could easily identify where to implement bundling anddropping) was challenging, which hindered us from analyzing
more apps. Table III shows the characteristics of the four
selected apps.
The different types and code sizes of these four apps enables
reliable evaluation of bundling and dropping. The Sensor
Readout app is also available on Google Play [63] and has

been downloaded more than 50,000 times (as of writing). Thisapp has received 540 reviews with an average rating of 4.3/5.
This allows evaluating energy optimization techniques for appsthat are already popular. AcrylicPaint, a finger painting app,represents apps where users might spend more continuous
time, making energy optimization more crucial.
We have implemented the bundling and dropping versions ofthese apps, except for Sensor Readout, following the approachpresented in section III-A2. The original Sensor Readout app,uses a timer function, and processes only 10 measurements per
second, although the app samples measurements continuously.
As a result, we did not have to implement our own timer forthe bundling and dropping variants. The apps, however, did
not follow a clear MVP pattern. Instead, their designs werecloser to the MVC pattern. We have identified which classes
contained the actual processing code, and refactored thoseclasses to accommodate our bundling/dropping presenters. Our
intention was to convert the existing design as close to thebundling MVP pattern as possible. For ensuring correctness,
two of the authors were involved in refactoring and testing theapps afterwards.
B. RQ 3: What are the energy impacts of bundling anddropping on real-world applications?
The energy savings from bundling and dropping are ofcourse impacted by the bundling/dropping time—the timethese two variants wait before processing a batch of events.
We selected six different times: 0.01s—fastest human timeperception; 0.03s—animation speed; 0.1s—the corneal reflex
time of human eyes; 0.2s—double the corneal reflex time;
0.5s—half of user-acceptable latency; 1 second—acceptable

TABLE III: Description of the selected four real-world Android apps from F-droid.
App
Sensor Readout [55]ColorPicker [56]Angulo [57]
AcrylicPaint [58]# Classes
56
12
4
7

acrylicPaintOriginal
acrylicPaintBundlingacrylicPaintDropping
acrylicPaintOriginal-GM2
acrylicPaintBundling-GM2
acrylicPaintDropping-GM2

16
14
12
10

Energy (J)AcrylicPaint App

18

Energy (J)Type“Real-time graphs of sensor data”“Pick colors and display values”“Angle and Distance Measuring”“Simple finger painting”

8
6

55
50
45
40
35
30
25
20
15

30 100 200 500 1000 2000
Bundling/Dropping Time (ms)Test scenario
Measure the Gyroscope sensor
Move the scroll bars for R,G,B
Start the measurements and wait
Draw a hexagon

Test
duration (s)
70
50
55
27

ColorPicker App

colorPickerOriginalcolorPickerBundlingcolorPickerDroppingcolorPickerOriginal-GM2
colorPickerBundling-GM2
colorPickerDropping-GM2

10

Angulo App

anguloOriginal
anguloBundlinganguloDropping
anguloOriginal-GM2
anguloBundling-GM2
anguloDropping-GM2

30 100 200 500 1000 2000
Bundling/Dropping Time (ms)SensorReadout App

sensorOriginal
sensorBundlingsensorDropping
sensorOriginal-GM2
sensorBundling-GM2
sensorDropping-GM2

120
100
Energy (J)Energy (J)

10

110
100
90
80
70
60
50
40

ULOC
6009
908
497
936

80
60
40

10

30 100 200 500 1000 2000
Bundling/Dropping Time (ms)10

30 100 200 500 1000 2000
Bundling/Dropping Time (ms)Fig. 4: Energy consumption of bundling and dropping compared with the original versions of four real-world apps. Bars
indicate the 99% confidence interval.
user latency [54]; and 2 seconds—double user-acceptablelatency. Figure 4 shows the energy consumption of bundlingand dropping compared with the original versions of thefour selected apps. Here, we also show the results for theGreenMiner-2 (GM2) on the Asus Zenphone 2.
Except for the Sensor Readout app, we observe moreenergy consumption for the bundling and dropping versions
for very low bundling and dropping times (e.g., 0.01s). Thissuggests that running a timer thread for bundling or dropping
incurs energy consumption overhead. As we mentioned before,
Sensor Readout did not require a separate timer thread anddoes not have this overhead when bundling or dropping isused. For all the apps, however, the energy consumptionof bundling and dropping improve significantly when thewaiting time is reasonably higher. For example, even for 0.1s
latency which is difficult for users to perceive, the bundlingand dropping versions of AcrylicPaint and Angulo can save
12% (12% with GM-2) and 9% (8% with GM-2) energy
consumption respectively, when compared with their original

versions. The energy savings become significant for larger
latency. For example, we can save 37% (24% with GM-2)
energy consumption for the Sensor Readout app with a 1s
latency in drawing the measurements graphs, and that without
losing any measurements (i.e., with bundling).
GreenMiner-2 (with the ASUS ZenFone 2 phone) consumes
less energy than the GreenMiner (with the Galaxy Nexus
phone) for all apps, and thus the energy savings are generally
lower. The trends in percent of energy consumption reductions,however, are similar across the apps for both the GreenMiners.
C. RQ 4: Can bundling and dropping help address users’
feedback without harming apps’ energy consumption?
Answering this question might require analysis from multiple perspectives. However, with one case study, we showthat there are scenarios where the developers can adopt ourbundling approach to address user feedback that involves
energy expensive modifications. For this study, we selected theSensor Readout app—the only app available on Google Play

SensorReadout App

100

Energy (J)

90
80
70
60
50
5

10

sensorOriginal
sensorBundling-0.1s
sensorDropping-0.1s
2030# of Measurements/second

Fig. 5: Energy savings of bundling/dropping for the Sensor app
with higher sampling rates. Bundling/dropping time is fixed to
0.1 second. Bars indicate the 99% confidence interval.
with a significant number of reviews. For a selected sensor
type, this app shows/updates 10 measurements per second.
In general, this app is praised by users. However, somereviews indicate user dissatisfaction. For example, one user desires to see colour changes with different measurements while
updating graphs [55]. Another user is unsure why the sampling
rates from the sensors are low—10 samples per second.
Changing colors continuously and sampling at higher rates
might increase the energy consumption of the app significantly.
And yet, developers need to carefully address user feedback
for their apps to stay popular [64]. In fact, there are reviews on
the Sensor Readout app suggesting similar apps are supposedly
better than Sensor Readout. We show that Sensor Readout
can benefit by applying bundling—by sampling measurements
faster for timeline graphs, but delaying graphical updates by
only 0.1 second without harming latency (more measuresments
per second but constant UI update rate).
Figure 5 shows the energy consumption of the original
version compared with the bundling and dropping versions,with different sampling rates. The bundling/dropping time (i.e.,
the latency in updating the graphs) is fixed to 0.1s. The averageenergy consumption of the original version is high (≈94
joules) when the sampling rate is 20/second compared withthe original 10/second (≈69 joules); a 36% increase in energy
consumption. The difference is also statistically significant(Kruskal-Wallis test, α = 0.05, p < 0.01). However, bundlingwith 20 samples/second consumes similar energy to the original version with just 10 samples/second. With sampling rate
higher than 20, the energy consumption of the phones does notincrease as expected. The Galaxy Nexus phones are unable toprocess more than a threshold number of samples.
Findings: Real-world Android apps can save significant
energy with bundling and dropping. Sacrifices in latency
correlate with the energy savings. Bundling with almost
imperceptible latency (0.1s) can save energy without affecting user satisfaction. In some scenarios, bundling anddropping can help developers address users’ concerns withno meaningful sacrifice in usability.

VI. U NDERSTANDING R ESOURCE U TILIZATION PATTERNSW ITH B UNDLING AND D ROPPING
It is unsurprising that dropping saves energy; in dropping thepresenter only sends the most recent event for processing. Thisrequires less CPU slots for the process (also known as CPU
jiffies [30]). Bundling, however, does the exact same amountof work as on-time processing. Thus the question arises: whydoes bundling save energy in spite of processing all the events?
Assumption: A CPU jiffy is an assigned CPU time slot
for a process in Linux [30], [46]. More CPU jiffies for aprocess causes more CPU jiffies for the kernel, because of
more context switches between the user space and the kernel
space. In on-time event processing system, each event requires
at least one user CPU jiffy. This incurs at least one context
switch and one kernel CPU jiffy. This effect, however, canbe minimized with bundled processing. Batching of events
minimizes the number of context switches and the number of
CPU jiffies. If our assumption is correct, the energy efficiencyof bundling is explainable. The number of CPU jiffies andcontext switches are almost linearly correlated with softwareenergy consumption [30].
A. RQ 5: Why do bundling and dropping save energy?
To verify the above assumption, we have analyzed the
AcrylicPaint app. Similar to Chowdhury et al. [30], we usedthe Linux proc file system. To capture the CPU jiffies used by
an app, we used /proc/pid/stat. This also includes thekernel CPU jiffies used for that app. However, app (process)specific context switches can not be captured using such a filesystem. We captured the number of context switches from/proc/stat before and after running a test for an app.
The difference is thus approximately the number of context
switches for the app.
Figure 6 shows the result (10 measurements for each configuration). The number of CPU jiffies and context switches
follow a similar pattern to the energy consumption of the
AcrylicPaint’s versions (Figure 4). This observation suggeststhat our assumption is true: bundling indeed reduces thenumber of CPU jiffies and context switches. This also indicatesthat bundling and dropping enable efficient resource usage,
and thus can potentially provide similar energy savings forplatforms other than Android. The mechanisms of context
switches between the kernel and user space are similar acrossdifferent platforms and architectures.
Findings: Bundling and dropping access resources in efficient ways—reducing the need for many context switches,leading to energy efficient software. This observation suggests that the energy efficiency of bundling and dropping
is not restricted to Android systems, but also is applicablein other platforms.
VII. M AINTAINABILITY A NALYSIS
Developers and architects need to be concerned with themaintainability consequences of changes made to enhance
any single aspect of a system’s quality. Thus it is important

AcrylicPaint App

acrylicPaintOriginal
acrylicPaintBundlingacrylicPaintDropping

260
240
220
200
180
160

10

30 100 200 500 1000 2000
Bundling/Dropping Time (ms)AcrylicPaint App

55000

Number of Context Switches

Number of CPU Jiffies

280

acrylicPaintOriginal
acrylicPaintBundlingacrylicPaintDropping

50000
45000
40000
35000
30000

10

30 100 200 500 1000 2000
Bundling/Dropping Time (ms)Fig. 6: Numbers of CPU jiffies and context switches for bundling and dropping compared with the original AcrylicPaint app.
Bars indicate the 99% confidence interval.
TABLE IV: DL values for before/after versions of each app
to understand the consequences of the changes made to the (bundling only).
apps to implement the bundling or dropping strategies. ThisAppDL Score DL Score DL ∆motivates our sixth and final research question.
Original
Bundling
RQ 6: What are the maintainability consequences ofAngulo68%
69%+1%
implementing bundling and dropping on Android apps?
ColorPicker
17%
17%
+0%
AcrylicPaint
88%
82%
-6%
To assess these consequences we analyzed the before andSensorReadout
32%
30%-2%
after versions of the four selected real-world apps. We firstreverse-engineered each of the apps using the Understand tool[65]. Using this tool we were able to collect code metrics
are shown in Table IV. While the values of the DL metricon all versions of the apps. (For the purposes of brevity wevaried widely (indicating the inherent maintainability of the
only report on the original and bundling versions of the apps
apps prior to our intervention) the changes for the apps due
here. Results for the dropping versions were very similar.) In
to the addition of bundling were small. The observed drops ineach case the modifications to the apps were slight in terms of
DL scores were due to new relationships between classes thateffort, requiring fewer than 100 additional lines of code and at
the bundling and dropping functionality required. But since themost three new classes (including one Handler class and one
DL scores do not change dramatically (decreasing about 6%
Thread class that runs the timer). But counting the lines offor AcrylicPaint, increasing 1% for Angulo, and staying thecode and classes is just the measure of the required effort forsame for ColorPicker), this indicates that the tradeoffs madeconverting a typical app version to a bundled version. Anotherfor energy efficiency were generally good ones—improving
important question is whether these changes affected the longthe energy efficiency of the apps while sacrificing little, if any,term maintainability of the system. If, for example, we added
maintainability of the apps for the long term. In fact, in [11],few lines of code but added many new dependencies between
it was noted that small variations in DL (≤ 10%) are typicallyclasses, this would increase coupling in the system, negatively
not meaningful.
affect the maintainability of the app going forward.
Findings: Energy efficiency is largely ignored during softTo determine whether this was the case we analyzed theware maintenance [4]. One reason could be the difficulty incoupling of the apps, in their before and after versions,fixing energy bugs [68]. Bundling and dropping, however,using the Decoupling Level (DL) metric [11], a system-wide
are easy to implement and maintain.
measure of coupling. The DL metric has been empirically validated [11] and shown to be more reliable than other coupling
VIII. T HREATS TO VALIDITY
metrics such as Propagation-Cost [66] and IndependenceLevel [67] in predicting maintenance effort. DL scores range
External validity is hampered by the single version of thefrom 0 to 100, and the higher the number the better, as this Android OS that we used on four Galaxy Nexus phones.
indicates that the system’s files are more highly decoupled Also, we do not know how many real-world apps can directly
and hence can be independently modified. The purpose of take advantage of the proposed bundling approach. The firstusing this metric is to determine if the changes made to threat is mitigated somewhat by using the GreenMiner-2 withaddress energy efficiency significantly lowered the value of a different phone (Zenphone 2). To mitigate the second threat,
the DL metric. If so, this would mean that the maintainability we tried to select apps from different domains, and withof the system was negatively impacted by the energy-saving the context-switching analysis we explained why bundling is
modifications.
energy efficient. This might help predicting what other types
The DL values of the before and after versions of four apps of apps can adopt GreenBundling.

Internal validity can be criticized for the way we calculated
the number of context switches. Unlike the CPU jiffies,
process-specific context switches are inaccessible using theprocfs file system. The difference between after and before
when running a process can be affected by other processes(e.g., garbage collection).
The Kruskal-Wallis test, although it does not assume any
normality distribution about the data, still assumes that datain each group has similar skewness [69]. These threats areminimized by measuring each configuration 10 times andthen showing the means, and confidence intervals. Constructand conclusion validity may also be questioned based on thetests scripts that we created for the real-world apps. It is
not guaranteed that typical users of these apps would interact
similar to the way our test scripts do. However, our test scripts
exercise the main functionality of these apps: e.g., drawing
measurement graphs and objects with the Sensor Readout app
and the AcrylicPaint app respectively.
IX. R ELATED W ORK
In recent years, developers have expressed more concerns
about software energy consumption [70]. The software research community has been investigating several areas of thisissue. Hasan et al. [15], Pereira et al. [16], and Manotas etal. [71] have presented recommendations for selecting energy
efficient Java collections. Energy efficient color transformationin Android apps was proposed by Li et al. [13] and Agolli etal. [72]. Off-loading jobs [73], pre-fetching content [74], andenabling ad-blockers [43] have been found to save energy insome cases. Chowdhury et al. [18] suggested that HTTP/2
servers are more energy efficient, from the clients’ perspective,
than HTTP/1.1 servers. Energy efficient logging techniquesfor Android systems [39] have also been studied.
Other research has shown correcting code smells helps
to improve energy efficiency [75]. In a similar vein, theimpact of code obfuscation and refactoring on software energy
consumption was studied by Sahin et al. [76], [77]. The energychange from code obfuscation is too small to notice, whereas
refactoring can impact both positively and negatively.
Developers need to measure or estimate their apps’ energy
consumption. Hao et al. [23] proposed an instruction-basedenergy estimation model. Machine learning based models were
proposed by Aggarwal et al. (GreenAdvisor [44]), Chowdhury
et al. (GreenOracle [46] and GreenScaler [30]), and Pathak et
al. [78]. Nucci et al. proposed PETrA [24] to estimate Android
apps’ energy consumption leveraging various Android tools.
Locating software energy bugs and hotspots automatically isanother important research area. Wakelock-related energy bugs
have been frequently reported by earlier studies [19]–[22].
Developers need to exploit tools and techniques to locate andsolve such bugs [21]. Similar to the energy bugs, developers
should also resolve energy hotspots [10]. Jabbarvand et al. [79]proposed a test-suite minimization approach focusing only
on locating energy bugs. In their later work, the authors

proposed an energy-specific mutation testing framework withhigh precision in detecting energy bugs [80].
This paper, however, focuses more on high-level design
choices that can help developers writing energy efficient systems. To the best of our knowledge, this is the least exploredarea of software energy efficiency, and there is still a needfor more research on this avenue. The closest to our workis the short study by Sahin et al. [31], where the authors
investigated different existing design patterns and their energy
consumption. In contrast to our work, that study lacks proper
guidelines and cost analysis for making a design choice.
X. C ONCLUSION & F UTURE W ORK
In this work we showed that an architectural choice, suchas choosing a bundled MVP architecture, can improve thesustainability and energy consumption of a system without
negatively impacting system maintainability. The consequenceof this research means that architects and developers can (andshould) make design decisions to address energy consumption
before they start coding.
We have demonstrated the value of a bundled presenter in
MVP by first benchmarking a generic MVP architecture andthen by demonstrating that the energy improvements demonstrated in the benchmark were in fact realized on real-world
apps that were refactored into bundled MVP architectures from
more classical MVC architectures. A significant reduction ofenergy consumption can in fact be achieved. Furthermore weshowed that these modified apps did not seriously affect theuser experience, nor did the refactored versions suffer in termsof their eventual maintainability. Thus, the energy-savings that
we achieved were truly win-win.
Our final message is this: fundamental architectural choices,such as the ones we have investigated in this paper, canhave substantial effects on energy consumption. Although
we demonstrated our results on MVP-based architectures, it
is our hope and belief that developers and researchers canuse this study to motivate similar studies, allowing them toaddress questions of energy consumption, and their consequent
tradeoffs, at design time. We do not need to wait until the app
is built to make these important design choices. In our future
work, we want to evaluate the proposed bundling architectureson other smartphones than Android, and with real end-users
for evaluating actual usability. We also want to evaluate
other architectural patterns and architectural choices so thatarchitects can predictably translate sustainability requirements
into designs and into working systems.
ACKNOWLEDGMENTS
Shaiful Chowdhury was supported by the Alberta-Innovates
Technology Future PhD Scholarship. Dr. Hindle is supported
by an NSERC Discovery Grant. Dr. Kazman was supported
by U.S. National Science Foundation grant number 1514561.
This research was also partially supported by JSPS KAKENHI
Grant Numbers JP15H05306 and JP18H03222 and an ”JSPS
Invitational Fellowship”.

R EFERENCES[1] V. Woollaston, “customers really want better battery life,” http://
www.dailymail.co.uk/sciencetech/article-2715860/, 2014, (last accessed:
2018-Jul-22).
[2] C. Wilke, S. Richly, S. Gtz, C. Piechnick, and U. Amann, “Energy
consumption and efficiency in mobile applications: A user feedback
study,” in 2013 IEEE International Conference on Green Computing
and Communications and IEEE Internet of Things and IEEE Cyber,
Physical and Social Computing, Aug 2013, pp. 134–141.
[3] H. Khalid, E. Shihab, M. Nagappan, and A. E. Hassan, “What do mobile
app users complain about?” IEEE Software, vol. 32, no. 3, pp. 70–77,
May 2015.
[4] I. Manotas, C. Bird, R. Zhang, D. Shepherd, C. Jaspan, C. Sadowski,
L. Pollock, and J. Clause, “An empirical study of practitioners’ perspectives on green software engineering,” in Proceedings of the 38th
International Conference on Software Engineering, ser. ICSE ’16, 2016,
pp. 237–248.
[5] C. Pang, A. Hindle, B. Adams, and A. E. Hassan, “What do programmers know about software energy consumption?” IEEE Software,
vol. 33, no. 3, pp. 83–89, May 2016.
[6] C. Sahin, L. Pollock, and J. Clause, “From benchmarks to real apps:
Exploring the energy impacts of performance-directed changes,” Journalof Systems and Software, vol. 117, pp. 307 – 316, 2016.
[7] Statista, “Number of smartphone users worldwide from 2014
to 2020 (in billions),” https://www.statista.com/statistics/330695/
number-of-smartphone-users-worldwide/, (last accessed: 201-Aug-06).
[8] P. Poole, “Half of Us Have Computers in Our Pockets, Though
You’d Hardly Know it,” http://www.huffingtonpost.com/pamela-poole/smartphone-technology b 2573671.html, (last accessed: 2018-Jul-22).
[9] Cisco,“Ciscovisualnetworking
index:
Forecast
andmethodology,
2016-2021,”
https://www.cisco.com/c/en/us/
solutions/collateral/service-provider/visual-networking-index-vni/
complete-white-paper-c11-481360.html, (last accessed: 201-Aug-06).
[10] Banerjee, Abhijeet and Chong, Lee Kee and Chattopadhyay, Sudipta andRoychoudhury, Abhik, “Detecting Energy Bugs and Hotspots in Mobile
Apps,” in FSE 2014, Hong Kong, China, Novemeber 2014, pp. 588–598.
[11] R. Mo, Y. Cai, R. Kazman, L. Xiao, and Q. Feng, “Decoupling level: A
new metric for architectural maintenance complexity,” in Proceedings ofthe 38th International Conference on Software Engineering, ser. ICSE
’16, 2016, pp. 499–510.
[12] “Greenbundle: replication and extension,” https://github.com/shaifulcse/
GreenBundle-Data-Code.
[13] D. Li, A. H. Tran, and W. G. J. Halfond, “Making Web Applications
More Energy Efficient for OLED Smartphones,” in ICSE 2014, Hyderabad, India, June 2014, pp. 527–538.
[14] L. Zhang, B. Tiwana, Z. Qian, Z. Wang, R. P. Dick, Z. M. Mao,and L. Yang, “Accurate Online Power Estimation and Automatic Battery Behavior Based Power Model Generation for Smartphones,” inProceedings of the 8th IEEE/ACM/IFIP International Conference on
Hardware/Software Codesign and System Synthesis, 2010.
[15] S. Hasan, Z. King, M. Hafiz, M. Sayagh, B. Adams, and A. Hindle,“Energy profiles of java collections classes,” in Proceedings of the 38th
International Conference on Software Engineering, ser. ICSE ’16, 2016,
pp. 225–236.
[16] R. Pereira, M. Couto, J. a. Saraiva, J. Cunha, and J. a. P. Fernandes,“The influence of the java collection framework on overall energy
consumption,” in Proceedings of the 5th International Workshop on
Green and Sustainable Software, ser. GREENS ’16, 2016, pp. 15–21.
[17] D. Li, Y. Lyu, J. Gui, and W. G. J. Halfond, “Automated energy
optimization of http requests for mobile applications,” in Proceedings ofthe 38th International Conference on Software Engineering, ser. ICSE
’16, 2016, pp. 249–260.
[18] S. Chowdhury, S. Varun, and A. Hindle, “Client-side Energy Efficiency
of HTTP/2 for Web and Mobile App Developers,” in SANER ’16, Osaka,
Japan, March 2016.
[19] Y. Liu, C. Xu, S. Cheung, and V. Terragni, “Understanding and detecting
wake lock misuses for android applications,” in FSE 2014, Seattle, WA,
USA, Nov 2016.
[20] F. Alam, P. R. Panda, N. Tripathi, N. Sharma, and S. Narayan, “Energy
optimization in android applications through wakelock placement,” in2014 Design, Automation Test in Europe Conference Exhibition (DATE),
March 2014, pp. 1–4.

[21] X. Wang, X. Li, and W. Wen, “Wlcleaner: Reducing energy waste caused
by wakelock bugs at runtime,” in Dependable, Autonomic and Secure
Computing (DASC), 2014 IEEE 12th International Conference on, Aug
2014, pp. 429–434.
[22] P. S. Patil, J. Doshi, and D. Ambawade, “Reducing power consumptionof smart device by proper management of wakelocks,” in Advance
Computing Conference (IACC), 2015 IEEE International, June 2015,
pp. 883–887.
[23] S. Hao, D. Li, W. G. J. Halfond, and R. Govindan, “Estimating Mobile
Application Energy Consumption Using Program Analysis,” in ICSE
’13, 2013, pp. 92–101.
[24] D. D. Nucci, F. Palomba, A. Prota, A. Panichella, A. Zaidman, andA. D. Lucia, “Software-based energy profiling of android apps: Simple,
efficient and reliable?” in 2017 IEEE 24th International Conference on
Software Analysis, Evolution and Reengineering (SANER), Feb 2017,
pp. 103–114.
[25] A. Carroll and G. Heiser, “An Analysis of Power Consumption in a
Smartphone,” in Proceedings of the USENIXATC’10, 2010.
[26] A. Shye, B. Scholbrock, and G. Memik, “Into the Wild: Studying Real
User Activity Patterns to Guide Power Optimizations for Mobile Architectures,” in IEEE/ACM MICRO 42, New York, NY, USA, December
2009, pp. 168–178.
[27] S. Gurumurthi, A. Sivasubramaniam, M. J. Irwin, N. Vijaykrishnan,
M. Kandemir, T. Li, and L. K. John, “Using Complete Machine
Simulation for Software Power Estimation: The SoftWatt Approach,” inProceedings of the 8th International Symposium on High-Performance
Computer Architecture, ser. HPCA ’02, 2002, pp. 141–150.
[28] J. Flinn and M. Satyanarayanan, “PowerScope: A Tool for Profiling theEnergy Usage of Mobile Applications,” in WMCSA ’99, New Orleans,Louisiana, USA, February 1999, pp. 2–10.
[29] M. Dong and L. Zhong, “Self-constructive High-rate System Energy
Modeling for Battery-powered Mobile Systems,” in Proceedings of the
MobiSys ’11, June 2011, pp. 335–348.
[30] S. Chowdhury, S. Borle, S. Romansky, and A. Hindle, “Greenscaler:training software energy models with automatic test generation,” Empirical Software Engineering, Jul 2018.
[31] C. Sahin, F. Cayci, I. L. M. Gutirrez, J. Clause, F. Kiamilev, L. Pollock,and K. Winbladh, “Initial explorations on design pattern energy usage,”in 2012 First International Workshop on Green and Sustainable Software(GREENS), June 2012, pp. 55–61.
[32] M. Fowler, “Gui architectures. 2006,” URL http://www. martinfowler.
com/eaaDev/uiArchs. html, 2007.
[33] M. Potel, “Mvp: Model-view-presenter the taligent programming model
for c++ and java,” Taligent Inc, p. 20, 1996.
[34] C. V. Lopes, Exercises in programming style. Chapman and Hall/CRC,
2016.
[35] Bohdan Samusko , “Model-view-presenter: Our choice ofarchitecture for your android app,” https://steelkiwi.com/blog/
model-view-presenter-our-choice-of-android-app/,(lastaccessed:
2018-Aug-02).
[36] android-architecture, “Android architecture blueprints,” https://github.
com/googlesamples/android-architecture, (last accessed: 2018-Aug-02).
[37] Pulkit Sethi, “Xamarin application architecture,” https://blog.kloud.com.
au/2018/01/17/xamarin-application-architecture/, (last accessed: 2018Aug-02).
[38] A. Pathak, Y. C. Hu, and M. Zhang, “Where is the Energy Spent
Inside My App?: Fine Grained Energy Accounting on Smartphones with
Eprof,” in EuroSys ’12, Bern, Switzerland, April 2012, pp. 29–42.
[39] S. Chowdhury, S. Di Nardo, A. Hindle, and Z. M. J. Jiang, “An
exploratory study on assessing the energy impact of logging on android
applications,” Empirical Software Engineering, vol. 23, no. 3, pp. 1422–
1456, Jun 2018.
[40] Y. Lyu, D. Li, and W. G. J. Halfond, “Remove rats from yourcode: Automated optimization of resource inefficient database writes
for mobile applications,” in Proceedings of the 27th ACM SIGSOFTInternational Symposium on Software Testing and Analysis, ser. ISSTA
2018, Amsterdam, Netherlands, 2018, pp. 310–321.
[41] Android, “Processes and threads overview,” https://developer.android.
com/guide/components/processes-and-threads, (last accessed: 2018-Jul22).
[42] A. Hindle, A. Wilson, K. Rasmussen, E. J. Barlow, J. C. Campbell,
and S. Romansky, “GreenMiner: A Hardware Based Mining Software
Repositories Software Energy Consumption Framework,” in MSR 2014,
Hyderabad, India, May 2014, pp. 12–21.

[43] K. Rasmussen, A. Wilson, and A. Hindle, “Green Mining: Energy
Consumption of Advertisement Blocking Methods,” in GREENS 2014,
Hyderabad, India, June 2014, pp. 38–45.
[44] K. Aggarwal, A. Hindle, and E. Stroulia, “Greenadvisor: A tool for
analyzing the impact of software evolution on energy consumption,” in2015 IEEE ICSME, Bremen, Germany, Sept 2015, pp. 311–320.
[45] S. Romansky, N. C. Borle, S. Chowdhury, A. Hindle, and R. Greiner,“Deep green: Modelling time-series of software energy consumption,”in 2017 IEEE International Conference on Software Maintenance andEvolution (ICSME), Shanghai, China, Sept 2017, pp. 273–283.
[46] S. A. Chowdhury and A. Hindle, “Greenoracle: Estimating softwareenergy consumption with energy measurement corpora,” in Proceedingsof the 13th International Conference on Mining Software Repositories,
ser. MSR ’16, 2016, pp. 49–60.
[47] A. McIntosh, S. Hassan, and A. Hindle, “What can android mobile
app developers do about the energy consumption of machine learning?”
Empirical Software Engineering, Jun 2018.
[48] M. Hollander, D. A. Wolfe, and E. Chicken, Nonparametric statisticalmethods. John Wiley & Sons, 2013.
[49] Android, “Android Debug Bridge,” https://developer.android.com/studio/
command-line/adb, (last accessed: 2018-Jul-22).
[50] Laerd,“Spearman’s
Rank-Order
Correlation,”
https://statistics.laerd.com/statistical-guides/
spearmans-rank-order-correlation-statistical-guide.php, (last accessed:
2018-May-11).
[51] T. Akidau, “The world beyond batch: Streaming 101,” https://www.
oreilly.com/people/09f01-tyler-akidau, (last accessed: 2018-AUG-05).
[52] J. Krystynak, “How to serve billions of web requests per day without
breaking a sweat,” https://www.infoworld.com/article/2868513/database/how-to-serve-billion-web-requests-per-day.html, (last accessed: 2018AUG-22).
[53] J. Shore, “How many data sources in your apps? let me
count
the
apis.”
https://searchcloudapplications.techtarget.
com/blog/Head-in-the-Clouds-SaaS-PaaS-and-Cloud-Strategy/
How-many-data-sources-Let-me-count-the-APIs,(last
accessed:
2018-AUG-22).
[54] “Microsoft,”
https://docs.microsoft.com/en-us/windows/desktop/
uxguide/progress-bars, (last accessed: 2018-Jun-02).
[55] F-Droid, “Sensor readout,” https://f-droid.org/en/packages/de.onyxbits.
sensorreadout/, (last accessed: 2018-Jun-02).
[56] F-droid, “Colorpicker,” https://f-droid.org/en/packages/com.enrico.
sample/, (last accessed: 2018-Jun-02).
[57] ——, “Angulo,” https://f-droid.org/en/packages/eu.domob.angulo/, (lastaccessed: 2018-Jun-02).
[58] ——, “Acrylicpaint,” https://f-droid.org/en/packages/anupam.acrylic/,(last accessed: 2018-Jun-02).
[59] “F-droid: Free and open source android app repository,” https://f-droid.
org/, (last accessed: 2018-May-22).
[60] L. Bao, D. Lo, X. Xia, X. Wang, and C. Tian, “How android app
developers manage power consumption?: An empirical study by mining
power management commits,” in Proceedings of the 13th International
Conference on Mining Software Repositories, ser. MSR ’16, 2016, pp.
37–48.
[61] D. E. Krutz, M. Mirakhorli, S. A. Malachowsky, A. Ruiz, J. Peterson,
A. Filipski, and J. Smith, “A dataset of open-source android applications,” in Proceedings of the 12th Working Conference on Mining
Software Repositories, ser. MSR ’15, 2015, pp. 522–525.
[62] X. Xia, E. Shihab, Y. Kamei, D. Lo, and X. Wang, “Predicting
crashing releases of mobile applications,” in Proceedings of the 10th
ACM/IEEE International Symposium on Empirical Software Engineeringand Measurement, 2016, pp. 29:1–29:10.
[63] Google Play, “Sensor readout,” https://play.google.com/store/apps/
details?id=de.onyxbits.sensorreadout, (last accessed: 2018-Jun-02).

[64] D. Pagano and W. Maalej, “User feedback in the appstore: An empirical
study,” in 21st IEEE International Requirements Engineering Conference(RE), July 2013, pp. 125–134.
[65] Scitools.com, “Understand,” https://scitools.com/, (last accessed: 2018Aug-18).
[66] A. MacCormack, J. Rusnak, and C. Y. Baldwin, “Exploring the structureof complex software designs: An empirical study of open source andproprietary code,” Management Science, vol. 52, no. 7, pp. 1015–1030,
July 2006.
[67] K. Sethi, Y. Cai, S. Wong, A. Garcia, and C. Sant’Anna, “Fromretrospect to prospect: Assessing modularity and stability from softwarearchitecture,” in 2009 Joint Working IEEE/IFIP Conference on Software
Architecture European Conference on Software Architecture, Sep 2009,
pp. 269–272.
[68] S. A. Chowdhury and A. Hindle, “Characterizing energy-aware software
projects: Are they different?” in Proceedings of the 13th International
Conference on Mining Software Repositories, ser. MSR ’16, 2016, pp.
508–511.
[69] J. McDonald, “Kruskalwallis test: Handbook of biological statistics,” http://www.biostathandbook.com/kruskalwallis.html, (last accessed: 2018-AUG-07).
[70] H. Malik, P. Zhao, and M. Godfrey, “Going green: An exploratory
analysis of energy-related questions,” in Proceedings of the 12th Working
Conference on Mining Software Repositories, ser. MSR ’15, 2015, pp.
418–421.
[71] I. Manotas, L. Pollock, and J. Clause, “Seeds: A software engineer’s
energy-optimization decision support framework,” in Proceedings of the36th International Conference on Software Engineering, ser. ICSE 2014,
2014, pp. 503–514.
[72] T. Agolli, L. Pollock, and J. Clause, “Investigating decreasing energy
usage in mobile apps via indistinguishable color changes,” in 2017
IEEE/ACM 4th International Conference on Mobile Software Engineering and Systems (MOBILESoft), May 2017, pp. 30–34.
[73] A. P. Miettinen and J. K. Nurminen, “Energy Efficiency of Mobile
Clients in Cloud Computing,” in Proceedings of the 2nd USENIX
Conference on Hot Topics in Cloud Computing, ser. HotCloud’10,
Boston, MA, USA, June 2010.
[74] N. Gautam, H. Petander, and J. Noel, “A Comparison of the Cost andEnergy Efficiency of Prefetching and Streaming of Mobile Video,” inProceedings of the 5th Workshop on Mobile Video, ser. MoVid ’13, Oslo,
Norway, February 2013, pp. 7–12.
[75] A. Carette, M. A. A. Younes, G. Hecht, N. Moha, and R. Rouvoy,“Investigating the energy impact of android smells,” in 2017 IEEE
24th International Conference on Software Analysis, Evolution andReengineering (SANER), Feb 2017, pp. 115–126.
[76] C. Sahin, P. Tornquist, R. McKenna, Z. Pearson, and J. Clause, “How
Does Code Obfuscation Impact Energy Usage?” in Proceedings ofthe 30th IEEE International Conference on Software Maintenance andEvolution (ICSME), 2014.
[77] C. Sahin, L. Pollock, and J. Clause, “How do code refactorings affectenergy usage?” in Proceedings of the 8th ACM/IEEE International Symposium on Empirical Software Engineering and Measurement (ESEM),
2014.
[78] A. Pathak, Y. C. Hu, M. Zhang, P. Bahl, and Y.-M. Wang, “Finegrained Power Modeling for Smartphones Using System Call Tracing,”
in EuroSys ’11, Salzburg, Austria, April 2011, pp. 153–168.
[79] R. Jabbarvand, A. Sadeghi, H. Bagheri, and S. Malek, “Energy-aware
test-suite minimization for android apps,” in Proceedings of the 25th
International Symposium on Software Testing and Analysis, ser. ISSTA
2016, 2016, pp. 425–436.
[80] R. Jabbarvand and S. Malek, “µdroid: An energy-aware mutation testing
framework for android,” in Proceedings of the 2017 11th Joint Meetingon Foundations of Software Engineering, ser. ESEC/FSE 2017, 2017,
pp. 208–219.