Keywords

1 Introduction

Mobile apps are omnipresent in our daily lives, providing us with a variety of important services. The availability of these services is bound to the limited battery capacity of today’s smartphones. Since the advancement of battery technology is highly challenging [24], energy-efficient mobile apps are critical for increasing user satisfaction. Improving the energy-efficiency of mobile apps is considered as a difficult task for practitioners, primarily due to a lack of knowledge and lack of appropriate tools [21].

Developing mobile apps for multiple platforms poses another challenge for practitioners [2, 17], as it typically requires creating and maintaining a separate codebase for each platform. Practitioners commonly choose mobile cross-platform development (MCPD) approaches, which allow the development of mobile apps that can run on multiple platforms, such as iOS and Android, using a single codebase [15]. This approach clearly saves resources for development, testing and maintenance compared to building separate apps for each platform.

Previous research [16] showed that MCPD approaches have a higher energy consumption than Android native when considering UI interactions. Therefore, this paper introduces Hybrid UI components, which are a combination of native UI components and web technologies. The research hypothesis of the proposed approach is that energy-intensive parts of the UI component are handled by the native implementation, such as animations and interactivity and the content is provided with web technologies (HTML, CSS, JavaScript) to keep the cross-platform availability. For the popular hybrid MCPD approach, Hybrid UI components would act as easy-to-use drop-in replacements for web-only UI components.

The goal of this paper is to evaluate the energy-efficiency of Hybrid UI components in a thorough and controlled experiment. Thus, the main contributions of this paper are: (1) an implementation of four selected Hybrid UI components; (2) an experimental comparison of Hybrid UI components against other mobile development approaches; (3) a discussion of the results and a discussion on the implications for cross-platform development; (4) a comprehensive replication package containing all research artifacts.

The remainder of this paper is organized as follows. Section 2 introduces the concept of Hybrid UI components. Section 3 gives an overview of relevant related research. Section 4 outlines the design and execution of the experiment, the experimental subjects, and the applied analysis procedure. Section 5 presents the results of this study, which is followed by the discussion thereof in Sect. 6, and a separate discussion on the threats to validity is given in Sect. 7. Finally, Sect. 8 concludes this paper.

Fig. 1.
figure 1

Dialog Capacitor UI Component

Full size image
Fig. 2.
figure 2

Dialog Hybrid UI Component

Full size image
Fig. 3.
figure 3

Different divisions of list items inside separate WebViews for the Scrolling Hybrid UI component

Full size image

2 Hybrid UI Components

MCPD refers to all mobile development approaches that enable developers to build apps from a single codebase or model for multiple mobile platforms. Researchers have conducted extensive studies on the various existing MCPD approaches, and have classified them accordingly [4, 13]. Based on developer popularity and usage, approaches that utilize web technologies, such as the hybrid mobile development approach, have been found to be widely adopted in industry [25].

The hybrid mobile development approach allows for embedding a web app inside a mobile app. Generally, the mobile app provides a fullscreen WebView to render the web content. A WebView is a UI component, available for all mobile platforms, which allows displaying web content inside a mobile app. By using web technologies (HTML, CSS, JavaScript), the web content can be styled and programmed to mimic the look and feel of the underlying mobile platform, e.g., Android or iOS. For the efficacy of mobile developers, open-source UI component libraries exist, which provide out-of-the-box web components with the look and feel of mobile platforms. Figure 1 shows a Dialog UI component inside a hybrid mobile app. The embedded WebView is set fullscreen inside the mobile app. The Dialog UI component, including animation and interactivity aspects, are fully built with web technologies, which mimic the look and feel of Android.

Hybrid UI components, as envisioned in this paper, are considered an extension of the hybrid MCPD approach. As existing research has shown, native development has a lower energy consumption [16], when considering UI interactions, than other mobile development approaches. Therefore the concept of Hybrid UI components is based on the assumption to provide energy-intensive parts of a UI component, such as animations and interactivity, by the native UI component and wrap a WebView inside the component to display the contents with web technologies to not compromise the cross-platform characteristic.

