Android: Managing MemoryRussell Myers

MeRussell Myers

Amazon Fire Phone

Middleware – applications and components

Web (recent) Intranet sites for Comcast,

Verizon, etc.

Overview

How much do we have? It’s been bad (Google I/O 2011 Memory Management For Android Applications)

G1 (first Android phone): 16 MB Droid: 24 MB Nexus One: 32 MB Xoom (first “real” Android tablet): 48 MB

These days 512 MB – 2 GB (reasonable targets) Android “L” will likely see an increase in this as 64-bit devices come in. KitKat could invite more low end devices as well.

By the way, no memory swapping!

Is it really that much? (hint: No)From my Nexus 7 (2013) (all numbers in PSS)

adb shell dumpsys meminfo System “stuff”

126350 kB: com.google.android.googlequicksearchbox 75594 kB: surfaceflinger 46574 kB: com.android.systemui 45217 kB: system 45054 kB: com.google.android.inputmethod.latin 13073 kB: com.google.process.location 12074 kB: zygote 9011 kB: com.android.phone (really!?)

Other apps 68521 kB: com.facebook.katana 36805 kB: com.amazon.kindle 85455 kB: com.android.chrome …

The bigger they are, the faster they fall. Low-Memory Killer (LMK) (http://lwn.net/Articles/317814/)

Kills applications before the device runs out of memory; not when. “Androidism” Threshold heuristics

Recency Size Priority

Can be different per device.

Tablets are worse Pushing more pixels

Nexus 5: 1920 x 1080 Fire Phone: 1280 x 720 Nexus 7 (2013): 1920 x 1200 Kindle Fire HDX 7: 1920 x 1200 Kindle Fire HDX 8.9: 2560 x 1600

ARGB_8888 Fire Phone - ~3.5 MB Kindle Fire HDX 8.9: ~15.6 MB

More views or bigger views More advanced interfaces

Ramifications Crashes

Out of memory exceptions Can’t free memory fast enough, causing ANRS

Application terminated more frequently in background Restarts (thus slower starts) more often. Potential loss of state

Can cause these problems for other applications as well! More power consumption

Ramifications (continued) More GC invocations! GC invocations get logged to logcat:

Example: D/Dalvikvm GC_EXPLICIT freed 1328K 35 free 26195 39879K paused 3ms 5ms total 122ms

There are a few types of garbage collection: GC_CONCURRENT - Happens every so often based on Android's

perception of heap size. Some aspects of this are concurrent, but not all. GC_FOR_ALLOC - Happens when GC_CONCURRENT either couldn't

free enough space in time for an allocation, or the allocation exceeded expectations.

GC_BEFORE_OOM - A more aggressive GC call that happens right before a memory error. This occurs if GC_FOR_ALLOC fails.

GC_EXPLICIT - Explicit GC call. (if you want this control, go unmanaged)

Looking at memory

Quick look adb shell dumpsys meminfo <package name> Shared – Shared memory Private – Stuff that’s just yours or “yet to be shared”. RSS – Resident Set Size PSS – Proportional Set Size Activities Views

Memory leaks A leak is a situation in which you have unexpected growth. A

leak can be bounded or unbounded. You care about both! Bounded being “after a lot of use X grows to 300 MB but stays

there”. Unbounded being “things continue to grow and grow”

Rate of leak matters How does the leak occur?

Usage pattern Background interaction

Potential causes Context leaks

Activities Views

Bitmap leaks Singleton references Listeners Observers Async operations (runnables, handlers, threads) Inner classes hold references to parent classes

Testing for memory leaks watch --interval=2.0 “adb shell dumpsys meminfo <package name>”

Acceptance tests / automated UI tests that run through common interactions. Espresso

Monkeyrunner Note the seeds used in case you need to reproduce! Not smart, but randomized.

Testing (continued) Understand the lifecycle of components of your application.

Activities / Views shouldn’t hang around. Done with that Bitmap? When does that listener need to be deregistered? Make sure you’re actually cleaning up in a safe area. (

Activity#onStop() may not be called for example!) Cache only what you absolutely need!

There will be growth! GC doesn’t constantly run (that’d be very bad) Overhead should (hopefully) remain low.

Found a leak! Root causing. What’s leaking? Eclipse MAT

Activities, Views, Contexts, “managed stuff” NDK for unmanaged

Embedded into Eclipse Update site: http://download.eclipse.org/mat/1.3.1/update-site/ No conversions necessary. (hprof-conv)

Stand-alone tool http://www.eclipse.org/mat/downloads.php

NDK for unmanaged stuff

Using MAT Open hprof files. Interesting views

Histogram Dominator Tree Top consumers

Comparing two hprofs from Histogram

Still using MAT

• Weak references don’t prevent garbage collection.• Shallow heap – Object size in bytes.• Retained heap – Size objects that could be freed by freeing the

object.• Considers other references

/proc/[pid]/smapssmaps () { pid=$(adb shell ps | grep "$1" | awk '{print $2}'); adb shell cat /proc/$pid/smaps | tr -d '\r’ # Parsing problems} “This file shows memory consumption for each of the process’s mappings”

(proc man page) Useful for non-heap items (and in some situations when the NDK can’t help) There’s a lot of other fun stuff in /proc by the way. Check it out.

Estimation What are you going to take up in the worst case? What does a “worst case” even mean?

How does your application grow? Notes app – Number of notes, size of notes, extra details to note, number

of points in time notes occurred, etc. Books library – Number of books, covers of a book, book content,

different in-memory caches of books. Game – Textures, models, players, monsters, pieces, etc.

Measure costs along different points in that growth pattern to get an estimation and understand impact of different dimensions of growth.

Supported devices (and as a result, image sizes)

Good link http://developer.android.com/training/articles/memory.html

Thanks! Twitter: @russell_myers E-mail: me@russellmyers.com