文章出处：http://blog.csdn.net/shift_wwx/article/details/42490863
请转载的朋友标明出处~~
查看内存使用情况，有好几种方法，我这里结合自己的想法总结一下，不知道对不对，希望看到的朋友不吝赐教。
1. cat /proc/meminfo
MemTotal: 所有可用RAM大小 （即物理内存减去一些预留位和内核的二进制代码大小）
MemFree: LowFree与HighFree的总和
Buffers: 用来给块设备做的缓冲大小（只记录文件系统的metadata以及 tracking in-flight pages，就是说 buffers是用来存储，目录里面有什么内容，权限等等。）
Cached: 用来给文件做缓冲大小（直接用来记忆我们打开的文件）. 它不包括SwapCached
SwapCached: 已经被交换出来的内存，但仍然被存放在swapfile中。用来在需要的时候很快的被替换而不需要再次打开I/O端口。
Active: 最近经常被使用的内存，除非非常必要否则不会被移作他用.
Inactive: 最近不经常被使用的内存，非常用可能被用于其他途径.
HighTotal:
HighFree: 高位内存是指所有在860MB以上的内存空间，该区域主要用于用户空间的程序或者是缓存页面。内核必须使用不同的手法使用该段内存，因此它比低位内存要慢一些。
LowTotal:
LowFree: 低位可以达到高位内存一样的作用，而且它还能够被内核用来记录一些自己的数据结构。
Among many other things, it is where everything from the Slab is
allocated. Bad things happen when you're out of lowmem.
SwapTotal: 交换空间的总和
SwapFree: 从RAM中被替换出暂时存在磁盘上的空间大小
Dirty: 等待被写回到磁盘的内存大小。
Writeback: 正在被写回到磁盘的内存大小。
Mapped: 影射文件的大小。
Slab: 内核数据结构缓存
VmallocTotal: vmalloc内存大小
VmallocUsed: 已经被使用的虚拟内存大小。
VmallocChunk: largest contigious block of vmalloc area which is free
CommitLimit:
Committed_AS:
2. dumpsys meminfo
更多关于dumpsys的使用信息，可以查看：android 中的dumpsys
可以dump的这些service都是在ServiceManager里面添加上的，例如meminfo是在：frameworks/base/services/java/com/android/server/am/ActivityManagerService.java的函数setSystemProcess添加的：
public static void setSystemProcess() {
try {
ActivityManagerService m = mSelf;
ServiceManager.addService(Context.ACTIVITY_SERVICE, m, true);
ServiceManager.addService(ProcessStats.SERVICE_NAME, m.mProcessStats);
ServiceManager.addService("meminfo", new MemBinder(m));
ServiceManager.addService("gfxinfo", new GraphicsBinder(m));
ServiceManager.addService("dbinfo", new DbBinder(m));
if (MONITOR_CPU_USAGE) {
ServiceManager.addService("cpuinfo", new CpuBinder(m));
}
ServiceManager.addService("permission", new PermissionController(m));
ApplicationInfo info =
mSelf.mContext.getPackageManager().getApplicationInfo(
"android", STOCK_PM_FLAGS);
mSystemThread.installSystemApplicationInfo(info);
synchronized (mSelf) {
ProcessRecord app = mSelf.newProcessRecordLocked(info,
info.processName, false);
app.persistent = true;
app.pid = MY_PID;
app.maxAdj = ProcessList.SYSTEM_ADJ;
app.makeActive(mSystemThread.getApplicationThread(), mSelf.mProcessStats);
mSelf.mProcessNames.put(app.processName, app.uid, app);
synchronized (mSelf.mPidsSelfLocked) {
mSelf.mPidsSelfLocked.put(app.pid, app);
}
mSelf.updateLruProcessLocked(app, false, null);
mSelf.updateOomAdjLocked();
}
} catch (PackageManager.NameNotFoundException e) {
throw new RuntimeException(
"Unable to find android system package", e);
}
}
来看一下MemBinder：
@Override
protected void dump(FileDescriptor fd, PrintWriter pw, String[] args) {
if (mActivityManagerService.checkCallingPermission(android.Manifest.permission.DUMP)
!= PackageManager.PERMISSION_GRANTED) {
pw.println("Permission Denial: can't dump meminfo from from pid="
+ Binder.getCallingPid() + ", uid=" + Binder.getCallingUid()
+ " without permission " + android.Manifest.permission.DUMP);
return;
}
mActivityManagerService.dumpApplicationMemoryUsage(fd, pw, " ", args, false, null);
}
最终调用的是：
mActivityManagerService.dumpApplicationMemoryUsage具体的source code这里暂不作分析了。
通过code可以看出meminfo的几个参数如下：
root@n300:/ # dumpsys meminfo -h meminfo dump options: [-a] [-d] [-c] [--oom] [process] -a: include all available information for each process. -d: include dalvik details when dumping process details. -c: dump in a compact machine-parseable representation. --oom: only show processes organized by oom adj. --local: only collect details locally, don't call process. If [process] is specified it can be the name or pid of a specific process to dump.
process这个参数比较奇怪，option说明上说pid也是可以的，但是我用的时候提示不行，不知道谁能帮解释一下。
最终只好用process name来：
root@h15:/ # dumpsys meminfo com.qiyi.video
Applications Memory Usage (kB):
Uptime: 1701367 Realtime: 1701367
** MEMINFO in pid 4034 [com.qiyi.video] **
Pss Private Private Swapped Heap Heap Heap
Total Dirty Clean Dirty Size Alloc Free
------ ------ ------ ------ ------ ------ ------
Native Heap 0 0 0 0 6292 4422 41
Dalvik Heap 9769 9752 0 0 11376 9996 1380
Dalvik Other 3714 3652 0 0
Stack 116 116 0 0
Ashmem 18800 18800 0 0
Other dev 5 0 4 0
.so mmap 1859 524 100 0
.jar mmap 4 0 4 0
.apk mmap 862 0 520 0
.ttf mmap 840 0 808 0
.dex mmap 5229 264 3972 0
Other mmap 95 4 0 0
Unknown 3867 3864 0 0
TOTAL 45160 36976 5408 0 17668 14418 1421
Objects
Views: 218 ViewRootImpl: 2
AppContexts: 4 Activities: 1
Assets: 18 AssetManagers: 18
Local Binders: 16 Proxy Binders: 18
Death Recipients: 2
OpenSSL Sockets: 0
SQL
MEMORY_USED: 180
PAGECACHE_OVERFLOW: 28 MALLOC_SIZE: 62
DATABASES
pgsz dbsz Lookaside(b) cache Dbname
4 20 17 0/17/1 /data/user/0/com.qiyi.video/databases/iqiyi_tv.db
4 20 118 2/17/3 /data/user/0/com.qiyi.video/offline_database/offline.db
看到这个信息之后一阵惊喜，打印出来的信息有这么多，不错～～
But as to what the 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 is really not clear. Add on top of that paging out to disk (let alone swap which we don't use on Android) and it is even less clear. Thus if you were to take all of the physical RAM actually mapped in 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 that takes into account memory sharing -- basically each page of RAM in a process is scaled by a ratio of the number of other processes also using that page. This way you can (in theory) add up the pss across all processes to see the total RAM they are using, and compare pss between processes to get a rough idea of their relative weight. The other interesting metric here is PrivateDirty, which is basically the amount of RAM inside the process that can not be paged to disk (it is not backed by the same data on disk), and is not shared with any other processes. Another way to look at this is the RAM that will become available to the system when that process goes away (and probably quickly subsumed into caches and other uses of it).
从这篇文章中得知：
一般的android和linux系统中很多进程会共享一些mem，所以一个进程用到的mem其实不是十分清除，
因此如果将每个进程实际占用的mem加到一起，可能会发现这个结果会远远的超过实际的总的mem。
Pss 是kernel根据共享mem计算得到的值，Pss的值是一块共享mem中一定比例的值。这样，将所有进程Pss加起来就是总的RAM值了，也可以通过进程间Pss值得到这些进程使用比重情况。
PrivateDirty，它基本上是进程内不能被分页到磁盘的内存，也不和其他进程共享。查看进程的内存用量的另一个途径，就是当进程结束时刻，系统可用内存的变化情况（也可能会很快并入高速缓冲或其他使用该内存区的进程）
其他类型 smap 路径名称 描述
Ashmem /dev/ashmem 匿名共享内存用来提供共享内存通过分配一个多个进程
可以共享的带名称的内存块
Other dev /dev/ 内部driver占用的在 “Other dev”
.so mmap .so C 库代码占用的内存
.jar mmap .jar Java 文件代码占用的内存
.apk mmap .apk apk代码占用的内存
.ttf mmap .ttf ttf 文件代码占用的内存
.dex mmap .dex Dex 文件代码占用的内存
Other mmap 其他文件占用的内存
当然，具体的还有直接dumpsys meminfo，这个只是能看到所有的总值，具体的还是需要加上process name。
Total RAM: 753344 kB Free RAM: 496064 kB (32756 cached pss + 184972 cached + 278336 free) Used RAM: 178637 kB (162385 used pss + 4648 buffers + 348 shmem + 11256 slab) Lost RAM: 78643 kB Tuning: 64 (large 384), oom 122880 kB, restore limit 40960 kB (high-end-gfx) root@h15:/ #
之前一直看不懂Lost RAM是什么意思？只好求助source code：
pw.print(" Lost RAM: ");
pw.print(memInfo.getTotalSizeKb()
- totalPss
- memInfo.getFreeSizeKb()
- memInfo.getCachedSizeKb()
- memInfo.getBuffersSizeKb()
- memInfo.getShmemSizeKb()
- memInfo.getSlabSizeKb()
);就是说Lost RAM = Total RAM - Free RAM - Used RAM
3. procrank
root@h15:/ # procrank PID Vss Rss Pss Uss cmdline 4034 744312K 80076K 63779K 61188K com.qiyi.video 3887 691700K 69676K 54293K 51784K com.android.systemui 3749 709572K 36112K 20045K 17728K system_server 2586 55280K 15424K 10098K 8804K /system/bin/tvserver 2594 68848K 14268K 8235K 6124K /system/bin/mediaserver 4151 665424K 20184K 7157K 6016K android.process.acore ... ... ... 2599 3512K 452K 180K 168K /system/bin/sdcard 2595 1000K 444K 165K 152K /system/bin/installd 2608 1500K 176K 160K 160K /sbin/adbd 2580 1428K 148K 136K 136K /sbin/healthd 2582 1008K 348K 118K 108K /system/bin/servicemanager 2588 364K 96K 80K 80K /system/bin/dig ------ ------ ------ 236736K 207864K TOTAL RAM: 753344K total, 260444K free, 6788K buffers, 187252K cached, 348K shmem, 11480K slab
Android procrank (/system/xbin/procrank) 工具，能够列出进程所占用的内存使用情况。顺序为从高到低。
每个进程占用内存大小以 VSS, RSS , PSS, USS 的形式列出。
为了简化描述，内存占用以页为单位表述，而不是字节。 通常每页为 4096 字节。
VSS ( 等同于 ps 命令列出的 VSZ) 是单个进程全部可访问的地址空间。
其大小包括可能还尚未在内存中驻留的部分。比如地址空间已经被 malloc 分配，但是还没有实际写入。
对于确定单个进程实际内存使用大小， VSS 用处不大。
RSS 是单个进程实际占用的内存大小。
RSS 易被误导的原因在于， 它包括了该进程所使用的所有共享库的全部内存大小。对于单个共享库， 尽管无论多少个进程使用，
实际该共享库只会被装入内存一次。
对于单个进程的内存使用大小， RSS 不是一个精确的描述。
PSS 不同于RSS，它只是按比例包含其所使用的共享库大小。
例如， 三个进程使用同一个占用 30 内存页的共享库。 对于三个进程中的任何一个，PSS 将只包括 10 个内存页。
PSS 是一个非常有用的数字，因为系统中全部进程以整体的方式被统计， 对于系统中的整体内存使用是一个很好的描述。
如果一个进程被终止， 其PSS 中所使用的共享库大小将会重新按比例分配给剩下的仍在运行并且仍在使用该共享库的进程。
此种计算方式有轻微的误差，因为当某个进程中止的时候， PSS 没有精确的表示被返还给整个系统的内存大小。
USS 是单个进程的全部私有内存大小。亦即全部被该进程独占的内存大小。
USS 是一个非常非常有用的数字， 因为它揭示了运行一个特定进程的真实的内存增量大小。
如果进程被终止， USS 就是实际被返还给系统的内存大小。
USS 是针对某个进程开始有可疑内存泄露的情况，进行检测的最佳数字。