Figure 2 shows a Dialog UI component, implemented as a Hybrid UI component. The Dialog is using the Android native AlertDialog for interactive aspects, such as the open and close animations. The content is displayed inside a WebView with cross-platform web technologies. For a developer using a hybrid development approach, such as Capacitor, Phonegap or Apache Cordova, Hybrid UI components would be an easy-to-use drop-in replacement for respective UI components.

3 Related Work

There is a substantial body of research in the field of energy optimization for mobile apps, primarily focused on the Android native development approach [3]. Studies have shown that refactoring code smells [5, 20] or following performance-based guidelines [9] can significantly reduce the energy footprint of Android native apps. However, these findings, although significant, cannot be directly applied to MCPD approaches.

A general approach to influence energy consumption, which is applicable to all mobile development approaches, is regarded with the coloring of user interfaces. Today’s smartphones are equipped with OLED displays, which have a different energy consumption depending on the lightness of the color pixels. Thus, UIs providing a dark mode could substantially reduce energy consumption [11]. A less invasive approach is presented in [1]. The authors introduce an approach for indistinguishably changing color values, by transforming them into another color space and by that reduce energy consumption.

Besides adapting color values Valerio et al. [22] suggested usability improvements, to increase user efficiency and by that save energy. Furthermore, dimming parts of the screen, which are not important for a user’s current task have been proposed. Intuitively, the area covered by the user’s fingers could be completely dimmed, as proposed by the authors of FingerShadow [6]. ShiftMask [18] is another approach, which dims parts of the screen, which are not in the focus of a user.

Considering the energy-efficiency of MCPD approaches, existing studies have primarily focused on comparative analysis. Thus, studies on various aspects of MCPD approaches have been conducted, including comparisons of the energy-efficiency of sensors [7], algorithm benchmarks [19], UI interactions [16], media playback [8] and common app features [12]. To the best of our knowledge, this study is the first to focus on improving the energy-efficiency of an MCPD approach. Since the widespread use of MCPD approaches by practitioners, we hope this study fosters more research interest in optimizing the energy-efficiency of MCPD approaches.

4 Study Design

For planning, execution and analysis of this study, established guidelines for empirical research were followed, as described in the handbook of Wohlin et al. [23]. All research artifacts have been made available publicly as a comprehensive replication packageFootnote 1.

4.1 UI Components and Interaction Scripts

Fig. 4.
figure 4

Screenshots of the UI elements considered in this study: (1) Dialog, (2) Drawer, (3) Scrolling and (4) Sheet

Full size image

In this study, four commonly used UI components, namely Dialog, Drawer, Scrolling, and Sheet, were examined as experimental subjects. These components are displayed in Fig. 4 and are widely used in mobile apps. To cover a broad spectrum of UI components, we aimed to diversify the selection as much as possible. The components were implemented using three development approaches: Android native, the hybrid development approach CapacitorFootnote 2, and our proposed approach as Hybrid UI components.

The Android native UI components were included in the study as a benchmark for comparison with the Hybrid UI component counterparts. Previous research has shown that Android native has the lowest energy consumption among different mobile development approaches, when considering UI interactions [16]. On the other hand, the hybrid development approach Capacitor was included as a baseline for comparison with Hybrid UI component counterparts. Following the goal of this research, Hybrid UI components should have a lower energy consumption than the Capacitor implementations, to be regarded as an optimization.

Realistic test scenarios were created by rendering the UI components with content generated from publicly available fake data APIs. This was especially important for the Scrolling component, which required a large amount of image and textual data. To ensure reproducibility of the results, the scripts used to gather the fake data are also provided as part of the replication package.

For each of the four UI components, repeatable UI interaction scripts were created. The scripts were implemented with the UI Automator Android testing frameworkFootnote 3, which was selected according to the guidelines provided by Cruz et al. [10]. The interaction scripts can be started from the controlling computer and can be reused with each implementation of the UI components. A detailed description of each interaction script is provided in Table 1.

