Some memory methods

 

Android program memory is generally limited to 16 MB, of course there are also 24 MB, and Android program memory is divided into two parts:NativeAndDalvik,Dalvik is what we usually call Java heap.,The object we created is allocated here,Bitmap is directly allocated on native, and its memory limit isNative + DalvikThe maximum limit cannot be exceeded..

 

1. SingleMaximum app memory size

int memClass = ((ActivityManager) getSystemService(Context.ACTIVITY_SERVICE)).getMemoryClass();

Meter 2 test is 96

N5 is 192

 

2. "/proc/meminfo" system memory information file[Memory condition of the entire system]

Android obtains the total memory and available memory of the mobile phone.

"/Proc/meminfo" Parsing

 

3. activitymanager. memoryinfo [entire system]

Availmem remaining memory

Critical Value of threshold [kill the background service and non-associated process when the threshold is exceeded]

Lowmemory low memory status

 

4. Android. OS. Debug

Getnativeheapfreesize ()

Getnativeheapallocatedsize ()

Getnativeheapsize ()

 

5.Android. OS.Debug. memoryinfo[Memory of the current process]

 

 

6. Runtime

Totalmemory ()
Freememory ()
Maxmemory ()

 

7. vmruntime

Gettargetheaputilization ()

Getminimumheapsize ()

Getexternalbytesallocated () should be externally allocated native memory

8. What are gc_external_alloc freed and gc_explicit freed?
Memory prompt released by system GC

Generally, the log is shown as follows:
09-28 17:16:37. 543: Debug/dalvikvm (21466): gc_external_alloc freed 390 objects/45656 bytes in 50 ms
09-28 17:16:40. 513: Debug/dalvikvm (3267): gc_explicit freed 4501 objects/251624 bytes in 67 Ms
Explicit: the free memory is the memory used by Java in the VM, that is, heap mem.
Externa: the free memory is the memory allocated by malloc in the native class of JNI In the VM, such as bitmap and some cursor
In davilk, the memory allocated to a program varies with the model vendor. Most of the current memory is 32 MB, in the VM, the memory is divided into memory used by Java and memory used by native, which cannot be shared. That is to say, when your native memory is used up, now Java has idle memory, and Native will apply again like VM instead of using Java directly.

Example:
Explicit 3411 K/6663 K
External 24870 K/26260 K
If you need to create a 2 m
Bitmap, native has 26260-24870 = 1390 K memory, so he will apply for memory from the VM, although Java idle memory is 2048-6663 = 3411> 3252, however, this part of memory native cannot be used. However, if you apply for 2 MB native memory, the VM will tell you that it cannot be allocated because the used memory is close to the peak of 32 MB (26260 + 6663 = 32923 ), therefore, force close reports oom.
So now we need to check the usage of our native memory to avoid oom.

3. Run the ADB command (top, procrank, PS..., and other commands) to query the runtime class provided by the Android system.

Memory consumption: VSS/RSS/PSS/USS
Terms
• VSS-virtual set size virtual memory consumption (including memory occupied by shared libraries)
• RSS-resident set size actually uses physical memory (including memory occupied by shared libraries)
• Pss-proportional set size physical memory actually used (proportional allocation of memory occupied by the Shared Library)
• Uss-unique set size physical memory occupied by the process (excluding the memory occupied by the Shared Library)
Generally, the memory usage is as follows: VSS> = RSS> = PSS> = USS

 

 

 

Memory Allocation Principle: At the beginning, the system will allocate a maximum of about twice the memory used by your program. When not, adjust the upper limit slowly. When the upper limit is exceeded, the upper limit will be greatly adjusted, during the test, the adjustment below 64 was very small. When the usage exceeds 64 MB, the system adjusted the upper limit of memory to more than MB. After setting the honeycomb adds "largeheap" option

Before 3.0, GC operations took a long time, usually greater than 100 ms. When GC is executed, the program will become stuck. After 3.0, GC execution usually takes less than 5 ms, in versions earlier than 3.0, when loading images, the system loads bitmaps into native, which is not managed by GCT and needs to be released by the mobile phone. Otherwise, it will encounter an inexplicable memory problem. After 3.0, bitmaps will be directly stored in the memory for GC, and the memory occupied by useless bitmaps will be cleared in a timely manner. When the image is initialized, the image will be placed in the memory. After loading, the system will transfer images from memory to memory. When you use a memory testing tool, you will find that the memory usage is very high when loading images. When the loading is complete, the memory usage suddenly drops, this problem occurs when a large number of images are loaded.

 

 

References:

Http://blog.csdn.net/xpwang168/article/details/6982453

 

Some memory methods