有道云笔记 Android内存监控

http://note.youdao.com/noteshare?id=6733e5300c8a4d06fa3c41a4f03f5c7b

内存总量：/proc/meminfo

adb shelldumpsys meminfoYOUR-PACKAGE-NAME

VSS – Virtual Set Size 虚拟耗用内存(包含共享库占用的内存)

RSS – Resident Set Size 实际使用物理内存(包含共享库占用的内存)

PSS – Proportional Set Size 实际使用的物理内存(比例分配共享库占用的内存)

USS – Unique Set Size 进程独自占用的物理内存(不包含共享库占用的内存)

USS 是针对某个进程开始有可疑内存泄露的情况， 是一个程序启动了会产生的虚拟内存，一旦这个程序进程杀掉就会释放！

Item全称含义等价

USSUnique Set Size物理内存进程独占的内存

PSSProportional Set Size物理内存PSS= USS+ 按比例包含共享库

RSSResident Set Size物理内存RSS= USS+ 包含共享库

VSSVirtual Set Size虚拟内存VSS= RSS+ 未分配实际物理内存

https://testerhome.com/topics/2572

内存的采集：

Android的内存的采集这边介绍三种方式：

1，通过Dumpsys 来取值

adb shell dumpsys meminfo ( pid)

adb shell  dumpsys  meminfo  pakagename or Pid

有如下两种显示方式：

正确的观点：

大家都知道，过多地创建bitmap会导致OOM异常，且native heapsize不受dalvik限制，所以可以得出结论：

Bitmap只能是分配在dalvik heap上的，因为只有这样才能解释bitmap容易导致OOM。

在Android2.3和以前的版本，bitmap对象的像素数据都是分配在native heap中的，所以我们在调试过程中这部分内存是在java heap中看不到的，不过在android 3.0之后，bitmap对象就直接分配在java heap上了，这样便于调试和管理。因此在3.0之后我们可以复用bitmap的内存，而不必回收它，不过新的bitmap对象要大小和原来的一样，到了android 4.4之后，就只要高宽不超过原来的就行了。Bitmap是分配在dalvik heap上的，只有这样才能解释bitmap容易导致OOM。

最大内存限制只是限Dalvik heap 的大小

#查看单个应用程序最大内存限制 对于 OOM 的监测很重要！！adb shell getprop|grepheapgrowthlimit

而meminfo 里面的dalvik heap size 的最大值若果超出了128M 那就很可能会发生OOM

2.使用ActivityManager

1. ActivityManager.MemoryInfo :

availMem:表示系统剩余内存

lowMemory：它是boolean值，表示系统是否处于低内存运行

hreshold：它表示当系统剩余内存低于好多时就看成低内存运行

我用过以上三种最多，其实Top 也可以 还有很多方法都可以。

2.Debug.MemoryInfo

dalvikPrivateDirty 进程占用内存

3.android 每个 app 内存限制大小

activityManager.getMemoryClass();

// OOM 之前

Runtime.getRuntime().addShutdownHook();

leakcanary 原理