Table 1. Interaction scripts for UI components
Full size table

Overall the study had 14 implementations of UI components (experimental subjects). For the 3 UI components Dialog, Drawer, and Sheet, a variant with each development approach was provided, resulting in 9 experimental subjects. For the Scrolling UI component, 3 different variants (discussed in Sect. 4.2) for the hybrid UI component were provided and 2 variants for the other development approaches, resulting in 5 experimental subjects.

4.2 UI Component Implementation Details

All implementations of the UI components follow the Material design guidelinesFootnote 4. This is the default design system used in Android apps. By following that practice we could make sure that for typical smartphone users the different UI component implementations are indistinguishable, as they have the same look and feel.

The Android native implementation of the UI components uses all the corresponding default UI components from the Android SDK. That is, the AlertDialog for the Dialog component, the DrawerLayout for the Drawer component and the BottomSheetDialog for the Sheet component. The Scrolling component was implemented with the RecyclerView, which makes use of the concept of virtual scrolling.

Virtual scrolling is an efficient approach to implement scrolling, especially for resource-constrained devices like smartphones. For a scrollable list, only the items which are within the displayable area of the screen are loaded and rendered. While scrolling, as soon as a list item is leaving the visible area, it is reused and rendered with different content on the other end of the list, which enters the visible area of the screen.

Capacitor is a hybrid mobile development approach, therefore web technologies could be used. For the UI component implementations, the JavaScript library ReactFootnote 5 was used together with the IonicFootnote 6 mobile UI library. Ionic is a popular library for mobile UI components built with web technologies. The library closely follows the Material design guidelines for the Android components and by that mimics the look and feel of the native implementations. From the Ionic library the ion-alert component was used for implementing the Dialog, the ion-menu component for implementing the Drawer and the ion-action-sheet component for implementing the Sheet component. Similar to the Android native implementation for Scrolling a virtual scrolling approach was used. Thus, an additional React component, named VirtuosoFootnote 7, was used for that purpose. To style the list items, we employed corresponding CSS styles from the Ionic library.

As envisioned, the Hybrid UI components should be built upon native UI components and wrap a WebView inside, for displaying the content. Thus, for implementing the Dialog, Drawer and Sheet component, the native Android AlertDialog, DrawerLayout and BottomSheetDialog were used as a basis. The visible area of the respective UI component was rendered with an embedded WebView. The contents of the WebViews were created with web technologies to mimic the exact same look and feel as for the native counterpart.

For Hybrid UI components, scrolling was implemented based on the virtual scrolling approach. Similar to Android native a RecyclerView was used and WebViews were used as scrollable items. Inside the WebViews the actual list items with respective styling and content were rendered. Since inside a WebView, more than one list item could be rendered and a reduction of the amount of WebViews inside the RecyclerView should increase the energy-efficiency, three variants of the component were implemented. The variants divide different amounts of list items into a WebView. Thus, we implemented the default approach with one list item per WebView, an approach with four list items per WebView and an approach with ten list items per WebView. In Fig. 3 a visualization of the variants is given. Thereby the line sections on the right indicate how list items are divided into WebViews.

For Hybrid UI components, scrolling was also implemented using the virtual scrolling approach. Like in the Android native implementation, a RecyclerView was used, and WebViews were used as scrollable items. The actual list items with their corresponding styling and content were rendered inside the WebViews. We implemented three variants of the component, that divide different numbers of list items into a WebView. As a hypothesis, we considered that by reducing the amount of WebViews the energy-efficiency should be increased. The first variant is the default approach with one list item per WebView, the second variant is an approach with four list items per WebView, and the third variant is an approach with ten list items per WebView. Figure 3 illustrates these variants. The line sections on the right indicate how the list items are divided into WebViews.

4.3 Energy Measurement

