Time to fix your apps: Manage Your App’s Memory Overview

The Memory Profiler is a component in the Android Profiler that helps you identify memory leaks and memory churn that can lead to stutter, freezes, and even app crashes. It shows a realtime graph of your app’s memory use, lets you capture a heap dump, force garbage collections, and track memory allocations.

Okey devs, let’s get our hand dirty by working out with memory management in Android Apps. To manage memory Android Runtime(ART) and Dalvik Virtual Machine use paging and memory-mapping which means that any memory that app modifies whether by allocating new object or touching mapped pages. The only way to release memory from an app is to release object references that the app holds, making the memory available to the garbage collector.

Garbage collection

Garbage Collection is a form of automatic memory management. The garbage collector, or just collector, attempts to reclaim garbage, or memory occupied by objects that are no longer in use by the program.

In android, a managed memory environment, like the ART or Dalvik virtual machine, keeps track of each memory allocation. Once it determines that a piece of memory is no longer being used by the program, it frees it back to the heap, without any intervention from the programmer. The mechanism for reclaiming unused memory within a managed memory environment is known as garbage collection. You don’t generally control when a garbage collection event occurs from within your code.

Garbage collection has two goals:

1. find data objects in a program that cannot be accessed in the future

2. reclaim the resources used by those objects.

Each heap generation has its own dedicated upper limit on the amount of memory that objects there can occupy. Any time a generation starts to fill up, the system executes a garbage collection event in an attempt to free up memory. The duration of the garbage collection depends on which generation of objects it’s collecting and how many active objects are in each generation.

Even though garbage collection can be quite fast, it can still affect your app’s performance. The system has a running set of criteria for determining when to perform garbage collection. When the criteria are satisfied, the system stops executing the process and begins garbage collection. If garbage collection occurs in the middle of an intensive processing loop like an animation or during music playback, it can increase processing time.

Lastly, Like other memory management techniques, garbage collection may take a significant proportion of total processing time in a program and, as a result, can have significant influence on performance.

Sharing Memory

SharedMemory enables the creation, mapping, and protection control over anonymous shared memory. In order to fit everything it needs in RAM, Android tries to share RAM pages across processes. It can do so in the following ways:

• Each app process is forked from an existing process called Zygote. The Zygote process starts when the system boots and loads common framework code and resources (such as activity themes). To start a new app process, the system forks the Zygote process then loads and runs the app’s code in the new process. This approach allows most of the RAM pages allocated for framework code and resources to be shared across all app processes.
• Most static data is mapped into a process. This technique allows data to be shared between processes, and also allows it to be paged out when needed.
• In many places, Android shares the same dynamic RAM across processes using explicitly allocated shared memory regions (either with ashmem or gralloc).

Allocating and Reclaiming App Memory

The Dalvik heap is constrained to a single virtual memory range for each app process. This defines the logical heap size, which can grow as it needs to but only up to a limit that the system defines for each app.

The logical size of the heap is not the same as the amount of physical memory used by the heap. When inspecting your app’s heap, Android computes a value called the Proportional Set Size (PSS), which accounts for both dirty and clean pages that are shared with other processes but only in an amount that’s proportional to how many apps share that RAM. This (PSS) total is what the system considers to be your physical memory footprint.

The Dalvik heap does not compact the logical size of the heap, meaning that Android does not defragment the heap to close up space. Android can only shrink the logical heap size when there is unused space at the end of the heap. However, the system can still reduce physical memory used by the heap. After garbage collection, Dalvik walks the heap and finds unused pages, then returns those pages to the kernel using madvise.

Restricting App Memory

To maintain a functional multi-tasking environment, Android sets a hard limit on the heap size for each app. The exact heap size limit varies between devices based on how much RAM the device has available overall. If your app has reached the heap capacity and tries to allocate more memory, it can receive an OutOfMemoryError. In some cases, you might want to query the system to determine exactly how much heap space you have available on the current device like.

Switching apps

When users switch between apps, Android keeps apps that are not foreground that is, not visible to the user or running a foreground service like music playback in a least-recently used (LRU) cache. For example, when a user first launches an app, a process is created for it. But when the user leaves the app, that process does not quit. The system keeps the process cached. If the user later returns to the app, the system reuses the process, thereby making the app switching faster.

If your app has a cached process and it retains memory that it currently does not need, then your app even while the user is not using it affects the system’s overall performance. As the system runs low on memory, it kills processes in the LRU cache beginning with the process least recently used. The system also accounts for processes that hold onto the most memory and can terminate them to free up RAM.