Mobile app development frameworks lower the effort to write and deploy apps across different execution platforms. At the same time, their use may limit native optimizations and impose overhead, increasing resource usage. In this paper, we analyze the resource usage of Android benchmarks and apps based on three mobile app development frameworks, Flutter, React Native, and Ionic, comparing them to functionally equivalent, native variants written in Java. These frameworks, besides being in widespread use, represent three different approaches for developing multiplatform apps: Flutter supports the deployment of apps that are compiled and run fully natively, React Native runs interpreted JavaScript code combined with native views for different platforms, and Ionic is based on web apps, which means that it does not depend on platform-specific details. We measure the energy consumption, execution time, and memory usage of ten optimized, CPU-intensive benchmarks, to gauge overhead in a controlled manner, and two applications, to measure their impact when running commonly mobile app functionalities. Our results show that cross-platform and hybrid frameworks can be competitive in CPU-intensive applications. In five of the ten benchmarks, at least one framework-based version exhibits lower energy consumption and execution time than its native counterpart, up to a reduction of 81% in energy and 83% in execution time. Furthermore, in three other benchmarks, framework-based and native versions achieved similar results. Overall, Flutter, usually imposes the least overhead in execution time and energy, while React Native imposes the highest in all the benchmarks. However, in an app that continuously animates multiple images on the screen, without interaction, the React Native version uses the least CPU and energy, up to a reduction of 96% in energy compared to the second-best framework-based version. These findings highlight the importance of analyzing expected application behavior before committing to a specific framework.

Container virtualization has recently gained popularity due to its low performance and resource allocation overhead. The rise of this technology can be attributed to the advancement of cloud computing and the adoption of micro-services architecture. These new approaches offer a more efficient and fine-grained system design through the benefits of containerization, such as isolation, portability, and improved performance. However, container-based systems have created new challenges in monitoring due to their automated flexibility, ephemerality, and the increasing number of containers in a system. So there is a practical need for effective monitoring and performance management tools. This paper analyses the key performance metrics for machine, container and application services, including CPU usage, memory usage, disk usage, and network usage. Furthermore, we review several widespread tools for collecting and monitoring these metrics and present the Monintainer tool. It is a solution designed to monitor entire container-based systems, from applications to their underlying infrastructure, allowing users to better understand their systems’ behaviour in run-time. The tool’s results can aid container-based systems’ design, implementation and optimization.

Over the last years, increasing attention has been given to creating energy-efficient software systems. However, developers still lack the knowledge and the tools to support them in that task. In this work, we explore our vision that energy consumption non-specialists can build software that consumes less energy by alternating, at development time, between third-party, readily available, diversely-designed pieces of software, without increasing the development complexity. To support our vision, we propose an approach for energy-aware development that combines the construction of application-independent energy profiles of Java collections and static analysis to produce an estimate of in which ways and how intensively a system employs these collections. By combining these two pieces of information, it is possible to produce energy-saving recommendations for alternative collection implementations to be used in different parts of the system. We implement this approach in a tool named CT+ that works with both desktop and mobile Java systems, and is capable of analyzing 40 different collection implementations of lists, maps, and sets. We applied CT+ to twelve software systems: two mobile-based, seven desktop-based, and three that can run in both environments. Our evaluation infrastructure involved a high-end server, a notebook, and three mobile devices. When applying the (mostly trivial) recommendations, we achieved up to 17.34% reduction in energy consumption just by replacing collection implementations. Even for a real world, mature, highly-optimized system such as Xalan, CT+ could achieve a 5.81% reduction in energy consumption. Our results indicate that some widely used collections, e.g., ArrayList, HashMap, and HashTable, are not energy-efficient and sometimes should be avoided when energy consumption is a major concern.

Mobile devices have become ubiquitous in the recent years, but the complaints about energy consumption are almost universal. On Android, the developer can choose among several different approaches to develop an app. In this paper, we investigate the impact of some of the most popular development approaches on the energy consumption of Android apps. Our study uses a testbed of 33 different benchmarks and 3 applications on 5 different devices to compare the energy efficiency and performance of the most commonly used approaches to develop apps on Android: Java, JavaScript, and C/C++ (through the NDK tools). In our experiments, Javascript was more energy-efficient in 75% of all benchmarks, while their Java counterparts consume up to 36.27x more energy (median of 1.97x). On the other hand, both Java and C++ outperformed JavaScript in most of the benchmarks. Based on these results, four Java applications were re-engineered to use a combination of Java and either JavaScript or C/C++ functions. For one of the apps, the hybrid solution using Java and C++ spent 10x less time and almost 100x less energy than a pure Java solution. The results were not uniform, however. For another app, when we restructured its implementation so as to minimize cross-language method invocations, the hybrid solution using Java and C++ took 8% longer to execute and consumed 11% more energy than a hybrid solution using Java and JavaScript. Since most Android apps are written solely in Java, the results of this study indicate that leveraging a combination of approaches may lead to non-negligible improvements in energy-efficiency and performance.

Energy consumption has become an increasingly important topic in software development, especially due to the ubiquity of mobile devices, and the choice of programming language can directly impact battery life. This paper presents a study on the issue of energy efficiency on the Android platform, comparing the performance and energy consumption of 33 different benchmarks in the two main programming languages employed in Android development: Java and JavaScript. Preliminary results show that Java applications may consume up to 36.27x more energy, with a median of 2.28x, than their JavaScript counterparts, in benchmarks that are mostly CPU-intensive. In some scenarios, though, Java benchmarks exhibited better energy efficiency, with JavaScript consuming up to 2.27x more energy. Based on these results, two Java applications were re-engineered, and through the insertion of JavaScript functions, hybrid applications were produced. In both cases, improvements in energy efficiency were obtained. Considering that Android apps written in Java are the norm, results from this study indicate that using a combination of JavaScript and Java may lead to a non-negligible improvement in energy efficiency.