The energy measurements were collected with a hardware-based metering approach, as this allows for exactly collecting the energy consumed by the device. The Monsoon High Voltage Power MonitorFootnote 8 was used, as it has a Python-based API, to precisely control the measurement process and is commonly used in similar study designs. The Samsung Galaxy S21 Android device was prepared to be usable with the power monitor. An overview of the device specifications is listed in Table 2.

The preparation of the device included removing the device’s battery and assembling the power monitor as the only power source. Throughout the experiments, the device was supplied with a constant voltage of 4.3V in order to infer reliable and repeatable measurements.

4.4 Experimental Setup and Execution

Fig. 5.
figure 5

Overview of experimental setup

Full size image
Table 2. Samsung Galaxy S21 Android Device Specifications
Full size table

The experimental setup consists of a controlling computer and a smartphone with a power monitor as its sole power supply. The Android Debug Bride (adb) was used to connect the controlling computer with the smartphone via Wi-Fi. The controlling computer was also connected to the power monitor to read and control the energy measurements. An overview of the experimental setup is given in Fig. 5.

Before starting the experiment, the smartphone was prepared by following these steps:

  • All required apps containing the UI components and the accompanying interaction scripts were installed and tested.

  • All background services, such as GPS or Bluetooth were deactivated and all other active apps were closed.

  • The device was put into a do-not-disturb-mode, to prevent any kind of notifications to interfere with the experiment execution.

For the actual execution of the experiment, a Python script on the controlling computer was prepared. The script randomly selects one of the experimental subjects and its corresponding interaction script.

The scripts open the app under test on the smartphone. Parallel to running the interaction script, the energy is metered with the power monitor. In addition, before and after starting the interaction script the idle energy consumption of the app is measured. The mean of the idle energy consumption is deducted from the energy consumption of the interaction with the UI component. With this procedure, the actual and isolated energy consumption of the UI component and respective interaction could be approximated. The power monitor can only collect the energy consumed by the whole smartphone. Therefore, the deduction of the idle energy consumption of the app under test was used to approximate the energy consumption of the UI component.

To minimize measurement bias, at least 30 identically and independently repeated samples were collected for each experimental subject. Thus, the controlling script ended the experiment after enough samples were available. Overall the experiment procedure yielded 420 samples.

4.5 Experimental Variables and Hypothesis

The stated research goal of this study, is to investigate, whether there are significant differences in energy consumption among different UI component implementations. To achieve this, statistical hypotheses were formulated. The independent variables are the UI component and the development approach, while the dependent variable is the energy consumption in Joules for interacting with the specific UI component.

For each experimental subject the respective mean \(\mu _{ij}\) was calculated, with \(i \in \{an, c, hu\}\) for the development approaches Android native, Capacitor, and Hybrid UI and further \(j \in \{di, dr, sc, sh\}\) for the UI components Dialog, Drawer, Scrolling and Sheet.

To investigate the differences in energy consumption of the UI component interactions, with regard to the different development approaches, a two-tailed null hypothesis (\(H_0\)) and corresponding alternative hypothesis (\(H_a\)) were formulated:

$$ H_{0,ij}: \mu _{hu,j} = \mu _{ij}, \qquad \forall i \in \{an, c\}, j \in \{di, dr, sc, sh\} $$
$$ H_{a,ij}: \mu _{hu,j} \ne \mu _{ij}, \qquad \forall i \in \{an, c\}, j \in \{di, dr, sc, sh\} $$

The \(H_{0,ij}\) hypothesis states that there is no significant difference in energy consumption between Hybrid UI components with regard to the other development approaches. In contrast, the alternative hypothesis \(H_{a,ij}\) states that there is a significant difference in energy consumption between Hybrid UI components and the other examined development approaches.

4.6 Data Analysis

From the experiment execution 30 samples, for each UI component, were obtained. A sample represents the energy consumption of a UI component in Joule when executing the respective interaction script.

