android 查看内存使用情况

文章出处：http://blog.csdn.net/shift_wwx

请转载的朋友标明出处~~

查看内存使用情况，有好几种方法，我这里结合自己的想法总结一下，不知道对不对，希望看到的朋友不吝赐教。

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 -hmeminfo 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  TOTALRAM: 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 是针对某个进程开始有可疑内存泄露的情况，进行检测的最佳数字。