The document discusses memory management fundamentals for Android applications, including the constraints of the Android memory model, the functionality of the Dalvik VM, and garbage collection (GC) processes. It highlights the importance of efficient memory usage due to limited heap size and the implications on app performance and user experience. Tools and techniques for diagnosing memory usage and leaks, such as adb shell procrank, Java memory methods, and the Eclipse memory analyzer tool, are also covered.

1. Memory
Management
Fundamentals
for
Android
apps

2. Agenda
1. Memory
usage
model
– Constraints
– Zygote,
Dalvik
and
GC
2. Tools
for
memory
diagnos@cs
– adb
shell
procrank
– lava.lang.Run@me
– Log
messages
– Alloca@on
tracker
– Eclipse
MAT

3. We’ve
grown
bigger
and
stronger
12x
RAM
T-­‐Mobile
G1
(2008)
Nexus
4
(2012)
192
MB
2
GB

4. So
why
should
we
care
about
the
memory?
• Heap
size
is
limited
and
device
dependent
• Screen
size
has
grown
drama@cally
-­‐
Bitmaps
• System
libraries
occupy
significant
amount
of
storage
• The
more
memory
we
use,
the
more
work
GC
has,
the
more
work
GC
has
the
bigger
pause
@me
will
be.
• BaWery
life

5. Dalvik
VM

6. Dalvik
VM
.dex
format

7. Respect
the
balance!
Cache
as
much
useful
Use
as
liWle
data
as
you
memory
as
can
you
can
Why?
Why?
I
can
do
I
will
kill
your
process
as
mul@tasking
and
I
soon
as
I
don’t
have
want
smooth
UX
memory
for
other
apps
and
your
app
uses
lots
of
when
switching
memory
between
apps

8. Mark-­‐and-­‐sweep
GC
Larger
heap
=
larger
pause
@me
=
poor
performance

9. Mark-­‐and-­‐sweep
GC
GC
Roots
Phase
1
Before
GC

10. Mark-­‐and-­‐sweep
GC
GC
Phase
2
Roots
Marking
complete
-­‐
Marked
object
-­‐
Garbage
Mark:
star@ng
from
roots,
mark
all
reachable
objects
by
using
a
depth-­‐first-­‐search
pointer
traversal

11. Mark-­‐and-­‐sweep
GC
GC
Phase
3
Roots
Sweep
complete
-­‐
Marked
object
Sweep:
scan
the
heap
from
the
beginning
to
the
end
and
reclaim
the
unmarked
objects
(and
unmark
the
marked
objects).

12. GC
Improvements
Before
Aber
Garbage
collector
• Stop-­‐the-­‐world
• Advantage
of
mul@core
support
• Full
heap
collec@on
• Mostly
concurrent
• Large
pause
@mes
• Par@al
collec@ons
• Smaller
pause
@mes

13. GC
Improvements
Aber
Before
• Stop-­‐the-­‐world
–
all
app
threads
are
stopped
• Full
heap
collec@on
• Large
pause
@mes
oben
>
100ms
• Ini4al
mark
-­‐
stop-­‐the-­‐world
• Mark
-­‐
concurrent
• Remark
–
stop-­‐the-­‐world
• Sweep
-­‐
concurrent

14. Healthy
memory
usage
paWern
Maximum
heap*
size
Allocated
GC
Run
memory
Garbage
Memory
Usage
Time
*
Maximum
amount
of
memory
our
app
is
allowed
to
use

15. Edge
case
Maximum
heap*
size
OutOfMemoryError
Allocated
GC
Run
memory
Garbage
Memory
Usage
Time
*
Maximum
amount
of
memory
our
app
is
allowed
to
use

16. Are
we
leaking
memory?
Maximum
heap*
size
Allocated
GC
Run
memory
Garbage
Amount
of
memory
leaking
Memory
Usage
Memory
leak
Time
*
Maximum
amount
of
memory
our
app
is
allowed
to
use

17. Maximum
heap
size
So
how
much
memory
can
we
actually
use?
1.
ActivityManager.getMemoryClass()
–
device
dependent
–
always
constant
2.
Runtime.getRuntime().maxMemory()
–
can
be
changed
on
rooted
devices,
is
slightly
larger
T-­‐Mobile
G1
–
16
MB
Nexus
One
–
32
MB
Nexus
7
–
64
MB