The permutation test [14] was selected to determine statistical significance, due to the fact that the majority of the samples were failing to meet the assumptions of normality (based on Shapiro-Wilk test with \(\alpha = 0.05\)). The permutation test is a non-parametric test and has no assumptions on the distribution of the samples.

As the obtained samples from the Hybrid UI components were used in multiple hypothesis tests (once with Android native and once with Capacitor) the chance of Type-I errors is increased with respect to our target \(\alpha = 0.05\) level. Thus, after applying a Bonferroni correction an \(\alpha \) of 0.025 is used to determine significance.

Finally, to complement the hypothesis testing and to determine the magnitude of the differences in energy consumption, effect sizes are calculated. The non-parametric Cliff’s Delta was selected as the appropriate effect size measure.

5 Results

Fig. 6.
figure 6

Energy consumption of different UI component implementations, based on the execution of the test script

Full size image

Figure 6 shows a descriptive overview of the results in the form of a box plot. The different UI components, considered in this study, are shown in separate charts. Each chart represents the energy consumption in Joules along the y-axis and the implementation approaches along the x-axis. For the Scrolling UI component, the three variants of the Hybrid UI implementation are shown. The number in parentheses accounts for the number of list items, which are rendered within a WebView.

Furthermore, Table 3 lists the results of the statistical analysis. For the Scrolling component, the results of the Hybrid UI component with ten list items per WebView are used in the statistical comparisons, as it is the most energy-efficient according to the descriptive results.

Considering the results regarding the comparison of Hybrid UI components and Android native components, clearly, all results show a statistically significant difference. Further, when interpreting the effect sizes for Android native the Dialog, Drawer, and Scrolling components are more energy-efficient, by a large extent than the Hybrid UI implementations. For the Sheet component, the Android native implementation is more energy-efficient than the Hybrid UI counterpart, but to a lesser extent.

The results regarding Capacitor show that there is a significant difference between the Dialog, Scrolling, and Sheet components. For the Drawer component, the \(H_0\) hypothesis could not be rejected. By interpreting the effect sizes Hybrid UI components are more energy-efficient, by a large extent, than the Capacitor counterpart. For the Scrolling component, the opposite is true, Capacitor is more energy-efficient than the Hybrid UI implementation.

Table 3. Results of statistical analysis for comparing Android native and Capacitor against Hybrid UI components
Full size table

6 Discussion

The proposed Hybrid UI approach for the Dialog and Sheet components has the potential to significantly reduce energy consumption by on average \(\sim \)38.3% and \(\sim \)54.7%, respectively, when compared to the Capacitor hybrid development method. This represents a substantial improvement, as the user experience and visual appearance remain completely unchanged.

Simultaneously, it must be noted that while the Hybrid UI implementation of the Drawer component resulted in slightly higher energy consumption compared to the Capacitor implementation (\(\sim \)1.4% on average), it was not a significant difference. On the other hand, a significant increase in energy consumption was observed for the Scrolling component when using the Hybrid UI component implementation. Further analysis revealed that the number of list items per WebView was a key factor in reducing energy consumption. As a result, the observed increase in energy consumption varied from over \(\sim \)109.6% (one list item per WebView) to as low as \(\sim \)18.6% (ten list items per WebView).

In this first implementation of Hybrid UI components, the wrapping native UI components were used as provided by the Android SDK. However, it was found that in the case of the Drawer and Scrolling UI components, this might not be the optimal approach, as these native components were not designed with our use case in mind.

A first runtime analysis of the implementation of the Drawer and Scrolling Hybrid UI components revealed that unnecessary re-renderings of the WebViews were triggered by the underlying native UI component. This seems to be mainly the case when a UI component leaves and enters the displayable area of the screen. For example, at times the Drawer UI component was re-rendered when sliding into the displayable area, although it was already rendered once. This would not have been necessary if the wrapped content inside the WebView didn’t change. To improve the performance of these Hybrid UI components, a more in-depth analysis of the inner workings of the native wrapper UI component is required, and potential adaptations on how the re-rendering approach could be tweaked to fit the use case of Hybrid UI components better. This could involve making changes to the way the native wrapper component handles the triggering of re-renderings based on the state of the WebView contents.

