Characterizing and Detecting Inefficient Image

Displaying Issues in Android Apps

Wenjie Li

†

, Yanyan Jiang

†?

, Chang Xu

†?

, Yepang Liu

†

State Key Lab for Novel Software Technology, Nanjing University, Nanjing, China

‡

Shenzhen Key Laboratory of Computational Intelligence, Department of Computer Science and Engineering,

empirical study of 162 real-world IID issues collected from 243

popular open-source Android apps, validating the presence and

severity of IID issues, and then sheds light on these issues’

characteristics to support future research on effective issue

detection. Based on the findings of this study, we developed

a static IID issue detection tool TAPIR and evaluated it with

real-world Android apps. The experimental evaluations show

encouraging results: TAPIR detected 43 previously-unknown IID

issues in the latest version of the 243 apps, 16 of which have been

confirmed by respective developers and 13 have been fixed.

significantly affected [1]. For example, inefficiently displayed

images can lead to app crash, UI lagging, memory bloat, or

battery drain, and finally make users abandon the concerned

apps even if they are functionally perfect [2].

In this paper, we empirically found that mobile apps often

suffer from inefficient image displaying (IID) issues in which

the image displaying code contains non-functional defects that

cause performance degradation or even more serious conse-

quences, such as the app crashing or no longer responding.

Despite the fact that existing work has considered IID issues

To facilitate deeper understanding of IID issues, this paper

presents an empirical study towards characterizing IID issues

in mobile apps. We carefully localized 162 IID issues (in 36

apps) from 1,826 issue reports and pull requests in 243 well-

maintained open-source Android apps in F-Droid [10]. Useful

findings include:

?

Corresponding authors.

(45.1%), and handling lots of images and/or large images

are the primary causes. This finding is useful for devel-

(7.4%). We also extracted sufficient conditions for local-

izing these issues in an Android app’s execution trace,

which would benefit both dynamic and static analyzers.

3) Certain anti-patterns can be strongly correlated with

IID issues: image decoding without resizing (23.4%),

loop-based redundant image decoding (22.2%), image

decoding in UI event handlers (11.1%), and unbounded

image caching (4.3%). This finding lays the foundation

of our pattern-based lightweight static IID issue detection

technique.

1) We conducted a systematic empirical study of IID issues

in real-world Android apps. The findings provide key

The rest of this paper is organized as follows. Section II

introduces the background knowledge of image displaying in

Android apps. Section III presents the methodology of our

empirical study for IID issues in Android apps and discusses

our empirical findings. Section IV presents the design and

implementation of our TAPIR tool. Section V experimentally

evaluates TAPIR with popular and open-source Android apps

and discusses its results and the threats to validity. Section VI

presents related work, and Section VII concludes this paper.

The process of image displaying in Android consists of the

following four phases, which are all performance-critical and

energy-consuming [1]:

• Image loading for reading the external representation

of an image (from an external source, e.g., a URL,

file, or input stream) and decoding the image into an

Android-recognizable in-memory object (e.g., Bitmap,

• Image transformation for post-decoding image process-

cycles for image decoding and transformation, but it

would incur significant space overhead.

• Image rendering for physically displaying an image ob-

ject on an Android device’s screen. Images are rendered

natively by the Android framework [11].

Image displaying is both computation- and memory-

intensive. Displaying a full resolution image on a high-

resolution display may cost:

• hundreds of milliseconds of CPU time [5], which can

tions or user experiences:

1) Decoding images in the UI thread can significantly de-

grade an app’s performance, causing its slow responsive-

ness or even “app-not-responding” anomalies

.

https://github.com/wordpress-mobile/WordPress-Android/issues/5777.

2) Image objects not being freed in time can consume

significantly large amounts of memory, leading to

.

3) Improperly stored (cached) images may cause repeatedly

(and unnecessary) processing of the same images, result-

ing in meaningless performance degradation and energy

waste

.

a manifested app bug from end users. An app developer’s

pull request (PR for short), on the other hand, possibly

contains the developer’s perspective on a concerned app bug.

Therefore, we collected both of them in the empirical study.

We first identified potential IID-related IReps and PRs in the

GitHub repositories by a keyword search in their issue tracking

systems using the following keywords

issue has never been re-reported in the following three

months

After the manual inspection, we obtained a total of 1,826

IReps/PRs in 48 apps, which are from 22,023 IReps/PRs

returned by the keyword search from the initially selected 243

Android apps.

Collecting IID issues. We then inspected the GitHub commits

associated with the 1,826 IReps/PRs to decide whether they