18. Memory
intensive
apps
What
if
it
is
not
enough?
Image
editor?
Video
editor?
3D
game?
<application
android:largeHeap=“true”
</application>
Use
only
if
you
are
sure
you
need
this
extra
memory.
ActivityManager.getLargeMemoryClass()

19. We
are
armed

20. Target
–
Honeycomb
Gallery
App
YOUR_SDK_LOCATIONsamplesandroid-­‐XXHoneycombGallery

21. Tools
to
diagnose
memory
usage
1. adb
shell
procrank
2. java.lang.Run@me
3. Log
messages
4. Alloca@on
tracker
and
heap
updates
5. Heap
dumps
and
Eclipse
Memory
Analyzer
Tool
(MAT)

22. procrank
u@lity
Applica4on:
answers
a
ques@on
how
much
memory
are
we
actually
using.

23. procrank
Lists
of
all
processes
on
the
device
and
memory
they
are
using
(sorted
desc.).
adb
shell
procrank
(requires
root
access)
Uss
–
Unique
set
size
–
rough
memory
amount
the
system
would
reclaim
if
it
kills
the
process.

24. Java.lang.Run@me
methods
• freeMemory()
• totalMemory()
Applica4on:
• observing
general
applica@on
memory
usage
paWern
at
run@me
• provides
basic
understanding
of
memory
usage
behavior

