Android Memory Management: Understanding App PSS

When you run Little Eye on your App, in the memory view, 3 important statistics about your App’s memory are reported. The Dalvik memory usage, which is how much memory is consumed by the Java heap, the Native memory, which is how much memory is being used by the process outside of the JVM.

Then there is a third statistic, cryptically called the “PSS”. Just what is PSS?

Propotionate Set Size

The “Proportionate Set Size” is a statistic that the Android system computes, to determine if it is going to kill your process. Simply looking at how much memory your App is consuming, is not the right way, since your App maybe using some shared memory with other processes, and it is “unfair” to blame your App for any shared memory it is using. The Android system is likely to kill Apps that are using too much memory (especially if the App is in the background), so the Android system needs to find a way to reliably compute how much memory your App is responsible for.

What exactly is Shared Memory?

Android is a Linux-based system, and Linux uses “shared” pages to share the same memory across processes. One common use of shared memory is to share the “code” memory pages (the area of memory where read-only executable code is loaded) across processes. External libraries and the JVM’s executable code are examples of areas of memory that can be safely shared across processes. There could also be data pages, which are “copy-on-write”, which could be shared temporarily between processes, until a processes modifies the shared memory.

Computing “real” memory usage by an App

So, to “fairly” calculate how much memory is used by an App, Android uses the PSS statistic. Basically, it is a sum of the non-shared memory consumed by your App, and the part of the shared memory that can be “attributed to your app” – (memory that is shared with other processes)/(# of processes that is sharing it)

Now, Android has a “fairer” picture of who’s consuming a lot of memory, and Android will start killing processes in the order of PSS.

What does it mean to you as an App developer?

If your App gets a very high PSS score, your App is likely to be killed by the Android system. Maybe this is something you can handle, but getting killed in the background unexpectedly can have consequences for your App, especially if you’re relying on some background activities or services to do work. Make sure that your App’s PSS isn’t too high, especially when your App goes into the background. It may be a good idea to free memory and objects that you no longer need in the background, and disconnect from any shared memory that you no longer need when you go into the background. This will reduce your chances of getting unexpectedly killed by the Android system.

The one thing to remember is that there are no “hard limits” on PSS – There’s no guarantee that your App will get killed above a certain threshold, or is guaranteed to survive if PSS is below some threshold. While an app has to be prepared for getting killed ANY time it’s not in foreground, it helps reduce those chances if the PSS is lesser.