Android: Managing Memory

Android: Managing Memory Russell Myers

Me Russell 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. • KitKatcould 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 dumpsysmeminfo • 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!?) • Otherapps • 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/DalvikvmGC_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 dumpsysmeminfo <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 dumpsysmeminfo<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]/smaps smaps () { 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

Android: Managing Memory