correspond to IID issues. For each code patch (may patch sev-

corresponding IRep/PR, which would suffice for our further

manual inspection in order to answer research questions in

this study.

Finally, we collected a total of 162 IID issues (distributed

These numbers (162 issues and 14.8% coverage) suggest that

IID issues are definitely not rare, and can be considered as

common in practice and deserving an in-depth study. The

dataset of 162 IID issues will be made publicly available.

2) Analyzing the IID issues: The analysis of collected IID

These keywords are general natural language words related to image

displaying. They come from existing research work, e.g., [5], [6] and our

empirical study experience.

For those issues that do not contain any explicit link to any patch, we

conducted a bisect on their GitHub repositories to find potential fixing patches

by following the methodology of existing work [15].

. Their consequences can

quence, which is mostly caused by OutOfMemoryError

sumed memory keeps growing but does not lag or crash

the app yet

, although the app may unnecessarily stop

background activities and affect user experiences.

https://github.com/romannurik/muzei/issues/383.

• Abnormal image displaying (14/162, 8.6%) occurs when

an app’s memory is insufficient for decoding large im-

ages but does not cause app crash yet, which may also

trigger frequent GC (Garbage Collection) and impact user

experiences.

• Application not responding (2/162, 1.2%) is the extreme

case of app slowdown and is usually caused by an app

performing time-consuming image displaying operations

in the UI thread

periences but their IReps/PRs lack further details for

inspection.

We also found that 125 of the 162 studied IID issues contain

explicit descriptions about their triggering conditions. All

these triggering conditions concern to handling large images

(50/125, 40.0%), handling lots of images (73/125, 58.4%),

or both (2/125, 1.6%). For these cases, inefficient handling

of large/lots of images mostly cause app crash/slowdown,

respectively.

These findings, although seemingly straightforward, provide

2) RQ2: What are the root causes of IID issues?: To

further understand on the source-code level how IID issues

have occurred, we manually inspected the issues’ associated

patches to recognize their root causes. The overall results are

summarized as follows:

image resource management (the tool itself does not cover),

existing image displaying performance analysis [9] can help

developers improve the rendering performance of slow image

displaying.

Besides, this finding also suggests that static program

analysis techniques concerning these particularly recognized

root causes may be effective for detecting IID issues, as long as

one can semantically model the image displaying process in an

app’s source code, or find particular code anti-patterns which

correlate to these root causes (studied later in Section III-B3).

https://github.com/ccrama/Slide/issues/1639.

0

is computed directly or indirectly involving the

, which

w×h

https://github.com/kontalk/androidclient/issues/789.

Fig. 5. Unbounded image caching in Atarashii issue 6 (simplified)

2 decode{File, FileDescriptor, Stream,

3 Glide.load,

5 decode{File, FileDescriptor, Stream,

6 universalimageloader.core.ImageLoader.

UI thread also contributes to a significant amount of studied

IID issues, which are found to invoke (directly or indirectly)

image decoding APIs in an UI event handler.

This anti-pattern covers 18/162 (11.1%) of all studied IID

issues. Fig. 4 gives such an example, in which a big image

read from a local location was decoded in the UI thread

and caused the concerned app to run slowly (similar to the

code snippet example of Image decoding without resizing’s

in Fig. 2). In this issue, two methods createThumbnail()

and decodeByteArray() are used to decode an image read

thread (Lines 7 and 10–13).

Unbounded image caching. Finally, an incorrectly imple-

mented unbounded cache, in which a pool of decoded images

is maintained but no image can be released, is another source

of IID issues, since the ever-increasing cache size would cause

memory bloat or OutOfMemoryError.

This anti-pattern covers 7/162 (4.3%) of all studied IID

issues. Fig. 5 gives such an example, in which an app crashed

because of OutOfMemoryError after its user browsed many

images. The cause is that the app’s image cache imageCache

was wrongly implemented such that it gathered all decoded

images without any image releasing. This made the app’s

memory consumption keep increasing and quickly exceed an

Android device’s memory bound (Line 15). Its developer later

IV. STATIC DETECTION OF IID ISSUES

API invocation sequence and/or parameter value combinations.

These issue-inducing rules are characterized in Table I, which

are matched against in the TAPIR static analyzer.

on top of Soot [20]. TAPIR takes an Android app binary (apk)

file as input and uses dex2jar [21] to obtain a set of Java

bytecode files. It then builds the app’s context-insensitive call

graph, with a few implicit method invocation relations being

added, which are used to check rule #4:

1) The methods of AsyncTask.execute and AsyncTask.

invocation relationship.

2) The methods of Thread.start and Thread.run in the

same class should have an implicit invocation relation-

objects by a forward slicing. In particular, TAPIR checks the

anti-pattern rules as follows:

1) Rule #1 (image decoding without resizing) is checked by

analyzing the data-flow of the Option parameter, and a

warning is raised if there lacks the Option parameter or

its value satisfies the condition specified in Table I.

2) Rule #2 and #3 (loop-based redundant image decoding)

are equivalent to checking the call graph reachability

between the loop-related method invocations and the IS.

Furthermore, TAPIR also checks whether there is any

In this section, we present the experimental setup (Sec-

tion V-A) and results (Sections V-B and V-C) for evaluating

apps, followed by a threat analysis (Section V-D).

TABLE II