25.
Observing
memory
state
changes
in
LogCat
new Thread(new Runnable() {
@Override
public void run() {
while (true) {
try {
Thread.sleep(5000);
} catch (InterruptedException e) {
// do nothing
}
reportMemoryUsage();
}
}
}, “MemoryUsageReporter").start();

26.
Gives
a
general
idea
about
memory
changes
at
run@me
RAM
USAGE
free:
1.96MB,
total:
14.68MB,
max
:
64.00
RAM
USAGE
free:
1.95MB,
total:
14.68MB,
max
:
64.00
RAM
USAGE
free:
1.71MB,
total:
14.68MB,
max
:
64.00
RAM
USAGE
free:
1.71MB,
total:
14.68MB,
max
:
64.00
RAM
USAGE
free:
4.62MB,
total:
17.35MB,
max
:
64.00
RAM
USAGE
free:
4.62MB,
total:
17.35MB,
max
:
64.00
RAM
USAGE
free:
1.95MB,
total:
14.68MB,
max
:
64.00
RAM
USAGE
free:
1.95MB,
total:
14.68MB,
max
:
64.00
RAM
USAGE
free:
1.95MB,
total:
14.68MB,
max
:
64.00

27. Interpre@ng
LogCat
messages
02-­‐25
11:12:59.321:
D/dalvikvm(7757):
GC_CONCURRENT
freed
1536K,
17%
free
10790K/
12856K,
paused
3ms+3ms,
total
21ms

28. General
informa@on
02-­‐25
11:12:59.321:
D/dalvikvm(7757):
GC_CONCURRENT
freed
1536K,
17%
free
10790K/
12856K,
paused
3ms+3ms,
total
21ms
• Timestamp
• Logging
level
• Log
tag
• Process
id

29. Reason
for
GC
Run
02-­‐25
11:12:59.321:
D/dalvikvm(7757):
GC_CONCURRENT
freed
GC_CONCURRENT
1536K,
17%
free
10790K/12856K,
paused
3ms+3ms,
total
21ms
Possible
reasons:
• GC_CONCURRENT
• GC_FOR_MALLOC/GC_FOR_ALLOC
• GC_EXTERNAL_ALLOC
• GC_HPROF_DUMP_HEAP
• GC_EXPLICIT

30.
Amount
of
memory
reclaimed
02-­‐25
11:12:59.321:
D/dalvikvm(7757):
GC_CONCURRENT
freed
freed
1536K,
17%
free
10790K/12856K,
paused
3ms+3ms,
total
21ms
1536K,
Heap
sta@s@cs
02-­‐25
11:12:59.321:
D/dalvikvm(7757):
GC_CONCURRENT
freed
1536K,
17%
free
10790K/12856K,
paused
3ms+3ms,
total
21ms
17%
free
10790K/12856K
• Percentage
of
free
heap
memory
aber
the
GC
run
• Size
of
objects
alive/Total
heap
size
Pause
@me
02-­‐25
11:12:59.321:
D/dalvikvm(7757):
GC_CONCURRENT
freed
1536K,
17%
free
10790K/12856K,
paused
3ms+3ms,
total
21ms
paused
3ms+3ms,
total
21ms

31. Bitmaps
–
what
has
changed?
Before
Honeycomb
Dalvik
Heap
Na@ve
Memory
Pixel
Data

32. Bitmaps
–
what
has
changed?
Aber
Honeycomb
Pixel
Data
Dalvik
Heap
Na@ve
Memory

33. Bitmaps
–
what
has
changed?
Before
Aber
Bitmap
pixel
data
storage
Na@ve
memory
• Freed
via
–recycle
or
finalizer
Dalvik
Heap
• Freed
synchronously
by
GC
• Hard
to
debug
• Full
GC
(stop-­‐the-­‐world)
• Easy
to
debug
• Concurrent
and
par@al
GCs

34. Profit?
• When
pixel
data
is
stored
in
Dalvik
heap
it
is
much
easier
to
debug
memory
usage
as
everything
is
in
one
place
• Pixel
data
in
pre-­‐Honeycomb
was
freed
by
recycle()
or
finalizer,
now
freed
syncronously
by
GC
• GCs
of
pixel
data
are
now
concurrent
and
par4al
–
pause
4mes
are
smaller

35. Alloca@on
tracker
(Monitor)
• Info
about
object
alloca@ons
in
a
specific
@me
period

36. Eclipse
Memory
Analyzer
Tool

37. Heap
Dump
• Is
a
snapshot
of
all
“living”
objects
at
a
given
point
in
@me
• Contains
info
about
which
objects
are
GC
roots
(will
not
be
reclaimed
if
there
are
no
refs
to
them).
• Does
not
contain
info
about
na@ve
objects
(pre-­‐Honeycomb
Bitmaps
e.g.)

38. Object
size
• Shallow
size
of
an
object
–
amount
of
memory
allocated
to
store
the
object
itself,
not
taking
into
account
the
referenced
object.
(Sum
of
size
of
the
object
header
and
the
fields)
Shallow
size
String
1
String
2

39. Shallow
object
size
-­‐
example
public
final
class
String
{
//
8
Bytes
header
private
char
value[];
//
4
Bytes
private
int
offset;
//
4
Bytes
private
int
count;
//
4
Bytes
private
int
hash
=
0;
//
4
Bytes
…}
“Shallow
size”
of
a
String
==
24
Bytes
(32
bit
Sun
JDK)

40. Retained
set
• Retained
set
of
object
X
Object
X
– The
set
of
objects
that
would
be
garbage
collected,
if
object
X
is
deleted
– The
retained
size
of
an
object
X
Retained
set
of
X
is
equal
to
the
shallow
size
of
the
“Retained
sets”
of
X

41. Genera@ng
a
heap
dump
file
• Dump
HPROF
file
(DDMS
or
programma@cally)*
• Convert
(Not
needed
in
Eclipse
DDMS)
hprof-­‐conv
dump.hprof
dump-­‐conv.hprof
• Open
the
file
with
Eclipse
MAT
*android.os.dumpHprofData(String
filename)

42. Ini@al
pie
chart
view
• Shows
the
biggest
objects
be
their
retained
size

43. Histogram
view
Number
of
instances
of
each
class
and
their
shallow
size

44. Histogram
view
Oben
not
very
useful.
Why?
Class
name
Number
of
objects
Shallow
size
in
bytes
char[]
9
597
555
496
Java.lang.String
10
799
259
176
How
many
char[]
are
caused
by
String
instances?

45. Dominator
tree
example
An
object
A
dominates
on
an
object
B
if
all
the
paths
to
object
B
pass
through
object
A.
1.
Note
that
A,
B
and
C
are
dominated
by
a
"virtual"
root
object.
2.
Note
that
the
dominator
rela@onship
is
transi4ve;
C
dominates
E
which
dominates
G
therefore
C
also
dominates
G.

46. Dominator
tree
view
List
of
objects
by
their
retained
heap

47. Memory
Leak
Demo

48. Ques@ons?
Taras
Leskiv
leskiv.taras@gmail.com
linkedin.com/in/tarasleskiv