Memory Management for Android apps note GC

From: http://www.poemcode.net/2012/06/interpreting_log_message/

This blog post is for Google
I/O 2011: One of the notes made by the memory management for Android app, mainly used to deliver the speaker Patrick
Dubroy's point of view is a small part of his understanding. The opinion here may contain errors or outdated information. Therefore, it is recommended that you directly watch the original video or presentation if your English skills are acceptable.

Memory Management for Android apps

Android logs are the right assistant for developers to check system and application running conditions. They are like dashboards in front of drivers. vehicle speed, mileage, fuel volume, and other data are related to driving safety, the GC information in the log reflects the health status of the system and application. Careful developers can even determine whether memory leakage has occurred.

The following are the three GC messages that I have captured. They represent three common scenarios. I used the same code in different versions, such as 2.2 (froyo), 2.3 (gingerbread), and 4.0.2 (ice cream sandwich), and found that the GC information changes greatly, this also confirms the speaker's statement about the change of Dalvik vm gc in 2.3 and 3.0.


Gc_concurrent freed 2234 K, 35% free 9013 K/13767 K, external 821 K/1435 K, paused 9 ms + 9 ms

Gc_for_malloc freed 689 K, 33% free 8959 K/13319 K, external 1451 K/1688 K, paused 82 Ms

Gc_external_alloc freed 122 K, 38% free 8460 K/13511 K, external 1519 K/1519 K, paused 78 Ms

The GC information can be divided into several parts, such as reason for GC and amount freed.

Reason for GC

There are five types mentioned by the speaker. gc_explicit is not recommended and rarely seen. gc_hprof_dump_heap does not occur during normal operation. Gc_concurrent is only available in Version 2.3. At the same time, gc_for_malloc removes "M ".

1. gc_concurrent

Triggered by basically, as your heap starts to fill up. VM kick off the current garbage collection so that it can hopefully complete before the heap gets full.

2. gc_for_malloc/gc_for_alloc

VM don't complete the concurrent collection in time and application has to allocate more memory. The heap was full, so VM had to stop and do a garbage collection.

3. gc_external_alloc

Externally allocated memory, like bitmap pixel data. It's also used for NiO direct byte buffers. The external memory has gone away in honeycomb, and basically everything is allocated inside the Dalvik heap now.

Now this external memory has gone away in Honeycomb. Basically everything is allocated inside the Dalvik heap now. So you won't see this in your log messages in honeycomb and later.

4. gc_hprof_dump_heap

When you do a hprof profile.

5. gc_explicit

When call system. GC, gc_explicit happen. programmer shoshould avoid doing this, and trust in the garbage collector.

Amount freed

The amount of memory that was freed on this collection

Heap statistics

XX % freed after the Collection Completed.

The 1st number is live objects

The 2nd number is the total heap size

External memory statistics

Which is bitmap pixel data and also NiO direct byte buffers.

The 1st of number is the amount of external memory that your app has allocated

The 2nd number is a sort of soft limit. When you 've allocated that much memory, we're re going to kick off GC.

Here, I have a question: the speaker mentioned that after 2.3, the external memory data (Bitmap pixel data) was moved to Dalvik heap. So what exactly is the data saved to this location?

Pause Time

One short pause at the beginning of the collection and one most of the way through. Non-concurrent collections you will see a single pause time.

Here, I have a question: the non-concurrent GC class only takes a long time to understand, but why does the concurrent GC class have two values? To understand the speaker literally, there are two time-consuming values, where does the intermediate value go when it starts and ends?