Comparing Performance and Energy Consumption of Android Applications: Native Versus Web Approaches

Tablets, ultramobiles and mobile phones are changing the routine of people and organizations around the world, representing a very important market of consumer electronics as well as applications. In [1] Android is pointed out as the dominant mobile Operating Systems (OS), although devices running iOS, or other OSs are also found on the market. Each OS represents an ecosystem that includes specific APIs, frameworks, and development tools, and usually also defines a language to be employed in development [2] [3]. To handle the diversity of ecosystems, traditionally, native applications have been developed using the language defined by the target platforms. The native approach was the predominant way to develop mobile application for a time, since it can present advantages, as a better usage of platform resources as 3D graphics or sensors. On the other hand, modern web technologies directed towards mobile are rapidly gaining interest from large communities of developers [4] [5]. These web-based approaches employ languages that are not native to the device’s OS [6], as HTML5, JavaScript, and PHP. As advantage, these approaches enable one single implementation to be shared across the target platforms and also not having to deal with deployment specific issues related to some of the ecosystems [6] [7], being known as cross-platform approaches. As mobile devices usually have limited resources and depend on battery to work, approaches that allow migrate processing and data storing for a remote server, saving device’s resources [8], as web or cloud based ones, have received attention. Following this approach, mobile applications are very closed to the traditional web systems adopting also a client/server architecture. These systems adopt different technologies/languages for the front-end (client side) and backend (server side). Usually, front-end can be developed in HTLM5 or JavaScript, but the server side usually adopts PHP. However, recently Node.js [9] is proposed as an open-source cross-platform JavaScript runtime environment, which enables developers to write server-side components using also the JavaScript programming language. Differently from the native applications, the web-based mobile ones are executed from an embedded web browser. This additional layer can generate some overhead and thus impact negatively on application performance. Moreover, applications developed in PHP and or using Node.js, require communication with the web server. Depending of the volume of data transfered, this communication can also impact negatively in performance and energy consumption. In contrast, locally executed applications (i.e native, and JavaScript ones) tend to consume more with processing compared to the ones implemented in PHP or using Node.js. Comparative studies among native and cross-platform applications have been published, since this tendency has emerged. However, most of these works consider only criteria as development facility, usability or end-user experience, and a small number of works discuss also performance or energy consumption [5]. Since these metrics are very important in the context of mobile devices, this work has as objective to compare native Android applications developed in Java to web-based applications developed in PHP, JavaScript and Node.js. Through experiments, we evaluate the impact of adopting these approaches, regarding performance and energy consumption. Besides, we discuss when the adoption of a client/server solution can provide benefits on efficiency compared to the local approaches. Yet, this work explores the Node.js technology, which has recently emerged as a performance improvement strategy for web-based applications, evaluating how its usage impact on application efficiency. This paper is organized as follows: Section II discusses related works; Section III presents the comparative study proposed here and details methodology and the different evaluated implementations; in Section IV experimental results are presented and discussed; and Section V presents the conclusion and points out future work.