Developing and maintaining a comprehensive UI component library using web technologies, that replicate the look and feel of native UI components, such as Ionic, is a significant undertaking. Besides the goal of being more energy-efficient, another advantage of Hybrid UI components is that the need for implementing and maintaining interactivity and animation features is eliminated, as the native UI components can be utilized. Developers solely need to focus on styling the content for Hybrid UI components. However, a disadvantage of this approach is, that it cannot be used directly within a web or progressive web app anymore.

We have shown the feasibility of using Hybrid UI components for the Android platform by implementing four selected UI components. The approach is highly extendable and other UI components, such as navigation bars, navigation rails, snackbars, time and date pickers, navigation tabs, and others, can be implemented as well. Although we have not tested the approach on the iOS platform, to the best of our knowledge, Hybrid UI components are transferable to iOS as well. However, examining energy-efficiency on iOS is challenging, as the platform is highly restricted for such kinds of experiments.

Hybrid UI components were designed as an extension to the hybrid MCPD approach to reduce energy consumption. Previous research has found that other MCPD approaches [16], such as React Native, consume more energy during UI interactions than the hybrid development approach. Therefore, Hybrid UI components could be used in conjunction with other MCPD approaches to decrease energy consumption.

7 Threats to Validity

There are potential threats to the validity of this study, which should be considered in the context of our results.

External Validity. We aimed for a hardware-based measurement approach, in order to have exact results. The preparation of the device, by removing the battery, makes it useless for other purposes. A replication with other devices was economically unfeasible. Therefore, we selected a modern and representative device (Samsung has the largest market share of all Android device manufacturers). To address this limitation, we prepared a publicly available replication package, which is compatible with other Android devices, to facilitate future replications.

Internal Validity. A smartphone is a complex system comprised of a variety of hardware and software components. In our measurement setup, the proper elicitation of the causal relationship between our treatment (development approach) and the outcome (energy consumption) could be disturbed by the presence of confounding factors. To mitigate this threat, we took several measures to eliminate known confounding factors such as background services, other active apps, and notifications. Additionally, we randomly selected subjects before starting each experimental run. These measures helped to substantially mitigate the threat of potentially disturbing factors and increase the internal validity of our study.

Construct Validity. The execution of the experiment was preceded by an extensive planning phase, in which all aspects of the experiment, including the goal, treatments, variables, and hypotheses, were clearly defined and established a priori. By adhering to this methodology, we ensured that the design of the experiment accurately reflected the construct under study.

Conclusion Validity. The analysis procedure was carefully chosen to ensure the correct conclusions could be drawn from the results. We conducted a check for normality of the samples to select an appropriate hypothesis test and corresponding effect size measure. Additionally, to account for the fact that the Hybrid UI component samples were reused in comparison with other development approaches, we applied a conservative correction of the target \(\alpha \) level. The raw measurements and the accompanying analysis are included in the replication package for independent review.

8 Conclusion

In summary, our study demonstrates the potential of Hybrid UI components in reducing energy consumption in MCPD approaches, particularly when used together with the hybrid MCPD approach. We implemented and evaluated a diverse set of four UI components and found that two of them showed a substantial improvement in energy efficiency, while the results for the other two were inconclusive. However, we could identify first indications, which could be used to also improve the energy-efficiency of the Drawer and Scrolling UI components.

As future work, we plan to implement and evaluate more Hybrid UI components for Android as well as for iOS. Our study has demonstrated the potential of this approach in reducing energy consumption in mobile applications, but further research is needed to fully optimize all of the offered UI components. By providing clear and measurable improvements in energy-efficiency, we hope to motivate developers of MCPD frameworks and apps to participate in the continued use and development of this approach.