The meaning of Android meminfo

http://gdgzzch.blog.163.com/blog/static/37640452201371483147573/

http://stackoverflow.com/questions/2298208/how-to-discover-memory-usage-of-my-application-in-android#2299813
http://my.oschina.net/shaorongjie/blog/128442

You can use adb shell dumpsys meminfo-a <process id>/<process name> to see the memory of a process. As follows:

Naitve Heap Size: Obtained from Mallinfo usmblks, representing the maximum total allocated space

Native Heap Alloc: Obtained from Mallinfo uorblks, total space allocated

Native Heap Free: Obtained from Mallinfo Fordblks, representing total remaining space

Native heap Size is approximately equal to Native heap Alloc + Native heap Free

Mallinfo is a C library, and the Mallinfo function provides a variety of statistics about the memory allocated by the malloc () function of C.

Dalvik Heap Size: Obtained from runtime TotalMemory (), the total memory size of the Dalvik heap.

Dalvik Heap Alloc:runtime totalmemory ()-freememory (), the amount of memory allocated by the Dalvik heap.

Dalvik Heap Free: Obtained from runtime Freememory (), the remaining memory size of the Dalvik heap.

Dalvik heap Size is approximately equal to Dalvik heap Alloc + Dalvik heap Free

Otherpss, include Cursor,ashmem, other Dev,.-Mmap,. Jar Mmap,. apk mmap,. TTF mmap,. Dex Mmap, other mmap, unkown statistics Information can be seen in the process's SMAP file.

Objects and SQL information is obtained from the Android debug information.

Other types SMAP path name Description

Cursor/dev/ashmem/cursor Cursor consumption of memory (KB)

Ashmem/dev/ashmem Anonymous shared memory is used to provide shared memory by assigning a multiple process

A memory block with names that can be shared

Other dev/dev/internal driver occupy the "other dev"

. So mmap. C Library Code occupies memory

. Jar mmap. Jar Java file code occupies memory

. apk mmap. APK apk Code occupies memory

. TTF mmap. TTF TTF file code occupies memory

. Dex mmap. Dex Dex file code occupies memory

Other mmap memory occupied by other files

Difference is between "Pss", "Privatedirty", and "Shareddirty" ... well now the fun begins.

A lot of memory in Android (and Linux systems in general) is actually shared across multiple processes. So how much memory a processes uses are really not clear. Add on top of this paging out to disk (let alone swap which we don't use on Android) and it's even less clear.

Thus If you were to take all of the physical RAM actually mapped on to each process, and add up all of the processes, you Would probably end up with a number much greater than the actual total RAM.

The PSS number is a metric the kernel computes this takes into account memory sharing--basically all page of RAM in a P Rocess is scaled by a ratio of the number of other processes also using that page. This-the-theory-add up-the PSS across all processes-to-see-the-total RAM they is using, and compare PSS BETW Een processes to get a rough idea of their relative weight.

The other interesting metric are privatedirty, which is basically the amount of RAM inside the process so can not be Paged to disk (it isn't backed by the same data on disk), and are not shared with any other processes. Another-on-the-look at the-is-RAM that would become available to the system when that process goes away (and probably Quickly subsumed to caches and other uses of it).

That's pretty much the SDK APIs for this. However there is more than you can does as a developer with your device.

Using ADB, there is a lot of information you can get about the memory using the a running system. A common one is the command "adb shell Dumpsys meminfo" which would spit out a bunch of information on the memory use of Each Java process, containing the above info as well as a variety of other things. You can also tack on the name or PID of a single process to see, for example "adb shell Dumpsys meminfo system" Give me th E System process:

 * * Meminfo in PID 890 [System] * * Native Dalvik other total size:10940     7047 N/a 17987 allocated:8943 5516 N/a 14459 free:336 1531 N/A 1867 (PSS): 4585 9282 11916 25783 (Gkfx dirty): 2184 3596 916 6696 (priv       Dirty): 4504 5956 7456 17916 Objects views:149 viewroots:4 appcontexts: activities:0 assets:4 assetmanagers:4 Local binders:141 Prox        Y binders:158death recipients:49 OpenSSL sockets:0 SQL heap:205 dbfiles: 0 numpagers:0 inactivepagekb:0 activepagekb:0 

The top section was the main one, where "size" is the total size in address space of a particular heap, "allocated" is the KB of actual allocations that heap thinks it have, "free" are the remaining KB free the heap have for additional allocations, and "PSS" and "Priv dirty" is the same as discussed before specific to pages associated with each of the heaps.

If you just want to look at memory usage across all processes, you can use the command "adb shell Procrank". Output of this in the same system looks like:

 PID Vss Rss Pss Uss cmdline 890 84456K 48668K 25850K 21284K system_server 1231 507    48K 39088K 17587K 13792K com.android.launcher2 947 34488K 28528K 10834K 9308K com.android.wallpaper 987   26964K 26956K 8751K 7308K com.google.process.gapps 954 24300K 24296K 6249K 4824K com.android.phone  948 23020K 23016K 5864K 4748K com.android.inputmethod.latin 888 25728K 25724K 5774K 3668K zygote   977 24100K 24096K 5667K 4340K android.process.acore ... 336K 332K 99K 92k/system/bin/installd 396K 392K 93K 84k/system/bin/keystor E 280K 276K 74K 68k/system/bin/servicemanager 256K 252K 69K 64k/system/b In/debuggerd 

Here the Vss and RSS columns is basically noise (these is the Straight-forward address space and RAM usage of a process, Where if you add up the RAM usage across processes your get an ridiculously large number).

Pss is as we ' ve seen before, and Uss is Priv Dirty.

Interesting thing to note HERE:PSS and Uss is slightly (or more than slightly) different than what we saw in Meminfo. Why was that? Well Procrank uses a different kernel mechanism to collect its data than Meminfo does, and they give slightly different re Sults. Why was that? Honestly I haven ' t a clue. I believe Procrank is the more accurate one ... but really, this just leave the point: ' Take any memory info ' get WI Th a grain of salt; Often a very large grain. "

Finally there is the command "adb shell cat/proc/meminfo", that gives a summary of the overall memory usage of the system. There is a IoT of data here, only the first few numbers worth discussing (and the remaining ones understood by few people , and my questions of those few people about them often resulting in conflicting explanations):

Memtotal:         395144 kbmemfree:          184936 kbbuffers:             880 kbcached:            84104 kbswapcached:            0 KB

Memtotal is the total amount of memory available to the kernel and user space (often less than the actual physical RAM of The device, since some of that RAM are needed for the radio, DMA buffers, etc).

Memfree is the amount of RAM, which is not being used at all. The number is very high; Typically on Android system would is only a few MB, since we try to use available memory to keep processes running

Cached is the RAM being used for filesystem caches and other such things. Typical systems would need to having 20MB or so for this to avoid getting into bad paging states; The Android out of memory killer was tuned for a particular system to make sure that background processes was killed before The cached RAM is consumed too much by them to result in such paging.

Android Meminfo The meaning of the various (turn)