On adopting linters to deal with performance concerns in Android apps

Abstract

With millions of applications (apps) distributed through mobile markets, engaging and retaining end-users challenge Android developers to deliver a nearly perfect user experience. As mobile apps run in resource-limited devices, performance is a critical criterion for the quality of experience. Therefore, developers are expected to pay much attention to limit performance bad practices. On the one hand, many studies already identified such performance bad practices and showed that they can heavily impact app performance. Hence, many static analysers, a.k.a. linters, have been proposed to detect and fix these bad practices. On the other hand, other studies have shown that Android developers tend to deal with performance reactively and they rarely build on linters to detect and fix performance bad practices. In this paper, we therefore perform a qualitative study to investigate this gap between research and development community. In particular, we performed interviews with 14 experienced Android developers to identify the perceived benefits and constraints of using linters to identify performance bad practices in Android apps. Our observations can have a direct impact on developers and the research community. Specifically, we describe why and how developers leverage static source code analysers to improve the performance of their apps. On top of that, we bring to light important challenges faced by developers when it comes to adopting static analysis for performance purposes.

The Rise of Android Code Smells: Who is to Blame?

“…• Study the self-admittance [13] of Android code smells. The observed correlations also show, with quantitative evidence, that the unawareness described by developers in the study of Habchi et al [18] is very prevalent. This oversight incites us to question the importance of mobile code smells and the efficiency of the communication channels used by framework builders.…”

“…We conducted this study with the hypothesis that some developers are responsible for the accrual of mobile code smells. In light of our results, we were able to reject this hypothesis [18], [19], [26]. Even if the numbers show that 61 % of the developers are neutral, this percentage is biased by the huge number of developers who had very few commits.…”

“…Hypothesis 1 (H1): Code smell introductions and removals are isolated practices. This hypothesis is supported by studies that suggested that the presence of code smells is the result of the actions of only some developers [18], [19].…”

“…They only approached this topic in their explanatory hypotheses when discussing the possible factors of mobile code smells accumulation. In particular, they hypothesised that some mobile developers who lack experience and knowledge about the framework, are responsible for the accrual of mobile code smells [18], [19], [26]. Our study builds on these hypotheses and addresses the developers role with a large scale analysis.…”

“…Hypothesis 2 (H2): There is an inverse correlation between code smell introductions and removals among developers. This hypothesis is motivated by the reasoning that some bad developers who are unaware about code smells will tend to introduce and never remove them and vice versa [18], [19], [26], [29]. Hypothesis 3 (H3): For each code smell type, there is an inverse correlation between code smell introductions and removals among developers.…”